Introduction
This chapter explains what components/services and configurations we need to allow Internet traffic to and from an EC2 instance. VPCs themselves are closed entities. If we need an Internet connection, we need to use an AWS Internet Gateway (IGW) service. The IGW is running on a Blackfoot Edge Device in the AWS domain. It performs Data-Plane VPC encapsulation and decapsulation, as well as IP address translation. We also need public, Internet routable IP addresses. In our example, we allocate an AWS Elastic-IP (EIP) address. Then we associate it with EC2 Instance. By doing it, we don’t add the EIP to the EC2 instance itself. Instead, we create a static one-to-one NAT entry into the VPC associated IGW. The subnet Route Table includes only a VPC’s CIDR range local route. That is why we need to add a routing entry to the Subnet RT, default or more specific, towards IGW. Note that a subnet within an AWS VPC is not a Broadcast domain (VPC doesn’t even support Broadcasts). Rather, we can think of it as a logical place for EC2 instances having uniform connection requirements, like reachability from the Internet. As a next step, we define the security policy. Each Subnet has a Network Access Control List (NACL), which is a stateless Data-Plane filter. The Stateless definition means that to allow bi-directional traffic flow, we have to permit flow-specific Request/Reply data separately. For simplicity, we are going to use the Subnet Default NACL. The Security Group (SG), in turn, is a stateful EC2 instance-specific Data-Plane filter. The Stateful means that filter permits flow-based ingress and egress traffic. Our example security policy is based on the SG. We will allow an SSH connection from the external host 91.152.204.245 to EC2 instance NWKT-EC-Fron-End. In addition, we allow all ICMP traffic from the EC2 instance to the same external host. As the last part, this chapter introduces the Reachability Analyzer service, which we can use for troubleshooting connections. Figure 3-1 illustrates what we are going to build in this chapter.
Figure 3-1: Setting Up an Internet Connection for Public
Subnet of AWS VPC.
Allow Internet Access from Subnet
The first part of the AWS VPC Internet Access includes four steps. First, we create an Internet Gateway. Then we associate it with our VPC. Third, we add a route towards IGW into the Subnet Route Table. As the last step, we update the Subnet NACL if needed. We are using the Default NACL that permits all traffic. Figure 3-2 illustrates these four steps.
Figure 3-2: Basic Internet Access Building Blocks.
Create Internet Gateway
Navigate to the VPC Dashboard. Then select the Internet Gateways either from the Virtual Private Cloud drop-down menu or from the Resources by Region section.
Figure 3-3: Create Internet Gateway, Step-1.
Figure 3-4 shows that we have a default Internet Gateway. Instead of using it, we create a new IGW. Click the Create internet gateway button.
Figure 3-4: Create Internet Gateway, Step-2.
Fill the Name tag in the Internet gateway settings section. The name that you give will be auto-filled as a Key/Value pair in Tag – optional section. To proceed, click the Create internet gateway button.
Figure 3-5: Create Internet Gateway, Step-3.
Attach the IGW with your VPC by selecting Attach to a VPC from the Actions drop-down menu or by clicking the Attach to a VPC button in the notification field.
Figure 3-6: Attach an Internet GW with a VPC, Step-1.
Select our VPC NVKT-VPC-01 from the drop-down menu of the Available VPCs section.
Figure 3-7: Attach an Internet GW with a VPC, Step-2.
After selecting the VPC, the AWS Command Line Interface command section appears. You can choose either Linux or Windows CLI commands to create an IGW-VPC association. Save the configuration by clicking the Attach internet gateway button.
Figure 3-8: Attach an Internet GW with a VPC, Step-3.
Figure 3-8 shows that you have succesfully created an Internet Gateway NWKT-IGW-01 (igw-0e997955bc6597031) and attached into the VPC NVKT-VPC-01 (vpc-04ef72cc79a73f82e).
Figure 3-9: Attach an Internet GW with a VPC, Step-4.
Now the new IGW is listed in the Internet gateway window.
Figure 3-10: Internet Gateway Configuration Verification.
Example 3-1 shows how we can verify the Internet Gateway configuration from the CLI in JSON format.
aws ec2 describe-internet-gateways --filters
Name=tag:Name,Values=NWKT-IGW-01
{
"InternetGateways": [
{
"Attachments": [
{
"State":
"available",
"VpcId":
"vpc-04ef72cc79a73f82e"
}
],
"InternetGatewayId":
"igw-0e997955bc6597031",
"OwnerId":
"123456654321",
"Tags": [
{
"Key":
"Name",
"Value":
"NWKT-IGW-01"
}
]
}
]
}
Example 3-1: Internet Gateway Configuration Verification
– JSON Format.
Update Subnet Route Table
The next thing to do is to add route towards the Internet Gateway into the Subnet Route Table. Navigate back to the VPC dashbord and select Route Tables. We are going to update the Route Table NWKT-PUB-RT that is associated with the subnet 10.10.0.0/24 (NWKT-Pub-euw2c | subnet-04af160d1d0aee071).
Figure 3-11: Subnet Route Tables.
Figure 3-12 shows that there is only a VPC CIDR range local route in the Route Table.
Figure 3-12: Subnet Route Tables – New Route Towards IGW.
You can see the Subnet-specific information by clicking the Explicit subnet associations hyperlink in the Details window shown in figure 3-12 above. Figure 3-13 shows that the Ipv4 CIRD block 10.10.0.0/24. You can navigate back to the Route Table view by clicking the Route Table hyperlink. Click the Edit routes button to add a new route (figure 3-12).
Figure 3-13: Subnet Route Tables – New Route Towards IGW,
Subnet Verification.
Add a default route 0.0.0.0/0 to the Destination field. Then select our Internet Gateway from the Target drop-down menu and click the Save changes button. You can also preview your changes by clicking the Preview button
Figure 3-14: Subnet Route Tables – New Route Towards IGW.
Figure 3-15: Subnet Route Tables – New Route Towards IGW - Preview.
After saving the changes the new route is shown in Route Table.
Figure 3-16: Subnet Route Tables – New Route Towards IGW
- Completed.
Network Access Control List
We are using our default Network ACL NWKT-NACL (acl-0dfc4c4ef28ae6491) in this example. It permits all Inbound (figure 3-17) and Outbound (figure 3-18) traffic by default and that’s fine for us because we will later use Security Groups for defining the access policy.
Figure 3-17: Network Access Control List – Inbound Rules.
Figure 3-18: Network Access Control List – Outbound Rules.
The Subnet association tab shows that this NACL is attached to both subnets 10.10.0.0/24 and 10.10.1.0/24.
The example below shows how you can check the NACL Inbound and Outbound rules by using the AWS CLI.
aws ec2 describe-network-acls --query
"NetworkAcls[2].Entries" --output table
-----------------------------------------------------------------
| DescribeNetworkAcls |
+-----------+---------+-----------+--------------+--------------+
|
CidrBlock | Egress | Protocol | RuleAction
| RuleNumber |
+-----------+---------+-----------+--------------+--------------+
| 0.0.0.0/0|
True | -1
| allow |
100 |
| 0.0.0.0/0|
True | -1
| deny |
32767 |
| 0.0.0.0/0|
False | -1
| allow |
100 |
| 0.0.0.0/0|
False | -1
| deny |
32767 |
+-----------+---------+-----------+--------------+--------------+
Example 3-2: Network Access Control List – Subnet
Association.
In the next part, we will launch an EC2 instance (t2.micro) and create a new Security Group, which we associate with the EC2 instance. We will also allocate an Elastic IP address from the AWS pool and associate it with the EC2 instance. When we have done all previous steps, we will test that everything works as expected. First, we open an SSH connection from the external host to the EC2 instance. Then we ping the external host from the EC2 instance command line. In addition, the next post introduces Reachability Analyzer that we can use for troubleshooting.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.