Repository navigation
Support auto-created VPC for AWS #3861
Description
Currently, AWS backend uses the default VPC in each configured region or vpc_name/vpc_ids if specified, so users always have to configure VPCs themselves. Usually, when public_ips is unset to set to true, the default VPC works fine since default VPCs have subnets with a route to Internet Gateway, and nothing else is needed. But public_ips: False requires private subnets with a route to NAT Gateways and this has to be configured outside of dstack. As of now, public_ips: False is required to use multiple EFA interfaces, so this is a common setup.
dstack can offer managed VPCs that are created and deleted automatically by dstack with all the necessary resources such as subnets and NAT Gateways configured. For example via vpc_autocreated: true property:
type: aws
public_ips: false
vpc_autocreated: true
regions: [us-east-1, eu-north-1, us-west-2]
creds:
type: defaultOn backend init, dstack would create a VPC with public subnets for all AZs in all configured regions, Internet Gateway, and routes (standard AWS configuration). It should also create private subnets with a regional NAT gateway either unconditionally or if public_ips: false. Users should be able to clean up the resources via dstack. For example, dstack can check all regions for autocreated VPC and clean them up if they are not in regions. So regions: [] can be used to clean up the resources. No regions means default regions as it does now.
The new AWS permissions should be listed for vpc_autocreated: true mode.
Realistically, production deployments won't use vpc_autocreated: true since typically organizations pre-configure VPCs with all the necessary resources, connections, and security policies. But it could be useful for testing or quick deployments.
Activity
r4victor commentedon May 8, 2026
The main TBD is how to provide access into an auto-created VPC when
public_ips: falseso that dstack server and CLI outside the VPC can access it. Users shouldn't configure the dstack-managed VPC since it kills the whole idea and dstack can clean up the VPC. Some options that dstack can set up:aws ec2-instance-connect open-tunnelas ProxyCommand. ~$7/mo per region. "Intended specifically for management traffic use cases, not for high volume data transfers. High volume data transfers are throttled."aws ssm start-sessioncan be used as ProxyCommand for SSH. Free of charge. Breaks for custom AMIs without the agent.aws ssm start-sessionrequiressession-manager-pluginthat needs be installed in additional the the AWS CLI. SSM Session Manager port-forward / SSH-over-SSM goes through AWS's relay, and there are reports that throughput is low.If the VPCs are connected, then one access point would be sufficient as all the traffic can route through one VPC. Inter-region data transfer would add extra cost ~$0.02/GB. VPC connection options include:
r4victor commentedon May 8, 2026
Closing as #3865 allows testing EFA without custom VPCs, and production setups won't rely on dstack-managed VPCs.