Pattern · Draft
Edge Configuration
Keep routing and rollout configuration in Parameter Store and project it to the edge.
Architecture
Parameter Store holds the desired routing state. A sync Lambda projects it into CloudFront KeyValueStore, which the edge function reads for each request. Configuration propagates asynchronously, so the edge may temporarily use older settings without a distribution update.
Draft: this pattern is captured but not yet reviewed. The forces, trade-offs and failure modes below are a working position, not a finished one.
The problem
CloudFront Functions cannot read Parameter Store, because they run at the edge with no network access. Operators still want to change routing and rollout without a Terraform apply or a distribution update.
The solution
Parameter Store holds the desired state. A sync Lambda reads it and writes a compact map into CloudFront KeyValueStore, and the edge function reads that map on each request. Changes land in seconds, without touching the distribution.
Forces
What pulls against what.
- Operability against control
- Eventual consistency against safety
- Blast radius of an edge configuration change
On AWS
- SSM Parameter Store
- CloudFront KeyValueStore
- CloudFront Functions
- Lambda
Trade-offs
- Routing and rollout become operational changes rather than releases
- The sync path is another component to observe, secure, and reason about
- Configuration is eventually consistent at the edge, so a rollback is fast but not immediate
When not to use it
- Configuration is static and safe to set once at deploy time
- A distributed configuration system already holds the same values
Failure modes
How it breaks when it breaks.
- A silent sync failure leaves the edge on stale configuration
- The parameter or the store grows past its size limits
- No audit trail of who changed the parameter, or when