Your VPC is now complete on the inside: subnets, internet gateways, and traffic rules. But networks rarely live in isolation: sometimes you need to connect your VPC with another VPC, or reach AWS services without going through the internet. That's what VPC Peering and endpoints are for. With this, we close the networking chapter.

Remember: a VPC is a fenced and isolated plot. Two different VPCs (even if they're in the same account) cannot communicate with each other by default. That's good for security, but sometimes you need them to talk.

Example: Your company has a VPC for the development team and another for the data team. The development team needs to access a database that lives in the data VPC. How do you connect them privately and securely, without sending traffic out to the internet?

VPC Peering creates a direct private connection between two VPCs, so their resources can communicate as if they were on the same network, using private IP addresses and without going through the internet.

Analogy: It's like opening a private door between two neighboring plots. The inhabitants of both can go from one to the other directly, without going out to the public street. Only those you authorize can go through that door.

Key features:

• Traffic goes through the AWS private network, never through the internet. It's secure and fast.
• Works between VPCs in the same account or in different accounts, and even between different regions.
• You have to add routes in the route tables of both VPCs so they know how to reach each other (remember the route tables from subchapter 6.4).

⚠️ Important limitation — not transitive: If VPC A is connected to B, and B to C, that does not mean A can talk to C. Peering only connects the two direct endpoints. For a complex topology with many VPCs, connecting all of them to each other (peering) becomes a mess. That's what Transit Gateway is for (a "central router" that connects many VPCs together), which is the large-scale solution you'll see in big architectures (we'll mention it in Chapter 30).

Here we solve a very common and often invisible problem. Imagine a server in a private subnet needs to access an S3 bucket.

The problem: S3 is a "public" AWS service (accessed via an internet URL). So, normally, that private server would have to go out to the internet through the NAT Gateway (subchapter 6.3) to reach S3. That means:

• Going through the NAT Gateway (which costs money per data).
• Traffic goes "to the internet" even though it's to another AWS service.

VPC Endpoints solve this. An endpoint creates a direct private connection between your VPC and an AWS service (like S3, DynamoDB, and many others), without going out to the internet and without going through the NAT Gateway.

Analogy: Instead of leaving your plot to the public street to go to a service that's "just around the corner," you open a direct private tunnel to that service. Safer, faster, and cheaper.

Advantages of endpoints:

• More secure: traffic never touches the internet.
• Cheaper: you avoid NAT Gateway costs for talking to AWS services.
• Better performance: direct route through AWS's internal network.

Very profitable practical tip: If you have servers in private subnets that access S3 or DynamoDB a lot, create a Gateway Endpoint (it's free) and you'll save the NAT Gateway costs for that traffic. It's one of the easiest and most effective cost optimizations out there.

To give you the full map, these are the ways to connect your VPC with the private outside world (no need to master them now, just know they exist):

The last two are the basis of the hybrid architectures we saw in Chapter 1: that's how the cloud and on-premise are connected.

• VPCs are isolated by default; for two to communicate you need VPC Peering (a "private door" between them).
• Peering is not transitive (A-B and B-C does not imply A-C); for many VPCs, Transit Gateway is used.
• VPC Endpoints connect your VPC with AWS services (like S3) privately, without going out to the internet or through the NAT Gateway: safer, faster, and cheaper.
• Gateway Endpoints (S3 and DynamoDB) are free: use them to save NAT costs.
• To connect with your on-premise datacenter: VPN (over the internet) or Direct Connect (dedicated line).

With this, you close Chapter 6 and now understand networking in AWS. In Chapter 7 we'll see who can do what in your account: identity and access with IAM, the pillar of security in AWS.