AWS Documentation » Amazon Virtual Private Cloud » User Guide » Scenarios for Using Amazon VPC » Scenario 2: VPC with Public and Private Subnets	« Previous Next »
	Did this page help you? Yes \| No \| Tell us about it...

Scenario 2: VPC with Public and Private Subnets

The configuration for this scenario includes a virtual private cloud (VPC) with a public subnet and a private subnet. We recommend this scenario if you want to run a public-facing web application, while maintaining back-end servers that aren't publicly accessible. A common example is a multi-tier website, with the web servers in a public subnet and the database servers in a private subnet. You can set up security and routing so that the web servers can communicate with the database servers.

The instances in the public subnet can receive inbound traffic directly from the Internet, whereas the instances in the private subnet can't. The instances in the public subnet can send outbound traffic directly to the Internet, whereas the instances in the private subnet can't. Instead, the instances in the private subnet can access the Internet by using a network address translation (NAT) instance that you launch into the public subnet.

Topics

Configuration for Scenario 2

The following diagram shows the key components of the configuration for this scenario.

Diagram for scenario 2: VPC with public and private subnets

Important

For this scenario, the Amazon Virtual Private Cloud Network Administrator Guide describes what your network administrator needs to do to configure the Amazon VPC customer gateway on your side of the VPN connection.

Basic Components for Scenario 2

The following list describes the basic components presented in the configuration diagram for this scenario:

A virtual private cloud (VPC) of size /16 (example CIDR: 10.0.0.0/16). This provides 65,536 private IP addresses.
A public subnet of size /24 (example CIDR: 10.0.0.0/24). This provides 256 private IP addresses.
A private subnet of size /24 (example CIDR: 10.0.1.0/24). This provides 256 private IP addresses.
An Internet gateway. This connects the VPC to the Internet and to other AWS products, such as Amazon Simple Storage Service (Amazon S3).
Instances with private IP addresses in the subnet range (examples: 10.0.0.5, 10.0.1.5), which enables them to communicate with each other and other instances in the VPC. Instances in the public subnet also have Elastic IP addresses (example: 198.51.100.1), which enable them to be reached from the Internet. Instances in the private subnet are back-end servers that don't need to accept incoming traffic from the Internet; however, they can send requests to the Internet using the NAT instance (see the next bullet).
A network address translation (NAT) instance with its own Elastic IP address. This enables instances in the private subnet to send requests to the Internet (for example, for software updates).
A custom route table associated with the public subnet. This route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC, and an entry that enables instances in the subnet to communicate directly with the Internet.
The main route table associated with the private subnet. The route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC, and an entry that enables instances in the subnet to communicate directly with your network.

For more information about subnets, see Your VPC and Subnets and IP Addressing in Your VPC. For more information about Internet gateways, see Adding an Internet Gateway to Your VPC. For more information about NAT, see NAT Instances.

Tip

To help manage the instances in the private subnet, you can set up bastion servers in the public subnet to act as proxies. For example, you can set up SSH port forwarders or RDP gateways in the public subnet to proxy the traffic going to your database servers from your own network.

Routing for Scenario 2

Your VPC has an implied router (shown in the configuration diagram for this scenario). For this scenario, the VPC wizard updates the main route table used with the private subnet, and creates a custom route table and associates it with the public subnet. Otherwise, you'd need to create and associate the route tables yourself.

In this scenario, all traffic from each subnet that is bound for AWS (for example, to the Amazon EC2 or Amazon S3 endpoints) goes over the Internet gateway. The database servers in the private subnet can't receive traffic from the Internet directly because they don't have Elastic IP addresses. However, the database servers can send and receive Internet traffic through the NAT instance in the public subnet.

Any additional subnets that you create use the main route table by default, which means that they are private subnets by default. If you'd like to make a subnet public, you can always change the route table that it's associated with.

The following tables describe the route tables for this scenario.

Main Route Table

The first row describes the entry for local routing in the VPC; this entry enables the instances in the VPC to communicate with each other. The second row describes the entry that sends all other subnet traffic to the NAT instance, which is specified using its AWS-assigned identifiers (for example, network interface eni-1a2b3c4d and instance i-1a2b3c4d).

Destination	Target
`10.0.0.0/16`	local
`0.0.0.0/0`	eni-xxxxxxxx / i-xxxxxxxx

Custom Route Table

The first row describes the entry for local routing in the VPC; this entry enables the instances in this VPC to communicate with each other. The second row describes the entry for routing all other subnet traffic to the Internet over the Internet gateway, which is specified using its AWS-assigned identifier (for example, igw-1a2b3d4d).

Destination	Target
`10.0.0.0/16`	local
`0.0.0.0/0`	`igw`-xxxxxxxx

Security for Scenario 2

AWS provides two features that you can use to increase security in your VPC: security groups and network ACLs. Both features enable you to control the inbound and outbound traffic for your instances, but security groups work at the instance level, while network ACLs work at the subnet level. Security groups alone can meet the needs of many VPC users. However, some VPC users decide to use both security groups and network ACLs to take advantage of the additional layer of security that network ACLs provide. For more information about security groups and network ACLs and how they differ, see Security in Your VPC.

For scenario 2, you'll use security groups but not network ACLs. For more information about security groups, see Security Groups for Your VPC.

Recommended Security Groups

Your VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the group. If you don't specify a security group when you launch an instance, the instance is automatically assigned to this default security group. You must change the rules for the default security group if you want the assigned instances to receive traffic from outside the VPC.

For this scenario, we recommend that you create the following security groups instead of using the default security group:

WebServerSG—For the web servers in the public subnet
NATSG—For the NAT instance in the public subnet
DBServerSG—For the database servers in the private subnet

The instances assigned to a security group can be in different subnets. However, in this scenario, each security group corresponds to the type of role an instance plays, and each role requires the instance to be in a particular subnet. Therefore, in this scenario, all instances assigned to a security group are in the same subnet.

Even though some instances are assigned to the same security group (for example, the web servers are assigned to WebServerSG), they can't automatically communicate with each other. Only the default security group contains rules that allow instances to communicate with each other by default. To allow that type of communication between your instances assigned to the same security group, you must add rules like the following to each security group in addition to its recommended rules.

Inbound
Source	Protocol	Port Range	Comments
The ID of the security group	All	All	Allow inbound traffic from other instances assigned to this security group
Outbound
Destination	Protocol	Port Range	Comments
The ID of the security group	All	All	Allow outbound traffic from other instances assigned to this security group

Creating the WebServerSG, NATSG, and DBServerSG Security Groups

To create the WebServerSG, NATSG, and DBServerSG security groups

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
Click Security Groups in the navigation pane.
Click the Create Security Group button.
In the Create Security Group dialog box, specify WebServerSG as the name of the security group, and provide a description. Select the ID of your VPC from the VPC list, and then click Yes, Create.
Click the Create Security Group button again.
In the Create Security Group dialog box, specify NATSG as the name of the security group, and provide a description. Select the ID of your VPC from the VPC list, and then click Yes, Create.
Click the Create Security Group button again.
In the Create Security Group dialog box, specify DBServerSG as the name of the security group, and provide a description. Select the ID of your VPC from the VPC list, and then click Yes, Create.

The next sections describe the recommended rules for each security group and show you how to add them.

Adding Rules to the WebServerSG Security Group

The WebServerSG security group is the security group that you'll specify when you launch your web servers into your public subnet. The following table describes the recommended rules for this security group, which allow the web servers to receive Internet traffic, as well as SSH and RDP traffic from your network. The web servers can also initiate traffic to the Internet and read and write requests to the database servers in the private subnet.

WebServerSG: Recommended Rules

Inbound
Source	Protocol	Port Range	Comments
`0.0.0.0/0`	TCP	80	Allow inbound HTTP access to the web servers from anywhere
`0.0.0.0/0`	TCP	443	Allow inbound HTTPS access to the web servers from anywhere
Your network's public IP address range	TCP	22	Allow inbound SSH access to Linux instances from your network (over the Internet gateway)
Your network's public IP address range	TCP	3389	Allow inbound RDP access to Windows instances from your network (over the Internet gateway)
Outbound
Destination	Protocol	Port Range	Comments
`0.0.0.0/0`	TCP	80	Allow web servers to initiate outbound HTTP access to the Internet (for example, for software updates)
`0.0.0.0/0`	TCP	443	Allow web servers to initiate outbound HTTPS access to the Internet (for example, for software updates)
The ID of your DBServerSG security group	TCP	1433	Allow outbound Microsoft SQL Server access to the database servers assigned to DBServerSG
The ID of your DBServerSG security group	TCP	3306	Allow outbound MySQL access to the database servers assigned to DBServerSG

Note

The group includes both SSH and RDP access, and both Microsoft SQL Server and MySQL access. For your situation, you might only need rules for Linux (SSH and MySQL) or Windows (RDP and Microsoft SQL Server).

To add rules to the WebServerSG security group

Select the WebServerSG security group that you created. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
Add rules for inbound traffic using the Inbound tab as follows:
1. Select HTTP from the Create a new rule list. Make sure that Source is 0.0.0.0/0, and then click Add Rule. Notice that the Apply Rules Changes button is enabled, and the text "Your changes have not been applied yet" is displayed. After you add all the rules for inbound traffic that you need, you'll click Apply Rule Changes to add the rules.
2. Select HTTPS from the Create a new rule list. Make sure that Source is 0.0.0.0/0, and then click Add Rule.
3. Select SSH from the Create a new rule list. In the Source box, specify the public IP address range of your network (this example uses 192.0.2.0/24), and then click Add Rule.
4. Select RDP from the Create a new rule list. In the Source box, specify the public IP range of your network, and then click Add Rule.
5. Click Apply Rule Changes.
Add rules for outbound traffic using the Outbound tab as follows:
1. Locate the default rule that enables all outbound traffic, and then click Delete.
2. Select HTTP from the Create a new rule list. Make sure that Destination is 0.0.0.0/0, and then click Add Rule.
3. Select HTTPS from the Create a new rule list. Make sure that Destination is 0.0.0.0/0, and then click Add Rule.
4. Select MS SQL from the Create a new rule list. In the Destination box, specify the ID of the DBServerSG security group, and then click Add Rule.
5. Select MySQL from the Create a new rule list. In the Destination box, specify the ID of the DBServerSG security group, and then click Add Rule.
6. Click Apply Rule Changes.

Adding Rules to the NATSG Security Group

The NATSG security group is the security group that you'll specify when you launch a NAT instance into your public subnet. The following table describes the recommended rules for this security group, which allow the NAT instance to receive Internet-bound traffic from instances in the private subnet, as well as SSH traffic from your network. The NAT instance can also send traffic to the Internet, so that instances in the private subnet can get software updates.

NATSG: Recommended Rules

Inbound
Source	Protocol	Port Range	Comments
`10.0.1.0/24`	TCP	80	Allow inbound HTTP traffic from database servers in the private subnet
`10.0.1.0/24`	TCP	443	Allow inbound HTTPS traffic from database servers in the private subnet
Your network's public IP address range	TCP	22	Allow inbound SSH access to the NAT instance from your network (over the Internet gateway)
Outbound
Destination	Protocol	Port Range	Comments
`0.0.0.0/0`	TCP	80	Allow outbound HTTP access to the Internet (over the Internet gateway)
`0.0.0.0/0`	TCP	443	Allow outbound HTTPS access to the Internet (over the Internet gateway)

To add the recommended rules to the NATSG security group

Select the NATSG security group that you created. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
Add rules for inbound traffic using the Inbound tab as follows:
1. Select HTTP from the Create a new rule list. In the Source box, specify the IP address range of your private subnet, and then click Add Rule.
2. Select HTTPS from the Create a new rule list. In the Source box, specify the IP address range of your private subnet, and then click Add Rule.
3. Select SSH from the Create a new rule list. In the Source box, specify the public IP address range of your network, and then click Add Rule.
4. Click Apply Rule Changes.
Add rules for outbound traffic using the Outbound tab as follows:
1. Select HTTP from the Create a new rule list. Make sure that Destination is 0.0.0.0/0, and then click Add Rule.
2. Select HTTPS from the Create a new rule list. Make sure that Destination is 0.0.0.0/0, and then click Add Rule.
3. Click Apply Rule Changes.

Adding Rules to the DBServerSG Security Group

The DBServerSG security group is the security group that you'll specify when you launch your database servers into your private subnet. The following table describes the recommended rules for this security group, which allow read or write database requests from the web servers. The database servers can also initiate traffic bound for the Internet (your route table sends that traffic to the NAT instance, which then forwards it to the Internet over the Internet gateway).

DBServerSG: Recommended Rules

Inbound
Source	Protocol	Port Range	Comments
The ID of your WebServerSG security group	TCP	1433	Allow web servers assigned to WebServerSG Microsoft SQL Server access to database servers assigned to DBServerSG
The ID of your WebServerSG security group	TCP	3306	Allow web servers assigned to WebServerSG MySQL access to database servers assigned to DBServerSG
Outbound
Destination	Protocol	Port Range	Comments
`0.0.0.0/0`	TCP	80	Allow outbound HTTP access to the Internet (for example, for software updates)
`0.0.0.0/0`	TCP	443	Allow outbound HTTPS access to the Internet (for example, for software updates)

To add the recommended rules to the DBServerSG security group

Select the DBServerSG security group that you created. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
Add rules for inbound traffic using the Inbound tab as follows:
1. Select MS SQL from the Create a new rule list. In the Source box, specify the ID of your WebServerSG security group, and then click Add Rule.
2. Select MYSQL from the Create a new rule list. In the Source box, specify the ID of your WebServerSG security group, and then click Add Rule.
3. Click Apply Rule Changes.
Add rules for outbound traffic using the Outbound tab as follows:
1. Select HTTP from the Create a new rule list. Make sure that Destination is 0.0.0.0/0, and then click Add Rule.
2. Select HTTPS from the Create a new rule list. Make sure that Destination is 0.0.0.0/0, and then click Add Rule.
3. Click Apply Rule Changes.

Implementing Scenario 2

Use the following process to implement scenario 2 using the VPC wizard.

To implement scenario 2 using the VPC wizard

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
Click VPC Dashboard in the navigation pane.
Locate the Your Virtual Private Cloud area of the dashboard and click Get started creating a VPC, if you have no VPC resources, or click Start VPC Wizard.
Select the second option, VPC with Public and Private Subnets, and then click Continue.
Verify the information on the confirmation page. Make any changes that you need, and then click Create VPC to create your VPC, subnets, Internet gateway, and route tables, and launch a NAT instance into the public subnet.

When the VPC wizard launched the NAT instance, it used the default security group for the VPC. You need to associate the NAT instance with the NATSG security group instead.

To change the security group of the NAT instance

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
Click Network Interfaces in the navigation pane.
Select the network interface for the NAT instance from the list, and then select Change Security Groups from the Actions list.
In the Change Security Groups dialog box, select the NATSG security group that you created (see Security for Scenario 2) from the Security Groups list, and then click Save.

You can launch instances into your VPC. If you're already familiar with launching instances outside a VPC, then you already know most of what you need to know to launch an instance into a VPC.

To launch an instance

Create the WebServerSG and DBServerSG security groups if you haven't done so already (see Security for Scenario 2). You'll specify one of these security groups when you launch the instance.
Start the Classic wizard:
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. Click the Launch Instance button from the dashboard.
3. On the Create a New Instance page, select Classic Wizard, and then click Continue.
On the CHOOSE AN AMI page, the Quick Start tab displays a list of basic configurations called Amazon Machine Images (AMI). Choose the AMI that you want to use and click its Select button.
On the INSTANCE DETAILS page, under Launch Instances, select the subnet to launch the instance into. Keep the other default settings on this page and click Continue.
To use the default settings on the next few INSTANCE DETAILS pages, just click Continue on each page.
On the CREATE A KEY PAIR page, you can choose from any existing key pairs that you've created, or follow the wizard directions to create a new key pair.
On the Configure Firewall page, select the security group you want to use for the instance (WebServerSG or DBServerSG), and then click Continue.
Review your settings. When you're satisfied with your selections, click Launch.

Before you can access an instance in your public subnet, you must assign it an Elastic IP address.

To allocate an Elastic IP address and assign it to an instance

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
Click Elastic IPs in the navigation pane.
Click the Allocate New Address button.
In the Allocate New Address dialog box, in the EIP used in list, select VPC, and then click Yes, Allocate.
Select the Elastic IP address from the list, and then click the Associate Address button.
In the Associate Address dialog box, select the network interface or instance. Select the address to associate the Elastic IP address with from the corresponding Private IP Address list, and then click Yes, Associate.

You can now connect to your instances in the VPC. For information about how to connect to a Linux instance, see Connect to Your Linux Instance in the Amazon Elastic Compute Cloud User Guide. For information about how to connect to a Windows instance, see Connect to Your Windows Instance in the Amazon Elastic Compute Cloud Microsoft Windows Guide.

Document Conventions	« Previous Next »
Terms of Use	Did this page help you? Yes \| No \| Tell us about it...