Menu
Amazon Virtual Private Cloud
User Guide

Scenario 2: VPC with Public and Private Subnets (NAT)

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) gateway that resides in the public subnet. The database servers can connect to the Internet for software updates using the NAT gateway, but the Internet cannot initiate connections to the database servers.

Note

You can also use the VPC wizard to configure a VPC with a NAT instance; however, we recommend that you use a NAT gateway. For more information, see NAT Gateways.

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

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.

  • Instances with private IP addresses in the subnet range (examples: 10.0.0.5, 10.0.1.5). This 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. The instances can have public IP addresses assigned at launch instead of Elastic IP addresses. 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 gateway (see the next bullet).

  • A NAT gateway 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 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 with the Internet through the NAT gateway.

For more information about subnets, see Your VPC and Subnets and IP Addressing in Your VPC. For more information about Internet gateways, see Internet Gateways. For more information about NAT gateways, see NAT Gateways.

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

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 device 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 gateway.

DestinationTarget

10.0.0.0/16

local

0.0.0.0/0

nat-gateway-id

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).

DestinationTarget

10.0.0.0/16

local

0.0.0.0/0

igw-id

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. If you'd like to use a network ACL, see Recommended Rules for Scenario 2.

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.

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

  • WebServerSG—For the web servers 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.

The WebServerSG security group is the security group that you 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 read and write requests to the database servers in the private subnet, and send traffic to the Internet; for example, to get software updates. Because the web server doesn't initiate any other outbound communication, the default outbound rule is removed.

Note

These recommendations include 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).

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 home network's public IP address range

TCP

22

Allow inbound SSH access to Linux instances from your home network (over the Internet gateway). You can get the public IP address of your local computer using a service such as http://checkip.amazonaws.com. If you are connecting through an ISP or from behind your firewall without a static IP address, you need to find out the range of IP addresses used by client computers.

Your home network's public IP address range

TCP

3389

Allow inbound RDP access to Windows instances from your home network (over the Internet gateway)

Outbound

Destination Protocol Port Range Comments

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

0.0.0.0/0

TCP

80

Allow outbound HTTP access to the Internet

0.0.0.0/0

TCP

443

Allow outbound HTTPS access to the Internet


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 gateway, 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)


The default security group for a VPC has rules that automatically allow assigned instances to communicate with each other. To allow that type of communication between instances in your VPC when you use a different security group, you must add a rule like the following to your security groups.

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

Implementing Scenario 2

You can use the VPC wizard to create the VPC, subnets, and NAT gateway for scenario 2. If you want to use an existing Elastic IP address for your NAT gateway, ensure that it's not currently associated with another instance or network interface. The NAT gateway is automatically created in the public subnet of your VPC.

To implement scenario 2 with a NAT gateway

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose VPC Dashboard, Start VPC Wizard.

  3. Choose the second option, VPC with Public and Private Subnets, and Select.

  4. On the Step 2 page of the wizard, you can specify names for your VPC and subnets, and leave the default values for the VPC CIDR block, the subnet CIDR blocks, Availability Zone, endpoints, DNS hostnames, hardware tenancy, and ClassicLink settings.

  5. In the Specify the details of your NAT gateway section, specify an Elastic IP address. When you are done, choose Create VPC.

Because the WebServerSG and DBServerSG security groups reference each other, create all the security groups required for this scenario before you add rules to them.

To create the WebServerSG and DBServerSG security groups

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose Security Groups, Create Security Group.

  3. Specify WebServerSG as the name of the security group, and provide a description. For VPC, select the ID of the VPC you created and choose Yes, Create.

  4. Choose Create Security Group again.

  5. Specify DBServerSG as the name of the security group, and provide a description. For VPC, select the ID of your VPC and choose Yes, Create.

To add rules to the WebServerSG security group

  1. 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.

  2. On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:

    1. Choose Type, HTTP. For Source, enter 0.0.0.0/0.

    2. Choose Add another rule, Type, HTTPSt. For Source, enter 0.0.0.0/0.

    3. Choose Add another rule, Type, SSH. For Source, enter your network's public IP address range.

    4. Choose Add another rule, Type, RDP. For Source, enter your network's public IP address range.

    5. Choose Save.

      Inbound rules for security group
  3. On the Outbound Rules tab, choose Edit and add rules for outbound traffic as follows:

    1. Locate the default rule that enables all outbound traffic and choose Remove.

    2. Choose Type, MS SQL. For Destination, specify the ID of the DBServerSG security group.

    3. Choose Add another rule, Type, MySQL. For Destination, specify the ID of the DBServerSG security group.

    4. Choose Add another rule, Type, HTTPS. For Destination, enter 0.0.0.0/0.

    5. Choose Add another rule, Type, HTTP. For Destination, enter 0.0.0.0/0.

    6. Choose Save.

To add the recommended rules to the DBServerSG security group

  1. 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.

  2. On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:

    1. Choose Type, MS SQL. For Source, specify the ID of your WebServerSG security group.

    2. Choose Add another rule, Type, MYSQL. For Source, specify the ID of your WebServerSG security group.

    3. Choose Save.

  3. On the Outbound Rules tab, choose Edit and add rules for outbound traffic as follows:

    1. Locate the default rule that enables all outbound traffic and choose Remove.

    2. Choose Type, HTTP. For Destination, enter 0.0.0.0/0.

    3. Choose Add another rule, Type, HTTPS. For Destination, enter 0.0.0.0/0.

    4. Choose Save.

You can now launch instances into your VPC.

To launch an instance (web server or database server)

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

  2. From the dashboard, choose Launch Instance.

  3. Select an AMI and an instance type and choose Next: Configure Instance Details.

  4. On the Configure Instance Details page, for Network, select the VPC that you created earlier and then select a subnet. For example, launch a web server into the public subnet and the database server into the private subnet.

  5. (Optional) By default, instances launched into a nondefault VPC are not assigned a public IP address. To be able to connect to your instance in the public subnet, you can assign a public IP address now, or allocate an Elastic IP address and assign it to your instance after it's launched. To assign a public IP address now, ensure that you choose Enable from the Auto-assign Public IP list. You do not need to assign a public IP address to an instance in the private subnet.

    Note

    You can only assign a public IP address to a single, new network interface with the device index of eth0. For more information, see Assigning a Public IP Address During Launch.

  6. On the next two pages of the wizard, you can configure storage for your instance, and add tags. On the Configure Security Group page, choose the Select an existing security group option, and select one of the security groups you created earlier (WebServerSG for a web server or DBServerSG for a database server). Choose Review and Launch.

  7. Review the settings that you've chosen. Make any changes that you need and choose Launch to choose a key pair and launch your instance.

If you did not assign a public IP address to your instance in the public subnet in step 5, you will not be able to connect to it. 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

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose Elastic IPs.

  3. Choose Allocate New Address.

  4. Choose Yes, Allocate.

    Note

    If your account supports EC2-Classic, first choose EC2-VPC from the Network platform list.

  5. Select the Elastic IP address from the list and choose Actions, Associate Address.

  6. In the Associate Address dialog box, select the network interface or instance. For Private IP address, select the corresponding address to associate the Elastic IP address with and choose 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 EC2 User Guide for Linux Instances. For information about how to connect to a Windows instance, see Connect to Your Windows Instance in the Amazon EC2 User Guide for Microsoft Windows Instances.

Implementing Scenario 2 with a NAT Instance

You can implement scenario 2 using a NAT instance instead of a NAT gateway. For more information about NAT instances, see NAT Instances.

You can follow the same procedures as above; however, in the NAT section of the VPC wizard, choose Use a NAT instance instead and specify the details for your NAT instance. You will also require a security group for your NAT instance (NATSG), which allows 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.

After you've created the VPC with the NAT instance, you must change the security group associated with the NAT instance to the new NATSG security group (by default, the NAT instance is launched using the default security group).

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 create the NATSG security group

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose Security Groups, and the choose Create Security Group.

  3. Specify NATSG as the name of the security group, and provide a description. For VPC, select the ID of your VPC and choose Yes, Create.

  4. 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.

  5. On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:

    1. Choose Type, HTTP . For Source, enter the IP address range of your private subnet.

    2. Choose Add another rule, Type, HTTPS. For Source, enter the IP address range of your private subnet.

    3. Choose Add another rule, Type, SSH. For Source, enter your network's public IP address range.

    4. Choose Save.

  6. On the Outbound Rules tab, choose Edit and add rules for outbound traffic as follows:

    1. Locate the default rule that enables all outbound traffic and choose Remove.

    2. Choose Type, HTTP. For Destination, enter 0.0.0.0/0.

    3. Choose Add another rule, Type, HTTPS. For Destination, enter 0.0.0.0/0.

    4. Choose Save.

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

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

  2. In the navigation pane, choose Network Interfaces.

  3. Select the network interface for the NAT instance from the list and choose Actions, Change Security Groups.

  4. In the Change Security Groups dialog box, for Security groups, select the NATSG security group that you created (see Security for Scenario 2) and choose Save.