DOC-410: Document CloudFront Functions execution and KeyValueStore

[dmacvicar]

Note

This is my suggested documentation change for CloudFront KeyValue store services. As I will be on vacation 🌴 the next two weeks and I just merged this feature. Feel free to use this as inspiration for the documentation, or just merge it as-s.

LocalStack now executes CloudFront Functions at request time and supports CloudFront KeyValueStore on both planes (localstack-pro#8204, ENG-1091).

This matters to teams whose edge routing is a CloudFront Function with its decision data in KVS: tenant pre-routers, canary and A/B routing, lookup-driven rewrites. Previously the code was stored but never run, so there was nothing to test locally.

Changes

aws/services/cloudfront.mdx gains three sections. I put it in the relevant service following the example of s3/s3control rds/rds-data, bedrock/bedrock-runtime, etc.

• CloudFront Functions: create, test, publish, associate, short-circuit responses, and the divergences that matter (viewer-request only, default cache behavior only, cf.kvs() as the only runtime helper, Node rather than AWS's restricted runtime).
• KeyValueStore: control plane on cloudfront, data plane on cloudfront-keyvaluestore, ETag handling per plane, the cf.kvs() surface, an error parity table, Terraform usage.
• Tenant routing at the edge: worked end-to-end example, inspired in the examples provided by the customer who requested the feature.

src/data/licensing/current-plans.json registers the KVS data plane as Ultimate, so the page carries both plan tags (synced with npm run sync:licensing-tags).

Reviewer highlights

• The URI-rewrite routing deviation is a caution, not a feature. LocalStack re-evaluates the cache behavior after a function rewrites the URI; real CloudFront matches it before the function runs and never re-evaluates. The integration test relies on this, so it would be easy to present as the recommended pattern. The doc leads with header stamping, which behaves the same on AWS, and marks the rewrite path as local-only.
• The tier split is user-visible. Per localstack/localstack-platform#2092 the data plane is Ultimate while CloudFront stays Base. On Base you can create a store and associate it with a function but not seed keys, and cf.kvs().get() then throws at request time. The doc says so directly rather than letting users hit it as a silent wrong answer.
• Coverage data is stale on purpose. src/data/coverage/cloudfront.json still marks the five KVS operations and TestFunction unimplemented; it is auto-generated weekly, so the table disagrees with the prose until the next run. There is no cloudfront-keyvaluestore.json yet, so the data plane gets a hand-written operation table: a <FeatureCoverage> pointing at a missing file throws at runtime while still passing the build.

Verification

Every command was run against localstack-pro:dev (2026.8.0.dev313) and every title="Output" block is real output. That includes re-running the customer reproduction scripts from ENG-1092 and ENG-1093, which now pass where they previously returned InternalFailure. npm run build passes with all internal links valid.

Three things surfaced only by running it, and are documented because of it:

• The data plane needs a resolvable hostname. Its endpoint rules prepend the account ID from --kvs-arn, so an IP can never work and 000000000000.localhost resolves for some clients but not others. Terraform fails with no such host, the AWS CLI does not. Only localhost.localstack.cloud works everywhere.
• awslocal needs pip install 'botocore[crt]', because these requests are SigV4A-signed.
• CustomOriginConfig.HTTPPort is ignored unless the origin domain is a localhost domain, so a custom origin on another port is silently dialled on 80. Worth a separate bug.

Future

• That PR (ENG-1114) makes functions run on non-default cache behaviors. Need to drop the note after we merge that PR.
• There is this "TODO" string leaking in a command output. This will be addressed in a future fix.