# Amazon VPC and Amazon DocumentDB Amazon Virtual Private Cloud (Amazon VPC) makes it possible for you to launch AWS resources, such as Amazon DocumentDB instances, into a virtual private cloud (VPC). When you use a VPC, you have control over your virtual networking environment. You can choose your own IP address range, create subnets, and configure routing and access control lists. There is no additional cost to run your cluster in a VPC. Accounts have a default VPC. All new clusters are created in the default VPC unless you specify otherwise. **Topics** + [DocumentDB clusters in a VPC](vpc-clusters.md) + [Accessing an Amazon DocumentDB cluster in a VPC](access-cluster-vpc.md) + [Create an IPv4-only VPC for use with a DocumentDB cluster](docdb-vpc-create-ipv4.md) + [Create a dual-stack VPC for use with a DocumentDB cluster](docdb-vpc-create-dual-stack.md) Following, you can find a discussion about VPC functionality relevant to Amazon DocumentDB clusters. For more information about Amazon VPC, see the [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). # DocumentDB clusters in a VPC Your Amazon DocumentDB cluster is in a virtual private cloud (VPC). A VPC is a virtual network that is logically isolated from other virtual networks in the AWS Cloud. Amazon VPC makes it possible for you to launch AWS resources, such as an Amazon DocumentDB cluster or Amazon EC2 instance, into a VPC. The VPC can either be a default VPC that comes with your account or one that you create. All VPCs are associated with your AWS account. Your default VPC has three subnets that you can use to isolate resources inside the VPC. The default VPC also has an internet gateway that can be used to provide access to resources inside the VPC from outside the VPC. For scenarios involving Amazon DocumentDB clusters in a VPC and outside of a VPC, see [Accessing an Amazon DocumentDB cluster in a VPC](access-cluster-vpc.md). **Topics** + [Working with clusters in a VPC](#vpc-working-clusters) + [Working with subnet groups](#vpc-working-subnet-groups) + [Amazon DocumentDB IP addressing](#vpc-docdb-ip-addressing) + [Creating a cluster in a VPC](#vpc-creating-cluster) ## Working with clusters in a VPC Here are some tips on working with a cluster in a VPC: + Your VPC must have at least two subnets. These subnets must be in two different Availability Zones in the AWS Region where you want to deploy your cluster. A subnet is a segment of a VPC's IP address range that you can specify and that you can use to group clusters based on your security and operational needs. + If you want your cluster in the VPC to be publicly accessible, make sure to turn on the VPC attributes `DNS hostnames` and `DNS resolution`. + Your VPC must have a subnet group that you create. You create a subnet group by specifying the subnets you created. Amazon DocumentDB chooses a subnet and an IP address within that subnet group to associate with the primary instance in your cluster. The primary instance uses the Availability Zone that contains the subnet. + Your VPC must have a VPC security group that allows access to the cluster. For more information, see [Accessing an Amazon DocumentDB cluster in a VPC](access-cluster-vpc.md). + The CIDR blocks in each of your subnets must be large enough to accommodate spare IP addresses for Amazon DocumentDB to use during maintenance activities, including failover and compute scaling. For example, a range such as 10.0.0.0/24 and 10.0.1.0/24 is typically large enough. + A VPC can have an `instance tenancy` attribute of either `default` or `dedicated`. All default VPCs have the `instance tenancy` attribute set to default, and a default VPC can support any instance class. If you choose to have your cluster in a dedicated VPC where the `instance tenancy` attribute is set to `dedicated`, the instance class of your cluster must be one of the approved Amazon EC2 dedicated instance types. For example, the `r5.large` EC2 dedicated instance corresponds to the `db.r5.large` instance class. For information about instance tenancy in a VPC, see [Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Instances.html) in the *Amazon Elastic Compute Cloud User Guide*. For more information about the instance types that can be in a dedicated instance, see [Amazon EC2 dedicated instances](https://aws.amazon.com/ec2/pricing/dedicated-instances/) on the Amazon EC2 pricing page. **Note** When you set the `instance tenancy` attribute to `dedicated` for a cluster, it doesn't guarantee that the cluster will run on a dedicated host. ## Working with subnet groups Subnets are segments of a VPC's IP address range that you designate to group your resources based on security and operational needs. A subnet group is a collection of subnets (typically private) that you create in a VPC and that you then designate for your clusters. By using a subnet group, you can specify a particular VPC when creating clusters using the AWS CLI or Amazon DocumentDB API. If you use the console, you can choose the VPC and subnet groups you want to use. Each subnet group should have subnets in at least two Availability Zones in a given AWS Region. When creating a cluster in a VPC, you choose a subnet group for it. From the subnet group, Amazon DocumentDB chooses a subnet and an IP address within that subnet to associate with the primary instance in your cluster. The database uses the Availability Zone that contains the subnet. DocumentDB always assigns an IP address from a subnet that has free IP address space. The subnets in a subnet group are either public or private, depending on the configuration that you set for their network access control lists (network ACLs) and routing tables. For a cluster to be publicly accessible, all of the subnets in its subnet group must be public. If a subnet that's associated with a publicly accessible cluster changes from public to private, it can affect cluster availability. To create a subnet group that supports dual-stack mode, make sure that each subnet that you add to the subnet group has an Internet Protocol version 6 (IPv6) CIDR block associated with it. For more information, see [Amazon DocumentDB IP addressing](#vpc-docdb-ip-addressing) and [IPv6 support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) in the *Amazon Virtual Private Cloud User Guide*. When Amazon DocumentDB creates a cluster in a VPC, it assigns a network interface to the cluster by using an IP address from your subnet group. However, we strongly recommend that you use the Domain Name System (DNS) name to connect to your cluster. We recommend this because the underlying IP address changes during failover. **Note** For each cluster that you run in a VPC, make sure to reserve at least one address in each subnet in the subnet group for use by Amazon DocumentDB for recovery actions. ### Shared subnets You can create a cluster in a shared VPC. Some considerations to keep in mind while using shared VPCs: + You can move a cluster from a shared VPC subnet to a non-shared VPC subnet and vice-versa. + Participants in a shared VPC must create a security group in the VPC to allow them to create a cluster. + Owners and participants in a shared VPC can access the database by using DocumentDB queries. However, only the creator of a resource can make any API calls on the resource. ## Amazon DocumentDB IP addressing IP addresses enable resources in your VPC to communicate with each other, and with resources over the internet. Amazon DocumentDB supports both IPv4 and IPv6 addressing protocols. By default, Amazon DocumentDB and Amazon VPC use the IPv4 addressing protocol. You can't turn off this behavior. When you create a VPC, make sure to specify an IPv4 CIDR block (a range of private IPv4 addresses). You can optionally assign an IPv6 CIDR block to your VPC and subnets, and assign IPv6 addresses from that block to clusters in your subnet. **Note** Dual-stack mode (IPv6 addressing) is only supported in Amazon DocumentDB versions 4.0 and 5.0. Support for the IPv6 protocol expands the number of supported IP addresses. By using the IPv6 protocol, you ensure that you have sufficient available addresses for the future growth of the internet. New and existing DocumentDB resources can use IPv4 and IPv6 addresses within your VPC. Configuring, securing, and translating network traffic between the two protocols used in different parts of an application can cause operational overhead. You can standardize on the IPv6 protocol for Amazon DocumentDB resources to simplify your network configuration. **Topics** + [IPv4 addresses](#vpc-docdb-ipv4-addresses) + [IPv6 addresses](#vpc-docdb-ipv6-addresses) + [Dual-stack mode](#vpc-docdb-dual-stack) ### IPv4 addresses When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a CIDR block, such as `10.0.0.0/16`. A subnet group defines the range of IP addresses in this CIDR block that a cluster can use. These IP addresses can be private or public. A private IPv4 address is an IP address that's not reachable over the internet. You can use private IPv4 addresses for communication between your cluster and other resources, such as Amazon EC2 instances, in the same VPC. Each cluster has a private IP address for communication in the VPC. A public IP address is an IPv4 address that's reachable from the internet. Public IP addressing is not allowed for your DocumentDB cluster. Any public IP address should be resolved by the Internet gateway and by EC2 in the public subnet. To see how to create a VPC with only private IPv4 addresses that you can use for a common Amazon DocumentDB scenario, see [Create an IPv4-only VPC for use with a DocumentDB cluster](docdb-vpc-create-ipv4.md). ### IPv6 addresses You can optionally associate an IPv6 CIDR block with your VPC and subnets, and assign IPv6 addresses from that block to the resources in your VPC. Each IPv6 address is globally unique. The IPv6 CIDR block for your VPC is automatically assigned from Amazon's pool of IPv6 addresses. You can't choose the range yourself. When connecting to an IPv6 address, make sure that the following conditions are met: + The client is configured so that client to database traffic over IPv6 is allowed. + DocumentDB security groups used by the cluster are configured correctly so that client to database traffic over IPv6 is allowed. + The client operating system stack allows traffic on the IPv6 address, and operating system drivers and libraries are configured to choose the correct default cluster endpoint (either IPv4 or IPv6). For more information about IPv6, see [IP Addressing](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) in the *Amazon Virtual Private Cloud User Guide*. ### Dual-stack mode When a cluster can communicate over both the IPv4 and IPv6 addressing protocols, it's running in dual-stack mode. So, resources can communicate with the cluster over IPv4, IPv6, or both. DocumentDB disables Internet Gateway access for IPv6 endpoints of private dual-stack mode clusters. DocumentDB does this to ensure that your IPv6 endpoints are private and can only be accessed from within your VPC. **Topics** + [Dual-stack mode and subnet groups](#dual-stack-subnet) + [Working with dual-stack mode clusters](#dual-stack-clusters) + [Modifying IPv4-only clusters to use dual-stack mode](#modify-ipv4-clusters) + [Dual-stack mode Region and version availability](#dual-stack-availability) + [Limitations for dual-stack network clusters](#dual-stack-limitations) #### Dual-stack mode and subnet groups To use dual-stack mode, make sure that each subnet in the subnet group that you associate with the cluster has an IPv6 CIDR block associated with it. You can create a new subnet group or modify an existing subnet group to meet this requirement. After a cluster is in dual-stack mode, clients can connect to it normally. Make sure that client security firewalls and DocumentDB cluster security groups are accurately configured to allow traffic over IPv6. To connect, clients use the cluster's endpoint. Client applications can specify which protocol is preferred when connecting to a database. In dual-stack mode, the cluster detects the client's preferred network protocol, either IPv4 or IPv6, and uses that protocol for the connection. If a subnet group stops supporting dual-stack mode because of subnet deletion or CIDR disassociation, there's a risk of an incompatible network state for clusters that are associated with the subnet group. Also, you can't use the subnet group when you create a new dual-stack mode cluster. To determine whether a subnet group supports dual-stack mode by using the AWS Management Console, view the **Network type** on the details page of the subnet group. To determine whether a subnet group supports dual-stack mode by using the AWS CLI, run the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/docdb/describe-db-subnet-groups.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/docdb/describe-db-subnet-groups.html) command and view `SupportedNetworkTypes` in the output. Read replicas are treated as independent clusters and can have a network type that's different from the primary cluster. If you change the network type of a read replica's primary cluster, the read replica isn't affected. When you are restoring a cluster, you can restore it to any network type that's supported. #### Working with dual-stack mode clusters When you create or modify a cluster, you can specify dual-stack mode to allow your resources to communicate with your cluster over IPv4, IPv6, or both. When you use the AWS Management Console to create or modify a cluster, you can specify dual-stack mode in the **Network type** section. The following image shows the **Network type** section in the console: ![\[Network type section in the console with Dual-stack mode selected.\]](http://docs.aws.amazon.com/documentdb/latest/developerguide/images/nw-type-dual-stack.png) When you use the AWS CLI to create or modify a cluster, set the `--network-type` option to `DUAL` to use dual-stack mode. When you use the DocumentDB API to create or modify a cluster, set the `NetworkType` parameter to `DUAL` to use dual-stack mode. If dual-stack mode isn't supported by the specified DocumentDB engine version or subnet group, the `NetworkTypeNotSupported` error is returned. For more information about creating a cluster, see [Creating an Amazon DocumentDB cluster](db-cluster-create.md). For more information about modifying a cluster, see [Modifying an Amazon DocumentDB cluster](db-cluster-modify.md). To determine whether a cluster is in dual-stack mode by using the console, view the **Network type** on the **Connectivity & security** tab for the cluster. #### Modifying IPv4-only clusters to use dual-stack mode You can modify an IPv4-only cluster to use dual-stack mode. To do so, change the network type of the cluster. It is recommended that you change the network type of your Amazon DocumentDB cluster during a maintenance window. You can set network type manually by using the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/docdb/modify-db-cluster.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/docdb/modify-db-cluster.html) command. Before modifying a cluster to use dual-stack mode, make sure that its subnet group supports dual-stack mode. If the subnet group associated with the cluster doesn't support dual-stack mode, specify a different subnet group that supports it when you modify the cluster. Modifying the subnet group of a cluster can cause downtime. If you modify the subnet group of a cluster before you change the cluster to use dual-stack mode, make sure that the subnet group is valid for the cluster before and after the change. We recommend that you run the `ModifyDBCluster` call with only the `NetworkType` parameter set to `DUAL` to change the network to dual-stack mode. Adding other parameters along with `NetworkType` in the same API call could result in downtime. To modify multiple parameters, ensure that the network type modification is successfully completed before sending another `ModifyDBCluster` request with other parameters. If you can't connect to the cluster after the change, make sure that the client and database security firewalls and route tables are accurately configured to allow traffic to the database on the selected network (either IPv4 or IPv6). You might also need to modify operating system parameter, libraries, or drivers to connect using an IPv6 address. **To modify an IPv4-only cluster to use dual-stack mode** 1. Modify a subnet group to support dual-stack mode, or create a subnet group that supports dual-stack mode: 1. Associate an IPv6 CIDR block with your VPC. For instructions, see [Add or remove a CIDR block to your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/add-ipv4-cidr.html) in the *Amazon VPC User Guide*. 1. Attach the IPv6 CIDR block to all of the subnets in your subnet group. For instructions, see [Add or remove an IPv6 CIDR block to your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-associate-ipv6-cidr.html) in the *Amazon Virtual Private Cloud User Guide*. 1. Confirm that the subnet group supports dual-stack mode. If you are using the AWS Management Console, select the subnet group, and make sure that the **Supported network types** value is **Dual**. If you are using the AWS CLI, run the [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/docdb/describe-db-subnet-groups.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/docdb/describe-db-subnet-groups.html) command, and make sure that the `SupportedNetworkType` value for the cluster is `Dual`. 1. Modify the security group associated with the cluster to allow IPv6 connections to the database, or create a new security group that allows IPv6 connections. For instructions, see [Security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) in the *Amazon Virtual Private Cloud User Guide*. 1. Modify the cluster to support dual-stack mode. To do so, set the **Network type** to **Dual-stack mode**. If you are using the console, make sure that the following settings are correct: + **Network type** — **Dual-stack mode** ![\[Network type section in the console with Dual-stack mode selected.\]](http://docs.aws.amazon.com/documentdb/latest/developerguide/images/nw-type-dual-stack.png) + **Subnet group** — The subnet group that you configured in a previous step + **Security group** — The security that you configured in a previous step If you are using the AWS CLI, make sure that the following settings are correct: + `--network-type` — `dual` + `--db-subnet-group-name` — The subnet group that you configured in a previous step + `--vpc-security-group-ids` — The VPC security group that you configured in a previous step For example: ``` aws docdb modify-db-cluster --db-cluster-identifier --network-type "DUAL" ``` 1. Confirm that the cluster supports dual-stack mode. If you are using the console, choose the **Connectivity & security** tab for the cluster and make sure that the **Network type** value is **Dual-stack mode**. If you are using the AWS CLI, run the `describe-db-cluster` command, and make sure that the `NetworkType` value for the cluster is `dual`. Run the `dig` command on the cluster endpoint to identify the IPv6 address associated with it: ``` dig AAAA ``` Use the cluster endpoint, not the IPv6 address, to connect to the cluster. #### Dual-stack mode Region and version availability Feature availability and support varies across AWS Regions. **Region support** The following list identifies the AWS Regions that support dual-stack mode: + US East (Ohio) + US East (N. Virginia) + US West (Oregon) + Africa (Cape Town) + South America (São Paulo) + Asia Pacific (Hong Kong) + Asia Pacific (Hyderabad) + Asia Pacific (Malaysia) + Asia Pacific (Mumbai) + Asia Pacific (Osaka) + Asia Pacific (Seoul) + Asia Pacific (Singapore) + Asia Pacific (Sydney) + Asia Pacific (Jakarta) + Asia Pacific (Thailand) + Asia Pacific (Tokyo) + Canada (Central) + China (Beijing) + China (Ningxia) + Europe (Frankfurt) + Europe (Ireland) + Europe (London) + Europe (Milan) + Europe (Paris) + Europe (Spain) + Europe (Stockholm) + Israel (Tel Aviv) + Mexico (Central) + Middle East (UAE) + AWS GovCloud (US-West) + AWS GovCloud (US-East) **Version support** Dual-stack mode is supported on Amazon DocumentDB version 4.0 and 5.0. If you are unable to access dual-stack mode on either of these versions, please make sure that you are running the latest engine patch version on your cluster. #### Limitations for dual-stack network clusters The following limitations apply to dual-stack network clusters: + Clusters can't use the IPv6 protocol exclusively. They can use IPv4 exclusively, or they can use the IPv4 and IPv6 protocol (dual-stack mode). + Amazon DocumentDB doesn't support native IPv6 subnets. + Clusters that use dual-stack mode must be private. They can't be publicly accessible. ## Creating a cluster in a VPC The following procedures help you create a cluster in a VPC. To use the default VPC, you can begin with step 2, and use the VPC and subnet group that have already been created for you. You can also create additional VPCs, if needed. **Note** If you want your cluster in the VPC to be publicly accessible, you must update the DNS information for the VPC by enabling the VPC attributes `DNS hostnames` and `DNS resolution`. For information about updating the DNS for a VPC instance, see [View and update DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) in the *Amazon Virtual Private Cloud User Guide*. Follow these steps to create a cluster in a VPC: + [Step 1: Create a VPC](#step1-create-vpc) + [Step 2: Create a subnet group](#step2-create-subnet-group) + [Step 3: Create a VPC security group](#step3-create-security-group) + [Step 4: Create a cluster in the VPC](#step4-create-vpc-cluster) ### Step 1: Create a VPC Create a VPC with subnets in at least two Availability Zones. You use these subnets when you create a subnet group. If you have a default VPC, a subnet is automatically created for you in each Availability Zone in the AWS Region. For more information, see [Create an IPv4-only VPC for use with a DocumentDB cluster](docdb-vpc-create-ipv4.md), or see [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) in the *Amazon Virtual Private Cloud User Guide*. ### Step 2: Create a subnet group A subnet group is a collection of subnets (typically private) that you create for a VPC and that you then designate for your clusters. A subnet group allows you to specify a particular VPC when you create clusters using the AWS CLI or DocumentDB API. If you use the AWS Management Console, you can just choose the VPC and subnets you want to use. Each subnet group must have at least one subnet in at least two Availability Zones in the AWS Region. As a best practice, each subnet group should have at least one subnet for every Availability Zone in the AWS Region. For a cluster to be publicly accessible, the subnets in the subnet group must have an internet gateway. For more information about internet gateways for subnets, see [Enable internet access for a VPC using an internet gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) in the *Amazon Virtual Private Cloud User Guide*. **Note** The subnet group for a local zone can have only one subnet. When you create a cluster in a VPC, you can choose a subnet group. Amazon DocumentDB chooses a subnet and an IP address (within that subnet) to associate with your cluster. If no subnet groups exist, Amazon DocumentDB creates a default subnet group when you create the cluster. DocumentDB creates and associates an Elastic Network Interface to your cluster with that IP address. The cluster uses the Availability Zone that contains the subnet. In this step, you create a subnet group and add the subnets that you created for your VPC. **To create a subnet group** 1. Sign in to the AWS Management Console, and open the Amazon DocumentDB console at [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb). 1. In the navigation pane, choose **Subnet groups**. 1. Choose **Create**. 1. For **Name**, type the name of your subnet group. 1. For **Description**, type a description for your subnet group. 1. In the **Add subnets** section, for **VPC**, choose the default VPC or the VPC that you created. Then choose the Availability Zones that include the subnets from **Availability Zones**, and then choose the subnets from **Subnets**. 1. Choose Create. Your new subnet group appears in the **Subnet groups** list on the DocumentDB console. You can choose the subnet group to see details, including all of the subnets associated with the group, in the details pane at the bottom of the window. ### Step 3: Create a VPC security group Before you create your cluster, create a VPC security group to associate with it. If you don't create a VPC security group, you can use the default security group when you create the cluster. For instructions on how to create a security group for your cluster, see [Create an IPv4-only VPC for use with a DocumentDB cluster](docdb-vpc-create-ipv4.md), or see [Control traffic to your AWS resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) in the *Amazon Virtual Private Cloud User Guide*. ### Step 4: Create a cluster in the VPC In this step, you create a cluster using the VPC name, the subnet group, and the VPC security group you created in the previous steps. **Note** If you want your cluster in the VPC to be publicly accessible, you must enable the VPC attributes `DNS hostnames` and `DNS resolution`. For more information, see [View and update DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) in the *Amazon Virtual Private Cloud User Guide*. For details on how to create a cluster, see [Creating an Amazon DocumentDB cluster](db-cluster-create.md). When prompted in the **Connectivity** section, enter the VPC name, the subnet group, and the VPC security group. **Note** Updating VPCs isn't currently supported for DocumentDBDocumentDB clusters. # Accessing an Amazon DocumentDB cluster in a VPC Amazon DocumentDB supports the following scenarios for accessing a cluster in a VPC: **Topics** + [An Amazon EC2 instance in the same VPC](#access-inside-vpc) + [An Amazon EC2 instance in a different VPC](#access-different-vpc) ## A cluster in a VPC accessed by an Amazon EC2 instance in the same VPC A common use of a cluster in a VPC is to share data with an application server that is running in an Amazon EC2 instance in the same VPC. The simplest way to manage access between EC2 instances and clusters in the same VPC is to do the following: + Create a VPC security group for your clusters to be in. This security group can be used to restrict access to the clusters. For example, you can create a custom rule for this security group. This might allow TCP access using the port that you assigned to the cluster when you created it and an IP address you use to access the cluster for development or other purposes. + Create a VPC security group for your EC2 instances (web servers and clients) to be in. This security group can, if needed, allow access to the EC2 instance from the internet by using the VPC's routing table. For example, you can set rules on this security group to allow TCP access to the EC2 instance over port 22. + Create custom rules in the security group for your clusters that allow connections from the security group you created for your EC2 instances. These rules might allow any member of the security group to access the clusters. There is an additional public and private subnet in a separate Availability Zone. An DocumentDB subnet group requires a subnet in at least two Availability Zones. The additional subnet makes it easy to switch to a multi-AZ cluster deployment in the future. For instructions on how to create a VPC with both public and private subnets for this scenario, see [Create an IPv4-only VPC for use with a DocumentDB cluster](docdb-vpc-create-ipv4.md). **Tip** You can set up network connectivity between an Amazon EC2 instance and a DocumentDB cluster automatically when you create the cluster. For more information, see [Connect Amazon EC2 automatically](connect-ec2-auto.md). **To create a rule in a VPC security group that allows connections from another security group, do the following:** 1. Sign in to the AWS Management Console and open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. In the navigation pane, locate and choose **Security groups**. 1. Choose or create a security group for which you want to allow access to members of another security group. This is the security group that you use for your clusters. Choose the **Inbound rules** tab, and then choose **Edit inbound rules**. 1. On the **Edit inbound rules** page, choose **Add rule**. 1. For **Type**, choose the entry that corresponds to the port you used when you created your cluster, such as **Custom TCP**. 1. In the **Source** field, start typing the ID of the security group, which lists the matching security groups. Choose the security group with members that you want to have access to the resources protected by this security group. In the scenario preceding, this is the security group that you use for your EC2 instance. 1. If required, repeat the steps for the TCP protocol by creating a rule with **All TCP** as the **Type** and your security group in the **Source** field. If you intend to use the UDP protocol, create a rule with **All UDP** as the **Type** and your security group in **Source**. 1. Choose **Save rules**. The following screen shows an inbound rule with a security group for its source. ![\[Inbound rules tab showing rule with security group as the source\]](http://docs.aws.amazon.com/documentdb/latest/developerguide/images/inbound-rule-sg.png) For more information about connecting to a cluster from your EC2 instance, see [Connect Amazon EC2 automatically](connect-ec2-auto.md). ## A cluster in a VPC accessed by an Amazon EC2 instance in a different VPC When your clusters is in a different VPC from the EC2 instance you are using to access it, you can use VPC peering to access the cluster. A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IP addresses. Resources in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, with a VPC in another AWS account, or with a VPC in a different AWS Region. To learn more about VPC peering, see [VPC peering](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) in the *Amazon Virtual Private Cloud User Guide*. # Create an IPv4-only VPC for use with a DocumentDB cluster A common scenario includes a cluster in a virtual private cloud (VPC) based on the Amazon VPC service. For example, this VPC could share data with a service or application that is running in the same VPC. In this topic, you create the VPC for this scenario. **Topics** + [Step 1: Create a VPC with private and public subnets](#vpc-private-public-subnets) + [Step 2: Create a VPC security group for a public application](#create-vpc-sg-public) + [Step 3: Create a VPC security group for a private cluster](#create-vpc-sg-private) + [Step 4: Create a subnet group](#create-cluster-subnet-group) + [Deleting a VPC](#docdb-delete-vpc) Your cluster needs to be available only to your application, and not to the public internet. Thus, you create a VPC with both public and private subnets. The application is hosted in the public subnet, so that it can reach the public internet. The cluster is hosted in a private subnet. The application can connect to the cluster because it is hosted within the same VPC. But the cluster isn't available to the public internet, providing greater security. The procedure in this topic configures an additional public and private subnet in a separate Availability Zone. These subnets aren't used by the procedure. A DocumentDB subnet group requires a subnet in at least two Availability Zones. The additional subnet makes it easier to configure more than one DocumentDB instance. This topic describes configuring a VPC for Amazon DocumentDB clusters. For more information about Amazon VPC, see the [https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). **Tip** You can set up network connectivity between an Amazon EC2 instance and a DocumentDB cluster automatically when you create the cluster. The network configuration is similar to the one described in this scenario. For more information, see [Connect Amazon EC2 automatically](connect-ec2-auto.md). ## Step 1: Create a VPC with private and public subnets Use the following procedure to create a VPC with both public and private subnets. **To create a VPC and subnets** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. In the top-right corner of the AWS Management Console, choose the Region to create your VPC in. This example uses the US West (Oregon) Region. 1. In the upper-left corner, choose **VPC dashboard**. To begin creating a VPC, choose **Create VPC**. 1. For **Resources to create** under **VPC settings**, choose **VPC and more**. 1. For the **VPC settings**, set these values: + **Name tag auto-generation** — **example** + **IPv4 CIDR block** — **10.0.0.0/16** + **IPv6 CIDR block** — **No IPv6 CIDR block** + **Tenancy** — **Default** + **Number of Availability Zones (AZs)** — **2** + **Customize AZs** — Keep the default values + **Number of public subnets** — **2** + **Number of private subnets** — **2** + **Customize subnets CIDR blocks** — Keep the default values + **NAT gateways (\$1)** — **None** + **VPC endpoints** — **None** + **DNS options** — Keep the default values 1. Choose **Create VPC**. ## Step 2: Create a VPC security group for a public application Next, create a security group for public access. To connect to public EC2 instances in your VPC, you add inbound rules to your VPC security group. These allow traffic to connect from the internet. **To create a VPC security group** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, choose **Security Groups**, and then choose **Create security group**. 1. On the **Create security group** page, set these values: + **Security group name** — **example-securitygroup** + **Description** — **Application security group** + **VPC** — Choose the VPC that you created earlier, for example: **vpc-example**. 1. Add inbound rules to the security group. 1. Determine the IP address to use to connect to EC2 instances in your VPC using Secure Shell (SSH). To determine your public IP address, in a different browser window or tab, you can use the service at [https://checkip.amazonaws.com](https://checkip.amazonaws.com). An example of an IP address is `203.0.113.25/32`. In many cases, you might connect through an internet service provider (ISP) or from behind your firewall without a static IP address. If so, find the range of IP addresses used by client computers. **Warning** If you use `0.0.0.0/0` for SSH access, you make it possible for all IP addresses to access your public instances using SSH. This approach is acceptable for a short time in a test environment, but it's unsafe for production environments. In production, authorize only a specific IP address or range of addresses to access your instances using SSH. 1. In the **Inbound rules** section, choose **Add rule**. 1. Set the following values for your new inbound rule to allow SSH access to your Amazon EC2 instance. After you do this, you can connect to your EC2 instance to install the application and other utilities. You also connect to your EC2 instance to upload content for your application. + **Type** — **SSH** + **Source** — The IP address or range you created from Step a, for example: **203.0.113.25/32** 1. Choose **Add rule**. 1. Set the following values for your new inbound rule to allow HTTP access to your application: + **Type** — **HTTP** + **Source** — **0.0.0.0/0** 1. Choose **Create security group** to create the security group. Note the security group ID because you need it later in another procedure. ## Step 3: Create a VPC security group for a private cluster To keep your cluster private, create a second security group for private access. To connect to private clusters in your VPC, you add inbound rules to your VPC security group that allow traffic from your application only. **To create a VPC security group** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, choose **Security Groups**, and then choose **Create security group**. 1. On the **Create security group** page, set these values: + **Security group name** — **example-securitygroup** + **Description** — **Instance security group** + **VPC** — Choose the VPC that you created earlier, for example: **vpc-example** 1. Add inbound rules to the security group. 1. In the **Inbound rules** section, choose **Add rule**. 1. Set the following values for your new inbound rule to allow DocumentDB traffic on port 27017 from your Amazon EC2 instance. After you do this, you can connect from your application to your cluster. By doing so, you can store and retrieve data from your application to your database. + **Type** — **Custom TCP** + **Source** — The identifier of the application security group that you created previously in this topic, for example: **sg-9edd5cfb**. 1. Choose **Add rule**. 1. Set the following values for your new inbound rule to allow HTTP access to your application: + **Type** — **HTTP** + **Source** — **0.0.0.0/0** 1. Choose **Create security group** to create the security group. ## Step 4: Create a subnet group A subnet group is a collection of subnets that you create in a VPC and that you then designate for your clusters. A subnet group makes it possible for you to specify a particular VPC when creating clusters. **To create a subnet group** 1. Identify the private subnets for your database in the VPC. 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Subnets**. 1. Note the subnet IDs of the subnets you created in Step 1 named, for example: **example-subnet-private1-us-west-2a** and **example-subnet-private2-us-west-2b**. You need the subnet IDs when you create your subnet group. 1. Sign in to the AWS Management Console, and open the Amazon DocumentDB console at [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb). Make sure that you connect to the Amazon DocumentDB console, not to the Amazon VPC console. 1. In the navigation pane, choose **Subnet groups**. 1. Choose **Create**. 1. On the **Create subnet group** page, set these values in the **Subnet group details** section: + **Name** — **example-db-subnet-group** + **Description** — **Instance security group** 1. In the **Add subnets** section, set these values: + **VPC** — Choose the VPC that you created earlier, for example: **vpc-example** + **Availability Zones** — Select both Availability Zones created in Step 1. Example: **us-west-2a** and **us-west-2b** + **Subnets** — Choose the private subnets you created in Step 1. 1. Choose **Create**. Your new subnet group appears in the subnet groups list on the DocumentDB console. You can choose the subnet group to see details in the details pane. These details include all of the subnets associated with the group. **Note** If you created this VPC to associated it with a DocumentDB cluster, create the cluster by following the instructions in [Creating an Amazon DocumentDB cluster](db-cluster-create.md). ## Deleting a VPC You can delete a VPC and the other resources that are used within it, if they are no longer needed. **Note** If you added resources in the VPC that you created in this topic, you might need to delete these before you can delete the VPC. For example, these resources might include Amazon EC2 instances or DocumentDB clusters. For more information, see [Delete your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/delete-vpc.html) in the *Amazon VPC User Guide*. **To delete a VPC and related resources** 1. Delete the subnet group: 1. Sign in to the AWS Management Console, and open the Amazon DocumentDB console at [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb). 1. In the navigation pane, choose **Subnet groups**. 1. Select the subnet group you want to delete, such as **example-db-subnet-group**. 1. Choose **Delete**, and then choose **Delete** in the confirmation window. 1. Note the VPC ID: 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Your VPCs**. 1. In the list, identify the VPC that you created, such as **vpc-example**. 1. Note the **VPC ID** of the VPC that you created. You need the VPC ID in later steps. 1. Delete the security groups: 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Security Groups**. 1. Select the security group for the Amazon DocumentDB cluster, such as **example-securitygroup**. 1. For **Actions**, choose **Delete security groups**, and then choose **Delete** on the confirmation dialog. 1. Back on the **Security Groups** page, select the security group for the Amazon EC2 instance, such as **example-securitygroup**. 1. For **Actions**, choose **Delete security groups**, and then choose **Delete** on the confirmation dialog. 1. Delete the VPC: 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Your VPCs**. 1. Select the VPC you want to delete, such as **vpc-example**. 1. For **Actions**, choose Delete VPC. The confirmation page shows other resources that are associated with the VPC that will also be deleted, including the subnets associated with it. 1. On the confirmation dialog, enter **delete**, and then choose **Delete**. # Create a dual-stack VPC for use with a DocumentDB cluster A common scenario includes a cluster in a virtual private cloud (VPC) based on the Amazon VPC service. This VPC shares data with a public Amazon EC2 instance that is running in the same VPC. In this topic, you create the VPC for this scenario. **Topics** + [Step 1: Create a VPC with private and public subnets](#ds-vpc-private-public-subnets) + [Step 2: Create a VPC security group for a public Amazon EC2 instance](#ds-vpc-public-security-group) + [Step 3: Create a VPC security group for a private cluster](#ds-vpc-private-security-group) + [Step 4: Create a subnet group](#ds-vpc-subnet-group) + [Step 5: Create an Amazon EC2 instance in dual-stack mode](#ds-vpc-ec2-dual-stack) + [Step 6: Create a cluster in dual-stack mode](#ds-vpc-cluster-dual-stack) + [Step 7: Connect to your Amazon EC2 instance and DB cluster](#ds-vpc-connect-ec2) + [Delete the VPC](#ds-vpc-delete) In this procedure, you create the VPC for this scenario that works with a database running in dual-stack mode. Dual-stack mode enables connection over the IPv6 addressing protocol. For more information about IP addressing, see [Amazon DocumentDB IP addressing](vpc-clusters.md#vpc-docdb-ip-addressing). Dual-stack network clusters are supported in most regions. For more information see [Dual-stack mode Region and version availability](vpc-clusters.md#dual-stack-availability). To see the limitations of dual-stack mode, see [Limitations for dual-stack network clusters](vpc-clusters.md#dual-stack-limitations). This topic and the IPv4-only topic create the public and private subnets in the same VPC. For information about creating the Amazon DocumentDB cluster in one VPC and the Amazon EC2 instance in a different VPC, see [Accessing an Amazon DocumentDB cluster in a VPC](access-cluster-vpc.md). Your DocumentDB cluster needs to be available only to your Amazon EC2 instance, and not to the public internet. Thus, you create a VPC with both public and private subnets. The EC2 instance is hosted in the public subnet, so that it can reach the public internet. The cluster is hosted in a private subnet. The EC2 instance can connect to the cluster because it's hosted within the same VPC. However, the cluster is not available to the public internet, providing greater security. The procedures in this topic configures an additional public and private subnet in a separate Availability Zone. These subnets aren't used by the procedure. An DocumentDB subnet group requires a subnet in at least two Availability Zones. The additional subnet makes it easy to configure more than one DocumentDB instance. To create a cluster that uses dual-stack mode, specify **Dual-stack mod**e for the **Network type** setting. You can also modify a cluster with the same setting. For more information about creating a cluster, see [Creating an Amazon DocumentDB cluster](db-cluster-create.md). For more information about modifying a DB cluster, see [Modifying an Amazon DocumentDB cluster](db-cluster-modify.md). This topic describes configuring a VPC for Amazon DocumentDB clusters. For more information about Amazon VPC, see the [https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). ## Step 1: Create a VPC with private and public subnets Use the following procedure to create a VPC with both public and private subnets. **To create a VPC and subnets** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. In the top-right corner of the AWS Management Console, choose the Region to create your VPC in. This example uses the US West (Oregon) Region. 1. In the upper-left corner, choose **VPC dashboard**. To begin creating a VPC, choose **Create VPC**. 1. For **Resources to create** under **VPC settings**, choose **VPC and more**. 1. For the **VPC settings**, set these values: + **Name tag auto-generation** — **example-dual-stack** + **IPv4 CIDR block** — **10.0.0.0/16** + **IPv6 CIDR block** — **Amazon-provided IPv6 CIDR block** + **Tenancy** — **Default** + **Number of Availability Zones (AZs)** — **2** + **Customize AZs** — Keep the default values + **Number of public subnets** — **2** + **Number of private subnets** — **2** + **Customize subnets CIDR blocks** — Keep the default values + **NAT gateways (\$1)** — **None** + **Egress only internet gateway** — **No** + **VPC endpoints** — **None** + **DNS options** — Keep the default values 1. Choose **Create VPC**. ## Step 2: Create a VPC security group for a public Amazon EC2 instance Next, you create a security group for public access. To connect to public EC2 instances in your VPC, add inbound rules to your VPC security group that allow traffic to connect from the internet. **To create a VPC security group** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, choose **Security Groups**, and then choose **Create security group**. 1. On the **Create security group** page, set these values: + **Security group name** — **example-dual-stack-securitygroup** + **Description** — **Dual-stack security group** + **VPC** — Choose the VPC that you created earlier, for example: **vpc-example-dual-stack**. 1. Add inbound rules to the security group. 1. Determine the IP address to use to connect to EC2 instances in your VPC using Secure Shell (SSH). To determine your public IP address, in a different browser window or tab, you can use the service at [https://checkip.amazonaws.com](https://checkip.amazonaws.com). An example of an Internet Protocol version 4 (IPv4) address range is `203.0.113.25/32`. An example of an Internet Protocol version 6 (IPv6) address range is `2001:db8:1234:1a00::/64`. In many cases, you might connect through an internet service provider (ISP) or from behind your firewall without a static IP address. If so, find the range of IP addresses used by client computers. **Warning** If you use `0.0.0.0/0` for IPv4 or `::0` for IPv6, you make it possible for all IP addresses to access your public instances using SSH. This approach is acceptable for a short time in a test environment, but it's unsafe for production environments. In production, authorize only a specific IP address or range of addresses to access your instances. 1. In the **Inbound rules** section, choose **Add rule**. 1. Set the following values for your new inbound rule to allow SSH access to your Amazon EC2 instance. After you do this, you can connect to your EC2 instance to install applications or other utilities. Specify an IP address so you can access your EC2 instance: + **Type** — **SSH** + **Source** — The IP address or range you created from Step a. An example of an IPv4 address range is **203.0.113.25/3**2. An example of an IPv6 address range is **2001:DB8::/32**. 1. Choose **Add rule**. 1. Choose **Create security group** to create the security group. Note the security group ID because you need it later in another procedure. ## Step 3: Create a VPC security group for a private cluster To keep your cluster private, create a second security group for private access. To connect to private clusters in your VPC, add inbound rules to your VPC security group. These allow traffic from your Amazon EC2 instance only. **To create a VPC security group** 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, choose **Security Groups**, and then choose **Create security group**. 1. On the **Create security group** page, set these values: + **Security group name** — **example-dual-stack-cluster-securitygroup** + **Description** — **Dual-stack cluster security group** + **VPC** — Choose the VPC that you created earlier, for example: **vpc-example-dual-stack** 1. Add inbound rules to the security group. 1. In the **Inbound rules** section, choose **Add rule**. 1. Set the following values for your new inbound rule to allow DocumentDB traffic on port 27017 from your Amazon EC2 instance. After you do this, you can connect from your EC2 instance to your cluster. By doing so, you can send data from your EC2 instance to your database. + **Type** — **Custom TCP** + **Source** — The identifier of the EC2 security group that you created previously in this topic, for example: **sg-9edd5cfb**. 1. Choose **Create security group** to create the security group. ## Step 4: Create a subnet group A subnet group is a collection of subnets that you create in a VPC and that you then designate for your clusters. By using a subnet group, you can specify a particular VPC when creating clusters. To create a subnet group that is `DUAL` compatible, all subnets must be `DUAL` compatible. To be `DUAL` compatible, a subnet must have an IPv6 CIDR associated with it. **To create a subnet group** 1. Identify the private subnets for your database in the VPC. 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Subnets**. 1. Note the subnet IDs of the subnets you created in Step 1 named, for example: **example-dual-stack-subnet-private1-us-west-2a** and **example-dual-stack-subnet-private2-us-west-2b**. You need the subnet IDs when you create your subnet group. 1. Sign in to the AWS Management Console, and open the Amazon DocumentDB console at [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb). Make sure that you connect to the Amazon DocumentDB console, not to the Amazon VPC console. 1. In the navigation pane, choose **Subnet groups**. 1. Choose **Create**. 1. On the **Create subnet group** page, set these values in the **Subnet group details** section: + **Name** — **example-dual-stack-cluster-subnet-group** + **Description** — **Dual-stack cluster subnet group** 1. In the **Add subnets** section, set these values: + **VPC** — Choose the VPC that you created earlier, for example: **vpc-example-dual-stack** + **Availability Zones** — Select both Availability Zones created in Step 1. Example: **us-west-2a** and **us-west-2b** + **Subnets** — Choose the private subnets you created in Step 1. 1. Choose **Create**. Your new subnet group appears in the subnet groups list on the DocumentDB console. You can choose the subnet group to see details in the details pane. These details include all of the subnets associated with the group. ## Step 5: Create an Amazon EC2 instance in dual-stack mode To create an Amazon EC2 instance, follow the instructions in [Launch an EC2 instance using the launch instance wizard in the console](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) in the *Amazon Elastic Compute Cloud User Guide*. On the **Configure Instance Details** page, set these values and keep the other values as their defaults: + **Network** — Choose an existing VPC with both public and private subnets, such as **vpc-example-dual-stack-vpc** (vpc-*identifier*) created in [Step 1: Create a VPC with private and public subnets](#ds-vpc-private-public-subnets). + **Subnet** — Choose an existing public subnet, such as **subnet-*identifier* \$1 example-dual-stack-subnet-public1-us-east-2a \$1 us-east-2a** created in [Step 2: Create a VPC security group for a public Amazon EC2 instance](#ds-vpc-public-security-group). + **Auto-assign Public IP** — Choose **Enable**. + **Auto-assign IPv6 IP** — Choose **Enable**. + **Firewall (security groups)** Choose **Select an existing security group**.— + **Common security groups** — Choose an existing security group, such as the **example-dual-stack-securitygroup** created in [Step 2: Create a VPC security group for a public Amazon EC2 instance](#ds-vpc-public-security-group). Make sure that the security group that you choose includes inbound rules for Secure Shell (SSH) and HTTP access. ## Step 6: Create a cluster in dual-stack mode In this step, you create a DB cluster that runs in dual-stack mode. **\$1\$1\$1 Note: this section needs editing once the IPv6 updates have been made to the console \$1\$1\$1** **To create a cluster in dual-stack mode** 1. Sign in to the AWS Management Console, and open the Amazon DocumentDB console at [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb). 1. In the upper-right corner of the console, choose the AWS Region where you want to create the DocumentDB cluster. This example uses the US East (Ohio) Region. 1. In the navigation pane, choose **Clusters**. 1. On the **Clusters** list page, choose **Create**. 1. On the **Create Amazon DocumentDB cluster** page, make sure that the **Instance-based cluster** option is chosen. 1. In the **Connectivity** section, under **Network type**, choose **Dual-stack mode**. ![\[Network type section in the console with Dual-stack mode selected.\]](http://docs.aws.amazon.com/documentdb/latest/developerguide/images/nw-type-dual-stack.png) 1. At the bottom of the page, switch on **Show advanced settings**. 1. In the **Network settings** section, set these values: + **Virtual private cloud (VPC)** — Choose an existing VPC with both public and private subnets, such as **vpc-example-dual-stack** (vpc-*identifier*) created in [Step 1: Create a VPC with private and public subnets](#ds-vpc-private-public-subnets). The VPC must have subnets in different Availability Zones. + **Subnet group** — Choose a subnet group for the VPC, such as **example-dual-stack-cluster-subnet-group** created in [Step 4: Create a subnet group](#ds-vpc-subnet-group). + **Public access** — Choose **No**. + **VPC security group (firewall)** — Select **Choose existing**. + **Existing VPC security groups** — Choose an existing VPC security group that is configured for private access, such as **example-dual-stack-cluster-securitygroup** created in [Step 3: Create a VPC security group for a private cluster](#ds-vpc-private-security-group). Remove other security groups, such as the default security group, by choosing the **X** associated with each. + **Availability Zone** — Choose the Availability Zone you created in Step 1. Example: **us-west-2a**. To avoid cross-AZ traffic, make sure the cluster and the EC2 instance are in the same Availability Zone. 1. For the remaining sections, specify your cluster settings. For information about each setting, see [Creating an Amazon DocumentDB cluster](db-cluster-create.md). ## Step 7: Connect to your Amazon EC2 instance and DB cluster After you create your Amazon EC2 instance and DocumentDB cluster in dual-stack mode, you can connect to each one using the IPv6 protocol. To connect to an EC2 instance using the IPv6 protocol, follow the instructions in [Connect your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect.html) in the *Amazon Elastic Compute Cloud User Guide*. To connect to your DocumentDB cluster from the EC2 instance, follow the instructions in [Step 5: Install the MongoDB Shell](connect-ec2-manual.md#manual-connect-ec2.install-mongo-shell), in the Connect Amazon EC2 manually topic (and continue with the subsequent Step 6 and Step 7 in the same procedure). ## Delete the VPC You can delete a VPC and the other resources that are used within it, if they are no longer needed. **Note** If you added resources in the VPC that you created in this topic, you might need to delete these before you can delete the VPC. For example, these resources might include Amazon EC2 instances or DocumentDB clusters. For more information, see [Delete your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/delete-vpc.html) in the *Amazon VPC User Guide*. **To delete a VPC and related resources** 1. Delete the subnet group: 1. Sign in to the AWS Management Console, and open the Amazon DocumentDB console at [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb). 1. In the navigation pane, choose **Subnet groups**. 1. Select the subnet group you want to delete, such as **example-dual-stack-cluster-subnet-group**. 1. Choose **Delete**, and then choose **Delete** in the confirmation window. 1. Note the VPC ID: 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Your VPCs**. 1. In the list, identify the VPC that you created, such as **vpc-example-dual-stack**. 1. Note the **VPC ID** of the VPC that you created. You need the VPC ID in later steps. 1. Delete the security groups: 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Security Groups**. 1. Select the security group for the Amazon DocumentDB cluster, such as **example-dual-stack-securitygroup**. 1. For **Actions**, choose **Delete security groups**, and then choose **Delete** on the confirmation dialog. 1. Back on the **Security Groups** page, select the security group for the Amazon EC2 instance, such as **example-securitygroup**. 1. For **Actions**, choose **Delete security groups**, and then choose **Delete** on the confirmation dialog. 1. Delete the NAT gateway: 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Security Groups**. 1. Select the NAT gateway of the VPC that you created. Use the VPC ID to identify the correct NAT gateway. 1. For **Actions**, choose **Delete NAT gateway**. 1. On the confirmation dialog, enter **delete**, and then choose **Delete**. 1. Delete the VPC: 1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com//vpc). 1. Choose **VPC Dashboard**, and then choose **Your VPCs**. 1. Select the VPC you want to delete, such as **vpc-example-dual-stack**. 1. For **Actions**, choose Delete VPC. The confirmation page shows other resources that are associated with the VPC that will also be deleted, including the subnets associated with it. 1. On the confirmation dialog, enter **delete**, and then choose **Delete**. 1. Release the elastic IP address: 1. Open the EC2 console at [https://console.aws.amazon.com/ec2](https://console.aws.amazon.com//ec2). 1. Choose **EC2 Dashboard**, and then choose **Elastic IPs**. 1. Select the Elastic IP address that you want to release. 1. For **Actions**, choose **Release Elastic IP addresses**. 1. On the confirmation dialog, choose **Release**.