Skip to content

AWS Updated 2026-07-04

AWS operations support: who owns incidents, patching, scaling, and backups

AWS operations support only works when every recurring duty has one named owner. A practical ownership map for incidents, patching, scaling, and backups — and how to verify each is real.

AWS operations support comes down to four recurring duties — incidents, patching, scaling, and backups — and each one needs exactly one named owner, whether that name belongs to an employee or a provider. AWS itself owns none of them above the hypervisor: under the shared responsibility model, the OS, the response, the capacity plan, and the restore test are all yours. Environments do not fail because these duties are hard; they fail because each party assumed another had them.

What you are deciding

You are drawing an ownership map with no blank cells. For each duty, three roles must be assigned: who acts (does the work), who approves (authorizes disruptive actions), and who verifies (checks it actually happened). The verify column is the one everybody skips, and it is where the map earns its keep — backups that run but were never restored, patches that were “automated” onto instances that quietly fell out of the automation, autoscaling that was configured against a metric that stopped being representative two product launches ago.

The four duties, concretely:

  • Incidents — detection, acknowledgment, mitigation, communication, post-mortem. Ownership includes the overnight hours or an explicit statement that overnight is uncovered.
  • Patching — OS packages on EC2, minor engine versions on RDS, runtime updates on Lambda and containers, and the AMIs your autoscaling launches from. Each layer can have a different owner; each layer needs one.
  • Scaling — capacity planning, autoscaling policy tuning, and the manual scale decision during a traffic event. Also the cost half: someone owns shrinking things.
  • Backups — configuration, retention policy, restore testing, and the recovery runbook with real measured times.

A managed provider typically takes the act column for all four and shares approve with you; verify should always include you, because verification is how you know the contract is being performed.

What to check first

  1. Ask four people “who owns patching?” If you get two answers, you have zero owners with extra steps.
  2. Find the last restore test. A date and a duration, written down. Absence is your single most dangerous blank cell.
  3. Pull the last incident timeline. Who detected, how long to a human, who decided the mitigation. Gaps here are rehearsals for a worse night.
  4. Check whether scaling has been touched since launch. Policies tuned once and forgotten drift out of alignment with real traffic.

How to verify

Each duty has a command that separates claimed ownership from performed ownership:

# PATCHING: compliance state across the fleet (SSM Patch Manager)
aws ssm list-resource-compliance-summaries \
  --query 'ResourceComplianceSummaryItems[].[ResourceId,Status,NonCompliantSummary.NonCompliantCount]'

# BACKUPS: did jobs actually succeed recently?
aws backup list-backup-jobs --by-state COMPLETED --max-results 10 \
  --query 'BackupJobs[].[ResourceArn,CompletionDate]'
aws backup list-backup-jobs --by-state FAILED --max-results 10

# SCALING: are policies attached, and when did they last fire?
aws autoscaling describe-policies --auto-scaling-group-name prod-asg \
  --query 'ScalingPolicies[].[PolicyName,PolicyType]'
aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name prod-asg --max-records 10

# INCIDENTS: which alarms exist and where they page
aws cloudwatch describe-alarms \
  --query 'MetricAlarms[].[AlarmName,StateValue,AlarmActions[0]]' --output table

Console equivalents: Systems Manager > Patch Manager > Compliance reporting for the patch truth, AWS Backup > Jobs for backup outcomes, EC2 > Auto Scaling groups > Activity for scaling history. For the AWS-side half of incidents — is it us or them — the account view at https://health.aws.amazon.com/ is the first stop, and the Systems Manager documentation at https://docs.aws.amazon.com/systems-manager/ covers what patch automation can and cannot see.

The runbook

  1. Write the four-by-three table this week. Four duties, three roles, twelve cells, no blanks and no committees — a cell containing a team name instead of a person or contracted party is a soft blank. Publish it where the on-call can find it at 03:00.
  2. Give incidents a severity ladder and a paging path. Detection through alarms that notify a rotation, not an inbox. The alarm set itself should map to real failure modes — start from the CloudWatch alarm baseline and prune to what someone would act on at night.
  3. Automate patching, then own the exceptions. SSM Patch Manager with maintenance windows for the fleet, RDS auto minor upgrades in a defined window, AMI refresh on a schedule. The owner’s real job is the report of what did not patch and why.
  4. Make backups prove themselves quarterly. A restore test with the duration written down converts a checkbox into a capability. Cross-region protection decisions and their trade-offs are covered in AWS Backup cross-region, and database point-in-time mechanics in RDS PITR and snapshot strategy.
  5. Review scaling quarterly against real traffic. Compare policy thresholds to the last quarter’s actual peaks, and rightsize downward as deliberately as you scale upward — capacity ownership includes the bill.

When this is the wrong move

If your workload is a static site on S3 and CloudFront, most of this map collapses to backups of the source repository — do not build ceremony for duties that do not exist. If you are fully on managed serverless (Lambda, DynamoDB, no instances), patching largely shifts to AWS and your map should reflect that honestly rather than inventing work. And if the organization is about to migrate platforms, stabilize ownership of the current environment at the minimum-viable level instead of perfecting a map you are about to redraw.

Common mistakes

  • Confusing automation with ownership. Automation performs the duty; the owner watches the automation. Unowned automation fails silently for months.
  • Letting the incident owner also be the only approver. At 03:00 the person acting needs pre-authorized mitigations, not a phone tree.
  • Backing up everything, restoring nothing. Retention policies get audited; restore capability wins incidents.
  • Assigning ownership without hours. A name in a cell with no time budget is decoration — the duty still loses to the sprint.

Keeping it under control

  • Review the ownership table quarterly and on every departure or provider change — same day, not next sprint.
  • Trend four numbers: patch compliance percentage, restore test age, time-to-acknowledge, scaling-policy age.
  • Keep runbooks next to the code, versioned, with the last-tested date in the header.
  • When a provider holds the act column, keep the verify column in-house permanently — that is the whole oversight model in one rule.

An ownership map with twelve filled cells is boring, and boring is precisely what production operations should feel like. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.