Why cloud architectures drift
Most AWS workloads start out reasonable and then drift. A team ships fast, adds services under deadline pressure, copies a security group from another project, and sizes instances for a launch peak that never returns. None of these choices is wrong on its own. Together they produce a workload that is harder to operate, more expensive than it needs to be and less resilient than anyone assumes.
The AWS Well-Architected Framework is AWS’s answer to that drift. It is a set of questions and best practices, written by AWS solutions architects, that you use to review a workload and decide what to fix first. It does not prescribe one architecture. It gives you a consistent way to find the gaps.
The six pillars
The framework is organized into six pillars. Each pillar has its own whitepaper, design principles and review questions.
- Operational Excellence: running and monitoring systems, and improving processes and procedures over time. Typical topics are infrastructure as code, small reversible changes, runbooks and learning from operational events.
- Security: protecting data, systems and assets. This covers identity and access management, detection, infrastructure protection, data protection and incident response.
- Reliability: making a workload perform its intended function correctly and consistently, including recovering from failure. Topics include service quotas, network topology, change management and backup and recovery.
- Performance Efficiency: using computing resources efficiently as demand changes and technology evolves, for example by choosing the right instance families, storage and database engines for the access pattern.
- Cost Optimization: delivering business value at the lowest price point. This includes expenditure awareness, matching supply to demand and choosing the right pricing model.
- Sustainability: reducing the environmental impact of running cloud workloads, mainly by improving utilization and reducing the resources a workload needs.
The pillars trade off against each other. Adding a second Region improves reliability and raises cost. A review makes those trade-offs explicit, so the business decides them rather than leaving them to chance.
Common challenges and what the framework asks
Security gaps that build up quietly
Long-lived access keys, broad IAM policies and logging that was never switched on are among the most frequent findings in any review. The Security pillar asks how you manage identities, how you detect events and how you protect data at rest and in transit. In practice the fixes are well understood: use IAM roles and temporary credentials instead of access keys, grant least privilege, enable AWS CloudTrail across all accounts and Regions, turn on Amazon GuardDuty, and encrypt data with AWS KMS.
Reliability that has never been tested
Many teams have backups they have never restored and Multi-AZ settings they have never failed over. The Reliability pillar pushes you to define recovery time and recovery point objectives, automate recovery, and test it. AWS Backup, Multi-AZ deployments for Amazon RDS and Auto Scaling groups spread across Availability Zones are the usual building blocks, but the important part is proving they work.
Cost that grows faster than usage
Overprovisioned instances, idle resources and steady workloads paid for at On-Demand rates are common. The Cost Optimization pillar asks whether you use the right pricing model for each workload. On-Demand is the most flexible option and the most expensive per hour. For steady, predictable usage, Savings Plans and Reserved Instances offer discounts of up to 72% compared with On-Demand in exchange for a one- or three-year commitment. For interruption-tolerant work, Spot Instances are available at up to 90% off On-Demand prices. Rightsizing with AWS Compute Optimizer and removing idle resources usually comes first, because there is no point committing to capacity you do not need.
Operations that depend on a few people
When deployments are manual and knowledge sits in one engineer’s head, every change is a risk. The Operational Excellence pillar asks how you deploy, observe and improve. Defining infrastructure as code with AWS CloudFormation or the AWS CDK, deploying through a pipeline, and running configuration and patching through AWS Systems Manager make changes repeatable and auditable.
Performance tuned for yesterday
A workload designed years ago may run on older instance generations or a database engine that no longer fits its access pattern. The Performance Efficiency pillar asks you to review your selections regularly, test newer options such as AWS Graviton-based instances, and use caching and managed services where they fit.
The AWS Well-Architected Tool
The AWS Well-Architected Tool is a service in the AWS Management Console that walks you through the review questions for a workload and records your answers. There is no additional charge for using it.
You define a workload, answer the questions for each pillar, and the tool flags each question as a high risk issue (HRI) or medium risk issue (MRI) depending on which best practices are missing. AWS describes an HRI as an architectural or operational choice that could have a significant negative impact on the business, and an MRI as one with a smaller impact. Each flagged question links to AWS guidance on how to address it.
Lenses
The AWS Well-Architected Framework Lens is applied to every workload by default. You can add more lenses from the Lens Catalog, which AWS maintains. Examples include Serverless Applications, SaaS, Data Analytics, Machine Learning, Generative AI, Container Build, Migration, IoT, Financial Services Industry and Healthcare Industry. Each lens adds its own questions, best practices and improvement plan.
You can also create custom lenses with your own pillars, questions and best practices, for example to encode internal standards, and share them with other AWS accounts.
From review to a prioritized improvement plan
A review is only useful if it changes the workload. The Well-Architected Tool produces an improvement plan for each lens, listing high risk issues first and then medium risk issues, with links to the relevant guidance. A practical way to work through it:
- Agree on scope. Review one workload at a time, with the people who build and run it in the room. Answer questions honestly; an optimistic answer only hides risk.
- Triage the high risk issues. Not every HRI matters equally to your business. Rank them by impact and effort, and group items that share a fix, such as several findings resolved by one logging or IAM change.
- Turn items into tickets. Put each improvement in your normal backlog with an owner and a target date, so it competes fairly with feature work.
- Save a milestone. A milestone records the state of the workload at a point in time, including the high and medium risks present. Save one at the end of the review and again after each round of fixes to show progress.
- Review again. Repeat the review after major changes, or on a regular schedule, so new drift is caught early.
Teams often find that the first review produces more findings than they can fix at once. That is normal. The value is in knowing which risks you carry, choosing which to accept, and fixing the rest in order.
Working with 9Acts
9Acts is an AWS Advanced Tier Services Partner and AWS MSP Partner, and has run AWS reviews and improvement work with clients since 2016. If you want a structured review of one of your workloads, see our AWS Well-Architected Review service.