Axum reference infrastructure #1578

Summary

Reference infrastructure: DynamoDB, a readiness signal that reports degraded identity without failing the load balancer health check, JSON logs, two or more tasks, IPv6 CloudFront ranges, geo on, CloudFront's JA4 header forwarded, and an example rate-based rule at the load balancer.

Part of #1558, server-side identity on every adapter. Plan ID A7, planned in wave 8 (MVP: Fastly and Axum); priority P1, size L. Design: spec; order and dependencies: plan.

Requirements

AX-3 Trusted IP and geo

The client IP comes only from trusted CloudFront and load balancer hops, IPv4 and IPv6. Country and US region come from CloudFront headers only from a trusted hop. The reference deployment enables geo, because an unknown country fails closed and issues no EC.

AX-6 Reference infrastructure

The reference stack wires the DynamoDB table, port 443 egress for vendor APIs, a readiness signal, JSON logs, two or more tasks and an example rate-based rule at the load balancer, since Axum's own limits are off by default (DEC-11). A store outage only degrades identity (Failure handling), so the load balancer health check stays green while identity reports itself degraded. IABTechLab/edgezero#275 serves Axum on a current-thread runtime, so capacity comes from task count.

ID-6 Rate limiting (after the MVP, DEC-15)

In the MVP, Fastly keeps main's limits on batch sync and pull sync and #1487's per-provider lookup limit, and Axum has none because the deployer's load balancer limits traffic (DEC-11). Until EZI-5, Fastly's limiter stays the existing fastly::erl bridge in the Fastly adapter, and T21 keeps it when it moves the handlers into core. After the MVP, provider lookups, batch sync, pull sync and record creation are rate limited on every supported adapter except Axum, where every limit stays off by default; batch sync is keyed per partner and the other keys follow DEC-15, and an Axum limit turned on in configuration runs per task, divided by the configured task count.

ID-7 Abuse resistance

Where a trusted JA4 is available, record creation is refused when the JA4's TLS client family contradicts the User-Agent's browser family; a JA4 the rule does not recognize, or no trusted JA4 at all, does not block (DEC-18). The family rule and its data live in core with T12, which owns keeping them current; JA4 comes only from EdgeZero's ctx.ja4() (EZI-3).

Current state

What the code does today, from the design's survey at the revisions it names:

• AX-3: feat(axum): add safe diagnostics and trusted proxy metadata edgezero#409, Add pluggable native Geo providers and protected CloudFront ingress edgezero#439 and Extract the protected CloudFront Geo baseline #1532 accept IPv6; the reference Terraform in Unify the AWS example with CloudFront and durable Edge Cookie storage #1540 trusts IPv4 ranges only. At db1ba337a its example inputs turn on a CloudFront front door with geo, which reaches the application through TS_NATIVE_GEO_PROFILE_TOML rather than EdgeZero's geo binding (EZI-4a).
• AX-6: Unify the AWS example with CloudFront and durable Edge Cookie storage #1540 at db1ba337a has the 443 egress (IPv4 only), a /health check, one task, a CloudFront front door for geo that its example inputs select, and a DynamoDB table whose IAM policy allows one partition key and one allocator item (AX-4); EdgeZero's readiness probe does not poll dependencies.
• ID-6: Fastly Edge Rate Limiting is the only limiter; record creation is limited nowhere; Collect server-side identity provider EIDs in a single page-load write #1487 keys lookups on the IP-derived EC prefix, so everyone behind one IPv4 address or IPv6 /64 shares a budget.
• ID-7: Fastly checks only that a JA4 exists plus a browser User-Agent platform; main's known-browser table (ec/device.rs) feeds analytics only and needs an HTTP/2 fingerprint that Axum behind CloudFront lacks; the RC's Axum checks only the User-Agent, with request filters, because it has no trusted JA4 (EZI-3); Cloudflare and Spin create no records yet. CloudFront sends JA4 to the origin only in the CloudFront-Viewer-JA4-Fingerprint header, which an origin request policy must forward. Add JA4 request interface design spec edgezero#469's draft design reports Axum as NotExposed and leaves the trusted proxy header to its section 13.1.

Acceptance criteria

• AX-3: An untrusted peer with forged forwarded and geo headers gets its own IP and no geo
• AX-3: A trusted IPv6 CloudFront hop is accepted
• AX-3: The reference deployment applies with geo on
• AX-6: The stack applies with those properties, the rate rule refuses traffic over its threshold, and with DynamoDB unreachable pages keep serving while identity reports degraded
• ID-6: In the MVP, Fastly's existing limits still refuse or skip over-limit requests after T21 and Axum's default configuration applies no limit
• ID-6: After the MVP, per-adapter tests hit each limit, and an Axum limit turned on for two tasks refuses at half the limit
• ID-7: On each supported adapter a scripted client with a browser User-Agent and a non-browser JA4 creates no record, a current Chrome, Safari and Firefox JA4 that no list names still creates one, and a request with no trusted JA4 is not refused for lacking one

Dependencies

Blocked by:

• Serve Axum in production mode from main #1573 Serve Axum in production mode from main (new in this plan)
• Identity on Axum through T21's shared app #1574 Identity on Axum through T21's shared app (new in this plan)
• Build the production image from source (#1539, #1538) #1577 Build the production image from source (Separate the source-built native image #1539, Separate the native AWS runtime wrapper #1538) (new in this plan)
• Extract the protected CloudFront native Geo integration #1529 Extract the protected CloudFront native Geo integration

Blocks:

• Load-test the record store at the target page-load rate with provider refreshes #1576 Load-test the record store at the target page-load rate with provider refreshes (new in this plan)

Related pull requests

• Unify the AWS example with CloudFront and durable Edge Cookie storage #1540 Unify the AWS example with CloudFront and durable Edge Cookie storage: carries part of this work.

  Fixes the plan asks of Unify the AWS example with CloudFront and durable Edge Cookie storage #1540

  When this unit is ported to main: trust IPv6 CloudFront ranges, keep the geo its example inputs select but bind it through EdgeZero's manifest (EZI-4a) instead of TS_NATIVE_GEO_PROFILE_TOML, key the DynamoDB table by partition instead of the one partition key and one allocator item its IAM policy allows (AX-4), and add an example rate-based rule at the load balancer (AX-3, AX-6, DEC-11). All units: replace TS_* names (AX-2).