The Cost Optimization pillar is the most ignored of the six and the one with the clearest dollar return. This guide walks the five design principles, the four practice areas, and exactly how a Well-Architected Review surfaces cost high-risk issues — then the part most teams miss: a partner-led WAFR can unlock AWS remediation funding so the remediation itself is AWS-funded.
The AWS Well-Architected Framework is six pillars — Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. Cost Optimization is the fifth, and in practice it is the one teams skip, because the other five feel like engineering and this one feels like finance.
That framing is the first mistake. The Cost Optimization pillar is not a finance exercise bolted onto an architecture review — it is an architecture discipline whose unit of measure happens to be dollars. The pillar's own definition, from the AWS documentation, is "the ability to run systems to deliver business value at the lowest price point." The operative phrase is at the lowest price point: not the cheapest possible system, but the cheapest system that still delivers the required business value. That distinction runs through every principle and practice below.
Each pillar in the framework is backed by a whitepaper, a set of design principles, a set of best-practice questions, and a checklist surfaced through the AWS Well-Architected Tool (a free service in the AWS console). For Cost Optimization the current whitepaper organises the material into five design principles and four practice areas, and the Tool asks a fixed set of questions (the "COST" questions, COST 1 through COST 11 in the current lens) whose answers determine your risk profile.
It helps to be precise about three terms that get used loosely. A pillar is one of the six domains. A lens is a set of questions applied to a workload — the default is the AWS Well-Architected Framework lens, but there are specialised lenses (Serverless, SaaS, Machine Learning, Financial Services) that re-ask the pillar questions for a specific context. A workload is the thing being reviewed: a collection of components delivering business value, usually mapping to one application or service. You review a workload against a lens, pillar by pillar.
Why does the cost pillar matter more in 2026 than it did five years ago? Because the era of zero-interest-rate "growth at any cost" is over, and because cloud bills have become one of the largest line items in a software company's P&L — frequently second only to payroll. Boards now ask about gross margin, and gross margin for a software business is largely a cloud-efficiency story. The cost pillar is the closest thing AWS publishes to a rubric for that story.
The pillar opens with five design principles. They are deliberately abstract — they are principles, not tactics — but each one maps to concrete behaviour. Here is what each actually means once you stop reading it as a slogan.
Read in order, the five principles describe a maturity arc: first you set up the financial-management function, then you change how you buy, then you measure, then you delete what you don't need to own, and finally you assign cost to the teams that incur it. A team that has internalised all five does not need a review to stay efficient. Most teams have internalised one or two, which is exactly why the review finds so much.
Treat cost as a first-class engineering concern with an owner, a cadence, and tooling — the discipline the industry now calls FinOps. In practice this means someone (or a small cross-functional group) is accountable for cloud spend, there is a regular review of cost trends, and engineers have visibility into the cost consequences of their architecture choices before the invoice arrives.
The anti-pattern is the bill landing on finance's desk once a month with no one able to explain a 30% jump. The principle is not "spend less"; it is "build the organisational capability to reason about spend at all."
Pay only for what you use, and scale usage to actual demand rather than provisioning for peak forever. This is the principle that separates cloud-native thinking from lift-and-shift thinking: a server that runs 24/7 at 8% utilisation to handle a two-hour daily spike is a data-centre habit, not a cloud one.
Concretely: turn off non-production environments outside working hours, auto-scale stateless tiers, and use serverless (Lambda, Fargate) where the workload is genuinely spiky. The consumption model is also why on-demand pricing for steady-state workloads is a finding — steady state is the one place the consumption model says you should commit (see Savings Plans below).
Tie cost to a business output metric so you can tell improvement from mere shrinkage. Cost per active user, cost per thousand API calls, cost per processed transaction, cost per inference — pick the denominator that matches your business. A bill that falls because you lost customers is not an efficiency win; a bill that stays flat while traffic doubles is.
This principle is what makes the pillar an engineering discipline rather than a cost-cutting one. Without a business-output denominator, "cost optimization" degenerates into "cost reduction," and cost reduction eventually starts removing value.
Let AWS run the commodity layers so your engineers work on what differentiates you. Running your own database on EC2 when RDS or Aurora would do, patching your own message brokers when SQS exists, or managing your own Kubernetes control plane when EKS or Fargate is available — these spend engineering payroll (the most expensive line item) on work that creates no competitive advantage.
The subtle point: this principle frequently increases a specific AWS service line while decreasing total cost of ownership, because the managed-service premium is smaller than the loaded cost of the engineers it frees. The pillar measures business value at the lowest price point, and engineer-hours are part of the price.
Make cost visible and attributable to the team, product, feature, or customer that incurs it. This is the tagging-and-allocation principle, and it is the one with the highest leverage, because you cannot manage what you cannot attribute. When every engineering team can see its own slice of the bill, optimisation becomes self-service — teams optimise their own line because they own it.
In AWS terms this means a cost-allocation tagging strategy, activated cost-allocation tags, and the use of AWS Cost Explorer, AWS Budgets, and (at scale) AWS Cost and Usage Reports broken down by tag, account, or organisational unit. Attribution is the precondition for accountability.
All five principles serve one definition: deliver business value at the lowest price point. Notice that none of them says "spend less." Cost Optimization in the Well-Architected sense is about efficiency — value per dollar — not raw frugality. A review that ends with you spending the same amount but getting twice the value has succeeded.
If the five principles are the philosophy, the four practice areas are the work. AWS organises every cost best-practice question under one of these four headings. This is the part of the pillar you can act on this quarter.
The four practice areas are: (1) practice cloud financial management (expenditure and usage awareness), (2) use cost-effective resources, (3) manage demand and supply resources (matching supply to demand), and (4) optimize over time. The labels vary slightly between the whitepaper and the Tool, but the substance is stable. Below is what lives in each, with the specific AWS services and the typical findings.
You cannot optimise what you cannot see. This area is about visibility, attribution, and governance: knowing what you spend, on what, by whom, and being alerted before a surprise compounds.
Services: AWS Cost Explorer (trend analysis), AWS Budgets (alerts and actions), AWS Cost and Usage Report (line-item detail), AWS Cost Anomaly Detection (ML-based spike alerts), cost-allocation tags, and AWS Organizations for multi-account separation. Typical findings: no tagging strategy, no budgets configured, no anomaly detection, a single account mixing prod and non-prod so nothing is attributable.
Once you can see spend, buy it correctly. This is the largest and most familiar area: right-sizing, the correct pricing model, and the correct service for the job.
Right-sizing means matching instance/database size to actual utilisation (AWS Compute Optimizer recommends this directly). Pricing model means choosing among On-Demand, Savings Plans, Reserved Instances, and Spot — commit for steady state, use Spot for fault-tolerant batch, stay On-Demand only for genuinely unpredictable load. Right service means Graviton (ARM) over x86 where compatible (typically 20–40% better price-performance), S3 storage classes matched to access patterns, and serverless where it genuinely costs less. Typical findings: On-Demand pricing on 24/7 workloads, over-provisioned instances, x86 where Graviton would run, single-storage-class S3.
Provision to current demand, not to a peak that occurs twice a year. This is the consumption model made operational.
Services: EC2 Auto Scaling and Application Auto Scaling (scale horizontally with load), scheduled scaling (shrink overnight and at weekends), Lambda and Fargate (scale to zero between requests), and demand-based scaling driven by queue depth or request rate. Typical findings: fixed-size fleets sized for peak, no scheduled shutdown of dev/staging, no auto-scaling on a tier whose load clearly varies, a cron-style batch job holding a permanent cluster.
Optimisation is not a project; it is a standing process. AWS ships new instance families, new pricing options, and new managed services constantly, and what was optimal last year may be a finding this year. This area is about establishing the cadence to keep capturing that.
Services and habits: regular review of AWS Trusted Advisor cost checks, re-running Compute Optimizer, watching for newer-generation instances (each generation is typically cheaper per unit of work), revisiting Savings Plans coverage as the baseline shifts, and decommissioning resources that outlived their purpose. Typical findings: previous-generation instances still running, expired or under-covering Savings Plans, idle resources (unattached EBS volumes, idle load balancers, old snapshots) nobody deleted.
Inside "use cost-effective resources," one decision moves more dollars than any other: which compute pricing model you use. Because reviewers see this finding constantly, it is worth a dedicated walkthrough.
AWS sells the same compute at radically different prices depending on commitment and interruptibility. The cost pillar does not say "always commit" — it says match the pricing model to the demand pattern. The mistake is almost never "committed too much"; it is running everything On-Demand because nobody owned the analysis.
The mechanics, briefly. On-Demand is the list price — maximum flexibility, no commitment, highest unit cost. Savings Plans commit you to a dollar-per-hour spend for 1 or 3 years in exchange for a discount (Compute Savings Plans are the flexible option, applying across instance family, size, region, and even Lambda/Fargate). Reserved Instances are the older mechanism, more rigid than Savings Plans, still relevant for RDS and a few services. Spot Instances sell spare capacity at deep discounts but AWS can reclaim them with two minutes' notice — ideal for fault-tolerant, interruptible work.
The practical recipe the pillar implies: identify your steady-state baseline (the compute you run every hour of every day), cover roughly that baseline with Compute Savings Plans, run fault-tolerant batch and CI on Spot, and leave only genuinely unpredictable load On-Demand. Most teams that have never done this are 100% On-Demand and leave a large, recurring discount on the table.
| Model | Commitment | Typical discount vs On-Demand | Interruptible? | Best for |
|---|---|---|---|---|
| On-Demand | None | 0% (baseline) | No | Spiky, unpredictable, short-lived workloads |
| Compute Savings Plans | 1 or 3 yr ($/hr) | ~up to 66% (3-yr) | No | Steady-state baseline; flexible across family/region/Lambda/Fargate |
| Reserved Instances | 1 or 3 yr (specific) | ~up to 72% (3-yr) | No | Stable RDS/ElastiCache; legacy commitments |
| Spot Instances | None | ~up to 90% | Yes (2-min notice) | Fault-tolerant batch, CI/CD, stateless scale-out |
| Graviton (any model) | Orthogonal | ~20–40% price-perf | n/a | Any ARM-compatible workload, stacks on the above |
A Well-Architected Review (WAFR) is a structured walkthrough of your workload against the framework's questions, recorded in the AWS Well-Architected Tool. Run against the cost pillar, it produces a ranked list of High Risk Issues — the concrete findings you then work down. Here is the actual mechanic.
The Well-Architected Tool is free and lives in the AWS console. You define a workload (name, environment, regions, the account(s) it spans), choose a lens (the default Framework lens, or a specialised one), and then answer the best-practice questions pillar by pillar. For Cost Optimization the questions are the COST series — covering financial management, expenditure awareness, cost-effective resources, demand/supply matching, and optimisation over time, i.e. the four practice areas above.
For each question you select which best practices you currently follow. The Tool maps unselected best practices to risks and classifies each as a High Risk Issue (HRI) or a Medium Risk Issue (MRI). An HRI is something the framework considers likely to cause material business impact — for the cost pillar, "material" usually means "you are demonstrably overspending or flying blind." The output is not a score out of ten; it is a prioritised list of HRIs with the relevant best-practice guidance attached.
The review itself is a few hours of structured conversation when run by someone experienced — a reviewer walks the questions with your team, captures the real state (not the aspirational one), and the Tool computes the HRI list. The artefact you leave with is a remediation plan: the HRIs ranked, the best-practice guidance for each, and an owner and rough effort against every item. That plan is the actual deliverable. The review is diagnosis; the value is in the treatment that follows.
A note on honesty during the review: the temptation is to answer aspirationally ("yes, we tag everything") because HRIs feel like a report card. They are not. An HRI you hide is an overspend you keep paying. The reviews that return the most money are the ones where the team answers about the system as it actually is.
Everything above you could do yourself with the free Tool. Here is the reason to involve an AWS partner: when an APN partner runs your Well-Architected Review, AWS attaches a remediation incentive — and that turns the cost pillar from a self-improvement exercise into one where AWS helps pay for the fixes.
AWS runs a Well-Architected Partner Program. Partners in it are trained and authorised to deliver formal reviews and record them in the Well-Architected Tool against your account. To encourage customers to actually close their HRIs (AWS wants healthy, durable workloads, not shelf-ware reviews), AWS offers a remediation incentive: historically AWS credits — commonly on the order of $5,000 per reviewed workload, sometimes more depending on workload size and the program terms in force — issued when HRIs identified in the review are remediated.
Stack the economics. The Well-Architected Tool is free. A partner-delivered review is frequently delivered at no cost to you because the partner is funded by AWS for the engagement. The remediation incentive then offsets the cost of doing the fixes. So the realistic shape of a partner-led cost-pillar WAFR is: free review, an HRI list quantifying recurring overspend, and AWS credits that fund a meaningful slice of the remediation — on top of the ongoing savings the remediation itself produces.
The two returns compound and should not be confused. The one-time return is the remediation funding — AWS credits offsetting the cost of the work. The recurring return is the overspend you stop paying every month forever once the HRIs are closed (the Savings Plans you finally buy, the instances you right-size, the idle resources you delete). The funding is the smaller number; the recurring savings is usually far larger. The funding is simply what gets the project approved and started.
Important honesty: the exact incentive amount, eligibility, and mechanics are set by AWS and change over time, and they depend on workload scope and partner tier. The durable fact is the structure — AWS funds partner-led reviews and incentivises remediation because consolidated, efficient workloads are worth more to AWS than the credits cost. Treat any specific dollar figure as indicative and confirm current terms with the partner running your review.
AWS funds Well-Architected Reviews and remediation for the same reason it funds credits and migrations: a customer whose workloads are efficient, reliable, and well-governed stays on AWS longer and grows. The remediation incentive is cheaper for AWS than the churn and support cost of an unhealthy account. The structural incentive is what makes the funded path real — not a discount someone is doing you a favour with.
You have two honest options, and the right one depends on your situation. The free Tool genuinely works; the partner path exists because of the funding and the experience the reviewer brings. Here is the straight comparison.
If you have a strong internal FinOps function and the discipline to act on findings, the self-service review is real and costs nothing. The partner-led path earns its place in two situations: when you want the remediation funding, and when you want an experienced reviewer who has seen the same HRIs across dozens of workloads and can tell the load-bearing finding from the cosmetic one. For most growth-stage teams, the funding plus the outside eye is worth more than the time saved doing it alone.
You already run regular cost reviews, you have a named FinOps owner, your tagging is in place, and you mainly want the structured HRI checklist to make sure you have not missed a category. The Tool gives you exactly that for free, and you do not need anyone's permission to start this afternoon.
You want AWS to help fund the remediation; you do not have spare engineering cycles to both diagnose and fix; you have never run a formal WAFR and want someone who has run many; or the workload is large enough that a few points of efficiency is real money. In these cases the funded review pays for itself before you count the recurring savings.
The cost pillar does not live in isolation — its findings frequently trade against the other pillars, and a mature review holds the tension rather than optimising one pillar into the ground. Here is how it interacts.
| Pillar | Core question | Tension with cost | Where they align |
|---|---|---|---|
| Operational Excellence | Can you run and improve workloads? | Tooling/automation has a cost | Automation kills idle waste; ops visibility = cost visibility |
| Security | Are data and systems protected? | Logging, encryption, WAF add spend | Least-privilege also limits blast radius of runaway cost |
| Reliability | Does it recover from failure? | Multi-AZ/redundancy costs more | Right-sized HA beats over-provisioned HA |
| Performance Efficiency | Are resources used efficiently? | Faster can mean pricier hardware | Graviton, right-sizing serve both at once |
| Sustainability | Are you minimising environmental impact? | Almost none | Fewer/efficient resources = lower carbon AND lower cost — nearly identical |
The free Tool and the funded partner review are both legitimate. The difference is funding, experience, and who does the remediation — not whether the review "counts."
| Variable | Self-service (free Tool) | Partner-led funded WAFR |
|---|---|---|
| Cost of the review | $0 (your time) | $0 (AWS-funded engagement) |
| Remediation funding | None | AWS credits, often ~$5K+/workload on remediation |
| Reviewer experience | Your team | Trained APN reviewer who has seen the HRIs at scale |
| Recorded in WA Tool | Yes (by you) | Yes (by the partner, against your account) |
| HRI list produced | Yes | Yes — usually with sharper prioritisation |
| Who fixes the HRIs | You | You and/or the partner, partly AWS-funded |
| Best for | Teams with a mature FinOps function | Teams who want the funding + an outside expert |
Situation: New VP Eng inherited a cloud bill growing faster than revenue and a board asking about gross margin. The team suspected significant waste but had never run a formal Well-Architected Review and had no FinOps owner. They wanted a credible, AWS-blessed diagnosis and the engineering capacity to act on it — without pulling four engineers off the roadmap for a month.
What CloudRoute did: Routed within 24 hours to an APN partner in the AWS Well-Architected Partner Program with a FinOps practice. The partner ran a cost-pillar WAFR through the Well-Architected Tool, producing nine HRIs: no cost-allocation tagging, 100% On-Demand on a clear steady-state baseline, no budgets/anomaly detection, three over-provisioned RDS instances, x86 on Graviton-compatible services, no S3 lifecycle policies, dev/staging running 24/7, ~40 unattached EBS volumes, and previous-generation instances. AWS attached a remediation incentive to closing the HRIs.
Outcome: Tagging + budgets + anomaly detection stood up in week 1. Compute Savings Plans purchased against the verified baseline; RDS right-sized; Graviton migration on the compatible tiers; lifecycle policies and idle-resource cleanup. Recurring AWS spend fell from ~$48K to ~$31K/month (~35%) within eight weeks; the AWS remediation credit covered the bulk of the remediation engineering. CloudRoute's commission was paid by the partner from AWS engagement funding — the customer paid $0 for the review.
engagement window: 8 weeks · recurring savings: ~35% · remediation: AWS-funded · cost to customer for the review: $0
CloudRoute routes you to an APN partner in the AWS Well-Architected Partner Program who runs the WAFR, hands you the HRI list, and unlocks the AWS remediation funding so the fixes are AWS-funded. Customer pays $0 for the review.