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.
Upgrade your AI knowledge with The CODE! Dive into a newsletter trusted by 200,000+ readers for its comprehensive, 5-minute snapshot of everything happening in AI. We navigate through hundreds of sources to bring you the latest AI trends, tools, and resources—so you can stay ahead, absolutely free.
IN TODAY'S EDITION
🧠 Use Case
How To Design a Secure Three Tier Architecture on AWS
👀 Remote Jobs
DistantJob is hiring a Sr DevOps Engineer
Remote Location: Worldwide
Flashbots is hiring a Senior DevOps Engineer
Remote Location: Worldwide
Powered by: Jobsurface.com
📚 Resources
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
🛠 TOOL OF THE DAY
DevOpsRoadmap.io - A FREE pragmatic DevOps learning to kickstart your DevOps career and knowledge in the Cloud Native era following the Agile MVP style.
🧠 USE CASE
How To Design a Secure Three Tier Architecture on AWS
Most outages and breaches I have traced back on AWS accounts share the same root cause: a database sitting in a subnet that has a route to the internet, or an application server accepting traffic directly from anywhere rather than through a load balancer. A three tier architecture exists to prevent exactly this. It separates a system into a presentation layer, an application layer, and a data layer, and places each one behind the network boundary that matches how much exposure it actually needs.
Why the layers get separated in the first place
The presentation layer is what the public reaches, typically a load balancer distributing requests. The application layer runs the actual business logic on compute instances. The data layer holds the database. Each layer only needs to talk to the layer immediately next to it. The load balancer needs to reach the application servers, the application servers need to reach the database, but the database never needs to initiate contact with anything outside the VPC, and the public internet never needs to reach the application servers or the database directly. Once you accept that constraint, the network design mostly writes itself.
Public subnets carry the entry point
Traffic starts with users reaching an Internet Gateway attached to the VPC. From there it hits an Application Load Balancer sitting in a public subnet. A public subnet is defined by having a route table entry pointing to the Internet Gateway, which is what makes it reachable from outside AWS at all. Nothing else in this architecture needs that route.
The ALB is the only thing directly reachable from the internet in this design. It terminates incoming connections and forwards them to healthy targets, which removes any need for individual application instances to be publicly reachable at all.
Application instances stay inside an Auto Scaling Group, spread across zones
Behind the ALB sit the EC2 instances that run the application. They are managed by an Auto Scaling Group, which handles launching new instances when load increases and replacing ones that fail health checks. Placing instances in a public subnet in this diagram is intentional for the ALB-to-instance path, but the instances themselves are only reachable through the Security Group attached to them, which permits inbound traffic solely from the ALB rather than from the internet at large.
Splitting the instances and the ALB targets across two Availability Zones, as shown with one instance in Availability Zone 1 and one in Availability Zone 2, means the loss of a single zone does not take the application down. The ALB simply stops routing to the unhealthy target and continues serving traffic through the surviving zone.
Database instances sit in private subnets with no path to the internet
The database tier lives in private subnets, one per Availability Zone, and a private subnet has no route table entry pointing to the Internet Gateway. This is what actually keeps the database unreachable from outside AWS, not a firewall rule alone but the absence of a network path in the first place. Even if every Security Group rule were misconfigured, there would be no route for external traffic to arrive on.
Each application instance connects to both database instances, one in its own Availability Zone and one across the zone boundary, which is what a primary and standby database pair typically requires for replication and failover. The Security Group wrapped around the database instances only allows inbound connections from the application tier Security Group, on the specific database port, nothing broader.
Why Security Groups are layered on top of subnet routing rather than replacing it
A Security Group is a stateful firewall attached to the instance itself, and it is the second control in this design, not the only one. The private subnet's missing internet route is what removes reachability at the network layer. The Security Group then narrows, within that already-restricted network, exactly which source is allowed to open a connection and on which port. Losing one control does not collapse the whole design, since the other is still in effect.
How the pieces work together end to end
A request starts at the Internet Gateway, moves to the ALB in the public subnet, gets distributed to a healthy EC2 instance inside the Auto Scaling Group, and that instance queries the database sitting in the private subnet. At no point does a request skip a layer. The ALB never talks to the database, and the database never talks to anything outside the VPC. Each Security Group only trusts the layer that is supposed to be calling it, the ALB's Security Group accepts from the internet on the listener port, the instance Security Group accepts from the ALB's Security Group, and the database Security Group accepts from the instance Security Group.
Practical points worth applying
Never assign a public IP or an Internet Gateway route to the subnet holding the database tier, regardless of how tightly the Security Group is scoped.
Reference Security Groups by ID in your inbound rules rather than by CIDR range, so that scaling the Auto Scaling Group up or down does not require updating firewall rules.
Spread both the application instances and the database instances across at least two Availability Zones, since a design that survives a zone failure needs redundancy at every tier, not only at the load balancer.
Keep the ALB as the sole internet-facing component. Any application instance that ends up with a public IP defeats the isolation this architecture is built to provide.
THE CODE - Learn how to code faster with AI in 5 mins a day. Loved by 300k+ devs, engineers at Meta, Google, OpenAI, and more.
🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)
Looking to promote your company, product, service, or event to 49,000+ DevOps and Cloud Professionals? Let's work together.
