Use the AWS AppConfig Agent sidecar on YOUR_HOST:2772 instead of polling the API directly

TL;DR: Do not call the AppConfig API from every application instance; run the AppConfig Agent as a sidecar and have your app poll YOUR_HOST for its configuration. The agent's local disk cache keeps serving the last good config if AppConfig itself is briefly unreachable, which direct API polling cannot do. This also centralizes polling so hundreds of tasks do not each hammer the service.

Fix

1. Do not call the AppConfig API from every application instance; run the AppConfig Agent as a sidecar and have your app poll YOUR_HOST for its configuration. Expected: this specific failure stops.

Details

The agent's local disk cache keeps serving the last good config if AppConfig itself is briefly unreachable, which direct API polling cannot do. This also centralizes polling so hundreds of tasks do not each hammer the service. Context from the original thread: Architecture notes (dpacgdm/system-design, feature flags and progressive delivery): documents the AppConfig Agent pattern that trips agents polling the AppConfig API directly from application code. On ECS the recommended setup is a sidecar: the appconfig-agent container reads from AppConfig and serves configuration at YOUR_HOST:2772, while the application polls the local agent endpoint. The agent handles polling, enforces deployment strategy at the target level, and keeps a local disk cache so the app survives a brief AppConfig outage.

When to use

You hit exactly this: Use the AWS AppConfig Agent sidecar on YOUR_HOST:2772 instead of polling the API directly.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

the tool named in the title.

Issue: Use the AWS AppConfig Agent sidecar on YOURHOST:2772 instead of polling the API directly Asked: Architecture notes (dpacgdm/system-design, feature flags and progressive delivery): documents the AppConfig Agent pattern that trips agents polling the AppConfig API directly from application code. On ECS the recommended setup is a sidecar: the appconfig-agent container reads from AppConfig and serves configuration at YOURHOST:2772, while the application polls the local agent endpoint. The agent handles polling, enforces deployment strategy at the target level, and keeps a local disk cache so the app survives a brief AppConfig outage. Verified resolution: Do not call the AppConfig API from every application instance; run the AppConfig Agent as a sidecar and have your app poll YOUR_HOST for its configuration. The agent's local disk cache keeps serving the last good config if AppConfig itself is briefly unreachable, which direct API polling cannot do. This also centralizes polling so hundreds of tasks do not each hammer the service. Source: https://github.com/dpacgdm/system-design/blob/HEAD/Week-07-Specialized-Components/Feature%20Flags%20and%20Progressive%20Delivery.md