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

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.

Topics

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 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 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, such as Amazon Simple Storage Service (Amazon S3).
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. 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 Adding an Internet Gateway to Your VPC. 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 Virtual Private Cloud 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).

Destination	Target
`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).

Destination	Target
`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) instance in the public subnet. The NAT instance 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 instance, 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 network 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 the NAT instance, which is specified by its AWS-assigned identifier (for example, i-1a2b3c4d).

Destination	Target
`10.0.0.0/16`	local
`172.16.0.0/12`	`vgw`-xxxxxxxx
`0.0.0.0/0`	`i`-xxxxxxxx

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

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. For more information about security groups, see Security Groups for Your VPC.

Topics

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

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 a 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 and DBServerSG Security Groups

To create the WebServerSG 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 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 server instances in the VPN-only 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 the recommended 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 address 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 DBServerSG Security Group

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 public IP address range	TCP	22	Allow inbound SSH traffic to Linux instances from your network (over the virtual private gateway)
Your network's public 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

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 SSH from the Create a new rule list. In the Source box, specify the IP address range of your network, and then click Add Rule.
2. Select RDP from the Create a new rule list. In the Source box, specify the IP address range of your network, and then click Add Rule.
3. 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.
4. 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.
5. 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 3

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

To prepare your customer gateway

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 Virtual Private Cloud Network Administrator Guide.
Obtain the Internet-routable IP address for the customer gateway's external interface. The address must be static and can't be behind a device performing network address translation (NAT).
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

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 third option, VPC with Public and Private Subnets and Hardware VPN Access, and then click Continue.
In the Create an Amazon Virtual Private Cloud dialog box, do the following, and then click Continue:
- In IP Address, specify the public IP address of your VPN router.
- In Specify the routing for the VPN Connection, select one of the routing options as follows:
  - If your VPN router supports Border Gateway Protocol (BGP), select Use dynamic routing (requires BGP).
  - If your VPN router does not support BGP, click Use static routing. 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.
Verify the information on the confirmation page. Make any changes that you want, and then click Create VPC to create the VPC, subnets, route table, Internet gateway, and VPN connection.
When the wizard is done, a confirmation dialog box is displayed with a button for downloading the configuration for your customer gateway. Click Download Configuration.
In the Download Configuration dialog box, select the vendor for the customer gateway, the platform, and the software version, and then click Yes, Download.
Save the text file containing the VPN configuration and give it to the network administrator along with this guide: Amazon Virtual Private Cloud Network Administrator Guide. The VPN won't work until the network administrator configures the customer gateway.

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

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

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.

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.

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

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
Click DHCP Options Setsin the navigation pane.
Click the Create DHCP Options Set button.
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 click Yes, Create. In this example, your DNS server is 192.0.2.1.
Click Your VPCs in the navigation pane.
Select the VPC, and then click the Change DHCP Options Set button.
In the Change DHCP Options Set dialog box, select the ID of the new set of options from the list, and then click Yes, Change.
(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 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...