AWS Documentation » Amazon Virtual Private Cloud » User Guide » Scenarios for Using Amazon VPC » Scenario 1: VPC with a Public Subnet Only	« Previous Next »
	Did this page help you? Yes \| No \| Tell us about it...

Scenario 1: VPC with a Public Subnet Only

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.

Topics

Configuration for Scenario 1

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 in the Amazon Virtual Private Cloud Getting Started Guide, then you've already implemented this scenario using the VPC wizard in the Amazon VPC console.

Basic Components for Scenario 1

The following list describes the basic components presented in the configuration diagram for this scenario:

A virtual private cloud (VPC) of size /16 (example CIDR: 10.0.0.0/16). This provides 65,536 private IP addresses.
A subnet of size /24 (example CIDR: 10.0.0.0/24). This provides 256 private IP addresses.
An Internet gateway. This connects the VPC to the Internet and to other AWS products, such as Amazon Simple Storage Service (Amazon S3).
An instance with a private IP 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 IP address (example: 198.51.100.2), which enables the instance to be reached from the Internet.
A route table entry that enables instances in the subnet to communicate with other instances in the VPC, and a route table entry that enables instances in the subnet to communicate directly over the Internet.

For more information about subnets, see Your VPC and Subnets and IP Addressing in Your VPC. For more information about Internet gateways, see Adding an Internet Gateway to Your VPC.

Tip

If you'd like instances in your VPC to communicate over the Internet without having to assign each instance an Elastic IP address, you can use a NAT instance. For more information about configuring a NAT instances, see Scenario 2: VPC with Public and Private Subnets or NAT Instances.

Routing for Scenario 1

Your VPC has an implied router (shown in the configuration diagram for this scenario.) For this scenario, the VPC wizard creates a 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. Otherwise, you'd need to create and associate the route table yourself.

The following table shows what the route table looks like for the example addresses used in the configuration diagram for this scenario. The first row shows the entry for local routing in the VPC; this entry enables the instances in this VPC to communicate with each other. The second row shows the entry for routing all other subnet traffic to the Internet gateway, which is specified using its AWS-assigned identifier.

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

Security for Scenario 1

AWS provides two features that you can use to increase security in your VPC: security groups and network ACLs. Both features enable you to control the inbound and outbound traffic for your instances, but security groups work at the instance level, while network ACLs work at the subnet level. Security groups alone can meet the needs of many VPC users. However, some VPC users decide to use both security groups and network ACLs to take advantage of the additional layer of security that network ACLs provide. For more information about security groups and network ACLs and how they differ, see Security in Your VPC.

For scenario 1, you'll use a security group but not network ACLs. For more information about security groups, see Security Groups for Your VPC.

Recommended Security Group Rules

Your VPC comes with a default security group whose initial settings deny all inbound traffic, allow all outbound traffic, and allow all traffic between instances assigned to the security group. If you don't specify a security group when you launch an instance, the instance is automatically assigned to the default security group for the VPC. We could modify the rules for the default security group, but the rules that you need for your web servers might not work for other instances that you launch into the VPC. Therefore, we recommend that you create a security group to use with the web servers in your public subnet.

You'll create a security group named WebServerSG, add the rules that you need, and then specify the security group when you launch instances into the VPC.

The following table describes the inbound and outbound rules you should add to the WebServerSG group. These rules allow instances assigned to this security group to receive Internet traffic, as well as SSH or RDP traffic from your network. These instances can also initiate traffic to the Internet.

Inbound
Source	Protocol	Port Range	Comments
0.0.0.0/0	TCP	80	Allow inbound HTTP access to the web servers from anywhere
0.0.0.0/0	TCP	443	Allow inbound HTTPS access to the web servers from anywhere
Public IP address range of your network	TCP	22	(Linux instances) Allow inbound SSH access from your network
Public IP address range of your network	TCP	3389	(Windows instances) Allow inbound RDP access from your network
Outbound
Destination	Protocol	Port Range	Comments
0.0.0.0/0	TCP	80	Allow outbound HTTP access to servers on the Internet (for example, for software updates)
0.0.0.0/0	TCP	443	Allow outbound HTTPS access to servers on the Internet (for example, for software updates)

The default security group for a VPC has rules that automatically allow assigned instances to communicate with each other. To allow that type of communication between the web servers in your subnet, you must add rules like the following to the WebServerSG security group.

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

Implementing Scenario 1

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

Tip

The Amazon Virtual Private Cloud Getting Started Guide describes the same steps, but provides additional details for some of these steps.

To implement scenario 1 using the VPC wizard

Set up the VPC, subnet, and Internet gateway:
1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
2. Click VPC Dashboard in the navigation pane.
3. Locate the Your Virtual Private Cloud area of the dashboard and click Get started creating a VPC, if you have no VPC resources, or click Start VPC Wizard.
4. Select the first option, VPC with a Single Public Subnet Only, and then click Continue.
5. The confirmation page shows the CIDR ranges and settings that you've chosen. Make any changes that you need, and then click Create VPC to create your VPC, subnet, Internet gateway, and route table.
Create the WebServerSG security group and add rules:
1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
2. Click Security Groups in the navigation pane.
3. Click the Create Security Group button.
4. Specify WebServerSG as the name of the security group, and provide a description. Select the ID of your VPC from the VPC menu, and then click Yes, Create.
5. 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.
6. On the Inbound tab, do the following:
  - Select HTTP from the Create a new rule list, make sure that Source is 0.0.0.0/0, and then click Add Rule.
  - Select HTTPS from the Create a new rule list, make sure that Source is 0.0.0.0/0, and then click Add Rule.
  - Select SSH (Linux) or RDP (Windows) from the Create a new rule list. In the Source box, specify your network's public IP address range, and then click Add Rule.
  - Click Apply Rule Changes to apply these inbound rules.
7. On the Outbound tab, do the following:
  - Locate the default rule that enables all outbound traffic, and then click Delete.
  - Select HTTP from the Create a new rule list, make sure that Destination is 0.0.0.0/0, and then click Add Rule.
  - Select HTTPS from the Create a new rule list, make sure that Destination is 0.0.0.0/0, and then click Add Rule.
  - Click Apply Rule Changes to apply these outbound rules.
Launch an instance into the VPC:
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
2. From the dashboard, click the Launch Instance button.
3. On the Create a New Instance page, select Quick Launch Wizard, and then click Continue. Follow the directions in the wizard. Specify a name for your instance, choose a key pair, select an AMI, and then click Continue.
4. Click Edit Details. Under Instance Details, select Launch into a VPC and specify a subnet. Under Security Settings, select the WebServerSG security group that you created in step 2. Click Save Details.
5. Review the settings that you've chosen. Make any changes that you need, and then click Launch.
Assign an Elastic IP address to the instance:
1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
2. Click Elastic IPs in the navigation pane.
3. Click the Allocate New Address button.
4. From the EIP used in list, select VPC, and then click Yes, Allocate.
5. Select the Elastic IP address from the list, and then click the Associate Address button.
6. In the Associate Address dialog box, select the instance to associate the address with, and then click Yes, Associate.

You can now connect to your instances in the VPC. For information about how to connect to a Linux instance, see Connect to Your Linux Instance in the Amazon Elastic Compute Cloud User Guide. For information about how to connect to a Windows instance, see Connect to Your Windows Instance in the Amazon Elastic Compute Cloud Microsoft Windows Guide.

Document Conventions	« Previous Next »
Terms of Use	Did this page help you? Yes \| No \| Tell us about it...