# VPC examples
Amazon Virtual Private Cloud (VPC) is a fundamental building block within the AWS ecosystem, allowing you to provision isolated virtual networks tailored to your specific needs. By creating and managing your own VPCs, you gain full control over the networking environment, including the ability to define IP address ranges, subnets, routing tables, and connectivity options.
This section contains three example configurations for your virtual private clouds (VPCs), each designed to address a different set of requirements:
+ VPC for a test environment: This configuration shows how to create a VPC that you can use as a development or test environment.
+ VPC for Web and database servers: This configuration shows how to create a VPC that you can use for a resilent architecture in a production environment.
+ VPC with servers in private subnets and NAT: In this more advanced configuration, all EC2 instances are provisioned within private subnets, with a NAT gateway facilitating secure outbound internet access. This is an example where you need to limit direct internet connectivity to your resources while still enabling necessary outbound communication.
By providing these example VPC configurations, we hope to illustrate the flexibility and customization options available when designing your cloud networking environment. The specific VPC setup you choose should be based on your application's architecture, security requirements, and overall business objectives. Carefully planning your VPC infrastructure can help you create a robust, scalable, and secure virtual network that supports the growth and evolution of your cloud-based workloads.
**Topics**
+ [Test environment](vpc-example-dev-test.md)
+ [Web and database servers](vpc-example-web-database-servers.md)
+ [Private servers](vpc-example-private-subnets-nat.md)
**Related examples**
+ To connect your VPCs to each other, see [VPC peering configurations](https://docs.aws.amazon.com/vpc/latest/peering/peering-configurations.html) in the *Amazon VPC Peering Guide*.
+ To connect your VPCs to your own network, see [Site-to-Site VPN scenarios](https://docs.aws.amazon.com/vpn/latest/s2svpn/site-site-architectures.html) in the *AWS Site-to-Site VPN User Guide*.
+ To connect your VPCs to each other and to your own network, see [Example transit gateway scenarios](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#TGW_Scenarios) in the *Amazon VPC Transit Gateways*.
**Additional resources**
+ [Understand resiliency patterns and trade-offs](https://aws.amazon.com/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/) (AWS Architecture Blog)
+ [Plan your network topology](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) (AWS Well-Architected Framework)
+ [Amazon Virtual Private Cloud Connectivity Options](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) (AWS Whitepapers)
# Example: VPC for a test environment
This example demonstrates how to create a VPC that you can use as a development or test environment. Because this VPC is not intended to be used in production, it is not necessary to deploy your servers in multiple Availability Zones. To keep the cost and complexity low, you can deploy your servers in a single Availability Zone.
**Topics**
+ [Overview](#overview-vpc-one-public-subnet)
+ [1. Create the VPC](#create-vpc-one-public-subnet)
+ [2. Deploy your application](#deploy-dev-test)
+ [3. Test your configuration](#test-dev-test)
+ [4. Clean up](#clean-up-dev-test)
## Overview
The following diagram provides an overview of the resources included in this example. The VPC has a public subnet in a single Availability Zone and an internet gateway. The server is an EC2 instance that runs in the public subnet. The security group for the instance allows SSH traffic from your own computer, plus any other traffic specifically required for your development or testing activities.
![\[A VPC with a public subnet in one Availability Zone.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/vpc-example-dev-test.png)
### Routing
When you create this VPC by using the Amazon VPC console, we create a route table for the public subnet with local routes and routes to the internet gateway. The following is an example of the route table with routes for both IPv4 and IPv6. If you create an IPv4-only subnet instead of a dual stack subnet, your route table has only the IPv4 routes.
| Destination | Target |
| --- | --- |
| 10.0.0.0/16 | local |
| 2001:db8:1234:1a00::/56 | local |
| 0.0.0.0/0 | igw-id |
| ::/0 | igw-id |
### Security
For this example configuration, you must create a security group for your instance that allows the traffic that your application needs. For example, you might need to add a rule that allows SSH traffic from your computer or HTTP traffic from your network.
The following are example inbound rules for a security group, with rules for both IPv4 and IPv6. If you create IPv4-only subnets instead of dual stack subnets, you need only the rules for IPv4.
| Source | Protocol | Port range | Description |
| --- | --- | --- | --- |
| 0.0.0.0/0 | TCP | 80 | Allows inbound HTTP access from all IPv4 addresses |
| ::/0 | TCP | 80 | Allows inbound HTTP access from all IPv6 addresses |
| 0.0.0.0/0 | TCP | 443 | Allows inbound HTTPS access from all IPv4 addresses |
| ::/0 | TCP | 443 | Allows inbound HTTPS access from all IPv6 addresses |
| Public IPv4 address range of your network | TCP | 22 | (Optional) Allows inbound SSH access from IPv4 IP addresses in your network |
| IPv6 address range of your network | TCP | 22 | (Optional) Allows inbound SSH access from IPv6 IP addresses in your network |
| Public IPv4 address range of your network | TCP | 3389 | (Optional) Allows inbound RDP access from IPv4 IP addresses in your network |
| IPv6 address range of your network | TCP | 3389 | (Optional) Allows inbound RDP access from IPv6 IP addresses in your network |
## 1. Create the VPC
Use the following procedure to create a VPC with a public subnet in one Availability Zone. This configuration is suitable for a development or testing environment.
**To create the VPC**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the dashboard, choose **Create VPC**.
1. For **Resources to create**, choose **VPC and more**.
1. **Configure the VPC**
1. For **Name tag auto-generation**, enter a name for the VPC.
1. For **IPv4 CIDR block**, you can keep the default suggestion, or alternatively you can enter the CIDR block required by your application or network. For more information, see [VPC CIDR blocks](vpc-cidr-blocks.md).
1. (Optional) If your application communicates by using IPv6 addresses, choose **IPv6 CIDR block**, **Amazon-provided IPv6 CIDR block**.
1. **Configure the subnets**
1. For **Number of Availability Zones**, choose **1**. You can keep the default Availability Zone, or alternatively you can expand **Customize AZs** and select an Availability Zone.
1. For **Number of public subnets**, choose **1**.
1. For **Number of private subnets**, choose **0**.
1. You can keep the default CIDR block for the public subnet, or alternatively you can expand **Customize subnet CIDR blocks** and enter a CIDR block. For more information, see [Subnet CIDR blocks](subnet-sizing.md).
1. For **NAT gateways**, keep the default value, **None**.
1. For **VPC endpoints**, choose **None**. A gateway VPC endpoint for S3 is used only to access Amazon S3 from private subnets.
1. For **DNS options**, keep both options selected. As a result, your instance will receive a public DNS hostname that corresponds to its public IP address.
1. Choose **Create VPC**.
## 2. Deploy your application
There are a variety of ways to deploy EC2 instances. For example:
+ [Amazon EC2 launch instance wizard](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)
+ [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/)
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/)
+ [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/ecs/)
After you deploy an EC2 instance, you can connect to the instance, install the software that you need for your application, and then create an image for future use. For more information, see [Create an AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html) in the *Amazon EC2 User Guide*. Alternatively, you can use [EC2 Image Builder](https://aws.amazon.com/image-builder/) to create and manage your Amazon Machine Image (AMI).
## 3. Test your configuration
After you've finished deploying your application, you can test it. If you can't connect to your EC2 instance, or if your application can't send or receive the traffic that you expect, you can use Reachability Analyzer to help you troubleshoot. For example, Reachability Analyzer can identify configuration issues with your route tables or security groups. For more information, see the [Reachability Analyzer Guide](https://docs.aws.amazon.com/vpc/latest/reachability/).
## 4. Clean up
When you are finished with this configuration, you can delete it. Before you can delete the VPC, you must terminate your instance. For more information, see [Delete your VPC](delete-vpc.md).
# Example: VPC for web and database servers
This example demonstrates how to create a VPC that you can use for a two-tier architecture in a production environment. To improve resiliency, you deploy the servers in two Availability Zones.
**Topics**
+ [Overview](#overview-vpc-public-private-subnets-multi-az)
+ [1. Create the VPC](#create-vpc-public-private-subnets-multi-az)
+ [2. Deploy your application](#deploy-web-database-servers)
+ [3. Test your configuration](#test-web-database-servers)
+ [4. Clean up](#clean-up-web-database-servers)
## Overview
The following diagram provides an overview of the resources included in this example. The VPC has public subnets and private subnets in two Availability Zones. The web servers run in the public subnets and receive traffic from clients through a load balancer. The security group for the web servers allows traffic from the load balancer. The database servers run in the private subnets and receive traffic from the web servers. The security group for the database servers allows traffic from the web servers. The database servers can connect to Amazon S3 by using a gateway VPC endpoint.
![\[A VPC with subnets in two Availability Zones.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/vpc-example-web-database.png)
### Routing
When you create this VPC by using the Amazon VPC console, we create a route table for the public subnets with local routes and routes to the internet gateway, and a route table for each private subnet with local routes and a route to the gateway VPC endpoint.
The following is an example of a route table for the public subnets, with routes for both IPv4 and IPv6. If you create IPv4-only subnets instead of dual stack subnets, your route table has only the IPv4 routes.
| Destination | Target |
| --- | --- |
| 10.0.0.0/16 | local |
| 2001:db8:1234:1a00::/56 | local |
| 0.0.0.0/0 | igw-id |
| ::/0 | igw-id |
The following is an example of a route table for the private subnets, with local routes for both IPv4 and IPv6. If you created IPv4-only subnets, your route table has only the IPv4 route. The last route sends traffic destined for Amazon S3 to the gateway VPC endpoint.
| Destination | Target |
| --- | --- |
| 10.0.0.0/16 | local |
| 2001:db8:1234:1a00::/56 | local |
| s3-prefix-list-id | s3-gateway-id |
### Security
For this example configuration, you create a security group for the load balancer, a security group for the web servers, and a security group for the database servers.
**Load balancer**
The security group for your Application Load Balancer or Network Load Balancer must allow inbound traffic from clients on the load balancer listener port. To accept traffic from anywhere on the internet, specify 0.0.0.0/0 as the source. The load balancer security group must also allow outbound traffic from the load balancer to the target instances on the instance listener port and the health check port.
**Web servers**
The following security group rules allow the web servers to receive HTTP and HTTPS traffic from the load balancer. You can optionally allow the web servers to receive SSH or RDP traffic from your network. The web servers can send SQL or MySQL traffic to your database servers.
| Source | Protocol | Port range | Description |
| --- | --- | --- | --- |
| ID of the security group for the load balancer | TCP | 80 | Allows inbound HTTP access from the load balancer |
| ID of the security group for the load balancer | TCP | 443 | Allows inbound HTTPS access from the load balancer |
| Public IPv4 address range of your network | TCP | 22 | (Optional) Allows inbound SSH access from IPv4 IP addresses in your network |
| IPv6 address range of your network | TCP | 22 | (Optional) Allows inbound SSH access from IPv6 IP addresses in your network |
| Public IPv4 address range of your network | TCP | 3389 | (Optional) Allows inbound RDP access from IPv4 IP addresses in your network |
| IPv6 address range of your network | TCP | 3389 | (Optional) Allows inbound RDP access from IPv6 IP addresses in your network |
| Destination | Protocol | Port range | Description |
| --- | --- | --- | --- |
| ID of the security group for instances running Microsoft SQL Server | TCP | 1433 | Allows outbound Microsoft SQL Server access to the database servers |
| ID of the security group for instances running MySQL | TCP | 3306 | Allows outbound MySQL access to the database servers |
**Database servers**
The following security group rules allow the database servers to receive read and write requests from the web servers.
| Source | Protocol | Port range | Comments |
| --- | --- | --- | --- |
| ID of the web server security group | TCP | 1433 | Allows inbound Microsoft SQL Server access from the web servers |
| ID of the web server security group | TCP | 3306 | Allows inbound MySQL Server access from the web servers |
| Destination | Protocol | Port range | Comments |
| --- | --- | --- | --- |
| 0.0.0.0/0 | TCP | 80 | Allows outbound HTTP access to the internet over IPv4 |
| 0.0.0.0/0 | TCP | 443 | Allows outbound HTTPS access to the internet over IPv4 |
For more information about security groups for Amazon RDS DB instances, see [Controlling access with security groups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html) in the *Amazon RDS User Guide*.
## 1. Create the VPC
Use the following procedure to create a VPC with a public subnet and a private subnet in two Availability Zones.
**To create the VPC**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the dashboard, choose **Create VPC**.
1. For **Resources to create**, choose **VPC and more**.
1. Configure the VPC:
1. Keep **Name tag auto-generation** selected to create Name tags for the VPC resources or clear it to provide your own Name tags for the VPC resources.
1. For **IPv4 CIDR block**, you can keep the default suggestion, or alternatively you can enter the CIDR block required by your application or network. For more information, see [VPC CIDR blocks](vpc-cidr-blocks.md).
1. (Optional) If your application communicates by using IPv6 addresses, choose **IPv6 CIDR block**, **Amazon-provided IPv6 CIDR block**.
1. Choose a **Tenancy** option. This option defines if EC2 instances that you launch into the VPC will run on hardware that's shared with other AWS accounts or on hardware that's dedicated for your use only. If you choose the tenancy of the VPC to be `Default`, EC2 instances launched into this VPC will use the tenancy attribute specified when you launch the instance. For more information, see [Launch an instance using defined parameters](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) in the *Amazon EC2 User Guide*. If you choose the tenancy of the VPC to be `Dedicated`, the instances will always run as [Dedicated Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) on hardware that's dedicated for your use.
1. Configure the subnets:
1. For **Number of Availability Zones**, choose **2**, so that you can launch instances in two Availability Zones to improve resiliency.
1. For **Number of public subnets**, choose **2**.
1. For **Number of private subnets**, choose **2**.
1. You can keep the default CIDR blocks for the subnets, or alternatively you can expand **Customize subnets CIDR blocks** and enter a CIDR block. For more information, see [Subnet CIDR blocks](subnet-sizing.md).
1. For **NAT gateways**, keep the default value, **None**.
1. For **VPC endpoints**, keep the default value, **S3 Gateway**. While there is no effect unless you access an S3 bucket, there is no cost to enable this VPC endpoint.
1. For **DNS options**, keep both options selected. As a result, your web servers will receive public DNS hostnames that correspond to their public IP addresses.
1. Choose **Create VPC**.
## 2. Deploy your application
Ideally, you've already tested your web servers and database servers in a development or test environment, and created the scripts or images that you'll use to deploy your application in production.
You can use EC2 instances for your web servers. There are a variety of ways to deploy EC2 instances. For example:
+ [Amazon EC2 launch instance wizard](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/)
+ [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/ecs/)
To improve availability, you can use [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/) to deploy servers in multiple Availability Zones and maintain the minimum server capacity that is required by your application.
You can use [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/) to distribute traffic evenly across your servers. You can attach your load balancer to an Auto Scaling group.
You can use EC2 instances for your database servers, or one of our purpose-built database types. For more information, see [Databases on AWS: How to choose](https://docs.aws.amazon.com/documentation/latest/databases-on-aws-how-to-choose/).
## 3. Test your configuration
After you've finished deploying your application, you can test it. If your application can't send or receive the traffic that you expect, you can use Reachability Analyzer to help you troubleshoot. For example, Reachability Analyzer can identify configuration issues with your route tables or security groups. For more information, see the [Reachability Analyzer Guide](https://docs.aws.amazon.com/vpc/latest/reachability/).
## 4. Clean up
When you are finished with this configuration, you can delete it. Before you can delete the VPC, you must terminate your instances and delete the load balancer. For more information, see [Delete your VPC](delete-vpc.md).
# Example: VPC with servers in private subnets and NAT
This example demonstrates how to create a VPC that you can use for servers in a production environment. To improve resiliency, you deploy the servers in two Availability Zones, by using an Auto Scaling group and an Application Load Balancer. For additional security, you deploy the servers in private subnets. The servers receive requests through the load balancer. The servers can connect to the internet by using a NAT gateway. To improve resiliency, you deploy the NAT gateway in both Availability Zones.
**Topics**
+ [Overview](#overview-vpc-private-subnets-nat)
+ [1. Create the VPC](#create-vpc-private-subnets-nat)
+ [2. Deploy your application](#deploy-private-subnets)
+ [3. Test your configuration](#test-private-subnets)
+ [4. Clean up](#clean-up-private-subnets)
## Overview
The following diagram provides an overview of the resources included in this example. The VPC has public subnets and private subnets in two Availability Zones. Each public subnet contains a NAT gateway and a load balancer node. The servers run in the private subnets, are launched and terminated by using an Auto Scaling group, and receive traffic from the load balancer. The servers can connect to the internet by using the NAT gateway. The servers can connect to Amazon S3 by using a gateway VPC endpoint.
![\[A VPC with subnets in two Availability Zones.\]](http://docs.aws.amazon.com/vpc/latest/userguide/images/vpc-example-private-subnets.png)
### Routing
When you create this VPC by using the Amazon VPC console, we create a route table for the public subnets with local routes and routes to the internet gateway. We also create a route table for the private subnets with local routes, and routes to the NAT gateway, egress-only internet gateway, and gateway VPC endpoint.
The following is an example of the route table for the public subnets, with routes for both IPv4 and IPv6. If you create IPv4-only subnets instead of dual stack subnets, your route table includes only the IPv4 routes.
| Destination | Target |
| --- | --- |
| 10.0.0.0/16 | local |
| 2001:db8:1234:1a00::/56 | local |
| 0.0.0.0/0 | igw-id |
| ::/0 | igw-id |
The following is an example of a route table for one of the private subnets, with routes for both IPv4 and IPv6. If you created IPv4-only subnets, the route table includes only the IPv4 routes. The last route sends traffic destined for Amazon S3 to the gateway VPC endpoint.
| Destination | Target |
| --- | --- |
| 10.0.0.0/16 | local |
| 2001:db8:1234:1a00::/56 | local |
| 0.0.0.0/0 | nat-gateway-id |
| ::/0 | eigw-id |
| s3-prefix-list-id | s3-gateway-id |
### Security
The following is an example of the rules that you might create for the security group that you associate with your servers. The security group must allow traffic from the load balancer over the listener port and protocol. It must also allow health check traffic.
| Source | Protocol | Port range | Comments |
| --- | --- | --- | --- |
| ID of the load balancer security group | listener protocol | listener port | Allows inbound traffic from the load balancer on the listener port |
| ID of the load balancer security group | health check protocol | health check port | Allows inbound health check traffic from the load balancer |
## 1. Create the VPC
Use the following procedure to create a VPC with a public subnet and a private subnet in two Availability Zones, and a NAT gateway in each Availability Zone.
**To create the VPC**
1. Open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. On the dashboard, choose **Create VPC**.
1. For **Resources to create**, choose **VPC and more**.
1. **Configure the VPC**
1. For **Name tag auto-generation**, enter a name for the VPC.
1. For **IPv4 CIDR block**, you can keep the default suggestion, or alternatively you can enter the CIDR block required by your application or network.
1. If your application communicates by using IPv6 addresses, choose **IPv6 CIDR block**, **Amazon-provided IPv6 CIDR block**.
1. **Configure the subnets**
1. For **Number of Availability Zones**, choose **2**, so that you can launch instances in multiple Availability Zones to improve resiliency.
1. For **Number of public subnets**, choose **2**.
1. For **Number of private subnets**, choose **2**.
1. You can keep the default CIDR block for the public subnet, or alternatively you can expand **Customize subnet CIDR blocks** and enter a CIDR block. For more information, see [Subnet CIDR blocks](subnet-sizing.md).
1. For **NAT gateways**, choose **1 per AZ** to improve resiliency.
1. If your application communicates by using IPv6 addresses, for **Egress only internet gateway**, choose **Yes**.
1. For **VPC endpoints**, if your instances must access an S3 bucket, keep the **S3 Gateway** default. Otherwise, instances in your private subnet can't access Amazon S3. There is no cost for this option, so you can keep the default if you might use an S3 bucket in the future. If you choose **None**, you can always add a gateway VPC endpoint later on.
1. For **DNS options**, clear **Enable DNS hostnames**.
1. Choose **Create VPC**.
## 2. Deploy your application
Ideally, you've finished testing your servers in a development or test environment, and created the scripts or images that you'll use to deploy your application in production.
You can use [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/) to deploy servers in multiple Availability Zones and maintain the minimum server capacity required by your application.
**To launch instances by using an Auto Scaling group**
1. Create a launch template to specify the configuration information needed to launch your EC2 instances by using Amazon EC2 Auto Scaling. For step-by-step directions, see [Create a launch template for your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) in the *Amazon EC2 Auto Scaling User Guide*.
1. Create an Auto Scaling group, which is a collection of EC2 instances with a minimum, maximum, and desired size. For step-by-step directions, see [Create an Auto Scaling group using a launch template](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-launch-template.html) in the *Amazon EC2 Auto Scaling User Guide*.
1. Create a load balancer, which distributes traffic evenly across the instances in your Auto Scaling group, and attach the load balancer to your Auto Scaling group. For more information, see the [Elastic Load Balancing User Guide](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/) and [Use Elastic Load Balancing](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html) in the *Amazon EC2 Auto Scaling User Guide*.
## 3. Test your configuration
After you've finished deploying your application, you can test it. If your application can't send or receive the traffic that you expect, you can use Reachability Analyzer to help you troubleshoot. For example, Reachability Analyzer can identify configuration issues with your route tables or security groups. For more information, see the [Reachability Analyzer Guide](https://docs.aws.amazon.com/vpc/latest/reachability/).
## 4. Clean up
When you are finished with this configuration, you can delete it. Before you can delete the VPC, you must delete the Auto Scaling group, terminate your instances, delete the NAT gateways, and delete the load balancer. For more information, see [Delete your VPC](delete-vpc.md).