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.

This live Kubernetes session shows you practical ways modern environments can optimize resource allocation at scale.

You will learn:

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

Every cloud engineer eventually inherits a system that was built quickly and never revisited. AWS gives engineers the building blocks to avoid this, but the platform itself does not force good architecture on anyone. A handful of design principles separate systems that survive real production conditions from systems that only work as long as nothing goes wrong. Four of these principles come up in nearly every AWS architecture review, and they are worth understanding from first principles rather than as checklist items.

Hardware fails. A single EC2 instance, no matter how well configured, sits on physical infrastructure that can and eventually will have a problem, whether that is a disk failure, a hypervisor issue, or a full rack losing power. Designing for failure means assuming this will happen and building the system so that a single failure does not become an outage.

Running a primary and a replica already protects against one instance failing, since a hardware fault on Instance A does not take the replica down with it. But this setup still has a gap. Both instances, and both sets of EBS volumes, sit inside the same Availability Zone, a physically distinct data center location within an AWS region. If that entire AZ loses power, network connectivity, or suffers a facility level incident, both the primary and the replica go down together, and the replication that was supposed to protect the system offers no protection at all, because the failure took out both sides at once.

Spreading the primary and replica across two separate Availability Zones closes that gap. Each AZ has its own independent power, cooling, and network infrastructure, so a failure in AZ1 has no physical path to affect AZ2. The Application Load Balancer sits in front of both instances and only sends traffic to whichever one is healthy, so a full zone failure now means a failover rather than an outage. Writing backups to Amazon S3, a service that itself stores data across multiple Availability Zones automatically, adds a further layer of protection that survives even if both compute instances and their attached volumes were lost at the same time.

A system where every component talks directly to every other component, and where a failure or a slowdown in one component immediately blocks all the others, is described as tightly coupled. Loose coupling means each component can fail, restart, or slow down without dragging the rest of the system down with it, usually achieved by separating layers with something in between them, like a load balancer or a queue, rather than having components call each other directly.

Each layer in this design only knows about the layer directly next to it, never reaching past it. The web tier does not know how many app tier instances exist behind the internal ALB, or which one will actually handle a given request, it only knows the internal ALB's address. This matters in practice: if the app tier needs to scale from four instances to twelve, or if half the app tier instances need to be replaced during a deployment, the web tier requires zero changes, since its only relationship is with the load balancer sitting in front of the app tier, not with any specific instance behind it.

The database layer follows the same principle in a different way. The Primary DB and Standby Instance sit in separate Availability Zones with synchronous replication between them, meaning a write is not confirmed as successful until it has been written to both. If the primary fails, automatic failover promotes the standby, and because the app tier connects to the database through a stable endpoint rather than a specific instance address, this failover can happen without every app tier instance needing manual reconfiguration. CloudFront and S3 sitting in front of the ALB serve a similar decoupling purpose for static content specifically, since a spike in traffic for images or scripts gets absorbed by CloudFront's caching layer entirely, without that load ever reaching the web tier or the ALB at all.

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