alb

aws.alb (Application Load Balancer)

infra-plugin wiring: add a loadbalancer edge from this ALB to each backend service. The engine emits a dedicated target group + a path-based listener rule per edge, and the listener 404s unmatched paths. Give each edge a path (more specific first, catch-all /* last); a lone service can omit it. listenerPort is the only config.

The only entry-point/load-balancer node in the catalog — there is no API Gateway type, so public traffic enters here and gateway-style concerns get pushed into the services. Config knobs: listenerPort (443), targetPort (3000), sslPolicy, scheme, healthCheckPath (default /health).

What the ALB does

• L7 routing: one listener on listenerPort (443) fans out by path (/users/* → user service) or host header to multiple aws.ecs.service target groups. One ALB can front several services.
• TLS termination at the listener per sslPolicy; forwards plain HTTP to targets on targetPort (3000). Services never handle certs.
• scheme: internet-facing for public traffic; internal for VPC-only (service-to-service tiers).
• Health checks: targets must return 2xx on healthCheckPath (default /health). Keep it cheap — no DB or downstream calls — since it's hit every few seconds. Failing targets are auto-removed from rotation and re-added when healthy.
• WebSocket upgrade is supported natively; no extra config needed (protocol choice tradeoffs: networking-essentials.md).

When not to use

• Not needed when a single aws.apprunner.service is the whole backend — App Runner does its own load balancing and TLS. Adding an ALB there is pure cost.
• Cost: ~$16–$40/mo fixed + LCU charges based on traffic.
• Edge kind: network internet → alb → service; pair with assignPublicIp: false on ECS so the ALB is the only public entry.

Standing in for an API gateway

A gateway's actual jobs are routing, auth offload, rate limiting, request validation/transformation, response caching, and usage plans/API keys. Where each lands in this catalog:

• Routing → the ALB itself, via path/host rules. This is the gateway's core job and the ALB covers it fully.
• JWT verification, per-user rate limiting (token bucket), and input validation → middleware in each service. The design agent should copy this into each service's agentNotes; implementation specifics live in api-design.md.
• Response caching (shared, non-user-specific responses only) → aws.elasticache.redis, and only if traffic justifies a cache node.
• Usage plans / developer API keys / request transformation → application logic if light; if a design genuinely needs metered third-party API products, that's beyond the current catalog — say so rather than faking it.
• Discipline: the entry point is rarely the interesting part of a design. "ALB handles routing; auth and rate limiting live in service middleware" is a complete answer for small designs — don't pile gateway features onto it speculatively.