The Secret Life of AWS: Cross-Network Communication (VPC Peering)
.jpeg)
Connecting isolated environments without touching the public internet.
Part 43 of The Secret Life of AWS
Timothy was staring at a connection timeout error.
Following Margaret's advice from the previous week, he had fully embraced network isolation. When he was tasked with building a new "Inventory" microservice, he created a brand new Virtual Private Cloud (VPC) for it, completely separate from the "Checkout" VPC.
Now, the Inventory service needed to query the Checkout database.
"They are in two different VPCs," Timothy explained to Margaret. "I can't connect them. I was thinking of attaching a NAT Gateway to the Inventory VPC and routing the traffic over the public internet to the Checkout VPC's public endpoint... but we just made the database private."
"Exactly," Margaret said. "We did not isolate the database just to open a back door over the public internet. Traffic between your internal backend systems should never leave the AWS global network."
"But VPCs are isolated by default," Timothy pointed out. "They literally cannot see each other."
"That is where we create a direct network link," Margaret said. "We need VPC Peering."
The Connection (The Handshake)
Margaret opened the VPC console.
"Before we even start," she noted, "we must ensure the two VPCs have different CIDR ranges. If their IP addresses overlap, they cannot be routed, and peering is impossible. Fortunately, you used 10.0.0.0/16 for Checkout and 10.1.0.0/16 for Inventory."
"A VPC Peering connection is a networking connection between two VPCs that enables you to route traffic between them using those private IP addresses," she explained. "Instances in either VPC can communicate with each other as if they are within the same network."
She initiated a Peering Request from the Inventory VPC (the Requester) to the Checkout VPC (the Accepter).
"Because a VPC is a hard security boundary, this requires a two-step handshake," Margaret noted. "You request the connection, and the owner of the target VPC must explicitly accept it. Even if both VPCs are in the same account, you must accept the request."
She clicked Accept Request. The connection status changed to Active.
"So they can talk now?" Timothy asked.
"Not yet," Margaret replied. "We have laid the cable between the two buildings, but we haven't told anyone how to use it."
The Route Tables (The Directions)
"To make the connection work, we have to update the Route Tables in both VPCs," Margaret said.
She opened the Route Table for the private subnet in the Inventory VPC. She added a new route with the destination set to 10.0.0.0/16 (the CIDR block of the Checkout VPC) and the target set to the ID of the new Peering Connection, pcx-0123456789abcdef0.
"This rule tells the Inventory service: 'If you are looking for an IP address in the 10.0.x.x range, send that traffic across the Peering Connection'."
"But routing is a two-way street," she reminded him. "If the database receives the request, it needs to know how to send the data back."
She opened the Route Table for the Checkout VPC and created the inverse route, pointing traffic destined for the Inventory VPC's CIDR block (10.1.0.0/16) back across the same pcx- connection.
The Security Groups (The Bouncers)
Timothy ran his test script again. It timed out.
"The route is there," Timothy frowned. "Why is it dropping?"
"Because we are practicing Defense in Depth," Margaret smiled. "The network route exists, but the Security Group on the database is still doing its job."
She opened the database's Security Group.
"Right now, this database only accepts traffic from the Checkout Application Security Group. It has no idea who the Inventory service is."
She added a new Inbound Rule for PostgreSQL on port 5432, setting the source to 10.1.0.0/16 (the CIDR block of the peered Inventory VPC).
"If both VPCs are in the same AWS Region," Margaret added, "we could even use Security Group Referencing across the peer, just like we did locally. If they were in different regions, we would just stick to the CIDR block. But for now, allowing the specific private IP range of the peered VPC works perfectly."
Timothy ran the script one last time.
Connection Successful. 200 OK.
"The traffic flowed from the Inventory subnet, across the peering connection, to the database, and back," Timothy traced the path on the screen. "And it never touched the internet."
"Correct," Margaret said. "You have bridged the islands without lowering the drawbridges."
Timothy looked at the diagram. "This works great for two VPCs. But what if we launch ten microservices? What if I have five VPCs that all need to talk to each other? That's a lot of peering connections."
Margaret smiled. "That is when we need a Transit Gateway. But that is a lesson for another day."
Key Concepts
- VPC Peering: A networking connection between two VPCs that enables you to route traffic between them using private IP addresses. Traffic never traverses the public internet.
- Requester & Accepter: The dual-handshake security model of VPC Peering. One VPC initiates the request, and the target VPC must explicitly accept it.
- Route Tables: A set of rules that determine where network traffic from your subnet or gateway is directed. Peering requires updating Route Tables in both VPCs to enable bidirectional traffic.
- CIDR Block: Classless Inter-Domain Routing. A method for allocating IP addresses and IP routing. VPCs must have non-overlapping CIDR blocks to be peered.
- Cross-VPC Security Groups: Security Groups must be updated to allow traffic from the peered VPC (either by CIDR block or, if in the same region, by referencing the peered Security Group ID).
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment