fix(infra): JARL1183 — reach the SSR instance directly, dropping the load balancer by randomdevpete · Pull Request #115 · randomdevpete/jarl

randomdevpete · 2026-08-30T11:18:19Z

Waiting on decision:

Land as-is, leaving the origin-address gap below unmitigated — or say which mitigation you want
first: pin the AMI, or always deploy JarlSsr and JarlStaticSite together.

CloudFront now reaches the SSR instance directly as a VPC origin. The internal load balancer, its
listener, its target group and its security group are gone; it balanced one target and terminated
nothing.

Also a bugfix. The instance's ingress admitted the VPC CIDR, and a CIDR rule never matches here —
the origin sees a CloudFront address, not the private one on the interface. /ssr/ answers 504 on the
live site today, and the last threemaster deploys failed on that check, going back to
2026-08-19. The rule now names CloudFront-VPCOrigins-Service-SG, resolved at deploy time by a custom
resource that fails naming the group when an account has none. cdk synth still needs no credentials.

The cost, and it bites at exactly one instance. The origin is the instance's private DNS name, and
the AMI is re-resolved on every deploy, so an instance replacement changes it and /ssr/* points at an
instance that has gone until JarlStaticSite deploys too. cdk deploy --all does both in order and
closes the gap; deploying JarlSsr alone does not. Health-check draining and round-robin need more
than one instance to matter — this does not. Nothing here mitigates it.

CI now typechecks and synthesizes infra/. Nothing did before: infra/ is outside the root
workspaces and the root tsconfig.json, and the lookup handler is a template literal that tsc,
oxlint and oxfmt cannot read — so a typo in it would first have run during a production deploy.
The step is credential-free, which is also the property being checked. The wider gap (no infra tests,
no cdk diff on a PR) is a separate piece of work, not this one.

Design, the security-group reasoning, the fresh-account ROLLBACK_FAILED hazard and the
UPDATE_ROLLBACK_FAILED one the re-runnable lookup buys are all in infra/README.md.

Not verifiable without deploying: that the ingress rule admits CloudFront, and the brief window
inside cdk deploy --all where /ssr/* still names the load balancer that has gone.

Checks:tsc --noEmit and cdk synth in infra/ (the latter under env -i with an empty HOME,
so no credentials at all), oxfmt --check, oxlint. Nothing was deployed. No style exceptions.

…load balancer The distribution's VPC origin now points at the EC2 instance on port 3000 instead of at an internal Application Load Balancer that balanced across a single target and terminated nothing. The load balancer, its listener, its target group and its security group go with it. The instance's ingress moves from the load balancer's security group to the one CloudFront creates and attaches to its own VPC origin network interfaces. The source has to be a security group rather than an address range: the instance holds a public IPv4 address for its outbound access, so a rule written against CloudFront's origin-facing prefix list would admit that address from the internet as well, and one written against the VPC CIDR matches nothing, because the origin sees a CloudFront address rather than the interface's private one. That group's id is not an attribute of the VPC origin, so it is resolved by name at deploy time, by a custom resource that fails naming the group when an account has none, and leaves synth free of credentials. Nothing health-checks the instance now that the target group has gone, so the origin's connection timeout drops to 2 seconds: an unreachable instance costs a viewer three attempts and a 504 in 6 seconds rather than the default 30. The origin's address is the instance's private DNS name, and the AMI is re-resolved on every deploy, so an instance replacement changes it and leaves /ssr/* pointing at an instance that has gone until JarlStaticSite deploys too. A load balancer's DNS name did not move. Nothing here mitigates that; infra/README.md says so. CI typechecks and synthesizes infra/ from here on. Nothing did before — infra/ sits outside the root workspaces and the root tsconfig — and the lookup handler is a template literal that tsc, oxlint and oxfmt cannot read, so a typo in it would first have run during a production deploy. Ticket: 1183

randomdevpete · 2026-08-30T11:18:19Z

Waiting on decision:

Land as-is, leaving the origin-address gap below unmitigated — or say which mitigation you want
first: pin the AMI, or always deploy JarlSsr and JarlStaticSite together.