AWS operational excellence means running and monitoring workloads, learning from operational events, and improving the processes that deliver business value. The practices below are a practical selection, not an official five-part AWS checklist. The Well-Architected Operational Excellence pillar groups its guidance into Organization, Prepare, Operate, and Evolve, with recommendations for controlled changes, clear procedures, useful operational data, and continuous learning.

Use these practices together: a safe release needs a way to detect trouble, a known response, and a workload designed to recover. Choose controls that match your service objectives and the AWS services you actually use. See the AWS Well-Architected Operational Excellence pillar for the full framework.

1. Make small, reversible changes

Smaller changes are easier to review, test, and diagnose. Keep application code, infrastructure definitions, and deployment configuration in version control so the team can see what changed and restore a known version when that is safe.

Validate the proposed change before deployment

Run automated checks before release, then deploy to a lower environment that exercises the same important dependencies as production. For infrastructure managed with CloudFormation, a change set previews proposed resource changes, including resources that may be replaced. Review the preview, but remember that it does not guarantee the update will succeed.

For tool-specific guidance on resource ownership, reviewing generated plans, and handling drift or Terraform state, see our guide to AWS IaC pitfalls.

Limit the release and plan the recovery

Deploy in stages when your delivery system supports it. For example, release an API change to a small portion of traffic, compare its error rate and latency with the existing version, and pause before the next stage if a service guardrail is exceeded. Define who can stop the rollout and how to restore service.

A rollback is not always safe for data or schema changes. Keep application versions compatible with the migration sequence, or plan a forward repair and recovery procedure. AWS recommends frequent, small, reversible changes and fast feedback on change quality in its guidance for designing operations.

2. Keep procedures current and usable

A runbook should help a responder complete a known task; a playbook should guide investigation when the cause or response is not yet clear. Give each procedure an owner and keep it near the source of truth your team uses, with permissions and review practices appropriate to its contents.

Make each procedure actionable

For a common event such as a rise in API errors, document the signal that starts the response, safe checks to narrow the cause, actions the responder may take, how to confirm recovery, and when to escalate. Include links to the relevant dashboard, service owner, and recovery steps. Keep commands and assumptions current as the workload changes.

For repeatable AWS actions, Systems Manager Automation runbooks can encode ordered steps against AWS resources. Review the permissions a runbook needs and use an appropriate IAM role; automation should be understandable, limited to its purpose, and safe to retry where possible.

Rehearse and improve procedures

Review procedures after incidents, significant architecture or deployment changes, and exercises that expose gaps. A game day can walk the on-call team through a dependency outage or a failed release without affecting production. Record what was unclear, assign corrective actions, and update the procedure. AWS recommends validating operational readiness, maintaining runbooks and playbooks, and practicing failure response in the pillar's Prepare guidance.

3. Design for failure and test recovery

Start with the outcomes the workload must preserve during an interruption, then map the dependencies that could prevent them: compute, network paths, data stores, queues, identity, and external services. Decide which failures the design must tolerate and what recovery time and data loss are acceptable. A multi-Availability Zone design helps isolate some zone failures, but every required tier and dependency needs a compatible recovery plan.

Configure redundancy for the workload

For an EC2 application, an Auto Scaling group can replace unhealthy instances and distribute capacity across Availability Zones when it is configured with subnets in those zones. Use health checks that reflect whether the application can serve requests, and ensure the remaining capacity and dependencies can handle the load during an impairment. AWS's multi-location reliability guidance explains how to plan across Availability Zones and when a regional recovery design may be warranted.

Test the response with clear limits

Use controlled exercises to check that monitoring detects the failure, responders follow the procedure, and the workload returns to an acceptable state. AWS Fault Injection Service templates define actions, targets, an IAM role, and optional stop conditions. A CloudWatch alarm can stop an experiment when a workload signal crosses a safety threshold, but stopping the experiment does not guarantee that every effect has been undone: only some FIS actions support configured post-actions. Define how the workload will return to steady state, then verify recovery. Start with a narrow target and a non-production environment when practical. See the AWS docs for FIS stop conditions and action post-actions.

4. Use operational data to guide action

Collect data that answers a question about customer or business outcomes. For a request-serving API, useful signals might include successful request volume, error rate, and latency percentiles; a queue-based worker may also need queue age and processing failures. Add infrastructure and dependency signals where they help explain those outcomes. Metrics, logs, and traces should let responders connect a symptom to the affected component.

Make alerts actionable

Set thresholds from workload behavior and service objectives rather than using a universal CPU or latency number. Give each alert an owner, a response procedure, and an escalation path. Review alarm history after incidents and adjust thresholds or missing-data treatment when alerts are late, noisy, or fail to detect a real problem.

CloudWatch alarms can notify subscribers, invoke Lambda functions, or emit state-change events to EventBridge, among other supported actions. Reserve automatic remediation for known, bounded responses; grant only the permissions it needs and test its failure path. The current CloudWatch alarm actions documentation lists the available actions and their behavior. For a service-specific walkthrough of Lambda execution, error, and throttling metrics, see our guide to analyzing Lambda metrics in CloudWatch.

Use the right record for the investigation

CloudTrail records account activity such as AWS API calls; it does not record application exceptions or serve as a workload-failure monitor. Use application logs and metrics to investigate those failures. When the question is how an AWS resource's recorded configuration changed, AWS Config can provide configuration history for resource types you have configured it to record. Its history and inventory concepts are covered in our AWS Config resource inventory and change tracking guide, and in the AWS Config documentation.

5. Use managed services with clear expectations

Managed services can reduce the work your team does for selected infrastructure tasks, but the amount of work transferred differs by service and configuration. Compare that benefit with the controls you still need to own: access, capacity, application behavior, data protection, monitoring, and recovery. AWS remains responsible for the resilience of the cloud infrastructure; customers remain responsible for configuring and operating resilient workloads and protecting their data under the service's model.

Check the service's failure behavior

For example, an Amazon RDS Multi-AZ DB instance deployment maintains a standby for failover, but that standby does not serve read traffic. A Multi-AZ DB cluster is a different deployment type with reader instances. Confirm which deployment you have, what failover covers, and whether backups and restore procedures meet your recovery objectives. See how RDS Multi-AZ deployments differ.

Lambda removes the need to manage the function's server fleet, but your workload still depends on concurrency limits, permissions, event delivery and retry behavior, and downstream capacity. Review service quotas and test the whole request path instead of treating a managed service as an availability guarantee. AWS's shared responsibility guidance for resiliency describes the boundary between AWS infrastructure and customer workload responsibilities.

Conclusion

Operational excellence comes from a working loop: make a controlled change, observe its effect, respond through a prepared procedure, and use what you learn to improve the workload. Start with the practice that addresses your largest operational risk, name an owner, and verify that the expected recovery or customer outcome actually occurs.

FAQs

What is an example of an operational excellence best practice in AWS?

One example is treating infrastructure changes as code: review the proposed change, test it in a lower environment, release it in a controlled stage, and define how to recover if its health signals worsen. The right rollout and recovery method depends on the resources and data affected.

What focus areas does AWS use for the Operational Excellence pillar?

AWS groups pillar guidance into four focus areas: Organization, Prepare, Operate, and Evolve. The five practices in this article are a practical selection across those areas, not AWS's official list of focus areas. See the AWS Well-Architected Operational Excellence pillar.