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.
PerfectScale — just launched the ultimate Kubernetes Troubleshooting Guide!
Real world examples. Clear explanations. Battle-tested knowledge.
Pure practical insights for DevOps practitioners and tech leaders.
👀 Remote Jobs
Sigma Prime is hiring a DevOps Engineer
Remote Location: Worldwide
Anagram is hiring a Site Reliability Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
Looking to promote your company, product, service, or event to 56,000+ Cloud Native Professionals? Let's work together. Advertise With Us
🧠 DEEP DIVE USE CASE
How to Connect AWS VPCs for Shared Services and Internal Access
In AWS, VPC Peering is a networking connection that lets two VPCs communicate using private IP addresses. Instances in either VPC can exchange traffic directly without internet gateways, VPNs, or Transit Gateway.
When Typically VPC Peering is Needed
Establishing connectivity across AWS accounts.
Enabling inter region communication between VPCs.
Routing of traffic between VPCs without using the internet.
Sharing resources such as databases or services across VPCs.
What Happens Internally
When a VPC Peering connection is created, AWS establishes a direct network link between the requester and accepter VPCs. Communication depends on routing and security configuration.
A peering connection ID is created and must be accepted by the target VPC.
Each VPC must update its route tables to include the CIDR block of the peer VPC.
Security groups and network ACLs must explicitly allow traffic to and from the peer VPC.
DNS settings can be enabled so private hostnames in one VPC resolve to private IPs in the peer VPC.
Typically you can configure VPC peering in many ways:
A simple VPC peering configuration with routes to an entire VPC with two VPCs looks like this. VPC A and VPC B are peered, and route tables in both VPCs include the full CIDR block of the peer.
What This Means
Instances in VPC A can send traffic to any instance in VPC B, and vice versa.
All subnets of both VPCs are reachable without defining subnet level routes.
Security groups and NACLs still control which traffic is allowed.
Use Cases
Centralized services such as logging or monitoring accessible from all VPCs.
Applications split across two VPCs that require unrestricted connectivity.
Simplified routing where subnet isolation is not required.
Full CIDR peering makes every subnet routable across VPCs. Restrict access with security groups if only specific resources should communicate.
VPC peering follows a full mesh architecture, meaning every VPC must have a direct peering connection with every other VPC it needs to communicate with.
In this Example:
VPC A ↔ VPC B (Peered)
VPC B ↔ VPC C (Peered)
VPC A ↔ VPC C (Peered)
Notice that even though A is connected to B, and B is connected to C, traffic cannot flow from A to C through B. If you need A to talk to C, you must set up a separate peering connection.
You can build the same with multiple VPCs as your network grows, creating a larger mesh of peering connections to scale the architecture.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Upgrade to Paid to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content.
UpgradePaid subscriptions get you:
- Access to archive of 250+ use cases
- Deep Dive use case editions (Thursdays and Saturdays)
- Access to Private Discord Community
- Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
- Quarterly 1:1 'Ask Me Anything' power session
