Menu
Amazon Virtual Private Cloud
User Guide

Scenario 3: VPC with Public and Private Subnets and Hardware VPN Access

The configuration for this scenario includes a virtual private cloud (VPC) with a public subnet and a private subnet, and a virtual private gateway to enable communication with your own network over an IPsec VPN tunnel. We recommend this scenario if you want to extend your network into the cloud and also directly access the Internet from your VPC. This scenario enables you to run a multi-tiered application with a scalable web front end in a public subnet, and to house your data in a private subnet that is connected to your network by an IPsec VPN connection.

Configuration for Scenario 3

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

Diagram for scenario 3: VPC with public and private subnets and hardware VPN access

Important

For this scenario, the Amazon VPC 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 Configuration for Scenario 3

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 VPN-only 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.

  • A VPN connection between your VPC and your network. The VPN connection consists of a virtual private gateway located on the Amazon side of the VPN connection and a customer gateway located on your side of the VPN connection.

  • Instances with private IP addresses in the subnet range (examples: 10.0.0.5 and 10.0.1.5), which enables the instances 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 enables 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 VPN-only subnet are back-end servers that don't need to accept incoming traffic from the Internet, but can send and receive traffic from your network.

  • 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 VPN-only 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 Internet Gateways. For more information about your VPN connection, see Adding a Hardware Virtual Private Gateway to Your VPC. For more information about configuring a customer gateway, see the Amazon VPC Network Administrator Guide.

Routing for Scenario 3

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 VPN-only 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.

The instances in the VPN-only subnet can't reach the Internet directly; any Internet-bound traffic must first traverse the virtual private gateway to your network, where the traffic is then subject to your firewall and corporate security policies. If the instances send any AWS-bound traffic (for example, requests to the Amazon S3 or Amazon EC2 APIs), the requests must go over the virtual private gateway to your network and then egress to the Internet before reaching AWS.

Tip

Any traffic from your network going to an Elastic IP address for an instance in the public subnet goes over the Internet, and not over the virtual private gateway. You could instead set up a route and security group rules that enable the traffic to come from your network over the virtual private gateway to the public subnet.

The VPN connection is configured either as a statically-routed VPN connection or as a dynamically-routed VPN connection (using BGP). If you select static routing, you'll be prompted to manually enter the IP prefix for your network when you create the VPN connection. If you select dynamic routing, the IP prefix is advertised automatically to the virtual private gateway for your VPC using BGP.

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 for routing all other subnet traffic from the private subnet to your network over the virtual private gateway, which is specified using its AWS-assigned identifier (for example, vgw-1a2b3c4d).

DestinationTarget

10.0.0.0/16

local

0.0.0.0/0

vgw-xxxxxxxx

Custom 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 for routing all other subnet traffic from the public subnet to the Internet over the Internet gateway, which is specified using its AWS-assigned identifier (for example, igw-1a2b3c4d).

DestinationTarget

10.0.0.0/16

local

0.0.0.0/0

igw-xxxxxxxx

Alternate Routing

Alternatively, if you want instances in the private subnet to access the Internet, you could set up the routing so that the Internet-bound traffic for the subnet goes to a network address translation (NAT) gateway or instance in the public subnet. The NAT device enables the instances in the VPN-only subnet to send requests over the Internet gateway (for example, for software updates). To enable the private subnet's Internet-bound traffic to go to the NAT device, you must update the main route table as follows.

Main Route Table

The first row describes the entry for local routing in the VPC. The second row describes the entry for routing the subnet traffic bound for your customer network (in this case, 172.16.0.0/12) to the virtual private gateway, which is specified using its AWS-assigned identifier (for example, vgw-1a2b3c4d). The third row sends all other subnet traffic to a NAT gateway, which is specified by its AWS-assigned identifier (for example, nat-12345678901234567).

DestinationTarget

10.0.0.0/16

local

172.16.0.0/12

vgw-xxxxxxxx

0.0.0.0/0

nat-xxxxxxxxxxxxxxxxx

For information about setting up a NAT device manually, see NAT. For information about using the VPC wizard to set up a NAT device, see Scenario 2: VPC with Public and Private Subnets (NAT).

Security for Scenario 3

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 3, you'll use security groups but not network ACLs. If you'd like to use a network ACL, see Recommended Rules for Scenario 3.

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 security 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 VPN-only 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'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 read and write requests to the database servers in the VPN-only 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

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

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

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 VPN-only subnet. The following table describes the recommended rules for this security group, which allow Microsoft SQL Server and MySQL read and write requests from the web servers and SSH and RDP traffic from your network. The database servers can also initiate traffic bound for the Internet (your route table sends that traffic over the virtual private 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

Your network's IP address range

TCP

22

Allow inbound SSH traffic to Linux instances from your network (over the virtual private gateway)

Your network's IP address range

TCP

3389

Allow inbound RDP traffic to Windows instances from your network (over the virtual private gateway)

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) over the virtual private gateway

0.0.0.0/0

TCP

443

Allow outbound HTTPS access to the Internet (for example, for software updates) over the virtual private gateway


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 3

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

To prepare your customer gateway

  1. Determine the appliance you'll use as your customer gateway. For more information about the devices that we've tested, see Amazon Virtual Private Cloud FAQs. For more information about the requirements for your customer gateway, see the Amazon VPC Network Administrator Guide.

  2. Obtain the Internet-routable IP address for the customer gateway's external interface. The address must be static and may be behind a device performing network address translation (NAT).

  3. Gather the list of internal IP ranges (in CIDR notation) that should be advertised across the VPN connection to the virtual private gateway (if you are using a statically routed VPN connection). For more information, see VPN Routing Options.

To implement scenario 3 using the VPC wizard

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

  2. If you have no VPC resources, locate the Your Virtual Private Cloud area of the dashboard and choose Get started creating a VPC, or choose Start VPC Wizard.

  3. Select the third option, VPC with Public and Private Subnets and Hardware VPN Access, and then choose Select.

  4. On the first page of the wizard, confirm the details for your VPC, public and private subnets, and then choose Next.

  5. On the Configure your VPN page, do the following, and then choose Create VPC:

    • In Customer Gateway IP, specify the public IP address of your VPN router.

    • Optionally specify a name for your customer gateway and VPN connection.

    • In Routing Type, select one of the routing options as follows:

      • If your VPN router supports Border Gateway Protocol (BGP), select Dynamic (requires BGP).

      • If your VPN router does not support BGP, choose Static. In IP Prefix, add each IP prefix for your network.

      For more information about which option to choose, see Amazon Virtual Private Cloud FAQs. For more information about dynamic versus static routing, see VPN Routing Options.

  6. When the wizard is done, choose VPN Connections in the navigation pane. Select the VPN connection that the wizard created, and choose Download Configuration. In the dialog box, select the vendor for the customer gateway, the platform, and the software version, and then choose Yes, Download.

  7. Save the text file containing the VPN configuration and give it to the network administrator along with this guide: Amazon VPC Network Administrator Guide. The VPN won't work until the network administrator configures the customer gateway.

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.

  3. Choose Create Security Group.

  4. 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 choose Yes, Create.

  5. Choose Create Security Group again.

  6. 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 choose Yes, Create.

To add the recommended 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. Select HTTP from the Type list, and enter 0.0.0.0/0 in the Source field.

    2. Choose Add another rule, then select HTTPS from the Type list, and enter 0.0.0.0/0 in the Source field.

    3. Choose Add another rule, then select SSH from the Type list. Enter your network's public IP address range in the Source field.

    4. Choose Add another rule, then select RDP from the Type list. Enter your network's public IP address range in the Source field.

    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 then choose Remove.

    2. Select MS SQL from the Type list. In the Destination field, specify the ID of the DBServerSG security group.

    3. Choose Add another rule, then select MySQL from the Type list. In the Destination field, specify the ID of the DBServerSG security group.

    4. Choose Add another rule, then select HTTPS from the Type list. In the Destination field, enter 0.0.0.0/0.

    5. Choose Add another rule, then select HTTP from the Type list. In the Destination field, 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. Select SSH from the Type list, and enter the IP address range of your network in the Source field.

    2. Choose Add another rule, then select RDP from the Type list, and enter the IP address range of your network in the Source field.

    3. Choose Add another rule, then select MS SQL from the Type list. Specify the ID of your WebServerSG security group in the Source field.

    4. Choose Add another rule, then select MYSQL from the Type list. Specify the ID of your WebServerSG security group in the Source field.

    5. 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 then choose Remove.

    2. Select HTTP from the Type list. In the Destination field, enter 0.0.0.0/0.

    3. Choose Add another rule, then select HTTPS from the Type list. In the Destination field, enter 0.0.0.0/0.

    4. Choose Save.

After your network administrator configures your customer gateway, 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 (web server or database server)

  1. Create the WebServerSG and DBServerSG security groups if you haven't done so already (see Security for Scenario 3). You'll specify one of these security groups when you launch the instance.

  2. Start the launch wizard:

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

    2. Choose Launch Instance on the dashboard.

  3. Follow the directions in the wizard. Choose an AMI, choose an instance type, and then choose Next: Configure Instance Details.

  4. On the Configure Instance Details page, select the VPC that you created earlier from the Network list, 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 select 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, select the Select an existing security group option, and select a security group for the instance (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 then choose Launch to choose a key pair and launch your instance.

For the instances running in the VPN-only subnet, you can test their connectivity by pinging them from your network. For more information, see Testing the End-to-End Connectivity of 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 using the console

  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, choose Actions, and then choose Associate Address.

  6. 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 choose Yes, Associate.

In scenario 3, you need a DNS server that enables your public subnet to communicate with servers on the Internet, and you need another DNS server that enables your VPN-only subnet to communicate with servers in your network.

Your VPC automatically has a set of DHCP options with domain-name-servers=AmazonProvidedDNS. This is a DNS server that Amazon provides to enable any public subnets in your VPC to communicate with the Internet over an Internet gateway. You must provide your own DNS server and add it to the list of DNS servers your VPC uses. Sets of DHCP options aren't modifiable, so you must create a set of DHCP options that includes both your DNS server and the Amazon DNS server, and update the VPC to use the new set of DHCP options.

To update the DHCP options

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

  2. In the navigation pane, choose DHCP Options Sets.

  3. Choose Create DHCP Options Set.

  4. In the Create DHCP Options Set dialog box, in the Domain name servers box, specify the address of the Amazon DNS server (AmazonProvidedDNS) and the address of your DNS server, separated by a comma, and then choose Yes, Create. In this example, your DNS server is 192.0.2.1.

  5. In the navigation pane, choose Your VPCs.

  6. Select the VPC, and then choose the Edit button in the Summary tab.

  7. Select the ID of the new set of options from the DHCP options set list and then choose Save.

  8. (Optional) The VPC now uses this new set of DHCP options and therefore has access to both DNS servers. If you want, you can delete the original set of options that the VPC used.

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.