# Peering and testing  Connections of two separated VPCS on AWS using Terraform

# **Peering and testing Connections of two separated VPCS on AWS using Terraform**

## 🚀 Overview:

VPC peering across two AWS regions is a network connection that allows Virtual Private Clouds (VPCs) in different geographic locations to communicate securely and directly with each other, enabling seamless data transfer and resource access while maintaining the isolation and security of each VPC. This inter-region connectivity facilitates distributed application architectures, disaster recovery setups, and data replication scenarios, enhancing the versatility and global reach of AWS infrastructure for businesses and organizations. This project utilizes Terraform, an Infrastructure as Code (IaC) tool, to provision and manage the infrastructure components, enabling automation, repeatability, and scalability. The primary objective of this project is to design and deploy two virtual Private Cloud on AWS in two separated region “us-west-2” and “us-east-1” then we will create a VPC peering to link both VPCs and finally launch two EC2 instances in both private subnets then test connectivity between them.

## 🔧 Problem Statement

Terraform is an IaC software tool that provides a consistent command line interface (CLI) workflow to manage hundreds of cloud services. Terraform codifies cloud APIs into declarative configuration files. In this specific case you need to create VPC peering across two AWS regions. It is a network connection that allows Virtual Private Clouds (VPCs) in different geographic locations to communicate securely and directly with each other, enabling seamless data transfer and resource access while maintaining the isolation and security of each VPC. This inter-region connectivity facilitates distributed application architectures, disaster recovery setups, and data replication scenarios, enhancing the versatility and global reach of AWS infrastructure for businesses and organizations. Terraform will use his deployment to provide all AWS needed elements avoiding us to use the console and it will automate the setup, ensuring consistency and reducing human error.

## 💽 Techonology Stack

The architecture consists of the following services tiers:

* **VPC**: AWS VPC
    
* **Subnets**: AWS Subnets
    
* **Route table**: AWS route table
    
* **NACL**: AWS NACL
    
* **Internet Gateway**: AWS IGW
    
* **NatGateway** : AWS NATGATEWAY
    
* **SSM Role:** AWS IAM
    
* **EC2 Instance**: AWS EC2
    
* **Peering Connection:** AWS VPC Peering
    

## 📌 Architecture Diagram

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735460267277/be084e67-e85e-40f6-89ba-fe80c599c2d6.png align="center")

## 🌟 Project Requirements

Before you get started, make sure you have the following prerequisites in place:

* [**Terraform**](https://www.terraform.io/) installed on your local machine.
    
* AWS IAM credentials configured in your text editor. In this case we will use VSCODE.
    
* Git installed on your local machine and Github account set up [**Github**](https://www.github.com/)
    
* Git for cloning the repository.
    
* AWS VPC services
    

You must know the goal of the peering connection:

To achieve VPC peering across regions, first, create the necessary VPCs in each region, ensuring they have unique CIDR blocks. Next, create VPC peering connections in both regions, accepting the peer requests. Update the route tables in each VPC to include routes for the peer VPC's CIDR block, pointing to the peering connection. Finally, configure security groups and network ACLs to allow the required traffic between the peered VPCs. This setup enables seamless and secure communication between resources in the US East and US west regions while maintaining network isolation. We will skip the completion of these manual steps and we will use Terraform where cade with all those steps were wrote and now will just be run and deploy.

## 📋 Table of Contents

I - **Terraform Configuration files**

[**Step 1: Providers Configuration**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Provider-configuration)

[**Step 2: Variables Configuration**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-variables-configuration)

[**Step 3: VPCs Configuration**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-VPC-configuration)

[**Step 4: Main Configuration**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Output-configuration)

[**Step 5: Output Configuration**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Output-configuration)

II - **Instructions of Deployment**

[**Step 1: Clone Repository**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Clone-Repository)

[**Step 2: Initialize Folder**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Initialize-Folder)

[**Step 3: Format Files**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Format-Files)

[**Step 4: Validate Files**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Validate-Files)

[**Step 5: Plan**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Plan)

[**Step 6: Apply**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Apply)

[**Step 7: Review of Resources**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Review-Of-Resources)

[**Step 8: Test**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Destroy)**ing Connectivity**

[**Step 9: Destroy**](http://127.0.0.1:8000/vpc-foundation-terraform-on-aws/#-Destroy)

## ✨Terraform Configuration files

You need to write different files generating resources

##### Step 1: ***Provider Configuration***

Here we declare our cloud provider and we specify the regions where we will be launching resources. The regions us-east-1 and us-west-2 are the two to be precise.

* [providers Configuration](https://github.com/Joebaho/VPC-PEERING/blob/main/providers.tf)
    

##### Step 2: ***Variables Configuration***

This is where we declare all variables and their value. It includes

**Variables**: List of element that can vary or change. They can be reuse values throughout our code without repeating ourselves and help make the code dynamic. We can de declare stuff like CIDR blocks, ports numbers, key name, instance type, count VPCs and subnets name.

**Value:** Declare different default value of each variables

We have

* [**variables Configuration**](https://github.com/Joebaho/VPC-PEERING/blob/main/variables.tf)
    
* [**value Configuration**](https://github.com/Joebaho/VPC-PEERING/blob/main/terraform.tfvars)
    

##### Step 3: ***VPCs Configuration***

This is where you create the basement, foundation and networking where all the resources will be launch. It includes VPC, Subnets, IGW, NatGateway, EIP, NCAL and Route tables

* [vpc-east](https://github.com/Joebaho/VPC-PEERING/blob/main/vpc_east.tf)
    
* [vpc-west](https://github.com/Joebaho/VPC-PEERING/blob/main/vpc_west.tf)
    

We have here

* **VPC**: Virtual Private Cloud the main and private environment where all resources will be launch
    
* **Subnets**: is a segmented portion of a virtual private cloud (VPC) that allows you to partition your network resources. Subnets are used to organize and manage your cloud resources more effectively by providing isolation and control over network traffic. We will be having two public and private in each VPCs
    
* **Internet Gateway**: it plays a crucial role in enabling internet connectivity for resources within a VPC, allowing instances to access services, applications, and data hosted on the public internet while providing scalability, redundancy, and security features. One for the each will allow access to internet for each VPCs.
    
* **Route Tables**: is a fundamental networking component that controls the routing of network traffic within a Virtual Private Cloud (VPC). Route tables define the rules for directing traffic from one subnet to another or to external networks, such as the internet or on-premises networks. As we need to are peering tow VPCs we will need to route the traffic from local to internet and the private link between the two close environment.
    
* **NCAL**: Network Access Control Lists (NACLs) are a security layer in AWS that act as a firewall for controlling traffic in and out of one or more subnets within a Virtual Private Cloud (VPC).
    
* **Security Groups**: a security group acts as a virtual firewall for controlling inbound and outbound traffic to AWS resources, such as EC2 instances, RDS databases, and other services within a Virtual Private Cloud (VPC). Security groups allow you to define rules that specify the type of traffic allowed or denied based on protocols, ports, and IP addresses.
    

##### Step 4: ***Main Configuration***

This is where we declare the file for the peering which is the main file. The main file is the one containing the goal of the project which is the peering of both VPCs. This is where the link and the attachment and connectivity of the VPCs is done.

. [main](https://github.com/Joebaho/VPC-PEERING/blob/main/main.tf)

The SSM file will be the role because we will connect to the instance using the private IP and as we will connect to the instance securely. The easier way will be by SSM connect

**.** [ssm-role](https://github.com/Joebaho/VPC-PEERING/blob/main/ssm-role.tf)

The both instances will bee launched in the private subnets of each VPCs. Here are the contains of each files that will launch the instances

. [ec2-east](https://github.com/Joebaho/VPC-PEERING/blob/main/ec2-east.tf)

. [ec2-west](https://github.com/Joebaho/VPC-PEERING/blob/main/ec2-west.tf)

##### Step 5: ***Output Configuration***

Know as Output Value : it is a convenient way to get useful information about your infrastructure printed on the CLI. It is showing the ARN, name or ID of a resource. In this case we are bringing out the both VPCs Id and both EC2 private IP. we gonna us those private IPs to test the connectivity

* [**Output Configuration**](https://github.com/Joebaho/VPC-PEERING/blob/main/outputs.tf)
    

## 💼 Instructions of Deployment

Follow these steps to deploy the architecture:

##### Step 1: ***Clone Repository:***

Clone the repository in your local machine using the command "git clone"

> ***git clone*** [https://github.com/Joebaho/VPC-PEERING](https://github.com/Joebaho/VPC-PEERING)

Step 2: ***Initialize Folder***

Initialize the folder containing configuration files that were clone to Terraform and apply the configuration by typing the following command

> ***terraform init***

You must see this image

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735528451950/cbfe81d7-5034-4f8e-afc8-74b792508202.png align="center")

##### Step 3: ***Format Files***

Apply any changes on files and Review the changes and confirm the good format with command:

> ***terraform fmt***

##### Step 4: ***Validate Files***

Ensure that every files are syntactically valid and ready to go with the command:

> ***terraform validate***

If everything is good you will have something like this

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735528480013/1fbc684b-108e-45db-868c-8f7e5a571d7b.png align="center")

##### Step 5: ***Plan***

Create an execution plan to provide the achievement of the desired state. It Check and confirm the numbers of resources that will be create. Use command:

> ***terraform plan***

The list of all resources in stage of creation will appear and you can see all properties(arguments and attributs) of each resources

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735528768226/269180d0-1759-499a-a7d9-c1ae3d886aa4.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735528778554/b7735ed6-9197-40e5-8559-f31df8723239.png align="center")

##### Step 6: ***Apply***

Bring all desired state resources on life. It Launch and create all resources listed in the configuration files. The command to perform the task is:

> ***terraform apply -auto-approve***

Now, the creation will start and you will be able to see which resources is on the way to be create and the time it taking to create.

At the end you will receive a prompt message showing all resources status: created, changed and the numbers of them.

Here are the outputs :

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735530865923/562e3607-f2b2-45da-baae-ddbe7a99b626.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735530874962/90291247-b5c4-421a-b1be-e551628b533f.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735530883276/be5022e0-deef-4aed-aeb6-353d81fa8850.png align="center")

##### Step 7: ***Review of resources***

Go back on the console and check all actual state resources one by one to see. You will have

* **VPC-EAST**
    

In the VPC option, we can see here the VPC, subnets( Public & Private) routes tables ( public & Private), Internet Gateway , Nat Gateway deployed in the us-east-1 region.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532161346/9f61a374-8a08-4953-84c3-7b4e5d8a8587.png align="center")

This shows route for the connectivity. Every communication from the CDIR block of the other VPC will have as target the VPC peering, for local one use the CDIR block of the requester VPC. If you want to access internet the Internet Gateway or the Nat Gateway will be the way to go.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532180799/67d00606-81f0-4907-bc67-efe47f8757a2.png align="center")

* **VPC\_WEST**
    

We can see here the VPC, subnets( Public & Private) routes tables ( public & Private), Internet Gateway , Nat Gateway deployed in the us-west-2 region.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532197717/76797599-94db-4703-9e07-a00e1535c1c3.png align="center")

This shows route for the connectivity. Every communication from the CDIR block of the other VPC will have as target the VPC peering, for local one use the CDIR block of the requester VPC. If you want to access internet the Internet Gateway or the Nat Gateway will be the way to go.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532207730/404462b1-7e34-44e5-82c5-c929d23d2ef3.png align="center")

* **Peering Connection east**
    

VPC peering connects two VPCs privately. The **requester VPC-west** initiates the connection, and the **accepter** VPC-east approves it. Both configure route tables for traffic flow between the VPCs. Manually this process needs acceptance confirmation of the accepter but in this case we placed that automatically in the code.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532645602/08e0b45d-623b-4b3c-b12a-01431346e69e.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532655502/35b686cb-e08f-4d00-924d-4f8924a51474.png align="center")

* **Peering Connection west**
    

VPC peering connects two VPCs privately. The **requester VPC-west** initiates the connection, and the **accepter** VPC-east approves it.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532669812/8ae9e4ef-eda4-44b9-a2d3-e484238b8e41.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532680872/ef2d45ca-8d27-437c-b73d-4c7e10bb27a4.png align="center")

* **EC2-WEST**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735532988714/1d1a3aad-6e21-4bd6-9981-143181d4a4fa.png align="center")

* **EC2-EAST**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735533359586/f574e794-9207-4d5e-837c-ab426f14dfc9.png align="center")

* **Server-west connect**
    

After selecting the instance, we may now look for a way to connect to it. As we added the SSM role we will have to select it and hit on “Connect” that will land us directly in the server.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735533012629/d7697e18-3ea7-430b-9827-11ea024cc38c.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735533095999/5ca9d121-e92b-4343-b68f-6bf0c0151ff3.png align="center")

* **Server-east connect**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735533402024/11fc985c-e108-4a05-ad68-a850976eabce.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735533413425/9d835b30-8635-4929-a002-bf471a6d662d.png align="center")

##### Step 8: ***Testing Connectivity***

The testing process will require to use the ping command to see if there is any response from the server. We need to grab the private IP of ec2-east server and test it the ec2-west server. As you can see on the both Screenshots each ping return a response this mean the connectivity is perfect and going through

* **Ping server west**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735533745148/d5c41e99-ce9c-42eb-b9a6-76f77fc99f44.png align="center")

* **Ping server east**
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735533755037/1023d171-637a-469f-9f30-f70e73ab3d8b.png align="center")

##### Step 9: ***Destroy***

Destroy the terraform managed infrastructure meaning all resources created will be shut down. This action can be done with the command "terraform destroy"

> ***terraform destroy -auto-approve***

At the end you will receive a prompt message showing all resources has been destroyed. The 53 resources created for the purpose of this project will all be destroyed and instances terminated. After typing the command the process of deleting resources will be launch and at the end there will be a confirmation message. See screenshot bellow:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1735534199247/17371a53-97ce-49e4-a0a0-b4c0c307ac27.png align="center")

## 🤝 Contributing

Your perspective is valuable! Whether you see potential for improvement or appreciate what's already here, your contributions are welcomed and appreciated. Thank you for considering joining us in making this project even better. Feel free to follow me for updates on this project and others, and to explore opportunities for collaboration. Together, we can create something amazing!

## 📄 License

This project is licensed under the JoebahoCloud License