Did this page help you? Yes No Tell us about it...

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

Topics

We recommend this scenario if you want to extend your data center 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 frontend in a public subnet, and to house your data in a private subnet that is connected to your data center by an IPsec VPN connection.

	Important
	For this scenario, your network administrator needs the Amazon Virtual Private Cloud Network Administrator Guide in order to configure the customer gateway on your side of the VPN connection.

Basic Layout

The following diagram shows the basic layout of your VPC in this scenario. The big white cloud is your VPC (your isolated portion of the AWS cloud). You have an Internet gateway attached to the VPC that enables the VPC to communicate with the Internet. You also have a virtual private gateway that enables the VPC to communicate with your home network over an IPsec VPN tunnel. The circle containing an R represents your VPC's built-in routing function. The VPC has two subnets. The table following the diagram gives additional details about the VPC and its layout for this scenario.

	Tip
	The AWS Management Console has a wizard in the Amazon VPC console to help you implement this scenario. For more information, see Implementing the Scenario.

Scenario 3: VPC with an Internet Gateway and Virtual Private Gateway

	A size /16 VPC (e.g., 10.0.0.0/16), which means 65,536 private (RFC 1918) IP addresses. For information about CIDR notation and what the "/16" means, go to the Wikipedia article about Classless Inter-Domain Routing.
	An Internet gateway connecting the VPC to the Internet.
	A VPN between your VPC and home network. The entire VPN setup consists of a customer gateway, virtual private gateway, VPN attachment (connecting the virtual private gateway to the VPC), and a VPN connection. For this scenario, we refer to the VPN setup generally as your virtual private gateway or VPN connection. For more information about your VPN connection, see Adding a Hardware Virtual Private Gateway to Your VPC. To enable the VPN connection, you must have an appliance (e.g., router) in your home network that acts as the anchor on your side of the connection (for more information, go to the Amazon Virtual Private Cloud Network Administrator Guide).
	A size /24 subnet (e.g., 10.0.1.0/24), which means 256 private IP addresses. The diagram shows the subnet containing several web servers; however, they could be any kind of instance you want. Each has a private IP address (e.g., 10.0.0.5) and an Elastic IP address (e.g., 192.0.2.1), which allows the instance to be reached from the Internet. The addresses shown in the diagram are examples; you'll probably have different values when you implement the scenario. You're going to set up routing in the VPC so that the subnet can send traffic directly to the Internet (see Routing). Therefore, the subnet is labeled as public in the diagram.
	Another subnet, also size /24. In the diagram, the subnet contains backend services for your website (e.g., database servers). Each server has a private IP address (e.g., 10.0.1.5). Unlike the web servers in the public subnet, these servers don't need to accept incoming traffic from the Internet (and should not). You're going to set up the VPC so that the subnet can receive and send traffic only from your home network (in addition to talking to other subnets). Therefore, we refer to the subnet as VPN-only in the diagram.

If you want an instance in the public subnet to be reachable from the Internet, that instance must have an Elastic IP address associated with it. For more information about Elastic IP addresses, see Elastic IP Addresses.

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

Routing

Your VPC has an implied router (shown in the following diagram as an R in a circle), as well as a modifiable main route table. You can also create other route tables to use in your VPC. By default, each table has a local route that enables instances in your VPC to talk to each other.

The following diagram and table describe the route tables and routes you need to set up in this scenario.

The VPC automatically comes with a main route table. Any subnet not explicitly associated with another route table uses the main route table. For this scenario, you update the main route table with a route that sends traffic from the VPN-only subnet to the virtual private gateway (the flow of traffic is indicated by the dotted line adjacent to the table). You don't explicitly associate the VPN-only subnet with any route table, so it implicitly uses the routes in the main route table.

Your VPC can have other route tables besides the main route table. For this scenario, you must create a route table (it's labeled Custom Route Table in the preceding diagram) with a route that sends traffic from the public subnet to the Internet gateway (the flow of traffic is indicated by the dotted line adjacent to the table).

After creating the custom route table and the route, you must associate the public subnet with the table. This association is represented by the line connecting the table to the subnet in the diagram. Notice that there's no line connecting the main route table to the VPN-only subnet; the lack of line indicates an implied association with the main route table.

	Note
	For this scenario, any traffic from your home network going to 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 home network over the virtual private gateway to the public subnet.

The following two tables show what the route tables look like for this scenario. In each, the first row covers the local routing in the VPC (i.e., allows the instances in the VPC to communicate with each other).

Main Route Table

The first row provides local routing within the VPC. The second row sends all the subnet traffic over the virtual private gateway, which is specified by its AWS-assigned identifier (e.g., vgw-1a2b3c4d).

Destination	Target
10.0.0.0/16	local
0.0.0.0/0	vgw-xxxxxxxx

	Note
	If you use the wizard in the console to set up your VPC, the wizard automatically updates the main route table with the route between the VPN-only subnet and the virtual private gateway. Otherwise, you must update the main route table yourself.

Custom Route Table

The first row provides local routing within the VPC. The second row sends all traffic from the public subnet to the Internet gateway, which is specified by its AWS-assigned identifier (e.g., igw-1a2b3c4d).

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

	Note
	If you use the wizard in the console to set up your VPC, the wizard automatically creates the custom route table and associates the public subnet with it. Otherwise, you must do that yourself.

Any AWS-bound traffic from the public subnet (e.g., going to the Amazon EC2 or Amazon S3 API endpoints) is routed to the Internet gateway. If the traffic is bound for AWS in the same Region as the VPC, there's no bandwidth charge. Exception: You're charged Regional Data Transfer rates for data transferred between the Internet gateway attached to your VPC and Amazon EC2 instances in the same Region, regardless of Availability Zone.

Any AWS-bound traffic from the VPN-only subnet is routed to the virtual private gateway. The traffic must egress your home network to the Internet, so you're charged for both the bandwidth across the virtual private gateway, and the Internet bandwidth costs.

Security

AWS provides two ways for you to control security in your VPC: security groups and network ACLs. They both enable you to control what traffic goes in and out of your instances, but security groups work at the instance level, and network ACLs work at the subnet level. Security groups alone will suffice for many VPC users. However, some users might want 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.

	Important
	Security groups are a basic Amazon EC2 concept. However, security groups in a VPC have different capabilities than security groups in EC2 (see EC2 vs. VPC Security Groups).

Recommended Security Groups

For scenario 3, you use only security groups and not network ACLs. A security group is just a group of instances that share a common set of inbound and outbound rules. To use security groups, you create a group, add the rules you want to the group, and then launch instances into the group. You can add and remove rules from the group, and those changes automatically apply to the instances in the group. You can launch an instance into more than one group, and you can change an instance's group membership after launch. For more information about security groups, see 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 in the group. If you don't specify a security group when you launch an instance, the instance automatically goes into this default group. You must change the group's rules from the initial default rules if you want the instances to receive traffic from outside the group.

For this scenario, we recommend you not use the default security group and instead create the following security groups:

WebServerSG—For the web servers in the public subnet
DBServerSG—For the database servers in the VPN-only subnet

The following figures show each security group as a circle. A simplified light-gray VPC is in the background to help you understand how the different VPC parts are related. Each figure has a corresponding table that lists the inbound and outbound rules for the group and what they do.

Important

Security groups are independent of network topology. The following diagrams show security groups adjacent to subnets in the VPC. This does not indicate a relationship between the security group and the subnet. Instead, the intention is to show that one or more instances in a given subnet will be launched into the adjacent security group. For example, instances in the public subnet will be launched into the WebServerSG group, so the public subnet is shown adjacent to that group.

The instances in a given security group do not have to be in the same subnet. 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, all instances in a given security group in this scenario are in the same subnet.

Let's start with the WebServerSG security group, which you launch your web servers into. Based on the rules in the following table, the web servers can receive Internet traffic, as well as SSH and RDP traffic from your home network. The instances can also initiate traffic to the Internet and read and write data to the database server instances in the private subnet.

Note

Security groups use stateful filtering. That is, all response traffic is automatically allowed. For example, if a client on the Internet sends a request to a web server in the WebServerSG, the instance can respond, regardless of any outbound rules on the group. Likewise, if the web server initiates traffic bound to a server on the Internet, the response is allowed back in to the instance, regardless of any inbound rules on the group.

WebServerSG

Inbound
Source	Protocol	Port Range	Comments
0.0.0.0/0	TCP	80	Allow inbound HTTP access to the web servers from anyone
0.0.0.0/0	TCP	443	Allow inbound HTTPS access to the web servers from anyone
Your home network's public IP address range	TCP	22	Allow inbound SSH access to Linux/UNIX instances from your home network (over the Internet gateway)
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
0.0.0.0/0	TCP	80	Allow web servers to initiate outbound HTTP access to the Internet (e.g., for software updates)
0.0.0.0/0	TCP	443	Allow web servers to initiate outbound HTTPS access to the Internet (e.g., for software updates)
DBServerSG	TCP	1433	Allow outbound Microsoft SQL Server access to the database servers in DBServerSG
DBServerSG	TCP	3306	Allow outbound MySQL access to the database servers in 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/UNIX (SSH and MySQL) or Windows (RDP and MS SQL).

Next is the DBServerSG security group, which you launch your database servers into. Based on the rules in the following table, the database servers allow Microsoft SQL Server and MySQL read or write requests from the web servers. They allow in SSH and RDP traffic from your home network. They can also initiate traffic bound for the Internet over the virtual private gateway.

DBServerSG

Inbound
Source	Protocol	Port Range	Comments
WebServerSG	TCP	1433	Allow servers in the WebServerSG to read and write over MS SQL port 1433 to instances in DBServerSG group
WebServerSG	TCP	3306	Allow servers in the WebServerSG to read and write over MySQL port 3306 to instances in DBServerSG group
10.0.0.0/8	TCP	22	Allow inbound SSH traffic to Linux/UNIX instances from home network (over the virtual private gateway)
10.0.0.0/8	TCP	3389	Allow inbound RDP traffic to Windows instances from home network (over the VPN gateway)
Outbound
Destination	Protocol	Port Range	Comments
0.0.0.0/0	TCP	80	Allow outbound HTTP access to the Internet (e.g., for software updates) over the virtual private gateway
0.0.0.0/0	TCP	443	Allow outbound HTTPS access to the Internet (e.g., for software updates) over the virtual private gateway

Even though some instances are in the same security group (e.g, the web servers are together in the WebServerSG), they can't automatically talk to each other. By default, security groups don't contain rules that allow instances in the group to communicate with each other. Exception: the VPC's default security group has such rules. If you want to allow that type of communication, you must add a rule like the one in the following example for the WebServerSG group.

Inbound
Source	Protocol	Port Range	Comments
WebServerSG	All	All	Allow inbound traffic from WebServerSG
Outbound
Destination	Protocol	Port Range	Comments
WebServerSG	All	All	Allow outbound traffic from WebServerSG

Implementing the Scenario

This section walks you through the process of implementing scenario 3. The following figure and table show the tasks required to implement the scenario.

	Tip
	Several of the tasks are automatically handled for you if you use the wizard in the AWS Management Console. The following sections describe how to use the wizard and how to do all the tasks manually.

Scenario 3: Basic Implementation Process

Process for Implementing Scenario 3

Task 1: Prepare for the VPN Connection

Task 2: Create the VPC and Subnets

Task 3: Create and Attach the Internet Gateway

Task 4: Create a Custom Route Table and Add Rules

Task 5: Set Up the VPN Connection

Task 6: Add a Route to the Main Route Table

Task 7: Create Security Groups and Add Rules

Task 8: Launch Instances into the Subnets

Task 9: Allocate and Assign Elastic IP Addresses

Task 10: Update DHCP Options

Task 1: Prepare for the VPN Connection

In scenario 3, you set up a VPN connection between your home network and your VPC. The connection requires an appliance onsite (e.g., router) to act as your customer gateway. You need help from a network administrator in your organization to:

Determine the appliance that will be your customer gateway
Provide you 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))

For more information about the requirements for your customer gateway, go to the Amazon Virtual Private Cloud Network Administrator Guide.

If you want to use the wizard to set up your VPC, see Use the Wizard for Scenario 3. Otherwise, see Task 2: Create the VPC and Subnets to perform the process manually.

Use the Wizard for Scenario 3

You can have Amazon VPC complete tasks 2-6 for you by using the wizard in the AWS Management Console. This procedure assumes you don't already have a VPC, and that you have the IP address for your customer gateway (see the preceding section).

To use the wizard

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click VPC Dashboard.
On the VPC Dashboard, locate the Your Virtual Private Cloud area and click Get started creating a VPC.
The wizard opens and displays a page where you can select one of four options.
Select the radio button for VPC with Public and Private Subnets and Hardware VPN Access and click Continue.
A dialog box opens with a field for your customer gateway's IP address.
Enter your customer gateway's IP address and click Continue.
A confirmation page is displayed showing the CIDR blocks we use for the VPC and subnets. It also shows the IP address that you just provided for the customer gateway, as well as the instance hardware tenancy of the VPC. You can change any of these values if you want.
Make any changes you want and click Continue.
The wizard begins to create your VPC, subnets, Internet Gateway, and VPN connection. It also updates the main route table, creates a custom route table, and adds routes.
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 customer gateway's vendor, platform, and software version, and then click Yes, Download.
Save the text file containing the 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 the wizard completes, you're partway done. The next task is to create the recommended security groups. For more information, see Task 7: Create Security Groups and Add Rules).

Note that the next few sections show how to manually do tasks that the wizard already completed for you.

Task 2: Create the VPC and Subnets

If you don't use the wizard in the console, you can manually create the VPC and subnets yourself. This section shows you how.

To create your VPC and subnets

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click Your VPCs, and then click Create VPC.
In the Create VPC dialog box, enter the CIDR range you want for your VPC (e.g., 10.0.0.0/16), and then click Yes, Create.
Tip
For information about choosing the CIDR range for your VPC, see VPC Sizing.
The VPC is created and appears on the Your VPCs page. Notice that it has an ID (e.g., vpc-xxxxxxxx).
In the Navigation pane, click Subnets.
At the top of the Subnets page, click Create Subnet.
In the Create Subnet dialog box, select the VPC and Availability Zone, enter the CIDR range you want for your subnet (e.g., 10.0.0.0/24), and then click Yes, Create.
The subnet is created and appears on the Subnets page. Notice that it has an ID (e.g., subnet-xxxxxxxx). The page also shows the number of available IP addresses in the subnet, the route table associated with the subnet, and the network ACL associated with the subnet. The subnet uses the main route table and default network ACL by default.
Create a second subnet (e.g., 10.0.1.0/24) by repeating the preceding steps for creating a subnet.

You've got your VPC and subnets now. Move on to the next section to create and attach an Internet gateway to the VPC.

Task 3: Create and Attach the Internet Gateway

If you don't use the wizard in the console, you can manually create and attach the Internet gateway yourself. This section shows you how.

To create the Internet gateway

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In in the Navigation pane, click Internet Gateways, and then click Create Internet Gateway.
In the Create Internet Gateway dialog box, click Yes, Create.
The Internet gateway is created and appears on the page. Notice that it has an ID (e.g., igw-xxxxxxxx).
Select the Internet gateway and click Attach to VPC.
In the Attach to VPC dialog box, click Yes, Attach.

Your VPC has an Internet gateway attached to it now. However, no route table refers to the gateway yet, so no traffic can flow to the gateway. Move on to the next section to set up routing for the public subnet.

Task 4: Create a Custom Route Table and Add Rules

If you don't use the wizard in the console, you can manually create the required custom route table and add routes yourself. This section shows you how.

For this scenario, you create a custom route table with a route to send all the non-local traffic (i.e., 0.0.0.0/0) in the public subnet to the Internet gateway, and you associate the public subnet with the table.

To create a custom route table

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click Route Tables.
Your VPC's route tables are listed.
Click Create Route Table.
In the Create Route Table dialog box, make sure your VPC is selected and click Yes, Create.
The new route table is created and appears on the page. Notice that it has an ID (e.g., rtb-xxxxxxxx).
Select the check box for the custom route table.
The lower pane displays the route table's details.
On the Routes tab, enter 0.0.0.0/0 in the Destination field, select the ID for the Internet gateway in the Target drop-down list, and click Add.
On the Associations tab, select the ID of the public subnet and click Associate.
The public subnet is now associated with the custom route table.

The VPC now has a custom route table associated with the public subnet. The table enables traffic to flow between the subnet and the Internet gateway. Move on to the next section to set up the VPN connection for your VPC.

Task 5: Set Up the VPN Connection

If you don't use the wizard in the console, you can manually set up the VPN connection yourself. This section shows you how. You must have already prepared for the VPN connection (see Task 1: Prepare for the VPN Connection).

To set up the VPN connection

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click VPC Dashboard.
In the Your VPN Connections area of the page, click Create (if this is your first VPN) or click Add VPN Connection.
In the Add VPN Connection dialog box, enter the IP address for your customer gateway (e.g., 198.0.2.1), and then click Yes, Create.
We create your customer gateway and your virtual private gateway, attach the virtual private gateway to the VPC, and create a 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 customer gateway's vendor, platform, and software version, and then click Yes, Download.
Save the text file contain and give it to the network administrator along with this guide: Amazon Virtual Private Cloud Network Administrator Guide.

You now have a customer gateway, a virtual private gateway attached to your VPC, and a VPN connection. However, the VPN won't work until your network administrator configures your customer gateway. Also, no route table refers to the gateway yet, so no traffic can flow to the gateway. Move on to the next section to set up routing for the VPN-only subnet.

Task 6: Add a Route to the Main Route Table

If you don't use the wizard in the console, you can manually add the required route to the main route table yourself. This section shows you how.

For this scenario, you add a route that sends the traffic from the VPN-only subnet to the virtual private gateway. You don't need to associate the route table with the subnet, because it's the main route table (which is automatically associated with any subnet that isn't explicitly associated with a subnet).

To update the main route table

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click Route Tables.
Your VPC's route tables are listed.
In the list of route tables, select the check box for the main route table.
The lower pane displays the route table's details.
On the Routes tab, enter 0.0.0.0/0 in the Destination field, and select the virtual private gateway's ID in the Target drop-down list, and click Add.

The VPC's main route table now includes the new route. The route enables traffic to flow between the VPN-only subnet and the virtual private gateway. If you click the Associations tab (next to the Routes tab for the main route table), you can see which subnets use the main route table. Your VPN-only subnet is listed there because you haven't explicitly associated it to any route table.

Move on to the next section to create the security groups you need for this scenario.

Task 7: Create Security Groups and Add Rules

If you don't use the wizard in the console, you can manually create the security groups yourself and add the rules to them. This section shows you how.

You first create both groups and then add the rules to each. For details about the groups and their rules for this scenario, see Security.

To create a security group

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click Security Groups.
Your VPC's security groups are listed.
Click Create Security Group.

In the Create Security Group dialog box, enter the name for your security group (e.g., WebServerSG), enter a description of the group, select your VPC's ID from the VPC menu, and click Yes, Create.

The security group is created and appears on the Security Groups page. Notice that it has an ID (e.g., sg-xxxxxxxx). You might have to turn on the Group ID column by clicking Show/Hide in the top right corner of the page.

	Note
	This page shows all security groups that belong to your AWS account, including your VPC groups and your EC2 groups. The VPC groups have a value listed in the VPC ID column. For information about the different kinds of security groups, see Security Groups.

Repeat the preceding steps for the other group you need (DBServerSG).

Now that you've created the security groups, you can add rules to them. For a list of the rules to add, see Security.

To add rules to the WebServerSG security group

In the list of security groups, select the check box for the WebServerSG group you just created.
The lower pane displays the security group's details.
Add rules for inbound HTTP and HTTPS access to the group from anywhere:
1. On the Inbound tab, select HTTP from the Create a new rule drop-down list.
2. Make sure the Source field's value is 0.0.0.0/0 and click Add Rule.
  The rule to allow HTTP access from anywhere (i.e., 0.0.0.0/0) is added to the Inbound tab. Notice that the rule on the right is highlighted in blue, and an asterisk appears on the tab. This indicates that you still need to click Apply Rule Changes (which you'll do after you've added all the inbound rules).
3. Select HTTPS from the Create a new rule drop-down list and click Add Rule.
  The rule to allow HTTPS access from anywhere (i.e., 0.0.0.0/0) is added to the Inbound tab.
Add rules for inbound SSH and Remote Desktop (RDP) access to the group from your home network's public IP address range:
1. On the Inbound tab, select SSH from the Create a new rule drop-down list.
2. In the Source field, enter your home network's public IP address range (this example uses 192.0.2.0/24).
3. Click Add Rule.
  The rule is added to the Inbound tab.
4. Select RDP from the Create a new rule drop-down list.
5. In the Source field, enter your home network's public IP range.
6. Click Add Rule.
  The rule is added to the Inbound tab.
Click Apply Rule Changes.
The new inbound rules on the right side of the screen are no longer highlighted in blue, and the asterisk no longer appears on the tab. Those changes indicate that the new inbound rules have been applied.
Add the outbound rules to limit egress traffic from the instances:
1. On the Outbound tab, locate the default rule that enables all outbound traffic, and click Delete.
  The rule is marked for deletion, and an asterisk appears on the tab. The deletion will not take effect until you click Apply Rule Changes, which you'll do after adding new outbound rules to the group.
2. On the Outbound tab, select HTTP from the Create a new rule drop-down list.
3. Make sure the Destination field's value is 0.0.0.0/0 and click Add Rule.
  The rule is added to the Outbound tab.
4. Select HTTPS from the Create a new rule drop-down list.
5. Make sure the Destination field's value is 0.0.0.0/0 and click Add Rule.
  The rule is added to the Outbound tab.
6. Select MS SQL (for Microsoft SQL) from the Create a new rule drop-down list.
7. In the Source field, start typing sg-.
  The drop-down list displays the IDs for your security groups (e.g., sg-xxxxxxxx).
8. Select the ID for the DBServerSG group and click Add Rule.
  The rule is added to the Outbound tab.
9. Select MySQL from the Create a new rule drop-down list.
10. In the Source field, start typing sg-.
  The drop-down list displays the IDs for your security groups (e.g., sg-xxxxxxxx).
11. Select the ID for the DBServerSG group and click Add Rule.
  The rule is added to the Outbound tab.
Click Apply Rule Changes.
The new outbound rules now apply to the security group.

The VPC now includes a security group for the web servers in your subnet. The group allows HTTP/HTTPS access in and out of the group to and from anywhere. The group also allows inbound SSH and RDP access from your home network's IP range. It also allows Microsoft SQL and MySQL access to the DBServerSG group.

Now that you know how to create security groups and add rules to them, you can add rules to the DBServerSG. The following image shows what the rules look like for the DBServerSG.

Move on to the next section to launch instances in your subnets.

Task 8: Launch Instances into the Subnets

After your network administrator configures your customer gateway, you can launch instances into your VPC. If you haven't launched instances before, use the following procedure. If you're already familiar with launching Amazon EC2 instances outside a VPC, then you already know most of what you need to know. The additional items to know:

You must specify the VPC and subnet you want to launch the instances in.
You must specify the VPC security group you want the instance to be in (e.g., WebServerSG, etc.).

To launch an instance

Start the launch wizard:
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. Click Launch Instance to start the Request Instances Wizard.
3. On the Create a New Instance screen, select Classic Wizard, and then click Continue.
The first page of the wizard displays tabs that list different types of AMIs.
Select an AMI from one of the tabs. If you don't have a particular AMI you want to launch, select either the Basic 32-bit Amazon Linux AMI, or the Getting Started on Microsoft Windows Server 2008 AMI on the Quick Start tab.
After you select an AMI, the wizard steps to the Instance Details page. This is where you control settings such as the number and size of instances to launch, and which subnet to launch the instance in.
Select the Launch Instances Into Your Virtual Private Cloud option, and select the subnet you want to launch the instance in. Keep the other default settings on this page and click Continue.
The wizard steps to the next page for instance details.
The default settings on this page of the wizard and the next page are what we want, so just click Continue on each page.
The Create Key Pair page appears.
A key pair is a security credential similar to a password, which you use to securely connect to your instance once it's running. If you're new to Amazon EC2 and haven't created any key pairs yet, when the wizard displays the Create Key Pair page, the Create a new Key Pair button is selected by default. We assume you'll want a new key pair.
Create a key pair:
Tip
If you're already familiar with Amazon EC2 and have an SSH key pair already, you don't need to create a new one now. You can just select one of your existing key pairs instead.
1. On the Create Key Pair page, enter a name for your key pair (e.g., GSG_Keypair). This is the name of the private key file associated with the pair (with a .pem extension).
2. Click Create & Download your Key Pair.
  You're prompted to save the private key from the key pair to your system.
3. Save the private key in a safe place on your system. Note the location because you'll need to use the key soon to connect to the instance.
On the Configure Firewall page of the wizard, select the security group you want to use for the instance (e.g., WebServerSG or DBServerSG), and click Continue.
After you configure the firewall, the wizard steps to the Review page where you can review the settings and launch the instance.
Review your settings and launch the instance:
1. Click Launch.
  A confirmation page is displayed to let you know your instance is launching.
2. Click Close to close the confirmation page, and then click Instances in the navigation pane to view your instance's status. It takes a short time for an instance to launch. The instance's status is pending while it's launching. After a short period, your instance's status switches to running. You can click Refresh to refresh the display.

For the instances running in the VPN-only subnet, you can test their connectivity by pinging them from your home network. For more information, see How to Test the End-to-End Connectivity of Your Instance.

You now have instances running in your VPC. Move on to the next section to associate Elastic IP addresses with web servers in the public subnet.

Task 9: Allocate and Assign Elastic IP Addresses

You should have at least one instance running in each of your subnets. Now you can allocate and assign Elastic IP addresses to instances in the public subnet.

To allocate and assign an elastic IP address to an instance

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click Elastic IPs, and then click Allocate New Address.
In the Allocate New Address dialog box, in the EIP used in: drop-down list, select VPC and click Yes, Allocate.
The new address is allocated and appears on the page.
Right-click the IP address in the list and select Associate.
In the Associate Address dialog box, select the instance you want to associate the address with and click Yes, Associate.
The address is associated with the instance. Notice that the instance ID is displayed next to the IP address in the list.

Your instance now has an Elastic IP address associated with it. The instance is now accessible from the Internet. You can also access it using SSH or Remote Desktop from your home network over the Internet. Make sure to use the instance's elastic IP address and not its private IP address when you connect with SSH or RDP.

Task 10: Update DHCP Options

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 home network. Amazon provides the first DNS server (AmazonProvidedDNS). In order for your VPC to use that DNS server, your VPC must use a set of DHCP options that includes the option domain-name-servers=AmazonProvidedDNS. Your VPC automatically has a set of DHCP options with only that option (see the following image). For more information about DHCP options, see Using DHCP Options with Your VPC.

If you want DNS to work with your home network, you must provide your own DNS server, and add it to the list of DNS servers your VPC uses. To do this for scenario 3, you must create a new set of DHCP options that includes both your DNS server and the one from Amazon, and then configure the VPC to use that set of options. Sets of DHCP options aren't modifiable once they exist, so you can't just add your DNS server to the existing set of options.

To update the DHCP options

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click DHCP Options Sets, and then click Create DHCP Options Set.
In the Create DHCP Options Set dialog box, in the domain-name-servers field, enter the Amazon DNS server IP address (AmazonProvidedDNS) and your corporate DNS server, separated by a comma. In this example, your DNS server is 192.0.2.1.
Click Yes, Create.
The new set of DHCP options is created. You now have the original set that your VPC comes with and the new set you just created.
Write down the ID of the new set of options you just created.
In the Navigation pane, click Your VPCs.
Select the VPC and click Change DHCP Options Set.
In the Change DHCP Options Set dialog box, select the ID of the new set of options and click Yes, Change.

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.

Congratulations! You've implemented scenario 3. You've got a VPC with a public subnet containing instances that are reachable from the Internet (and your home network), and that can initiate traffic to the Internet. You've also got a VPN-only subnet that can communicate with your home network.

Alternate Routing

The preceding sections assume you want the Internet-bound traffic from the VPN-only subnet to go over the virtual private gateway to your home network. You could instead set up the routing so the subnet's Internet-bound traffic goes to a Network Address Translation (NAT) instance in the public subnet (scenario 2 uses a similar setup). The NAT instance enables the instances in the VPN-only subnet to send requests out to the Internet over the Internet gateway (e.g., for software updates). Amazon provides AMIs specifically to act as NAT instances in your VPC. For more information, see NAT Instances.

	Note
	The NAT instance’s primary role is actually Port Address Translation (PAT). However, we use the more widely known term NAT when referring to the instance. For information about PAT, go to the Wikipedia article about PAT.

The following diagram shows the routing for the alternative version of scenario 3. Notice that the VPN-only subnet is now labeled as private instead of VPN-only. The subnet no longer routes all its traffic to the virtual private gateway. However, it still can't be reached directly from the Internet, so we label it private.

To enable the private subnet's Internet-bound traffic to go to the NAT instance, you must add a route to the main route table.

Main Route Table

The first row provides local routing within the VPC. The second row sends all traffic bound for the home network's IP address range to the virtual private gateway, which is specified by its AWS-assigned identifier. The third row sends all remaining traffic (i.e., Internet-bound traffic) to the NAT instance, which is specified by its AWS-assigned identifier.

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

To implement the alternative version of scenario 3, use the process in the following diagram. It's very similar to the process shown for the original version of scenario 3, but with one additional task (circled in the diagram).

The console doesn't have a wizard to handle this scenario, so you must do each task yourself. Most of the basic tasks are covered earlier in this section (see Implementing the Scenario). However, the following sections describe how to:

Set up the NAT instance
Change the routing to accommodate the NAT instance
Modify the security groups and create a special security group for the NAT instance

Set Up the NAT Instance

If you're already familiar with launching Amazon EC2 instances outside a VPC, then you already know most of what you need to know about launching the NAT instance. The additional items to know:

Amazon provides NAT AMIs you can use
You must specify the VPC and subnet when you launch the instance

After the NAT instance is running, you must also do the following tasks to complete the setup:

Disable the source/destination check on the instance (instructions follow)
Allocate and assign an Elastic IP address to the instance (instructions follow)
Update the main route table with a route going to the instance
Create a NATSG security group and move the instance into the group

To launch a NAT instance

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the Navigation pane, click AMIs.
Change the Viewing settings to show Amazon AMIs using the Amazon Linux platform.
The NAT AMIs that we provide include the string ami-vpc-nat in their names
Locate the NAT AMI of your choice, right-click it, and select Launch Instance to start the launch wizard.
The wizard opens on the Instance Details page. This is where you control settings such as the number and size of instances to launch, and which subnet to launch the instance in.
Select the Launch Instances Into Your Virtual Private Cloud option, and select the public subnet in your VPC. Keep the other default settings on this page and click Continue.
The wizard steps to the next page for instance details.
The default settings on this page of the wizard and the next page are what we want, so just click Continue on each page.
The Create Key Pair page appears.
Tip
If you're already familiar with Amazon EC2 and have an SSH key pair already, you don't need to create a new one now.
A key pair is a security credential similar to a password, which you use to securely connect to your instance once it's running. If you're new to Amazon EC2 and haven't created any key pairs yet, when the wizard displays the Create Key Pair page, the Create a new Key Pair button is selected by default. It's assumed you'll want a new key pair.
Create a key pair:
1. On the Create Key Pair page, enter a name for your key pair (e.g., GSG_Keypair). This is the name of the private key file associated with the pair (with a .pem extension).
2. Click Create & Download your Key Pair.
  You're prompted to save the private key from the key pair to your system.
3. Save the private key in a safe place on your system. Note the location because you'll need to use the key soon to connect to the instance.
On the Configure Firewall page of the wizard, select the VPC's default security group for now and click Continue. Later you'll create a NATSG group and move the instance into that group.
After you configure the firewall, the wizard steps to the Review page where you can review the settings and launch the instance.
Review your settings and launch the instance:
1. Click Launch.
  A confirmation page is displayed to let you know your instance is launching.
2. Click Close to close the confirmation page, and then click Instances in the navigation pane to view your instance's status. It takes a short time for an instance to launch. The instance's status is pending while it's launching. After a short period, your instance's status switches to running. You can click Refresh to refresh the display.

You now have a NAT instance running in your VPC. For the instance to perform network address translation, you must disable source/destination checking on the instance. In other words, each EC2 instance performs source and destination checking by default. This means the instance must be the source or destination of any traffic it sends or receives. However, the NAT instance needs to be able to send and receive traffic where the eventual source or destination is not the NAT instance itself. To enable that behavior, you must disable source/destination checking on the NAT instance.

To disable source/destination checking on the NAT instance

	Note
	This procedure only works for EC2 instances that are running within a VPC.

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the Navigation pane, click Instances.
Right-click the NAT instance in the list of instances, and select Change Source / Dest Check.
The Change Source/Dest. Check dialog box opens.
For a regular instance, the value should be Enabled, indicating that the instance is performing source/destination checking. For a NAT instance, you want the value to be Disabled.
Click Yes, Disable.

Source/destination checking for the instance is disabled. Your NAT is one step closer to being able to do its job.

Your NAT instance also needs an Elastic IP address.

To allocate and assign an Elastic IP address to an instance

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the Navigation pane, click Elastic IPs, and then click Allocate New Address.
In the Allocate New Address dialog box, in the EIP used in: drop-down list, select VPC, and then click Yes, Allocate.
The new address is allocated and appears on the page.
Right-click the IP address in the list and select Associate.
In the Associate Address dialog box, select the instance you want to associate the address with and click Yes, Associate.
The address is associated with the instance. Notice that the instance ID is displayed next to the IP address in the list.

Your NAT instance now has an Elastic IP address associated with it. The instance is currently in the default security group. After you've created your security groups, you need to move the NAT instance into the NATSG group (see Task 6: Create Security Groups and Add Rules).

Add Routes to Main Route Table

For this alternate scenario, you must set up the main route table so that traffic bound for the home network goes to the virtual private gateway, and all remaining traffic goes to the NAT instance. The following table shows what the main route table would look like.

Main Route Table

The first row provides local routing in the VPC. The second row in the table sends the subnet traffic bound for the home network to the virtual private gateway, which is specified by its AWS-assigned identifier (e.g., vgw-xxxxxxxx). The third row sends all remaining subnet traffic to the NAT instance, which is specified by its AWS-assigned identifier (e.g., i-xxxxxxxx).

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

For general instructions on creating route tables and adding routes, see Task 4: Create a Custom Route Table and Add Rules.

Create NATSG Security Group

For this alternate scenario, you must create a security group for the NAT instance (we'll call it NATSG) in addition to the other security groups described earlier (see Security). You also must move the NAT instance into the NATSG group.

The following figure and table show the NATSG group and its rules.

NATSG

Inbound
Source	Protocol	Port Range	Comments
10.0.1.0/24	TCP	80	Allow inbound HTTP traffic from servers in private subnet
10.0.1.0/24	TCP	443	Allow inbound HTTPS traffic from servers in private subnet
Public IP address range of your home network	TCP	22	Allow inbound SSH access to the Linux/UNIX NAT instance from your home 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
0.0.0.0/0	TCP	443	Allow outbound HTTPS access to the Internet

The following image shows what the rules look like for the NATSG security group.

For general instructions on how to create a security group, see Task 7: Create Security Groups and Add Rules.

When you launched the NAT instance, you put it in the default security group in the VPC. You now need to move it into the NATSG group.

To change an instance's group membership

	Note
	The following procedure works only for VPC instances. You can't change security group membership for standard (EC2) instances.

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the Navigation pane, click Instances.
Right-click the NAT instance in the list of instances, and select Change Security Groups.
The Change Security Groups dialog box opens, with the default group selected (the instance is in the default group currently).

From the drop-down list, select the NATSG group, and then click Yes, Change.

	Tip
	When changing an instance's group membership, you can select multiple groups from the list. The new list of groups you select replaces the instance's current list of groups. An instance can be in a maximum of five VPC security groups.

The NAT instance is now in the NATSG security group. Your instances in the private subnet can now reach the Internet via the NAT instance.

Document Conventions
Terms of Use

Did this page help you? Yes No Tell us about it...

	Tip
	For information about choosing the CIDR range for your VPC, see VPC Sizing.

	Tip
	If you're already familiar with Amazon EC2 and have an SSH key pair already, you don't need to create a new one now. You can just select one of your existing key pairs instead.