feat(core): Provision managed CloudFront API front door - #512
Draft
Simone319 wants to merge 1 commit into
Draft
Conversation
🦋 Changeset detectedLatest commit: 464222a The changes in this PR will be included in the next version bump. This PR includes changesets to release 23 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Simone319
changed the title
Simone319
force-pushed
the
zimzha/front-door-d2
branch
from
September 8, 2026 13:11
de1e4e9 to
df68b0d
Compare
Add a managed CloudFront distribution that becomes the stable public origin for the backend HTTP surface, so adding or scaling a compute never changes the browser hostname and Secure auth cookies persist. The distribution is provisioned and its URL published, but the client is not switched to it yet — an additive, no-traffic-change step that can be deployed and smoke-tested first. - Gate on a new BlocksDefaults.provisionApiFrontDoor (true in production, false in sandbox), with a matching preset field. - scheduleFrontDoor registers a synth-time CDK aspect that, when provisioning is on, builds one Distribution whose single default behavior proxies the stack's API origin (cookies + Authorization forwarded, caching off) and emits a FrontDoorUrl output. httpOriginFromApiUrl is the single place a Blocks API URL becomes a CloudFront origin. - Scope the distribution and its output under the owning BlocksStack/ BlocksBackend so several front-door-enabled backends can share one stack without colliding on a logical id. Non-breaking: nothing routes through the distribution yet.
Simone319
force-pushed
the
zimzha/front-door-d2
branch
from
September 9, 2026 09:46
f5e5c4a to
464222a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Provisions a managed CloudFront API front door: a single CloudFront distribution that becomes the stable public origin for the backend's HTTP surface. Today a browser talks directly to the API Gateway, whose hostname changes whenever the backend's compute topology changes; routing all backend traffic through one long-lived distribution keeps the public hostname fixed, which is what lets
Secureauth cookies survive adding, scaling, or swapping a compute.In this PR the distribution is provisioned and its URL published, but nothing routes through it yet — the client still calls the API Gateway directly. That makes this an additive, no-traffic-change step that can be deployed and smoke-tested before the client is switched over in the follow-up.
BlocksDefaults.provisionApiFrontDoor(boolean) gates the feature:truein theproductionpreset,falseinsandbox. A sandbox's dev server is same-originlocalhostand a deployed sandbox is disposable, so a stable origin buys nothing there and isn't worth the CloudFront propagation time. Apps that spread aBlocksPresetspreset need no change; a hand-writtenBlocksDefaultsliteral must add the field.scheduleFrontDoor(in@aws-blocks/core/cdk) registers a one-shot CDK aspect fromcreate(), so the decision is deferred to synth (when the whole app exists). When provisioning is on, the aspect builds onecloudfront.Distributionwhose single default behavior proxies the stack's API origin — forwarding cookies +Authorizationand disabling caching (the backend is dynamic and auth-bearing) — and emits aFrontDoorUrloutput. When off (sandbox / opt-out) it does nothing.httpOriginFromApiUrl, the single place the framework turns a Blocks API URL into a CloudFront origin (a follow-up reuses it for Hosting).BlocksStack/BlocksBackend, so several front-door-enabled backends can share one stack without colliding on a logical id.Testing
Synth unit tests (
bb-lambda-compute/src/front-door.cdk.test.ts):FrontDoorUrloutput, and the client-facingApiUrloutput still points at the API Gateway (nothing routes through the distribution yet); sandbox → none; an explicitprovisionApiFrontDoor: falseopts a production app out.httpOriginFromApiUrlbuilds a CloudFront origin from a Blocks API URL.Build, lint, and affected unit tests pass on Node 22. There is no end-to-end coverage here because nothing routes through the distribution yet — the client switch and its e2e land in the follow-up PR.
Non-breaking: purely additive; single-compute apps keep reaching the API Gateway directly.