AWS VPC From Zero to Hero Series: 2, Build, Secure, and Monitor Networks on AWS
Tags: aws, beginners, networking
Published: 2024-02-16 14:25:22

This is a series of hands-on labs that start from beginner level to advanced level to give you a real understanding of AWS VPC.

## Overview
In this interactive lab, you'll construct and peer three VPCs—labeled A, B, and C to illustrate the escalating complexity of configuration and routing that accompanies the addition of multiple VPCs, gateways, and associated resources. You will then transition the network architecture to a hub-and-spoke design using AWS Transit Gateway. Additionally, you'll set up network monitoring and implement security measures to safeguard your resources.

## Topics covered
By the end of this lab, you will be able to do the following:
	• Set up routing between VPCs.
	• Select the appropriate connectivity options for an environment.
	• Capture network traffic information (metadata) with VPC flow logs.
	• Configure monitoring for networking statistics and metrics.
	• Filter network traffic with Network Access Lists (NACLs), and Security Groups (SG).

## Prerequisites
- An active AWS account.
- A user that has access to the AWS console with the needed permissions.
-  knowledge about basic networking concepts (such as IP Addressing, CIDR notation, and routing), an understanding of basic cloud operations, and familiarity with navigating in the AWS Management Console.

## Duration
This lab requires approximately 120 minutes to complete.

## Task 1: Build a Multi-VPC Architecture
you will provision three logically isolated sections of the AWS Cloud into VPCs. In addition to using multiple VPCs, you will span the environment across multiple Availability zones (AZ) within a Region. After creating these VPCs, you will launch Amazon Elastic Compute Cloud (Amazon EC2) instances into the virtual networks that you define.
Each of the VPCs you create requires an internet gateway (IGW). This is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in your VPC and the internet. It therefore imposes no availability risks or bandwidth constraints on your network traffic.
You will finish this task by observing that by default, EC2 instances in different VPCs are not able to communicate with each other using private IP addresses.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vvtprfro982df6k7jq5a.png)

## TASK 1.1: CREATE THREE VPCS WITH PRIVATE SUBNETS
In this task, you will be creating three VPCs with private subnets. Each VPC will have subnets in two Availability Zones within the Region.
 Table 1. The below table shows IPv4 CIDR allocations for VPCs and AZs
![Table 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nm1sy6iclty6qn29hdkc.png)

### Task 1.1.1: Create VPCs
Our first step is to create VPCs with non-overlapping CIDR blocks.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k61b29zm4dhx7vzjk8br.png)

We will not create the VPC as we did in [lab 1](https://dev.to/ahmedshendy/netcraft-the-aws-vpc-adventure-series-adventure-1-35kg) using **VPC and more** option, In this lab we will use **VPC only** option to get more control on the created resources.
1- Go to VPC service
2- Choose **Create VPC** and configure the following:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/siituq3jhgg1win5svxw.png)
3- Follow the same steps to create **VPC B** and **VPC C**; refer to Table 1.
4- Now we have these 3 VPCs
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lnz0cqoxnghekv6ic94q.png)

### Task 1.1.2: Create Subnets
For each VPC, we will create two subnets - one per availability zone (AZs name could differ - depending on your chosen region).
![VPC with subnets](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/440mcpndktgrmhwgnd4l.png)
5- On the left navigation pane, under  **Virtual private cloud**, choose **Subnets**.
6- Choose **Create subnet** to create subnets for VPC A configure the following:
	• **VPC ID**: VPC A 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qfnzgyusrcenmx0uit4u.png)
	• **Subnet name**: VPC A - AZ1
	• **Availability Zone**: Select the first Availability Zone in the list. (Do not choose No Preference)
	• **IPv4 CIDR block**: 10.0.0.0/24
	• **Tags**: Accept proposed Tags
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pw8ukdzncaeqg6yhrkpr.png)

7- Choose **Add new subnet** to add Subnet 2 of 2 into AZ2 and configure the following:
	• **Subnet name**: VPC A - AZ2
	• Availability Zone: Select the second Availability Zone in the list. (Do not choose No Preference)
	• **IPv4 CIDR block**: 10.0.1.0/24
	• **Tags**: Accept proposed Tags.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nm238qte0ttdoqvjujkj.png)
8- Choose Create subnet.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dsp2jcpr5bf5eu5d5jpp.png)

9- Repeat the steps above to create subnets for VPC B and VPC C; refer to the below table for copying subnet name and subnet CIDR allocations.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jplfii5g6w9wpy3jk5w9.png)
After you finish the task, six new subnets should be available.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/630dz787bn88df8yb3sn.png)

### Task 1.1.3: Deploy Internet Gateways
In this section, you will deploy one Internet Gateway (IGW) per VPC. You need an Internet Gateway to establish outside connectivity to EC2 instances in VPCs.
10- On the left navigation pane, under  **Virtual private cloud**, choose **Internet gateways**.
11- Choose **Create internet gateway** and configure the following:
	• Name tag: VPC A - IGW
	• Tags: Accept proposed Tags
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ui27n6y1tlniji3dm8b9.png)
12- Choose **Create internet gateway**.
13- From **Actions** Select **Attach to a VPC**.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x5wk504hnrn48kkxe22r.png)
14- For Available VPCs, choose VPC A.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ojnajiisyqwy6ranvhxk.png)
15- Choose **Attach internet gateway**.
16- Repeat the above steps to create and attach IGWs 
VPC B - IGW to VPC B and 
VPC C - IGW to VPC C.
 You should now have an IGW for the default VPC and three newly created IGWs available.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fje41bnpnm1ltyg5tlel.png)

### Task 1.1.4: Update Routing Tables
To utilize newly created Internet Gateways, you need to update VPC routing tables to point the default routes to these IGWs.
17- On the left navigation pane, under  **Virtual private cloud**, choose **Route tables**.
 Please make sure that you **DO NOT** create a new Route table. Please follow the next steps to rename the existing Main Route table.
18- Select the Route table that belongs to VPC A.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fy8518eiln8ozqrde2xo.png)
19- Edit the name to be: VPC A Route Table
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6akra55mw4h8bl3yiasn.png)
20- Make the same for the other 2 route tables
21- Select  **VPC A Route Table**.
22- Choose the **Routes** tab in the lower half of the page.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0m2t5bin9xhydzkhy5k1.png)
 There is one route in your route table that allows traffic within the 10.0.0.0/16 network to flow within the network, but it does not route traffic outside of the network.
23- Choose **Edit routes**.
24- Choose Add route and then configure the following:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ef9phfbabf5ow5cxrpp6.png)
25- Choose **Save changes**.
26- Repeat the above steps to add the default route 0.0.0.0/0 to the Route tables
VPC B Route Table for VPC B and 
VPC C Route Table for VPC C.

## TASK 1.2: DEPLOY EC2 INSTANCES IN VPC’S
You will deploy one EC2 instance per VPC and demonstrate that, by default, VPCs provide network isolation. The EC2 instances should not be able to reach each other using ping (a common diagnostic tool) before the next task is completed.
27- At the top of the AWS Management Console, to the right of the Services menu, in the search bar, search for **EC2** and then choose **EC2** from the list.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ak2o439xwdwt5n7justm.png)
28- On the left navigation pane, choose **Instances**.
29- Choose **Launch instances** and configure the following:

- Name and tags: Under Name, enter EC2 VPC A - AZ1
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/86ynwehz2gqgw5nn6fz1.png)
- Application and OS Images (Amazon Machine Image):
-- Quick Start: Select Amazon Linux
        ○ Amazon Machine Image (AMI): Amazon Linux 2 AMI (HVM), SSD Volume Type
        ○ Architecture: 64-bit (x86) 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/718i49h5rjwn60u41dug.png)
	•  Instance type: t2.micro 
	•  Key pair (login): Proceed without a key pair (Not recommended) 
 You will use SSM session Manager to access the shell running on the EC2, so a key pair is not needed in the lab.
30- Scroll down to  Network settings, choose **Edit**, and configure the following:
	• VPC - required: VPC A 
	• Subnet: VPC A - AZ1 
	• Auto-assign public IP: Enable 
	• Firewall (security groups):
		○ Choose  Create security group
		○ Security group name - required: VPC A EC2 Security Group
		○ Description - required: Allow ICMP Traffic
	• Inbound security groups rules:
		○ Type: Select All ICMP - IPv4 from the dropdown instead of SSH
		○ Source type: Custom 
		○ Source: 10.0.0.0/8
 It is not a best practice to have wide open Security groups that allow anyone/everyone such as 0.0.0.0/0, to limit access to only what is required.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hy0aete7r5cihijkcx9f.png)
31- Scroll down to  **Advanced details** and configure the following:
	• IAM instance profile: From the drop-down list, select  **AmazonSSMRoleForInstancesQuickSetup**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nnp4wxo3p4hcfd6uym26.png)
32- Choose **Launch instance**.
33- Choose **View all instances** to display all the instances launched.
34- Occasionally choose the console refresh button and wait for Public Instance to display the Instance state as  Running and wait for Status check to pass  2/2 checks passed.
 The Amazon EC2 instance named Public Instance is initially in a Pending state. The instance state then changes to Running indicating that the instance has finished booting.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fjpdka0c9go6wc9sr5tj.png)
35- Launch 2 more EC2 instances and assign them names accordingly:
i. Second EC2 instance in VPC B with the following configuration
	• Name and tags: EC2 VPC B - AZ1
	• Network settings:
		○ VPC - required: VPC B 
		○ Subnet: VPC B - AZ1 
	• Firewall (security groups):
		○ Security group name - required: VPC B EC2 Security Group
		○ Description - required: Allow ICMP Traffic
 Except for the above details, keep all other configurations same as first EC2 instance.
ii. Third EC2 instance in VPC C with the following configuration
	• Name and tags: EC2 VPC C - AZ1
	•  Network settings:
		○ VPC - required: VPC C 
		○ Subnet: VPC C - AZ1 
	• Firewall (security groups):
		○ Security group name - required: VPC C EC2 Security Group
		○ Description - required: Allow ICMP Traffic
 Except for the above details, keep all other configurations same as first EC2 instance.
 For all EC2 instances, update the Security Group rules under the Security tab to allow ICMP traffic. There is no need to have a rule for SSH since SSM Session Manager will be used to connect to the terminal.
 After a few minutes, you should now have 3 EC2 instances in the  Running state.
36- Copy the  Private IPv4 addresses assigned to EC2 instances by choosing an Instance and navigating to the Details tab.
37- Copy the following table with IP information to your favorite notepad tool, and populate the private IP addresses that you copied in the previous step.
 Table 2. Populate the following table with EC2 instances' private IP Addresses:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8et9lue06ho3vxtfmdw4.png)

## TASK 1.3: TEST INTER-VPC COMMUNICATION BETWEEN EC2 INSTANCES
Now that the EC2 instances are available in each VPC, you will use ping (a common diagnostic tool) to verify that the instances cannot communicate demonstrating how VPCs provide isolation.

38- At the top of the AWS Management Console, to the right of the Services menu, in the search bar, search for EC2 and then choose EC2 from the list.
39- On the left navigation pane, choose Instances.
40- Select the  EC2 VPC A - AZ1 instance.
41- Choose **Connect** from the navigation bar.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bc4v4gd9oz97nmy580nq.png)
42- With **Session Manager** tab selected, choose **Connect**.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/npsdj0mqcc3i5l7pjlp0.png)
A terminal session should open in a new browser tab.
43- From the EC2 VPC A - AZ1 instance in VPC A, try pinging the private IP addresses of:
- EC2 VPC B - AZ1 instance in VPC B and
- EC2 VPC C - AZ1 instance in VPC C.
Check if those addresses are pingable.
ping 10.1.0.x
 Refer to Table 2. for the private IP addresses of the instances.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wwfl5kdkl9sv9c6sn1zy.png)

## TASK 1.4: SETUP VPC PEERING
The end of the previous task demonstrated that EC2 instances in different VPCs cannot reach each other on their private IP addresses. but, we want to ensure that all the traffic between VPCs is on the AWS Backbone, and not traversing the internet. You will achieve this using VPC peering. VPC Peering is a connection between two VPCs that enables you to route your traffic between them.
In this task, you will establish VPC peering links between VPC A and VPC B, as well as VPC A and VPC C. Note that all three VPCs have non-overlapping CIDRS. You cannot create a VPC peering connection between VPCs with matching or overlapping IPv4 CIDR blocks.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p59vibv13alyidm5n5i0.png)

44- At the top of the AWS Management Console, to the right of the Services menu, in the search bar, search for **VPC** and then choose VPC from the list.

45- On the left navigation pane, under  **Virtual private cloud**, choose **Peering connections**.

46- Choose **Create peering connection** and configure the following:
- Name: VPC A <-> VPC B
- VPC ID (Requester): VPC A 
- Account:  My account
- Region:  This Region (xx-xxxx-x) Make sure the region labeled AWSRegion in the left side of the instructions matches with the region where you are creating the VPC Peering connection.
- VPC ID (Accepter): VPC B 
- Tags: Accept proposed Tags
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d6ur9e9fu4wgr76kp61n.png)
47- Choose **Create peering connection**.
The status transitions through Initiating Request to Pending Acceptance.
48- From the **Actions** button, choose **Accept request**.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k8xk0gtxh8mv4oenagfx.png)
49- Choose **Accept request**.
50- Repeat the above steps to create VPC A <-> VPC C peering connection with the following configuration:
- Name: VPC A <-> VPC C
- VPC ID (Requester): VPC A 
- Account:  My account
- Region:  This Region (xx-xxxx-x)
- VPC ID (Accepter): VPC C 
- Tags: Accept proposed Tags
You should now have two active peering connections.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mohbench6vewbf8lkp6x.png)

### Task 1.4.1: Update Route Tables for VPCs
51- On the left navigation pane, under  **Virtual private cloud**, choose **Route Tables**.

#### A. Update Route Table for VPC A
52- Select  **VPC A Route Table**.
53- Choose **Routes** tab.
54- Choose _Edit routes_.
55- Choose Add route to add VPC B CIDR in Destination to enable VPC A to reach VPC B through the VPC peering connection:
- Destination: 10.1.0.0/16
- Target: Choose Peering Connection from drop-down list
- Select pcx-xxxxxxxxxx (VPC A <-> VPC B)  from the drop-down list 

56- Choose Add route to add VPC C CIDR in Destination to enable VPC A to reach VPC C through the VPC peering connection:
- Destination: 10.2.0.0/16
- Target: Choose Peering Connection from drop-down list
- Select pcx-yyyyyyyyyy (VPC A <-> VPC C)  from the drop-down list
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zb1s64n7l39klutsslxr.png)
57- Choose **Save changes**.
#### B. Update Route Tables for VPC B

58- On the left navigation pane, under  Virtual private cloud, choose Route tables.
59- Select  VPC B Route Table.
60- Choose Routes tab.
61- Choose Edit routes .
62- Choose Add route to add VPC A CIDR in Destination to enable VPC B to reach VPC A through the VPC peering connection:
- Destination: 10.0.0.0/16
- Target: Choose Peering Connection from drop-down list
- Select pcx-xxxxxxxxxx (VPC A <-> VPC B)  from the drop-down list

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m24eii018d9x8y177svj.png)
63- Choose **Save changes**.
#### C. Update Route Table for VPC C
64- On the left navigation pane, under  Virtual private cloud, choose Route tables.
65- Select  VPC C Route Table.
66- Choose Routes tab.
67- Choose Edit **routes**.
68- Choose Add route to add VPC A CIDR in Destination to enable VPC C to reach VPC A through the VPC peering connection:
- Destination: 10.0.0.0/16
- Target: Choose Peering Connection from drop-down list
- Select pcx-yyyyyyyyyy (VPC A <-> VPC C)  from the drop-down list
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/34qkjabblwqqjeywj7tq.png)

69- Choose **Save changes**.
#### D. Check EC2 connectivity in VPC A
70- At the top of the AWS Management Console, to the right of the Services menu, search for **EC2** in the search bar and then choose EC2 from the list.
71- On the left navigation pane, choose **Instances**.
72- Select the  EC2 VPC A - AZ1 instance.
73- Choose Connect from the navigation bar.
74- With the Session Manager tab selected, choose **Connect**.
If peering and routing are configured correctly, you can ping both instances.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2soz3glme5htw6km28r3.png)
75- Select the  EC2 VPC B - AZ1 instance.
76- Choose Connect from the navigation bar.
77- With the Session Manager tab selected, choose **Connect**.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yb60joazg1llcxmx72v1.png)

From the above image, you can find that **EC2 VPC B - AZ1** ping to EC2 inside VPC A, but can't pint to EC2 inside VPC C, this is due that there is a peering between VPC B and VPC A, but there is no peering between VPC B and VPC C.

## TASK 1.5: SIMPLIFY ROUTING USING AWS TRANSIT GATEWAY
In the previous section, you created VPC Peering Links to facilitate connectivity between the VPCs, without sending that traffic over the public internet. While this approach can be used to interconnect many VPCs, managing many point-to-point connections can be cumbersome as the number of VPCs you connect grows. A more scalable approach is to utilize AWS Transit Gateway.
In this task, you will remove point-to-point peering connections between **VPC A** and **VPC B**; **VPC A** and **VPC C**. You will set up Transit Gateway (TGW) and use it to interconnect VPC A, VPC B, and VPC C.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pknvrlqcs9dfqiu16xvt.png)

### Task 1.5.1: Delete VPC Peering Connections
78- At the top of the AWS Management Console, to the right of the Services menu, in the search bar, search for VPC and then choose VPC from the list.
79- On the left navigation pane, under  **Virtual private cloud**, choose **Peering connections**.
80- Select  VPC A <-> VPC B peering connection.
81- From the Actions button, choose Delete peering connection.
82- Select the option to  Delete related route table entries to avoid traffic blackholing scenarios.
83- To confirm deletion, type _delete_ in the field: delete.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/abw758v2awd7sbu1m7tv.png)
84- Choose **Delete**.
85- Repeat the above steps to delete VPC A <-> VPC C peering connection.

### Task 1.5.2: Setup Transit Gateway
#### A. Create Transit Gateway
86- On the left navigation pane, under  **Transit gateways**, choose **Transit gateways**.
87- Choose **Create transit gateway** and configure the following:
- Name tag: TGW
- Description: Lab Transit Gateway TGW
- Amazon side Autonomous System Number (ASN): 64512
The Amazon side ASN or Multicast support cannot be changed after the transit gateway is created.

- DNS support:  enable
- VPN ECMP support:  enable
- Default route table association:  enable
- Default route table propagation:  enable
- Multicast support:  enable
- Keep the default settings for the rest of the parameters
88- Choose **Create transit gateway**.
A few moments later, TGW will transition from Pending to  Available state.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ec81gve3uf2uynytivq5.png)

#### B. Create Transit Gateway attachments subnets
According to best practices, it is recommended to use a separate small /28 subnet for each transit gateway VPC attachment.
Table 3. The below table shows IPv4 CIDR allocations for all Subnets in all the VPCs.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ajg0r18n239d5a74fkl2.png)

The availability zones in the above table are shown as an example. Please use the availability zones from the region where your lab is deployed.

89- On the left navigation pane, under  Virtual private cloud, choose Subnets.
90- Choose Create subnet and configure the following:

- VPC ID: VPC A 
- Subnet name: Create subnets with names that reflect VPC and AZ placement, such as VPC A - AZ1 TGW
- Availability Zone: Select the first Availability Zone in the list. (Do not choose No Preference)
- IPv4 CIDR block: 10.0.2.0/28
- Tags: Accept proposed Tags
91- se Add new subnet and configure the following:

- Subnet name: Create subnets with names that reflect VPC and AZ placement, such as VPC A - AZ2 TGW
- Availability Zone: Select the second Availability Zone in the list. (Do not choose No Preference)
- IPv4 CIDR block: 10.0.3.0/28
- Tags: Accept proposed Tags
92- Choose **Create subnet**.
93- Repeat the steps above to create subnets for VPC B and VPC C; refer to Table 3. above for CIDR allocations.
After you finish the task, six new Transit Gateway attachment subnets should be available.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gxn7vvmqymtm2open9ph.png)

#### C. Create Transit Gateway attachments
94- On the left navigation pane, under  Transit gateways, choose Transit gateway attachments.
95- Choose **Create transit gateway** attachment and configure the following:

- Name tag: VPC A Attachment
- Transit Gateway ID: TGW 
- Attachment type: VPC 
- VPC ID: VPC A
- Subnet IDs: Choose both subnets from the drop-down list:
   - VPC A - AZ1 TGW
   - VPC A - AZ2 TGW
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rzp24g6pkiu07wwg7jyh.png)

96- Choose Create transit gateway attachment .
97- Repeat these steps to create attachments 
- VPC B Attachment for VPC B 
- VPC C Attachment for VPC C
Upon completion, you should see three Transit Gateway attachments.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kvuiu6wqrknctntoupu7.png)

#### Task 1.5.3: Check Transit Gateway route table
98- On the left navigation pane, under  Transit gateways, choose Transit gateway route tables.
99- Select the route table you see with the route table ID starting with  tgw-rtb-xxxxxxxxxxxxxx.
100- Choose the Routes tab in the lower half of the page.
Your routing table should be populated with VPC A, VPC B, VPC C routes.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g2dodtotkhyqnxljzcs0.png)

#### Task 1.5.4: Update Route Tables of VPCs
101- On the left navigation pane, under  Virtual private cloud, choose Route tables.
102- Select  VPC A Route Table.
103- Choose Routes tab.
104- Choose Edit routes .
105- Choose Add route and configure the following:
- Destination: Enter 10.0.0.0/8
- Target: Choose Transit Gateway from the drop-down list and then choose the displayed Transit Gateway ID.
You can do this because the existing local route for VPC A (10.0.0.0/16) is more specific and therefore, any traffic for 10.0.0.0/16 will traverse the more specific local route to the VPC. Anything other traffic for 10.0.0.0/8 will traverse the less specific route (10.0.0.0/8) to the transit gateway.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/84y55r0ckmdrlfxfvcp3.png)
106- Choose Save changes .
107- Repeat these steps to create 10.0.0.0/8 route pointing to the TGW Transit Gateway in VPC B Route Table and VPC C Route Table Routing tables.

### TASK 1.6: CHECK CONNECTIVITY BETWEEN VPCS USING THE TGW
Now connect to any EC2 as we did before and try to ping to the other 2 EC2s, it will work from any EC2 to other EC2s
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dobjyudccnh1kzxkj0k9.png)


## Task 2: Configure Network Monitoring
In this task, you will set up a way to log network traffic using VPC Flow logs. You will also use Amazon CloudWatch to monitor and alarm based on predetermined conditions. Finally, you will explore dashboards where you can customize your experience.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f4242xlw57218d38mxmq.png)
You will utilize the three VPCs with Internet Gateways, Transit Gateway, and EC2 instances that were created in task 1. You will set up VPC Flow logs for VPC A, generate some traffic, and then view the logs in CloudWatch.

### TASK 2.1: CREATE VPC FLOW LOGS
VPC Flow Logs is a feature that enables you to capture information (metadata) about the IP traffic going to and from network interfaces in your VPC. For example, if you have a content delivery platform, flow logs can profile, analyze, and predict customer patterns of the content access, and track down top talkers and malicious calls.
In this task, you will create a flow log for all traffic in VPC A and save it to the destination log group VPCFlowLog.

#### Task 2.1.1: Create CloudWatch Log group
108- At the top of the AWS Management Console, to the right of the Services menu, in the search bar, search for **CloudWatch** and then choose CloudWatch from the list.

109- On the left navigation pane, under  Logs, choose **Log groups**.

110- Choose Create log group and configure the following:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/edbe91e41rd3wacjo1w4.png)

111- Choose **Create**.

### Task 2.1.2: Create Create an IAM role for flow logs
112- At the top of the AWS Management Console, to the right of the Services menu, in the search bar, search for **IAM** and then choose IAM from the list.
113- On the left navigation pane, under  **Access management**, choose **Policies**.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1b53dhhsymf82epzq83l.png)
114- Choose **Create policy** group and configure the following:
- Chose **JSON**
- replace the content with this json
`{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": "*"
    }
  ]
}   `
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s5f8c4k0fgwyza0u6bfs.png)

115- Choose Next.
116- Enter **Policy name**: VPCFlowLogPolicy
117- Choose Create policy

118- On the left navigation pane, under  **Access management**, choose **Roles**.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fj4v7544or0wad2i25ux.png)
119- Choose **Create role** group and configure the following:
- Trusted entity type: Custom trust policy. 
- Custom trust policy: replace "Principal": {}, with the following.
`"Principal": {
   "Service": "vpc-flow-logs.amazonaws.com"
},`
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kvh0cpcuw0g0qnz4ld13.png)
120- Choose **Next**
121- In Add permissions select the **VPCFlowLogPolicy**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jt2v8s1xj2peenh5g6gd.png)
122- Choose **Next**
123- Enter **Role name**: VPCFlowLogRole
124- Choose **Create**


### Task 2.1.3: Create VPC Flow log
112- Go to VPC A
113- From **Actions**  and choose _Create flow log_
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9eowaolt6bdoeyitxiyd.png)
114- On the Create flow log page, under Flow log settings, configure the following:
- Filter:  All
- Maximum aggregation interval:  1 minute
- Destination:  Send to CloudWatch Logs
- Destination log group: VPCFlowLog
- IAM role: VPCFlowLogRole
- Log record format:  AWS default format
114- Choose **Create flow log**.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/007l8vghrzw9rt1lm9u2.png)

### TASK 2.2: GENERATE NETWORK TRAFFIC BETWEEN VPCS
IP traffic going to and from network interfaces in VPC A is now being collected in through VPC Flow Logs and stored using an Amazon CloudWatch Log Group. You need to verify that your monitoring is setup properly. To accomplish this, you will generate some traffic between the Amazon EC2 instance in 

VPC A
 (EC2 VPC A – AZ1), and instance in 

VPC B
 (EC2 VPC B – AZ1) using 

iperf
 (a widely used tool for network performance measurement and tuning).

#### Task 2.2.1: Update Security Group for EC2 instance in VPC B
First, you will have to update the Security Group for the Amazon EC2 instance in VPC B to allow the iperf server to receive incoming traffic.
115- Go to **EC2 VPC B - AZ1**, and choose **Security** tab

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uexv1i5hkr8xcuiceem5.png)
116- Choose on the Security Group with ID starting with sg- (VPC B EC2 Security Group) in the lower pane to view and edit its rules.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/12bgo113rk9e5fsezhvn.png)
117- On VPC B EC2 Security Group Security Group page, at the bottom of the page, choose the Inbound rules tab.
118- At the right side of the Inbound rules section, choose Edit inbound rules .

119- On the Edit inbound rules page, choose Add rule and configure the following:
- Type: Custom TCP 
- Port range: 5201
- Source type: Custom 
- Source: 10.0.0.0/16
You added a rule to allow traffic on TCP port 5201 from the Amazon EC2 instance in VPC A by allowing the VPC CIDR 10.0.0.0/16 in the source.
120- Choose **Save rules**.

#### Task 2.2.2: Install and run iperf3 server on EC2 instance in VPC B
121- Connect to **EC2 VPC B - AZ1**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/455j09z6o6q1k65iehcu.png)

122- Enter the following command to install iperf:
`sudo yum install iperf3 -y`

123-  Enter the following command to start the iperf server on the EC2 instance in VPC B:
`iperf3 -s`
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3uel7y3e1etlixsbtwk6.png)

#### Task 2.2.3: Perform the following on the EC2 instance in VPC A
124- Connect to **EC2 VPC A - AZ1** using the session manager as we did before.
125- Enter the following command to install iperf:
`sudo yum install iperf3 -y`

126- Enter the following command to set up a TCP transfer with 2 parallel streams for 30 seconds to the EC2 instance in VPC B. Make sure to replace 

<PRIVATE IP OF "EC2 VPC B - AZ1" INSTANCE 10.1.0.X>
 in the following command:
`iperf3 -c <PRIVATE IP OF "EC2 VPC B- AZ1" INSTANCE 10.1.0.X> -P2 -t 30`
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4d5xru5iwsd0r8pxlv9h.png)

127- Shutdown the iperf3 server running on EC2 VPC B - AZ1 instance in VPC B by switching back to Session Manager and by pressing CTRL+C.

### TASK 2.3: VIEW FLOW LOGS IN CLOUDWATCH
VPC Flow logs can be sent to either an Amazon S3 bucket or CloudWatch. In this lab, you configured the flow logs from VPC A to be sent to CloudWatch. Navigate to CloudWatch to view the logs.
Anatomy of a flow log:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xo9j9faikk8ic3pwxvh7.png)

128- Go to VPC service and select VPC A.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fmqb6cqab91z66dx719v.png)

129- In the Details pane at the bottom of the page, choose the Flow logs tab.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7jjz3awvw7ldpva6npny.png)

130- Under **Destination name**, choose **VPCFlowLog**  to navigate to CloudWatch.
 When publishing to CloudWatch, flow log data is published to a log group, and each network interface has a unique log stream in the log group. Log streams contain flow log records. You can create multiple flow logs that publish data to the same log group.
131- Select one of the network interface (ENI) log streams to see the flow records for that interface.
 To find the appropriate log, use ENI from EC2 VPC A - AZ1 (on EC2 Instance - Networking Tab scroll to see Networking interfaces list).

### TASK 2.4: QUERY FLOW LOG FOR INSIGHTS
CloudWatch Logs Insights enables you to interactively search and analyze log data in CloudWatch Logs, including VPC flow logs. You can perform queries to help you more efficiently and effectively respond to operational issues.
Run a query to show the top 10 talkers based on bytes transferred.

132- Navigate to the browser tab with **CloudWatch** service.
133- On the left navigation pane, under  **Logs**, choose **Logs Insights**.
134- From the drop-down list, select  VPCFlowLog.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rw8fqzy9qn75ab0hj6vh.png)
135- On the right navigation pane, choose  Queries.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tid2p5u0pj6m2cq8anxq.png)

136- Under Sample queries, expand  VPC Flow Logs.
137- From the list, choose  Top 10 byte transfers by source and destination IP addresses.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jqwba134mterveo21res.png)
138- Choose **Apply**.
139- Choose **Run query**.
Review the query results. Do you recognize the top two IP addresses?
 Hint: Take a look at the Primary private IPv4 address and Description columns in the EC2 - Network Interfaces and see what they are for.

### TASK 2.5: USING AMAZON CLOUDWATCH TO SET AN ALARM
Amazon CloudWatch is a metrics repository. Amazon VPC publishes data points to Amazon CloudWatch for your transit gateways and transit gateway attachments. CloudWatch enables you to retrieve statistics about those data points as an ordered set of time series data, known as metrics. In this section, you will create a static route, set up an alarm on a threshold breach, and set up a dashboard to view a set of metrics on one page.

#### Task 2.5.1: Create a static route
You can create a static route for a VPC, VPN, or transit gateway peering attachment, or you can create a blackhole route. The blackhole state indicates that the route’s target isn’t available. For more details on the static route and blackhole route, check Additional Resources.
In this section, you will create a blackhole route in your transit gateway route table that drops traffic that matches the route. This task is necessary to view the CloudWatch Metrics in the later task.

140- Go to VPC page.
141- On the left navigation pane, under  Transit gateways, choose Transit gateway route tables.
142- Select the route table you see with the route table ID starting with  tgw-rtb-xxxxxxxxxxxxxx.
143- Choose the Routes tab in the lower half of the page.
144- Choose **Create static route**.
145- Under Details, configure the following:
- CIDR: Enter 10.3.0.0/16
- Type: Choose  Blackhole
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dx88he4gvtgqxivcb73w.png)
146- Choose **Create static route**.

### Task 2.5.2: Create Alarm
You can create a CloudWatch alarm that monitors CloudWatch metrics for a given AWS service. CloudWatch will automatically send you a notification when the metric reaches a threshold you specify.
Create an alarm that monitors the number of packets dropped because they match a blackhole route of a Transit gateway. If the packets are dropped, an email notification is sent to the configured email address.

147- Go to CloudWatch service.
148- On the left navigation pane, under CloudWatch  Alarms, choose All alarms.
149- Select **Create alarm** .
150- Choose **Select metric** .
151- On the **Select metric** page, under the Metrics section, select the TransitGateway card.
152- Select the _Per-TransitGateway Metrics_ card.
153- Search for  _PacketDropCountBlackhole_ .
154- Select tgw-xxxxxxxxxxxxxx Transit Gateway.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wcg0gh45l9gjotoxrdi0.png)
155- Choose **Select metric** .
156- On the Metric page, change the Statistic and Period parameters to the following:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9jkyf4678j95jn6tt6ro.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/se5fpotaw1fpic5aksxe.png)
157- On the Conditions section, configure the following:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/52dv04ukak23nh4v80ld.png)
158- Choose **Next** .
159- On the Notification page, configure the following:
- Alarm state trigger:  In alarm
- Send a notification to the following SNS topic:  Create new topic
- Create a new topic… :PacketDropCountBlackhole-Alarm
- Email endpoints that will receive the notification… Enter your email address where you want to receive the alarm notification.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qylkx2565vm5xj7r3bvh.png)
160- Choose _Create topic_.
161- Choose **Next** .
162- For the Alarm name, enter _PacketDropCountBlackhole-Alarm_.
163- Choose **Next** .
164- Review the settings on the next page and choose **Create alarm**.
The State of the alarm may show Insufficient data. This will happen until enough data points are received by the alarm.
 Under Actions you may see Pending confirmation which means that you have not confirmed the subscription yet.
 Amazon SNS will send a confirmation response to your email address. Be aware that this can take a few moments for it to be delivered.
165- Go into your email, open the new email from AWS Notifications and choose the Confirm subscription link.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ul7mfm2dupx64rpwcqbu.png)
A new browser page opens indicating the subscription status has changed to Subscription Confirmed! This will be required to ensure you receive the notification.
### Task 2.5.3: Trigger Alarm
In this section, you will get the opportunity to trigger the alarm and test the notification that you configured.
166- Go to the EC2 service page
167- Using session manager to connect to _EC2 VPC A - AZ1_ instance. 
168- From the _EC2 VPC A - AZ1_ instance in VPC A try pinging any private IP address belonging to _10.3.0.0/16_ CIDR range for example _10.3.0.0_
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e8kdcqh7icay2otc410a.png)
If the number of packets dropped is greater or equal to 1 because they matched a blackhole route of a Transit gateway, then it will activate the CloudWatch Alarm you created.
169- Go to **CloudWatch** service page.
170- On the left navigation pane, under CloudWatch  Alarms, choose All alarms.
171- Confirm that the State of the PacketDropCountBlackhole-Alarm alarm is in alarm.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4md5dvrxlqbz9inw3ilp.png)
Please note that it may take a few minutes before you see the state change to In alarm.
 The number of packets dropped crossed the set threshold. This will invoke the CloudWatch Alarm you created, which will send a message to the Amazon SNS topic. Amazon SNS will then send you an email message.
172- Check your email to confirm that you received a notification with the subject ALARM: “PacketDropCountBlackhole-Alarm” alerting you that your Amazon CloudWatch Alarm has entered the ALARM state.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tzibb8i1izpknwbooxpd.png)

### Task 2.5.4: Create dashboard
Amazon CloudWatch dashboards are customizable home pages in the CloudWatch console that you can use to monitor your resources in a single view, even those resources that are spread across different Regions. You can use CloudWatch dashboards to create customized views of the metrics and alarms for your AWS resources.
In this section, you will create a CloudWatch Dashboard to view the **PacketDropCountBlackhole** metric for the Transit Gateway.

173- On the left navigation pane, choose Dashboards.
174- Select **Create dashboard** .
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4rzwbvdbag3eac4tmcww.png)

175- Enter **PacketDropCountBlackhole-Dashboard** for Dashboard name.
176- Choose **Create dashboard** .
177- Select Number on the Add widget page, then choose **Next**.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hl5d0oac9ew294yxkdsf.png)
178- On the **Add metric graph** page, under the **Metrics** section, select the _TransitGateway_ card.
179- Select the _Per-TransitGateway Metrics_ card.
180- Search for  _PacketDropCountBlackhole_ .
181- Select tgw-xxxxxxxxxxxxxx Transit Gateway.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ibuqwwwovoa5b5cm0evs.png)

181- Choose **Graphed metrics (1)** tab.
182- Change the Statistic and Period parameters:
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/631l9x77l694akhv32o6.png)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1byex8e1k54f9c98oyd5.png)

183- Scroll to the top of the Add metric graph page. Near the top of the screen, by _Untitled graph_, choose the Edit icon.
184- Enter a name for the graph, such as PacketDropCountBlackhole-Graph.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d0vojrpf1368qmb16s6z.png)

185- Choose **Apply** .
186- Choose **Create widget** at the bottom of the page.
187- At the top of the dashboard, choose **Save**.
You can resize the widget by dragging the lower right corner of the graph. Change the data time span to 1h for better visualization. After making these modifications, always remember to choose **Save** button to save your Dashboard changes.
 **_Task complete_**: You have successfully generated traffic between instances, viewed the flow log in CloudWatch, and configured a CloudWatch Alarm, and a CloudWatch Dashboard.

## Task 3: Security Controls
Recall that at the end of Task 1, you had provisioned 3 AWS VPCs and EC2 instances in each VPC. The VPCs were interconnected using Transit Gateway. The environment is depicted as below.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/57jgvgvzly8of40hps7j.png)

You will now be adding security to the environment you have built. You will use Network Access Lists (NACLs) and Security Groups, which are basic filtering mechanisms.


### TASK 3.1: MODIFYING DEFAULT NETWORK ACLS TO BLOCK, ALLOW SUBNETS
Network ACLs are stateless access controls you configure at a subnet level, to allow or block a CIDR block on a particular port or range of ports. Network ACL rules are numbered list and evaluated top down, with a DENY ALL at the end. If a rule is matched, subsequent rules are not evaluated.
Both inbound and outbound traffic can be controlled with these rules. By default when you have created the above subnets, the default Network ACL attached to them will have an ALLOW ALL rule for both inbound and outbound traffic.
In this task, you will modify Network ACL on **VPC A - AZ1** to allow only VPC B’s CIDR; and test connectivity using ping to send ICMP traffic from VPC B to VPC A, and from VPC C to VPC A as well.
 According to best practices, it is recommended to use a separate subnet for each transit gateway VPC attachment in case of using NACLs with Transit Gateways. We keep the inbound and outbound NACL that is associated with the transit gateway subnets open, and will apply NACLs with filters to your workload subnets.

#### Task 3.1.1: TGW Subnets & NACL configuration
188- Go to the VPC service page.
189- On the left navigation pane, under  Security, choose Network ACLs.
190- At the upper-right corner of the Network ACLs page, choose Create network ACL.
191- On the Create network ACL page, under Network ACL settings, configure the following:
- Name: nacl-tgw-vpca
- VPC: VPC A 
- Tags: Accept proposed Tags
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ptqovjj7rgx6bx5uzi4g.png)
192- Choose **Create network ACL** .
193- Repeat these steps to create network ACLs:
- nacl-tgw-vpcb for VPC B.
- nacl-tgw-vpcc for VPC C.

194- On the Network ACLs page, select **nacl-tgw-vpca**.
195- Choose the **Subnet associations** tab.
196- Choose **Edit subnet associations** .
197- From the Edit subnet associations page, select the following:
- VPC A - AZ1 TGW
- VPC A - AZ2 TGW
198- Choose **Save changes** .
199- Repeat these steps for VPC B and VPC C by choosing corresponding subnets with TGW in Subnet name.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iu8jksu8zok4hdf5sc26.png)

200- On the Network ACLs page, select _nacl-tgw-vpca_.
201- On the _nacl-tgw-vpca_ Network ACLs page, at the bottom of the page, choose the Inbound rules tab.
Notice there is only one inbound rule that denies all incoming traffic.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/20hsb9ny5oah3tmzhd12.png)
202- At the right side of the **Inbound rules** section, choose **Edit inbound rules** .
203- On the **Edit inbound rules** page, choose **Add new rule** and configure the following:
- Rule number: 100
- Type: All traffic 
- Source: 0.0.0.0/0
- Allow/Deny: Allow 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sfo017xkgfm2gqls6rza.png)
204- Choose **Save changes** .
205- On the **nacl-tgw-vpca** Network ACLs page, at the bottom of the page, choose the **Outbound rules** tab.
Notice there is only one outbound rule that denies all incoming traffic.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rm94i3l9asjw0l5y3ett.png)

206- At the right side of the **Outbound rules** section, choose **Edit outbound rules** .
207- On the Edit outbound rules page, choose Add new rule and configure the following:
Rule number: 100
Type: All traffic 
Destination: 0.0.0.0/0
Allow/Deny: Allow 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ck2pcayjdy5abyqwd7sm.png)

208- Choose **Save changes** .
209- Repeat the above steps to add the same Inbound and Outbound Rules in **nacl-tgw-vpcb** and **nacl-tgw-vpcc** Network ACLs.
210- Now we’re ready to proceed to the next section and configure NACLs for EC2 instances to allow the ICMP traffic, TGW NACLs that allow everything will not introduce any blocking for us.
####Task 3.1.2: NACL configuration for EC2 subnets in AZ1
211- On the left navigation pane, under  Security, choose Network ACLs.
212- In the Network ACLs page, in the Filter network ACLs search bar, search for  VPC A .
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kv13ughkw0m4txpjskny.png)
213- Select the ACL marked as the Default with a value of Yes.
Check the default inbound rules in the Network ACL can be seen above. All traffic gets evaluated for Protocol, Port, and Source IP match. In this default Network ACL, all traffic is allowed into the VPC A-AZ1 Subnet by the first rule. The second rule which is a DENY ALL is not evaluated.
We will now modify the first rule (100) to allow only ICMP traffic from VPC B’s CIDR.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gp83jwajo2ougmz0xm6i.png)

214- On the Network ACLs page, at the bottom of the page, choose the **Inbound rules** tab.
215- At the right side of the Inbound rules section, choose **Edit inbound rules**.
216- On the Edit inbound rules page, modify rule number 100 and configure the following:
- Type: All ICMP - IPv4 
- Source: 10.1.0.0/16
- Allow/Deny: Allow 
217- Choose **Save changes** .
We have now completed modifying the Network ACL of VPC A - AZ1 Subnet to allow ONLY ICMP traffic from VPC B’s CIDR and all other traffic will be denied by the catch-all DENY rule. Let us now test this from VPC B - AZ1 Subnet for ALLOW, and VPC C - AZ1 Subnet for DENY.
 Note that You have not modified outbound rules, and the default outbound rule allows ALL traffic to flow out of the subnet.

### TASK 3.2: TESTING CONNECTIVITY THROUGH NACLS FROM VPC B TO VPC A
Here, you will login to EC2 VPC B - AZ1 using EC2 instance connect, and verify reachability to EC2 VPC A - AZ1 over ICMP (ping).
218- Go to the EC2 service page.
219- On the left navigation pane, choose Instances.
220- Select the  **EC2 VPC B - AZ1** instance.
221- Choose **Connect** from the navigation bar.
222- With the Session Manager tab selected, choose **Connect** .
A terminal session should open in a new browser tab.
223- From the EC2 VPC B - AZ1 instance in VPC B, try pinging the private IP addresses of the EC2 VPC A - AZ1 instance in VPC A.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1rvqp3a2jow8ayyhlvn8.png)
The ICMP traffic should flow through and show as being successfully returned. Enter ‘CTRL + C’ to stop the ping.
You have now verified that the Network ACL on VPC A - AZ1 subnet is allowing ICMP traffic to flow in and out, from EC2 VPC B - AZ1.

### TASK 3.3: TESTING CONNECTIVITY THROUGH NACLS FROM VPC C TO VPC A
Similarly, connect to EC2 VPC C - AZ1 from EC2 console, and ping EC2 VPC A - AZ1 as you did from VPC B above.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ptlvkc7qpravug1msg9j.png)
The ping command will freeze without progress because the Network ACL in VPC A - AZ1 subnet is DENYING all traffic from VPC C. Enter ‘CTRL + C’ to stop the ping see review the results. They should indicate that no replies were received.
 Task complete: You have successfully modified the default Network ACL in VPC A to allow ICMP traffic only from VPC B; the only other rule is a DENY ALL. You verified that ICMP traffic flows through from EC2 VPC B - AZ1 to EC2 VPC A - AZ1 and DID NOT flow through from EC2 VPC C - AZ1.

### TASK 3.4: MODIFYING SECURITY GROUP TO ALLOW ONLY ICMP TRAFFIC FROM VPC C TO VPC A

Security Groups are virtual, stateful firewalls attached to an instance or network interface. Both inbound and outbound rules can be defined to allow specific protocols, ports, and source/destination CIDR. A DENY is not possible with security groups.
With Security Groups, all rules are evaluated before a network packet is allowed or blocked, unlike Network ACLs where the rules are evaluated in order of rule number and once a rule matches subsequent rules are not evaluated.
In this section, you will modify the security group attached to EC2 VPC A - AZ1 to allow only ICMP traffic inbound from VPC C’s CIDR only. You will verify that EC2 VPC C - AZ1 can ping EC2 VPC A - AZ1, and EC2 VPC B - AZ1 is not able to ping EC2 VPC A - AZ1.
 Prerequisite: Edit the Network ACL in VPC A - AZ1 subnet to revert the change to Rule 100, and set it to allow ALL TRAFFIC from all sources (0.0.0.0/0), because you want all traffic to flow past the Network ACL to the instance in VPC A to test the Security Group at the instance level.
224- Navigate to the browser tab with VPC service.
225- On the left navigation pane, under  Security, choose Network ACLs.
226- On the Network ACLs page, in the Filter network ACLs search bar, search for  VPC A.
227- On the Network ACLs page, at the bottom of the page, choose the **Inbound rules** tab.
228- At the right side of the **Inbound rules** section, choose **Edit inbound rules**.
229- On the Edit inbound rules page, modify rule number 100 and configure the following:
- Type: All traffic 
- Source: 0.0.0.0/0
- Allow/Deny: Allow 

230- Choose **Save changes** .
231- Navigate to the browser tab with EC2 Instances.
232- On the left navigation pane, choose Instances and select  EC2 VPC A - AZ1.
233- Navigate to the Security tab below and choose the Security Group with ID starting with sg- (VPC A EC2 Security Group) in the lower pane to view and edit its rules.
234- On the VPC A EC2 Security Group Security Group page, at the bottom of the page, choose the Inbound rules tab.
235- At the right side of the **Inbound rules** section, choose **Edit inbound rules** .

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6ugraczdkyf13kjltzfy.png)


236- On the Edit inbound rules page, in the rule that is currently allowing All ICMP from 10.0.0.0/8 source, change it to allow only from VPC C’s CIDR:
- Type: All ICMP-IPv4 
- Source type: Custom 
- Source: 10.2.0.0/16

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9i6rc4slfghk1xsdpd2o.png)

237- Choose **Save rules** .

## TASK 3.5: TESTING CONNECTIVITY FROM VPC B TO VPC A THROUGH SECURITY GROUPS
Now you have modified the Security Group on EC2 VPC A - AZ1 to allow ICMP traffic (ping traffic) only from instances in VPC C. You will now verify that you are NOT able to ping this instance from EC2 VPC B - AZ1, and you are ABLE to ping from EC2 VPC C - AZ1.
238- On the left navigation pane, choose Instances.
239- Select the  EC2 VPC B - AZ1 instance.
240- Choose Connect from the navigation bar.
241- With the Session Manager tab selected, choose **Connect**.
 A terminal session should open in a new browser tab.
242- From the EC2 VPC B - AZ1 ping to the private IP of the instance that is in VPC A.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5r8lvcrcdt1ztir20ypn.png)
It will not be able to reach out to the EC2 in VPC A.

## TASK 3.6: TESTING CONNECTIVITY FROM VPC C TO VPC A THROUGH SECURITY GROUPS
Similarly connect to EC2 VPC C - AZ1 and try to ping EC2 VPC A - AZ1.
243- On the left navigation pane, choose Instances.
244- Select the  EC2 VPC C - AZ1 instance.
245- Choose Connect from the navigation bar.
246- With the Session Manager tab selected, choose **Connect**.
A terminal session should open in a new browser tab.
247- From the EC2 VPC C - AZ1 instance in VPC C, try pinging the private IP addresses of EC2 VPC A - AZ1 instance in VPC A.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kxjgdjxd2oolo0a5wshv.png)

The ping will succeed and traffic will flow through. This is because the SG on EC2 VPC A - AZ1 is allowing ICMP traffic from VPC C’s CIDR range.
 **Task complete**: You have successfully modified the Security Group on EC2 VPC A - AZ1 to allow only ICMP traffic from VPC C. You tested and verified that you cannot ping this instance from VPC B, but You can ping it from VPC C confirming the behavior of the Security Group.

**Conclusion**
 Congratulations! You now have successfully:

- Demonstrate intra versus inter-VPC routing.
- Select the appropriate connectivity options for an environment.
- Capture network traffic information (metadata) with VPC flow logs.
- Configure monitoring for networking statistics and metrics.
- Filter network traffic with Network Access Lists (NACLs), and Security Groups (SG).

**End lab**
1- Delete the EC2s
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ldu5b32gziskhrxy32qx.png)

2- Go to the VPC service page to delete the TGW and VPCs

3- Select **Transit gateway attachments** under **Transit gateways**
4- You need to delete the attachments one by one
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r5cjwcw51kbch309q53v.png)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d5cuqs1cak7mea78gq4p.png)
5- Select **Transit gateways** under **Transit gateways**.
6- Select TGW and from Actions select **Delete transit gateway**.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oremkemt8oo6o22dd8vu.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u5hjkxy4f55iael9tgsv.png)


7- Select **Your VPCs** under **Virtual private cloud**.
6- Select **VPC A**, then from Actions select delete VPC

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xmk8barmobdq7joj7ttu.png)
7- In **Delete VPC** page, Enter _delete_ to confirm the delete then Select **Delete**.
8- Make the same with VPC B, and VPC C to delete them.


**Additional Resources**
For more information about the topics covered in this lab, see:
- [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html).
- [Amazon VPC Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
- [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html).
- [Route tables](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html#tgw-route-tables-overview).
- [Create a static route](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html#tgw-create-static-route)
- [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
- [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
- [Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html).
- [Amazon CloudWatch Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
- [Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
- [AWS Network Access Control List](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html).
- [Amazon Security Group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html).