[Feature]: Support VM-less AWS gateways backed by native load balancers #4443

Problem

With the AWS gateway backend, creating a dstack gateway provisions one or more gateway EC2 instances. Setting load_balancer: { type: alb } adds an AWS Application Load Balancer in front of those instances; it does not remove them. This leaves a long-running gateway compute layer to pay for and operate even when AWS can provide the ingress, TLS, health-check, and traffic-distribution primitives.

We would like an opt-in gateway mode that uses AWS-native infrastructure for the data plane without requiring a dstack-managed gateway EC2 instance, while keeping gateway and service lifecycle, routing intent, and scaling policy under dstack control-plane management.

Proposed outcome

Allow a project to create a VM-less AWS gateway backed by AWS-native load-balancing resources (for example, ALB and ACM). dstack remains responsible for the gateway resource model and desired state; AWS handles TLS termination and forwarding to healthy service targets.

The existing EC2-backed gateway mode should remain available and backward compatible.

Suggested implementation areas

• Add an explicit, opt-in gateway implementation mode/capability for a native AWS data plane. Keep the public configuration declarative; final field names and resource topology should be determined during design.
• Reconcile AWS resources from dstack desired state: ALB/listeners, ACM certificate attachment, target groups or an equivalent scalable routing mechanism, health checks, security groups, and DNS-facing hostname.
• Integrate service lifecycle with target registration: register service replicas when ready, remove/drain targets on scale-in or termination, and recover/reconcile after control-plane restarts or partial AWS API failures.
• Keep scaling decisions in dstack. Define how run/service metrics or AWS metrics feed the existing scaling policy, and make target capacity converge with the desired replica count.
• Preserve gateway-facing service behavior where supported: stable service URLs, project isolation/export, HTTPS, WebSockets, authentication, rate limiting, and health semantics. Document any capability that cannot be provided by the native mode.
• Use least-privilege AWS permissions and support private targets/subnets. Surface AWS quotas, provisioning failures, and resource ownership in events/logs.
• Decide whether ALBs and certificates are per gateway, shared across eligible gateways/projects, or configurable by policy. Account for ALB listener-rule and target-group quotas when many services/projects share a domain.

Acceptance criteria

• A gateway can be provisioned on AWS without creating a gateway EC2 instance.
• A service can be reached through a stable custom-domain endpoint with ACM-backed HTTPS and traffic reaches only healthy, active run replicas.
• Run start, scale-out, scale-in, stop, and failure events update the native data plane safely, including connection draining and cleanup/reconciliation.
• dstack remains the source of truth for service/gateway lifecycle and autoscaling decisions; no manual target registration is required.
• Existing EC2-backed gateways and their configuration continue to work unchanged.
• The supported feature set, IAM permissions, resource/quotas model, and multi-project sharing behavior are documented.

Related issues

• [Feature]: Support GCP ALB for gateways #4257 — GCP ALB support for gateways
• [Feature]: Support in-place gateway recreation to preserve ALB/IP and avoid DNS changes #3924 — Preserve ALB/IP during in-place gateway recreation
• Allow gateways from different projects to use the same compute resources #798 — Reuse gateway compute across projects (completed; this request instead removes the gateway VM requirement)