TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

TLDR is the free daily email with summaries of the most interesting stories in startups, tech, and programming. The stuff worth knowing, minus the doomscrolling.

Issues are curated by ex-Google and Anthropic engineers and land in your inbox before your morning coffee. A 5-minute read, and you walk into the day already knowing what your team is still catching up on.

Tech is just the start. We also cover AI, marketing, dev, and more. Pick the briefs that match your work.

Free, daily, and read by 7M+ subscribers. Subscribe and let the experts do the digging for the tech news that matters.

Subscribe for Free

Powered by: Jobsurface.com

Browse 580 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Every AWS account starts with a VPC (Virtual Private Cloud) which is a logically isolated section of the AWS network where you launch your resources. By default, VPCs cannot talk to each other. The instances in VPC-A have no route to the instances in VPC-B. They are completely isolated at the network layer.

This isolation is intentional and useful. It means that by default, a misconfigured security group in one VPC cannot expose resources in another. But most real architectures eventually need VPCs to communicate. A shared services VPC might host DNS, logging, or a bastion host that every other VPC needs to reach. A microservices architecture might spread workloads across multiple VPCs for compliance or billing boundaries. The question is how to connect them without punching unnecessary holes through the internet.

AWS gives you two mechanisms to solve this: VPC Peering and Transit Gateway. They solve the same core problem but at very different scales, and choosing the wrong one at the wrong stage creates operational work that is hard to undo.

A VPC Peering connection is a one-to-one private network link between two VPCs. Traffic between peered VPCs travels entirely within the AWS backbone and never touches the public internet. Latency is low and there is no bandwidth bottleneck from a gateway appliance in the middle. AWS does not charge per-hour for the peering connection itself, you only pay standard data transfer rates for traffic that crosses Availability Zones or regions.

Setting up peering between VPC-A and VPC-B requires creating the peering connection, accepting it from the other side, and then adding routes in both VPCs' route tables pointing the other VPC's CIDR block at the peering connection. Security groups on the target instances also need to allow traffic from the peering source CIDR. Once that is done, instances in VPC-A can reach instances in VPC-B using their private IP addresses as if they were on the same network.

The non transitive nature of VPC peering is the most important property to understand. If VPC-A peers with VPC-B and VPC-B peers with VPC-C, VPC-A cannot reach VPC-C through VPC-B. Each pair of VPCs that needs to communicate requires its own dedicated peering connection. With three VPCs you need three connections. With ten VPCs you need up to 45. With twenty VPCs that number reaches 190. Every new connection means new route table entries on multiple VPCs, new security group rules, and a new connection to monitor. The operational overhead compounds quickly.

The mesh problem becomes visible before you might expect it to. Even at a modest scale of five or six VPCs, maintaining a full mesh of peering connections requires careful coordination. When CIDR blocks overlap, which is a common problem in organisations that did not plan their IP addressing upfront, peering is not even possible between those VPCs. You also cannot peer VPCs with overlapping CIDR ranges, so organisations that reused the same address space across accounts and environments run into this wall regularly.

Beyond the VPC-to-VPC problem, there is the on premises connectivity problem. If your on-premises network needs to reach multiple VPCs via a VPN or AWS Direct Connect, the traditional approach requires a separate VPN termination or Virtual Private Gateway on each VPC. A Customer Gateway on-premises connecting to four VPCs needs four separate VPN tunnels. A Direct Connect Gateway can help, but it still requires individual associations with each VPC. The management surface grows linearly with every VPC added.

This is the architecture that Transit Gateway was built to replace. The complexity in this diagram is not hypothetical, it is what production AWS environments look like when they grow organically without a hub-and-spoke network model in place from the start.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)