Running a workload on AWS does not by itself guarantee lower emissions. The practical aim is to deliver the same useful outcome with fewer resources, while meeting the workload’s security, availability, latency, and recovery requirements.

This guide groups related actions into five working principles. The AWS Well-Architected Sustainability Pillar defines six official design principles, including reducing downstream impact; this five-part guide is a practical summary, not a complete restatement of that framework. Read the AWS design principles.

  1. Assess impact: Define the workload boundary and gather operational signals and AWS emissions estimates.
  2. Set sustainability goals: Establish measurable targets against a representative baseline and preserve service objectives.
  3. Optimize resource use: Right-size capacity and remove idle resources without sacrificing required headroom.
  4. Evaluate newer technologies: Test hardware, software, service, and Region choices against the workload.
  5. Manage services and data deliberately: Align services, retention, and data movement with access, recovery, and downstream needs.

1. Assess your impact

Start with a workload boundary: identify the application, AWS accounts and Regions it uses, the business output it delivers, and the performance and reliability targets it must meet. Record resource use alongside output, such as successful requests, completed jobs, or active users. CloudWatch can collect service metrics and application metrics you publish, but a CPU or request count is not a direct measurement of energy use or carbon emissions. CloudWatch metrics documentation.

For AWS-level emissions estimates, use the AWS Sustainability service. It reports estimated emissions associated with AWS usage using both market-based and location-based methods, with views by month, Region, service, and emissions Scope 1, 2, and 3. The standalone service is available globally through the console, with emissions data for all AWS commercial Regions. AWS’s launch and availability details. AWS deprecated the Customer Carbon Footprint Tool on June 30, 2026, in favor of AWS Sustainability. AWS’s deprecation notice.

The estimates are useful for tracking an organization’s AWS footprint, but they do not assign an exact measured footprint to each request or application. The console currently breaks out EC2, S3, and CloudFront; other AWS products appear as “Other.” Carbon data is published monthly by the 21st for the previous usage month, and AWS may recalculate historical estimates when it updates its methodology. Keep an export and note the methodology version when you need reproducible comparisons. AWS Sustainability data and methodology notes · data timing and exports.

2. Set sustainability goals

Set a baseline over a representative period, then choose a measurable improvement that does not weaken the workload’s service targets. Useful intensity measures include vCPU-seconds per 1,000 successful requests, compute-hours per completed batch, or storage retained per active customer. Pair the intensity measure with an absolute resource or emissions measure: efficiency per request can improve while total impact still grows as usage expands.

Key strategies for implementation

  • Define what counts: Choose the workload boundary, business output, time period, and sources included in the baseline.
  • Set a specific target: Name the metric, target date, owner, and the latency, availability, security, and recovery limits that must hold.
  • Compare like with like: Account for traffic volume, seasonality, data retained, and architectural changes when comparing periods.
  • Test one change at a time: Benchmark a representative workload before making a broad rollout.

Monitoring and adjusting goals

Review workload-level efficiency after meaningful releases and on a regular operating cadence. Use CloudWatch and application telemetry for performance and resource trends; use AWS Sustainability estimates for the broader AWS emissions view. These data sources have different granularity, so do not present an account-level monthly estimate as a per-request measurement.

3. Optimize resource use

Find the components that consume the most resources, then reduce waste without compromising the workload’s service objectives. Review representative peak and off-peak periods, not just an average that can hide bursts or idle capacity.

Instance right-sizing

For EC2, compare CPU, memory where instrumented, storage, network, queue depth, throughput, latency, and errors over the workload’s full demand cycle. Resize or change instance families only after testing the candidate against the same workload and its service limits. For a load-test and before-and-after comparison workflow, see our AWS performance benchmarking guide.

Aim for resources to do useful work, not for an arbitrary utilization percentage. Keep enough capacity for expected peaks, failures, and scale-out time. Monitor whether a change improves output per unit of resource while keeping latency and error rates within target.

Advanced resource management

Remove unattached or unused resources and retire workload components that no longer serve a business need. For development, testing, and flexible batch jobs, consider schedules, queues, or scale-to-zero designs when the workload can tolerate startup time and delay. Buffering or shifting work is suitable only when its freshness, deadline, and customer requirements allow it.

Monitoring and optimization

Compare a proposed change with a baseline under equivalent load. Track absolute resource use, resource use per unit of output, and the workload’s latency, availability, and error rates. Cost is useful operational evidence, but a lower bill alone does not prove that emissions fell.

4. Evaluate newer technologies

More efficient processors, runtimes, and service options can improve a workload, but the result depends on compatibility, demand, and measured performance. Treat vendor comparisons as a reason to test an option, not as a promised result for your application.

Include Region in the comparison. AWS recommends selecting Regions based on both business requirements and sustainability goals. First shortlist Regions that meet latency, data-residency, service-availability, and resilience requirements; then compare the emissions estimates and accounting method relevant to your organization. A distant Region can add latency or data movement, so do not choose one on a sustainability signal alone. AWS Region selection guidance.

Custom hardware advancements

AWS says Graviton-based EC2 instances can use up to 60% less energy than comparable EC2 instances for the same performance. That is an AWS-reported maximum for comparable instances, not a guaranteed reduction in your workload’s energy use or AWS emissions estimate. Check operating-system, runtime, library, and licensing support, then benchmark equivalent throughput and latency before migrating. AWS Graviton details.

Understand the shared responsibility boundary

AWS operates and improves the infrastructure, facilities, and energy procurement behind the cloud. Customers influence the resources their workloads require through software, architecture, Region, and service choices. Focus customer actions on that workload boundary; facility cooling and data-center power usage are not settings that customers can tune. AWS’s shared responsibility guidance.

Use services that fit the workload

Serverless and managed services can help with variable or intermittent demand and can shift infrastructure operations to AWS. They do not eliminate resource use, and they are not automatically more efficient for every workload. Compare cold-start and latency needs, steady-state utilization, scaling limits, data transfer, and service charges before switching.

Track and adopt changes carefully

Use recommendations from tools such as AWS Compute Optimizer as candidates for evaluation. Test them with representative production-like traffic, preserve rollback options, and measure the same performance and resource indicators before and after. Keep an eye on AWS service and instance updates, but adopt them when the evidence fits your workload.

5. Manage services and data deliberately

Resource optimization through shared infrastructure

AWS’s Sustainability Pillar notes that managed services can benefit from provider-scale operation and shared infrastructure. A managed database, container platform, or serverless service may reduce the infrastructure your team maintains, but selection should still be based on workload requirements and measured results. Managed services do not guarantee lower emissions for every use case.

Automated resource management

Configure scaling and scheduling around observed demand. Set safe minimum and maximum capacity, scaling thresholds, and recovery behavior; account for warm capacity where startup time or sudden demand requires it. Check that automation actually removes idle resources and maintains the required availability and response time.

Data lifecycle and storage choices

Classify data by access frequency, retrieval time, resilience, and retention requirements. Use S3 Lifecycle to transition data when its access pattern changes and expire it only after its business, legal, and recovery retention period ends. A lower storage rate can come with transition, retrieval, restore, or minimum-duration costs, so evaluate the complete lifecycle before changing classes. S3 Lifecycle guidance · S3 storage class trade-offs.

Also review duplicate datasets, backups, replicas, and unnecessary data movement. Keep the copies required for durability, recovery, and compliance; remove only those that no longer serve a defined need.

Consider downstream impact

Efficiency includes the resources needed by people and devices that use your service. Reduce unnecessary data returned to clients, avoid work that does not change the result, and test that user-facing performance improvements do not require avoidable device upgrades. These practices address the downstream impact principle in the AWS framework.

Conclusion

Build sustainability work around measured workload efficiency, not a promised percentage reduction. Establish a baseline, identify the largest resource demands, test a targeted change, and verify its effect on both resource use and service quality. Revisit the results as workload demand, AWS services, and the emissions methodology change.

A useful review pairs three views: estimated AWS emissions over time, workload resources per unit of useful output, and absolute workload demand. Together they help you see whether an architecture change improved efficiency, kept required service levels, and changed the broader footprint in the direction you intended.

FAQs

Does lowering AWS costs always reduce emissions?

No. Cost is only a proxy for resource use: prices, discounts, and billing choices can change without changing the resources a workload consumes. To assess efficiency, compare usage evidence such as compute time, storage, and data movement per unit of successful work, alongside the workload’s performance and reliability targets. Use AWS Sustainability estimates to follow broader emissions trends, but do not treat a lower bill alone as evidence of lower emissions.