Cost-aware architecture treats cost as a property of a system, like availability or latency: much of a cloud bill is fixed once it is decided who runs a service, on which model it runs, across how many zones and regions it spreads, where its data sits and which processor architecture it computes on. Rightsizing and commitments then optimise only within those decisions. That is why AWS, Microsoft and Google each give cost its own pillar in their Well-Architected Frameworks, and why the FinOps Foundation places the work in its Architecting & Workload Placement capability. How such decisions are reviewed and approved is covered in cost in architecture and procurement reviews.
How it works
The three frameworks name their principles differently but set the same frame: pay for what is used, tie cost to an outcome, and keep adjusting.
| Framework | Principles of the cost pillar |
|---|---|
| AWS Well-Architected, Cost Optimization Pillar | Implement cloud financial management; Adopt a consumption model; Measure overall efficiency; Stop spending money on undifferentiated heavy lifting; Analyze and attribute expenditure |
| Azure Well-Architected Framework, Cost Optimization | Develop cost-management discipline; Design with a cost-efficiency mindset; Design for usage optimization; Design for rate optimization; Monitor and optimize over time |
| Google Cloud Well-Architected Framework, Cost Optimization | Align cloud spending with business value; Foster a culture of cost awareness; Optimize resource usage; Optimize continuously |
Microsoft also documents where cost optimisation collides with the other pillars: reliability, security, operational excellence and performance efficiency. Those trade-offs are the core of every architecture decision with a price attached:
| Decision | What it fixes in cost | What it is weighed against | Question to ask |
|---|---|---|---|
| Managed service or self-run | a higher unit price against operating work for patching, backups and failover that appears on no invoice | control, licences | Who runs it at night and at weekends? |
| Serverless, containers or virtual machines | billing per invocation and duration, per requested pod resource, or per instance hour | sustained load, runtime limits, cold starts | How many hours a day is there load? |
| One zone or several | standbys and replicas as additional instances, traffic between zones | availability target | Which failure justifies the surcharge? |
| One region or several | duplicated infrastructure, replication and transfer between regions | recovery target | What does a regional outage cost by comparison? |
| Data placement | egress, transfer between services and zones | latency, data residency | Where is the data read? |
| Arm or x86 | separate price lists for Arm types | build and dependency chain | Do arm64 builds exist for every dependency? |
The billing units of the operating models are covered in serverless functions, containers and Kubernetes and virtual machines and instance families; data transfer prices in data transfer and egress.
AWS
Amazon RDS for PostgreSQL lists separate prices for Single-AZ, Multi-AZ with one standby in another zone, and Multi-AZ with two readable standbys, which runs identical instances in three zones. Replication between the zones of a Multi-AZ deployment is free; traffic between an EC2 instance and an RDS instance in different zones costs the EC2 regional data transfer rate, which the RDS pricing page gives as USD 0.01 per GB in each direction without naming a region (read on 2026-10-16). A snapshot copy to another region costs the transfer and then storage in the destination region. For Arm, AWS requires every third-party library of a Lambda function to have an arm64 version.
Azure
Between the availability zones of one region, Azure charges no data transfer, and the type of IP address makes no difference. The Arm sizes of the Dpsv6 series run on Microsoft's own Cobalt 100 processor.
Google Cloud
Traffic from a VM to a VM, to Cloud SQL or to GKE in another zone of the same region costs USD 0.01 per GiB, a rate the VPC pricing page gives for every region (read on 2026-10-16), charged to the project of the sending VM. Cloud SQL bills high-availability, regional instances at their own HA prices; traffic from Cloud SQL to Compute Engine in the same region is free, and to a replica in another region it costs USD 0.12 per GiB, inside and outside North America alike. The C4A and N4A series run on Google's Arm processor Axion.
What it means for your cost
Architecture sets quantity and unit price before any commitment lowers the rate, and no discount replaces it afterwards. A decision is therefore recorded with three things: the expected cost in a business unit, such as per request or per customer (unit economics), the trade-off that justifies it, and the event that triggers a review. The chapter's order holds here too: architecture first, then measurement and rightsizing, commitments last (commitment strategy). A reservation bought for an instance family before serverless or Arm is decided stays payable for every hour of its term, whether that family still runs or not. The levers on the traffic itself are in data transfer optimisation.
Where it goes wrong
- High availability everywhere. Symptom: test and development databases run with a standby or at HA prices. Cause: the production template was copied to every environment without weighing it.
- Zone traffic nobody planned for. Symptom: the regional data transfer line grows with load. Cause: application and database sit in different zones; AWS charges both directions between EC2 and RDS, Google Cloud the direction from the VM to Cloud SQL.
- A second region without a budget. Symptom: transfer and storage lines appear in a second region. Cause: snapshot copies or replicas were set up for disaster recovery without their price being planned.
- An Arm migration stalls. Symptom: the move stops at one service. Cause: a library or layer has no arm64 version.
- Self-run looks cheaper. Symptom: the own database server costs less on the invoice than the managed service. Cause: patching, backups and failover show up as working time, not as a cloud line; AWS puts this under its principle "Stop spending money on undifferentiated heavy lifting".
- A commitment before the decision. Symptom: after moving to serverless or Arm, a reservation sits unused. Cause: it was bought for the old instance family.
Example
An application on virtual machines reads from a managed database in another zone of the same region; V₁ is the gigabytes sent to the database, V₂ the gigabytes returned. At the rates read on 2026-10-16, traffic between EC2 and RDS on AWS costs USD 0.01 × (V₁ + V₂), charged on the EC2 side in both directions (a rate AWS states without a region). On Google Cloud with Cloud SQL only the direction from the VM to the database costs, USD 0.01 × V₁ (in GiB, in every region), because traffic from Cloud SQL to Compute Engine in the same region is free. On Azure the same traffic costs nothing. The same architecture therefore has three prices, and the gap grows with volume.
Sources
Read on 2026-10-16. AWS Cost Optimization Pillar and its design principles, Amazon RDS pricing, Amazon RDS for PostgreSQL pricing, Lambda instruction set architectures and arm64; Microsoft cost optimisation design principles, cost optimisation trade-offs, availability zones, Dpsv6 series; Google Cloud cost optimisation pillar of the Well-Architected Framework, VPC network pricing, Cloud SQL pricing, general-purpose machine family; FinOps Foundation Architecting & Workload Placement (CC BY 4.0).