Free lesson · SRE and CloudOps on AWS

What SRE means on AWS specifically

Easy8 min readawssrereliability

The Model, And What Changes On AWS

SRE as a discipline came from an environment where the organisation ran its own data centres, its own hardware, and its own infrastructure software. The practices - error budgets, toil reduction, blameless postmortems, SLO-driven prioritisation - transfer cleanly. The subject matter does not.

Important: On AWS you are not responsible for the failure domain you are designing against. You do not run the hypervisor, replace the disk, or manage the power. AWS does, and you inherit both the reliability of that work and its failure modes without visibility into either.

The consequence: SRE on AWS is disproportionately architecture and disproportionately less infrastructure operations. The question shifts from "how do I make this machine reliable" to "how do I compose services whose failure modes I cannot control into a system that survives them."

That is a genuinely different job. A team that hires SREs expecting infrastructure operators, and gives them managed services, will find the operators have little to operate - and the architectural work that would actually improve reliability goes undone.

What you own on AWS:

Yours	AWS's
Architecture - how you compose services	Service implementation
Which failure modes you design for	Which failure modes exist
Application code and its behaviour under failure	Hardware, hypervisor, facilities
Configuration - the largest source of self-inflicted outages	Service availability within its SLA
Capacity, quotas, and headroom	Underlying capacity
Operational practice - detection, response, learning	-

Managed Does Not Mean Reliable

The assumption that causes the most damage.

Warning: A managed service has failure modes, degrades in specific ways, and has a published availability target that is not 100%. Using it does not transfer reliability responsibility to AWS; it changes which failures you must design for.

RDS Multi-AZ fails over automatically - and the failover takes a period during which writes fail, and your connection pool holds stale connections afterwards unless it handles reconnection. That is your problem, and it is invisible until it happens.

DynamoDB is highly available and it throttles. A hot partition returns errors at low aggregate utilisation, and the application must handle them.

Lambda scales and it has concurrency limits. Reaching one produces throttling that looks like an outage.

The discipline: for every managed service in your architecture, be able to state how it fails and what your application does when it does. A team that cannot answer that for its primary datastore has not done reliability engineering on it, regardless of how managed it is.

Composite availability is the arithmetic people skip. A request touching five services, each at 99.9%, has a theoretical availability of about 99.5% if every dependency is required - because failures compound. Reducing hard dependencies is usually a larger reliability lever than improving any single one.

Where Reliability Actually Comes From On AWS

graph TD
    A[Reliability on AWS] --> F[**Free** - use it or waste it]
    A --> B[**Built** - your architecture]
    A --> O[**Operated** - your practice]
    F --> F1[Multi-AZ managed services]
    F --> F2[ELB health checks and draining]
    F --> F3[Auto Scaling replacement]
    F --> F4[S3 and DynamoDB durability]
    B --> B1[Redundancy across AZs]
    B --> B2[**Timeouts, retries with jitter,<br/>circuit breakers**]
    B --> B3[Graceful degradation<br/>and load shedding]
    B --> B4[**Static stability**]
    O --> O1[SLOs and error budgets]
    O --> O2[Detection and alerting]
    O --> O3[Incident response]
    O --> O4[Learning and prevention]

This diagram shows where reliability comes from on AWS, in three categories. Free capabilities you either use or waste include multi-Availability-Zone managed services, load balancer health checks and connection draining, Auto Scaling instance replacement, and S3 and DynamoDB durability. Built capabilities from your architecture include redundancy across Availability Zones, timeouts and retries with jitter and circuit breakers, graceful degradation and load shedding, and static stability. Operated capabilities from your practice include service level objectives and error budgets, detection and alerting, incident response, and learning and prevention.

The free tier of that diagram is where most easy reliability sits, and it is routinely under-used. A single-AZ RDS instance, an Auto Scaling group in one AZ, or an application that does not use connection draining is leaving available reliability unclaimed.

Static stability is the AWS-specific principle worth naming. A system is statically stable if it continues to operate correctly without requiring a control plane action during a failure. An Auto Scaling group that must launch instances during an AZ failure depends on the EC2 control plane at the moment everyone else is also calling it. Pre-provisioning capacity across AZs so that losing one requires no action is more reliable than reacting well.

What SRE Actually Does Here

The practices, and how they land in an AWS context.

SLOs and error budgets - Topic 2. The mechanism that converts reliability from an opinion into a number, and creates the space for engineering work.

Toil reduction - Module 05 Topic 2. On AWS, much of this is moving up the managed services ladder rather than writing automation.

Blameless postmortems - Module 05 Topic 1, with an AWS-specific failure taxonomy that makes pattern detection possible.

Instrumentation and alerting - Module 02. The signal, and protecting the humans who respond to it.

Failure testing - Module 04 Topic 1. FIS makes AZ-level failure injection genuinely accessible, which was not true a few years ago.

Capacity and quota management - Module 03 Topic 2. Quotas are an AWS-specific reliability constraint with no on-premises equivalent, and they cause outages.

The Configuration Problem

Worth separating out, because it is where the failures actually come from.

Tip: In a mature AWS estate, self-inflicted change causes more incidents than infrastructure failure does. A security group rule, an IAM policy, a route table entry, a parameter value, a deployment, a certificate that expired.

That has a direct implication for where reliability effort goes. A team investing heavily in multi-Region failover while deploying manually to production has optimised for the rare event and left the common one unaddressed.

The high-return work in most organisations is unglamorous: change control that makes a bad change hard, progressive delivery with automatic rollback, configuration validation before deployment, and certificate expiry monitoring. Course 3 Modules 04 and 05 cover the mechanisms; the SRE contribution is insisting that incident data drives where the effort goes rather than intuition.

Categorise your last twenty incidents. The distribution will tell you what to work on, and it is rarely what the roadmap says.

Reading AWS's Own Reliability Model

Understanding how AWS structures availability is a prerequisite for designing against it.

Regions are fully independent. Failures do not propagate between them by design, which is why multi-Region is the answer to a Region failure and nothing less is.

Availability Zones are physically separated with independent power, cooling, and networking, connected by low-latency links. Multi-AZ is the primary reliability mechanism and it is cheap.

Services differ in scope. Some are zonal - an EC2 instance lives in one AZ. Some are Regional - S3, DynamoDB, SQS. Some are global - IAM, Route 53, CloudFront. Knowing which is which tells you what a given failure can affect.

Control plane and data plane fail differently, and this is the most useful distinction. The data plane - serving requests, reading objects - is generally more available than the control plane - creating resources, changing configuration. A design that must call the control plane during a failure is depending on the less available half at the worst moment, which is the static stability argument restated.

The Well-Architected reliability pillar and the AWS Health Dashboard are both worth building into practice rather than consulting occasionally.

Where SRE Sits Organisationally

Model	Works when
Embedded - SREs in product teams	Teams are large enough, and the practice is consistent
Central - one SRE team	Small organisation, or a shared platform focus
Hybrid - central practice, embedded practitioners	Most common at scale

The relationship to platform engineering matters and is often muddled. Course 3 covers the platform team, which builds the paved path. SRE is concerned with whether the resulting systems are reliable and improving. They overlap heavily and they are not the same function - a platform team can ship an excellent paved path to a system with no SLOs and no incident learning.

Warning: SRE without the authority to affect priorities is operations with a different title. If the team is paged for a service they cannot require changes to, they are absorbing the consequences of decisions they do not influence, and the reliability will not improve.

The error budget is the mechanism that provides that authority - a shared, agreed number that says when reliability work takes precedence. Without it, reliability competes with features on opinion, and it loses. Topic 2 covers making it real.

The other precondition is engineering time. A team spending all of its capacity on operations cannot reduce the operations. Google's 50% toil ceiling exists for that reason, and the number matters less than the principle: capacity must be protected for the work that removes the operational load.

Common Failure Modes

Warning: "It is managed, so it is reliable." Managed services have failure modes you must design for.

No stated failure behaviour for each dependency.

Composite availability not calculated. Five 99.9% dependencies is not 99.9%.

Control plane dependency during failure. The less available half, at the worst moment.

Multi-Region built while deploying manually. Rare event addressed, common one ignored.

Incident distribution never analysed. Effort follows intuition.

SRE as renamed operations.

SRE with no authority. Absorbing consequences without influence.

No protected engineering time. Operations cannot be reduced.

Free reliability unused. Single-AZ, no draining, no health checks.

Quotas unmanaged. An AWS-specific constraint with no on-premises equivalent.

Why This Matters In An Interview

Interview: SRE interviews test whether reliability is understood as a system property or as an operational activity.

What interviewers are listening for:

Managed services having failure modes you must design for.

Static stability - not depending on control plane actions during a failure.

Configuration and change as the dominant incident source.

The error budget as the mechanism that makes reliability work happen.

Common follow-ups:

"What does an SRE do on AWS that differs from on-premises?" → Less infrastructure operation, more architecture. You inherit failure modes you cannot see and must design around them. Quotas, control plane dependencies, and composite availability become primary concerns.

"You use RDS Multi-AZ. Is your database reliable?" → More reliable, and failover takes time during which writes fail, and your connection pool must reconnect. Being able to state how a managed service fails is the actual test.

"Where would you invest to improve reliability?" → Categorise the last twenty incidents first. In most estates the answer is change management and progressive delivery, not multi-Region - because self-inflicted change causes more incidents than infrastructure failure.

"How does SRE get reliability prioritised?" → An agreed error budget with a policy attached. Without it, reliability competes with features on opinion and loses.

Practice

Exercise: Starter. For each managed service in one system, write down how it fails and what your application does when it does. The gaps are your reliability backlog.

Intermediate. Categorise your last twenty incidents by cause. Compare the distribution against where reliability effort is currently going.

Advanced. Identify every control plane call your system would need to make during an AZ failure. For each, determine whether it can be pre-provisioned instead.