The redirect map is now stored in a CloudFront KeyValueStore (packages/cdk/src/system.ts — redirectKvs) populated via ImportSource.fromInline(buildKvsImportData(redirects)).
ImportSource is a one-shot import that runs only at KVS creation. Subsequent stack updates that change packages/cdk/redirects.json will:
- Update the asset in S3 (CDK regenerates the import file when input changes), and
- Show no diff on the live KVS data — keys/values stay frozen at the values from the initial import.
This is fine right now: the historical Tumblr map (251 entries) is frozen. But if we ever want to add new redirects (e.g. URL changes after a site rename, future blog moves, etc.) without tearing down and recreating the KVS we need a live update path.
Options
- Custom resource calling
cloudfront-keyvaluestore.UpdateKeys — AwsCustomResource with the operation, scoped to put/delete diffs computed at synth time. The API supports up to 50 keys per request, so 251 entries = 6 calls. Idempotent if we always send the full desired state.
- Replace KVS on data-hash change — set
keyValueStoreName to embed a hash of the data. CDK creates a new KVS, swaps the function association, deletes the old one. Heavier (function update on every redirect change) but no custom resource.
- Out-of-band script — a
redirects:sync npm script that diffs redirects.json against the live KVS and runs aws cloudfront-keyvaluestore put-key / delete-key. Simple, but separates infra and data.
My instinct is option 1: keeps everything declarative in CDK, no manual sync step.
Filed as a follow-up; not blocking launch.
The redirect map is now stored in a CloudFront KeyValueStore (
packages/cdk/src/system.ts—redirectKvs) populated viaImportSource.fromInline(buildKvsImportData(redirects)).ImportSourceis a one-shot import that runs only at KVS creation. Subsequent stack updates that changepackages/cdk/redirects.jsonwill:This is fine right now: the historical Tumblr map (251 entries) is frozen. But if we ever want to add new redirects (e.g. URL changes after a site rename, future blog moves, etc.) without tearing down and recreating the KVS we need a live update path.
Options
cloudfront-keyvaluestore.UpdateKeys—AwsCustomResourcewith the operation, scoped to put/delete diffs computed at synth time. The API supports up to 50 keys per request, so 251 entries = 6 calls. Idempotent if we always send the full desired state.keyValueStoreNameto embed a hash of the data. CDK creates a new KVS, swaps the function association, deletes the old one. Heavier (function update on every redirect change) but no custom resource.redirects:syncnpm script that diffsredirects.jsonagainst the live KVS and runsaws cloudfront-keyvaluestore put-key/delete-key. Simple, but separates infra and data.My instinct is option 1: keeps everything declarative in CDK, no manual sync step.
Filed as a follow-up; not blocking launch.