AWS VPC Networking:Choosing Between VPC Peering and Transit Gateway

Haroon Khan — Wed, 07 Oct 2026 17:39:40 +0000

As your cloud architecture scales, keeping all your applications inside a single Virtual Private Cloud (VPC) quickly becomes impractical. Most teams eventually split workloads—separating production environments, testing staging servers, and isolating shared microservices into their own distinct VPCs.

Once you have multiple isolated VPCs, they inevitably need a secure way to exchange data. AWS gives us two primary networking constructs to bridge these gaps: VPC Peering and VPC Transit Gateway. Let's examine how each option operates, how they handle scaling, and where they fit best.

VPC Peering and VPC Transit Gateway.

Let's examine how each option operates, how they handle scaling, and where they fit best.Direct Connections with VPC PeeringWe use VPC Peering when our goal is to link two VPCs directly through the internal AWS backbone. Because data stays off the public internet, communication remains fast, encrypted, and private.For small setups, VPC Peering is an amazing choice because it is straightforward to set up, free of extra hourly charges, and lacks a single point of failure. However, a major scaling hurdle appears as your network grows. If you only need to link two or three VPCs, peering works effortlessly. But if the number of VPCs increases, managing the connections becomes overwhelming.

For example, if VPC A is connected to VPC B, and VPC B is connected to VPC C, VPC A still cannot communicate with VPC C through VPC B. A separate peering connection between VPC A and VPC C is required.

This works well with a few VPCs, but as the number of VPCs grows, we need more peering connections and routes. This makes the network harder to manage.

Centralizing Traffic with VPC Transit Gateway

To completely overcome the massive route-table overhead and scaling bottlenecks of VPC Peering, AWS provides VPC Transit Gateway.Rather than wiring every single VPC directly to every other VPC, Transit Gateway acts as a central cloud router using a hub-and-spoke architecture. Instead of multiple point-to-point links, every VPC only needs a single attachment to the Transit Gateway hub.The core power of Transit Gateway lies in its centralized routing control. It dynamically handles traffic forwarding across all attached spokes using unified routing rules. This drastically reduces connection counts and cleans up route table management, replacing a chaotic network web with a streamlined, enterprise-ready topology.

Deployment Scenarios:

When to Use Which?Deciding between these two networking models comes down entirely to the scale and future growth of your infrastructure:

VPC Peering fits best in small, simple environments with minimal networking requirements. If you only have two or three VPCs that need dedicated point-to-point communication (such as an app tier talking directly to a database tier), Peering is lightweight, cost-efficient, and easy to maintain.
VPC Transit Gateway is engineered for large-scale enterprise multi-VPC architectures. If your organization manages dozens of VPCs, requires seamless hybrid integration with on-premises data centers via VPN or Direct Connect, and demands centralized traffic control, Transit Gateway is the ideal solution to keep your network manageable.

Summary

Both networking approaches have their rightful place in AWS. Understanding how they handle scale prevents you from getting trapped in an unmanageable routing maze later on.Kick off with VPC Peering if your infrastructure is small and straightforward, but pivot to a Transit Gateway early if your multi-VPC environment is bound to expand rapidly!

How I built and secured my first AWS static website using S3, CloudFront, and ACM

Haroon Khan — Thu, 17 Sep 2026 07:20:25 +0000

Three days ago, AWS was completely new territory for me. As a cybersecurity student, I knew I needed hands-on cloud infrastructure experience, but starting from absolute zero is always a bit daunting. Fast forward 72 hours, and I have successfully deployed my first static website on my own domain, haroonkhan.online.

More importantly, I didn't just host it—I secured it.

Here is how I bypassed the insecure beginner shortcuts and built a locked-down architecture in my first three days.

The Problem with Default Tutorials
If you search for "how to host a static website on S3," the vast majority of guides tell you to upload your files, uncheck "Block all public access," and call it a day.

Coming at this with a security-first mindset, leaving a storage bucket entirely exposed to the public internet was an immediate red flag. I wanted to build this correctly, mirroring professional enterprise architectures rather than settling for a quick, vulnerable fix.

Building a Secure Pipeline
Instead of relying on public S3 endpoints, I designed a three-tier delivery method to protect haroonkhan.online:

The Vault (Amazon S3): My actual HTML, CSS, and JS files live here. The bucket is strictly private, with all public access permanently blocked.

The Shield (Amazon CloudFront): This acts as a global Content Delivery Network (CDN). It caches the content for fast global delivery while enforcing strict HTTPS encryption so all transit is secure.

The Map (Route 53): This handles the DNS routing, ensuring anyone typing my domain name is seamlessly directed to the CloudFront distribution.

The Secret Sauce: Origin Access Control (OAC)
The most challenging—and rewarding—part of this build was figuring out how to bridge a locked-down S3 bucket with the public internet. The modern solution is Origin Access Control (OAC).

By writing a highly specific S3 Bucket Policy, I explicitly denied all external access except for my designated CloudFront distribution. If a malicious actor tries to hit the raw S3 URL directly, they hit a brick wall. The only way to view the site is through the secure, encrypted CDN pathway.