VPC Virtual Private Network

Amazon Virtual Private Cloud (VPC)

Amazon Virtual Private Cloud (Amazon VPC) lets you provision a logically isolated section of the Amazon Web Services (AWS) cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways. You can use both IPv4 and IPv6 in your VPC for secure and easy access to resources and applications.

You can easily customize the network configuration for your Amazon Virtual Private Cloud. For example, you can create a public-facing subnet for your webservers that has access to the Internet, and place your backend systems such as databases or application servers in a private-facing subnet with no Internet access. You can leverage multiple layers of security, including security groups and network access control lists, to help control access to Amazon EC2 instances in each subnet.

Additionally, you can create a Hardware Virtual Private Network (VPN) connection between your corporate datacenter and your VPC and leverage the AWS cloud as an extension of your corporate datacenter.

_______________________________________________

IP Classes Calculation

Class A - 0-127 (1-126 usable range)
1.0.0.0/8 - 126.255.255.2558

Class B -128.0.0.0/16-192.255.255.255/16

Class C - 192.0.0.0/24 - 223.255.255.255/24

Private range:

class A - 10.x.x.x/8
class B - 172.16.0.0/16 - 172.31.255.255/16
Class C - 192.168.x.x/24

xxxxxxxx.xxxxxxx.xxxxxxxx.xxxxxxxx

255.0.0.0
255.255.0.0
255.255.255.0

128 64 32 16 8 4 2 1

111111111.11000000.00000000.00000000

1 1 1 1 1 1 1 1
128 64 32 16 8 4 2 1

255.255.255.0 - 192.168.0.0-192.168.0.255

binary value

00
10
01
11

---------------------------------------------------------------------------------

Features and Benefits

Multiple Connectivity Options

A variety of connectivity options exist for your Amazon Virtual Private Cloud. You can connect your VPC to the Internet, to your datacenter, or other VPC's, based on the AWS resources that you want to expose publicly and those that you want to keep private.

Connect directly to the Internet (public subnets)– You can launch instances into a publicly accessible subnet where they can send and receive traffic from the Internet.
Connect to the Internet using Network Address Translation (private subnets)– Private subnets can be used for instances that you do not want to be directly addressable from the Internet. Instances in a private subnet can access the Internet without exposing their private IP address by routing their traffic through a Network Address Translation (NAT) gateway in a public subnet.
Connect securely to your corporate datacenter– All traffic to and from instances in your VPC can be routed to your corporate datacenter over an industry standard, encrypted IPsec hardware VPN connection.
Connect privately to other VPCs- Peer VPCs together to share resources across multiple virtual networks owned by your or other AWS accounts.
Connect to Amazon S3 without using an internet gateway or NAT, and control what resources, requests, or users are allowed through a VPC endpoint.
Combine connectivity methods to match the needs of your application– You can connect your VPC to both the Internet and your corporate datacenter and configure Amazon VPC route tables to direct all traffic to its proper destination.

Secure

Amazon VPC provides advanced security features such as security groups and network access control lists to enable inbound and outbound filtering at the instance level and subnet level. In addition, you can store data in Amazon S3 and restrict access so that it’s only accessible from instances in your VPC. Optionally, you can also choose to launch Dedicated Instances which run on hardware dedicated to a single customer for additional isolation.

Simple

You can create a VPC quickly and easily using the AWS Management Console. You can select one of the common network setups that best match your needs and press "Start VPC Wizard." Subnets, IP ranges, route tables, and security groups are automatically created for you, so you can concentrate on creating the applications to run in your VPC.

All the Scalability and Reliability of AWS

Amazon VPC provides all the same benefits as the rest of the AWS platform. You can instantly scale your resources up or down, select Amazon EC2 instances types and sizes that are right for your applications, and pay only for the resources you use - all within Amazon’s proven infrastructure.

Use Cases

Host a simple, public-facing website

You can host a basic web application, such as a blog or simple website in a VPC, and gain the additional layers of privacy and security afforded by Amazon VPC. You can help secure the website by creating security group rules which allow the webserver to respond to inbound HTTP and SSL requests from the Internet while simultaneously prohibiting the webserver from initiating outbound connections to the Internet. You can create a VPC that supports this use case by selecting "VPC with a Single Public Subnet Only" from the Amazon VPC console wizard.

Host multi-tier web applications

You can use Amazon VPC to host multi-tier web applications and strictly enforce access and security restrictions between your webservers, application servers, and databases. You can launch webservers in a publicly accessible subnet and application servers and databases in non-publically accessible subnets. The application servers and databases can’t be directly accessed from the Internet, but they can still access the Internet via a NAT gateway to download patches, for example. You can control access between the servers and subnets using inbound and outbound packet filtering provided by network access control lists and security groups. To create a VPC that supports this use case, you can select "VPC with Public and Private Subnets" in the Amazon VPC console wizard.

Host scalable web applications in the AWS cloud that are connected to your datacenter

You can create a VPC where instances in one subnet, such as webservers, communicate with the Internet while instances in another subnet, such as application servers, communicate with databases on your corporate network. An IPsec VPN connection between your VPC and your corporate network helps secure all communication between the application servers in the cloud and databases in your datacenter. Webservers and application servers in your VPC can leverage Amazon EC2 elasticity and Auto Scaling features to grow and shrink as needed. You can create a VPC to support this use case by selecting "VPC with Public and Private Subnets and Hardware VPN Access" in the Amazon VPC console wizard.

Extend your corporate network into the cloud

You can move corporate applications to the cloud, launch additional webservers, or add more compute capacity to your network by connecting your VPC to your corporate network. Because your VPC can be hosted behind your corporate firewall, you can seamlessly move your IT resources into the cloud without changing how your users access these applications. You can select "VPC with a Private Subnet Only and Hardware VPN Access" from the Amazon VPC console wizard to create a VPC that supports this use case.

Disaster Recovery

You can periodically backup your mission critical data from your datacenter to a small number of Amazon EC2 instances with Amazon Elastic Block Store (EBS) volumes, or import your virtual machine images to Amazon EC2. In the event of a disaster in your own datacenter, you can quickly launch replacement compute capacity in AWS to ensure business continuity. When the disaster is over, you can send your mission critical data back to your datacenter and terminate the Amazon EC2 instances that you no longer need. By using Amazon VPC for disaster recovery, you can have all the benefits of a disaster recovery site at a fraction of the normal cost.

VPC Types

Scenario 1: VPC with a Single Public Subnet.
Scenario 2: VPC with Public and Private Subnets (NAT)
Scenario 3: VPC with Public and Private Subnets and AWS Managed VPN Access.
Scenario 4: VPC with a Private Subnet Only and AWS Managed VPN Access.
Example: Create an IPv4 VPC and Subnets Using the AWS CLI.

Scenario 1: VPC with a Single Public Subnet

The configuration for this scenario includes a virtual private cloud (VPC) with a single public subnet, and an Internet gateway to enable communication over the Internet. We recommend this configuration if you need to run a single-tier, public-facing web application, such as a blog or a simple website.

This topic assumes that you'll use the VPC wizard in the Amazon VPC console to create the VPC.

This scenario can also be optionally configured for IPv6—you can use the VPC wizard to create a VPC and subnet with associated IPv6 CIDR blocks. Instances launched into the public subnet can receive IPv6 addresses, and communicate using IPv6. For more information about IPv4 and IPv6 addressing, see IP Addressing in Your VPC.

Topics

Overview

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

Diagram for scenario 1: VPC with a public subnet

Note

If you completed the exercise Getting Started, then you've already implemented this scenario using the VPC wizard in the Amazon VPC console.

The configuration for this scenario includes the following:

A virtual private cloud (VPC) with a size /16 IPv4 CIDR block (example: 10.0.0.0/16). This provides 65,536 private IPv4 addresses.
A subnet with a size /24 IPv4 CIDR block (example: 10.0.0.0/24). This provides 256 private IPv4 addresses.
An Internet gateway. This connects the VPC to the Internet and to other AWS services.
An instance with a private IPv4 address in the subnet range (example: 10.0.0.6), which enables the instance to communicate with other instances in the VPC, and an Elastic IPv4 address (example: 198.51.100.2), which is a public IPv4 address that enables the instance to be reached from the Internet.
A custom route table associated with the subnet. The route table entries enable instances in the subnet to use IPv4 to communicate with other instances in the VPC, and to communicate directly over the Internet. A subnet that's associated with a route table that has a route to an Internet gateway is known as a public subnet.

For more information about subnets, see VPCs and Subnets. For more information about Internet gateways, see Internet Gateways.

Overview for IPv6

You can optionally enable IPv6 for this scenario. In addition to the components listed above, the configuration includes the following:

A size /56 IPv6 CIDR block associated with the VPC (example: 2001:db8:1234:1a00::/56). Amazon automatically assigns the CIDR; you cannot choose the range yourself.
A size /64 IPv6 CIDR block associated with the public subnet (example: 2001:db8:1234:1a00::/64). You can choose the range for your subnet from the range allocated to the VPC. You cannot choose the size of the subnet IPv6 CIDR block.
An IPv6 address assigned to the instance from the subnet range (example: 2001:db8:1234:1a00::123).
Route table entries in the custom route table that enable instances in the VPC to use IPv6 to communicate with each other, and directly over the Internet.

Routing

Your VPC has an implied router (shown in the configuration diagram above). In this scenario, the VPC wizard creates a custom route table that routes all traffic destined for an address outside the VPC to the Internet gateway, and associates this route table with the subnet.

The following table shows the route table for the example in the configuration diagram above. The first entry is the default entry for local IPv4 routing in the VPC; this entry enables the instances in this VPC to communicate with each other. The second entry routes all other IPv4 subnet traffic to the Internet gateway (for example, igw-1a2b3c4d).

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

Routing for IPv6

If you associate an IPv6 CIDR block with your VPC and subnet, your route table must include separate routes for IPv6 traffic. The following table shows the custom route table for this scenario if you choose to enable IPv6 communication in your VPC. The second entry is the default route that's automatically added for local routing in the VPC over IPv6. The fourth entry routes all other IPv6 subnet traffic to the Internet gateway.

Destination	Target
10.0.0.0/16	local
2001:db8:1234:1a00::/56	local
0.0.0.0/0	igw-id
::/0	igw-id

Security

AWS provides two features that you can use to increase security in your VPC: security groupsand network ACLs. Security groups control inbound and outbound traffic for your instances, and network ACLs control inbound and outbound traffic for your subnets. In most cases, security groups can meet your needs; however, you can also use network ACLs if you want an additional layer of security for your VPC. For more information, see Security.

For this scenario, you use a security group but not a network ACL. If you'd like to use a network ACL, see Recommended Rules for Scenario 1.

Your VPC comes with a default security group. An instance that's launched into the VPC is automatically associated with the default security group if you don't specify a different security group during launch. You can add rules to the default security group, but the rules may not be suitable for other instances that you launch into the VPC. Instead, we recommend that you create a custom security group for your web server.

For this scenario, create a security group named WebServerSG. When you create a security group, it has a single outbound rule that allows all traffic to leave the instances. You must modify the rules to enable inbound traffic and restrict the outbound traffic as needed. You specify this security group when you launch instances into the VPC.

The following are the inbound and outbound rules for IPv4 traffic for the WebServerSG security group.

Inbound
Source	Protocol	Port Range	Comments
0.0.0.0/0	TCP	80	Allow inbound HTTP access to the web servers from any IPv4 address.
0.0.0.0/0	TCP	443	Allow inbound HTTPS access to the web servers from any IPv4 address
Public IPv4 address range of your network	TCP	22	(Linux instances) Allow inbound SSH access from your network over IPv4. You can get the public IPv4 address of your local computer using a service such as http://checkip.amazonaws.com. If you are connecting through an ISP or from behind your firewall without a static IP address, you need to find out the range of IP addresses used by client computers.
Public IPv4 address range of your network	TCP	3389	(Windows instances) Allow inbound RDP access from your network over IPv4.
The security group ID (sg-xxxxxxxx)	All	All	(Optional) Allow inbound traffic from other instances associated with this security group. This rule is automatically added to the default security group for the VPC; for any custom security group you create, you must manually add the rule to allow this type of communication.
Outbound (Optional)
Destination	Protocol	Port Range	Comments
0.0.0.0/0	All	All	Default rule to allow all outbound access to any IPv4 address. If you want your web server to initiate outbound traffic, for example, to get software updates, you can leave the default outbound rule. Otherwise, you can remove this rule.

Security for IPv6

If you associate an IPv6 CIDR block with your VPC and subnet, you must add separate rules to your security group to control inbound and outbound IPv6 traffic for your web server instance. In this scenario, the web server will be able to receive all Internet traffic over IPv6, and SSH or RDP traffic from your local network over IPv6.

The following are the IPv6-specific rules for the WebServerSG security group (which are in addition to the rules listed above).

Inbound
Source	Protocol	Port Range	Comments
::/0	TCP	80	Allow inbound HTTP access to the web servers from any IPv6 address.
::/0	TCP	443	Allow inbound HTTPS access to the web servers from any IPv6 address.
IPv6 address range of your network	TCP	22	(Linux instances) Allow inbound SSH access over IPv6 from your network.
IPv6 address range of your network	TCP	3389	(Windows instances) Allow inbound RDP access over IPv6 from your network
Outbound (Optional)
Destination	Protocol	Port Range	Comments
::/0	All	All	Default rule to allow all outbound access to any IPv6 address. If you want your web server to initiate outbound traffic, for example, to get software updates, you can leave the default outbound rule. Otherwise, you can remove this rule.

Implementing Scenario 1

To implement scenario 1, create a VPC using the VPC wizard, create and configure the WebServerSG security group, and then launch an instance into your VPC.

These procedures include optional steps for enabling and configuring IPv6 communication for your VPC. You do not have to perform these steps if you do not want to use IPv6 in your VPC.

To create a VPC

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the dashboard, choose Start VPC Wizard.
Select the first option, VPC with a Single Public Subnet, and then choose Select.
For VPC name and Subnet name, you can name your VPC and subnet to help you to identify them later in the console. You can specify your own IPv4 CIDR block range for the VPC and subnet, or you can leave the default values (10.0.0.0/16 and 10.0.0.0/24 respectively).
(Optional, IPv6-only) For IPv6 CIDR block, choose Amazon-provided IPv6 CIDR block. For Public subnet's IPv6 CIDR, choose Specify a custom IPv6 CIDR and specify the hexadecimal pair value for your subnet, or leave the default value (00).
You can leave the rest of the default settings, and choose Create VPC.

To create the WebServerSG security group

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Security Groups.
Choose Create Security Group.
Provide a name and description for the security group. In this topic, the nameWebServerSG is used as an example. Select the ID of your VPC from the VPC menu, and then choose Yes, Create.
Select the WebServerSG security group that you just created. The details pane include a tab for information about the security group, plus tabs for working with its inbound rules and outbound rules.
On the Inbound Rules tab, choose Edit, and then do the following:
- Select HTTP from the Type list, and enter 0.0.0.0/0 in the Source field.
- Choose Add another rule, then select HTTPS from the Type list, and enter 0.0.0.0/0 in the Source field.
- Choose Add another rule, then select SSH (for Linux) or RDP (for Windows) from the Type list. Enter your network's public IP address range in the Source field. (If you don't know this address range, you can use 0.0.0.0/0 for testing purposes; in production, you authorize only a specific IP address or range of addresses to access your instance.)
- (Optional) Choose Add another rule, then select ALL traffic from the Type list. In the Source field, enter the ID of the WebServerSG security group.
- (Optional, IPv6-only) Choose Add another rule, select HTTP from the Type list, and enter ::/0 in the Source field.
- (Optional, IPv6-only) Choose Add another rule, select HTTPS from the Type list, and enter ::/0 in the Source field.
- (Optional, IPv6-only) Choose Add another rule, select SSH (for Linux) or RDP (for Windows) from the Type list. Enter your network's IPv6 address range in the Source field. (If you don't know this address range, you can use ::/0 for testing purposes; in production, you authorize only a specific IPv6 address or range of addresses to access your instance.)
Choose Save.
(Optional) On the Outbound Rules tab, choose Edit. Locate the default rule that enables all outbound traffic, choose Remove, and then choose Save.

To launch an instance into the VPC

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
From the dashboard, choose Launch Instance.
Follow the directions in the wizard. Choose an AMI, choose an instance type, and then choose Next: Configure Instance Details.

Note

If you intend to use your instance for IPv6 communication, you must choose a supported instance type; for example, T2. For more information, seeAmazon EC2 Instance Types.
On the Configure Instance Details page, select the VPC that you created in step 1 from the Network list, and then specify a subnet.
(Optional) By default, instances launched into a nondefault VPC are not assigned a public IPv4 address. To be able to connect to your instance, you can assign a public IPv4 address now, or allocate an Elastic IP address and assign it to your instance after it's launched. To assign a public IPv4 address now, ensure that you select Enable from the Auto-assign Public IP list.

Note

You can only use the auto-assign public IP feature for a single, new network interface with the device index of eth0. For more information, see Assigning a Public IPv4 Address During Instance Launch.
(Optional, IPv6-only) You can auto-assign an IPv6 address to your instance from the subnet range. For Auto-assign IPv6 IP, choose Enable.
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 the WebServerSG security group that you created in step 2. Choose Review and Launch.
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.
If you did not assign a public IPv4 address to your instance in step 5, you will not be able to connect to it over IPv4. Assign an Elastic IP address to the instance:
1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
2. In the navigation pane, choose Elastic IPs.
3. Choose Allocate new address.
4. Choose Allocate.
  
  Note
  
  If your account supports EC2-Classic, first choose VPC.
5. Select the Elastic IP address from the list, choose Actions, and then choose Associate address.
6. Select the instance to associate the address with, and then choose Associate.

You can now connect to your instances in the VPC. For information about how to connect to a Linux instance, see Connect to Your Linux Instance in the Amazon EC2 User Guide for Linux Instances. For information about how to connect to a Windows instance, see Connect to Your Windows Instance in the Amazon EC2 User Guide for Windows Instances.

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

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

The instances in the public subnet can send outbound traffic directly to the Internet, whereas the instances in the private subnet can't. Instead, the instances in the private subnet can access the Internet by using a network address translation (NAT) gateway that resides in the public subnet. The database servers can connect to the Internet for software updates using the NAT gateway, but the Internet cannot establish connections to the database servers.

Note

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

This topic assumes that you'll use the VPC wizard in the Amazon VPC console to create the VPC and NAT gateway.

This scenario can also be optionally configured for IPv6—you can use the VPC wizard to create a VPC and subnets with associated IPv6 CIDR blocks. Instances launched into the subnets can receive IPv6 addresses, and communicate using IPv6. Instances in the private subnet can use an egress-only Internet gateway to connect to the Internet over IPv6, but the Internet cannot establish connections to the private instances over IPv6. For more information about IPv4 and IPv6 addressing, see IP Addressing in Your VPC.

Topics

Overview

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

Diagram for scenario 2: VPC with public and private subnets

The configuration for this scenario includes the following:

A VPC with a size /16 IPv4 CIDR block (example: 10.0.0.0/16). This provides 65,536 private IPv4 addresses.
A public subnet with a size /24 IPv4 CIDR block (example: 10.0.0.0/24). This provides 256 private IPv4 addresses. A public subnet is a subnet that's associated with a route table that has a route to an Internet gateway.
A private subnet with a size /24 IPv4 CIDR block (example: 10.0.1.0/24). This provides 256 private IPv4 addresses.
An Internet gateway. This connects the VPC to the Internet and to other AWS services.
Instances with private IPv4 addresses in the subnet range (examples: 10.0.0.5, 10.0.1.5). This enables them to communicate with each other and other instances in the VPC.
Instances in the public subnet with Elastic IPv4 addresses (example: 198.51.100.1), which are public IPv4 addresses that enable them to be reached from the Internet. The instances can have public IP addresses assigned at launch instead of Elastic IP addresses. Instances in the private subnet are back-end servers that don't need to accept incoming traffic from the Internet and therefore do not have public IP addresses; however, they can send requests to the Internet using the NAT gateway (see the next bullet).
A NAT gateway with its own Elastic IPv4 address. Instances in the private subnet can send requests to the Internet through the NAT gateway over IPv4 (for example, for software updates).
A custom route table associated with the public subnet. This route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC over IPv4, and an entry that enables instances in the subnet to communicate directly with the Internet over IPv4.
The main route table associated with the private subnet. The route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC over IPv4, and an entry that enables instances in the subnet to communicate with the Internet through the NAT gateway over IPv4.

For more information about subnets, see VPCs and Subnets. For more information about Internet gateways, see Internet Gateways. For more information about NAT gateways, see NAT Gateways.

Overview for IPv6

You can optionally enable IPv6 for this scenario. In addition to the components listed above, the configuration includes the following:

A size /56 IPv6 CIDR block associated with the VPC (example: 2001:db8:1234:1a00::/56). Amazon automatically assigns the CIDR; you cannot choose the range yourself.
A size /64 IPv6 CIDR block associated with the public subnet (example: 2001:db8:1234:1a00::/64). You can choose the range for your subnet from the range allocated to the VPC. You cannot choose the size of the VPC IPv6 CIDR block.
A size /64 IPv6 CIDR block associated with the private subnet (example: 2001:db8:1234:1a01::/64). You can choose the range for your subnet from the range allocated to the VPC. You cannot choose the size of the subnet IPv6 CIDR block.
IPv6 addresses assigned to the instances from the subnet range (example: 2001:db8:1234:1a00::1a).
An egress-only Internet gateway. This enables instances in the private subnet to send requests to the Internet over IPv6 (for example, for software updates). An egress-only Internet gateway is necessary if you want instances in the private subnet to be able to initiate communication with the Internet over IPv6. For more information, see Egress-Only Internet Gateways.
Route table entries in the custom route table that enable instances in the public subnet to use IPv6 to communicate with each other, and directly over the Internet.
Route table entries in the main route table that enable instances in the private subnet to use IPv6 to communicate with each other, and to communicate with the Internet through an egress-only Internet gateway.

IPv6-enabled VPC with a public and private subnet

Routing

In this scenario, the VPC wizard updates the main route table used with the private subnet, and creates a custom route table and associates it with the public subnet.

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

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

The following tables describe the route tables for this scenario.

Main Route Table

The first entry is the default entry for local routing in the VPC; this entry enables the instances in the VPC to communicate with each other. The second entry sends all other subnet traffic to the NAT gateway (for example, nat-12345678901234567).

Destination	Target
`10.0.0.0/16`	local
`0.0.0.0/0`	nat-gateway-id

Custom Route Table

The first entry is the default entry for local routing in the VPC; this entry enables the instances in this VPC to communicate with each other. The second entry routes all other subnet traffic to the Internet over the Internet gateway (for example, igw-1a2b3d4d).

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

Routing for IPv6

If you associate an IPv6 CIDR block with your VPC and subnets, your route tables must include separate routes for IPv6 traffic. The following tables show the route tables for this scenario if you choose to enable IPv6 communication in your VPC.

Main Route Table

The second entry is the default route that's automatically added for local routing in the VPC over IPv6. The fourth entry routes all other IPv6 subnet traffic to the egress-only Internet gateway.

Destination	Target
10.0.0.0/16	local
2001:db8:1234:1a00::/56	local
0.0.0.0/0	nat-gateway-id
::/0	egress-only-igw-id

Custom Route Table

The second entry is the default route that's automatically added for local routing in the VPC over IPv6. The fourth entry routes all other IPv6 subnet traffic to the Internet gateway.

Destination	Target
10.0.0.0/16	local
2001:db8:1234:1a00::/56	local
0.0.0.0/0	igw-id
::/0	igw-id

Security

For scenario 2, you'll use security groups but not network ACLs. If you'd like to use a network ACL, see Recommended Rules for Scenario 2.

Your VPC comes with a default security group. An instance that's launched into the VPC is automatically associated with the default security group if you don't specify a different security group during launch. For this scenario, we recommend that you create the following security groups instead of using the default security group:

WebServerSG: Specify this security group when you launch the web servers in the public subnet.
DBServerSG: Specify this security group when you launch the database servers in the private subnet.

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

The following table describes the recommended rules for the WebServerSG security group, which allow the web servers to receive Internet traffic, as well as SSH and RDP traffic from your network. The web servers can also initiate read and write requests to the database servers in the private subnet, and send traffic to the Internet; for example, to get software updates. Because the web server doesn't initiate any other outbound communication, the default outbound rule is removed.

Note

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

WebServerSG: Recommended Rules

Inbound
Source	Protocol	Port Range	Comments
0.0.0.0/0	TCP	80	Allow inbound HTTP access to the web servers from any IPv4 address.
0.0.0.0/0	TCP	443	Allow inbound HTTPS access to the web servers from any IPv4 address.
Your home network's public IPv4 address range	TCP	22	Allow inbound SSH access to Linux instances from your home network (over the Internet gateway). You can get the public IPv4 address of your local computer using a service such as http://checkip.amazonaws.com. If you are connecting through an ISP or from behind your firewall without a static IP address, you need to find out the range of IP addresses used by client computers.
Your home network's public IPv4 address range	TCP	3389	Allow inbound RDP access to Windows instances from your home network (over the Internet gateway).
Outbound
Destination	Protocol	Port Range	Comments
The ID of your DBServerSG security group	TCP	1433	Allow outbound Microsoft SQL Server access to the database servers assigned to the DBServerSG security group.
The ID of your DBServerSG security group	TCP	3306	Allow outbound MySQL access to the database servers assigned to the DBServerSG security group.
0.0.0.0/0	TCP	80	Allow outbound HTTP access to any IPv4 address.
0.0.0.0/0	TCP	443	Allow outbound HTTPS access to any IPv4 address.

The following table describes the recommended rules for the DBServerSG security group, which allow read or write database requests from the web servers. The database servers can also initiate traffic bound for the Internet (the route table sends that traffic to the NAT gateway, which then forwards it to the Internet over the Internet gateway).

DBServerSG: Recommended Rules

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

(Optional) 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 for a custom security group, you must add the following 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 to other instances assigned to this security group.

Security for IPv6

If you associate an IPv6 CIDR block with your VPC and subnets, you must add separate rules to your WebServerSG and DBServerSG security groups to control inbound and outbound IPv6 traffic for your instances. In this scenario, the web servers will be able to receive all Internet traffic over IPv6, and SSH or RDP traffic from your local network over IPv6. They can also initiate outbound IPv6 traffic to the Internet. The database servers can initiate outbound IPv6 traffic to the Internet.

The following are the IPv6-specific rules for the WebServerSG security group (which are in addition to the rules listed above).

Inbound
Source	Protocol	Port Range	Comments
::/0	TCP	80	Allow inbound HTTP access to the web servers from any IPv6 address.
::/0	TCP	443	Allow inbound HTTPS access to the web servers from any IPv6 address.
IPv6 address range of your network	TCP	22	(Linux instances) Allow inbound SSH access over IPv6 from your network.
IPv6 address range of your network	TCP	3389	(Windows instances) Allow inbound RDP access over IPv6 from your network
Outbound
Destination	Protocol	Port Range	Comments
::/0	TCP	HTTP	Allow outbound HTTP access to any IPv6 address.
::/0	TCP	HTTPS	Allow outbound HTTPS access to any IPv6 address.

The following are the IPv6-specific rules for the DBServerSG security group (which are in addition to the rules listed above).

Outbound
Destination	Protocol	Port Range	Comments
::/0	TCP	80	Allow outbound HTTP access to any IPv6 address.
::/0	TCP	443	Allow outbound HTTPS access to any IPv6 address.

Implementing Scenario 2

You can use the VPC wizard to create the VPC, subnets, NAT gateway, and optionally, an egress-only Internet gateway. You must specify an Elastic IP address for your NAT gateway; if you don't have one, you must first allocate one to your account. If you want to use an existing Elastic IP address, ensure that it's not currently associated with another instance or network interface. The NAT gateway is automatically created in the public subnet of your VPC.

These procedures include optional steps for enabling and configuring IPv6 communication for your VPC. You do not have to perform these steps if you do not want to use IPv6 in your VPC.

(Optional) To allocate an Elastic IP address for the NAT gateway (IPv4)

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Elastic IPs.
Choose Allocate New Address.
Choose Yes, Allocate.

Note

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

To create a VPC

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
On the VPC dashboard, choose Start VPC Wizard.
Choose the second option, VPC with Public and Private Subnets, and Select.
For VPC name, Public subnet name and Private subnet name, you can name your VPC and subnets to help you identify them later in the console. You can specify your own IPv4 CIDR block range for the VPC and subnets, or you can leave the default values.
(Optional, IPv6-only) For IPv6 CIDR block, choose Amazon-provided IPv6 CIDR block. For Public subnet's IPv6 CIDR, choose Specify a custom IPv6 CIDR and specify the hexadecimal pair value for your subnet, or leave the default value. For Private subnet's IPv6 CIDR, choose Specify a custom IPv6 CIDR. Specify the hexadecimal pair value for the IPv6 subnet or leave the default value.
In the Specify the details of your NAT gateway section, specify the allocation ID for an Elastic IP address in your account.
You can leave the rest of the default values on the page, and choose Create VPC.

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

To create the WebServerSG and DBServerSG security groups

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Security Groups, Create Security Group.
Provide a name and description for the security group. In this topic, the nameWebServerSG is used as an example. For VPC, select the ID of the VPC you created and choose Yes, Create.
Choose Create Security Group again.
Provide a name and description for the security group. In this topic, the nameDBServerSG is used as an example. For VPC, select the ID of your VPC and choose Yes, Create.

To add rules to the WebServerSG security group

Select the WebServerSG security group that you created. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:
1. Choose Type, HTTP. For Source, enter 0.0.0.0/0.
2. Choose Add another rule, Type, HTTPS. For Source, enter 0.0.0.0/0.
3. Choose Add another rule, Type, SSH. For Source, enter your network's public IPv4 address range.
4. Choose Add another rule, Type, RDP. For Source, enter your network's public IPv4 address range.
5. (Optional, IPv6-only) Choose Add another rule, Type, HTTP. For Source, enter ::/0.
6. (Optional, IPv6-only) Choose Add another rule, Type, HTTPS. For Source, enter ::/0.
7. (Optional, IPv6-only) Choose Add another rule, Type, SSH (for Linux) or RDP (for Windows). For Source, enter your network's IPv6 address range.
8. Choose Save.
On the Outbound Rules tab, choose Edit and add rules for outbound traffic as follows:
1. Locate the default rule that enables all outbound traffic and choose Remove.
2. Choose Type, MS SQL. For Destination, specify the ID of the DBServerSG security group.
3. Choose Add another rule, Type, MySQL. For Destination, specify the ID of the DBServerSG security group.
4. Choose Add another rule, Type, HTTPS. For Destination, enter 0.0.0.0/0.
5. Choose Add another rule, Type, HTTP. For Destination, enter 0.0.0.0/0.
6. (Optional, IPv6-only) Choose Add another rule, Type, HTTPS. For Destination, enter ::/0.
7. (Optional, IPv6-only) Choose Add another rule, Type, HTTP. For Destination, enter ::/0.
8. Choose Save.

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.
On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:
1. Choose Type, MS SQL. For Source, specify the ID of your WebServerSG security group.
2. Choose Add another rule, Type, MYSQL. For Source, specify the ID of your WebServerSG security group.
3. Choose Save.
On the Outbound Rules tab, choose Edit and add rules for outbound traffic as follows:
1. Locate the default rule that enables all outbound traffic and choose Remove.
2. Choose Type, HTTP. For Destination, enter 0.0.0.0/0.
3. Choose Add another rule, Type, HTTPS. For Destination, enter 0.0.0.0/0.
4. (Optional, IPv6-only) Choose Add another rule, Type, HTTP. For Destination, enter ::/0.
5. (Optional, IPv6-only) Choose Add another rule, Type, HTTPS. For Destination, enter ::/0.
6. Choose Save.

You can now launch instances into your VPC.

To launch an instance (web server or database server)

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
From the dashboard, choose Launch Instance.
Select an AMI and an instance type and choose Next: Configure Instance Details.

Note

If you intend to use your instance for IPv6 communication, you must choose a supported instance type; for example, T2. For more information, seeAmazon EC2 Instance Types.
On the Configure Instance Details page, for Network, select the VPC that you created earlier and then select a subnet. For example, launch a web server into the public subnet and the database server into the private subnet.
(Optional) By default, instances launched into a nondefault VPC are not assigned a public IPv4 address. To be able to connect to your instance in the public subnet, you can assign a public IPv4 address now, or allocate an Elastic IP address and assign it to your instance after it's launched. To assign a public IPv4 address now, ensure that you choose Enable from the Auto-assign Public IP list. You do not need to assign a public IP address to an instance in the private subnet.

Note

You can only use the auto-assign public IPv4 feature for a single, new network interface with the device index of eth0. For more information, see Assigning a Public IPv4 Address During Instance Launch.
(Optional, IPv6-only) You can auto-assign an IPv6 address to your instance from the subnet range. For Auto-assign IPv6 IP, choose Enable.
On the next two pages of the wizard, you can configure storage for your instance, and add tags. On the Configure Security Group page, choose the Select an existing security group option, and select one of the security groups you created earlier (WebServerSG for a web server or DBServerSG for a database server). Choose Review and Launch.
Review the settings that you've chosen. Make any changes that you need and choose Launch to choose a key pair and launch your instance.

If you did not assign a public IPv4 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 (IPv4)

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Elastic IPs.
Choose Allocate new address.
Choose Allocate.

Note

If your account supports EC2-Classic, first choose VPC.
Select the Elastic IP address from the list and choose Actions, Associate address.
Select the network interface or instance. For Private IP, select the corresponding address to associate the Elastic IP address with and choose Associate.

Implementing Scenario 2 with a NAT Instance

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

You can follow the same procedures as above; however, in the NAT section of the VPC wizard, choose Use a NAT instance instead and specify the details for your NAT instance. You will also require a security group for your NAT instance (NATSG), which allows the NAT instance to receive Internet-bound traffic from instances in the private subnet, as well as SSH traffic from your network. The NAT instance can also send traffic to the Internet, so that instances in the private subnet can get software updates.

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

NATSG: Recommended Rules

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

To create the NATSG security group

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Security Groups, and the choose Create Security Group.
Specify a name and description for the security group. In this topic, the name NATSG is used as an example. For VPC, select the ID of your VPC and choose Yes, Create.
Select the NATSG security group that you created. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:
1. Choose Type, HTTP . For Source, enter the IP address range of your private subnet.
2. Choose Add another rule, Type, HTTPS. For Source, enter the IP address range of your private subnet.
3. Choose Add another rule, Type, SSH. For Source, enter your network's public IP address range.
4. Choose Save.
On the Outbound Rules tab, choose Edit and add rules for outbound traffic as follows:

Scenario 3: VPC with Public and Private Subnets and AWS Managed 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.

This topic assumes that you'll use the VPC wizard in the Amazon VPC console to create the VPC and the VPN connection.

This scenario can also be optionally configured for IPv6—you can use the VPC wizard to create a VPC and subnets with associated IPv6 CIDR blocks. Instances launched into the subnets can receive IPv6 addresses. Currently, we do not support IPv6 communication over a VPN connection; however, instances in the VPC can communicate with each other via IPv6, and instances in the public subnet can communicate over the Internet via IPv6. For more information about IPv4 and IPv6 addressing, see IP Addressing in Your VPC.

Topics

Overview

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

Diagram for scenario 3: VPC with public and private subnets and
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.

The configuration for this scenario includes the following:

A virtual private cloud (VPC) with a size /16 IPv4 CIDR (example: 10.0.0.0/16). This provides 65,536 private IPv4 addresses.
A public subnet with a size /24 IPv4 CIDR (example: 10.0.0.0/24). This provides 256 private IPv4 addresses. A public subnet is a subnet that's associated with a route table that has a route to an Internet gateway.
A VPN-only subnet with a size /24 IPv4 CIDR (example: 10.0.1.0/24). This provides 256 private IPv4 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 IPv4 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 with Elastic IP addresses (example: 198.51.100.1), which are public IPv4 addresses that enable them to be reached from the Internet. The instances can have public IPv4 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 VPCs 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 AWS Managed VPN Connections. For more information about configuring a customer gateway, see the Amazon VPC Network Administrator Guide.

Overview for IPv6

You can optionally enable IPv6 for this scenario. In addition to the components listed above, the configuration includes the following:

A size /56 IPv6 CIDR block associated with the VPC (example: 2001:db8:1234:1a00::/56). AWS automatically assigns the CIDR; you cannot choose the range yourself.
A size /64 IPv6 CIDR block associated with the public subnet (example: 2001:db8:1234:1a00::/64). You can choose the range for your subnet from the range allocated to the VPC. You cannot choose the size of the IPv6 CIDR.
A size /64 IPv6 CIDR block associated with the VPN-only subnet (example: 2001:db8:1234:1a01::/64). You can choose the range for your subnet from the range allocated to the VPC. You cannot choose the size of the IPv6 CIDR.
IPv6 addresses assigned to the instances from the subnet range (example: 2001:db8:1234:1a00::1a).
Route table entries in the custom route table that enable instances in the public subnet to use IPv6 to communicate with each other, and directly over the Internet.
A route table entry in the main route table that enable instances in the VPN-only subnet to use IPv6 to communicate with each other.

IPv6-enabled VPC with a public and VPN-only subnet

Routing

Your VPC has an implied router (shown in the configuration diagram for this scenario). In 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.

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. Currently, we do not support IPv6 for VPN connections.

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 entry is the default entry for local routing in the VPC; this entry enables the instances in the VPC to communicate with each other over IPv4. The second entry routes all other IPv4 subnet traffic from the private subnet to your network over the virtual private gateway (for example, vgw-1a2b3c4d).

Destination	Target
`10.0.0.0/16`	local
`0.0.0.0/0`	vgw-id

Custom Route Table

The first entry is the default entry for local routing in the VPC; this entry enables the instances in the VPC to communicate with each other. The second entry routes all other IPv4 subnet traffic from the public subnet to the Internet over the Internet gateway (for example, igw-1a2b3c4d).

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

Alternate Routing

Alternatively, if you want instances in the private subnet to access the Internet, you can create a network address translation (NAT) gateway or instance in the public subnet, and set up the routing so that the Internet-bound traffic for the subnet goes to the NAT device. This enables the instances in the VPN-only subnet to send requests over the Internet gateway (for example, for software updates).

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

To enable the private subnet's Internet-bound traffic to go to the NAT device, you must update the main route table as follows.

The first entry is the default entry for local routing in the VPC. The second row entry for routes the subnet traffic bound for your customer network (in this case, assume your local network's IP address is 172.16.0.0/12) to the virtual private gateway. The third entry sends all other subnet traffic to a NAT gateway.

Destination	Target
`10.0.0.0/16`	local
`172.16.0.0/12`	vgw-id
`0.0.0.0/0`	nat-gateway-id

Routing for IPv6

Main Route Table

The second entry is the default route that's automatically added for local routing in the VPC over IPv6.

Destination	Target
10.0.0.0/16	local
2001:db8:1234:1a00::/56	local
0.0.0.0/0	vgw-id

Custom Route Table

The second entry is the default route that's automatically added for local routing in the VPC over IPv6. The fourth entry routes all other IPv6 subnet traffic to the Internet gateway.

Destination	Target
10.0.0.0/16	local
2001:db8:1234:1a00::/56	local
0.0.0.0/0	igw-id
::/0	igw-id

Security

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.

Your VPC comes with a default security group. An instance that's launched into the VPC is automatically associated with the default security group if you don't specify a different security group during launch. For this scenario, we recommend that you create the following security groups instead of using the default security group:

WebServerSG: Specify this security group when you launch web servers in the public subnet.
DBServerSG: Specify this security group when you launch database servers in the VPN-only subnet.

The following table describes the recommended rules for the WebServerSG 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 any IPv4 address.
0.0.0.0/0	TCP	443	Allow inbound HTTPS access to the web servers from any IPv4 address.
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 following table describes the recommended rules for the DBServerSG 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 inbound Microsoft SQL Server access from the web servers associated with the WebServerSG security group.
The ID of your WebServerSG security group	TCP	3306	Allow inbound MySQL Server access from the web servers associated with the WebServerSG security group.
Your network's IPv4 address range	TCP	22	Allow inbound SSH traffic to Linux instances from your network (over the virtual private gateway).
Your network's IPv4 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 IPv4 HTTP access to the Internet (for example, for software updates) over the virtual private gateway.
0.0.0.0/0	TCP	443	Allow outbound IPv4 HTTPS access to the Internet (for example, for software updates) over the virtual private gateway.

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 to other instances assigned to this security group.

Security for IPv6

The following are the IPv6-specific rules for the WebServerSG security group (which are in addition to the rules listed above).

Inbound
Source	Protocol	Port Range	Comments
::/0	TCP	80	Allow inbound HTTP access to the web servers from any IPv6 address.
::/0	TCP	443	Allow inbound HTTPS access to the web servers from any IPv6 address.
IPv6 address range of your network	TCP	22	(Linux instances) Allow inbound SSH access over IPv6 from your network.
IPv6 address range of your network	TCP	3389	(Windows instances) Allow inbound RDP access over IPv6 from your network
Outbound
Destination	Protocol	Port Range	Comments
::/0	TCP	HTTP	Allow outbound HTTP access to any IPv6 address.
::/0	TCP	HTTPS	Allow outbound HTTPS access to any IPv6 address.

Implementing Scenario 3

To implement scenario 3, get information about your customer gateway, and create the VPC using the VPC wizard. The VPC wizard creates a VPN connection for you with a customer gateway and virtual private gateway.

These procedures include optional steps for enabling and configuring IPv6 communication for your VPC. You do not have to perform these steps if you do not want to use IPv6 in your VPC.

To prepare your customer gateway

Determine the device 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.
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).
If you want to create a statically-routed VPN connection, get the list of internal IP ranges (in CIDR notation) that should be advertised across the VPN connection to the virtual private gateway. For more information, see VPN Routing Options.

To create a VPC using the VPC wizard

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
On the dashboard, choose Start VPC Wizard.
Select the third option, VPC with Public and Private Subnets and Hardware VPN Access, and then choose Select.
For VPC name, Public subnet name and Private subnet name, you can name your VPC and subnets to help you identify them later in the console. You can specify your own IPv4 CIDR block range for the VPC and subnets, or you can leave the default values.
(Optional, IPv6-only) For IPv6 CIDR block, choose Amazon-provided IPv6 CIDR block. For Public subnet's IPv6 CIDR, choose Specify a custom IPv6 CIDR and specify the hexadecimal pair value for your subnet, or leave the default value. For Private subnet's IPv6 CIDR, choose Specify a custom IPv6 CIDR. Specify the hexadecimal pair value for the IPv6 subnet or leave the default value.
Choose Next.
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 range for your network in CIDR notation.
  For more information, see VPN Routing Options.
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 your customer gateway, the platform, and the software version, and then choose Yes, Download.
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.

Create the WebServerSG and DBServerSG security groups. These security groups will reference each other, therefore you must create them before you add rules to them.

To create the WebServerSG and DBServerSG security groups

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Security Groups.
Choose Create Security Group.
Provide a name and description for the security group. In this topic, the nameWebServerSG is used as an example. Select the ID of your VPC from the VPC list, and then choose Yes, Create.
Choose Create Security Group again.
Provide a name and description for the security group. In this topic, the nameDBServerSG is used as an example. Select the ID of your VPC from the VPC list, and then choose Yes, Create.

To add rules to the WebServerSG security group

Select the WebServerSG security group that you created. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
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. (Optional, IPv6-only) Choose Add another rule, Type, HTTP. For Source, enter ::/0.
6. (Optional, IPv6-only) Choose Add another rule, Type, HTTPS. For Source, enter ::/0.
7. (Optional, IPv6-only) Choose Add another rule, Type, SSH (for Linux) or RDP (for Windows). For Source, enter your network's IPv6 address range.
8. Choose Save.
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 theDestination field, enter 0.0.0.0/0.
5. Choose Add another rule, then select HTTP from the Type list. In the Destinationfield, enter 0.0.0.0/0.
6. Choose Save.

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

To launch an instance (web server or database server)

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
Choose Launch Instance on the dashboard.
Follow the directions in the wizard. Choose an AMI, choose an instance type, and then choose Next: Configure Instance Details.

Note

If you intend to use your instance for IPv6 communication, you must choose a supported instance type; for example, T2. For more information, seeAmazon EC2 Instance Types.
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.
(Optional) By default, instances launched into a nondefault VPC are not assigned a public IPv4 address. To be able to connect to your instance in the public subnet, you can assign a public IPv4 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 use the auto-assign public IP address feature with a single, new network interface with the device index of eth0. For more information, see Assigning a Public IPv4 Address During Instance Launch.
(Optional, IPv6-only) You can auto-assign an IPv6 address to your instance from the subnet range. For Auto-assign IPv6 IP, choose Enable.
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 one of the security groups that you created (WebServerSG for a web server instance or DBServerSG for a database server instance). Choose Review and Launch.
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 VPN Connection.

To allocate an Elastic IP address and assign it to an instance using the console

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Elastic IPs.
Choose Allocate new address.
Choose Allocate.

Note

If your account supports EC2-Classic, first choose VPC.
Select the Elastic IP address from the list, and choose Actions, Associate address.
Select the network interface or instance. Select the address to associate the Elastic IP address with from the corresponding Private IP list, and then choose 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/.
In the navigation pane, choose DHCP Options Sets.
Choose Create DHCP options set.
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 (for example, 192.0.2.1), separated by a comma, and then choose Yes, Create.
In the navigation pane, choose Your VPCs.
Select the VPC, and then choose Actions, Edit DHCP Options Set.
Select the ID of the new set of options from the DHCP options set list and then choose Save.
(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.

Scenario 4: VPC with a Private Subnet Only and AWS Managed VPN Access

The configuration for this scenario includes a virtual private cloud (VPC) with a single private subnet, and a virtual private gateway to enable communication with your own network over an IPsec VPN tunnel. There is no Internet gateway to enable communication over the Internet. We recommend this scenario if you want to extend your network into the cloudusing Amazon's infrastructure without exposing your network to the Internet.

This topic assumes that you'll use the VPC wizard in the Amazon VPC console to create the VPC and the VPN connection.

This scenario can also be optionally configured for IPv6—you can use the VPC wizard to create a VPC and subnet with associated IPv6 CIDR blocks. Instances launched into the subnet can receive IPv6 addresses. Currently, we do not support IPv6 communication over a VPN connection; however, instances in the VPC can communicate with each other via IPv6. For more information about IPv4 and IPv6 addressing, see IP Addressing in Your VPC.

Topics

Overview

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

Diagram for scenario 4: VPC with only a virtual private gateway

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.

The configuration for this scenario includes the following:

A virtual private cloud (VPC) with a size /16 CIDR (example: 10.0.0.0/16). This provides 65,536 private IP addresses.
A VPN-only subnet with a size /24 CIDR (example: 10.0.0.0/24). This provides 256 private IP addresses.
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, 10.0.0.6, and 10.0.0.7), which enables the instances to communicate with each other and other instances in the VPC.
A custom route table associated with the subnet. The route table contains a route that enables instances in the subnet to communicate with other instances in the VPC, and a route that enables instances in the subnet to communicate directly with your network.

For more information about subnets, see VPCs and Subnets and IP Addressing in Your VPC. For more information about your VPN connection, see AWS Managed VPN Connections. For more information about configuring a customer gateway, see the Amazon VPC Network Administrator Guide.

Overview for IPv6

You can optionally enable IPv6 for this scenario. In addition to the components listed above, the configuration includes the following:

A size /56 IPv6 CIDR block associated with the VPC (example: 2001:db8:1234:1a00::/56). AWS automatically assigns the CIDR; you cannot choose the range yourself.
A size /64 IPv6 CIDR block associated with the VPN-only subnet (example: 2001:db8:1234:1a00::/64). You can choose the range for your subnet from the range allocated to the VPC. You cannot choose the size of the IPv6 CIDR.
IPv6 addresses assigned to the instances from the subnet range (example: 2001:db8:1234:1a00::1a).
A route table entry in the custom route table that enable instances in the private subnet to use IPv6 to communicate with each other.

Routing

Your VPC has an implied router (shown in the configuration diagram for this scenario). In this scenario, the VPC wizard creates a route table that routes all traffic destined for an address outside the VPC to the VPN connection, and associates the route table with the subnet.

The following describes the route table for this scenario. The first entry is the default entry for local routing in the VPC; this entry enables the instances in this VPC to communicate with each other. The second entry routes all other subnet traffic to the virtual private gateway (for example, vgw-1a2b3c4d).

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

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 your VPC through BGP.

The instances in your VPC 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 Amazon S3 or Amazon EC2), the requests must go over the virtual private gateway to your network and then to the Internet before reaching AWS. Currently, we do not support IPv6 for VPN connections.

Routing for IPv6

If you associate an IPv6 CIDR block with your VPC and subnets, your route table includes separate routes for IPv6 traffic. The following describes the custom route table for this scenario. The second entry is the default route that's automatically added for local routing in the VPC over IPv6.

Destination	Target
10.0.0.0/16	local
2001:db8:1234:1a00::/56	local
0.0.0.0/0	vgw-id

Security

For scenario 4, you'll use the default security group for your VPC but not a network ACL. If you'd like to use a network ACL, see Recommended Rules for Scenario 4.

Your VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between the instances assigned to the security group. For this scenario, we recommend that you add inbound rules to the default security group to allow SSH traffic (Linux) and Remote Desktop traffic (Windows) from your network.

Important

The default security group automatically allows assigned instances to communicate with each other, so you don't have to add a rule to allow this. If you use a different security group, you must add a rule to allow this.

The following table describes the inbound rules that you should add to the default security group for your VPC.

Default Security Group: Recommended Rules

Inbound
Source	Protocol	Port Range	Comments
Private IPv4 address range of your network	TCP	22	(Linux instances) Allow inbound SSH traffic from your network.
Private IPv4 address range of your network	TCP	3389	(Windows instances) Allow inbound RDP traffic from your network.

Security for IPv6

If you associate an IPv6 CIDR block with your VPC and subnets, you must add separate rules to your security group to control inbound and outbound IPv6 traffic for your instances. In this scenario, the database servers cannot be reached over the VPN connection using IPv6; therefore, no additional security group rules are required.

Implementing Scenario 4

To implement scenario 4, get information about your customer gateway, and create the VPC using the VPC wizard, The VPC wizard creates a VPN connection for you with a customer gateway and virtual private gateway.

To prepare your customer gateway

Determine the device you'll use as your customer gateway. For 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.
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).
If you want to create a statically-routed VPN connection, get the list of internal IP ranges (in CIDR notation) that should be advertised across the VPN connection to the virtual private gateway. For more information, see VPN Routing Options.

Use the VPC wizard to create your VPC and a VPN connection.

To create a VPC using the VPC wizard

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
On the dashboard, choose Start VPC Wizard.
Select the fourth option, VPC with a Private Subnet Only and Hardware VPN Access, and then choose Select.
On the first page of the wizard, confirm the details for your VPC and private subnet. Naming your VPC and subnet helps you identify them later in the console.
(Optional, IPv6-only) For IPv6 CIDR block, choose Amazon-provided IPv6 CIDR block. For Private subnet's IPv6 CIDR, choose Specify a custom IPv6 CIDR. Specify the hexadecimal pair value for the IPv6 subnet or leave the default value (00).
Choose Next.
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 range for your network in CIDR notation.
  For more information, see VPN Routing Options.
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.
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.

For this scenario, you need to update the default security group with new inbound rules that allow SSH and Remote Desktop (RDP) access from your network. If you don't want instances to initiate outbound communication, you can also remove the default outbound rule.

To update the rules for the default security group

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
Choose Security Groups in the navigation pane, and then select the default security group for the VPC. The details pane displays the details for the security group, plus tabs for working with its inbound and outbound rules.
On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows:
1. Select SSH from the Type list, and enter your network's private IP address range in the Source field; for example, 172.0.0.0/8.
2. Choose Add another rule, then select RDP from the Type list, and enter your network's private IP address range in the Source field.
3. Choose Save.
(Optional) On the Outbound Rules tab, choose Edit, locate the default rule that enables all outbound traffic, choose Remove, and then 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

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
Choose Launch Instance on the dashboard.
Follow the directions in the wizard. Choose an AMI, choose an instance type, and then choose Next: Configure Instance Details.

Note

If you intend to use your instance for IPv6 communication, you must choose a supported instance type; for example, T2. For more information, seeAmazon EC2 Instance Types.
On the Configure Instance Details page, select the VPC that you created earlier from the Network list, and then select the subnet. Choose Next: Add Storage.
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 the default security group. Choose Review and Launch.
Review the settings that you've chosen. Make any changes that you need, and then choose Launch to choose a keypair and launch your instance.

In scenario 4, you need a DNS server that enables your VPN-only subnet to communicate with servers in your network. You must create a new set of DHCP options that includes your DNS server and then configure the VPC to use that set of options.

Note

To update the DHCP options

Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose DHCP Options Sets.
Choose Create DHCP Options Set.
In the Create DHCP Options Set dialog box, in the Domain name servers box, enter the address of your DNS server, and then choose Yes, Create. In this example, your DNS server is 192.0.2.1.
In the navigation pane, choose Your VPCs.
Select the VPC, and then choose Edit in the Summary tab.
Select the ID of the new set of options from the DHCP options set list and then choose Save.
(Optional) The VPC now uses this new set of DHCP options and therefore uses your DNS server. If you want, you can delete the original set of options that the VPC used.

You can now use SSH or RDP to connect to your instance 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 Windows Instances.

Example: Create an IPv4 VPC and Subnets Using the AWS CLI

The following example uses AWS CLI commands to create a nondefault VPC with an IPv4 CIDR block, and a public and private subnet in the VPC. After you've created the VPC and subnets, you can launch an instance in the public subnet and connect to it. To begin, you must first install and configure the AWS CLI. For more information, see Getting Set Up with the AWS Command Line Interface.

Topics

Step 1: Create a VPC and Subnets

The first step is to create a VPC and two subnets. This example uses the CIDR block10.0.0.0/16 for the VPC, but you can choose a different CIDR block. For more information, see VPC and Subnet Sizing.

To create a VPC and subnets using the AWS CLI

Create a VPC with a 10.0.0.0/16 CIDR block.



Copy

aws ec2 create-vpc --cidr-block 10.0.0.0/16

In the output that's returned, take note of the VPC ID.

{
    "Vpc": {
        "VpcId": "vpc-2f09a348", 
        ...
    }
}

Using the VPC ID from the previous step, create a subnet with a 10.0.1.0/24 CIDR block.
```
Copy

aws ec2 create-subnet --vpc-id vpc-2f09a348 --cidr-block 10.0.1.0/24
```

Create a second subnet in your VPC with a 10.0.0.0/24 CIDR block.



Copy

aws ec2 create-subnet --vpc-id vpc-2f09a348 --cidr-block 10.0.0.0/24

Step 2: Make Your Subnet Public

To make your subnet a public subnet

Create an Internet gateway.



Copy

aws ec2 create-internet-gateway

In the output that's returned, take note of the Internet gateway ID.

{
    "InternetGateway": {
        ...
        "InternetGatewayId": "igw-1ff7a07b", 
        ...
    }
}

Using the ID from the previous step, attach the Internet gateway to your VPC.



Copy

aws ec2 attach-internet-gateway --vpc-id vpc-2f09a348 --internet-gateway-id igw-1ff7a07b

Create a custom route table for your VPC.



Copy

aws ec2 create-route-table --vpc-id vpc-2f09a348

In the output that's returned, take note of the route table ID.

{
    "RouteTable": {
        ... 
        "RouteTableId": "rtb-c1c8faa6", 
        ...
    }
}

Create a route in the route table that points all traffic (0.0.0.0/0) to the Internet gateway.



Copy

aws ec2 create-route --route-table-id rtb-c1c8faa6 --destination-cidr-block 0.0.0.0/0 --gateway-id igw-1ff7a07b

To confirm that your route has been created and is active, you can describe the route table and view the results.



Copy

aws ec2 describe-route-tables --route-table-id rtb-c1c8faa6

{
    "RouteTables": [
        {
            "Associations": [], 
            "RouteTableId": "rtb-c1c8faa6", 
            "VpcId": "vpc-2f09a348", 
            "PropagatingVgws": [], 
            "Tags": [], 
            "Routes": [
                {
                    "GatewayId": "local", 
                    "DestinationCidrBlock": "10.0.0.0/16", 
                    "State": "active", 
                    "Origin": "CreateRouteTable"
                }, 
                {
                    "GatewayId": "igw-1ff7a07b", 
                    "DestinationCidrBlock": "0.0.0.0/0", 
                    "State": "active", 
                    "Origin": "CreateRoute"
                }
            ]
        }
    ]
}

The route table is currently not associated with any subnet. You need to associate it with a subnet in your VPC so that traffic from that subnet is routed to the Internet gateway. First, use the describe-subnets command to get your subnet IDs. You can use the --filter option to return the subnets for your new VPC only, and the --queryoption to return only the subnet IDs and their CIDR blocks.
```
Copy

aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-2f09a348" --query 'Subnets[*].{ID:SubnetId,CIDR:CidrBlock}'
```
```
[
    {
        "CIDR": "10.0.1.0/24", 
        "ID": "subnet-b46032ec"
    }, 
    {
        "CIDR": "10.0.0.0/24", 
        "ID": "subnet-a46032fc"
    }
]
```
You can choose which subnet to associate with the custom route table, for example,subnet-b46032ec. This subnet will be your public subnet.
```
Copy

aws ec2 associate-route-table  --subnet-id subnet-b46032ec --route-table-id rtb-c1c8faa6
```
You can optionally modify the public IP addressing behavior of your subnet so that an instance launched into the subnet automatically receives a public IP address. Otherwise, you should associate an Elastic IP address with your instance after launch so that it's reachable from the Internet.
```
Copy

aws ec2 modify-subnet-attribute --subnet-id subnet-b46032ec --map-public-ip-on-launch
```

Step 3: Launch an Instance into Your Subnet

To test that your subnet is public and that instances in the subnet are accessible via the Internet, launch an instance into your public subnet and connect to it. First, you must create a security group to associate with your instance, and a key pair with which you'll connect to your instance. For more information about security groups, see Security Groups for Your VPC. For more information about key pairs, see Amazon EC2 Key Pairs in the Amazon EC2 User Guide for Linux Instances.

To launch and connect to an instance in your public subnet

Create a key pair and use the --query option and the --output text option to pipe your private key directly into a file with the .pem extension.
```
Copy

aws ec2 create-key-pair --key-name MyKeyPair --query 'KeyMaterial' --output text > MyKeyPair.pem
```
In this example, you launch an Amazon Linux instance. If you use an SSH client on a Linux or Mac OS X operating system to connect to your instance, use the following command to set the permissions of your private key file so that only you can read it.
```
Copy

chmod 400 MyKeyPair.pem
```
Create a security group in your VPC, and add a rule that allows SSH access from anywhere.
```
Copy

aws ec2 create-security-group --group-name SSHAccess --description "Security group for SSH access" --vpc-id vpc-2f09a348
```
```
{
    "GroupId": "sg-e1fb8c9a"
}
```
```
Copy

aws ec2 authorize-security-group-ingress --group-id sg-e1fb8c9a --protocol tcp --port 22 --cidr 0.0.0.0/0
```
Note

If you use 0.0.0.0/0, you enable all IPv4 addresses to access your instance using SSH. This is acceptable for this short exercise, but in production, authorize only a specific IP address or range of addresses.
Launch an instance into your public subnet, using the security group and key pair you've created. In the output, take note of the instance ID for your instance.
```
Copy

aws ec2 run-instances --image-id ami-a4827dc9 --count 1 --instance-type t2.micro --key-name MyKeyPair --security-group-ids sg-e1fb8c9a --subnet-id subnet-b46032ec
```
Note

In this example, the AMI is an Amazon Linux AMI in the US East (N. Virginia) region. If you're in a different region, you'll need the AMI ID for a suitable AMI in your region. For more information, see Finding a Linux AMI in the Amazon EC2 User Guide for Linux Instances.

Your instance must be in the running state in order to connect to it. Describe your instance and confirm its state, and take note of its public IP address.



Copy

aws ec2 describe-instances --instance-id i-0146854b7443af453

{
    "Reservations": [
        {
            ... 
            "Instances": [
                {
                    ...
                    "State": {
                        "Code": 16, 
                        "Name": "running"
                    }, 
                    ...
                    "PublicIpAddress": "52.87.168.235", 
                    ...
                }
            ]
        }
    ]
}

When your instance is in the running state, you can connect to it using an SSH client on a Linux or Mac OS X computer by using the following command:
```
Copy

ssh -i "MyKeyPair.pem" ec2-user@52.87.168.235
```
If you're connecting from a Windows computer, use the following instructions: Connecting to Your Linux Instance from Windows Using PuTTY.

Step 4: Clean Up

After you've verified that you can connect to your instance, you can terminate it if you no longer need it. To do this, use the terminate-instances command. To delete the other resources you've created in this example, use the following commands in their listed order:

Delete your security group:



Copy

aws ec2 delete-security-group --group-id sg-e1fb8c9a

Delete your subnets:



Copy

aws ec2 delete-subnet --subnet-id subnet-b46032ec



Copy

aws ec2 delete-subnet --subnet-id subnet-a46032fc

Delete your custom route table:



Copy

aws ec2 delete-route-table --route-table-id rtb-c1c8faa6

Detach your Internet gateway from your VPC:



Copy

aws ec2 detach-internet-gateway --internet-gateway-id igw-1ff7a07b --vpc-id vpc-2f09a348

Delete your Internet gateway:



Copy

aws ec2 delete-internet-gateway --internet-gateway-id igw-1ff7a07b

Delete your VPC:



Copy

aws ec2 delete-vpc --vpc-id vpc-2f09a348

Example: Create an IPv6 VPC and Subnets Using the AWS CLI

The following example uses AWS CLI commands to create a nondefault VPC with an IPv6 CIDR block, a public subnet, and a private subnet with outbound Internet access only. After you've created the VPC and subnets, you can launch an instance in the public subnet and connect to it. You can launch an instance in your private subnet and verify that it can connect to the Internet. To begin, you must first install and configure the AWS CLI. For more information, seeGetting Set Up with the AWS Command Line Interface.

Topics

Step 1: Create a VPC and Subnets

The first step is to create a VPC and two subnets. This example uses the IPv4 CIDR block10.0.0.0/16 for the VPC, but you can choose a different CIDR block. For more information, see VPC and Subnet Sizing.

To create a VPC and subnets using the AWS CLI

Create a VPC with a 10.0.0.0/16 CIDR block and associate an IPv6 CIDR block with the VPC.



Copy

aws ec2 create-vpc --cidr-block 10.0.0.0/16 --amazon-provided-ipv6-cidr-block

In the output that's returned, take note of the VPC ID.

{
    "Vpc": {
        "VpcId": "vpc-2f09a348", 
        ...
}

Describe your VPC to get the IPv6 CIDR block that's associated with the VPC.



Copy

aws ec2 describe-vpcs --vpc-id vpc-2f09a348

{
    "Vpcs": [
        {
            ...
            "Ipv6CidrBlockAssociationSet": [
                {
                    "Ipv6CidrBlock": "2001:db8:1234:1a00::/56", 
                    "AssociationId": "vpc-cidr-assoc-17a5407e", 
                    "Ipv6CidrBlockState": {
                        "State": "ASSOCIATED"
                    }
                }
            ], 
            ...
}

Create a subnet with a 10.0.0.0/24 IPv4 CIDR block and a2001:db8:1234:1a00::/64 IPv6 CIDR block (from the ranges that were returned in the previous step).
```
Copy

aws ec2 create-subnet --vpc-id vpc-2f09a348 --cidr-block 10.0.0.0/24 --ipv6-cidr-block 2001:db8:1234:1a00::/64
```

Create a second subnet in your VPC with a 10.0.1.0/24 IPv4 CIDR block and a 2001:db8:1234:1a01::/64 IPv6 CIDR block.



Copy

aws ec2 create-subnet --vpc-id vpc-2f09a348 --cidr-block 10.0.1.0/24 --ipv6-cidr-block 2001:db8:1234:1a01::/64

Step 2: Configure a Public Subnet

After you've created the VPC and subnets, you can make one of the subnets a public subnet by attaching an Internet gateway to your VPC, creating a custom route table, and configuring routing for the subnet to the Internet gateway. In this example, a route table is created that routes all IPv4 traffic and IPv6 traffic to an Internet gateway.

To make your subnet a public subnet

Create an Internet gateway.



Copy

aws ec2 create-internet-gateway

In the output that's returned, take note of the Internet gateway ID.

{
    "InternetGateway": {
        ...
        "InternetGatewayId": "igw-1ff7a07b", 
        ...
    }
}

Using the ID from the previous step, attach the Internet gateway to your VPC.



Copy

aws ec2 attach-internet-gateway --vpc-id vpc-2f09a348 --internet-gateway-id igw-1ff7a07b

Create a custom route table for your VPC.



Copy

aws ec2 create-route-table --vpc-id vpc-2f09a348

In the output that's returned, take note of the route table ID.

{
    "RouteTable": {
        ... 
        "RouteTableId": "rtb-c1c8faa6", 
        ...
    }
}

Create a route in the route table that points all IPv6 traffic (::/0) to the Internet gateway.
```
Copy

aws ec2 create-route --route-table-id rtb-c1c8faa6 --destination-ipv6-cidr-block ::/0 --gateway-id igw-1ff7a07b
```
Note

If you intend to use your public subnet for IPv4 traffic too, you need to add another route for 0.0.0.0/0 traffic that points to the Internet gateway.

To confirm that your route has been created and is active, you can describe the route table and view the results.



Copy

aws ec2 describe-route-tables --route-table-id rtb-c1c8faa6

{
    "RouteTables": [
        {
            "Associations": [], 
            "RouteTableId": "rtb-c1c8faa6", 
            "VpcId": "vpc-2f09a348", 
            "PropagatingVgws": [], 
            "Tags": [], 
            "Routes": [
                {
                    "GatewayId": "local", 
                    "DestinationCidrBlock": "10.0.0.0/16", 
                    "State": "active", 
                    "Origin": "CreateRouteTable"
                }, 
                {
                    "GatewayId": "local", 
                    "Origin": "CreateRouteTable", 
                    "State": "active", 
                    "DestinationIpv6CidrBlock": "2001:db8:1234:1a00::/56"
                }, 
                {
                    "GatewayId": "igw-1ff7a07b", 
                    "Origin": "CreateRoute", 
                    "State": "active", 
                    "DestinationIpv6CidrBlock": "::/0"
                }
            ]
        }
    ]
}

The route table is not currently associated with any subnet. Associate it with a subnet in your VPC so that traffic from that subnet is routed to the Internet gateway. First, describe your subnets to get their IDs. You can use the --filter option to return the subnets for your new VPC only, and the --query option to return only the subnet IDs and their IPv4 and IPv6 CIDR blocks.



Copy

aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-2f09a348" --query 'Subnets[*].{ID:SubnetId,IPv4CIDR:CidrBlock,IPv6CIDR:Ipv6CidrBlockAssociationSet[*].Ipv6CidrBlock}'

[
    {
        "IPv6CIDR": [
            "2001:db8:1234:1a00::/64"
        ], 
        "ID": "subnet-b46032ec", 
        "IPv4CIDR": "10.0.0.0/24"
    }, 
    {
        "IPv6CIDR": [
            "2001:db8:1234:1a01::/64"
        ], 
        "ID": "subnet-a46032fc", 
        "IPv4CIDR": "10.0.1.0/24"
    }
]

You can choose which subnet to associate with the custom route table, for example,subnet-b46032ec. This subnet will be your public subnet.
```
Copy

aws ec2 associate-route-table  --subnet-id subnet-b46032ec --route-table-id rtb-c1c8faa6
```

Step 3: Configure an Egress-Only Private Subnet

You can configure the second subnet in your VPC to be an IPv6 egress-only private subnet. Instances that are launched in this subnet are able to access the Internet over IPv6 (for example, to get software updates) through an egress-only Internet gateway, but hosts on the Internet cannot reach your instances.

To make your subnet an egress-only private subnet

Create an egress-only Internet gateway for your VPC. In the output that's returned, take note of the gateway ID.



Copy

aws ec2 create-egress-only-internet-gateway --vpc-id vpc-2f09a348

{
    "EgressOnlyInternetGateway": {
        "EgressOnlyInternetGatewayId": "eigw-015e0e244e24dfe8a", 
        "Attachments": [
            {
                "State": "attached", 
                "VpcId": "vpc-2f09a348"
            }
        ]
    }
}

Create a custom route table for your VPC. In the output that's returned, take note of the route table ID.
```
Copy

aws ec2 create-route-table --vpc-id vpc-2f09a348
```

Create a route in the route table that points all IPv6 traffic (::/0) to the egress-only Internet gateway.



Copy

aws ec2 create-route --route-table-id rtb-abc123ab --destination-ipv6-cidr-block ::/0 --egress-only-internet-gateway-id eigw-015e0e244e24dfe8a

Associate the route table with the second subnet in your VPC (you described the subnets in the previous section). This subnet will be your private subnet with egress-only IPv6 Internet access.
```
Copy

aws ec2 associate-route-table --subnet-id subnet-a46032fc --route-table-id rtb-abc123ab
```

Step 4: Modify the IPv6 Addressing Behavior of the Subnets

You can modify the IP addressing behavior of your subnets so that instances launched into the subnets automatically receive IPv6 addresses. When you launch an instance into the subnet, a single IPv6 address is assigned from the range of the subnet to the primary network interface (eth0) of the instance.



Copy

aws ec2 modify-subnet-attribute --subnet-id subnet-b46032ec --assign-ipv6-address-on-creation



Copy

aws ec2 modify-subnet-attribute --subnet-id subnet-a46032fc --assign-ipv6-address-on-creation

Step 5: Launch an Instance into Your Public Subnet

To test that your public subnet is public and that instances in the subnet are accessible from the Internet, launch an instance into your public subnet and connect to it. First, you must create a security group to associate with your instance, and a key pair with which you'll connect to your instance. For more information about security groups, see Security Groups for Your VPC. For more information about key pairs, see Amazon EC2 Key Pairs in the Amazon EC2 User Guide for Linux Instances.

To launch and connect to an instance in your public subnet

Create a key pair and use the --query option and the --output text option to pipe your private key directly into a file with the .pem extension.
```
Copy

aws ec2 create-key-pair --key-name MyKeyPair --query 'KeyMaterial' --output text > MyKeyPair.pem
```
In this example, launch an Amazon Linux instance. If you use an SSH client on a Linux or OS X operating system to connect to your instance, use the following command to set the permissions of your private key file so that only you can read it.
```
Copy

chmod 400 MyKeyPair.pem
```

Create a security group for your VPC, and add a rule that allows SSH access from any IPv6 address.



Copy

aws ec2 create-security-group --group-name SSHAccess --description "Security group for SSH access" --vpc-id vpc-2f09a348

{
    "GroupId": "sg-e1fb8c9a"
}



Copy

aws ec2 authorize-security-group-ingress --group-id sg-e1fb8c9a --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "Ipv6Ranges": [{"CidrIpv6": "::/0"}]}]'

Note

If you use ::/0, you enable all IPv6 addresses to access your instance using SSH. This is acceptable for this short exercise, but in production, authorize only a specific IP address or range of addresses to access your instance.

Launch an instance into your public subnet, using the security group and key pair that you've created. In the output, take note of the instance ID for your instance.
```
Copy

aws ec2 run-instances --image-id ami-a4827dc9 --count 1 --instance-type t2.micro --key-name MyKeyPair --security-group-ids sg-e1fb8c9a --subnet-id subnet-b46032ec
```
Note

In this example, the AMI is an Amazon Linux AMI in the US East (N. Virginia) region. If you're in a different region, you need the AMI ID for a suitable AMI in your region. For more information, see Finding a Linux AMI in the Amazon EC2 User Guide for Linux Instances.

Your instance must be in the running state in order to connect to it. Describe your instance and confirm its state, and take note of its IPv6 address.



Copy

aws ec2 describe-instances --instance-id i-0146854b7443af453

{
    "Reservations": [
        {
            ... 
            "Instances": [
                {
                    ...
                    "State": {
                        "Code": 16, 
                        "Name": "running"
                    }, 
                    ...
                    "NetworkInterfaces": {
                        "Ipv6Addresses": {
                            "Ipv6Address": "2001:db8:1234:1a00::123"
                        } 
                    ...
                }
            ]
        }
    ]
}

When your instance is in the running state, you can connect to it using an SSH client on a Linux or OS X computer by using the following command. Your local computer must have an IPv6 address configured.
```
Copy

ssh -i "MyKeyPair.pem" ec2-user@2001:db8:1234:1a00::123
```
If you're connecting from a Windows computer, use the following instructions: Connecting to Your Linux Instance from Windows Using PuTTY.

Step 6: Launch an Instance into Your Private Subnet

To test that instances in your egress-only private subnet can access the Internet, launch an instance in your private subnet and connect to it using a bastion instance in your public subnet (you can use the instance you launched in the previous section). First, you must create a security group for the instance. The security group must have a rule that allows your bastion instance to connect using SSH, and a rule that allows the ping6 command (ICMPv6 traffic) to verify that the instance is not accessible from the Internet.

Create a security group in your VPC, and add a rule that allows inbound SSH access from the IPv6 address of the instance in your public subnet, and a rule that allows all ICMPv6 traffic:



Copy

aws ec2 create-security-group --group-name SSHAccessRestricted --description "Security group for SSH access from bastion" --vpc-id vpc-2f09a348

{
    "GroupId": "sg-aabb1122"
}



Copy

aws ec2 authorize-security-group-ingress --group-id sg-aabb1122 --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "Ipv6Ranges": [{"CidrIpv6": "2001:db8:1234:1a00::123/128"}]}]'



Copy

aws ec2 authorize-security-group-ingress --group-id sg-aabb1122 --ip-permissions '[{"IpProtocol": "58", "FromPort": -1, "ToPort": -1, "Ipv6Ranges": [{"CidrIpv6": "::/0"}]}]'

Launch an instance into your private subnet, using the security group you've created and the same key pair you used to launch the instance in the public subnet.
```
Copy

aws ec2 run-instances --image-id ami-a4827dc9 --count 1 --instance-type t2.micro --key-name MyKeyPair --security-group-ids sg-aabb1122 --subnet-id subnet-a46032fc
```
Use the describe-instances command to verify that your instance is running, and to get its IPv6 address.
Configure SSH agent forwarding on your local machine, and then connect to your instance in the public subnet. For Linux, use the following commands:
```
Copy

ssh-add MyKeyPair.pem
```
```
Copy

ssh -A ec2-user@2001:db8:1234:1a00::123
```
For OS X, use the following commands:
```
Copy

ssh-add -K MyKeyPair.pem
```
```
Copy

ssh -A ec2-user@2001:db8:1234:1a00::123
```
For Windows, use the following instructions: To configure SSH agent forwarding for Windows (PuTTY). Connect to the instance in the public subnet by using its IPv6 address.
From your instance in the public subnet (the bastion instance), connect to your instance in the private subnet by using its IPv6 address:
```
Copy

ssh ec2-user@2001:db8:1234:1a01::456
```

From your private instance, test that you can connect to the Internet by running theping6 command for a website that has ICMP enabled, for example:



Copy

ping6 -n ietf.org

PING ietf.org(2001:1900:3001:11::2c) 56 data bytes
64 bytes from 2001:1900:3001:11::2c: icmp_seq=1 ttl=46 time=73.9 ms
64 bytes from 2001:1900:3001:11::2c: icmp_seq=2 ttl=46 time=73.8 ms
64 bytes from 2001:1900:3001:11::2c: icmp_seq=3 ttl=46 time=73.9 ms
...

To test that hosts on the Internet cannot reach your instance in the private subnet, use the ping6 command from a computer that's enabled for IPv6. You should get a timeout response. If you get a valid response, then your instance is accessible from the Internet—check the route table that's associated with your private subnet and verify that it does not have a route for IPv6 traffic to an Internet gateway.
```
Copy

ping6 2001:db8:1234:1a01::456
```

Step 7: Clean Up

After you've verified that you can connect to your instance in the public subnet and that your instance in the private subnet can access the Internet, you can terminate the instances if you no longer need them. To do this, use the terminate-instances command. To delete the other resources you've created in this example, use the following commands in their listed order:

Delete your security groups:



Copy

aws ec2 delete-security-group --group-id sg-e1fb8c9a



Copy

aws ec2 delete-security-group --group-id sg-aabb1122

Delete your subnets:



Copy

aws ec2 delete-subnet --subnet-id subnet-b46032ec



Copy

aws ec2 delete-subnet --subnet-id subnet-a46032fc

Delete your custom route tables:



Copy

aws ec2 delete-route-table --route-table-id rtb-c1c8faa6



Copy

aws ec2 delete-route-table --route-table-id rtb-abc123ab

Detach your Internet gateway from your VPC:



Copy

aws ec2 detach-internet-gateway --internet-gateway-id igw-1ff7a07b --vpc-id vpc-2f09a348

Delete your Internet gateway:



Copy

aws ec2 delete-internet-gateway --internet-gateway-id igw-1ff7a07b

Delete your egress-only Internet gateway:



Copy

aws ec2 delete-egress-only-internet-gateway  --egress-only-internet-gateway-id eigw-015e0e244e24dfe8a

Delete your VPC:



Copy

aws ec2 delete-vpc --vpc-id vpc-2f09a348

VPC Virtual Private Network

Scenario 1: VPC with a Single Public Subnet

Overview

Overview for IPv6

Routing

Routing for IPv6

Security

Security for IPv6

Implementing Scenario 1

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

Overview

Overview for IPv6

Routing

Main Route Table

Custom Route Table

Routing for IPv6

Security

Security for IPv6

Implementing Scenario 2

Implementing Scenario 2 with a NAT Instance

Scenario 3: VPC with Public and Private Subnets and AWS Managed VPN Access

Overview

Overview for IPv6

Routing

Main Route Table

Custom Route Table

Alternate Routing

Routing for IPv6

Security

Security for IPv6

Implementing Scenario 3

Scenario 4: VPC with a Private Subnet Only and AWS Managed VPN Access

Overview

Overview for IPv6

Routing

Routing for IPv6

Security

Security for IPv6

Implementing Scenario 4

Example: Create an IPv4 VPC and Subnets Using the AWS CLI

Step 1: Create a VPC and Subnets

Step 2: Make Your Subnet Public

Step 3: Launch an Instance into Your Subnet

Step 4: Clean Up

Example: Create an IPv6 VPC and Subnets Using the AWS CLI

Step 1: Create a VPC and Subnets

Step 2: Configure a Public Subnet

Step 3: Configure an Egress-Only Private Subnet

Step 4: Modify the IPv6 Addressing Behavior of the Subnets

Step 5: Launch an Instance into Your Public Subnet

Step 6: Launch an Instance into Your Private Subnet

Step 7: Clean Up

Comments

Post a Comment

Popular posts from this blog