

# Sustainability
<a name="a-sustainability"></a>

The Sustainability pillar includes understanding the impacts of the services used, quantifying impacts through the entire workload lifecycle, and applying design principles and best practices to reduce these impacts when building cloud workloads. You can find prescriptive guidance on implementation in the [Sustainability Pillar whitepaper](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp).

**Topics**
+ [Region selection](a-region-selection.md)
+ [Alignment to demand](a-alignment-to-demand.md)
+ [Software and architecture](a-sus-software-architecture.md)
+ [Data](a-sus-data.md)
+ [Hardware and services](a-sus-hardware-and-services.md)
+ [Process and culture](a-sus-process-and-culture.md)

# Region selection
<a name="a-region-selection"></a>

**Topics**
+ [SUS 1 How do you select Regions for your workload?](w2aac19c17b7b5.md)

# SUS 1 How do you select Regions for your workload?
<a name="w2aac19c17b7b5"></a>

The choice of Region for your workload significantly affects its KPIs, including performance, cost, and carbon footprint. To effectively improve these KPIs, you should choose Regions for your workloads based on both business requirements and sustainability goals.

**Topics**
+ [SUS01-BP01 Choose Region based on both business requirements and sustainability goals](sus_sus_region_a2.md)

# SUS01-BP01 Choose Region based on both business requirements and sustainability goals
<a name="sus_sus_region_a2"></a>

Choose a Region for your workload based on both your business requirements and sustainability goals to optimize its KPIs, including performance, cost, and carbon footprint.

 **Common anti-patterns:** 
+  You select the workload’s Region based on your own location. 
+  You consolidate all workload resources into one geographic location. 

 **Benefits of establishing this best practice:** Placing a workload close to Amazon renewable energy projects or Regions with low published carbon intensity can help to lower the carbon footprint of a cloud workload. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

The AWS Cloud is a constantly expanding network of Regions and points of presence (PoP), with a global network infrastructure linking them together. The choice of Region for your workload significantly affects its KPIs, including performance, cost, and carbon footprint. To effectively improve these KPIs, you should choose Regions for your workload based on both your business requirements and sustainability goals.

 **Implementation steps** 
+  Follow these steps to assess and shortlist potential Regions for your workload based on your business requirements including compliance, available features, cost, and latency: 
  +  Confirm that these Regions are compliant, based on your required local regulations. 
  +  Use the [AWS Regional Services Lists](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) to check if the Regions have the services and features you need to run your workload. 
  +  Calculate the cost of the workload on each Region using the [AWS Pricing Calculator](https://calculator.aws/). 
  +  Test the network latency between your end user locations and each AWS Region. 
+  Choose Regions near Amazon renewable energy projects and Regions where the grid has a published carbon intensity that is lower than other locations (or Regions). 
  +  Identify your relevant sustainability guidelines to track and compare year-to-year carbon emissions based on [Greenhouse Gas Protocol](https://ghgprotocol.org/) (market-based and location based methods). 
  +  Choose region based on method you use to track carbon emissions. For more detail on choosing a Region based on your sustainability guidelines, see [How to select a Region for your workload based on sustainability goals](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/). 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Understanding your carbon emission estimations](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html) 
+  [Amazon Around the Globe](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true) 
+  [Renewable Energy Methodology](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology) 
+  [What to Consider when Selecting a Region for your Workloads](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/) 

 **Related videos:** 
+  [Architecting sustainably and reducing your AWS carbon footprint](https://www.youtube.com/watch?v=jsbamOLpCr8) 

# Alignment to demand
<a name="a-alignment-to-demand"></a>

**Topics**
+ [SUS 2 How do you align cloud resources to your demand?](sus-02.md)

# SUS 2 How do you align cloud resources to your demand?
<a name="sus-02"></a>

The way users and applications consume your workloads and other resources can help you identify improvements to meet sustainability goals. Scale infrastructure to continually match demand and verify that you use only the minimum resources required to support your users. Align service levels to customer needs. Position resources to limit the network required for users and applications to consume them. Remove unused assets. Provide your team members with devices that support their needs and minimize their sustainability impact.

**Topics**
+ [SUS02-BP01 Scale workload infrastructure dynamically](sus_sus_user_a2.md)
+ [SUS02-BP02 Align SLAs with sustainability goals](sus_sus_user_a3.md)
+ [SUS02-BP03 Stop the creation and maintenance of unused assets](sus_sus_user_a4.md)
+ [SUS02-BP04 Optimize geographic placement of workloads based on their networking requirements](sus_sus_user_a5.md)
+ [SUS02-BP05 Optimize team member resources for activities performed](sus_sus_user_a6.md)
+ [SUS02-BP06 Implement buffering or throttling to flatten the demand curve](sus_sus_user_a7.md)

# SUS02-BP01 Scale workload infrastructure dynamically
<a name="sus_sus_user_a2"></a>

Use elasticity of the cloud and scale your infrastructure dynamically to match supply of cloud resources to demand and avoid overprovisioned capacity in your workload.

**Common anti-patterns:**
+ You do not scale your infrastructure with user load.
+ You manually scale your infrastructure all the time.
+ You leave increased capacity after a scaling event instead of scaling back down.

 **Benefits of establishing this best practice:** Configuring and testing workload elasticity help to efficiently match supply of cloud resources to demand and avoid overprovisioned capacity. You can take advantage of elasticity in the cloud to automatically scale capacity during and after demand spikes to make sure you are only using the right number of resources needed to meet your business requirements.

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 The cloud provides the flexibility to expand or reduce your resources dynamically through a variety of mechanisms to meet changes in demand. Optimally matching supply to demand delivers the lowest environmental impact for a workload. 

 Demand can be fixed or variable, requiring metrics and automation to make sure that management does not become burdensome. Applications can scale vertically (up or down) by modifying the instance size, horizontally (in or out) by modifying the number of instances, or a combination of both. 

 You can use a number of different approaches to match supply of resources with demand. 
+  **Target-tracking approach:** Monitor your scaling metric and automatically increase or decrease capacity as you need it. 
+  **Predictive scaling:** Scale in anticipation of daily and weekly trends. 
+  **Schedule-based approach:** Set your own scaling schedule according to predictable load changes. 
+  **Service scaling:** Pick services (like serverless) that are natively scaling by design or provide auto scaling as a feature. 

 Identify periods of low or no utilization and scale resources to remove excess capacity and improve efficiency. 

## Implementation steps
<a name="implementation-steps"></a>
+ Elasticity matches the supply of resources you have against the demand for those resources. Instances, containers, and functions provide mechanisms for elasticity, either in combination with automatic scaling or as a feature of the service. AWS provides a range of auto scaling mechanisms to ensure that workloads can scale down quickly and easily during periods of low user load. Here are some examples of auto scaling mechanisms:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_user_a2.html)
+  Scaling is often discussed related to compute services like Amazon EC2 instances or AWS Lambda functions. Consider the configuration of non-compute services like [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) read and write capacity units or [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) shards to match the demand. 
+  Verify that the metrics for scaling up or down are validated against the type of workload being deployed. If you are deploying a video transcoding application, 100% CPU utilization is expected and should not be your primary metric. You can use a [customized metric](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (such as memory utilization) for your scaling policy if required. To choose the right metrics, consider the following guidance for Amazon EC2: 
  +  The metric should be a valid utilization metric and describe how busy an instance is. 
  +  The metric value must increase or decrease proportionally to the number of instances in the Auto Scaling group. 
+  Use [dynamic scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html) instead of [manual scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html) for your Auto Scaling group. We also recommend that you use [target tracking scaling policies](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) in your dynamic scaling. 
+  Verify that workload deployments can handle both scale-out and scale-in events. Create test scenarios for scale-in events to verify that the workload behaves as expected and does not affect the user experience (like losing sticky sessions). You can use [Activity history](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html) to verify a scaling activity for an Auto Scaling group. 
+  Evaluate your workload for predictable patterns and proactively scale as you anticipate predicted and planned changes in demand. With predictive scaling, you can eliminate the need to overprovision capacity. For more detail, see [Predictive Scaling with Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/). 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Getting Started with Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) 
+  [Predictive Scaling for EC2, Powered by Machine Learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/) 
+  [Analyze user behavior using Amazon OpenSearch Service, Amazon Data Firehose and Kibana](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/) 
+  [What is Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [Monitoring DB load with Performance Insights on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+  [Introducing Native Support for Predictive Scaling with Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/) 
+  [Introducing Karpenter - An Open-Source, High-Performance Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/) 
+  [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/) 

 **Related videos:** 
+  [Build a cost-, energy-, and resource-efficient compute environment](https://www.youtube.com/watch?v=8zsC5e1eLCg) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) 

 **Related examples:** 
+  [Lab: Amazon EC2 Auto Scaling Group Examples](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) 
+  [Lab: Implement Autoscaling with Karpenter](https://www.eksworkshop.com/beginner/085_scaling_karpenter/) 

# SUS02-BP02 Align SLAs with sustainability goals
<a name="sus_sus_user_a3"></a>

 Review and optimize workload service-level agreements (SLA) based on your sustainability goals to minimize the resources required to support your workload while continuing to meet business needs. 

 **Common anti-patterns:** 
+  Workload SLAs are unknown or ambiguous. 
+  You define your SLA just for availability and performance. 
+  You use the same design pattern (like Multi-AZ architecture) for all your workloads. 

 **Benefits of establishing this best practice:** Aligning SLAs with sustainability goals leads to optimal resource usage while meeting business needs. 

 **Level of risk exposed if this best practice is not established:** Low 

## Implementation guidance
<a name="implementation-guidance"></a>

 SLAs define the level of service expected from a cloud workload, such as response time, availability, and data retention. They influence the architecture, resource usage, and environmental impact of a cloud workload. At a regular cadence, review SLAs and make trade-offs that significantly reduce resource usage in exchange for acceptable decreases in service levels. 

 **Implementation steps** 
+  Define or redesign SLAs that support your sustainability goals while meeting your business requirements, not exceeding them. 
+  Make trade-offs that significantly reduce sustainability impacts in exchange for acceptable decreases in service levels. 
  +  **Sustainability and reliability:** Highly available workloads tend to consume more resources. 
  +  **Sustainability and performance:** Using more resources to boost performance could have a higher environmental impact. 
  +  **Sustainability and security:** Overly secure workloads could have a higher environmental impact. 
+  Use design patterns such as [microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html) that prioritize business-critical functions and allow lower service levels (such as response time or recovery time objectives) for non-critical functions. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [AWS Service Level Agreements (SLAs)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all) 
+  [Importance of Service Level Agreement for SaaS Providers](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/) 

 **Related videos:** 
+ [ Delivering sustainable, high-performing architectures ](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [ Build a cost-, energy-, and resource-efficient compute environment ](https://www.youtube.com/watch?v=8zsC5e1eLCg)

# SUS02-BP03 Stop the creation and maintenance of unused assets
<a name="sus_sus_user_a4"></a>

Decommission unused assets in your workload to reduce the number of cloud resources required to support your demand and minimize waste.

 **Common anti-patterns:** 
+  You do not analyze your application for assets that are redundant or no longer required. 
+  You do not remove assets that are redundant or no longer required. 

 **Benefits of establishing this best practice:** Removing unused assets frees resources and improves the overall efficiency of the workload. 

 **Level of risk exposed if this best practice is not established:** Low 

## Implementation guidance
<a name="implementation-guidance"></a>

 Unused assets consume cloud resources like storage space and compute power. By identifying and eliminating these assets, you can free up these resources, resulting in a more efficient cloud architecture. Perform regular analysis on application assets such as pre-compiled reports, datasets, static images, and asset access patterns to identify redundancy, underutilization, and potential decommission targets. Remove those redundant assets to reduce the resource waste in your workload. 

 **Implementation steps** 
+  Use monitoring tools to identify static assets that are no longer required. 
+  Before removing any asset, evaluate the impact of removing it on the architecture. 
+  Develop a plan and remove assets that are no longer required. 
+  Consolidate overlapping generated assets to remove redundant processing. 
+  Update your applications to no longer produce and store assets that are not required. 
+  Instruct third parties to stop producing and storing assets managed on your behalf that are no longer required. 
+  Instruct third parties to consolidate redundant assets produced on your behalf. 
+  Regularly review your workload to identify and remove unused assets. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Optimizing your AWS Infrastructure for Sustainability, Part II: Storage](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/) 
+ [ How do I terminate active resources that I no longer need on my AWS account? ](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)

 **Related videos:** 
+ [ How do I check for and then remove active resources that I no longer need on my AWS account? ](https://www.youtube.com/watch?v=pqg9AqESRlg)

# SUS02-BP04 Optimize geographic placement of workloads based on their networking requirements
<a name="sus_sus_user_a5"></a>


|  | 
| --- |
| This best practice was updated with new guidance on July 13th, 2023. | 

Select cloud location and services for your workload that reduce the distance network traffic must travel and decrease the total network resources required to support your workload.

 ** Common anti-patterns: ** 
+  You select the workload's Region based on your own location. 
+  You consolidate all workload resources into one geographic location. 
+  All traffic flows through your existing data centers. 

 **Benefits of establishing this best practice:** Placing a workload close to its users provides the lowest latency while decreasing data movement across the network and reducing environmental impact. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 The AWS Cloud infrastructure is built around location options such as Regions, Availability Zones, placement groups, and edge locations such as [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) and [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). These location options are responsible for maintaining connectivity between application components, cloud services, edge networks and on-premises data centers. 

 Analyze the network access patterns in your workload to identify how to use these cloud location options and reduce the distance network traffic must travel. 

## Implementation steps
<a name="implementation-steps"></a>
+  Analyze network access patterns in your workload to identify how users use your application. 
  +  Use monitoring tools, such as [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) and [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), to gather data on network activities. 
  +  Analyze the data to identify the network access pattern. 
+  Select the Regions for your workload deployment based on the following key elements: 
  +  **Your Sustainability goal:** as explained in [Region selection](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html). 
  +  **Where your data is located:** For data-heavy applications (such as big data and machine learning), application code should run as close to the data as possible. 
  +  **Where your users are located:** For user-facing applications, choose a Region (or Regions) close to your workload’s users.
  + **Other constraints:** Consider constraints such as cost and compliance as explained in [What to Consider when Selecting a Region for your Workloads](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/).
+  Use local caching or [AWS Caching Solutions](https://aws.amazon.com/caching/aws-caching/) for frequently used assets to improve performance, reduce data movement, and lower environmental impact.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_user_a5.html)
+  Use services that can help you run code closer to users of your workload:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_user_a5.html)
+  Use connection pooling to allow for connection reuse and reduce required resources. 
+  Use distributed data stores that don’t rely on persistent connections and synchronous updates for consistency to serve regional populations. 
+  Replace pre-provisioned static network capacity with shared dynamic capacity, and share the sustainability impact of network capacity with other subscribers. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/) 
+  [Amazon ElastiCache Documentation](https://docs.aws.amazon.com/elasticache/index.html) 
+  [What is Amazon CloudFront?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
+  [Amazon CloudFront Key Features](https://aws.amazon.com/cloudfront/features/) 

 **Related videos:** 
+  [Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA) 
+ [ Scaling network performance on next-gen Amazon EC2 instances ](https://www.youtube.com/watch?v=jNYpWa7gf1A)

 **Related examples:** 
+  [AWS Networking Workshops](https://catalog.workshops.aws/networking/en-US) 
+ [ Architecting for sustainability - Minimize data movement across networks ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)

# SUS02-BP05 Optimize team member resources for activities performed
<a name="sus_sus_user_a6"></a>

Optimize resources provided to team members to minimize the environmental sustainability impact while supporting their needs. 

 **Common anti-patterns:** 
+  You ignore the impact of devices used by your team members on the overall efficiency of your cloud application. 
+  You manually manage and update resources used by team members. 

 **Benefits of establishing this best practice:** Optimizing team member resources improves the overall efficiency of cloud-enabled applications. 

 **Level of risk exposed if this best practice is not established:** Low 

## Implementation guidance
<a name="implementation-guidance"></a>

 Understand the resources your team members use to consume your services, their expected lifecycle, and the financial and sustainability impact. Implement strategies to optimize these resources. For example, perform complex operations, such as rendering and compilation, on highly utilized scalable infrastructure instead of on underutilized high-powered single-user systems. 

 **Implementation steps** 
+  Provision workstations and other devices to align with how they’re used. 
+  Use virtual desktops and application streaming to limit upgrade and device requirements. 
+  Move processor or memory-intensive tasks to the cloud to use its elasticity. 
+  Evaluate the impact of processes and systems on your device lifecycle, and select solutions that minimize the requirement for device replacement while satisfying business requirements. 
+  Implement remote management for devices to reduce required business travel. 
  +  [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html) is a unified user interface (UI) experience that helps you remotely manage your nodes running on AWS or on premises. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [What is Amazon WorkSpaces?](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html) 
+ [ Cost Optimizer for Amazon WorkSpaces ](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+  [Amazon AppStream 2.0 Documentation](https://docs.aws.amazon.com/appstream2/) 
+  [NICE DCV](https://docs.aws.amazon.com/dcv/) 

 **Related videos:** 
+  [Managing cost for Amazon WorkSpaces on AWS](https://www.youtube.com/watch?v=0MoY31hZQuE) 

# SUS02-BP06 Implement buffering or throttling to flatten the demand curve
<a name="sus_sus_user_a7"></a>

Buffering and throttling flatten the demand curve and reduce the provisioned capacity required for your workload. 

 **Common anti-patterns:** 
+ You process the client requests immediately while it is not needed.
+ You do not analyze the requirements for client requests.

 **Benefits of establishing this best practice:** Flattening the demand curve reduce the required provisioned capacity for the workload. Reducing the provisioned capacity means less energy consumption and less environmental impact. 

 **Level of risk exposed if this best practice is not established:** Low 

## Implementation guidance
<a name="implementation-guidance"></a>

 Flattening the workload demand curve can help you to reduce the provisioned capacity for a workload and reduce its environmental impact. Assume a workload with the demand curve shown in below figure. This workload has two peaks, and to handle those peaks, the resource capacity as shown by orange line is provisioned. The resources and energy used for this workload is not indicated by the area under the demand curve, but the area under the provisioned capacity line, as provisioned capacity is needed to handle those two peaks. 

![\[Provisioned capacity waveform with two distinct peaks that require high provisioned capacity.\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/images/provisioned-capacity-1.png)


 

 You can use buffering or throttling to modify the demand curve and smooth out the peaks, which means less provisioned capacity and less energy consumed. Implement throttling when your clients can perform retries. Implement buffering to store the request and defer processing until a later time. 

![\[Waveform diagram displaying a workload with smoothed-out peaks created using buffering or throttling.\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/images/provisioned-capacity-2.png)


 

 **Implementation steps** 
+  Analyze the client requests to determine how to respond to them. Questions to consider include: 
  +  Can this request be processed asynchronously? 
  +  Does the client have retry capability? 
+  If the client has retry capability, then you can implement throttling, which tells the source that if it cannot service the request at the current time, it should try again later. 
  +  You can use [Amazon API Gateway](https://aws.amazon.com/api-gateway/) to implement throttling. 
+  For clients that cannot perform retries, a buffer needs to be implemented to flatten the demand curve. A buffer defers request processing, allowing applications that run at different rates to communicate effectively. A buffer-based approach uses a queue or a stream to accept messages from producers. Messages are read by consumers and processed, allowing the messages to run at the rate that meets the consumers’ business requirements. 
  +  [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) is a managed service that provides queues that allow a single consumer to read individual messages. 
  +  [Amazon Kinesis](https://aws.amazon.com/kinesis/) provides a stream that allows many consumers to read the same messages. 
+  Analyze the overall demand, rate of change, and required response time to right size the throttle or buffer required. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+ [ Getting started with Amazon SQS ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [ Application integration Using Queues and Messages ](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)

 **Related videos:** 
+ [ Choosing the Right Messaging Service for Your Distributed App ](https://www.youtube.com/watch?v=4-JmX6MIDDI)

# Software and architecture
<a name="a-sus-software-architecture"></a>

**Topics**
+ [SUS 3 How do you take advantage of software and architecture patterns to support your sustainability goals?](sus-03.md)

# SUS 3 How do you take advantage of software and architecture patterns to support your sustainability goals?
<a name="sus-03"></a>

Implement patterns for performing load smoothing and maintaining consistent high utilization of deployed resources to minimize the resources consumed. Components might become idle from lack of use because of changes in user behavior over time. Revise patterns and architecture to consolidate under-utilized components to increase overall utilization. Retire components that are no longer required. Understand the performance of your workload components, and optimize the components that consume the most resources. Be aware of the devices that your customers use to access your services, and implement patterns to minimize the need for device upgrades. 

**Topics**
+ [SUS03-BP01 Optimize software and architecture for asynchronous and scheduled jobs](sus_sus_software_a2.md)
+ [SUS03-BP02 Remove or refactor workload components with low or no use](sus_sus_software_a3.md)
+ [SUS03-BP03 Optimize areas of code that consume the most time or resources](sus_sus_software_a4.md)
+ [SUS03-BP04 Optimize impact on devices and equipment](sus_sus_software_a5.md)
+ [SUS03-BP05 Use software patterns and architectures that best support data access and storage patterns](sus_sus_software_a6.md)

# SUS03-BP01 Optimize software and architecture for asynchronous and scheduled jobs
<a name="sus_sus_software_a2"></a>

Use efficient software and architecture patterns such as queue-driven to maintain consistent high utilization of deployed resources.

 **Common anti-patterns:** 
+  You overprovision the resources in your cloud workload to meet unforeseen spikes in demand. 
+  Your architecture does not decouple senders and receivers of asynchronous messages by a messaging component. 

 **Benefits of establishing this best practice:** 
+  Efficient software and architecture patterns minimize the unused resources in your workload and improve the overall efficiency. 
+  You can scale the processing independently of the receiving of asynchronous messages. 
+  Through a messaging component, you have relaxed availability requirements that you can meet with fewer resources. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Use efficient architecture patterns such as [event-driven architecture](https://aws.amazon.com/event-driven-architecture/) that result in even utilization of components and minimize overprovisioning in your workload. Using efficient architecture patterns minimizes idle resources from lack of use due to changes in demand over time. 

 Understand the requirements of your workload components and adopt architecture patterns that increase overall utilization of resources. Retire components that are no longer required. 

 **Implementation steps** 
+  Analyze the demand for your workload to determine how to respond to those. 
+  For requests or jobs that don’t require synchronous responses, use queue-driven architectures and auto scaling workers to maximize utilization. Here are some examples of when you might consider queue-driven architecture:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_software_a2.html)
+  For requests or jobs that can be processed anytime, use scheduling mechanisms to process jobs in batch for more efficiency. Here are some examples of scheduling mechanisms on AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_software_a2.html)
+  If you use polling and webhooks mechanisms in your architecture, replace those with events. Use [event-driven architectures](https://docs.aws.amazon.com/lambda/latest/operatorguide/event-driven-architectures.html) to build highly efficient workloads. 
+  Leverage [serverless on AWS](https://aws.amazon.com/serverless/) to eliminate over-provisioned infrastructure. 
+  Right size individual components of your architecture to prevent idling resources waiting for input. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [What is Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) 
+  [What is Amazon MQ?](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) 
+  [Scaling based on Amazon SQS](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html) 
+  [What is AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [What is AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
+  [Using AWS Lambda with Amazon SQS](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html) 
+  [What is Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 

 **Related videos:** 
+  [Moving to event-driven architectures](https://www.youtube.com/watch?v=h46IquqjF3E) 

# SUS03-BP02 Remove or refactor workload components with low or no use
<a name="sus_sus_software_a3"></a>

Remove components that are unused and no longer required, and refactor components with little utilization to minimize waste in your workload.

 **Common anti-patterns:** 
+  You do not regularly check the utilization level of individual components of your workload. 
+  You do not check and analyze recommendations from AWS rightsizing tools such as [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/). 

 **Benefits of establishing this best practice:** Removing unused components minimizes waste and improves the overall efficiency of your cloud workload. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Review your workload to identify idle or unused components. This is an iterative improvement process which can be initiated by changes in demand or the release of a new cloud service. For example, a significant drop in [AWS Lambda](https://docs.aws.amazon.com/lambda/) function run time can be an indicator of a need to lower the memory size. Also, as AWS releases new services and features, the optimal services and architecture for your workload may change. 

 Continually monitor workload activity and look for opportunities to improve the utilization level of individual components. By removing idle components and performing rightsizing activities, you meet your business requirements with the fewest cloud resources. 

 **Implementation steps** 
+  Monitor and capture the utilization metrics for critical components of your workload (like CPU utilization, memory utilization, or network throughput in [Amazon CloudWatch metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)). 
+  For stable workloads, check AWS rightsizing tools such as [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) at regular intervals to identify idle, unused, or underutilized components. 
+  For ephemeral workloads, evaluate utilization metrics to identify idle, unused, or underutilized components. 
+  Retire components and associated assets (like Amazon ECR images) that are no longer needed. 
+  Refactor or consolidate underutilized components with other resources to improve utilization efficiency. For example, you can provision multiple small databases on a single [Amazon RDS](https://aws.amazon.com/rds/) database instance instead of running databases on individual under-utilized instances. 
+  Understand the [resources provisioned by your workload to complete a unit of work](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html). 

## Resources
<a name="resources"></a>

 **Related documents:** 
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+  [What is Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
+  [Automated Cleanup of Unused Images in Amazon ECR](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/) 

 **Related examples:** 
+ [ Well-Architected Lab - Rightsizing with AWS Compute Optimizer](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [ Well-Architected Lab - Optimize Hardware Patterns and Observe Sustainability KPIs ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)

# SUS03-BP03 Optimize areas of code that consume the most time or resources
<a name="sus_sus_software_a4"></a>


|  | 
| --- |
| This best practice was updated with new guidance on July 13th, 2023. | 

Optimize your code that runs within different components of your architecture to minimize resource usage while maximizing performance.

 **Common anti-patterns:** 
+  You ignore optimizing your code for resource usage. 
+  You usually respond to performance issues by increasing the resources. 
+  Your code review and development process does not track performance changes. 

 **Benefits of establishing this best practice:** Using efficient code minimizes resource usage and improves performance. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 It is crucial to examine every functional area, including the code for a cloud architected application, to optimize its resource usage and performance. Continually monitor your workload’s performance in build environments and production and identify opportunities to improve code snippets that have particularly high resource usage. Adopt a regular review process to identify bugs or anti-patterns within your code that use resources inefficiently. Leverage simple and efficient algorithms that produce the same results for your use case. 

## Implementation steps
<a name="implementation-steps"></a>
+  While developing your workloads, adopt an automated code review process to improve quality and identify bugs and anti-patterns. 
  + [ Automate code reviews with Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
  + [ Detecting concurrency bugs with Amazon CodeGuru ](https://aws.amazon.com/blogs/devops/detecting-concurrency-bugs-with-amazon-codeguru/)
  + [ Raising code quality for Python applications using Amazon CodeGuru ](https://aws.amazon.com/blogs/devops/raising-code-quality-for-python-applications-using-amazon-codeguru/)
+  As you run your workloads, monitor resources to identify components with high resource requirements per unit of work as targets for code reviews. 
+  For code reviews, use a code profiler to identify the areas of code that use the most time or resources as targets for optimization. 
  + [ Reducing your organization's carbon footprint with Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/reducing-your-organizations-carbon-footprint-with-codeguru-profiler/)
  + [ Understanding memory usage in your Java application with Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/understanding-memory-usage-in-your-java-application-with-amazon-codeguru-profiler/)
  + [ Improving customer experience and reducing cost with Amazon CodeGuru Profiler ](https://aws.amazon.com/blogs/devops/improving-customer-experience-and-reducing-cost-with-codeguru-profiler/)
+  Use the most efficient operating system and programming language for the workload. For details on energy efficient programming languages (including Rust), see [Sustainability with Rust](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/). 
+  Replace computationally intensive algorithms with simpler and more efficient version that produce the same result. 
+  Remove unnecessary code such as sorting and formatting. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [What is Amazon CodeGuru Profiler?](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) 
+  [FPGA instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html) 
+  [The AWS SDKs on Tools to Build on AWS](https://aws.amazon.com/tools/) 

 **Related videos:** 
+ [ Improve Code Efficiency Using Amazon CodeGuru Profiler ](https://www.youtube.com/watch?v=1pU4VddsBRw)
+ [ Automate Code Reviews and Application Performance Recommendations with Amazon CodeGuru ](https://www.youtube.com/watch?v=OD8H63C0E0I)

# SUS03-BP04 Optimize impact on devices and equipment
<a name="sus_sus_software_a5"></a>

Understand the devices and equipment used in your architecture and use strategies to reduce their usage. This can minimize the overall environmental impact of your cloud workload. 

 **Common anti-patterns:** 
+  You ignore the environmental impact of devices used by your customers. 
+  You manually manage and update resources used by customers. 

 **Benefits of establishing this best practice:** Implementing software patterns and features that are optimized for customer device can reduce the overall environmental impact of cloud workload. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Implementing software patterns and features that are optimized for customer devices can reduce the environmental impact in several ways: 
+  Implementing new features that are backward compatible can reduce the number of hardware replacements. 
+  Optimizing an application to run efficiently on devices can help to reduce their energy consumption and extend their battery life (if they are powered by battery). 
+  Optimizing an application for devices can also reduce the data transfer over the network. 

 Understand the devices and equipment used in your architecture, their expected lifecycle, and the impact of replacing those components. Implement software patterns and features that can help to minimize the device energy consumption, the need for customers to replace the device and also upgrade it manually. 

 **Implementation steps** 
+  Inventory the devices used in your architecture. Devices can be mobile, tablet, IOT devices, smart light, or even smart devices in a factory. 
+  Optimize the application running on the devices: 
  +  Use strategies such as running tasks in the background to reduce their energy consumption. 
  +  Account for network bandwidth and latency when building payloads, and implement capabilities that help your applications work well on low bandwidth, high latency links. 
  +  Convert payloads and files into optimized formats required by devices. For example, you can use [Amazon Elastic Transcoder](https://docs.aws.amazon.com/elastic-transcoder/) or [AWS Elemental MediaConvert](https://aws.amazon.com/mediaconvert/) to convert large, high quality digital media files into formats that users can play back on mobile devices, tablets, web browsers, and connected televisions. 
  +  Perform computationally intense activities server-side (such as image rendering), or use application streaming to improve the user experience on older devices. 
  +  Segment and paginate output, especially for interactive sessions, to manage payloads and limit local storage requirements. 
+  Use automated over-the-air (OTA) mechanism to deploy updates to one or more devices. 
  +  You can use a [CI/CD pipeline](https://aws.amazon.com/blogs/mobile/build-a-cicd-pipeline-for-your-android-app-with-aws-services/) to update mobile applications. 
  +  You can use [AWS IoT Device Management](https://aws.amazon.com/iot-device-management/) to remotely manage connected devices at scale. 
+  To test new features and updates, use managed device farms with representative sets of hardware and iterate development to maximize the devices supported. For more details, see [SUS06-BP04 Use managed device farms for testing](sus_sus_dev_a5.md). 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [What is AWS Device Farm?](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) 
+  [Amazon AppStream 2.0 Documentation](https://docs.aws.amazon.com/appstream2/) 
+  [NICE DCV](https://docs.aws.amazon.com/dcv/) 
+ [ OTA tutorial for updating firmware on devices running FreeRTOS ](https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-ota-workflow.html)

 **Related videos:** 
+ [ Introduction to AWS Device Farm](https://www.youtube.com/watch?v=UiJo_PEZkD4)

# SUS03-BP05 Use software patterns and architectures that best support data access and storage patterns
<a name="sus_sus_software_a6"></a>

Understand how data is used within your workload, consumed by your users, transferred, and stored. Use software patterns and architectures that best support data access and storage to minimize the compute, networking, and storage resources required to support the workload.

 **Common anti-patterns:** 
+  You assume that all workloads have similar data storage and access patterns. 
+  You only use one tier of storage, assuming all workloads fit within that tier. 
+  You assume that data access patterns will stay consistent over time. 
+  Your architecture supports a potential high data access burst, which results in the resources remaining idle most of the time. 

 **Benefits of establishing this best practice:** Selecting and optimizing your architecture based on data access and storage patterns will help decrease development complexity and increase overall utilization. Understanding when to use global tables, data partitioning, and caching will help you decrease operational overhead and scale based on your workload needs. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Use software and architecture patterns that aligns best to your data characteristics and access patterns. For example, use [modern data architecture on AWS](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/) that allows you to use purpose-built services optimized for your unique analytics use cases. These architecture patterns allow for efficient data processing and reduce the resource usage. 

 **Implementation steps** 
+  Analyze your data characteristics and access patterns to identify the correct configuration for your cloud resources. Key characteristics to consider include: 
  +  **Data type:** structured, semi-structured, unstructured 
  +  **Data growth:** bounded, unbounded 
  +  **Data durability:** persistent, ephemeral, transient 
  +  **Access patterns** reads or writes, update frequency, spiky, or consistent 
+  Use architecture patterns that best support data access and storage patterns. 
  + [ Let’s Architect\$1 Modern data architectures ](https://aws.amazon.com/blogs/architecture/lets-architect-modern-data-architectures/)
  + [ Databases on AWS: The Right Tool for the Right Job ](https://www.youtube.com/watch?v=-pb-DkD6cWg)
+  Use technologies that work natively with compressed data. 
+  Use purpose-built [analytics services](https://aws.amazon.com/big-data/datalakes-and-analytics/?nc2=h_ql_prod_an_a) for data processing in your architecture. 
+  Use the database engine that best supports your dominant query pattern. Manage your database indexes to ensure efficient querying. For further details, see [AWS Databases](https://aws.amazon.com/products/databases/). 
+  Select network protocols that reduce the amount of network capacity consumed in your architecture. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Athena Compression Support file formats](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html) 
+  [COPY from columnar data formats with Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html) 
+  [Converting Your Input Record Format in Firehose](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) 
+  [Format Options for ETL Inputs and Outputs in AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html) 
+  [Improve query performance on Amazon Athena by Converting to Columnar Formats](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html) 
+  [Loading compressed data files from Amazon S3 with Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html) 
+  [Monitoring DB load with Performance Insights on Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html) 
+  [Monitoring DB load with Performance Insights on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 
+ [ Amazon S3 Intelligent-Tiering storage class ](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/)

 **Related videos:** 
+ [ Building modern data architectures on AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)

# Data
<a name="a-sus-data"></a>

**Topics**
+ [SUS 4 How do you take advantage of data management policies and patterns to support your sustainability goals?](sus-04.md)

# SUS 4 How do you take advantage of data management policies and patterns to support your sustainability goals?
<a name="sus-04"></a>

Implement data management practices to reduce the provisioned storage required to support your workload, and the resources required to use it. Understand your data, and use storage technologies and configurations that more effectively support the business value of the data and how it’s used. Lifecycle data to more efficient, less performant storage when requirements decrease, and delete data that’s no longer required. 

**Topics**
+ [SUS04-BP01 Implement a data classification policy](sus_sus_data_a2.md)
+ [SUS04-BP02 Use technologies that support data access and storage patterns](sus_sus_data_a3.md)
+ [SUS04-BP03 Use policies to manage the lifecycle of your datasets](sus_sus_data_a4.md)
+ [SUS04-BP04 Use elasticity and automation to expand block storage or file system](sus_sus_data_a5.md)
+ [SUS04-BP05 Remove unneeded or redundant data](sus_sus_data_a6.md)
+ [SUS04-BP06 Use shared file systems or storage to access common data](sus_sus_data_a7.md)
+ [SUS04-BP07 Minimize data movement across networks](sus_sus_data_a8.md)
+ [SUS04-BP08 Back up data only when difficult to recreate](sus_sus_data_a9.md)

# SUS04-BP01 Implement a data classification policy
<a name="sus_sus_data_a2"></a>

Classify data to understand its criticality to business outcomes and choose the right energy-efficient storage tier to store the data.

 **Common anti-patterns:** 
+  You do not identify data assets with similar characteristics (such as sensitivity, business criticality, or regulatory requirements) that are being processed or stored. 
+  You have not implemented a data catalog to inventory your data assets. 

 **Benefits of establishing this best practice:** Implementing a data classification policy allows you to determine the most energy-efficient storage tier for data. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Data classification involves identifying the types of data that are being processed and stored in an information system owned or operated by an organization. It also involves making a determination on the criticality of the data and the likely impact of a data compromise, loss, or misuse. 

 Implement data classification policy by working backwards from the contextual use of the data and creating a categorization scheme that takes into account the level of criticality of a given dataset to an organization’s operations. 

 **Implementation steps** 
+  Conduct an inventory of the various data types that exist for your workload. 
  +  For more detail on data classification categories, see [Data Classification whitepaper](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html). 
+  Determine criticality, confidentiality, integrity, and availability of data based on risk to the organization. Use these requirements to group data into one of the data classification tiers that you adopt. 
  +  As an example, see [Four simple steps to classify your data and secure your startup](https://aws.amazon.com/blogs/startups/four-simple-steps-to-classify-your-data-and-secure-your-startup/). 
+  Periodically audit your environment for untagged and unclassified data, and classify and tag the data appropriately. 
  +  As an example, see [Data Catalog and crawlers in AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html). 
+  Establish a data catalog that provides audit and governance capabilities. 
+  Determine and document the handling procedures for each data class. 
+  Use automation to continually audit your environment to identify untagged and unclassified data, and classify and tag the data appropriately. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Leveraging AWS Cloud to Support Data Classification](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html) 
+  [Tag policies from AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) 

 **Related videos:** 
+ [ Enabling agility with data governance on AWS](https://www.youtube.com/watch?v=vznDgJkoH7k)

# SUS04-BP02 Use technologies that support data access and storage patterns
<a name="sus_sus_data_a3"></a>


|  | 
| --- |
| This best practice was updated with new guidance on July 13th, 2023. | 

 Use storage technologies that best support how your data is accessed and stored to minimize the resources provisioned while supporting your workload. 

 **Common anti-patterns:** 
+  You assume that all workloads have similar data storage and access patterns. 
+  You only use one tier of storage, assuming all workloads fit within that tier. 
+  You assume that data access patterns will stay consistent over time. 

 **Benefits of establishing this best practice:** Selecting and optimizing your storage technologies based on data access and storage patterns will help you reduce the required cloud resources to meet your business needs and improve the overall efficiency of cloud workload. 

 **Level of risk exposed if this best practice is not established:** Low 

## Implementation guidance
<a name="implementation-guidance"></a>

 Select the storage solution that aligns best to your access patterns, or consider changing your access patterns to align with the storage solution to maximize performance efficiency. 
+  Evaluate your data characteristics and access pattern to collect the key characteristics of your storage needs. Key characteristics to consider include: 
  +  **Data type:** structured, semi-structured, unstructured 
  +  **Data growth:** bounded, unbounded 
  +  **Data durability:** persistent, ephemeral, transient 
  +  **Access patterns:** reads or writes, frequency, spiky, or consistent 
+  Migrate data to the appropriate storage technology that supports your data characteristics and access pattern. Here are some examples of AWS storage technologies and their key characteristics:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_data_a3.html)
+  For storage systems that are a fixed size, such as Amazon EBS or Amazon FSx, monitor the available storage space and automate storage allocation on reaching a threshold. You can leverage Amazon CloudWatch to collect and analyze different metrics for [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html) and [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring-cloudwatch.html). 
+  Amazon S3 Storage Classes can be configured at the object level and a single bucket can contain objects stored across all of the storage classes. 
+  You can also use Amazon S3 Lifecycle policies to automatically transition objects between storage classes or remove data without any application changes. In general, you have to make a trade-off between resource efficiency, access latency, and reliability when considering these storage mechanisms. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Amazon EBS volume types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) 
+  [Amazon EC2 instance store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) 
+  [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html) 
+ [ Amazon EBS I/O Characteristics ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [ Using Amazon S3 storage classes ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+  [What is Amazon Glacier?](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html) 

 **Related videos:** 
+  [Architectural Patterns for Data Lakes on AWS](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents) 
+ [ Deep dive on Amazon EBS (STG303-R1) ](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [ Optimize your storage performance with Amazon S3 (STG343) ](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [ Building modern data architectures on AWS](https://www.youtube.com/watch?v=Uk2CqEt5f0o)

 **Related examples:** 
+ [ Amazon EFS CSI Driver ](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [ Amazon EBS CSI Driver ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [ Amazon EFS Utilities ](https://github.com/aws/efs-utils)
+ [ Amazon EBS Autoscale ](https://github.com/awslabs/amazon-ebs-autoscale)
+ [ Amazon S3 Examples ](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)

# SUS04-BP03 Use policies to manage the lifecycle of your datasets
<a name="sus_sus_data_a4"></a>

Manage the lifecycle of all of your data and automatically enforce deletion to minimize the total storage required for your workload.

 **Common anti-patterns:** 
+  You manually delete data. 
+  You do not delete any of your workload data. 
+  You do not move data to more energy-efficient storage tiers based on its retention and access requirements. 

 **Benefits of establishing this best practice:** Using data lifecycle policies ensures efficient data access and retention in a workload. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Datasets usually have different retention and access requirements during their lifecycle. For example, your application may need frequent access to some datasets for a limited period of time. After that, those datasets are infrequently accessed. 

 To efficiently manage your datasets throughout their lifecycle, configure lifecycle policies, which are rules that define how to handle datasets. 

 With Lifecycle configuration rules, you can tell the specific storage service to transition a dataset to more energy-efficient storage tiers, archive it, or delete it. 

 **Implementation steps** 
+  [Classify datasets in your workload.](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_data_a2.html) 
+  Define handling procedures for each data class. 
+  Set automated lifecycle policies to enforce lifecycle rules. Here are some examples of how to set up automated lifecycle policies for different AWS storage services:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_data_a4.html)
+  Delete unused volumes, snapshots, and data that is out of its retention period. Leverage native service features like Amazon DynamoDB Time To Live or Amazon CloudWatch log retention for deletion. 
+  Aggregate and compress data where applicable based on lifecycle rules. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Optimize your Amazon S3 Lifecycle rules with Amazon S3 Storage Class Analysis](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html) 
+  [Evaluating Resources with AWS Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 

 **Related videos:** 
+  [Simplify Your Data Lifecycle and Optimize Storage Costs With Amazon S3 Lifecycle](https://www.youtube.com/watch?v=53eHNSpaMJI) 
+ [ Reduce Your Storage Costs Using Amazon S3 Storage Lens ](https://www.youtube.com/watch?v=A8qOBLM6ITY)

# SUS04-BP04 Use elasticity and automation to expand block storage or file system
<a name="sus_sus_data_a5"></a>

Use elasticity and automation to expand block storage or file system as data grows to minimize the total provisioned storage.

 **Common anti-patterns:** 
+  You procure large block storage or file system for future need. 
+  You overprovision the input and output operations per second (IOPS) of your file system. 
+  You do not monitor the utilization of your data volumes. 

 **Benefits of establishing this best practice:** Minimizing over-provisioning for storage system reduces the idle resources and improves the overall efficiency of your workload. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Create block storage and file systems with size allocation, throughput, and latency that are appropriate for your workload. Use elasticity and automation to expand block storage or file system as data grows without having to over-provision these storage services. 

 **Implementation steps** 
+  For fixed size storage like [Amazon EBS](https://aws.amazon.com/ebs/), verify that you are monitoring the amount of storage used versus the overall storage size and create automation, if possible, to increase the storage size when reaching a threshold. 
+  Use elastic volumes and managed block data services to automate allocation of additional storage as your persistent data grows. As an example, you can use [Amazon EBS Elastic Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html) to change volume size, volume type, or adjust the performance of your Amazon EBS volumes. 
+  Choose the right storage class, performance mode, and throughput mode for your file system to address your business need, not exceeding that. 
  + [ Amazon EFS performance ](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
  + [ Amazon EBS volume performance on Linux instances ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html)
+  Set target levels of utilization for your data volumes, and resize volumes outside of expected ranges. 
+  Right size read-only volumes to fit the data. 
+  Migrate data to object stores to avoid provisioning the excess capacity from fixed volume sizes on block storage. 
+  Regularly review elastic volumes and file systems to terminate idle volumes and shrink over-provisioned resources to fit the current data size. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Amazon FSx Documentation](https://docs.aws.amazon.com/fsx/index.html) 
+  [What is Amazon Elastic File System?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) 

 **Related videos:** 
+ [ Deep Dive on Amazon EBS Elastic Volumes ](https://www.youtube.com/watch?v=Vi_1Or7QuOg)
+ [ Amazon EBS and Snapshot Optimization Strategies for Better Performance and Cost Savings ](https://www.youtube.com/watch?v=h1hzRCsJefs)
+ [ Optimizing Amazon EFS for cost and performance, using best practices ](https://www.youtube.com/watch?v=9kfeh6_uZY8)

# SUS04-BP05 Remove unneeded or redundant data
<a name="sus_sus_data_a6"></a>

Remove unneeded or redundant data to minimize the storage resources required to store your datasets. 

 **Common anti-patterns:** 
+  You duplicate data that can be easily obtained or recreated. 
+  You back up all data without considering its criticality. 
+  You only delete data irregularly, on operational events, or not at all. 
+  You store data redundantly irrespective of the storage service's durability. 
+  You turn on Amazon S3 versioning without any business justification. 

 **Benefits of establishing this best practice:** Removing unneeded data reduces the storage size required for your workload and the workload environmental impact. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Do not store data that you do not need. Automate the deletion of unneeded data. Use technologies that deduplicate data at the file and block level. Leverage native data replication and redundancy features of services. 

 **Implementation steps** 
+  Evaluate if you can avoid storing data by using existing publicly available datasets in [AWS Data Exchange](https://aws.amazon.com/data-exchange/) and [Open Data on AWS](https://registry.opendata.aws/). 
+  Use mechanisms that can deduplicate data at the block and object level. Here are some examples of how to deduplicate data on AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_data_a6.html)
+  Analyze the data access to identify unneeded data. Automate lifecycle policies. Leverage native service features like [Amazon DynamoDB Time To Live](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html), [Amazon S3 Lifecycle](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html), or [Amazon CloudWatch log retention](https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html) for deletion. 
+  Use data virtualization capabilities on AWS to maintain data at its source and avoid data duplication. 
  +  [Cloud Native Data Virtualization on AWS](https://www.youtube.com/watch?v=BM6sMreBzoA) 
  +  [Lab: Optimize Data Pattern Using Amazon Redshift Data Sharing](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) 
+  Use backup technology that can make incremental backups. 
+  Leverage the durability of [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html) and [replication of Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) to meet your durability goals instead of self-managed technologies (such as a redundant array of independent disks (RAID)). 
+  Centralize log and trace data, deduplicate identical log entries, and establish mechanisms to tune verbosity when needed. 
+  Pre-populate caches only where justified. 
+  Establish cache monitoring and automation to resize the cache accordingly. 
+  Remove out-of-date deployments and assets from object stores and edge caches when pushing new versions of your workload. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Change log data retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) 
+  [Data deduplication on Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html) 
+  [Features of Amazon FSx for ONTAP including data deduplication](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview) 
+  [Invalidating Files on Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html) 
+  [Using AWS Backup to back up and restore Amazon EFS file systems](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) 
+  [What is Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 
+  [Working with backups on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 

 **Related videos:** 
+  [Fuzzy Matching and Deduplicating Data with ML Transforms for AWS Lake Formation](https://www.youtube.com/watch?v=g34xUaJ4WI4) 

 **Related examples:** 
+  [How do I analyze my Amazon S3 server access logs using Amazon Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/) 

# SUS04-BP06 Use shared file systems or storage to access common data
<a name="sus_sus_data_a7"></a>

Adopt shared file systems or storage to avoid data duplication and allow for more efficient infrastructure for your workload. 

 **Common anti-patterns:** 
+  You provision storage for each individual client. 
+  You do not detach data volume from inactive clients. 
+  You do not provide access to storage across platforms and systems. 

 **Benefits of establishing this best practice:** Using shared file systems or storage allows for sharing data to one or more consumers without having to copy the data. This helps to reduce the storage resources required for the workload. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 If you have multiple users or applications accessing the same datasets, using shared storage technology is crucial to use efficient infrastructure for your workload. Shared storage technology provides a central location to store and manage datasets and avoid data duplication. It also enforces consistency of the data across different systems. Moreover, shared storage technology allows for more efficient use of compute power, as multiple compute resources can access and process data at the same time in parallel. 

 Fetch data from these shared storage services only as needed and detach unused volumes to free up resources. 

 **Implementation steps** 
+  Migrate data to shared storage when the data has multiple consumers. Here are some examples of shared storage technology on AWS:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_data_a7.html)
+ Copy data to or fetch data from shared file systems only as needed. As an example, you can create an [Amazon FSx for Lustre file system backed by Amazon S3](https://aws.amazon.com/blogs/storage/new-enhancements-for-moving-data-between-amazon-fsx-for-lustre-and-amazon-s3/) and only load the subset of data required for processing jobs to Amazon FSx.
+ Delete data as appropriate for your usage patterns as outlined in [SUS04-BP03 Use policies to manage the lifecycle of your datasets](sus_sus_data_a4.md).
+  Detach volumes from clients that are not actively using them. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+ [ Linking your file system to an Amazon S3 bucket ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/create-dra-linked-data-repo.html)
+ [ Using Amazon EFS for AWS Lambda in your serverless applications ](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/)
+ [ Amazon EFS Intelligent-Tiering Optimizes Costs for Workloads with Changing Access Patterns ](https://aws.amazon.com/blogs/aws/new-amazon-efs-intelligent-tiering-optimizes-costs-for-workloads-with-changing-access-patterns/)
+ [ Using Amazon FSx with your on-premises data repository ](https://docs.aws.amazon.com/fsx/latest/LustreGuide/fsx-on-premises.html)

 **related videos:** 
+ [ Storage cost optimization with Amazon EFS ](https://www.youtube.com/watch?v=0nYAwPsYvBo)

# SUS04-BP07 Minimize data movement across networks
<a name="sus_sus_data_a8"></a>


|  | 
| --- |
| This best practice was updated with new guidance on July 13th, 2023. | 

Use shared file systems or object storage to access common data and minimize the total networking resources required to support data movement for your workload.

 **Common anti-patterns:** 
+  You store all data in the same AWS Region independent of where the data users are. 
+  You do not optimize data size and format before moving it over the network. 

 **Benefits of establishing this best practice:** Optimizing data movement across the network reduces the total networking resources required for the workload and lowers its environmental impact. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Moving data around your organization requires compute, networking, and storage resources. Use techniques to minimize data movement and improve the overall efficiency of your workload. 

## Implementation steps
<a name="implementation-steps"></a>
+  Consider proximity to the data or users as a decision factor when [selecting a Region for your workload](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/). 
+  Partition Regionally consumed services so that their Region-specific data is stored within the Region where it is consumed. 
+  Use efficient file formats (such as Parquet or ORC) and compress data before moving it over the network. 
+  Don't move unused data. Some examples that can help you avoid moving unused data: 
  +  Reduce API responses to only relevant data. 
  +  Aggregate data where detailed (record-level information is not required). 
  +  See [Well-Architected Lab - Optimize Data Pattern Using Amazon Redshift Data Sharing](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/). 
  +  Consider [Cross-account data sharing in AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html). 
+  Use services that can help you run code closer to users of your workload.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_data_a8.html)

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Optimizing your AWS Infrastructure for Sustainability, Part III: Networking](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/) 
+  [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/) 
+  [Amazon CloudFront Key Features including the CloudFront Global Edge Network](https://aws.amazon.com/cloudfront/features/) 
+  [Compressing HTTP requests in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html) 
+  [Intermediate data compression with Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression) 
+  [Loading compressed data files from Amazon S3 into Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html) 
+  [Serving compressed files with Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html) 

 **Related videos:** 
+ [ Demystifying data transfer on AWS](https://www.youtube.com/watch?v=-MqXgzw1IGA)

 **Related examples:** 
+ [ Architecting for sustainability - Minimize data movement across networks ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)

# SUS04-BP08 Back up data only when difficult to recreate
<a name="sus_sus_data_a9"></a>

Avoid backing up data that has no business value to minimize storage resources requirements for your workload. 

 **Common anti-patterns:** 
+  You do not have a backup strategy for your data. 
+  You back up data that can be easily recreated. 

 **Benefits of establishing this best practice:** Avoiding back-up of non-critical data reduces the required storage resources for the workload and lowers its environmental impact. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Avoiding the back up of unnecessary data can help lower cost and reduce the storage resources used by the workload. Only back up data that has business value or is needed to satisfy compliance requirements. Examine backup policies and exclude ephemeral storage that doesn’t provide value in a recovery scenario. 

 **Implementation steps** 
+  Implement data classification policy as outlined in [SUS04-BP01 Implement a data classification policy](sus_sus_data_a2.md). 
+  Use the criticality of your data classification and design backup strategy based on your [recovery time objective (RTO) and recovery point objective (RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)). Avoid backing up non-critical data. 
  +  Exclude data that can be easily recreated. 
  +  Exclude ephemeral data from your backups. 
  +  Exclude local copies of data, unless the time required to restore that data from a common location exceeds your service-level agreements (SLAs). 
+  Use an automated solution or managed service to back up business-critical data. 
  +  [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) is a fully-managed service that makes it easy to centralize and automate data protection across AWS services, in the cloud, and on premises. For hands-on guidance on how to create automated backups using AWS Backup, see [Well-Architected Labs - Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/). 
  +  [Automate backups and optimize backup costs for Amazon EFS using AWS Backup](https://aws.amazon.com/blogs/storage/automating-backups-and-optimizing-backup-costs-for-amazon-efs-using-aws-backup/). 

## Resources
<a name="resources"></a>

 **Related best practices:** 
+ [REL09-BP01 Identify and back up all data that needs to be backed up, or reproduce the data from sources](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_identified_backups_data.html)
+ [REL09-BP03 Perform data backup automatically](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_automated_backups_data.html)
+ [REL13-BP02 Use defined recovery strategies to meet the recovery objectives](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)

 **Related documents:** 
+  [Using AWS Backup to back up and restore Amazon EFS file systems](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) 
+  [Amazon EBS snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) 
+  [Working with backups on Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 
+ [ APN Partner: partners that can help with backup ](https://partners.amazonaws.com/search/partners?keyword=Backup)
+ [AWS Marketplace: products that can be used for backup ](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [ Backing Up Amazon EFS ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [ Backing Up Amazon FSx for Windows File Server ](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [ Backup and Restore for Amazon ElastiCache (Redis OSS) ](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)

 **Related videos:** 
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup ](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341) ](https://www.youtube.com/watch?v=av8DpL0uFjc)

 **Related examples:** 
+ [ Well-Architected Lab - Testing Backup and Restore of Data ](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [ Well-Architected Lab - Backup and Restore with Failback for Analytics Workload ](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [ Well-Architected Lab - Disaster Recovery - Backup and Restore ](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)

# Hardware and services
<a name="a-sus-hardware-and-services"></a>

**Topics**
+ [SUS 5 How do you select and use cloud hardware and services in your architecture to support your sustainability goals?](sus-05.md)

# SUS 5 How do you select and use cloud hardware and services in your architecture to support your sustainability goals?
<a name="sus-05"></a>

Look for opportunities to reduce workload sustainability impacts by making changes to your hardware management practices. Minimize the amount of hardware needed to provision and deploy, and select the most efficient hardware and services for your individual workload. 

**Topics**
+ [SUS05-BP01 Use the minimum amount of hardware to meet your needs](sus_sus_hardware_a2.md)
+ [SUS05-BP02 Use instance types with the least impact](sus_sus_hardware_a3.md)
+ [SUS05-BP03 Use managed services](sus_sus_hardware_a4.md)
+ [SUS05-BP04 Optimize your use of hardware-based compute accelerators](sus_sus_hardware_a5.md)

# SUS05-BP01 Use the minimum amount of hardware to meet your needs
<a name="sus_sus_hardware_a2"></a>

Use the minimum amount of hardware for your workload to efficiently meet your business needs.

 **Common anti-patterns:** 
+  You do not monitor resource utilization. 
+  You have resources with a low utilization level in your architecture. 
+  You do not review the utilization of static hardware to determine if it should be resized. 
+  You do not set hardware utilization goals for your compute infrastructure based on business KPIs. 

 **Benefits of establishing this best practice:** Rightsizing your cloud resources helps to reduce a workload’s environmental impact, save money, and maintain performance benchmarks. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Optimally select the total number of hardware required for your workload to improve its overall efficiency. The AWS Cloud provides the flexibility to expand or reduce the number of resources dynamically through a variety of mechanisms, such as [AWS Auto Scaling](https://aws.amazon.com/autoscaling/), and meet changes in demand. It also provides [APIs and SDKs](https://aws.amazon.com/developer/tools/) that allow resources to be modified with minimal effort. Use these capabilities to make frequent changes to your workload implementations. Additionally, use rightsizing guidelines from AWS tools to efficiently operate your cloud resource and meet your business needs. 

 **Implementation steps** 
+  Choose the instances type to best fit your needs. 
  + [ How do I choose the appropriate Amazon EC2 instance type for my workload? ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
  + [ Attribute-based instance type selection for Amazon EC2 Fleet. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
  + [ Create an Auto Scaling group using attribute-based instance type selection. ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)
+  Scale using small increments for variable workloads. 
+  Use multiple compute purchase options in order to balance instance flexibility, scalability, and cost savings. 
  +  [On-Demand Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html) are best suited for new, stateful, and spiky workloads which can’t be instance type, location, or time flexible. 
  +  [Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) are a great way to supplement the other options for applications that are fault tolerant and flexible. 
  +  Leverage [Compute Savings Plans](https://aws.amazon.com/savingsplans/compute-pricing/) for steady state workloads that allow flexibility if your needs (like AZ, Region, instance families, or instance types) change. 
+  Use instance and availability zone diversity to maximize application availability and take advantage of excess capacity when possible. 
+  Use the rightsizing recommendations from AWS tools to make adjustments on your workload. 
  + [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
  + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+  Negotiate service-level agreements (SLAs) that allow for a temporary reduction in capacity while automation deploys replacement resources. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+ [ Optimizing your AWS Infrastructure for Sustainability, Part I: Compute ](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [ Attirbute based Instance Type Selection for Auto Scaling for Amazon EC2 Fleet ](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [AWS Compute Optimizer Documentation ](https://docs.aws.amazon.com/compute-optimizer/index.html)
+  [Operating Lambda: Performance optimization](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/) 
+  [Auto Scaling Documentation](https://docs.aws.amazon.com/autoscaling/index.html) 

 **Related videos:** 
+ [ Build a cost-, energy-, and resource-efficient compute environment ](https://www.youtube.com/watch?v=8zsC5e1eLCg)

 **Related examples:** 
+ [ Well-Architected Lab - Rightsizing with AWS Compute Optimizer and Memory Utilization Enabled (Level 200) ](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)

# SUS05-BP02 Use instance types with the least impact
<a name="sus_sus_hardware_a3"></a>


|  | 
| --- |
| This best practice was updated with new guidance on July 13th, 2023. | 

Continually monitor and use new instance types to take advantage of energy efficiency improvements.

 **Common anti-patterns:** 
+  You are only using one family of instances. 
+  You are only using x86 instances. 
+  You specify one instance type in your Amazon EC2 Auto Scaling configuration. 
+  You use AWS instances in a manner that they were not designed for (for example, you use compute-optimized instances for a memory-intensive workload). 
+  You do not evaluate new instance types regularly. 
+  You do not check recommendations from AWS rightsizing tools such as [AWS Compute Optimizer.](https://aws.amazon.com/compute-optimizer/) 

 **Benefits of establishing this best practice:** By using energy-efficient and right-sized instances, you are able to greatly reduce the environmental impact and cost of your workload. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Using efficient instances in cloud workload is crucial for lower resource usage and cost-effectiveness. Continually monitor the release of new instance types and take advantage of energy efficiency improvements, including those instance types designed to support specific workloads such as machine learning training and inference, and video transcoding. 

## Implementation steps
<a name="implementation-steps"></a>
+  Learn and explore instance types which can lower your workload environmental impact. 
  +  Subscribe to [What's New with AWS](https://aws.amazon.com/new/) to be up-to-date with the latest AWS technologies and instances. 
  +  Learn about different AWS instance types. 
  +  Learn about AWS Graviton-based instances which offer the best performance per watt of energy use in Amazon EC2 by watching [re:Invent 2020 - Deep dive on AWS Graviton2 processor-powered Amazon EC2 instances](https://www.youtube.com/watch?v=NLysl0QvqXU) and [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents). 
+  Plan and transition your workload to instance types with the least impact. 
  +  Define a process to evaluate new features or instances for your workload. Take advantage of agility in the cloud to quickly test how new instance types can improve your workload environmental sustainability. Use proxy metrics to measure how many resources it takes you to complete a unit of work. 
  +  If possible, modify your workload to work with different numbers of vCPUs and different amounts of memory to maximize your choice of instance type. 
  +  Consider transitioning your workload to Graviton-based instances to improve the performance efficiency of your workload. 
    +  [AWS Graviton Fast Start](https://aws.amazon.com/ec2/graviton/fast-start/) 
    +  [Considerations when transitioning workloads to AWS Graviton-based Amazon Elastic Compute Cloud instances](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md) 
    +  [AWS Graviton2 for ISVs](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html) 
  +  Consider selecting the AWS Graviton option in your usage of [AWS managed services.](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md) 
  +  Migrate your workload to Regions that offer instances with the least sustainability impact and still meet your business requirements. 
  +  For machine learning workloads, take advantage of purpose-built hardware that is specific to your workload such as [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/), and [Amazon EC2 DL1.](https://aws.amazon.com/ec2/instance-types/dl1/) AWS Inferentia instances such as Inf2 instances offer up to 50% better performance per watt over comparable Amazon EC2 instances. 
  +  Use [Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) to right size ML inference endpoint. 
  +  For spiky workloads (workloads with infrequent requirements for additional capacity), use [burstable performance instances.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) 
  +  For stateless and fault-tolerant workloads, use [Amazon EC2 Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) to increase overall utilization of the cloud, and reduce the sustainability impact of unused resources. 
+  Operate and optimize your workload instance. 
  +  For ephemeral workloads, evaluate [instance Amazon CloudWatch metrics](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics) such as `CPUUtilization` to identify if the instance is idle or under-utilized. 
  +  For stable workloads, check AWS rightsizing tools such as [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) at regular intervals to identify opportunities to optimize and right-size the instances. 
    + [ Well-Architected Lab - Rightsizing Recommendations ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
    + [ Well-Architected Lab - Rightsizing with Compute Optimizer ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
    + [ Well-Architected Lab - Optimize Hardware Patterns and Observice Sustainability KPIs ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Optimizing your AWS Infrastructure for Sustainability, Part I: Compute](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/) 
+  [AWS Graviton](https://aws.amazon.com/ec2/graviton/) 
+  [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/) 
+  [Amazon EC2 Capacity Reservation Fleets](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html) 
+  [Amazon EC2 Spot Fleet](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html) 
+  [Functions: Lambda Function Configuration](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+ [ Attribute-based instance type selection for Amazon EC2 Fleet ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [Building Sustainable, Efficient, and Cost-Optimized Applications on AWS](https://aws.amazon.com/blogs/compute/building-sustainable-efficient-and-cost-optimized-applications-on-aws/)
+ [ How the Contino Sustainability Dashboard Helps Customers Optimize Their Carbon Footprint ](https://aws.amazon.com/blogs/apn/how-the-contino-sustainability-dashboard-helps-customers-optimize-their-carbon-footprint/)

 **Related videos:** 
+  [Deep dive on AWS Graviton2 processer-powered Amazon EC2 instances](https://www.youtube.com/watch?v=NLysl0QvqXU) 
+  [Deep dive into AWS Graviton3 and Amazon EC2 C7g instances](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents) 
+ [ Build a cost-, energy-, and resource-efficient compute environment ](https://www.youtube.com/watch?v=8zsC5e1eLCg)

 **Related examples:** 
+ [ Solution: Guidance for Optimizing Deep Learning Workloads for Sustainability on AWS](https://aws.amazon.com/solutions/guidance/optimizing-deep-learning-workloads-for-sustainability-on-aws/)
+  [Well-Architected Lab - Rightsizing Recommendations](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/) 
+  [Well-Architected Lab - Rightsizing with Compute Optimizer](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/) 
+  [Well-Architected Lab - Optimize Hardware Patterns and Observe Sustainability KPIs](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/) 
+ [ Well-Architected Lab - Migrating Services to Graviton ](https://www.wellarchitectedlabs.com/sustainability/100_labs/100_migrate_services_to_graviton/)

# SUS05-BP03 Use managed services
<a name="sus_sus_hardware_a4"></a>

Use managed services to operate more efficiently in the cloud.

 **Common anti-patterns:** 
+  You use Amazon EC2 instances with low utilization to run your applications. 
+  Your in-house team only manages the workload, without time to focus on innovation or simplifications. 
+  You deploy and maintain technologies for tasks that can run more efficiently on managed services. 

 **Benefits of establishing this best practice:** 
+  Using managed services shifts the responsibility to AWS, which has insights across millions of customers that can help drive new innovations and efficiencies. 
+  Managed service distributes the environmental impact of the service across many users because of the multi-tenet control planes. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Managed services shift responsibility to AWS for maintaining high utilization and sustainability optimization of the deployed hardware. Managed services also remove the operational and administrative burden of maintaining a service, which allows your team to have more time and focus on innovation. 

 Review your workload to identify the components that can be replaced by AWS managed services. For example, [Amazon RDS](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/), and [Amazon ElastiCache](https://aws.amazon.com/elasticache/) provide a managed database service. [Amazon Athena](https://aws.amazon.com/athena/), [Amazon EMR](https://aws.amazon.com/emr/), and [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) provide a managed analytics service. 

 **Implementation steps** 

1.  Inventory your workload for services and components. 

1.  Assess and identify components that can be replaced by managed services. Here are some examples of when you might consider using a managed service:     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_hardware_a4.html)

1.  Identify dependencies and create a migrations plan. Update runbooks and playbooks accordingly. 
   +  The [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/) automatically collects and presents detailed information about application dependencies and utilization to help you make more informed decisions as you plan your migration 

1.  Test the service before migrating to the managed service. 

1.  Use the migration plan to replace self-hosted services with managed service. 

1.  Continually monitor the service after the migration is complete to make adjustments as required and optimize the service. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+ [AWS Cloud Products ](https://aws.amazon.com/products/)
+ [AWS Total Cost of Ownership (TCO) Calculator ](https://calculator.aws/#/)
+  [Amazon DocumentDB](https://aws.amazon.com/documentdb/) 
+  [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) 
+  [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/msk/) 

 **Related videos:** 
+ [ Cloud operations at scale with AWS Managed Services](https://www.youtube.com/watch?v=OCK8GCImWZw)

# SUS05-BP04 Optimize your use of hardware-based compute accelerators
<a name="sus_sus_hardware_a5"></a>

Optimize your use of accelerated computing instances to reduce the physical infrastructure demands of your workload.

 **Common anti-patterns:** 
+  You are not monitoring GPU usage. 
+  You are using a general-purpose instance for workload while a purpose-built instance can deliver higher performance, lower cost, and better performance per watt. 
+  You are using hardware-based compute accelerators for tasks where they’re more efficient using CPU-based alternatives. 

 **Benefits of establishing this best practice:** By optimizing the use of hardware-based accelerators, you can reduce the physical-infrastructure demands of your workload. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 If you require high processing capability, you can benefit from using accelerated computing instances, which provide access to hardware-based compute accelerators such as graphics processing units (GPUs) and field programmable gate arrays (FPGAs). These hardware accelerators perform certain functions like graphic processing or data pattern matching more efficiently than CPU-based alternatives. Many accelerated workloads, such as rendering, transcoding, and machine learning, are highly variable in terms of resource usage. Only run this hardware for the time needed, and decommission them with automation when not required to minimize resources consumed. 

## Implementation steps
<a name="implementation-steps"></a>
+  Identify which [accelerated computing instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) can address your requirements. 
+  For machine learning workloads, take advantage of purpose-built hardware that is specific to your workload, such as [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/), and [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/). AWS Inferentia instances such as Inf2 instances offer up to [50% better performance per watt over comparable Amazon EC2 instances](https://aws.amazon.com/machine-learning/inferentia/). 
+  Collect usage metric for your accelerated computing instances. For example, you can use CloudWatch agent to collect metrics such as `utilization_gpu` and `utilization_memory` for your GPUs as shown in [Collect NVIDIA GPU metrics with Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html). 
+  Optimize the code, network operation, and settings of hardware accelerators to make sure that underlying hardware is fully utilized. 
  +  [Optimize GPU settings](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html) 
  +  [GPU Monitoring and Optimization in the Deep Learning AMI](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html) 
  +  [Optimizing I/O for GPU performance tuning of deep learning training in Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/) 
+  Use the latest high performant libraries and GPU drivers. 
+  Use automation to release GPU instances when not in use. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [Accelerated Computing](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing) 
+ [ Let's Architect\$1 Architecting with custom chips and accelerators ](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/)
+ [ How do I choose the appropriate Amazon EC2 instance type for my workload? ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+  [Amazon EC2 VT1 Instances](https://aws.amazon.com/ec2/instance-types/vt1/) 
+  [Amazon Elastic Graphics](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-graphics.html) 
+ [ Choose the best AI accelerator and model compilation for computer vision inference with Amazon SageMaker AI ](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/)

 **Related videos:** 
+ [ How to select Amazon EC2 GPU instances for deep learning ](https://www.youtube.com/watch?v=4bVrIbgGWEA)
+  [Deep Dive on Amazon EC2 Elastic GPUs](https://www.youtube.com/watch?v=HbJ2xxgrcCE) 
+  [Deploying Cost-Effective Deep Learning Inference](https://www.youtube.com/watch?v=WiCougIDRsw) 

# Process and culture
<a name="a-sus-process-and-culture"></a>

**Topics**
+ [SUS 6 How do your organizational processes support your sustainability goals?](sus-06.md)

# SUS 6 How do your organizational processes support your sustainability goals?
<a name="sus-06"></a>

Look for opportunities to reduce your sustainability impact by making changes to your development, test, and deployment practices. 

**Topics**
+ [SUS06-BP01 Adopt methods that can rapidly introduce sustainability improvements](sus_sus_dev_a2.md)
+ [SUS06-BP02 Keep your workload up-to-date](sus_sus_dev_a3.md)
+ [SUS06-BP03 Increase utilization of build environments](sus_sus_dev_a4.md)
+ [SUS06-BP04 Use managed device farms for testing](sus_sus_dev_a5.md)

# SUS06-BP01 Adopt methods that can rapidly introduce sustainability improvements
<a name="sus_sus_dev_a2"></a>

Adopt methods and processes to validate potential improvements, minimize testing costs, and deliver small improvements.

 **Common anti-patterns:** 
+  Reviewing your application for sustainability is a task done only once at the beginning of a project. 
+  Your workload has become stale, as the release process is too cumbersome to introduce minor changes for resource efficiency. 
+  You do not have mechanisms to improve your workload for sustainability. 

 **Benefits of establishing this best practice:** By establishing a process to introduce and track sustainability improvements, you will be able to continually adopt new features and capabilities, remove issues, and improve workload efficiency. 

 **Level of risk exposed if this best practice is not established:** Medium 

## Implementation guidance
<a name="implementation-guidance"></a>

 Test and validate potential sustainability improvements before deploying them to production. Account for the cost of testing when calculating potential future benefit of an improvement. Develop low cost testing methods to deliver small improvements. 

 **Implementation steps** 
+  Add requirements for sustainability improvement to your development backlog. 
+  Use an iterative [improvement process](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html) to identify, evaluate, prioritize, test, and deploy these improvements. 
+  Continually improve and streamline your development processes. As an example, [Automate your software delivery process using continuous integration and delivery (CI/CD) pipelines](https://aws.amazon.com/getting-started/hands-on/set-up-ci-cd-pipeline/) to test and deploy potential improvements to reduce the level of effort and limit errors caused by manual processes. 
+  Develop and test potential improvements using the minimum viable representative components to reduce the cost of testing. 
+  Continually assess the impact of improvements and make adjustment as needed. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [AWS enables sustainability solutions](https://aws.amazon.com/sustainability/) 
+ [ Scalable agile development practices based on AWS CodeCommit](https://aws.amazon.com/blogs/devops/scalable-agile-development-practices-based-on-aws-codecommit/)

 **Related videos:** 
+ [ Delivering sustainable, high-performing architectures ](https://www.youtube.com/watch?v=FBc9hXQfat0)

 **Related examples:** 
+  [Well-Architected Lab - Turning cost & usage reports into efficiency reports](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/) 

# SUS06-BP02 Keep your workload up-to-date
<a name="sus_sus_dev_a3"></a>

Keep your workload up-to-date to adopt efficient features, remove issues, and improve the overall efficiency of your workload. 

 **Common anti-patterns:** 
+ You assume your current architecture is static and will not be updated over time.
+  You do not have any systems or a regular cadence to evaluate if updated software and packages are compatible with your workload. 

 **Benefits of establishing this best practice:** By establishing a process to keep your workload up to date, you can adopt new features and capabilities, resolve issues, and improve workload efficiency.

 **Level of risk exposed if this best practice is not established:** Low 

## Implementation guidance
<a name="implementation-guidance"></a>

 Up to date operating systems, runtimes, middlewares, libraries, and applications can improve workload efficiency and make it easier to adopt more efficient technologies. Up to date software might also include features to measure the sustainability impact of your workload more accurately, as vendors deliver features to meet their own sustainability goals. Adopt a regular cadence to keep your workload up to date with the latest features and releases. 

 **Implementation steps** 
+  Define a process and a schedule to evaluate new features or instances for your workload. Take advantage of agility in the cloud to quickly test how new features can improve your workload to: 
  +  Reduce sustainability impacts. 
  +  Gain performance efficiencies. 
  +  Remove barriers for a planned improvement. 
  +  Improve your ability to measure and manage sustainability impacts. 
+  Inventory your workload software and architecture and identify components that need to be updated. 
  +  You can use [AWS Systems Manager Inventory](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html) to collect operating system (OS), application, and instance metadata from your Amazon EC2 instances and quickly understand which instances are running the software and configurations required by your software policy and which instances need to be updated. 
+  Understand how to update the components of your workload.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/sus_sus_dev_a3.html)
+  Use automation for the update process to reduce the level of effort to deploy new features and limit errors caused by manual processes. 
  +  You can use [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) to automatically update AMIs, container images, and other artifacts related to your cloud application. 
  +  You can use tools such as [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) to automate the process of system updates, and schedule the activity using [AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [AWS Architecture Center](https://aws.amazon.com/architecture) 
+  [What's New with AWS](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected) 
+  [AWS Developer Tools](https://aws.amazon.com/products/developer-tools/) 

 **Related examples:** 
+  [Well-Architected Labs - Inventory and Patch Management](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) 
+  [Lab: AWS Systems Manager](https://mng.workshop.aws/ssm.html) 

# SUS06-BP03 Increase utilization of build environments
<a name="sus_sus_dev_a4"></a>

Increase the utilization of resources to develop, test, and build your workloads.

 **Common anti-patterns:** 
+  You manually provision or terminate your build environments. 
+  You keep your build environments running independent of test, build, or release activities (for example, running an environment outside of the working hours of your development team members). 
+  You over-provision resources for your build environments. 

 **Benefits of establishing this best practice:** By increasing the utilization of build environments, you can improve the overall efficiency of your cloud workload while allocating the resources to builders to develop, test, and build efficiently. 

 **Level of risk exposed if this best practice is not established:** Low 

## Implementation guidance
<a name="implementation-guidance"></a>

 Use automation and infrastructure-as-code to bring build environments up when needed and take them down when not used. A common pattern is to schedule periods of availability that coincide with the working hours of your development team members. Your test environments should closely resemble the production configuration. However, look for opportunities to use instance types with burst capacity, Amazon EC2 Spot Instances, automatic scaling database services, containers, and serverless technologies to align development and test capacity with use. Limit data volume to just meet the test requirements. If using production data in test, explore possibilities of sharing data from production and not moving data across. 

 **Implementation steps** 
+  Use infrastructure-as-code to provision your build environments. 
+  Use automation to manage the lifecycle of your development and test environments and maximize the efficiency of your build resources. 
+  Use strategies to maximize the utilization of development and test environments. 
  +  Use minimum viable representative environments to develop and test potential improvements. 
  +  Use serverless technologies if possible. 
  +  Use On-Demand Instances to supplement your developer devices. 
  +  Use instance types with burst capacity, Spot Instances, and other technologies to align build capacity with use. 
  +  Adopt native cloud services for secure instance shell access rather than deploying fleets of bastion hosts. 
  +  Automatically scale your build resources depending on your build jobs. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+  [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 
+  [Amazon EC2 Burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) 
+  [What is AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+ [ What is AWS CodeBuild? ](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [ Instance Scheduler on AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)

 **Related videos:** 
+ [ Continuous Integration Best Practices ](https://www.youtube.com/watch?v=77HvSGyBVdU)

# SUS06-BP04 Use managed device farms for testing
<a name="sus_sus_dev_a5"></a>

Use managed device farms to efficiently test a new feature on a representative set of hardware.

 **Common anti-patterns:** 
+  You manually test and deploy your application on individual physical devices. 
+  You do not use app testing service to test and interact with your apps (for example, Android, iOS, and web apps) on real, physical devices. 

 **Benefits of establishing this best practice:** Using managed device farms for testing cloud-enabled applications provides a number of benefits: 
+  They include more efficient features to test application on wide range of devices. 
+  They eliminate the need for in-house infrastructure for testing. 
+  They offer diverse device types, including older and less popular hardware, which eliminates the need for unnecessary device upgrades. 

 **Level of risk exposed if this best practice is not established:** Low 

## Implementation guidance
<a name="implementation-guidance"></a>

Using Managed device farms can help you to streamline the testing process for new features on a representative set of hardware. Managed device farms offer diverse device types including older, less popular hardware, and avoid customer sustainability impact from unnecessary device upgrades.

 **Implementation steps** 
+  Define your testing requirements and plan (like test type, operating systems, and test schedule). 
  +  You can use [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) to collect and analyze client-side data and shape your testing plan. 
+  Select the managed device farm that can support your testing requirements. For example, you can use [AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) to test and understand the impact of your changes on a representative set of hardware. 
+  Use continuous integration/continuous deployment (CI/CD) to schedule and run your tests. 
  + [ Integrating AWS Device Farm with your CI/CD pipeline to run cross-browser Selenium tests ](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/)
  + [ Building and testing iOS and iPadOS apps with AWS DevOps and mobile services ](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)
+  Continually review your testing results and make necessary improvements. 

## Resources
<a name="resources"></a>

 **Related documents:** 
+ [AWS Device Farm device list ](https://awsdevicefarm.info/)
+ [ Viewing the CloudWatch RUM dashboard ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html)

 **Related examples:** 
+ [AWS Device Farm Sample App for Android ](https://github.com/aws-samples/aws-device-farm-sample-app-for-android)
+ [AWS Device Farm Sample App for iOS ](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios)
+ [ Appium Web tests for AWS Device Farm](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python)

 **Related videos:** 
+ [ Optimize applications through end user insights with Amazon CloudWatch RUM ](https://www.youtube.com/watch?v=NMaeujY9A9Y)