The AWS Well-Architected Framework Sustainability Pillar helps teams reduce the environmental impact of cloud workloads while meeting business requirements. It calls for understanding a workload’s impact, then improving how much useful work it delivers for the resources it consumes. This guide explains the shared responsibilities, practical review areas, and AWS tools you can use to track progress.

The six design principles are to understand impact, establish sustainability goals, maximize utilization, adopt more efficient hardware and software, use managed services, and reduce downstream impact. Apply them across the workload lifecycle, not just when choosing compute. See the AWS sustainability design principles and best-practice areas for the complete guidance.

Shared responsibility for sustainability

AWS describes sustainability as a shared responsibility. AWS works on the sustainability of the cloud through efficient shared infrastructure, data-center water stewardship, and renewable power sourcing. Customers work on the sustainability in the cloud by designing and operating workloads that use fewer resources for the required outcome. That includes choosing and configuring services, removing waste, and considering the impact of how customers use your application. The AWS shared responsibility guidance describes both sides.

For an engineering team, this means provider improvements do not replace workload optimization. AWS operates the facilities and shared infrastructure; your team remains responsible for decisions such as capacity, data retention, architecture, and the amount of work your application performs.

Best practices for sustainable AWS workloads

AWS groups its workload guidance into six areas. Start with the largest sources of resource use, then evaluate changes against performance, reliability, security, and business needs.

Choose Regions for business and sustainability goals

First identify the Regions that meet your data-residency, service-availability, latency, resilience, and other business requirements. When more than one Region is suitable, include sustainability goals in the decision. Region choice can affect a workload’s carbon footprint, but the result depends on more than usage volume: electricity-grid intensity and AWS energy procurement also matter. Include the extra data transfer and latency that a move could introduce; do not assume that any single Region is always the lowest-impact choice. See the AWS guidance to choose a Region based on business requirements and sustainability goals.

Align capacity to demand

Match provisioned capacity to actual demand. Right-size resources from representative workload measurements, scale dynamically where demand varies, and stop or schedule non-production resources that do not need to run continuously. Avoid scaling down so far that retries, latency, or redundant capacity erase the expected benefit. For EC2-based workloads, autoscaling guidance can help with demand-driven capacity; validate its scaling limits against your own service objectives.

Optimize software and architecture

Profile before rewriting. Find code paths that consume the most compute, memory, network, or storage resources, then check whether an algorithm, cache, queue, schedule, or simpler service boundary can deliver the same outcome with less work. Prefer benchmarks from your own representative load over general claims that one programming language is always more energy-efficient than another. Consider the resources your application requires on customer devices as well as in AWS.

Manage data for real access patterns

Classify data and set retention, backup, and storage policies to match its value and access pattern. Remove redundant or expired data, avoid unnecessary copies, and limit cross-Region or other network transfers where the application allows it. Amazon S3 Lifecycle rules can transition or expire objects according to policy; they do not guarantee a particular carbon reduction. See this guide to S3 Lifecycle rules for implementation details.

Select efficient hardware and managed services

Choose an instance family, processor, storage type, or accelerator that fits the work and its performance needs. Newer or specialized hardware may improve work per unit of resource, but the result depends on the workload, so benchmark before adopting it broadly. Managed services can pool infrastructure across customers and reduce the operating work your team maintains; choose them when their behavior and tradeoffs fit the workload. For a database example, see the RDS instance rightsizing guide. A managed or serverless service is not automatically more sustainable in every workload—measure the outcome.

Make sustainability part of the engineering process

Set workload-level goals, assign an owner, and include sustainability work in normal architecture and deployment reviews. A useful goal measures resource use or emissions per unit of business output, such as per transaction or completed batch, so growth does not hide a decline in efficiency. Revisit the goal when demand, architecture, or the AWS services you use change.

Measure impact with the right tools

Use service and application telemetry to understand what the workload is doing. For example, CPU, queue depth, request volume, and storage access patterns can help locate overprovisioning or excess work. CloudWatch metrics are operational signals; they do not directly report a workload’s energy use or carbon emissions.

For AWS emissions estimates, use the current AWS Sustainability service. It provides carbon emissions estimates by reporting period, scope, Region, and service, along with water-allocation views and downloadable or programmatic data. The estimates are published monthly for the previous usage month, by the 21st of the following month, so they are useful for reporting and trend review rather than live scaling decisions. AWS notes that data may be unavailable for a new account, and emissions below 0.5 grams CO2e for a month display as zero. Service-level detail is grouped for many services; check the data definitions and resolution before using the figures in detailed analysis.

The former AWS Customer Carbon Footprint Tool was deprecated on June 30, 2026, in favor of AWS Sustainability. AWS reports estimates, not a direct energy reading for each request or resource. Its calculation methodology can change as data and methods improve, and historical estimates may be recalculated. Review the AWS Sustainability calculation methodology and tool release notes when establishing reporting boundaries or comparing historical values.

Cost and resource-use metrics can guide investigation, but they are not substitutes for carbon measurements. A lower bill or higher utilization percentage alone does not prove emissions fell: cost also depends on pricing and configuration, while emissions estimates reflect service usage, location, energy sources, and the calculation method. Compare the same workload output and reporting boundary before and after a change, using the published methodology to interpret the estimates.

Run a repeatable improvement cycle

The Well-Architected guidance treats sustainability improvement as an iterative process. Use this cycle to keep changes measurable and safe:

  1. Set a baseline. Record the workload’s useful output, performance and reliability measures, and the resource usage relevant to its major components. Choose an appropriate unit, such as requests or jobs completed.
  2. Find a target. Use telemetry and architecture review to identify a material hotspot, idle resource, unnecessary data movement, or wasteful process.
  3. Choose and assess a change. State the expected resource or emissions improvement, implementation cost, and risks to performance, reliability, security, and user experience.
  4. Test under representative conditions. Compare the same work before and after the change. Reject or revise changes that miss service objectives or shift costs and resource use elsewhere.
  5. Deploy, measure, and repeat. Roll out a successful change, record its measured result, and look for the next improvement. AWS documents this sustainability improvement process.

Key takeaways

  • Reduce the resources required to deliver a defined workload outcome, while maintaining its service objectives.
  • Apply all six practice areas: Region selection, demand, software and architecture, data management, hardware and services, and process and culture.
  • Keep responsibilities clear: AWS improves the infrastructure; customers optimize their workloads and the resources they deploy.
  • Use operational telemetry to find engineering opportunities and AWS Sustainability’s monthly estimates to review emissions trends. Neither cost nor utilization alone proves a carbon reduction.