# Configure a virtual private cloud
Amazon Virtual Private Cloud (VPC) is a fundamental building block, allowing you to provision a logically isolated virtual network within the AWS cloud. By creating your own VPC, you gain full control over the networking environment, including the ability to define IP address ranges, subnets, routing tables, and connectivity options.
Your AWS account contains a default VPC for each AWS Region. This default VPC comes pre-configured with settings that make it a convenient option for quickly launching resources. However, the default VPC may not always align with your long-term networking needs. This is where creating additional VPCs can be advantageous.
Creating additional VPCs offers several advantages over relying on the default VPC that comes provisioned with every new AWS account. With a self-managed VPC, you can architect the network topology to align precisely with your specific requirements, whether that's implementing a multi-tier application, connecting to on-premises resources, or segregating workloads by department or business unit.
In addition, creating multiple VPCs can enable greater security and isolation between your different applications or business units. Each VPC acts as a separate, virtual network, allowing you to apply distinct security policies, access controls, and routing configurations tailored to each environment.
Ultimately, the decision to use the default VPC or create one (or more) custom VPCs should be based on your specific application requirements, security needs, and long-term scalability goals. Investing the time to thoughtfully design your VPC infrastructure can pay dividends in the form of a robust, secure, and adaptable cloud networking foundation.
**Topics**
+ [VPC basics](vpc-subnet-basics.md)
+ [VPC configuration options](create-vpc-options.md)
+ [Default VPCs](default-vpc.md)
+ [Create a VPC](create-vpc.md)
+ [Visualize the resources in your VPC](view-vpc-resource-map.md)
+ [Add or remove CIDR block](add-ipv4-cidr.md)
+ [DHCP option sets](VPC_DHCP_Options.md)
+ [DNS attributes](vpc-dns.md)
+ [Network Address Usage](network-address-usage.md)
+ [Share a VPC subnet](vpc-sharing.md)
+ [Extend a VPC to other Zones](Extend_VPCs.md)
+ [Delete your VPC](delete-vpc.md)
+ [Generate IaC from console actions](vpcs-automate-c2c.md)
# VPC basics
A VPC spans all of the Availability Zones in a Region. After you create a VPC, you can add one or more subnets in each Availability Zone. For more information, see [Subnets for your VPC](configure-subnets.md).
**Topics**
+ [VPC IP address range](#vpc-ip-address-range)
+ [VPC diagram](#vpc-diagram)
+ [VPC resources](#vpc-resources)
## VPC IP address range
When you create a VPC, you specify its IP addresses as follows:
+ **IPv4 only** – The VPC has an IPv4 CIDR block but does not have an IPv6 CIDR block.
+ **Dual stack** – The VPC has both an IPv4 CIDR block and an IPv6 CIDR block.
For more information, see [IP addressing for your VPCs and subnets](vpc-ip-addressing.md).
## VPC diagram
The following diagram shows a VPC with no additional VPC resources. For example VPC configurations, see [VPC examples](vpc-examples-intro.md).
![\[A VPC that spans the Availability Zones for its Region.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/vpc-diagram.png)
## VPC resources
Each VPC automatically comes with the following resources:
+ [Default DHCP option set](DHCPOptionSetConcepts.md#ArchitectureDiagram)
+ [Default network ACL](default-network-acl.md)
+ [Default security group](default-security-group.md)
+ [Main route table](subnet-route-tables.md#main-route-table)
You can create the following resources for your VPC:
+ [Network ACLs](vpc-network-acls.md)
+ [Custom route tables](VPC_Route_Tables.md)
+ [Security groups](vpc-security-groups.md)
+ [Internet gateway](VPC_Internet_Gateway.md)
+ [NAT gateways](vpc-nat-gateway.md)
# VPC configuration options
You can specify the following configuration options when you create a VPC.
**Availability Zones**
Discrete data centers with redundant power, networking, and connectivity in an AWS Region. You can use multiple AZs to operate production applications and databases that are more highly available, fault tolerant, and scalable than would be possible from a single data center. If you partition your applications running in subnets across AZs, you are better isolated and protected from issues such as power outages, lightning strikes, tornadoes, and earthquakes.
**CIDR blocks**
You must specify IP address ranges for your VPC and subnets. For more information, see [IP addressing for your VPCs and subnets](vpc-ip-addressing.md).
**DNS options**
If you need public IPv4 DNS hostnames for the EC2 instances launched into your subnets, you must enable both of the DNS options. For more information, see [DNS attributes for your VPC](vpc-dns.md).
+ **Enable DNS hostnames**: EC2 instances launched in the VPC receive public DNS hostnames that correspond to their public IPv4 addresses.
+ **Enable DNS resolution**: DNS resolution for private DNS hostnames is provided for the VPC by the Amazon DNS server, called the Route 53 Resolver.
**Internet gateway**
Connects your VPC to the internet. The instances in a public subnet can access the internet because the subnet route table contains a route that sends traffic bound for the internet to the internet gateway. If a server doesn't need to be directly reachable from the internet, you should not deploy it into a public subnet. For more information, see [Internet gateways](VPC_Internet_Gateway.md).
**Name**
The names that you specify for the VPC and the other VPC resources are used to create Name tags. If you use the name tag auto-generation feature in the console, the tag values have the format *name*-*resource*.
**NAT gateways**
Enables instances in a private subnet to send outbound traffic to the internet, but prevents resources on the internet from connecting to the instances. In production, we recommend that you deploy a NAT gateway in each active AZ. For more information, see [NAT gateways](vpc-nat-gateway.md).
**Route tables**
Contains a set of rules, called routes, that determine where network traffic from your subnet or gateway is directed. For more information, see [Route tables](VPC_Route_Tables.md).
**Subnets**
A range of IP addresses in your VPC. You can launch AWS resources, such as EC2 instances, into your subnets. Each subnet resides entirely within one Availability Zone. By launching instances in at least two Availability Zones, you can protect your applications from the failure of a single Availability Zone.
A public subnet has a direct route to an internet gateway. Resources in a public subnet can access the public internet. A private subnet does not have a direct route to an internet gateway. Resources in a private subnet require another component, such as a NAT device, to access the public internet.
For more information, see [Subnets](configure-subnets.md).
**Tenancy**
This option defines if EC2 instances that you launch into the VPC will run on hardware that's shared with other AWS accounts or on hardware that's dedicated for your use only. If you choose the tenancy of the VPC to be `Default`, EC2 instances launched into this VPC will use the tenancy attribute specified when you launch the instance -- For more information, see [Launch an instance using defined parameters](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) in the *Amazon EC2 User Guide*. If you choose the tenancy of the VPC to be `Dedicated`, the instances will always run as [Dedicated Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) on hardware that's dedicated for your use. If you're using AWS Outposts, your Outpost requires private connectivity; you must use `Default` tenancy.
# Default VPCs
When you start using Amazon VPC, you have a default VPC in each AWS Region. A default VPC comes with a public subnet in each Availability Zone, an internet gateway, and settings to enable DNS resolution. Therefore, you can immediately start launching Amazon EC2 instances into a default VPC. You can also use services such as Elastic Load Balancing, Amazon RDS, and Amazon EMR in your default VPC.
A default VPC is suitable for getting started quickly and for launching public instances such as a blog or simple website. You can modify the components of your default VPC as needed.
You can add subnets to your default VPC. For more information, see [Create a subnet](create-subnets.md).
**Topics**
+ [Default VPC components](default-vpc-components.md)
+ [Default subnets](default-subnet.md)
+ [Work with your default VPC and default subnets](work-with-default-vpc.md)
# Default VPC components
When we create a default VPC, we do the following to set it up for you:
+ Create a VPC with a size `/16` IPv4 CIDR block (`172.31.0.0/16`). This provides up to 65,536 private IPv4 addresses.
+ Create a size `/20` default subnet in each Availability Zone. This provides up to 4,096 addresses per subnet, a few of which are reserved for our use.
+ Create an [internet gateway](VPC_Internet_Gateway.md) and connect it to your default VPC.
+ Add a route to the main route table that points all traffic (`0.0.0.0/0`) to the internet gateway.
+ Create a default security group and associate it with your default VPC.
+ Create a default network access control list (ACL) and associate it with your default VPC.
+ Associate the default DHCP options set for your AWS account with your default VPC.
**Note**
Amazon creates the above resources on your behalf. IAM policies do not apply to these actions because you do not perform these actions. For example, if you have an IAM policy that denies the ability to call CreateInternetGateway, and then you call CreateDefaultVpc, the internet gateway in the default VPC is still created. To prevent Amazon from creating an internet gateway, you would have to deny CreateDefaultVpc and CreateInternetGateway.
To block all traffic to and from the internet gateways in your account, see [Block public access to VPCs and subnets](security-vpc-bpa.md).
The following figure illustrates the key components that we set up for a default VPC.
![\[We create a default VPC in each Region, with a default subnet in each Availability Zone.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/default-vpc.png)
The following table shows the routes in the main route table for the default VPC.
| Destination | Target |
| --- | --- |
| 172.31.0.0/16 | local |
| 0.0.0.0/0 | internet\$1gateway\$1id |
You can use a default VPC as you would use any other VPC:
+ Add additional nondefault subnets.
+ Modify the main route table.
+ Add additional route tables.
+ Associate additional security groups.
+ Update the rules of the default security group.
+ Add AWS Site-to-Site VPN connections.
+ Add more IPv4 CIDR blocks.
+ Access VPCs in a remote Region by using a Direct Connect gateway. For information about Direct Connect gateway options, see [Direct Connect gateways](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html) in the *AWS Direct Connect User Guide*.
You can use a default subnet as you would use any other subnet; add custom route tables and set network ACLs. You can also specify a specific default subnet when you launch an EC2 instance.
You can optionally associate an IPv6 CIDR block with your default VPC.
# Default subnets
By default, a default subnet is a public subnet, because the main route table sends the subnet's traffic that is destined for the internet to the internet gateway. You can make a default subnet into a private subnet by removing the route from the destination 0.0.0.0/0 to the internet gateway. However, if you do this, no EC2 instance running in that subnet can access the internet.
Instances that you launch into a default subnet receive both a public IPv4 address and a private IPv4 address, and both public and private DNS hostnames. Instances that you launch into a nondefault subnet in a default VPC don't receive a public IPv4 address or a DNS hostname. You can change your subnet's default public IP addressing behavior. For more information, see [Modify the IP addressing attributes of your subnet](subnet-public-ip.md).
From time to time, AWS may add a new Availability Zone to a Region. In most cases, we automatically create a new default subnet in this Availability Zone for your default VPC within a few days. However, if you made any modifications to your default VPC, we do not add a new default subnet. If you want a default subnet for the new Availability Zone, you can create one yourself. For more information, see [Create a default subnet](work-with-default-vpc.md#create-default-subnet).
# Work with your default VPC and default subnets
This section describes how to work with default VPCs and default subnets.
**Topics**
+ [View your default VPC and default subnets](#view-default-vpc)
+ [Create a default VPC](#create-default-vpc)
+ [Create a default subnet](#create-default-subnet)
+ [Delete your default subnets and default VPC](#deleting-default-vpc)
## View your default VPC and default subnets
You can view your default VPC and subnets using the Amazon VPC console or the command line.
**To view your default VPC and subnets using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Your VPCs**.
1. In the **Default VPC** column, look for a value of **Yes**. Take note of the ID of the default VPC.
1. In the navigation pane, choose **Subnets**.
1. In the search bar, type the ID of the default VPC. The returned subnets are subnets in your default VPC.
1. To verify which subnets are default subnets, look for a value of **Yes** in the **Default Subnet **column.
**To describe your default VPC using the command line**
+ Use the [describe-vpcs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpcs.html) (AWS CLI)
+ Use the [Get-EC2Vpc](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Vpc.html) (AWS Tools for Windows PowerShell)
Use the commands with the `isDefault` filter and set the filter value to `true`.
**To describe your default subnets using the command line**
+ Use the [describe-subnets](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-subnets.html) (AWS CLI)
+ Use the [Get-EC2Subnet](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Subnet.html) (AWS Tools for Windows PowerShell)
Use the commands with the `vpc-id` filter and set the filter value to the ID of the default VPC. In the output, the `DefaultForAz` field is set to `true` for default subnets.
## Create a default VPC
If you delete your default VPC, you can create a new one. You cannot restore a previous default VPC that you deleted, and you cannot mark an existing nondefault VPC as a default VPC.
When you create a default VPC, it is created with the standard [components](default-vpc-components.md) of a default VPC, including a default subnet in each Availability Zone. You cannot specify your own components. The subnet CIDR blocks of your new default VPC may not map to the same Availability Zones as your previous default VPC. For example, if the subnet with CIDR block `172.31.0.0/20` was created in `us-east-2a` in your previous default VPC, it may be created in `us-east-2b` in your new default VPC.
If you already have a default VPC in the Region, you cannot create another one.
**To create a default VPC using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Your VPCs**.
1. Choose **Actions**, **Create Default VPC**.
1. Choose **Create**. Close the confirmation screen.
**To create a default VPC using the command line**
You can use the [create-default-vpc](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-default-vpc.html) AWS CLI command. This command does not have any input parameters.
```
aws ec2 create-default-vpc
```
The following is example output.
```
{
"Vpc": {
"VpcId": "vpc-3f139646",
"InstanceTenancy": "default",
"Tags": [],
"Ipv6CidrBlockAssociationSet": [],
"State": "pending",
"DhcpOptionsId": "dopt-61079b07",
"CidrBlock": "172.31.0.0/16",
"IsDefault": true
}
}
```
Alternatively, you can use the [New-EC2DefaultVpc](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2DefaultVpc.html) Tools for Windows PowerShell command or the [CreateDefaultVpc](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateDefaultVpc.html) Amazon EC2 API action.
## Create a default subnet
**Note**
You cannot create a default subnet using the AWS Management Console.
You can create a default subnet in an Availability Zone that does not have one. For example, you might want to create a default subnet if you have deleted a default subnet, or if AWS has added a new Availability Zone and did not automatically create a default subnet for that zone in your default VPC.
When you create a default subnet, it is created with a size `/20` IPv4 CIDR block in the next available contiguous space in your default VPC. The following rules apply:
+ You cannot specify the CIDR block yourself.
+ You cannot restore a previous default subnet that you deleted.
+ You can have only one default subnet per Availability Zone.
+ You cannot create a default subnet in a nondefault VPC.
If there is not enough address space in your default VPC to create a size `/20` CIDR block, the request fails. If you need more address space, you can [add an IPv4 CIDR block to your VPC](vpc-cidr-blocks.md#vpc-resize).
If you've associated an IPv6 CIDR block with your default VPC, the new default subnet does not automatically receive an IPv6 CIDR block. Instead, you can associate an IPv6 CIDR block with the default subnet after you create it. For more information, see [Add or remove an IPv6 CIDR block from your subnet](subnet-associate-ipv6-cidr.md).
**To create a default subnet using the AWS CLI**
Use the [create-default-subnet](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-default-subnet.html) AWS CLI command and specify the Availability Zone in which to create the subnet.
```
aws ec2 create-default-subnet --availability-zone us-east-2a
```
The following is example output.
```
{
"Subnet": {
"AvailabilityZone": "us-east-2a",
"Tags": [],
"AvailableIpAddressCount": 4091,
"DefaultForAz": true,
"Ipv6CidrBlockAssociationSet": [],
"VpcId": "vpc-1a2b3c4d",
"State": "available",
"MapPublicIpOnLaunch": true,
"SubnetId": "subnet-1122aabb",
"CidrBlock": "172.31.32.0/20",
"AssignIpv6AddressOnCreation": false
}
}
```
For more information about setting up the AWS CLI, see the [AWS Command Line Interface User Guide](https://docs.aws.amazon.com/cli/latest/userguide/).
Alternatively, you can use the [New-EC2DefaultSubnet](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2DefaultSubnet.html) Tools for Windows PowerShell command or the [CreateDefaultSubnet](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateDefaultSubnet.html) Amazon EC2 API action.
## Delete your default subnets and default VPC
You can delete a default subnet or default VPC just as you can delete any other subnet or VPC. However, if you delete your default subnets or default VPC, you must explicitly specify a subnet in one of your VPCs when you launch instances. If you do not have another VPC, you must create a VPC with a subnet in at least one Availability Zone. For more information, see [Create a VPC](create-vpc.md).
If you delete your default VPC, you can create a new one. For more information, see [Create a default VPC](#create-default-vpc).
If you delete a default subnet, you can create a new one. For more information, see [Create a default subnet](#create-default-subnet). To ensure that your new default subnet behaves as expected, modify the subnet attribute to assign public IP addresses to instances that are launched in that subnet. For more information, see [Modify the IP addressing attributes of your subnet](subnet-public-ip.md). You can only have one default subnet per Availability Zone. You cannot create a default subnet in a nondefault VPC.
# Create a VPC
Use the following procedures to create a virtual private cloud (VPC). A VPC must have additional resources, such as subnets, route tables, and gateways, before you can create AWS resources in the VPC.
**Topics**
+ [Create a VPC plus other VPC resources](#create-vpc-and-other-resources)
+ [Create a VPC only](#create-vpc-only)
+ [Create a VPC using the AWS CLI](#create-vpc-cli)
For information about modifying a VPC, see [Add or remove a CIDR block from your VPC](add-ipv4-cidr.md).
## Create a VPC plus other VPC resources
Use the following procedure to create a VPC plus the additional VPC resources that you need to run your application, such as subnets, route tables, internet gateways, and NAT gateways. For example VPC configurations, see [VPC examples](vpc-examples-intro.md).
**To create a VPC, subnets, and other VPC resources using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the VPC dashboard, choose **Create VPC**.
1. For **Resources to create**, choose **VPC and more**.
1. Keep **Name tag auto-generation** selected to create Name tags for the VPC resources or clear it to provide your own Name tags for the VPC resources.
1. For **IPv4 CIDR block**, enter an IPv4 address range for the VPC. A VPC must have an IPv4 address range.
1. (Optional) To support IPv6 traffic, choose **IPv6 CIDR block**, **Amazon-provided IPv6 CIDR block**.
1. Choose a **Tenancy** option. This option defines if EC2 instances that you launch into the VPC will run on hardware that's shared with other AWS accounts or on hardware that's dedicated for your use only. If you choose the tenancy of the VPC to be `Default`, EC2 instances launched into this VPC will use the tenancy attribute specified when you launch the instance. For more information, see [Launch an instance using defined parameters](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) in the *Amazon EC2 User Guide*. If you choose the tenancy of the VPC to be `Dedicated`, the instances will always run as [Dedicated Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) on hardware that's dedicated for your use. If you're using AWS Outposts, your Outpost requires private connectivity; you must use `Default` tenancy.
1. For **Number of Availability Zones (AZs)**, we recommend that you provision subnets in at least two Availability Zones for a production environment. To choose the AZs for your subnets, expand **Customize AZs**. Otherwise, let AWS choose them for you.
1. To configure your subnets, choose values for **Number of public subnets** and **Number of private subnets**. To choose the IP address ranges for your subnets, expand **Customize subnets CIDR blocks**. Otherwise, let AWS choose them for you.
1. (Optional) If resources in a private subnet need access to the public internet over IPv4, for **NAT gateways**, choose the number of AZs in which to create NAT gateways. In production, we recommend that you deploy a NAT gateway in each AZ with resources that need access to the public internet. Note that there is a cost associated with NAT gateways. For more information, see [Pricing for NAT gateways](nat-gateway-pricing.md).
1. (Optional) If resources in a private subnet need access to the public internet over IPv6, for **Egress only internet gateway**, choose **Yes**.
1. (Optional) If you need to access Amazon S3 directly from your VPC, choose **VPC endpoints**, **S3 Gateway**. This creates a gateway VPC endpoint for Amazon S3. For more information, see [Gateway endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) in the *AWS PrivateLink Guide*.
1. (Optional) For **DNS options**, both options for domain name resolution are enabled by default. If the default doesn't meet your needs, you can disable these options.
1. (Optional) To add a tag to your VPC, expand **Additional tags**, choose **Add new tag**, and enter a tag key and a tag value.
1. In the **Preview** pane, you can visualize the relationships between the VPC resources that you've configured. Solid lines represent relationships between resources. Dotted lines represent network traffic to NAT gateways, internet gateways, and gateway endpoints. After you create the VPC, you can visualize the resources in your VPC in this format at any time using the **Resource map** tab. For more information, see [Visualize the resources in your VPC](view-vpc-resource-map.md).
1. When you are finished configuring your VPC, choose **Create VPC**.
## Create a VPC only
Use the following procedure to create a VPC with no additional VPC resources using the Amazon VPC console.
**To create a VPC with no additional VPC resources using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the VPC dashboard, choose **Create VPC**.
1. For **Resources to create**, choose **VPC only**.
1. (Optional) For **Name tag**, enter a name for your VPC. Doing so creates a tag with a key of `Name` and the value that you specify.
1. For **IPv4 CIDR block**, do one of the following:
+ Choose **IPv4 CIDR manual input** and enter an IPv4 address range for your VPC.
+ Choose **IPAM-allocated IPv4 CIDR block**, select your Amazon VPC IP Address Manager (IPAM) IPv4 address pool and a netmask. The size of the CIDR block is limited by the allocation rules on the IPAM pool. IPAM is a VPC feature that makes it easier for you to plan, track, and monitor IP addresses for your AWS workloads. For more information, see the [Amazon VPC IPAM User Guide](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html).
If you are using IPAM to manage your IP addresses, we recommend that you choose this option. Otherwise, the CIDR block that you specify for your VPC might overlap with an IPAM CIDR allocation.
1. (Optional) To create a dual stack VPC, specify an IPv6 address range for your VPC. For **IPv6 CIDR block**, do one of the following:
+ Choose **IPAM-allocated IPv6 CIDR block** if you are using Amazon VPC IP Address Manager and you want to provision a IPv6 CIDR from an IPAM pool. If you use the IPAM-allocated IPv6 CIDR block to provision IPv6 CIDRs to VPCs, you get the benefit of contiguous IPv6 CIDRs for VPC creation. Contiguously-allocated CIDRs are CIDRs that are allocated sequentially. They enable you to simplify your security and networking rules; the IPv6 CIDRs can be aggregated in a single entry across networking and security constructs like access control lists, route tables, security groups, and firewalls.
You have two options for provisioning an IP address range to the VPC under **CIDR block**:
+ **Netmask length**: Choose this option to select a netmask length for the CIDR. Do one of the following:
+ If there is a default netmask length selected for the IPAM pool, you can choose **Default to IPAM netmask length** to use the default netmask length set for the IPAM pool by the IPAM administrator. For more information about the optional default netmask length allocation rule, see [Create a Regional IPv6 pool](https://docs.aws.amazon.com/vpc/latest/ipam/create-ipv6-reg-pool.html) in the *Amazon VPC IPAM User Guide*.
+ If there is no default netmask length selected for the IPAM pool, choose a netmask length that's more specific than the netmask length of the IPAM pool CIDR. For example, if the IPAM pool CIDR is /50, you can choose a netmask length between **/52** to **/60** for the VPC. Possible netmask lengths are between **/44** and **/60** in increments of /4.
+ **Select a CIDR**: Choose this option to manually enter an IPv6 address. You can only choose a netmask length that's more specific than the netmask length of the IPAM pool CIDR. For example, if the IPAM pool CIDR is /50, you can choose a netmask length between **/52** to **/60** for the VPC. Possible IPv6 netmask lengths are between **/44** and **/60** in increments of /4.
+ Choose **Amazon-provided IPv6 CIDR block** to request an IPv6 CIDR block from an Amazon pool of IPv6 addresses. For **Network Border Group**, select the group from which AWS advertises IP addresses. Amazon provides a fixed IPv6 CIDR block size of **/56**.
+ Choose **IPv6 CIDR owned by me** to provision an IPv6 CIDR that you have already brought to AWS. For more information about bringing your own IP address ranges to AWS, see [Bring your own IP addresses (BYOIP)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html) in the *Amazon EC2 User Guide*. You can provision an IP address range for the VPC using the following options for **CIDR block**:
+ **No preference**: Choose this option to use netmask length of **/56**.
+ **Select a CIDR**: Choose this option to manually enter an IPv6 address and choose a netmask length that's more specific than the size of BYOIP CIDR. For example, if the BYOIP pool CIDR is /50, you can choose a netmask length between **/52** to **/60** for the VPC. Possible IPv6 netmask lengths are between **/44** and **/60** in increments of /4.
1. (Optional) Choose a **Tenancy** option. This option defines if EC2 instances that you launch into the VPC will run on hardware that's shared with other AWS accounts or on hardware that's dedicated for your use only. If you choose the tenancy of the VPC to be `Default`, EC2 instances launched into this VPC will use the tenancy attribute specified when you launch the instance -- For more information, see [Launch an instance using defined parameters](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) in the *Amazon EC2 User Guide*. If you choose the tenancy of the VPC to be `Dedicated`, the instances will always run as [Dedicated Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) on hardware that's dedicated for your use. If you're using AWS Outposts, your Outpost requires private connectivity; you must use `Default` tenancy.
1. (Optional) To add a tag to your VPC, choose **Add new tag** and enter a tag key and a tag value.
1. Choose **Create VPC**.
1. After you create a VPC, you can add subnets. For more information, see [Create a subnet](create-subnets.md).
## Create a VPC using the AWS CLI
The following procedure contains example AWS CLI commands to create a VPC plus the additional VPC resources needed to run an application. If you run all of the commands in this procedure, you'll create a VPC, a public subnet, a private subnet, a route table for each subnet, an internet gateway, an egress-only internet gateway, and a public NAT gateway. If you do not need all of these resources, you can use only the example commands that you need.
**Prerequisites**
Before you begin, install and configure the AWS CLI. When you configure the AWS CLI, you are prompted for AWS credentials. The examples in this procedure assume that you also configured a default Region. Otherwise, add the `--region` option to each command. For more information, see [Installing or updating the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) and [Configuring the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html).
**Tagging**
You can add tags to a resource after you create it by using the [create-tags](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-tags.html) command. Alternatively, you can add the `--tag-specification` option to the creation command for the resource as follows.
```
--tag-specifications ResourceType=vpc,Tags=[{Key=Name,Value=my-project}]
```
**To create a VPC plus VPC resources by using the AWS CLI**
1. Use the following [create-vpc](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc.html) command to create a VPC with the specified IPv4 CIDR block.
```
aws ec2 create-vpc --cidr-block 10.0.0.0/24 --query Vpc.VpcId --output text
```
Alternatively, to create a dual stack VPC, add the `--amazon-provided-ipv6-cidr-block` option to add an Amazon-provided IPv6 CIDR block, as shown in the following example.
```
aws ec2 create-vpc --cidr-block 10.0.0.0/24 --amazon-provided-ipv6-cidr-block --query Vpc.VpcId --output text
```
These commands return the ID of the new VPC. The following is an example.
```
vpc-1a2b3c4d5e6f1a2b3
```
1. [Dual stack VPC] Get the IPv6 CIDR block that's associated with your VPC by using the following [describe-vpcs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpcs.html) command.
```
aws ec2 describe-vpcs --vpc-id vpc-1a2b3c4d5e6f1a2b3 --query Vpcs[].Ipv6CidrBlockAssociationSet[].Ipv6CidrBlock --output text
```
The following is example output.
```
2600:1f13:cfe:3600::/56
```
1. Create one or more subnets, depending on your use case. In production, we recommend that you launch resources in at least two Availability Zones. Use one of the following commands to create each subnet.
+ **IPv4-only subnet** – To create a subnet with a specific IPv4 CIDR block, use the following [create-subnet](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-subnet.html) command.
```
aws ec2 create-subnet --vpc-id vpc-1a2b3c4d5e6f1a2b3 --cidr-block 10.0.1.0/20 --availability-zone us-east-2a --query Subnet.SubnetId --output text
```
+ **Dual stack subnet** – If you created a dual stack VPC, you can use the `--ipv6-cidr-block` option to create a dual stack subnet, as shown in the following command.
```
aws ec2 create-subnet --vpc-id vpc-1a2b3c4d5e6f1a2b3 --cidr-block 10.0.1.0/20 --ipv6-cidr-block 2600:1f13:cfe:3600::/64 --availability-zone us-east-2a --query Subnet.SubnetId --output text
```
+ **IPv6-only subnet** – If you created a dual stack VPC, you can use the `--ipv6-native` option to create an IPv6-only subnet, as shown in the following command.
```
aws ec2 create-subnet --vpc-id vpc-1a2b3c4d5e6f1a2b3 --ipv6-native --ipv6-cidr-block 2600:1f13:cfe:3600::/64 --availability-zone us-east-2a --query Subnet.SubnetId --output text
```
These commands return the ID of the new subnet. The following is an example.
```
subnet-1a2b3c4d5e6f1a2b3
```
1. If you need a public subnet for your web servers, or for a NAT gateway, do the following:
1. Create an internet gateway by using the following [create-internet-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-internet-gateway.html) command. The command returns the ID of the new internet gateway.
```
aws ec2 create-internet-gateway --query InternetGateway.InternetGatewayId --output text
```
1. Attach the internet gateway to your VPC by using the following [attach-internet-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/attach-internet-gateway.html) command. Use the internet gateway ID returned from the previous step.
```
aws ec2 attach-internet-gateway --vpc-id vpc-1a2b3c4d5e6f1a2b3 --internet-gateway-id igw-id
```
1. Create a custom route table for your public subnet by using the following [create-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route-table.html) command. The command returns the ID of the new route table.
```
aws ec2 create-route-table --vpc-id vpc-1a2b3c4d5e6f1a2b3 --query RouteTable.RouteTableId --output text
```
1. Create a route in the route table that sends all IPv4 traffic to the internet gateway by using the following [create-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route.html) command. Use the ID of the route table for the public subnet.
```
aws ec2 create-route --route-table-id rtb-id-public --destination-cidr-block 0.0.0.0/0 --gateway-id igw-id
```
1. Associate the route table with the public subnet by using the following [associate-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-route-table.html) command. Use the ID of the route table for the public subnet and the ID of the public subnet.
```
aws ec2 associate-route-table --route-table-id rtb-id-public --subnet-id subnet-id-public-subnet
```
1. [IPv6] You can add an egress-only internet gateway so that instances in a private subnet can access the internet over IPv6 (for example, to get software updates), but hosts on the internet can't access your instances.
1. Create an egress-only internet gateway by using the following [create-egress-only-internet-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-egress-only-internet-gateway.html) command. The command returns the ID of the new internet gateway.
```
aws ec2 create-egress-only-internet-gateway --vpc-id vpc-1a2b3c4d5e6f1a2b3 --query EgressOnlyInternetGateway.EgressOnlyInternetGatewayId --output text
```
1. Create a custom route table for your private subnet by using the following [create-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route-table.html) command. The command returns the ID of the new route table.
```
aws ec2 create-route-table --vpc-id vpc-1a2b3c4d5e6f1a2b3 --query RouteTable.RouteTableId --output text
```
1. Create a route in the route table for the private subnet that sends all IPv6 traffic to the egress-only internet gateway by using the following [create-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route.html) command. Use the ID of the route table returned in the previous step.
```
aws ec2 create-route --route-table-id rtb-id-private --destination-cidr-block ::/0 --egress-only-internet-gateway eigw-id
```
1. Associate the route table with the private subnet by using the following [associate-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-route-table.html) command.
```
aws ec2 associate-route-table --route-table-id rtb-id-private --subnet-id subnet-id-private-subnet
```
1. If you need a NAT gateway for your resources in a private subnet, do the following:
1. Create an elastic IP address for the NAT gateway by using the following [allocate-address](https://docs.aws.amazon.com/cli/latest/reference/ec2/allocate-address.html) command.
```
aws ec2 allocate-address --domain vpc --query AllocationId --output text
```
1. Create the NAT gateway in the public subnet by using the following [create-nat-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-nat-gateway.html) command. Use the allocation ID returned from the previous step.
```
aws ec2 create-nat-gateway --subnet-id subnet-id-public-subnet --allocation-id eipalloc-id
```
1. (Optional) If you already created a route table for the private subnet in step 5, skip this step. Otherwise, use the following [create-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route-table.html) command to create a route table for your private subnet. The command returns the ID of the new route table.
```
aws ec2 create-route-table --vpc-id vpc-1a2b3c4d5e6f1a2b3 --query RouteTable.RouteTableId --output text
```
1. Create a route in the route table for the private subnet that sends all IPv4 traffic to the NAT gateway by using the following [create-route](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route.html) command. Use the ID of the route table for the private subnet, which you created either in this step or in step 5.
```
aws ec2 create-route --route-table-id rtb-id-private --destination-cidr-block 0.0.0.0/0 --gateway-id nat-id
```
1. (Optional) If you already associated a route table with the private subnet in step 5, skip this step. Otherwise, use the following [associate-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-route-table.html) command to associate the route table with the private subnet. Use the ID of the route table for the private subnet, which you created either in this step or in step 5.
```
aws ec2 associate-route-table --route-table-id rtb-id-private --subnet-id subnet-id-private-subnet
```
# Visualize the resources in your VPC
This section describes how you can see a visual representation of the resources in your VPC using the **Resource map** tab. The following resources are visible in the resource map:
+ VPC
+ Subnets
+ The Availability Zone is represented with a letter.
+ Public subnets are green.
+ Private subnets are blue.
+ Route tables
+ Internet gateways
+ Egress-only internet gateways
+ NAT gateways
+ Gateway endpoints (Amazon S3 and Amazon DynamoDB)
The resource map shows relationships between resources inside a VPC and how traffic flows from subnets to NAT gateways, internet gateway and gateway endpoints.
You can use the resource map to understand the architecture of a VPC, see how many subnets it has in it, which subnets are associated with which route tables, and which route tables have routes to NAT gateways, internet gateways, and gateway endpoints.
You can also use the resource map to spot undesirable or incorrect configurations, such as private subnets disconnected from NAT gateways or private subnets with a route directly to the internet gateway. You can choose resources within the resource map, such as route tables, and edit the configurations for those resources.
**To visualize the resources in your VPC**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **VPCs**.
1. Select the VPC.
1. Choose the **Resource map** tab to display a visualization of the resources.
1. Choose **Show details** to view details in addition to the resource IDs and zones displayed by default.
+ **VPC**: The IPv4 and IPv6 CIDR ranges assigned to the VPC.
+ **Subnets**: The IPv4 and IPv6 CIDR ranges assigned to each subnet.
+ **Route tables**: The subnet associations, and the number of routes in the route table.
+ **Network connections**: The details related to each type of connection:
+ If there are public subnets in the VPC, there is an internet gateway resource with the number of routes and the source and destination subnets for traffic using the internet gateway.
+ If there is an egress-only internet gateway, there is an egress-only internet gateway resource with the number of routes and the source and destination subnets for traffic using the egress-only internet gateway.
+ If there is a NAT gateway, there is a NAT gateway resource with the number of network interfaces and Elastic IP addresses for the NAT gateway.
+ If there is a gateway endpoint, there is a gateway endpoint resource with the name of the AWS service (Amazon S3 or Amazon DynamoDB) that you can connect to using the endpoint.
1. Hover over a resource to see the relationship between the resources. Solid lines represent relationships between resources. Dotted lines represent network traffic to network connections.
# Add or remove a CIDR block from your VPC
This section describes how to add or remove IPv4 and IPv6 CIDR blocks from a VPC.
**Important**
Your VPC can have up to five IPv4 and five IPv6 CIDR blocks by default, but this limit is adjustable. For more information, see [Amazon VPC quotas](amazon-vpc-limits.md). For information about restrictions on CIDR blocks for a VPC, see [VPC CIDR blocks](vpc-cidr-blocks.md).
If your VPC has more than one IPv4 CIDR block associated with it, you can remove an IPv4 CIDR block from the VPC. You cannot remove the primary IPv4 CIDR block. You must remove an entire CIDR block; you cannot remove a subset of a CIDR block or a merged range of CIDR blocks. You must first delete all subnets in the CIDR block.
If you no longer want IPv6 support in your VPC, but you want to continue using your VPC to create and communicate with IPv4 resources, you can remove the IPv6 CIDR block.
To remove an IPv6 CIDR block, you must first unassign any IPv6 addresses that are assigned to any instances in your subnet.
Removing an IPv6 CIDR block does not automatically delete any security group rules, network ACL rules, or route table routes that you've configured for IPv6 networking. You must manually modify or delete these rules or routes.
**To add or remove a CIDR block from a VPC using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Your VPCs**.
1. Select the VPC, and then choose **Actions**, **Edit CIDRs**.
1. To remove a CIDR, choose **Remove** next to the CIDR.
1. To add a CIDR, choose **Add new IPv4 CIDR** or **Add new IPv6 CIDR**.
1. To add a CIDR for **IPv4 CIDR block**, do one of the following:
+ Choose **IPv4 CIDR manual input** and enter an IPv4 CIDR block.
+ Choose **IPAM-allocated IPv4 CIDR** and select a CIDR from an IPv4 IPAM pool.
+ Choose **Save**.
1. To add a CIDR for **IPv6 CIDR block**, do the following:
+ Choose **IPAM-allocated IPv6 CIDR block** if you are using Amazon VPC IP Address Manager and you want to provision a IPv6 CIDR from an IPAM pool. You have two options for provisioning an IP address range to the VPC under **CIDR block**:
+ **Netmask length**: Choose this option to select a netmask length for the CIDR. Do one of the following:
+ If there is a default netmask length selected for the IPAM pool, you can choose **Default to IPAM netmask length** to use the default netmask length set for the IPAM pool by the IPAM administrator. For more information about the optional default netmask length allocation rule, see [Create a Regional IPv6 pool](https://docs.aws.amazon.com/vpc/latest/ipam/create-ipv6-reg-pool.html) in the *Amazon VPC IPAM User Guide*.
+ If there is no default netmask length selected for the IPAM pool, choose a netmask length that's more specific than the netmask length of the IPAM pool CIDR. For example, if the IPAM pool CIDR is /50, you can choose a netmask length between **/52** to **/60** for the VPC. Possible netmask lengths are between **/44** and **/60** in increments of /4.
+ **Select a CIDR**: Choose this option to manually enter an IPv6 address. You can only choose a netmask length that's more specific than the netmask length of the IPAM pool CIDR. For example, if the IPAM pool CIDR is /50, you can choose a netmask length between **/52** to **/60** for the VPC. Possible IPv6 netmask lengths are between **/44** and **/60** in increments of /4.
+ Choose **Amazon-provided IPv6 CIDR block** to request an IPv6 CIDR block from an Amazon pool of IPv6 addresses. For **Network Border Group**, select the group from which AWS advertises IP addresses. Amazon provides a fixed IPv6 CIDR block size of **/56**.
+ Choose **IPv6 CIDR owned by me** to provision an IPv6 CIDR that you have already brought to AWS. For more information, see [Bring your own IP addresses (BYOIP) to Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html) in the *Amazon EC2 User Guide*. You have two options for provisioning an IP address range to the VPC under **CIDR block**:
+ **No preference**: Choose this option to use netmask length of **/56**.
+ **Select a CIDR**: Choose this option to manually enter an IPv6 address and choose a netmask length that's more specific than the size of BYOIP CIDR. For example, if the BYOIP pool CIDR is /50, you can choose a netmask length between **/52** to **/60** for the VPC. Possible IPv6 netmask lengths are between **/44** and **/60** in increments of /4.
+ Choose **Select CIDR** when you're done.
1. Choose **Close**.
1. If you've added a CIDR block to your VPC, you can create subnets that use the new CIDR block. For more information, see [Create a subnet](create-subnets.md).
**To associate or disassociate a CIDR block from a VPC using the AWS CLI**
Use the [associate-vpc-cidr-block](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-vpc-cidr-block.html) and [disassociate-vpc-cidr-block](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-vpc-cidr-block.html) commands.
# DHCP option sets in Amazon VPC
Network devices in your VPC use Dynamic Host Configuration Protocol (DHCP). You can use DHCP option sets to control the following aspects of the network configuration in your virtual network:
+ The DNS servers, domain names, or Network Time Protocol (NTP) servers used by the devices in your VPC.
+ Whether DNS resolution is enabled in your VPC.
**Topics**
+ [What is DHCP?](#DHCPOptionSets)
+ [DHCP option set concepts](DHCPOptionSetConcepts.md)
+ [Work with DHCP option sets](DHCPOptionSet.md)
## What is DHCP?
Every device on a TCP/IP network requires an IP address to communicate over the network. In the past, IP addresses had to be assigned to each device in your network manually. Today, IP addresses are assigned dynamically by DHCP servers using the Dynamic Host Configuration Protocol (DHCP).
Applications running on EC2 instances can communicate with Amazon DHCP servers as needed to retrieve their IP address lease or other network configuration information (such as the IP address of an Amazon DNS server or the IP address of the router in your VPC).
You can specify the network configurations that are provided by Amazon DHCP servers by using DHCP option sets.
If you have a VPC configuration that requires your applications to make direct requests to the Amazon IPv6 DHCP server, note the following:
+ An EC2 instance in a dual-stack subnet can only retrieve its IPv6 address from the IPv6 DHCP server. *It cannot retrieve any additional network configurations from the IPv6 DHCP server, such as DNS server names or domain names.*
+ An EC2 instance in a IPv6-only subnet can retrieve its IPv6 address from the IPv6 DHCP server *and can retrieve additional networking configuration information, such as DNS server names and domain names.*
+ For an EC2 instance in an IPv6-only subnet, the IPv4 DHCP Server will return 169.254.169.253 as the name server if "AmazonProvidedDNS" is explicitly mentioned in the DHCP option set. If "AmazonProvidedDNS" is missing from the option set, the IPv4 DHCP Server won't return an address whether other IPv4 name servers are mentioned in the option set or not.
The Amazon DHCP servers can also provide an entire IPv4 or IPv6 prefix to a network interface in your VPC using prefix delegation (see [Assigning prefixes to Amazon EC2 network interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-prefix-eni.html) in the *Amazon EC2 User Guide*). IPv4 prefix delegation is not provided in DHCP responses. IPv4 prefixes assigned to the interface can be retrieved using IMDS (see [Instance metadata categories](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories) in the *Amazon EC2 User Guide*).
# DHCP option set concepts
A *DHCP option set* is a group of network settings used by resources in your VPC, such as EC2 instances, to communicate over your virtual network.
Each Region has a default DHCP option set. Each VPC uses the default DHCP option set for its Region unless you either create and associate a custom DHCP option set with the VPC or configure the VPC with no DHCP option set.
If your VPC has no DHCP option set configured:
+ For [EC2 instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-hypervisor-type), AWS configures `169.254.169.253` as the default domain name server.
+ For [EC2 instances built on Xen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-hypervisor-type), no domain name servers are configured and, because instances in the VPC have no access to a DNS server, they can't access the internet.
You can associate a DHCP option set with multiple VPCs, but each VPC can have only one associated DHCP option set.
If you delete a VPC, the DHCP option set that is associated with the VPC is disassociated from the VPC.
**Topics**
+ [Default DHCP option set](#ArchitectureDiagram)
+ [Custom DHCP option set](#CustomDHCPOptionSet)
## Default DHCP option set
The default DHCP option set contains the following settings:
+ **Domain name servers**: The DNS servers that your network interfaces use for domain name resolution. For a default DHCP option set, this is always `AmazonProvidedDNS`. For more information, see [Amazon DNS server](AmazonDNS-concepts.md#AmazonDNS).
+ **Domain name**: The domain name that a client should use when resolving hostnames using the Domain Name System (DNS). For more information about the domain names used for EC2 instances, see [Amazon EC2 instance hostnames](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html).
+ **IPv6 Preferred Lease Time**: How frequently a running instance with an IPv6 assigned to it goes through DHCPv6 lease renewal. The default lease time is 140 seconds. Lease renewal typically occurs when half of the lease time has elapsed.
When you use a default DHCP options set, the following settings are not used, but there are defaults for EC2 instances:
+ **NTP servers**: By default, EC2 instances use the [Amazon Time Sync Service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) to retrieve the time.
+ **NetBIOS name servers**: For EC2 instances running Windows, the NetBIOS computer name is a friendly name assigned to the instance to identify it on the network. The NetBIOS name server maintains a list of mappings between NetBIOS computer names and network addresses for networks that use NetBIOS as their naming service.
+ **NetBIOS node type**: For EC2 instances running Windows, this is the method that the instances use to resolve NetBIOS names to IP addresses.
When you use the default option set, the Amazon DHCP server uses the network settings in the default option set. When you launch instances in your VPC, they do the following, as shown in the diagram: (1) interact with the DHCP server, (2) interact with the Amazon DNS server, and (3) connect to other devices in the network through the router for your VPC. The instances can interact with the Amazon DHCP server at any time to get their IP address lease and additional network settings.
![\[Default DHCP option set\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/dhcp-default-update-new.png)
## Custom DHCP option set
You can create a custom DHCP option set with the following settings, and then associate it with a VPC:
+ **Domain name servers**: The DNS servers that your network interfaces use for domain name resolution.
+ **Domain name**: The domain name that a client uses when resolving hostnames using the Domain Name System (DNS).
+ **NTP servers**: The NTP servers that provide the time to the instances.
+ **NetBIOS name servers**: For EC2 instances running Windows, the NetBIOS computer name is a friendly name assigned to the instance to identify it on the network. A NetBIOS name server maintains a list of mappings between NetBIOS computer names and network addresses for networks that use NetBIOS as their naming service.
+ **NetBIOS node type**: For EC2 instances running Windows, the method that the instances use to resolve NetBIOS names to IP addresses.
+ **IPv6 Preferred Lease Time** (optional): A value (in seconds, minutes, hours, or years) for how frequently a running instance with an IPv6 assigned to it goes through DHCPv6 lease renewal. Acceptable values are between 140 and 4294967295 seconds (approximately 138 years). If no value is entered, the default lease time is 140 seconds. If you use long-term addressing for EC2 instances, you can increase the lease time and avoid frequent lease renewal requests. Lease renewal typically occurs when half of the lease time has elapsed.
When you use a custom option set, instances launched into your VPC do the following, as shown in the diagram: (1) use the network settings in the custom DHCP option set, (2) interact with the DNS, NTP, and NetBIOS servers specified in the custom DHCP option set, and (3) connect to other devices in the network through the router for your VPC.
![\[Custom DHCP option set\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/dhcp-custom-update-new.png)
**Related tasks**
+ [Create a DHCP option set](DHCPOptionSet.md#CreatingaDHCPOptionSet)
+ [Change the option set associated with a VPC](DHCPOptionSet.md#ChangingDHCPOptionsofaVPC)
# Work with DHCP option sets
Use the following procedures to view and work with DHCP option sets. For more information about how DHCP option sets work, see [DHCP option set concepts](DHCPOptionSetConcepts.md).
**Topics**
+ [Create a DHCP option set](#CreatingaDHCPOptionSet)
+ [Change the option set associated with a VPC](#ChangingDHCPOptionsofaVPC)
+ [Delete a DHCP option set](#DeletingaDHCPOptionSet)
## Create a DHCP option set
A custom DHCP option set enables you to customize your VPC with your own DNS server, domain name, and more. You can create as many additional DHCP option sets as you want. However, you can only associate a VPC with one DHCP option set at a time.
**Note**
After you create a DHCP option set, you can't modify it. To update the DHCP options for your VPC, you must create a new DHCP option set and then associate it with your VPC.
**To create a DHCP options set using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **DHCP option sets**.
1. Choose **Create DHCP options set**.
1. For **Tag settings**, optionally enter a name for the DHCP option set. If you enter a value, it automatically creates a Name tag for the DHCP option set.
1. For **DHCP options**, provide the configuration settings that you need.
+ **Domain name** (optional): Enter the domain name that a client should use when resolving hostnames using DNS. If you are not using AmazonProvidedDNS, your custom domain name servers must resolve the hostname as appropriate. If you use an Amazon Route 53 private hosted zone, you can use AmazonProvidedDNS. For more information, see [DNS attributes for your VPC](vpc-dns.md).
**Note**
Only use domain names that you fully control.
Some Linux operating systems accept multiple domain names separated by spaces. However, Windows and other Linux operating systems treat the value as a single domain, which results in unexpected behavior. If your DHCP option set is associated with a VPC that has instances running operating systems that treat the value as a single domain, specify only one domain name.
+ **Domain name servers** (optional): Enter the DNS servers that will be used to resolve the IP address of a host from the host's name.
You can enter either **AmazonProvidedDNS** or custom domain name servers. Using both might cause unexpected behavior. You can enter the IP addresses of up to four IPv4 domain name servers (or up to three IPv4 domain name servers and **AmazonProvidedDNS**) and four IPv6 domain name servers separated by commas. Although you can specify up to eight domain name servers, some operating systems might impose lower limits. For more information about **AmazonProvidedDNS** and the Amazon DNS server, see [Amazon DNS server](AmazonDNS-concepts.md#AmazonDNS).
**Important**
If your VPC has an internet gateway, be sure to specify your own DNS server or an Amazon DNS server (AmazonProvidedDNS) for the **Domain name servers** value. Otherwise, the instances in the VPC won't have access to DNS, which disable internet access.
+ **NTP servers** (optional): Enter the IP addresses of up to eight Network Time Protocol (NTP) servers (four IPv4 addresses and four IPv6 addresses).
NTP servers provide the time to your network. You can specify the Amazon Time Sync Service at IPv4 address `169.254.169.123` or IPv6 address `fd00:ec2::123`. Instances communicate with the Amazon Time Sync Service by default. Note that the IPv6 address is only accessible on [EC2 instances built on the Nitro System](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html).
For more information about the NTP servers option, see [RFC 2132](https://datatracker.ietf.org/doc/html/rfc2132#section-8.3). For more information about the Amazon Time Sync Service, see [Set the time for your instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) in the *Amazon EC2 User Guide*.
+ **NetBIOS name servers** (optional): Enter the IP addresses of up to four NetBIOS name servers.
For EC2 instances running a Windows OS, the NetBIOS computer name is a friendly name assigned to the instance to identify it on the network. The NetBIOS name server maintains a list of mappings between NetBIOS computer names and network addresses for networks that use NetBIOS as their naming service.
+ **NetBIOS node type** (optional): Enter **1**, **2**, **4**, or **8**. We recommend that you specify **2** (point-to-point or P-node). Broadcast and multicast are not currently supported. For more information about these node types, see section 8.7 of [RFC 2132](https://tools.ietf.org/html/rfc2132) and section 10 of [RFC1001](https://tools.ietf.org/html/rfc1001).
For EC2 instances running a Windows OS, this is the method that the instances use to resolve NetBIOS names to IP addresses. In the default options set, there is no value for NetBIOS node type.
+ **IPv6 Preferred Lease Time** (optional): A value (in seconds, minutes, hours, or years) for how frequently a running instance with an IPv6 assigned to it goes through DHCPv6 lease renewal. Acceptable values are between 140 and 2147483647 seconds (approximately 68 years). If no value is entered, the default lease time is 140 seconds. If you use long-term addressing for EC2 instances, you can increase the lease time and avoid frequent lease renewal requests. Lease renewal typically occurs when half of the lease time has elapsed.
1. Add **Tags**.
1. Choose **Create DHCP options set**. Note the name or ID of the new DHCP option set.
1. To configure a VPC to use the new option set, see [Change the option set associated with a VPC](#ChangingDHCPOptionsofaVPC).
**To create a DHCP option set for your VPC using the command line**
+ [create-dhcp-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-dhcp-options.html) (AWS CLI)
+ [New-EC2DhcpOption](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2DhcpOption.html) (AWS Tools for Windows PowerShell)
## Change the option set associated with a VPC
After you create a DHCP option set, you can associate it with one or more VPCs. You can associate only one DHCP option set with a VPC at a time. If you do not associate a DHCP option set with a VPC, this disables domain name resolution in the VPC.
When you associate a new set of DHCP options with a VPC, any existing instances and all new instances that you launch in that VPC use the new options. You don't need to restart or relaunch your instances. Instances automatically pick up the changes within a few hours, depending on how frequently they renew their DHCP leases. If you prefer, you can explicitly renew the lease using the operating system on the instance.
**To change the DHCP option set associated with a VPC using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Your VPCs**.
1. Select the check box for the VPC, and then choose **Actions**, **Edit VPC settings**.
1. For **DHCP options set**, choose a new DHCP option set. Alternatively, choose **No DHCP option set** to disable domain name resolution for the VPC.
1. Choose **Save**.
**To change the DHCP option set associated with a VPC using the command line**
+ [associate-dhcp-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-dhcp-options.html) (AWS CLI)
+ [Register-EC2DhcpOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2DhcpOption.html) (AWS Tools for Windows PowerShell)
## Delete a DHCP option set
When you no longer need a DHCP option set, use the following procedure to delete it. You can't delete a DHCP option set if it's in use. For each VPC associated with the DHCP option set to delete, you must associate a different DHCP option set with the VPC or configure the VPC to use no DHCP option set. For more information, see [Change the option set associated with a VPC](#ChangingDHCPOptionsofaVPC).
**To delete a DHCP option set using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **DHCP option sets**.
1. Select the radio button for the DHCP option set, and then choose **Actions**, **Delete DHCP option set**.
1. When prompted for confirmation, enter **delete**, and then choose **Delete DHCP option set**.
**To delete a DHCP option set using the command line**
+ [delete-dhcp-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-dhcp-options.html) (AWS CLI)
+ [Remove-EC2DhcpOption](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2DhcpOption.html) (AWS Tools for Windows PowerShell)
# DNS attributes for your VPC
Domain Name System (DNS) is a standard by which names used on the internet are resolved to their corresponding IP addresses. A DNS hostname is a name that uniquely and absolutely names a computer; it's composed of a host name and a domain name. DNS servers resolve DNS hostnames to their corresponding IP addresses.
Public IPv4 addresses enable communication over the internet, while private IPv4 addresses enable communication within the network of the instance. For more information, see [IP addressing for your VPCs and subnets](vpc-ip-addressing.md).
Amazon provides a DNS server ([the Amazon Route 53 Resolver](AmazonDNS-concepts.md#AmazonDNS)) for your VPC. To use your own DNS server instead, create a new set of DHCP options for your VPC. For more information, see [DHCP option sets in Amazon VPC](VPC_DHCP_Options.md).
**Topics**
+ [Understanding Amazon DNS](AmazonDNS-concepts.md)
+ [View DNS hostnames for your EC2 instance](vpc-dns-viewing.md)
+ [View and update DNS attributes for your VPC](vpc-dns-updating.md)
# Understanding Amazon DNS
As an AWS architect or administrator, one of the foundational networking components you'll encounter is the Amazon DNS server, also known as the Route 53 Resolver. This DNS resolver service is natively integrated into each Availability Zone within your AWS Region, providing a reliable and scalable solution for domain name resolution within your Virtual Private Cloud (VPC). In this section you'll learn about the Amazon DNS server's IP addresses, the private DNS hostnames it can resolve, and the rules that govern its usage.
**Topics**
+ [Amazon DNS server](#AmazonDNS)
+ [Rules and considerations](#amazon-dns-rules)
+ [DNS hostnames for EC2 instances](#vpc-dns-hostnames)
+ [DNS attributes for your VPC](#vpc-dns-support)
+ [DNS quotas](#vpc-dns-limits)
+ [Private hosted zones](#vpc-private-hosted-zones)
## Amazon DNS server
The Route 53 Resolver (also called "Amazon DNS server" or "AmazonProvidedDNS") is a DNS Resolver service which is built into each Availability Zone in an AWS Region. The Route 53 Resolver is located at `169.254.169.253` (IPv4), `fd00:ec2::253` (IPv6), and at the primary private IPV4 CIDR range provisioned to your VPC plus two. For example, if you have a VPC with an IPv4 CIDR of `10.0.0.0/16` and an IPv6 CIDR of `2001:db8::/32`, you can reach the Route 53 Resolver at `169.254.169.253` (IPv4), `fd00:ec2::253` (IPv6), or `10.0.0.2` (IPv4). Resources within a VPC use a [link local address](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#link-local-addresses) for DNS queries. These queries are transported to the Route 53 Resolver privately and are not visible on the network. In an IPv6-only subnet, the IPv4 link-local address (169.254.169.253) is still reachable as long as "AmazonProvidedDNS" is the name server in the DHCP option set.
When you launch an instance into a VPC, we provide the instance with a private DNS hostname. We also provide a public DNS hostname if the instance is configured with a public IPv4 address and the VPC DNS attributes are enabled.
The format of the private DNS hostname depends on how you configure the EC2 instance when you launch it. For more information on the types of private DNS hostnames, see [Amazon EC2 instance hostname types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html) in the *Amazon EC2 User Guide*.
The Amazon DNS server in your VPC is used to resolve the DNS domain names that you specify in a private hosted zone in Route 53. For more information about private hosted zones, see [Working with private hosted zones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) in the *Amazon Route 53 Developer Guide*.
## Rules and considerations
When using the Amazon DNS server, the following rules and considerations apply.
+ You cannot filter traffic to or from the Amazon DNS server using network ACLs or security groups.
+ Services that use the Hadoop framework, such as Amazon EMR, require instances to resolve their own fully qualified domain names (FQDN). In such cases, DNS resolution can fail if the `domain-name-servers` option is set to a custom value. To ensure proper DNS resolution, consider adding a conditional forwarder on your DNS server to forward queries for the domain `region-name.compute.internal` to the Amazon DNS server. For more information, see [Setting up a VPC to host clusters](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-vpc-host-job-flows.html) in the *Amazon EMR Management Guide*.
+ The Amazon Route 53 Resolver only supports recursive DNS queries.
## DNS hostnames for EC2 instances
When you launch an instance, it always receives a private IPv4 address and a private DNS hostname that corresponds to its private IPv4 address. If your instance has a public IPv4 address, the DNS attributes for its VPC determines whether it receives a public DNS hostname that corresponds to the public IPv4 address. For more information, see [DNS attributes for your VPC](#vpc-dns-support).
With the Amazon provided DNS server enabled, DNS hostnames are resolved as follows.
**Private IPv4 DNS name**
The private IPv4 DNS hostname of an instance resolves to its private IPv4 address. You can use the private IPv4 DNS hostname for communication between instances in the same VPC or in connected VPCs. For more information, see [Private IPv4 addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) in the *Amazon EC2 User Guide*.
**Public IPv4 DNS name**
The public IPv4 DNS hostname of an instance resolves to its public IPv4 address (outside the network of the instance) or its private IPv4 address (inside the network of the instance). For more information, see [Public IPv4 addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) in the *Amazon EC2 User Guide*.
To resolve public IPv4 DNS names to private IPv4 addresses over a VPC peering connection, you must enable DNS resolution for the peering connection. For more information, see [Enable DNS resolution for a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-dns.html).
**Private resource DNS name**
The RBN-based DNS name that can resolve to the A and AAAA DNS records selected for this instance. This DNS hostname is visible in the instance details for instances in dual-stack and IPv6-only subnets. For more information about RBN, see [EC2 instance hostname types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html) in the *Amazon EC2 User Guide*.
## DNS attributes for your VPC
The following VPC attributes determine the DNS support provided for your VPC. If both attributes are enabled, an instance launched into the VPC receives a public DNS hostname if it is assigned a public IPv4 address or an Elastic IP address at creation. If you enable both attributes for a VPC that didn't previously have them both enabled, instances that were already launched into that VPC receive public DNS hostnames if they have a public IPv4 address or an Elastic IP address.
To check whether these attributes are enabled for your VPC, see [View and update DNS attributes for your VPC](vpc-dns-updating.md).
| Attribute | Description |
| --- | --- |
| enableDnsHostnames | Determines whether the VPC supports assigning public DNS hostnames to instances with public IP addresses. The default for this attribute is `false` unless the VPC is a default VPC. Note the **Rules and considerations** for this attribute below. |
| enableDnsSupport | Determines whether the VPC supports DNS resolution through the Amazon provided DNS server. If this attribute is `true`, queries to the Amazon provided DNS server succeed. For more information, see [Amazon DNS server](#AmazonDNS). The default for this attribute is `true`. Note the **Rules and considerations** for this attribute below. |
**Rules and considerations**
+ If both attributes are set to `true`, the following occurs:
+ Instances with public IP addresses receive corresponding public DNS hostnames.
+ The Route 53 Resolver server can resolve Amazon-provided private DNS hostnames.
+ If at least one of the attributes is set to `false`, the following occurs:
+ Instances with public IP addresses do not receive corresponding public DNS hostnames.
+ The Route 53 Resolver cannot resolve Amazon-provided private DNS hostnames.
+ Instances receive custom private DNS hostnames if there is a custom domain name in the [DHCP options set](VPC_DHCP_Options.md). If you are not using the Route 53 Resolver server, your custom domain name servers must resolve the hostname as appropriate.
+ If you use custom DNS domain names defined in a private hosted zone in Amazon Route 53, or use private DNS with interface VPC endpoints (AWS PrivateLink), you must set both the `enableDnsHostnames` and `enableDnsSupport` attributes to `true`.
+ The Route 53 Resolver can resolve private DNS hostnames to private IPv4 addresses for all address spaces, including where the IPv4 address range of your VPC falls outside of the private IPv4 addresses ranges specified by [RFC 1918](https://tools.ietf.org/html/rfc1918). However, if you created your VPC before October 2016, the Route 53 Resolver does not resolve private DNS hostnames if your VPC's IPv4 address range falls outside of these ranges. To enable support for this, contact [Support](https://aws.amazon.com/contact-us/).
## DNS quotas
There is a 1024 packet per second (PPS) limit to services that use [link-local](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#link-local-addresses) addresses. This limit includes the aggregate of Route 53 Resolver DNS queries, [Instance Metadata Service (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html) requests, [Amazon Time Service Network Time Protocol (NTP)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html) requests, and [Windows Licensing Service (for Microsoft Windows based instances)](https://aws.amazon.com/windows/resources/licensing/) requests. This quota cannot be increased.
The number of DNS queries per second supported by Route 53 Resolver varies by the type of query, the size of the response, and the protocol in use. For more information and recommendations for a scalable DNS architecture, see the [AWS Hybrid DNS with Active Directory](https://d1.awsstatic.com/whitepapers/aws-hybrid-dns-with-active-directory.pdf) Technical Guide.
If you reach the quota, the Route 53 Resolver rejects traffic. Some of the causes for reaching the quota might be a DNS throttling issue, or instance metadata queries that use the Route 53 Resolver network interface. For information about how to solve VPC DNS throttling issues, see [How can I determine whether my DNS queries to the Amazon provided DNS server are failing due to VPC DNS throttling](https://repost.aws/knowledge-center/vpc-find-cause-of-failed-dns-queries). For information about instance metadata retrieval, see [Retrieve instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html) in the *Amazon EC2 User Guide*.
## Private hosted zones
To access the resources in your VPC using custom DNS domain names, such as `example.com`, instead of using private IPv4 addresses or AWS-provided private DNS hostnames, you can create a private hosted zone in Route 53. A private hosted zone is a container that holds information about how you want to route traffic for a domain and its subdomains within one or more VPCs without exposing your resources to the internet. You can then create Route 53 resource record sets, which determine how Route 53 responds to queries for your domain and subdomains. For example, if you want browser requests for example.com to be routed to a web server in your VPC, you'll create an A record in your private hosted zone and specify the IP address of that web server. For more information about creating a private hosted zone, see [Working with private hosted zones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) in the *Amazon Route 53 Developer Guide*.
To access resources using custom DNS domain names, you must be connected to an instance within your VPC. From your instance, you can test that your resource in your private hosted zone is accessible from its custom DNS name by using the `ping` command; for example, `ping mywebserver.example.com`. (You must ensure that your instance's security group rules allow inbound ICMP traffic for the `ping` command to work.)
Private hosted zones do not support transitive relationships outside of the VPC; for example, you cannot access your resources using their custom private DNS names from the other side of a VPN connection.
**Important**
If you use custom DNS domain names defined in a private hosted zone in Amazon Route 53, you must set both the `enableDnsHostnames` and `enableDnsSupport` attributes to `true`.
# View DNS hostnames for your EC2 instance
You can view the DNS hostnames for a running instance or a network interface using the Amazon EC2 console or the command line. Knowing these hostnames is important for connecting to your resources.
The **Public DNS (IPv4)** and **Private DNS** fields are available when the DNS options are enabled for the VPC that is associated with the instance. For more information, see [DNS attributes for your VPC](AmazonDNS-concepts.md#vpc-dns-support).
## Instance
**To view DNS hostnames for an instance using the console**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. In the navigation pane, choose **Instances**.
1. Select your instance from the list.
1. In the details pane, the **Public DNS (IPv4)** and **Private DNS** fields display the DNS hostnames, if applicable.
**To view DNS hostnames for an instance using the command line**
+ [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) (AWS CLI)
+ [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html) (AWS Tools for Windows PowerShell)
## Network interface
**To view the private DNS hostname for a network interface using the console**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. In the navigation pane, choose **Network Interfaces**.
1. Select the network interface from the list.
1. In the details pane, the **Private DNS (IPv4)** field displays the private DNS hostname.
**To view DNS hostnames for a network interface using the command line**
+ [describe-network-interfaces](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-network-interfaces.html) (AWS CLI)
+ [Get-EC2NetworkInterface](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2NetworkInterface.html) (AWS Tools for Windows PowerShell)
# View and update DNS attributes for your VPC
You can view and update the DNS support attributes for your VPC using the Amazon VPC console. These settings control whether your instances get public DNS hostnames and whether the Amazon DNS server can resolve your private DNS names. Configuring these attributes correctly is vital for ensuring seamless communication within your VPC.
**To describe and update DNS support for a VPC using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Your VPCs**.
1. Select the checkbox for the VPC.
1. Review the information in **Details**. In this example, both **DNS hostnames** and **DNS resolution** are enabled.
![\[The DNS Settings tab\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/dns-settings.png)
1. To update these settings, choose **Actions** and then choose **Edit VPC settings**. Select or clear **Enable** on the appropriate DNS attribute and choose **Save changes**.
**To describe DNS support for a VPC using the command line**
+ [describe-vpc-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpc-attribute.html) (AWS CLI)
+ [Get-EC2VpcAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2VpcAttribute.html) (AWS Tools for Windows PowerShell)
**To update DNS support for a VPC using the command line**
+ [modify-vpc-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpc-attribute.html) (AWS CLI)
+ [Edit-EC2VpcAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2VpcAttribute.html) (AWS Tools for Windows PowerShell)
# Network Address Usage for your VPC
Network Address Usage (NAU) is a metric applied to resources in your virtual network to help you plan for and monitor the size of your VPC. Each NAU unit contributes to a total that represents the size of your VPC.
It's important to understand the total number of units that make up the NAU of your VPC because the following VPC quotas limit the size of a VPC:
+ [Network Address Usage](amazon-vpc-limits.md#vpc-size-limits) – The maximum number of NAU units that a single VPC can have. Each VPC can have up to 64,000 NAU units by default. You can request a quota increase up to 256,000.
+ [Peered Network Address Usage](amazon-vpc-limits.md#vpc-size-limits) – The maximum number of NAU units for a VPC and all of its peered VPCs. If a VPC is peered with other VPCs in the same Region, the VPCs combined can have up to 128,000 NAU units by default. You can request a quota increase up to 512,000. VPCs that are peered across different Regions do not contribute to this limit.
You can use the NAU in the following ways:
+ Before you create your virtual network, calculate the NAU units to help you decide if you should spread workloads across multiple VPCs.
+ After you’ve created your VPC, use Amazon CloudWatch to monitor the NAU usage of the VPC so that it doesn't grow beyond the NAU quota limits. For more information, see [CloudWatch metrics for your VPCs](vpc-cloudwatch.md).
## How NAU is calculated
If you understand how NAU is calculated, it can help you plan for the scaling of your VPCs.
The following table explains which resources make up the NAU count in a VPC and how many NAU units each resource uses. Some AWS resources are represented as single NAU units and some resources are represented as multiple NAU units. You can use the table to learn how NAU is calculated.
| Resource | NAU units |
| --- | --- |
| Each private or public IPv4 and each IPv6 address assigned to a network interface for an EC2 instance in the VPC | 1 |
| Additional network interfaces attached to an EC2 instance | 1 |
| Prefix assigned to a network interface | 1 |
| Network Load Balancer per AZ | 6 |
| Gateway Load Balancer per AZ | 6 |
| VPC endpoint per AZ | 6 |
| Transit gateway attachment | 6 |
| Lambda function | 6 |
| NAT gateway | 6 |
| EFS mount target | 6 |
| EFA interface (EFA with an ENA device) or an EFA-only interface | 1 |
| Amazon EKS pod | 1 |
## NAU examples
The following examples show how to calculate NAU.
**Example 1 - Two VPCs connected using VPC peering**
Peered VPCs in the same Region contribute to a combined NAU quota.
+ VPC 1
+ 50 Network Load Balancers in 2 subnets in separate Availability Zones - 600 NAU units
+ 5,000 instances (each with an IPv4 address and IPv6 address) in one subnet and 5,000 instances (each with an IPv4 address and IPv6 address) in another subnet - 20,000 units
+ 100 Lambda functions - 600 NAU units
+ VPC 2
+ 50 Network Load Balancers in 2 subnets in separate Availability Zones - 600 NAU units
+ 5,000 instances (each with an IPv4 address and IPv6 address) in one subnet and 5,000 instances (each with an IPv4 address and IPv6 address) in another subnet - 20,000 units
+ 100 Lambda functions - 600 NAU units
+ Total peering NAU count: 42,400 units
+ Default peering NAU quota: 128,000 units
**Example 2 - Two VPCs connected using a transit gateway**
VPCs that are connected using a transit gateway do not contribute to a combined NAU quota as they do for peered VPCs.
+ VPC 1
+ 50 Network Load Balancers in 2 subnets in separate Availability Zones - 600 NAU units
+ 5,000 instances (each with an IPv4 address and IPv6 address) in one subnet and 5,000 instances (each with an IPv4 address and IPv6 address) in another subnet - 20,000 units
+ 100 Lambda functions - 600 NAU units
+ VPC 2
+ 50 Network Load Balancers in 2 subnets in separate Availability Zones - 600 NAU units
+ 5,000 instances (each with an IPv4 address and IPv6 address) in one subnet and 5,000 instances (each with an IPv4 address and IPv6 address) in another subnet - 20,000 units
+ 100 Lambda functions - 600 NAU units
+ Total NAU count per VPC: 21,200 units
+ Default NAU quota per VPC: 64,000 units
# Share your VPC subnets with other accounts
VPC subnet sharing allows multiple AWS accounts to create their application resources, such as Amazon EC2 instances, Amazon Relational Database Service (RDS) databases, Amazon Redshift clusters, and AWS Lambda functions, into shared, centrally-managed virtual private clouds (VPCs). In this model, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations. After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner.
You can share your VPC subnets to leverage the implicit routing within a VPC for applications that require a high degree of interconnectivity and are within the same trust boundaries. This reduces the number of VPCs that you create and manage, while using separate accounts for billing and access control. You can simplify network topologies by interconnecting shared Amazon VPC subnets using connectivity features, such as AWS PrivateLink, transit gateways, and VPC peering. For more information about the benefits of VPC subnet sharing, see [VPC sharing: A new approach to multiple accounts and VPC management](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/).
There are quotas related to VPC subnet sharing. For more information, see [VPC subnet sharing](amazon-vpc-limits.md#vpc-share-limits).
**Topics**
+ [Shared subnet prerequisites](vpc-share-prerequisites.md)
+ [Working with shared subnets](vpc-sharing-share-subnet-working-with.md)
+ [Billing and metering for owner and participants](vpc-share-billing.md)
+ [Responsibilities and permissions for owners and participants](vpc-share-limitations.md)
+ [AWS resources and shared VPC subnets](vpc-sharing-service-behavior.md)
# Shared subnet prerequisites
This section contains prerequisites for working with shared subnets:
+ The accounts for the VPC owner and participant must be managed by AWS Organizations.
+ You must enable resource sharing in the AWS RAM console from the management account for your organization. For more information, see [Enable resource sharing within AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) in the *AWS RAM User Guide*.
+ You must create a resource share. You can specify the subnets to share when you create the resource share, or add the subnets to the resource share later on using the procedure in the next section. For more information, see [Create a resource share](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-create) in the *AWS RAM User Guide*.
# Working with shared subnets
This section describes how to work with shared subnets in the AWS console and AWS CLI.
**Topics**
+ [Share a subnet](#vpc-sharing-share-subnet)
+ [Unshare a shared subnet](#vpc-sharing-stop-share-subnet)
+ [Identify the owner of a shared subnet](#vpc-sharing-view-owner)
## Share a subnet
You can share non-default subnets with other accounts within your organization as follows. In addition, you can share security groups across AWS Organizations. For more information, see [Share security groups with AWS Organizations](security-group-sharing.md).
**To share a subnet using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Subnets**.
1. Select your subnet and choose **Actions**, **Share subnet**.
1. Select your resource share and choose **Share subnet**.
**To share a subnet using the AWS CLI**
Use the [create-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html) and [associate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/associate-resource-share.html) commands.
### Map subnets across Availability Zones
To ensure that resources are distributed across the Availability Zones for a Region, we independently map Availability Zones to names for each account. For example, the Availability Zone `us-east-1a` for your AWS account might not have the same location as `us-east-1a` for another AWS account.
To coordinate Availability Zones across accounts for VPC sharing, you must use an *AZ ID*, which is a unique and consistent identifier for an Availability Zone. For example, `use1-az1` is the AZ ID for one of the Availability Zones in the `us-east-1` Region. Use AZ IDs to determine the location of resources in one account relative to another account. You can view the AZ ID for each subnet in the Amazon VPC console.
The following diagram illustrates two accounts with different mappings of Availability Zone code to AZ ID.
![\[Two accounts with different mappings of Availability Zone code to AZ ID.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/availability-zone-mapping.png)
## Unshare a shared subnet
The owner can unshare a shared subnet with participants at any time. After the owner unshares a shared subnet, the following rules apply:
+ Existing participant resources continue to run in the unshared subnet. AWS managed services (for example, Elastic Load Balancing) that have automated/managed workflows (such as auto scaling or node replacement) may require continuous access to the shared subnet for some resources.
+ Participants can no longer create new resources in the unshared subnet.
+ Participants can modify, describe, and delete their resources that are in the subnet.
+ If participants still have resources in the unshared subnet, the owner cannot delete the shared subnet or the shared-subnet VPC. The owner can only delete the subnet or shared-subnet VPC after the participants delete all the resources in the unshared subnet.
**To unshare a subnet using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Subnets**.
1. Select your subnet and choose **Actions**, **Share subnet**.
1. Choose **Actions**, **Stop sharing**.
**To unshare a subnet using the AWS CLI**
Use the [disassociate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/disassociate-resource-share.html) command.
## Identify the owner of a shared subnet
Participants can view the subnets that have been shared with them by using the Amazon VPC console, or the command line tool.
**To identify a subnet owner using the console**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Subnets**. The **Owner** column displays the subnet owner.
**To identify a subnet owner using the AWS CLI**
Use the [describe-subnets](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-subnets.html) and [describe-vpcs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-vpcs.html) commands, which include the ID of the owner in their output.
# Billing and metering for owner and participants
This section contains billing and metering details for those who own the shared subnet and for those working with the shared subnet:
+ In a shared VPC, each participant pays for their application resources including Amazon EC2 instances, Amazon Relational Database Service databases, Amazon Redshift clusters, and AWS Lambda functions. Participants also pay for data transfer charges associated with inter-Availability Zone data transfer as well as data transfer over VPC peering connections, across internet gateways, and across AWS Direct Connect gateways.
+ VPC owners pay hourly charges (where applicable), data processing and data transfer charges across NAT gateways, virtual private gateways, transit gateways, AWS PrivateLink, and VPC endpoints. In addition, public IPv4 addresses used in shared VPCs are billed to VPC owners. For more information about public IPv4 address pricing, see the **Public IPv4 Address** tab on the [Amazon VPC pricing page](https://aws.amazon.com/vpc/pricing/).
+ Data transfer within the same Availability Zone (uniquely identified using the AZ-ID) is free irrespective of account ownership of the communicating resources.
# Responsibilities and permissions for owners and participants
This section includes details about the responsibilities and permissions for those who own the shared subnet (owner) and for those who are using the shared subnet (participant).
## Owner resources
Owners are responsible for the VPC resources that they own. VPC owners are responsible for creating, managing, and deleting the resources associated with a shared VPC. These include subnets, route tables, network ACLs, peering connections, gateway endpoints, interface endpoints, Route 53 Resolver endpoints, internet gateways, NAT gateways, virtual private gateways, and transit gateway attachments.
## Participant resources
Participants are responsible for the VPC resources that they own. Participants can create a limited set of VPC resources in a shared VPC. For example, participants can create network interfaces and security groups, and enable VPC flow logs for the network interfaces that they own. The VPC resources that a participant creates count against the VPC quotas in the participant account, not the owner account. For more information, see [VPC subnet sharing](amazon-vpc-limits.md#vpc-share-limits).
## VPC resources
The following responsibilities and permissions apply to VPC resources when working with shared VPC subnets:
**Flow logs**
+ Participants can create, delete, and describe flow logs for network interfaces that they own in a shared VPC subnet.
+ Participants cannot create, delete, or describe flow logs for network interfaces that they do not own in a shared VPC subnet.
+ Participants cannot create, delete, or describe flow logs for a shared VPC subnet.
+ VPC owners can create, delete, and describe flow logs for network interfaces that they do not own in a shared VPC subnet.
+ VPC owners can create, delete, and describe flow logs for a shared VPC subnet.
+ VPC owners cannot describe or delete flow logs created by a participant.
**Internet gateways and egress-only internet gateways**
+ Participants cannot create, attach, or delete internet gateways and egress-only internet gateways in a shared VPC subnet. Participants can describe internet gateways in a shared VPC subnet. Participants cannot describe egress-only internet gateways in a shared VPC subnet.
**NAT gateways**
+ Participants cannot create, delete, or describe NAT gateways in a shared VPC subnet.
**Network access control lists (NACLs)**
+ Participants cannot create, delete, or replace NACLs in a shared VPC subnet. Participants can describe NACLs created by VPC owners in a shared VPC subnet.
**Network interfaces**
+ Participants can create network interfaces in a shared VPC subnet. Participants cannot work with network interfaces created by VPC owners in a shared VPC subnet in any other way, such as attaching, detaching, or modifying the network interfaces. Participants can modify or delete the network interfaces in a shared VPC that they created. For example, participants can associate or disassociate IP addresses with the network interfaces that they created.
+ VPC owners can describe network interfaces owned by participants in a shared VPC subnet. VPC owners cannot work with network interfaces owned by participants in any other way, such as attaching, detaching, or modifying the network interfaces owned by participants in a shared VPC subnet.
**Route tables**
+ Participants cannot work with route tables (for example, create, delete, or associate route tables) in a shared VPC subnet. Participants can describe route tables in a shared VPC subnet.
**Security groups**
+ Participants can work with (create, delete, describe, modify, or create ingress and egress rules for) security groups that they own in a shared VPC subnet. Participants can work with security groups created by VPC owners if [the VPC owner shares the security group with the participant](security-group-sharing.md).
+ Participants can create rules in the security groups that they own that reference security groups that belong to other participants or the VPC owner as follows: account-number/security-group-id
+ Participants can't launch instances using the default security group for the VPC because it belongs to the owner.
+ Participants can't launch instances using non-default security groups that are owned by the VPC owner or other participants unless the security group is [shared with them](security-group-sharing.md).
+ VPC owners can describe the security groups created by participants in a shared VPC subnet. VPC owners cannot work with security groups created by participants in any other way. For example, VPC owners can't launch instances using security groups created by participants.
**Subnets**
+ Participants cannot modify shared subnets or their related attributes. Only the VPC owner can. Participants can describe subnets in a shared VPC subnet.
+ VPC owners can share subnets only with other accounts or organizational units that are in the same organization from AWS Organizations. VPC owners can't share subnets that are in a default VPC.
**Transit gateways**
+ Only the VPC owner can attach a transit gateway to a shared VPC subnet. Participants can't.
**VPCs**
+ Participants cannot modify VPCs or their related attributes. Only the VPC owner can. Participants can describe VPCs, their attibutes, and the DHCP option sets.
+ VPC tags and tags for the resources within the shared VPC are not shared with the participants.
+ Participants can associate their own security groups with a shared VPC. This allows the participant to use the security group with Elastic network interfaces they own in the shared VPC.
# AWS resources and shared VPC subnets
The following AWS services support resources in shared VPC subnets. For more information, follow the links to the corresponding service documentation.
+ [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Shared_subnets)
+ [AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared)
+ [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-vpc.html#ec2-shared-VPC-subnets)
+ [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html)
+ Amazon ElastiCache (Redis OSS)
+ [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/mount-fs-diff-account-same-vpc.html)
+ [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/network-reqs.html#network-requirements-shared)
+ Elastic Load Balancing
+ [Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html#register-targets-shared-subnets)
+ [ Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html#prerequisites)
+ [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-targets-shared-subnets)
+ [Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-clusters-in-a-vpc.html#emr-vpc-shared-subnet)
+ [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/shared-vpc.html)
+ AWS Lambda
+ Amazon MQ running Apache MQ (not Rabbit MQ)
+ Amazon MSK
+ AWS Network Manager
+ [AWS Cloud WAN](https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-vpc-attachment.html#cloudwan-vpc-attachments-shared-subnets)
+ [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/how-network-access-analyzer-works.html#analyzer-limitations)
+ [Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/how-reachability-analyzer-works.html#considerations)
+ Amazon OpenSearch Service
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#interface-endpoint-shared-subnets)†
+ [Amazon Relational Database Service (RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Shared_subnets)
+ [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/rs-shared-subnet-vpc.html)
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html)
+ [Amazon SageMaker Unified Studio](https://docs.aws.amazon.com/sagemaker-unified-studio/latest/adminguide/create-domain-sagemaker-unified-studio-quick.html)
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/working-with-transit-gateways.html#transit-gateway-shared-subnets)
+ [AWS Verified Access](https://docs.aws.amazon.com/verified-access/latest/ug/verified-access-endpoints.html#shared-vpc)
+ Amazon VPC
+ [Peering](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html#vpc-peering-limitations)
+ [Traffic Mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-network-limitations.html)
+ [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/create-target-group.html#target-group-shared-subnets)
† You can connect to all AWS services that support PrivateLink using a VPC endpoint in a shared VPC. For a list of services that support PrivateLink, see [AWS services that integrate with AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) in the *AWS PrivateLink Guide*.
This list is intended to include all services that support launching resources in shared VPC subnets. Despite our best efforts, there might be services that support launching resources in shared VPC subnets but are not listed here. We encourage you to submit documentation feedback if you have questions.
# Extend a VPC to a Local Zone, Wavelength Zone, or Outpost
You can host VPC resources, such as subnets, in multiple locations world-wide. These locations are composed of Regions, Availability Zones, Local Zones, and Wavelength Zones. Each *Region* is a separate geographic area.
+ Availability Zones are multiple, isolated locations within each Region.
+ Local Zones allow you to place resources, such as compute and storage, in multiple locations closer to your end users.
+ AWS Outposts brings native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility.
+ Wavelength Zones allow developers to build applications that deliver ultra-low latencies to 5G devices and end users. Wavelength deploys standard AWS compute and storage services to the edge of telecommunication carriers' 5G networks.
AWS operates state-of-the-art, highly available data centers. Although rare, failures can occur that affect the availability of instances that are in the same location. If you host all of your instances in a single location that is affected by a failure, none of your instances would be available.
# Subnets in AWS Local Zones
AWS Local Zones allow you to place resources closer to your users, and seamlessly connect to the full range of services in the AWS Region, using familiar APIs and tool sets. When you create a subnet in a Local Zone, you extend the VPC to that Local Zone.
To use a Local Zone, you use the following process:
+ Opt in to the Local Zone.
+ Create a subnet in the Local Zone.
+ Launch resources in the Local Zone subnet, so that your applications are closer to your users.
The following diagram illustrates a VPC in the US West (Oregon) (`us-west-2`) Region that spans Availability Zones and a Local Zone.
![\[A VPC with Availability Zones and a Local Zone.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/region-with-lzs.png)
When you create a VPC, you can choose to assign a set of Amazon-provided public IP addresses to the VPC. You can also set a network border group for the addresses that limits the addresses to the group. When you set a network border group, the IP addresses can't move between network border groups. Local Zone network traffic will go directly to the internet or to points-of-presence (PoPs) without traversing the Local Zone's parent Region, enabling access to low-latency computing. For the complete list of Local Zones and their corresponding parent Regions, see [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) in the *AWS Local Zones User Guide*.
The following rules apply to Local Zones:
+ The Local Zone subnets follow the same routing rules as Availability Zone subnets, including route tables, security groups, and network ACLs.
+ Outbound internet traffic leaves a Local Zone from the Local Zone.
+ You must provision public IP addresses for use in a Local Zone. When you allocate addresses, you can specify the location from which the IP address is advertised. We refer to this as a network border group, and you can set this parameter to limit the addresses to this location. After you provision the IP addresses, you cannot move them between the Local Zone and the parent Region (for example, from `us-west-2-lax-1a` to `us-west-2`).
+ If the Local Zone supports IPv6, you can request IPv6 Amazon-provided IP addresses and associate them with the network border group for a new or existing VPC. For the list of Local Zones that support IPv6, see [Considerations](https://docs.aws.amazon.com/local-zones/latest/ug/how-local-zones-work.html#considerations) in the *AWS Local Zones User Guide*
+ You can't create VPC endpoints in Local Zone subnets.
For more information about working with Local Zones, see the [AWS Local Zones User Guide](https://docs.aws.amazon.com/local-zones/latest/ug/).
## Considerations for internet gateways
Take the following information into account when you use internet gateways (in the parent Region) in Local Zones:
+ You can use internet gateways in Local Zones with Elastic IP addresses or Amazon auto-assigned public IP addresses. The Elastic IP addresses that you associate must include the network border group of the Local Zone. For more information, see [Associate Elastic IP addresses with resources in your VPC](vpc-eips.md).
You cannot associate an Elastic IP address that is set for the Region.
+ Elastic IP addresses that are used in Local Zones have the same quotas as Elastic IP addresses in a Region. For more information, see [Elastic IP addresses](amazon-vpc-limits.md#vpc-limits-eips).
+ You can use internet gateways in route tables that are associated with Local Zone resources. For more information, see [Routing to an internet gateway](route-table-options.md#route-tables-internet-gateway).
## Access Local Zones using a Direct Connect gateway
Consider the scenario where you want an on-premises data center to access resources that are in a Local Zone. You use a virtual private gateway for the VPC that's associated with the Local Zone to connect to a Direct Connect gateway. The Direct Connect gateway connects to an Direct Connect location in a Region. The on-premises data center has an Direct Connect connection to the Direct Connect location.
**Note**
Traffic that is destined for a subnet in a Local Zone using Direct Connect does not travel through the parent Region of the Local Zone. Instead, traffic takes the shortest path to the Local Zone. This decreases latency and helps make your applications more responsive.
You configure the following resources for this configuration:
+ A virtual private gateway for the VPC that is associated with the Local Zone subnet. You can view the VPC for the subnet on the subnet details page in the Amazon VPC console, or use the [describe-subnets](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-subnets.html) command.
For information about creating a virtual private gateway, see [Create a target gateway](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html#vpn-create-target-gateway) in the *AWS Site-to-Site VPN User Guide*.
+ A Direct Connect connection. For the best latency performance, AWS recommends that you use the Direct Connect location closest to the Local Zone to which you'll be extending your subnet.
For information about ordering a connection, see [Cross connects](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Colocation.html#cross-connect-us-west-1) in the *Direct Connect User Guide*.
+ A Direct Connect gateway. For information about creating a Direct Connect gateway, see [Create a Direct Connect gateway](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways-intro.html#create-direct-connect-gateway) in the *Direct Connect User Guide*.
+ A virtual private gateway association to connect the VPC to the Direct Connect gateway. For information about creating a virtual private gateway association, see [Associating and disassociating virtual private gateways](https://docs.aws.amazon.com/directconnect/latest/UserGuide/virtualgateways.html#associate-vgw-with-direct-connect-gateway) in the *Direct Connect User Guide*.
+ A private virtual interface on the connection from the Direct Connect location to the on-premises data center. For information about creating a Direct Connect gateway, see [Creating a private virtual interface to the Direct Connect gateway ](https://docs.aws.amazon.com/directconnect/latest/UserGuide/virtualgateways.html#create-private-vif-for-gateway) in the *Direct Connect User Guide*.
## Connect Local Zone subnets to a transit gateway
You can't create a transit gateway attachment for a subnet in a Local Zone. The following diagram shows how to configure your network so that subnets in the Local Zone connect to a transit gateway through the parent Availability Zone. Create subnets in the Local Zones and subnets in the parent Availability Zones. Connect the subnets in the parent Availability Zones to the transit gateway, and then create a route in the route table for each VPC that routes traffic destined for the other VPC CIDR to the network interface for the transit gateway attachment.
**Note**
Traffic destined for a subnet in a Local Zone that originates from a transit gateway will first traverse the parent Region.
![\[Local Zone to transit gateway\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/lz-tgw.png)
Create the following resources for this scenario:
+ A subnet in each parent Availability Zone. For more information, see [Create a subnet](create-subnets.md).
+ A transit gateway. For more information, see [Create a transit gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#create-tgw) in *Amazon VPC Transit Gateways*.
+ A transit gateway attachment for each VPC using the parent Availability Zone. For more information, see [Create a transit gateway attachment to a VPC](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#create-vpc-attachment) in *Amazon VPC Transit Gateways*.
+ A transit gateway route table associated with the transit gateway attachment. For more information, see [Transit gateway route tables](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) in *Amazon VPC Transit Gateways*.
+ For each VPC, an entry in the subnet route tables of the Local Zone subnets that have the other VPC CIDR as the destination, and the ID of the network interface for the transit gateway attachment as the target. To find the network interface for the transit gateway attachment, search the descriptions of your network interfaces for the ID of the transit gateway attachment. For more information, see [Routing for a transit gateway](route-table-options.md#route-tables-tgw).
The following is an example route table for VPC 1.
| Destination | Target |
| --- | --- |
| *VPC 1 CIDR* | *local* |
| *VPC 2 CIDR* | *vpc1-attachment-network-interface-id* |
The following is an example route table for VPC 2.
| Destination | Target |
| --- | --- |
| *VPC 2 CIDR* | *local* |
| *VPC 1 CIDR* | vpc2-attachment-network-interface-id |
The following is an example of the transit gateway route table. The CIDR blocks for each VPC propagate to the transit gateway route table.
| CIDR | Attachment | Route type |
| --- | --- | --- |
| *VPC 1 CIDR* | *Attachment for VPC 1* | propagated |
| *VPC 2 CIDR* | *Attachment for VPC 2* | propagated |
# Subnets in AWS Wavelength
*AWS Wavelength* allows developers to build applications that deliver ultra-low latencies to mobile devices and end-users. Wavelength deploys standard AWS compute and storage services to the edge of telecommunication carriers' 5G networks. Developers can extend a virtual private cloud (VPC) to one or more Wavelength Zones, and then use AWS resources like Amazon EC2 instances to run applications that require ultra-low latency and connect to AWS services in the Region.
To use a Wavelength Zones, you must first opt in to the Zone. Next, create a subnet in the Wavelength Zone. You can create Amazon EC2 instances, Amazon EBS volumes, and Amazon VPC subnets and carrier gateways in Wavelength Zones. You can also use services that orchestrate or work with EC2, EBS, and VPC, such as Amazon EC2 Auto Scaling, Amazon EKS clusters, Amazon ECS clusters, Amazon EC2 Systems Manager, Amazon CloudWatch, AWS CloudTrail, and CloudFormation. The services in Wavelength are part of a VPC that is connected over a reliable, high bandwidth connection to an AWS Region for easy access to services including Amazon DynamoDB and Amazon RDS.
The following rules apply to Wavelength Zones:
+ A VPC extends to a Wavelength Zone when you create a subnet in the VPC and associate it with the Wavelength Zone.
+ By default, every subnet that you create in a VPC that spans a Wavelength Zone inherits the main VPC route table, including the local route.
+ When you launch an EC2 instance in a subnet in a Wavelength Zone, you assign a carrier IP address to it. The carrier gateway uses the address for traffic from the interface to the internet, or mobile devices. The carrier gateway uses NAT to translate the address, and then sends the traffic to the destination. Traffic from the telecommunication carrier network routes through the carrier gateway.
+ You can set the target of a VPC route table, or subnet route table in a Wavelength Zone to a carrier gateway, which allows inbound traffic from a carrier network in a specific location, and outbound traffic to the carrier network and internet. For more information about routing options in a Wavelength Zone, see [Routing](https://docs.aws.amazon.com/wavelength/latest/developerguide/how-wavelengths-work.html#wavelength-routing-overview) in the *AWS Wavelength Developer Guide*.
+ Subnets in Wavelength Zones have the same networking components as subnets in Availability Zones, including IPv4 addresses, DHCP option sets, and network ACLs.
+ You can't create a transit gateway attachment to a subnet in a Wavelength Zone. Instead, create the attachment through a subnet in the parent Availability Zone, and then route traffic to the desired destinations through the transit gateway. For an example, see the next section.
## Considerations for multiple Wavelength Zones
EC2 instances that are in different Wavelength Zones in the same VPC are not allowed to communicate with each other. If you need Wavelength Zone to Wavelength Zone communication, AWS recommends that you use multiple VPCs, one for each Wavelength Zone. You can use a transit gateway to connect the VPCs. This configuration enables communication between instances in the Wavelength Zones.
Wavelength Zone to Wavelength Zone traffic routes through the AWS Region. For more information, see [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/).
The following diagram shows how to configure your network so that instances in two different Wavelength Zones can communicate. You have two Wavelength Zones (Wavelength Zone A and Wavelength Zone B). You need to create the following resources to enable communication:
+ For each Wavelength Zone, a subnet in an Availability Zone that is the parent Availability Zone for the Wavelength Zone. In the example, you create subnet 1 and subnet 2. For information about creating subnets, see [Create a subnet](create-subnets.md). Use the [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) command to find the parent zone.
+ A transit gateway. The transit gateway connects the VPCs. For information about creating a transit gateway, see [Create a transit gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html#create-tgw) in the *Amazon VPC Transit Gateways Guide*.
+ For each VPC, a VPC attachment to the transit gateway in the parent Availability Zone of the Wavelength Zone. For more information, see [Transit gateway attachments to a VPC](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html) in the *Amazon VPC Transit Gateways Guide*.
+ Entries for each VPC in the transit gateway route table. For information about creating transit gateway routes, see [Transit gateway route tables](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) in the *Amazon VPC Transit Gateways Guide*.
+ For each VPC, an entry in the VPC route table that has the other VPC CIDR as the destination, and the transit gateway ID as the target. For more information, see [Routing for a transit gateway](route-table-options.md#route-tables-tgw).
In the example, the route table for VPC 1 has the following entry:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpc/latest/userguide/subnet-wavelength.html)
The route table for VPC 2 has the following entry:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpc/latest/userguide/subnet-wavelength.html)
![\[Multiple Wavelength Zones\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/mult-wavelength-zones.png)
# Subnets in AWS Outposts
AWS Outposts offers you the same AWS hardware infrastructure, services, APIs, and tools to build and run your applications on premises and in the cloud. AWS Outposts is ideal for workloads that need low latency access to on-premises applications or systems, and for workloads that need to store and process data locally. For more information about AWS Outposts, see [AWS Outposts](https://aws.amazon.com/outposts/).
A VPC spans all Availability Zones in an AWS Region. After you connect your Outpost to its parent Region, you can extend any VPC in the Region to your Outpost by creating a subnet for the Outpost in that VPC.
The following rules apply to AWS Outposts:
+ The subnets must reside in one Outpost location.
+ You create a subnet for an Outpost by specifying the Amazon Resource Name (ARN) of the Outpost when you create the subnet.
+ Outposts rack - A local gateway handles the network connectivity between your VPC and on-premises networks. For more information, see [Local gateways](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) in the *AWS Outposts User Guide for Outposts rack*.
+ Outposts servers - A local network interface handles the network connectivity between your VPC and on-premises networks. For more information, see [Local network interfaces](https://docs.aws.amazon.com/outposts/latest/server-userguide/local-network-interface.html) in the *AWS Outposts User Guide for Outposts servers*.
+ By default, every subnet that you create in a VPC, including subnets for your Outposts, is implicitly associated with the main route table for the VPC. Alternatively, you can explicitly associate a custom route table with the subnets in your VPC and have a local gateway as a next-hop target for all traffic destined for your on-premises network.
![\[A VPC with Availability Zones and an Outpost.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/region-with-outpost.png)
# Delete your VPC
When you are finished with a VPC, you can delete it.
**Requirement**
Before you can delete a VPC, you must first terminate or delete any resources that created a [requester-managed network interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requester-managed-eni.html) in the VPC. For example, you must terminate your EC2 instances and delete your load balancers, NAT gateways, transit gateway VPC attachments, and interface VPC endpoints.
**Note**
If you have created a [flow log](flow-logs.md) for the VPC you are deleting, note that flow logs for deleted VPCs are eventually automatically removed.
**Topics**
+ [Delete a VPC using the console](#delete-vpc-console)
+ [Delete a VPC using the command line](#delete-vpc-cli)
## Delete a VPC using the console
If you delete a VPC using the Amazon VPC console, we also delete the following VPC components for you:
+ DHCP options
+ Egress-only internet gateways
+ Gateway endpoints
+ Internet gateways
+ Network ACLs
+ Route tables
+ Security groups
+ Subnets
**To delete your VPC using the console**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Terminate all instances in the VPC. For more information, see [Terminate Your Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) in the *Amazon EC2 User Guide*.
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. In the navigation pane, choose **Your VPCs**.
1. Select the VPC to delete and choose **Actions**, **Delete VPC**.
1. If there are resources that you must delete or terminate before we can delete the VPC, we display them. Delete or terminate these resources and then try again. Otherwise, we display the resources that we will delete in addition to the VPC. Review the list and then proceed to the next step.
1. (Optional) If you have a Site-to-Site VPN connection, you can select the option to delete it. If you plan to use the customer gateway with another VPC, we recommend that you keep the Site-to-Site VPN connection and the gateways. Otherwise, you must configure your customer gateway device again after you create a new Site-to-Site VPN connection.
1. When prompted for confirmation, enter **delete** and then choose **Delete**.
## Delete a VPC using the command line
Before you can delete a VPC using the command line, you must terminate or delete any resources that created a requester-managed network interface in the VPC. You must also delete or detach all VPC resources that you created, such as subnets, security groups, network ACLs, route tables, internet gateways, and egress-only internet gateways. You do not need to delete the default security group, default route table, or default network ACL.
The following procedure demonstrates the commands that you use to delete common VPC resources and then to delete your VPC. You must use these commands in this order. If you created additional VPC resources, you'll also need to use their corresponding delete command before you can delete the VPC.
**To delete a VPC by using the AWS CLI**
1. Delete your security group by using the [delete-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-security-group.html) command.
```
aws ec2 delete-security-group --group-id sg-id
```
1. Delete each network ACL by using the [delete-network-acl](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-network-acl.html) command.
```
aws ec2 delete-network-acl --network-acl-id acl-id
```
1. Delete each subnet by using the [delete-subnet](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-subnet.html) command.
```
aws ec2 delete-subnet --subnet-id subnet-id
```
1. Delete each custom route table by using the [delete-route-table](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-route-table.html) command.
```
aws ec2 delete-route-table --route-table-id rtb-id
```
1. Detach your internet gateway from your VPC by using the [detach-internet-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/detach-internet-gateway.html) command.
```
aws ec2 detach-internet-gateway --internet-gateway-id igw-id --vpc-id vpc-id
```
1. Delete your internet gateway by using the [delete-internet-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-internet-gateway.html) command.
```
aws ec2 delete-internet-gateway --internet-gateway-id igw-id
```
1. [Dual stack VPC] Delete your egress-only internet gateway by using the [delete-egress-only-internet-gateway](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-egress-only-internet-gateway.html) command.
```
aws ec2 delete-egress-only-internet-gateway --egress-only-internet-gateway-id eigw-id
```
1. Delete your VPC by using the [delete-vpc](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-vpc.html) command.
```
aws ec2 delete-vpc --vpc-id vpc-id
```
# Generate infrastructure-as-code from your VPC console actions with Console-to-Code
The console provides a guided path for creating resources and testing prototypes. If you want to create the same resources at scale, you’ll need automation code. Console-to-Code is a feature of Amazon Q Developer that can help you get started with your automation code. Console-to-Code records your console actions, including default values and compatible parameters. It then uses generative AI to suggest code in your preferred infrastructure-as-code (IaC) format for the actions you want. Because the console workflow makes sure the parameter values that you specify are valid together, the code that you generate by using Console-to-Code has compatible parameter values. You can use the code as a starting point, and then customize it to make it production-ready for your specific use case.
For example, with Console-to-Code you can record yourself using the VPC console to create subnets, security groups, NACLs, a custom routing table, and an internet gateway and generate code in CloudFormation JSON format. Then, you can copy that code and customize it for use in your CloudFormation template.
Console-to-Code can currently generate infrastructure-as-code (IaC) in the following languages and formats:
+ CDK Java
+ CDK Python
+ CDK TypeScript
+ CloudFormation JSON
+ CloudFormation YAML
For more information and instructions on how to use Console-to-Code, see [Automating AWS services with Amazon Q Developer Console-to-Code](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/console-to-code.html) in the *Amazon Q Developer User Guide*.