[Lambda Web Functions] Mutable region set on an endpoint, plus per-region health-based routing

This is a feature request in a roadmap tracker, not a code change: the payload names no files, tests or entry points in the repository. Read the two comments and the 👍 vote count to see whether the request is already prioritised, then read the AWS CLI reference for aws lambda-web update-web-function-endpoint to confirm which flags exist. There is no patch to make here, so a newcomer's useful contribution is a concrete use case or a clarified scope, and done means the request is narrowed to one testable capability.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
Two related capabilities for Lambda Web Functions MultiRegion endpoints:

1. The ability to change which regions are active on an existing endpoint — add or remove a region — via the CLI (aws lambda-web update-web-function-endpoint) and the Console, without recreating the endpoint and without changing its hostname.
2. Optionally, the ability to attach a health check to each region so routing can fail traffic away from an unhealthy region.

Which service(s) is this request for?
AWS Lambda — Web Functions (aws lambda-web).

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Today an endpoint's region set and its type (HomeRegion vs MultiRegion) are immutable at creation. aws lambda-web update-web-function-endpoint exposes only --description, --auth-type, --auto-deployment-mode, --revision-weights, --scaling-config, and --throttle-config — there is no way to add or remove a region. Passing --regions against an existing endpoint errors with "settings can't be changed for endpoint <name>". The only path to a different region set is to create a brand-new endpoint, which mints a new *.lambda-web.global.on.aws hostname.

That hostname change is the expensive part, and it is made worse by the same TLS limitation that Lambda Function URLs have: the endpoint terminates TLS with an AWS-managed certificate for its own *.on.aws name, so you cannot point a custom-domain CNAME directly at the endpoint — the SNI/certificate won't match your domain. In practice every production deployment must front the endpoint with CloudFront (or another proxy) to terminate TLS for the real domain and originate to the *.on.aws hostname. So "just repoint DNS" is not available: changing the region set means editing the CloudFront origin domain, which is a distribution change (add the new origin, repoint cache behaviors, wait for the distribution to deploy, then remove the old origin), not a DNS swap. A routine operational change — expanding to or contracting from a region — becomes a disruptive, multi-step migration touching the distribution that serves live traffic.

Separately, MultiRegion endpoints route by latency but do not perform health-based failover. A broken revision or an unhealthy regional dependency in the lowest-latency region keeps receiving production traffic, because membership and routing carry no health signal. This means a MultiRegion endpoint is not a substitute for an operator-controlled failover design (Route 53 / Application Recovery Controller + per-region endpoints), and teams that want resilience are pushed back to building their own control plane in front of PerRegion endpoints.

The combined impact: adopting Web Functions for multi-region workloads currently means either accepting a disruptive endpoint-recreation-plus-CloudFront-origin-migration to adjust regions, or forgoing the native MultiRegion endpoint entirely and layering CloudFront/Route 53 on top of PerRegion endpoints to get both mutable regions and health-based failover.

Are you currently working around this issue?

• To change regions: creating a new endpoint with the desired region set, pinning the revision with --revision-weights, then adding the new *.on.aws hostname as a CloudFront origin, repointing cache behaviors, waiting for the distribution to deploy, and finally deleting the old endpoint. (A direct custom-domain CNAME to the endpoint is not possible because of AWS-managed TLS termination on the *.on.aws name, same as Function URLs.)
• For health-based failover: using PerRegion endpoints behind customer-managed Route 53 / CloudFront instead of a native MultiRegion endpoint.

Additional context
Ideal end state:

• update-web-function-endpoint (and the Console) accept region add/remove on an existing MultiRegion endpoint, keeping the endpoint ARN and hostname stable so no CloudFront origin change is required.
• An optional per-region health check (HTTP path or similar) whose status influences routing, so an unhealthy region is drained automatically — closing the gap with Route 53 / ARC-style failover.
• (Nice-to-have, and the root of the migration pain) native custom-domain support on a Web Functions endpoint — ACM cert + custom domain name — so a custom CNAME can resolve directly to the endpoint without a mandatory CloudFront layer, as has long been requested for Function URLs.

Attachments
N/A