The Well-Architected cost pillar, in practice (2026).
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 five best practice areas, and how a Well-Architected Review surfaces cost high-risk issues. It also covers when a partner helps, and what AWS funding does and does not cover.
- The Cost Optimization pillar of the AWS Well-Architected Framework is built on five design principles (cloud financial management, consumption model, measuring efficiency, stop spending on undifferentiated heavy lifting, attributing expenditure) and five best practice areas (cloud financial management, expenditure and usage awareness, cost-effective resources, managing demand and supply, optimizing over time). It is the framework AWS itself uses to decide whether your spend is healthy.
- A Well-Architected Review (WAFR) run against the cost pillar produces a list of High Risk Issues (HRIs) — concrete, ranked findings like "no cost-allocation tagging," "on-demand pricing on steady-state compute," or "no lifecycle policies on S3." The output is a remediation plan, not a grade. The value is in working the HRI list down.
- You can run the review yourself: AWS charges nothing extra for the Well-Architected Tool. A partner helps when you lack the time to act on the findings. AWS partner funding (MAP, POC or incremental workload funding) is tied to new work such as a migration, a test or a new workload, not to a review on its own.
IWhat the Cost Optimization pillar actually is
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 five best 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.
IIThe five design principles, decoded
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.
Principle 1 — Implement cloud financial management
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."
Principle 2 — Adopt a consumption model
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).
Principle 3 — Measure overall efficiency
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.
Principle 4 — Stop spending money on undifferentiated heavy lifting
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.
Principle 5 — Analyze and attribute expenditure
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.
IIIThe best practice areas: where the savings actually are
If the five principles are the philosophy, the best practice areas are the work. This is the part of the pillar you can act on this quarter.
AWS groups the cost best practices into five areas: practice cloud financial management, expenditure and usage awareness, cost-effective resources, manage demand and supply resources, and optimize over time. Cloud financial management is covered by the first design principle above. Below are the other four, with the AWS services and the typical findings.
Area 1 — Expenditure and usage awareness
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.
Area 2 — Cost-effective resources
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.
Area 3 — Matching supply to demand
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.
Area 4 — Optimizing over time
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.
IVThe pricing-model decision, in detail
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 |
VHow a Well-Architected Review surfaces cost HRIs
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.
- No cost-allocation tagging / attribution: You cannot say which team or product drives spend. Almost always an HRI because it blocks every downstream optimisation.
- On-Demand pricing on steady-state compute: A persistent baseline running at list price with no Savings Plans or RIs — a recurring, quantifiable overspend.
- No budgets or anomaly detection: Nothing alerts you to a cost spike until the invoice. Flagged because the blast radius of a runaway resource is unbounded.
- Over-provisioned / un-right-sized resources: Instances and databases far larger than utilisation warrants, with Compute Optimizer recommendations unactioned.
- No lifecycle management on storage: S3 with no lifecycle policies, unattached EBS volumes, and stale snapshots accumulating indefinitely.
- No scaling to demand: Fixed fleets sized for peak; non-production environments running 24/7. The consumption-model HRI.
- Previous-generation resources: Older instance families still running where a newer generation delivers the same work for less — the "optimize over time" HRI.
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.
VIWhat a partner adds, and what AWS funds
Everything above you can do yourself with the Well-Architected Tool. A partner adds experience and hands to do the fixes. AWS funding through partners is tied to new work, not to a review on its own.
AWS partner funding for startups covers three routes: MAP when you move a workload to AWS, POC funding when you test something, and incremental workload (IW) funding when you launch new work on AWS. For startups: $50K to $150K. Depends on the workload; AWS approves. If the fixes from your review come with one of those projects, ask the partner what qualifies.
Remediation credits after a partner-led review: a 2019 AWS Partner Network guest post said AWS provides credits to customers who move forward with fixes found in the review. AWS does not publish current terms on a program page we could find on 10 October 2026. Treat it as something to ask about, not something to plan around.
Keep the two returns apart. Any one-time funding is the smaller number. The recurring return, the overspend you stop paying every month once the issues are closed, is usually far larger.
An earlier version of this page put a fixed credit amount on each reviewed workload and said the fixes are AWS-funded. We could not source that, so we removed it.
VIISelf-service review vs partner-led review
Both are legitimate. The right one depends on your time, your skills, and whether the fixes come with new work.
If you have a FinOps owner and the discipline to act on findings, the self-service review is real and AWS charges nothing extra for the Well-Architected Tool. A partner earns its place when you lack the cycles to both diagnose and fix, or when you want a reviewer who has seen the same issues across many workloads.
When self-service is the right call
You already run regular cost reviews, you have a named FinOps owner, your tagging is in place, and you mainly want the structured checklist to make sure you have not missed a category. The Tool gives you exactly that, and you can start this afternoon.
When a partner-led review wins
You do not have spare engineering time to both diagnose and fix; you have never run a formal review and want someone who has run many; the workload is large enough that a few points of efficiency is real money; or the fixes come with a migration, a test or a new workload that may qualify for MAP, POC or IW funding.
VIIIHow the cost pillar relates to the other five
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 |
Self-service review vs partner-led review
Both reviews count. The difference is experience, time, and who does the fixes.
| Variable | Self-service (Well-Architected Tool) | Partner-led review |
|---|---|---|
| Tool cost | No additional charge | No additional charge for the Tool |
| Reviewer | Your team | An AWS partner who has run many reviews |
| Recorded in the Tool | Yes (by you) | Yes (by the partner, in your account) |
| Risk list produced | Yes | Yes, usually with sharper priorities |
| Who does the fixes | You | You and/or the partner |
| AWS partner funding | Not applicable | Only if the work includes a qualifying migration, test or new workload (MAP, POC or IW) |
| Best for | Teams with a mature FinOps function | Teams short on time or planning bigger changes |
How a match works (example)
- You tell us about the work
You fill in a short form: what you run today, what you want to move, test or build, your stage and your region.
- We pick one partner
We read your answers and pick one vetted AWS consulting partner that fits the work, the stack and the region. We reply within 24 hours; your matched partner reaches out within 5 business days.
- The partner checks which funding fits
Your matched partner scopes the work with you. Then it checks which partner-filed funding fits: MAP if you are moving to AWS, POC if you want to test something, or incremental workload (IW) funding if you are already on AWS and launching new work.
- The partner files, AWS decides
If the work qualifies, the partner files the funding request with AWS. AWS reviews it and decides. The amount depends on the workload.
- You pay nothing
CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.
AWS Activate credits are separate, and you apply for them yourself. Use Activate Founders if no investor backs you. Use Activate Portfolio with the Org ID or invite from your VC, accelerator, incubator or angel group if it is an Activate Provider. A consulting partner cannot apply for Activate on your behalf.
Common questions
What is the Cost Optimization pillar of the AWS Well-Architected Framework?
What are the five design principles of the cost pillar?
What is a High Risk Issue (HRI) in a Well-Architected Review?
Does a Well-Architected Review actually cost money?
Does a Well-Architected Review unlock AWS funding or credits?
Is the cost pillar about spending less money?
Which AWS services map to the cost pillar's practice areas?
Self-service review or partner-led review — which should I choose?
Want a partner to run the review and the fixes?
CloudRoute introduces you to one vetted AWS partner who can run the cost-pillar review and help close the issues. If the fixes come with a migration, a test or new work on AWS, the partner can check MAP, POC or IW funding for it: $50K to $150K for startups. Depends on the workload; AWS approves. We reply within 24 hours; your matched partner reaches out within 5 business days.