Monitoring and SLAs

Every pattern in this topic assumes you find out

Multi-AZ redundancy, Auto Scaling health checks, a tested disaster recovery plan: every pattern this topic has covered so far quietly assumes something. It assumes you find out a failure is happening, ideally before a user does, and it assumes someone can say afterward, in hard numbers, how reliable the system actually was. This lesson covers both halves: monitoring, which is how you find out, and SLAs, which are the documented promise about how often you shouldn't have had to.

Monitoring: metrics, logs, and alarms

3 building blocks cover almost everything a monitoring setup does. A metric is a number tracked over time, average CPU utilization, requests per second, error rate. A log is a record of a specific event, a line saying exactly what happened and when, useful for investigating after something already went wrong rather than watching a trend. An alarm watches a metric against a threshold and takes an action once that threshold is breached for a defined period.

Amazon CloudWatch is AWS's implementation of all 3: it collects metrics automatically from most AWS services, stores and lets you query logs, and lets you define alarms on top of either. A concrete example: an alarm watches average CPU utilization in 5-minute periods, and if it stays above 80% for 3 consecutive periods, the alarm triggers, which might page an on-call engineer or, tying back to the previous lesson, feed directly into an Auto Scaling target-tracking policy that launches more capacity. Azure Monitor and Google Cloud Operations play the equivalent role on their own platforms; the vocabulary shifts slightly, but metrics, logs, and alarms are the same 3 pieces everywhere.

SLI, SLO, SLA: measuring, targeting, promising

These 3 terms get used almost interchangeably in casual conversation, and the exam boundary between them is worth learning precisely.

A Service Level Indicator (SLI) is a quantitative measurement of how a service is actually performing, like the percentage of requests that succeed. A Service Level Objective (SLO) is the internal target a team sets for that SLI, like "we aim for 99.95% successful requests." A Service Level Agreement (SLA) is the external, contractual version: a promise made to customers that, if missed, carries financial consequences, typically a service credit.

Think of an SLI as a car's speedometer reading, an SLO as the speed limit the driver privately commits to staying under, and an SLA as the promise made to a passenger that the trip won't exceed a certain speed, backed by a refund if it does. The comparison holds for the relationship between measuring, targeting, and promising, but it breaks on 1 point: an SLI isn't usually a single instant reading like a speedometer, it's typically aggregated over a window of time, an hour or a month, not a live glance at the dashboard.

Providers deliberately set the SLO stricter than the SLA. If a public SLA promises 99.9% uptime, the internal SLO driving day-to-day operations might be 99.95%, giving the team a buffer to notice and react before a missed internal target turns into a missed, compensable external promise.

The nines: what an uptime percentage costs in real downtime

Availability numbers get compared casually, "we're at 4 nines," without always registering what that actually means in hours. Each additional nine divides the allowed downtime by roughly 10, which is why the jump from 99.9% to 99.99% is a far bigger engineering commitment than the numbers alone suggest.

Most SaaS products and APIs target 3 nines. 5 nines is reserved for systems where even a few minutes of annual downtime carries real financial or safety consequences, and it costs proportionally more to engineer.

Worked example: reading a real SLA

The Amazon EC2 SLA is a useful, concrete case. It commits to a Region-level Monthly Uptime Percentage of at least 99.99%, and separately to an Instance-Level Uptime Percentage of at least 99.5% for individual instances. If actual Region-level uptime in a given month falls short, the credit tiers are 10% for 99.0% up to (but not including) 99.99%, 30% for 95.0% up to (but not including) 99.0%, and 100% below 95.0%.

Concretely: if Region-level EC2 uptime lands at 98.5% one month, that falls in the 95.0%-to-under-99.0% band, and the customer is eligible for a 30% credit on that service's bill for the month, applied automatically or on request depending on the provider, not a cash refund and not compensation for whatever revenue the outage cost the customer's own business.

What an SLA promises, and what it does not

It's tempting to treat "backed by an SLA" as "this will never go down" or as insurance against business losses. Neither is true. An SLA is a compensation mechanism for the provider's own failure to meet its own published commitment, paid out as a credit against future bills. It commonly excludes scheduled maintenance windows and factors outside the provider's control, and, just like the shared responsibility model from earlier in this domain, it only ever covers the provider's own service. An outage caused by a bug in the customer's own application code is the customer's reliability problem to monitor and fix; no provider SLA was ever written to cover it.

Boundary: chaining services makes the overall number worse, not better

A workload rarely depends on just 1 service. Chain 3 services with individual availability of 99.99%, 99.95%, and 99.9%, and it's tempting to assume the strongest one helps pull the average up. It doesn't: composite availability multiplies the individual probabilities rather than averaging them, so 99.99% times 99.95% times 99.9% lands around 99.84%, worse than any single component in the chain. Every added dependency is a tax on overall reliability, which is exactly why architects count how many services a critical request path actually touches, not just how reliable each one is in isolation.

Exam cues: matching a scenario to the right term

Where this leaves you

An SLA is a compensation contract set at a floor below what a provider privately targets for itself, never a guarantee that nothing will fail, and monitoring is what actually tells you, in real time, whether today is one of the days that floor gets tested. That closes out Security and Reliability: you can now name who owns which security task, how systems stay up through a failure, how they recover from one bigger than redundancy could absorb, and what a promise about uptime actually means when it doesn't hold. The next domain turns from what you know toward where it takes you: cloud careers and the certification path this course has been building toward all along.