Cost Optimisation and Sustainability Pillars

The Cost Optimisation pillar focuses on avoiding unnecessary costs and getting the most value from your AWS spending. It is often the most immediately impactful pillar because cloud resources are easy to over-provision. Key design principles: Implement cloud financial management — treat cost as a first-class metric. Adopt a consumption model — pay only for what you use. Measure overall efficiency — track cost per unit of business value. Reduce spending on undifferentiated heavy lifting — use managed services instead of managing infrastructure.

Right-sizing is the most impactful cost optimisation action — identifying and eliminating over-provisioned resources. A common pattern is launching large instances during initial provisioning and never revisiting them. AWS Compute Optimizer analyses utilisation metrics and recommends the optimal instance type. Common finding: an m5.4xlarge running at 5% CPU should be a t3.medium, saving 80% of compute cost. Right-sizing applies to EC2, Lambda (memory), RDS, and EBS volumes.

For steady-state workloads, On-Demand pricing is the most expensive option. Significant savings are available through: Reserved Instances (1 or 3 years) — up to 72% savings for predictable workloads. Savings Plans — flexible commitment (up to 66% savings) that applies across instance families and regions. Spot Instances — up to 90% savings for interruptible workloads (batch, CI/CD, stateless). A typical cost-optimised fleet combines all three: Savings Plans for the baseline, Spot for burst, On-Demand for edge cases.

Spot Instances use spare AWS capacity at up to 90% discount but can be interrupted with 2 minutes' notice when AWS needs the capacity back. Spot works well for: batch processing (checkpoint and resume), CI/CD build agents, stateless web servers (behind ALB; ELB routes around interrupted instances), and EMR and EKS worker nodes. Use Spot Fleet or ASG with multiple instance types and AZs to diversify across pools and reduce interruption risk.

S3 storage costs can be dramatically reduced by using the right storage class and automating transitions. S3 Intelligent-Tiering automatically moves objects between access tiers based on access patterns — ideal when access patterns are unknown. Lifecycle rules transition objects on a schedule: from Standard → Standard-IA after 30 days → Glacier after 90 days → Deep Archive after 180 days. Also consider S3 Select to retrieve only the needed subset of object data, reducing data transfer and processing costs.

Without proper tagging, it is impossible to understand what each team or project is spending. Cost Allocation Tags let you break down costs by team, project, environment, or any dimension you define. Activate tags in the Billing console, then use AWS Cost Explorer to filter and group costs by tag. Enforce tagging with Tag Policies in AWS Organizations and use AWS Config rules to detect untagged resources. This enables showback (visibility) and chargeback (cost attribution) to individual teams.

The Sustainability pillar (added in 2021) focuses on minimising the environmental impact of cloud workloads by reducing energy consumption and increasing efficiency. Design principles: Understand your impact — measure the carbon footprint of your workloads. Establish sustainability goals. Maximise utilisation — right-size to avoid idle resources. Anticipate and adopt more efficient hardware — use the latest instance generations. Use managed services — AWS runs data centres more efficiently than most organisations.

AWS Graviton processors (ARM-based) offer up to 60% better energy efficiency and 20-40% better price/performance compared to x86 instances. Graviton3/4 instances (c7g, m7g, r7g, t4g families) are available for most EC2, Lambda, and Fargate workloads. Moving from x86 to Graviton improves both the Sustainability and Cost Optimisation pillars simultaneously — fewer watts per computation and lower instance prices. Most workloads (Linux, containerised apps, JVM) can migrate with minimal changes.

A major source of unnecessary cost and energy waste is idle resources — EC2 instances sitting at 1% CPU, unattached EBS volumes, unused Elastic IPs, and forgotten dev/test environments running 24/7. Implement a stop/start schedule for non-production environments using EventBridge rules and Systems Manager Automation — stop dev instances at 6pm, start at 8am. Use AWS Trusted Advisor and Cost Explorer to identify idle instances, unused EBS volumes, and underutilised Reserved Instances.

Storing data indefinitely wastes energy. The Sustainability pillar recommends implementing data lifecycle policies to automatically delete or archive data that is no longer needed. Use S3 Lifecycle rules with expiration dates to delete objects after a retention period. Use DynamoDB TTL to automatically expire old records. Use CloudWatch Logs retention policies to delete log groups after a defined period. Deleting unnecessary data reduces both your storage costs and the energy required to store and cool it.

Cost Optimisation sometimes conflicts with other pillars. Multi-AZ RDS doubles your database cost but is required for the Reliability pillar. Cross-Region Replication improves reliability but increases storage and transfer costs. Active-active multi-region reduces latency (Performance Efficiency) but costs 2-3x more. The Well-Architected Framework does not say to always choose the cheapest option — it says to make conscious trade-offs between pillars and document the reasoning. The exam tests your ability to select the most cost-effective solution that still meets the stated requirements.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Cost Optimisation combines right-sizing, purchasing models (Reserved/Savings Plans/Spot), and S3 lifecycle management, Sustainability focuses on maximising utilisation, using Graviton instances, and implementing data lifecycle policies, and cost trade-offs with other pillars should be made consciously based on business requirements. Cost tags enable showback and chargeback across teams. Next up we explore the Well-Architected Tool and the review process.