Building a Private and Secure Multi-VPC Architecture For Departments

In Today’s Article:

• ??Client’s Key Challenges
• ??What is VPC Peering?
• ??Create User Requirements
• ??Architectural Design
• ??Implementation

??Step 1: Create VPCs and Subnets

??Step 2: Initiate and accept peering connection

??Step 3: Update route tables

??Step 4: Update security group

• ??Testing
• ??Results and Benefits
• ??Reflections & Lessons

Hi friends, welcome ??

Today, we’re diving into another exciting AWS concept—VPC Peering! I’ll walk you through my client’s challenges and explain why VPC Peering was an ideal solution. I’ll also discuss my implementation approach, expected outcomes and key lessons learned.?

??What is VPC Peering?

VPC peering is a networking strategy that connects 2 VPC, allowing them to communicate securely. Information exchanged between the 2 VPCs does not traverse the public internet. Besides providing a safe and private connection, VPC peering also provides high-speed connection, increasing performance by reducing latency.??

Some use cases for VPC peering include:

• Enabling secure communication for a company’s multiple departments hosted in different VPCs.
• Giving teams access to shared resources without exposing them to the internet.?
• Allowing communication in hybrid architectures by providing connections between on-premises and cloud resources,?

??Client’s Key Challenges

Before I got involved, my client had already set up VPCs for 3 of their departments: Finance, Marketing and Development. Although isolating departments improved security and performance, it forced the Marketing and Development teams to request finance reports through support tickets, slowing down their work.?

This is what my client expressed:?

…however, all departments depend on getting reports from Finance. Due to the isolated VPCs, the team members in Marketing and Development need to raise tickets to gain access to Finance reports, which reduces our productivity. Any ideas on how we can improve this?... No. We currently aren’t using different accounts.

??Create User Requirements

From what my client aired, I noted two key things:

• The Finance VPC holds shared resources to be accessed by the other 2 departments.
• The VPCs are all in the same account.

Based on these insights, I defined the following user requirements:

• Allow seamless exchange of information between the Finance, Development and Marketing teams.
• Minimize operational overhead by reducing the need for manual ticket-based access requests.
• Maintain VPC isolation by ensuring each department remains in its own VPC.
• Provide Marketing and Development teams with access to finance reports while maintaining security.

From the above user requirements, it became clear to me that the solution my client needed was VPC Peering.

??Architectural Design

I made the following architectural design to showcase a VPC peering connection for my client.?

• Requester: these are VPCs that initiate a peering connection request. In this case they are MarketingVPC and DeveloperVPC
• Accepter: this is a VPC that accepts the peering connection request. In this case, it is the FinanceVPC.

??Implementation

Before establishing a peering connection, I conducted a ping test that confirmed there was no connectivity between the MarketingVPC and FinanceVPC because no data was successfully transmitted. This was also the case for the communication between the DeveloperVPC and FinanceVPC.?

By the end of the implementation, the terminal should show us a different outcome.?

??Step 1: Create VPCs and Subnets

As mentioned earlier, my client had already set up VPCs for each department and put resources in each of their subnets. With that already done, I dove right into creating peering connections.

??Step 2: Initiate and accept peering connection

From the VPC console, I selected the ‘’Peering Connections’’ option from the left navigation pane. Using the configuration workflow, I specified the Requester and Accepter VPCs. In this case, the Accepter was the FinanceVPC while the Requesters were the MarketingVPC and the DeveloperVPC.

Since the Accepter VPC is in the same account as the Requester VPCs, I only needed to accept the peering request in the success page that came after initiating a peering request. Had they been in different accounts, I would have logged into the Accepter account, gone to the VPC console, and clicked Peering Connections in the left navigation pane. From the window that opens, I would locate pending requests and accept the request that was just made. At the end of this step, I had 2 peering connections, namely—Marketing<>Finance and Developer<>Finance.

?Requirements met:?

• Allow seamless exchange of information between the Finance, Development and Marketing teams.
• Maintain VPC isolation by ensuring each department remains in its own VPC.

??Step 3: Update route tables

Successfully creating a peering connection through the peering configuration workflow is not enough. Additionally, route tables must be updated in both peered VPCs to define valid traffic paths.

Still on the VPC console, I used the details tab of a selected VPC and clicked on its subnet ID. From there I located its route table and added new routes. For example, for the MarketingVPC’s route table, I added a new route of a peering connection type whose destination was the private IP address of the FinanceVPC resource. (I did the same for the DeveloperVPC route table).

?

Likewise, in the FinanceVPC route table, I added a new route of a peering connection type whose destination was the private IP address of the MarketingVPC resource. (I also added another route pointing to the DeveloperVPC resource).

?Requirement met: Allow seamless exchange of information between the Finance, Development and Marketing teams.

??Step 4: Update security group

Finally, I updated the security group of the FinanceVPC to allow traffic from both the Marketing and Developer VPCs using the custom ICMP IPv4 protocol for diagnostic purposes through the "ping" command. An example of this configuration is shown below.?

?Requirement met: provide Marketing and Development teams with access to finance reports while maintaining security.

??Testing

To check whether my implementation worked, I connected to the Requester VPCs using Session Manager. In the terminal, I typed the command ‘ping 172.31.0.81’ where 172.31.0.81 is the private IP address of the resource in the FinanceVPC.?

This time, the results confirmed successful data transmission between the two VPCs, indicating that the peering connection was established successfully.

?Results and Benefits

Using this design and implementation could give my client the following benefits:

• Reduce access time of finance reports from hours or days to near-instant access.
• Increased productivity by at least 50% because Developer and Marketing teams can access finance reports instantly.?
• Lower operational costs by eliminating manual ticket handling.?
• Seamless and secure inter-departmental collaboration.?

??Reflections & Lessons

Doing this project taught me this about implementing cloud solutions for inter-departmental connectivity:

1. Planning is crucial: before setting up a peering connection, understanding the existing architecture and identifying the dependencies is essential. This prevents misconfigurations.
2. Updating security groups is non-negotiable: simply creating a peering connection is not enough. One must also update the route tables and security groups. Without doing so, the departments would still be unable to connect to the FinanceVPC. .?
3. Considerations for scaling: VPC peering is effective for small-scale multi-VPC environments where only 2 VPC require connectivity at a time. However, for larger organizations with multiple VPCs, a transit gateway provides a more scalable and efficient long-term solution.??

In conclusion, by leveraging VPC peering, I established a secure and private inter-departmental connectivity for my client’s multi-VPC environment. Doing so eliminated the need for manual requests, enhanced productivity and streamlined operations all while maintaining VPC isolation between the Marketing, Development and Finance teams. While VPC peering is a good solution for direct two-way communication, AWS Transit Gateway is better for larger-scale environments.

Have you used VPC peering in your organization before? Let me know in the comments

Well, friends, until next time—toodooloos! ??