# Amazon VPC and Amazon RDS
Amazon Virtual Private Cloud (Amazon VPC) makes it possible for you to launch AWS resources, such as Amazon RDS DB 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 DB instance in a VPC.
Accounts have a default VPC. All new DB instances are created in the default VPC unless you specify otherwise.
**Topics**
+ [
# Working with a DB instance in a VPC
](USER_VPC.WorkingWithRDSInstanceinaVPC.md)
+ [
# Updating the VPC for a DB instance
](USER_VPC.VPC2VPC.md)
+ [
# Scenarios for accessing a DB instance in a VPC
](USER_VPC.Scenarios.md)
+ [
# Tutorial: Create a VPC for use with a DB instance (IPv4 only)
](CHAP_Tutorials.WebServerDB.CreateVPC.md)
+ [
# Tutorial: Create a VPC for use with a DB instance (dual-stack mode)
](CHAP_Tutorials.CreateVPCDualStack.md)
+ [
# Moving a DB instance not in a VPC into a VPC
](USER_VPC.Non-VPC2VPC.md)
Following, you can find a discussion about VPC functionality relevant to Amazon RDS DB instances. For more information about Amazon VPC, see [Amazon VPC Getting Started Guide](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) and [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/).
# Working with a DB instance in a VPC
Your DB instance 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 RDS DB instance 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 a list of scenarios involving Amazon RDS DB instances in a VPC and outside of a VPC, see [Scenarios for accessing a DB instance in a VPC](USER_VPC.Scenarios.md).
**Topics**
+ [
## Working with a DB instance in a VPC
](#Overview.RDSVPC.Create)
+ [
## VPC encryption control
](#USER_VPC.EncryptionControl)
+ [
## Working with DB subnet groups
](#USER_VPC.Subnets)
+ [
## Shared subnets
](#USER_VPC.Shared_subnets)
+ [
## Amazon RDS IP addressing
](#USER_VPC.IP_addressing)
+ [
## Hiding a DB instance in a VPC from the internet
](#USER_VPC.Hiding)
+ [
## Creating a DB instance in a VPC
](#USER_VPC.InstanceInVPC)
In the following tutorials, you can learn to create a VPC that you can use for a common Amazon RDS scenario:
+ [Tutorial: Create a VPC for use with a DB instance (IPv4 only)](CHAP_Tutorials.WebServerDB.CreateVPC.md)
+ [Tutorial: Create a VPC for use with a DB instance (dual-stack mode)](CHAP_Tutorials.CreateVPCDualStack.md)
## Working with a DB instance in a VPC
Here are some tips on working with a DB instance 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 DB instance. A *subnet* is a segment of a VPC's IP address range that you can specify and that you can use to group DB instances based on your security and operational needs.
For Multi-AZ deployments, defining a subnet for two or more Availability Zones in an AWS Region allows Amazon RDS to create a new standby in another Availability Zone as needed. Make sure to do this even for Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.
**Note**
The DB subnet group for a Local Zone can have only one subnet.
+ If you want your DB instance 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 DB subnet group that you create. You create a DB subnet group by specifying the subnets you created. Amazon RDS chooses a subnet and an IP address within that subnet group to associate with your DB instance. The DB instance uses the Availability Zone that contains the subnet.
+ Your VPC must have a VPC security group that allows access to the DB instance.
For more information, see [Scenarios for accessing a DB instance in a VPC](USER_VPC.Scenarios.md).
+ The CIDR blocks in each of your subnets must be large enough to accommodate spare IP addresses for Amazon RDS 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 DB instance class.
If you choose to have your DB instance in a dedicated VPC where the instance tenancy attribute is set to dedicated, the DB instance class of your DB instance 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 DB instance class. For information about instance tenancy in a VPC, see [Dedicated instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.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/purchasing-options/dedicated-instances/) on the Amazon EC2 pricing page.
**Note**
When you set the instance tenancy attribute to dedicated for a DB instance, it doesn't guarantee that the DB instance will run on a dedicated host.
+ When an option group is assigned to a DB instance, it's associated with the DB instance's VPC. This linkage means that you can't use the option group assigned to a DB instance if you attempt to restore the DB instance into a different VPC.
+ If you restore a DB instance into a different VPC, make sure to either assign the default option group to the DB instance, assign an option group that is linked to that VPC, or create a new option group and assign it to the DB instance. With persistent or permanent options, such as Oracle TDE, you must create a new option group that includes the persistent or permanent option when restoring a DB instance into a different VPC.
## VPC encryption control
VPC encryption controls allow you to enforce encryption-in-transit for all network traffic within your VPCs. Use encryption control to meet regulatory compliance requirements by ensuring that only encryption-capable Nitro-based hardware can be provisioned in designated VPCs. Encryption control also catches compatibility issues at API request time rather than during provisioning. Your existing workloads continue operating and only new incompatible requests are blocked.
Set your VPC encryption controls by setting the VPC control mode to :
+ *disabled* (default)
+ *monitor*
+ *enforced*
To check the current control mode for your VPC, use the AWS Management Console or [DescribeVpcs](https://docs.aws.amazon.com//AWSEC2/latest/APIReference/API_DescribeVpcs.html) CLI or API command.
If your VPC enforces encryption, you can only provision Nitro-based DB instances that support encryption in transit in that VPC. For more information see, [DB instance class types](Concepts.DBInstanceClass.Types.md). For information about Nitro instances, see [Instances built on the AWS Nitro System](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) in the *Amazon EC2 User Guide*.
**Note**
If you try to provision incompatible DB instances in an encryption-enforced VPC, Amazon RDS returns a `VpcEncryptionControlViolationException` exception.
## Working with DB 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 *DB subnet group* is a collection of subnets (typically private) that you create in a VPC and that you then designate for your DB instances. By using a DB subnet group, you can specify a particular VPC when creating DB instances using the AWS CLI or RDS API. If you use the console, you can choose the VPC and subnet groups you want to use.
Each DB subnet group should have subnets in at least two Availability Zones in a given AWS Region. When creating a DB instance in a VPC, you choose a DB subnet group for it. From the DB subnet group, Amazon RDS chooses a subnet and an IP address within that subnet to associate with the DB instance. The DB uses the Availability Zone that contains the subnet. Amazon RDS always assigns an IP address from a subnet that has free IP address space.
If the primary DB instance of a Multi-AZ deployment fails, Amazon RDS can promote the corresponding standby and later create a new standby using an IP address of the subnet in one of the other Availability Zones.
The subnets in a DB subnet group are either public or private. The subnets are public or private, depending on the configuration that you set for their network access control lists (network ACLs) and routing tables. For a DB instance to be publicly accessible, all of the subnets in its DB subnet group must be public. If a subnet that's associated with a publicly accessible DB instance changes from public to private, it can affect DB instance availability.
To create a DB subnet group that supports dual-stack mode, make sure that each subnet that you add to the DB subnet group has an Internet Protocol version 6 (IPv6) CIDR block associated with it. For more information, see [Amazon RDS IP addressing](#USER_VPC.IP_addressing) and [Migrating to IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) in the *Amazon VPC User Guide.*
**Note**
The DB subnet group for a Local Zone can have only one subnet.
When Amazon RDS creates a DB instance in a VPC, it assigns a network interface to your DB instance by using an IP address from your DB subnet group. However, we strongly recommend that you use the Domain Name System (DNS) name to connect to your DB instance. We recommend this because the underlying IP address changes during failover.
**Note**
For each DB instance that you run in a VPC, make sure to reserve at least one address in each subnet in the DB subnet group for use by Amazon RDS for recovery actions.
## Shared subnets
You can create a DB instance in a shared VPC.
Some considerations to keep in mind while using shared VPCs:
+ You can move a DB instance 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 DB instance.
+ Owners and participants in a shared VPC can access the database by using SQL queries. However, only the creator of a resource can make any API calls on the resource.
## Amazon RDS IP addressing
IP addresses enable resources in your VPC to communicate with each other, and with resources over the internet. Amazon RDS supports both IPv4 and IPv6 addressing protocols. By default, Amazon RDS 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 DB instances in your subnet.
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 RDS 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 RDS resources to simplify your network configuration.
**Topics**
+ [
### IPv4 addresses
](#USER_VPC.IP_addressing.IPv4)
+ [
### IPv6 addresses
](#USER_VPC.IP_addressing.IPv6)
+ [
### Dual-stack mode
](#USER_VPC.IP_addressing.dual-stack-mode)
### 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 *DB subnet group* defines the range of IP addresses in this CIDR block that a DB instance 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 DB instance and other resources, such as Amazon EC2 instances, in the same VPC. Each DB instance has a private IP address for communication in the VPC.
A public IP address is an IPv4 address that's reachable from the internet. You can use public addresses for communication between your DB instance and resources on the internet, such as a SQL client. You control whether your DB instance receives a public IP address.
Amazon RDS uses Public Elastic IPv4 addresses from EC2's public IPv4 address pool for publicly accessible database instances. These IP addresses are visible in your AWS account when using the `describe-addresses` CLI, API or viewing the Elastic IPs (EIP) section in the AWS Management Console. Each RDS-managed IP address is marked with a `service_managed` attribute set to `"rds"`.
While these IPs are visible in your account, they remain fully managed by Amazon RDS and cannot be modified or released. Amazon RDS releases IPs back into the public IPv4 address pool when no longer in use.
CloudTrail logs API calls related to RDS's EIP, such as the `AllocateAddress`. These API calls are invoked by the Service Principal `rds.amazonaws.com`.
**Note**
IPs allocated by Amazon RDS do not count against your account's EIP limits.
For a tutorial that shows you how to create a VPC with only private IPv4 addresses that you can use for a common Amazon RDS scenario, see [Tutorial: Create a VPC for use with a DB instance (IPv4 only)](CHAP_Tutorials.WebServerDB.CreateVPC.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.
+ RDS security groups used by the DB instance 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 DB instance 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 VPC User Guide*.
### Dual-stack mode
A DB instance runs in dual-stack mode when it can communicate over both IPv4 and IPv6 addressing protocols. Resources can then communicate with the DB instance using either IPv4, IPv6, or both protocols. Private dual-stack mode DB instances have IPv6 endpoints that RDS restricts to VPC access only, ensuring your IPv6 endpoints remain private. Public dual-stack mode DB instances provide both IPv4 and IPv6 endpoints that you can access from the internet.
**Topics**
+ [
#### Dual-stack mode and DB subnet groups
](#USER_VPC.IP_addressing.dual-stack-db-subnet-groups)
+ [
#### Working with dual-stack mode DB instances
](#USER_VPC.IP_addressing.dual-stack-working-with)
+ [
#### Modifying IPv4-only DB instances to use dual-stack mode
](#USER_VPC.IP_addressing.dual-stack-modifying-ipv4)
+ [
#### Region and version availability
](#USER_VPC.IP_addressing.RegionVersionAvailability)
+ [
#### Limitations for dual-stack network DB instances
](#USER_VPC.IP_addressing.dual-stack-limitations)
For a tutorial that shows you how to create a VPC with both IPv4 and IPv6 addresses that you can use for a common Amazon RDS scenario, see [Tutorial: Create a VPC for use with a DB instance (dual-stack mode)](CHAP_Tutorials.CreateVPCDualStack.md).
#### Dual-stack mode and DB subnet groups
To use dual-stack mode, make sure that each subnet in the DB subnet group that you associate with the DB instance has an IPv6 CIDR block associated with it. You can create a new DB subnet group or modify an existing DB subnet group to meet this requirement. After a DB instance is in dual-stack mode, clients can connect to it normally. Make sure that client security firewalls and RDS DB instance security groups are accurately configured to allow traffic over IPv6. To connect, clients use the DB instance's endpoint. Client applications can specify which protocol is preferred when connecting to a database. In dual-stack mode, the DB instance detects the client's preferred network protocol, either IPv4 or IPv6, and uses that protocol for the connection.
If a DB subnet group stops supporting dual-stack mode because of subnet deletion or CIDR disassociation, there's a risk of an incompatible network state for DB instances that are associated with the DB subnet group. Also, you can't use the DB subnet group when you create a new dual-stack mode DB instance.
To determine whether a DB subnet group supports dual-stack mode by using the AWS Management Console, view the **Network type** on the details page of the DB subnet group. To determine whether a DB subnet group supports dual-stack mode by using the AWS CLI, run the [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html) command and view `SupportedNetworkTypes` in the output.
Read replicas are treated as independent DB instances and can have a network type that's different from the primary DB instance. If you change the network type of a read replica's primary DB instance, the read replica isn't affected. When you are restoring a DB instance, you can restore it to any network type that's supported.
#### Working with dual-stack mode DB instances
When you create or modify a DB instance, you can specify dual-stack mode to allow your resources to communicate with your DB instance over IPv4, IPv6, or both.
When you use the AWS Management Console to create or modify a DB instance, 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/AmazonRDS/latest/UserGuide/images/dual-stack-mode.png)
When you use the AWS CLI to create or modify a DB instance, set the `--network-type` option to `DUAL` to use dual-stack mode. When you use the RDS API to create or modify a DB instance, set the `NetworkType` parameter to `DUAL` to use dual-stack mode. When you are modifying the network type of a DB instance, downtime is possible. If dual-stack mode isn't supported by the specified DB engine version or DB subnet group, the `NetworkTypeNotSupported` error is returned.
For more information about creating a DB instance, see [Creating an Amazon RDS DB instance](USER_CreateDBInstance.md). For more information about modifying a DB instance, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md).
To determine whether a DB instance is in dual-stack mode by using the console, view the **Network type** on the **Connectivity & security** tab for the DB instance.
#### Modifying IPv4-only DB instances to use dual-stack mode
You can modify an IPv4-only DB instance to use dual-stack mode. To do so, change the network type of the DB instance. The modification might result in downtime.
It is recommended that you change the network type of your Amazon RDS DB instances during a maintenance window. Currently, setting the network type of new instances to dual-stack mode isn't supported. You can set network type manually by using the `modify-db-instance` command.
Before modifying a DB instance to use dual-stack mode, make sure that its DB subnet group supports dual-stack mode. If the DB subnet group associated with the DB instance doesn't support dual-stack mode, specify a different DB subnet group that supports it when you modify the DB instance. Modifying the DB subnet group of a DB instance can cause downtime.
If you modify the DB subnet group of a DB instance before you change the DB instance to use dual-stack mode, make sure that the DB subnet group is valid for the DB instance before and after the change.
For RDS for PostgreSQL, RDS for MySQL, RDS for Oracle, and RDS for MariaDB Single-AZ instances, we recommend that you run the [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) command with only the `--network-type` parameter set to `DUAL` to change the network to dual-stack mode. Adding other parameters along with the `--network-type` parameter 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 `modify-db-instance` request with other parameters.
Network type modifications for RDS for PostgreSQL, RDS for MySQL, RDS for Oracle, and RDS for MariaDB Multi-AZ DB instances cause a brief downtime and trigger a failover if you only use the `--network-type` parameter or if you combine parameters in a modify-db-instance command.
Network type modifications on RDS for SQL Server Single-AZ or Multi-AZ DB instances cause downtime if you only use the `--network-type` parameter or if you combine parameters in a `modify-db-instance` command. Network type modifications cause failover in an SQL Server Multi-AZ instance.
If you can't connect to the DB instance 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.
When you modify a DB instance to use dual-stack mode, there can't be a pending change from a Single-AZ deployment to a Multi-AZ deployment, or from a Multi-AZ deployment to a Single-AZ deployment.
**To modify an IPv4-only DB instance to use dual-stack mode**
1. Modify a DB subnet group to support dual-stack mode, or create a DB subnet group that supports dual-stack mode:
1. Associate an IPv6 CIDR block with your VPC.
For instructions, see [ Add an IPv6 CIDR block to your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#vpc-associate-ipv6-cidr) in the *Amazon VPC User Guide*.
1. Attach the IPv6 CIDR block to all of the subnets in your the DB subnet group.
For instructions, see [ Add an IPv6 CIDR block to your subnet](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html#subnet-associate-ipv6-cidr) in the *Amazon VPC User Guide*.
1. Confirm that the DB subnet group supports dual-stack mode.
If you are using the AWS Management Console, select the DB subnet group, and make sure that the **Supported network types** value is **Dual, IPv4**.
If you are using the AWS CLI, run the [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html) command, and make sure that the `SupportedNetworkType` value for the DB instance is `Dual, IPv4`.
1. Modify the security group associated with the DB instance 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 VPC User Guide*.
1. Modify the DB instance 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/AmazonRDS/latest/UserGuide/images/dual-stack-mode.png)
+ **DB subnet group** – The DB 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 DB 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 rds modify-db-instance --db-instance-identifier my-instance --network-type "DUAL"
```
1. Confirm that the DB instance supports dual-stack mode.
If you are using the console, choose the **Connectivity & security** tab for the DB instance. On that tab, make sure that the **Network type** value is **Dual-stack mode**.
If you are using the AWS CLI, run the [ describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) command, and make sure that the `NetworkType` value for the DB instance is `dual`.
Run the `dig` command on the DB instance endpoint to identify the IPv6 address associated with it.
```
dig db-instance-endpoint AAAA
```
Use the DB instance endpoint, not the IPv6 address, to connect to the DB instance.
#### Region and version availability
Feature availability and support varies across specific versions of each database engine, and across AWS Regions. For more information on version and Region availability with dual-stack mode, see [Supported Regions and DB engines for dual-stack mode in Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.DualStackMode.md).
#### Limitations for dual-stack network DB instances
The following limitations apply to dual-stack network DB instances:
+ DB instances 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 RDS doesn't support native IPv6 subnets.
+ For RDS for SQL Server, dual-stack mode DB instances that use Always On AGs availability group listener endpoints only present IPv4 addresses.
+ You can't use RDS Proxy with dual-stack mode DB instances.
+ You can't use dual-stack mode with RDS on AWS Outposts DB instances.
+ You can't use dual-stack mode with DB instances in a Local Zone.
## Hiding a DB instance in a VPC from the internet
One common Amazon RDS scenario is to have a VPC in which you have an Amazon EC2 instance with a public-facing web application and a DB instance with a database that isn't publicly accessible. For example, you can create a VPC that has a public subnet and a private subnet. EC2 instances that function as web servers can be deployed in the public subnet. The DB instances are deployed in the private subnet. In such a deployment, only the web servers have access to the DB instances. For an illustration of this scenario, see [A DB instance in a VPC accessed by an Amazon EC2 instance in the same VPC](USER_VPC.Scenarios.md#USER_VPC.Scenario1).
When you launch a DB instance inside a VPC, the DB instance has a private IP address for traffic inside the VPC. This private IP address isn't publicly accessible. You can use the **Public access** option to designate whether the DB instance also has a public IP address in addition to the private IP address. If the DB instance is designated as publicly accessible, its DNS endpoint resolves to the private IP address from within the VPC. It resolves to the public IP address from outside of the VPC. Access to the DB instance is ultimately controlled by the security group it uses. That public access is not permitted if the security group assigned to the DB instance doesn't include inbound rules that permit it. In addition, for a DB instance to be publicly accessible, the subnets in its DB subnet group must have an internet gateway. For more information, see [Can't connect to Amazon RDS DB instance](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting)
You can modify a DB instance to turn on or off public accessibility by modifying the **Public access** option. The following illustration shows the **Public access** option in the **Additional connectivity configuration** section. To set the option, open the **Additional connectivity configuration** section in the **Connectivity** section.
![\[Set your database Public access option in the Additional connectivity configuration section to No.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/VPC-example4.png)
For information about modifying a DB instance to set the **Public access** option, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md).
## Creating a DB instance in a VPC
The following procedures help you create a DB instance in a VPC. To use the default VPC, you can begin with step 2, and use the VPC and DB subnet group have already been created for you. If you want to create an additional VPC, you can create a new VPC.
**Note**
If you want your DB instance 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 information for a VPC instance, see [Updating DNS support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html).
Follow these steps to create a DB instance in a VPC:
+ [Step 1: Create a VPC](#USER_VPC.CreatingVPC)
+ [Step 2: Create a DB subnet group](#USER_VPC.CreateDBSubnetGroup)
+ [Step 3: Create a VPC security group](#USER_VPC.CreateVPCSecurityGroup)
+ [Step 4: Create a DB instance in the VPC](#USER_VPC.CreateDBInstanceInVPC)
### Step 1: Create a VPC
Create a VPC with subnets in at least two Availability Zones. You use these subnets when you create a DB 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 a VPC with private and public subnets](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.VPCAndSubnets), or see [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) in the *Amazon VPC User Guide*.
### Step 2: Create a DB subnet group
A DB subnet group is a collection of subnets (typically private) that you create for a VPC and that you then designate for your DB instances. A DB subnet group allows you to specify a particular VPC when you create DB instances using the AWS CLI or RDS API. If you use the console, you can just choose the VPC and subnets you want to use. Each DB subnet group must have at least one subnet in at least two Availability Zones in the AWS Region. As a best practice, each DB subnet group should have at least one subnet for every Availability Zone in the AWS Region.
For Multi-AZ deployments, defining a subnet for all Availability Zones in an AWS Region enables Amazon RDS to create a new standby replica in another Availability Zone if necessary. You can follow this best practice even for Single-AZ deployments, because you might convert them to Multi-AZ deployments in the future.
For a DB instance to be publicly accessible, the subnets in the DB subnet group must have an internet gateway. For more information about internet gateways for subnets, see [Connect to the internet using an internet gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) in the *Amazon VPC User Guide*.
**Note**
The DB subnet group for a Local Zone can have only one subnet.
When you create a DB instance in a VPC, you can choose a DB subnet group. Amazon RDS chooses a subnet and an IP address within that subnet to associate with your DB instance. If no DB subnet groups exist, Amazon RDS creates a default subnet group when you create a DB instance. Amazon RDS creates and associates an Elastic Network Interface to your DB instance with that IP address. The DB instance uses the Availability Zone that contains the subnet.
For Multi-AZ deployments, defining a subnet for two or more Availability Zones in an AWS Region allows Amazon RDS to create a new standby in another Availability Zone should the need arise. You need to do this even For Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.
In this step, you create a DB subnet group and add the subnets that you created for your VPC.
**To create a DB subnet group**
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Subnet groups**.
1. Choose **Create DB Subnet Group**.
1. For **Name**, type the name of your DB subnet group.
1. For **Description**, type a description for your DB subnet group.
1. For **VPC**, choose the default VPC or the VPC that you created.
1. In the **Add subnets** section, choose the Availability Zones that include the subnets from **Availability Zones**, and then choose the subnets from **Subnets**.
![\[Create a DB subnet group.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/RDSVPC101.png)
**Note**
If you have enabled a Local Zone, you can choose an Availability Zone group on the **Create DB subnet group** page. In this case, choose the **Availability Zone group**, **Availability Zones**, and **Subnets**.
1. Choose **Create**.
Your new DB subnet group appears in the DB subnet groups list on the RDS console. You can choose the DB 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 DB instance, you can create a VPC security group to associate with your DB instance. If you don't create a VPC security group, you can use the default security group when you create a DB instance. For instructions on how to create a security group for your DB instance, see [Create a VPC security group for a private DB instance](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.SecurityGroupDB), or see [Control traffic to resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) in the *Amazon VPC User Guide*.
### Step 4: Create a DB instance in the VPC
In this step, you create a DB instance and use the VPC name, the DB subnet group, and the VPC security group you created in the previous steps.
**Note**
If you want your DB instance in the VPC to be publicly accessible, you must enable the VPC attributes *DNS hostnames* and *DNS resolution*. For more information, see [DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) in the *Amazon VPC User Guide*.
For details on how to create a DB instance, see [Creating an Amazon RDS DB instance](USER_CreateDBInstance.md).
When prompted in the **Connectivity** section, enter the VPC name, the DB subnet group, and the VPC security group.
# Updating the VPC for a DB instance
You can use the AWS Management Console to move your DB instance to a different VPC.
For information about modifying a DB instance, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md). In the **Connectivity** section of the modify page, shown following, enter the new DB subnet group for **DB subnet group**. The new subnet group must be a subnet group in a new VPC.
![\[Modify the DB instance subnet group.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/EC2-VPC.png)
You can't change the VPC for a DB instance if the following conditions apply:
+ The DB instance is in multiple Availability Zones. You can convert the DB instance to a single Availability Zone, move it to a new VPC, and then convert it back to a Multi-AZ DB instance. For more information, see [Configuring and managing a Multi-AZ deployment for Amazon RDS](Concepts.MultiAZ.md).
+ The DB instance has one or more read replicas. You can remove the read replicas, move the DB instance to a new VPC, and then add the read replicas again. For more information, see [Working with DB instance read replicas](USER_ReadRepl.md).
+ The DB instance is a read replica. You can promote the read replica, and then move the standalone DB instance to a new VPC. For more information, see [Promoting a read replica to be a standalone DB instance](USER_ReadRepl.Promote.md).
+ The subnet group in the target VPC doesn't have subnets in the DB instance's the Availability Zone. You can add subnets in the DB instance's Availability Zone to the DB subnet group, and then move the DB instance to the new VPC. For more information, see [Working with DB subnet groups](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Subnets).
# Scenarios for accessing a DB instance in a VPC
Amazon RDS supports the following scenarios for accessing a DB instance in a VPC:
+ [An Amazon EC2 instance in the same VPC](#USER_VPC.Scenario1)
+ [An EC2 instance in a different VPC](#USER_VPC.Scenario3)
+ [A client application through the internet](#USER_VPC.Scenario4)
+ [A private network](#USER_VPC.NotPublic)
## A DB instance in a VPC accessed by an Amazon EC2 instance in the same VPC
A common use of a DB instance in a VPC is to share data with an application server that is running in an Amazon EC2 instance in the same VPC.
The following diagram shows this scenario.
![\[VPC scenario with a public web server and a private database.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/con-VPC-sec-grp.png)
The simplest way to manage access between EC2 instances and DB instances in the same VPC is to do the following:
+ Create a VPC security group for your DB instances to be in. This security group can be used to restrict access to the DB instances. 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 DB instance when you created it and an IP address you use to access the DB instance 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 DB instances 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 DB instances.
There is an additional public and private subnet in a separate Availability Zone. An RDS DB subnet group requires a subnet in at least two Availability Zones. The additional subnet makes it easy to switch to a Multi-AZ DB instance deployment in the future.
For a tutorial that shows you how to create a VPC with both public and private subnets for this scenario, see [Tutorial: Create a VPC for use with a DB instance (IPv4 only)](CHAP_Tutorials.WebServerDB.CreateVPC.md).
**Tip**
You can set up network connectivity between an Amazon EC2 instance and a DB instance automatically when you create the DB instance. For more information, see [Configure automatic network connectivity with an EC2 instance](USER_CreateDBInstance.md#USER_CreateDBInstance.Prerequisites.VPC.Automatic).
**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, choose **Security groups**.
1. Choose or create a security group for which you want to allow access to members of another security group. In the preceding scenario, this is the security group that you use for your DB instances. 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 DB instance, such as **MYSQL/Aurora**.
1. In the **Source** box, 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** box. 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.
![\[Adding a security group to another security group's rules.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/con-vpc-add-sg-rule.png)
For more information about connecting to the DB instance from your EC2 instance, see [Connecting to an Amazon RDS DB instance](CHAP_CommonTasks.Connect.md) .
## A DB instance in a VPC accessed by an EC2 instance in a different VPC
When your DB instances is in a different VPC from the EC2 instance you are using to access it, you can use VPC peering to access the DB instance.
The following diagram shows this scenario.
![\[A DB instance in a VPC accessed by an Amazon EC2 instance in a different VPC.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/RDSVPC2EC2VPC.png)
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*.
## A DB instance in a VPC accessed by a client application through the internet
To access a DB instances in a VPC from a client application through the internet, you configure a VPC with a single public subnet, and an internet gateway to enable communication over the internet.
The following diagram shows this scenario.
![\[A DB instance in a VPC accessed by a client application through the internet.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/GS-VPC-network.png)
We recommend the following configuration:
+ A VPC of size /16 (for example CIDR: 10.0.0.0/16). This size provides 65,536 private IP addresses.
+ A subnet of size /24 (for example CIDR: 10.0.0.0/24). This size provides 256 private IP addresses.
+ An Amazon RDS DB instance that is associated with the VPC and the subnet. Amazon RDS assigns an IP address within the subnet to your DB instance.
+ An internet gateway which connects the VPC to the internet and to other AWS products.
+ A security group associated with the DB instance. The security group's inbound rules allow your client application to access to your DB instance.
For information about creating a DB instances in a VPC, see [Creating a DB instance in a VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.InstanceInVPC).
## A DB instance in a VPC accessed by a private network
If your DB instance isn't publicly accessible, you have the following options for accessing it from a private network:
+ An AWS Site-to-Site VPN connection. For more information, see [What is AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ An Direct Connect connection. For more information, see [What is Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
+ An AWS Client VPN connection. For more information, see [What is AWS Client VPN?](https://docs.aws.amazon.com//vpn/latest/clientvpn-admin/what-is.html)
The following diagram shows a scenario with an AWS Site-to-Site VPN connection.
![\[DB instances in a VPC accessed by a private network.\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/site-to-site-vpn-connection.png)
For more information, see [Internetwork traffic privacy](inter-network-traffic-privacy.md).
# Tutorial: Create a VPC for use with a DB instance (IPv4 only)
A common scenario includes a DB instance in a virtual private cloud (VPC) based on the Amazon VPC service. This VPC shares data with a web server that is running in the same VPC. In this tutorial, you create the VPC for this scenario.
The following diagram shows this scenario. For information about other scenarios, see [Scenarios for accessing a DB instance in a VPC](USER_VPC.Scenarios.md).
![\[Single VPC scenario\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/con-VPC-sec-grp.png)
Your DB instance needs to be available only to your web server, and not to the public internet. Thus, you create a VPC with both public and private subnets. The web server is hosted in the public subnet, so that it can reach the public internet. The DB instance is hosted in a private subnet. The web server can connect to the DB instance because it is hosted within the same VPC. But the DB instance isn't available to the public internet, providing greater security.
This tutorial configures an additional public and private subnet in a separate Availability Zone. These subnets aren't used by the tutorial. An RDS DB subnet group requires a subnet in at least two Availability Zones. The additional subnet makes it easier to switch to a Multi-AZ DB instance deployment in the future.
This tutorial describes configuring a VPC for Amazon RDS DB instances. For a tutorial that shows you how to create a web server for this VPC scenario, see [Tutorial: Create a web server and an Amazon RDS DB instance](TUT_WebAppWithRDS.md). For more information about Amazon VPC, see [Amazon VPC Getting Started Guide](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) and [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/).
**Tip**
You can set up network connectivity between an Amazon EC2 instance and a DB instance automatically when you create the DB instance. The network configuration is similar to the one described in this tutorial. For more information, see [Configure automatic network connectivity with an EC2 instance](USER_CreateDBInstance.md#USER_CreateDBInstance.Prerequisites.VPC.Automatic).
## 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** – **tutorial**
+ **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 subnet** – **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.
**Note**
Amazon RDS requires at least two subnets in two different Availability Zones to support Multi-AZ DB instance deployments. This tutorial creates a Single-AZ deployment, but the requirement makes it easier to convert to a Multi-AZ DB instance deployment in the future.
1. Choose **Create VPC**.
## Create a VPC security group for a public web server
Next, you 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:** **tutorial-securitygroup**
+ **Description:** **Tutorial Security Group**
+ **VPC:** Choose the VPC that you created earlier, for example: **vpc-*identifier* (tutorial-vpc)**
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. If you do this, you can connect to your Amazon EC2 instance to install the web server and other utilities. You also connect to your EC2 instance to upload content for your web server.
+ **Type:** **SSH**
+ **Source:** The IP address or range 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 web server:
+ **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 this tutorial.
## Create a VPC security group for a private DB instance
To keep your DB instance private, create a second security group for private access. To connect to private DB instances in your VPC, you add inbound rules to your VPC security group that allow traffic from your web server 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:** **tutorial-db-securitygroup**
+ **Description:** **Tutorial DB Instance Security Group**
+ **VPC:** Choose the VPC that you created earlier, for example: **vpc-*identifier* (tutorial-vpc)**
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 MySQL traffic on port 3306 from your Amazon EC2 instance. If you do this, you can connect from your web server to your DB instance. By doing so, you can store and retrieve data from your web application to your database.
+ **Type:** **MySQL/Aurora**
+ **Source:** The identifier of the **tutorial-securitygroup** security group that you created previously in this tutorial, for example: **sg-9edd5cfb**.
1. Choose **Create security group** to create the security group.
## Create a DB subnet group
A *DB subnet group* is a collection of subnets that you create in a VPC and that you then designate for your DB instances. A DB subnet group makes it possible for you to specify a particular VPC when creating DB instances.
**To create a DB 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 named **tutorial-subnet-private1-us-west-2a** and **tutorial-subnet-private2-us-west-2b**.
You need the subnet IDs when you create your DB subnet group.
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
Make sure that you connect to the Amazon RDS console, not to the Amazon VPC console.
1. In the navigation pane, choose **Subnet groups**.
1. Choose **Create DB subnet group**.
1. On the **Create DB subnet group** page, set these values in **Subnet group details**:
+ **Name:** **tutorial-db-subnet-group**
+ **Description:** **Tutorial DB Subnet Group**
+ **VPC:** **tutorial-vpc (vpc-*identifier*)**
1. In the **Add subnets** section, choose the **Availability Zones** and **Subnets**.
For this tutorial, choose **us-west-2a** and **us-west-2b** for the **Availability Zones**. For **Subnets**, choose the private subnets you identified in the previous step.
1. Choose **Create**.
Your new DB subnet group appears in the DB subnet groups list on the RDS console. You can choose the DB subnet group to see details in the details pane at the bottom of the window. These details include all of the subnets associated with the group.
**Note**
If you created this VPC to complete [Tutorial: Create a web server and an Amazon RDS DB instance](TUT_WebAppWithRDS.md), create the DB instance by following the instructions in [Create an Amazon RDS DB instance](CHAP_Tutorials.WebServerDB.CreateDBInstance.md).
## Deleting the VPC
After you create the VPC and other resources for this tutorial, you can delete them if they are no longer needed.
**Note**
If you added resources in the VPC that you created for this tutorial, you might need to delete these before you can delete the VPC. For example, these resources might include Amazon EC2 instances or Amazon RDS DB instances. For more information, see [Delete your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) in the *Amazon VPC User Guide*.
**To delete a VPC and related resources**
1. Delete the DB subnet group.
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Subnet groups**.
1. Select the DB subnet group you want to delete, such as **tutorial-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 **VPCs**.
1. In the list, identify the VPC that you created, such as **tutorial-vpc**.
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 RDS DB instance, such as **tutorial-db-securitygroup**.
1. For **Actions**, choose **Delete security groups**, and then choose **Delete** on the confirmation page.
1. On the **Security Groups** page, select the security group for the Amazon EC2 instance, such as **tutorial-securitygroup**.
1. For **Actions**, choose **Delete security groups**, and then choose **Delete** on the confirmation page.
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 **VPCs**.
1. Select the VPC you want to delete, such as **tutorial-vpc**.
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 page, enter **delete**, and then choose **Delete**.
# Tutorial: Create a VPC for use with a DB instance (dual-stack mode)
A common scenario includes a DB instance 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 tutorial, you create the VPC for this scenario that works with a database running in dual-stack mode. Dual-stack mode to enable connection over the IPv6 addressing protocol. For more information about IP addressing, see [Amazon RDS IP addressing](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing).
Dual-stack network instances are supported in most regions. For more information see [Region and version availability](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.RegionVersionAvailability). To see the limitations of dual-stack mode, see [Limitations for dual-stack network DB instances](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-limitations).
The following diagram shows this scenario.
![\[VPC scenario for dual-stack mode\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/con-VPC-sec-grp-dual-stack.png)
For information about other scenarios, see [Scenarios for accessing a DB instance in a VPC](USER_VPC.Scenarios.md).
Your DB instance 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 Amazon EC2 instance is hosted in the public subnet, so that it can reach the public internet. The DB instance is hosted in a private subnet. The Amazon EC2 instance can connect to the DB instance because it's hosted within the same VPC. However, the DB instance is not available to the public internet, providing greater security.
This tutorial configures an additional public and private subnet in a separate Availability Zone. These subnets aren't used by the tutorial. An RDS DB subnet group requires a subnet in at least two Availability Zones. The additional subnet makes it easy to switch to a Multi-AZ DB instance deployment in the future.
To create a DB instance that uses dual-stack mode, specify **Dual-stack mode** for the **Network type** setting. You can also modify a DB instance with the same setting. For more information, see [Creating an Amazon RDS DB instance](USER_CreateDBInstance.md) and [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md).
This tutorial describes configuring a VPC for Amazon RDS DB instances. For more information about Amazon VPC, see [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/).
## 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 upper-right corner of the AWS Management Console, choose the Region to create your VPC in. This example uses the US East (Ohio) 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 remaining **VPC settings**, set these values:
+ **Name tag auto-generation** – **tutorial-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 subnet** – **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.
**Note**
Amazon RDS requires at least two subnets in two different Availability Zones to support Multi-AZ DB instance deployments. This tutorial creates a Single-AZ deployment, but the requirement makes it easy to convert to a Multi-AZ DB instance deployment in the future.
1. Choose **Create VPC**.
## 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:** **tutorial-dual-stack-securitygroup**
+ **Description:** **Tutorial Dual-Stack Security Group**
+ **VPC:** Choose the VPC that you created earlier, for example: **vpc-*identifier* (tutorial-dual-stack-vpc)**
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).
An example of an Internet Protocol version 4 (IPv4) address 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 Secure Shell (SSH) access to your Amazon EC2 instance. If you do this, you can connect to your EC2 instance to install SQL clients and other applications. Specify an IP address so you can access your EC2 instance:
+ **Type:** **SSH**
+ **Source:** The IP address or range from step a. An example of an IPv4 IP address is **203.0.113.25/32**. An example of an IPv6 IP address is **2001:DB8::/32**.
1. Choose **Create security group** to create the security group.
Note the security group ID because you need it later in this tutorial.
## Create a VPC security group for a private DB instance
To keep your DB instance private, create a second security group for private access. To connect to private DB instances 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:** **tutorial-dual-stack-db-securitygroup**
+ **Description:** **Tutorial Dual-Stack DB Instance Security Group**
+ **VPC:** Choose the VPC that you created earlier, for example: **vpc-*identifier* (tutorial-dual-stack-vpc)**
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 MySQL traffic on port 3306 from your Amazon EC2 instance. If you do, you can connect from your EC2 instance to your DB instance. Doing this means that you can send data from your EC2 instance to your database.
+ **Type:** **MySQL/Aurora**
+ **Source:** The identifier of the **tutorial-dual-stack-securitygroup** security group that you created previously in this tutorial, for example **sg-9edd5cfb**.
1. To create the security group, choose **Create security group**.
## Create a DB subnet group
A *DB subnet group* is a collection of subnets that you create in a VPC and that you then designate for your DB instances. By using a DB subnet group, you can specify a particular VPC when creating DB instances. To create a DB 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 DB 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 named **tutorial-dual-stack-subnet-private1-us-west-2a** and **tutorial-dual-stack-subnet-private2-us-west-2b**.
You will need the subnet IDs when you create your DB subnet group.
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
Make sure that you connect to the Amazon RDS console, not to the Amazon VPC console.
1. In the navigation pane, choose **Subnet groups**.
1. Choose **Create DB subnet group**.
1. On the **Create DB subnet group** page, set these values in **Subnet group details**:
+ **Name:** **tutorial-dual-stack-db-subnet-group**
+ **Description:** **Tutorial Dual-Stack DB Subnet Group**
+ **VPC:** **tutorial-dual-stack-vpc (vpc-*identifier*)**
1. In the **Add subnets** section, choose values for the **Availability Zones** and **Subnets** options.
For this tutorial, choose **us-east-2a** and **us-east-2b** for the **Availability Zones**. For **Subnets**, choose the private subnets you identified in the previous step.
1. Choose **Create**.
Your new DB subnet group appears in the DB subnet groups list on the RDS console. You can choose the DB subnet group to see its details. These include the supported addressing protocols and all of the subnets associated with the group and the network type supported by the DB subnet group.
## Create an Amazon EC2 instance in dual-stack mode
To create an Amazon EC2 instance, follow the instructions in [Launch an instance using the new launch instance wizard](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) in the *Amazon EC2 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 **tutorial-dual-stack-vpc** (vpc-*identifier*) created in [Create a VPC with private and public subnets](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets).
+ **Subnet** – Choose an existing public subnet, such as **subnet-*identifier* \$1 tutorial-dual-stack-subnet-public1-us-east-2a \$1 us-east-2a** created in [Create a VPC security group for a public Amazon EC2 instance](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2).
+ **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 `tutorial-securitygroup` created in [Create a VPC security group for a public Amazon EC2 instance](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2). Make sure that the security group that you choose includes inbound rules for Secure Shell (SSH) and HTTP access.
## Create a DB instance in dual-stack mode
In this step, you create a DB instance that runs in dual-stack mode.
**To create a DB instance**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the upper-right corner of the console, choose the AWS Region where you want to create the DB instance. This example uses the US East (Ohio) Region.
1. In the navigation pane, choose **Databases**.
1. Choose **Create database**.
1. On the **Create database** page, make sure that the **Standard create** option is chosen, and then choose the MySQL DB engine type.
1. In the **Connectivity** section, set these values:
+ **Network type** – Choose **Dual-stack mode**.
![\[Network type section in the console with Dual-stack mode selected\]](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/images/dual-stack-mode.png)
+ **Virtual private cloud (VPC)** – Choose an existing VPC with both public and private subnets, such as **tutorial-dual-stack-vpc** (vpc-*identifier*) created in [Create a VPC with private and public subnets](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets).
The VPC must have subnets in different Availability Zones.
+ **DB subnet group** – Choose a DB subnet group for the VPC, such as **tutorial-dual-stack-db-subnet-group** created in [Create a DB subnet group](#CHAP_Tutorials.CreateVPCDualStack.DBSubnetGroup).
+ **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 **tutorial-dual-stack-db-securitygroup** created in [Create a VPC security group for a private DB instance](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupDB).
Remove other security groups, such as the default security group, by choosing the **X** associated with each.
+ **Availability Zone** – Choose **us-west-2a**.
To avoid cross-AZ traffic, make sure the DB instance and the EC2 instance are in the same Availability Zone.
1. For the remaining sections, specify your DB instance settings. For information about each setting, see [Settings for DB instances](USER_CreateDBInstance.Settings.md).
## Connect to your Amazon EC2 instance and DB instance
After you create your Amazon EC2 instance and DB instance in dual-stack mode, you can connect to each one using the IPv6 protocol. To connect to an Amazon EC2 instance using the IPv6 protocol, follow the instructions in [Connect to your Linux instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) in the *Amazon EC2 User Guide*.
To connect to your RDS for MySQL DB instance from the Amazon EC2 instance, follow the instructions in [Connect to a MySQL DB instance](CHAP_GettingStarted.CreatingConnecting.MySQL.md#CHAP_GettingStarted.Connecting.MySQL).
## Deleting the VPC
After you create the VPC and other resources for this tutorial, you can delete them if they are no longer needed.
If you added resources in the VPC that you created for this tutorial, you might need to delete these before you can delete the VPC. Examples of resources are Amazon EC2 instances or DB instances. For more information, see [Delete your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) in the *Amazon VPC User Guide*.
**To delete a VPC and related resources**
1. Delete the DB subnet group:
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Subnet groups**.
1. Select the DB subnet group to delete, such as **tutorial-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 **VPCs**.
1. In the list, identify the VPC you created, such as **tutorial-dual-stack-vpc**.
1. Note the **VPC ID** value of the VPC that you created. You need this VPC ID in subsequent 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 RDS DB instance, such as **tutorial-dual-stack-db-securitygroup**.
1. For **Actions**, choose **Delete security groups**, and then choose **Delete** on the confirmation page.
1. On the **Security Groups** page, select the security group for the Amazon EC2 instance, such as **tutorial-dual-stack-securitygroup**.
1. For **Actions**, choose **Delete security groups**, and then choose **Delete** on the confirmation page.
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 **NAT Gateways**.
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 page, 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 **VPCs**.
1. Select the VPC that you want to delete, such as **tutorial-dual-stack-vpc**.
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 page, enter **delete**, and then choose **Delete**.
1. Release the Elastic IP addresses:
1. Open the Amazon 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 page, choose **Release**.
# Moving a DB instance not in a VPC into a VPC
Some legacy DB instances on the EC2-Classic platform are not in a VPC. If your DB instance is not in a VPC, you can use the AWS Management Console to easily move your DB instance into a VPC. Before you can move a DB instance not in a VPC, into a VPC, you must create the VPC.
| |
| --- |
| EC2-Classic was retired on August 15, 2022. If you haven't migrated from EC2-Classic to a VPC, we recommend that you migrate as soon as possible. For more information, see [ Migrate from EC2-Classic to a VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) in the Amazon EC2 User Guide and the blog [EC2-Classic Networking is Retiring – Here’s How to Prepare](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/). |
**Important**
If you are a new Amazon RDS customer, if you have never created a DB instance before, or if you are creating a DB instance in an AWS Region you have not used before, in almost all cases you are on the *EC2-VPC* platform and have a default VPC. For information about working with DB instances in a VPC, see [Working with a DB instance in a VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md).
Follow these steps to create a VPC for your DB instance.
+ [Step 1: Create a VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.CreatingVPC)
+ [Step 2: Create a DB subnet group](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.CreateDBSubnetGroup)
+ [Step 3: Create a VPC security group](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.CreateVPCSecurityGroup)
After you create the VPC, follow these steps to move your DB instance into the VPC.
+ [Updating the VPC for a DB instance](USER_VPC.VPC2VPC.md)
We highly recommend that you create a backup of your DB instance immediately before the migration. Doing so ensures that you can restore the data if the migration fails. For more information, see [Backing up, restoring, and exporting data](CHAP_CommonTasks.BackupRestore.md).
The following are some limitations to moving your DB instance into the VPC.
+ **Previous generation DB instance classes** – Previous generation DB instance classes might not be supported on the VPC platform. When moving a DB instance to a VPC, choose a db.m3 or db.r3 DB instance class. After you move the DB instance to a VPC, you can scale the DB instance to use a later DB instance class. For a full list of VPC supported instance classes, see [Amazon RDS instance types](https://aws.amazon.com/rds/instance-types/).
+ **Multi-AZ** – Moving a Multi-AZ DB instance not in a VPC into a VPC is not currently supported. To move your DB instance to a VPC, first modify the DB instance so that it is a single-AZ deployment. Change the **Multi-AZ deployment** setting to **No**. After you move the DB instance to a VPC, modify it again to make it a Multi-AZ deployment. For more information, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md).
+ **Read replicas** – Moving a DB instance with read replicas not in a VPC into a VPC is not currently supported. To move your DB instance to a VPC, first delete all of its read replicas. After you move the DB instance to a VPC, recreate the read replicas. For more information, see [Working with DB instance read replicas](USER_ReadRepl.md).
+ **Option groups** – If you move your DB instance to a VPC, and the DB instance is using a custom option group, change the option group that is associated with your DB instance. Option groups are platform-specific, and moving to a VPC is a change in platform. To use a custom option group in this case, assign the default VPC option group to the DB instance, assign an option group that is used by other DB instances in the VPC you are moving to, or create a new option group and assign it to the DB instance. For more information, see [Working with option groups](USER_WorkingWithOptionGroups.md).
## Alternatives for moving a DB instance not in a VPC into a VPC with minimal downtime
Using the following alternatives, you can move a DB instance not in a VPC into a VPC with minimal downtime. These alternatives cause minimum disruption to the source DB instance and allow it to serve user traffic during the migration. However, the time required to migrate to a VPC will vary based on the database size and the live workload characteristics.
+ **AWS Database Migration Service (AWS DMS)** – AWS DMS enables the live migration of data while keeping the source DB instance fully operational, but it replicates only a limited set of DDL statements. AWS DMS doesn't propagate items such as indexes, users, privileges, stored procedures, and other database changes not directly related to table data. In addition, AWS DMS doesn't automatically use RDS snapshots for the initial DB instance creation, which can increase migration time. For more information, see [AWS Database Migration Service](https://aws.amazon.com/dms/).
+ **DB snapshot restore or point-in-time recovery** – You can move a DB instance to a VPC by restoring a snapshot of the DB instance or by restoring a DB instance to a point in time. For more information, see [Restoring to a DB instance](USER_RestoreFromSnapshot.md) and [Restoring a DB instance to a specified time for Amazon RDS](USER_PIT.md).