Practical sustainability in AWS cloud

Sustainability has become an essential factor of almost all businesses, and there are things we all can affect, whether it relates to our everyday or work life. Sustainability was also raised to AWS Well-Architected framework as the new sixth pillar, stating that sustainability is at least partly an architectural challenge when it comes to IT systems. This article summarizes a few key actions every AWS customer can take to drive sustainability with cloud workloads.

Who’s responsible for carbon emissions in the cloud?

The AWS Well-Architected Framework organizes the carbon emissions related to cloud computing to the following scopes:

• Scope 1: All direct emissions from the activities of an organization or under its control. For example, fuel combustion by data center backup generators.
• Scope 2: Indirect emissions from electricity purchased and used to power data centers and other facilities. For example, emissions from commercial power generation.
• Scope 3: All other indirect emissions from activities of an organization from sources it doesn’t control. AWS examples include emissions related to data center construction and the manufacture and transportation of IT hardware deployed in data centers.

Each workload deployed generates a fraction of the total AWS emissions from each of the previous scopes. The actual amount varies per workload and depends on several factors, some depending on our choices, and others are more related to AWS’s choices. As for some other pillars in AWS Well-Architected Framework, the sustainability pillar also has its shared responsibility model:

So let’s dive a bit deeper into the choices we as AWS customers can make and how to optimize the carbon emissions from our side.

Best practices for sustainable workloads in AWS

Location matters

There are over 20 AWS Regions all over the globe on which we can choose to deploy and run our workloads. Of course, it makes sense to utilize a region geographically close to our users. Still, for example, there are six AWS Regions available only in Europe. In most use cases, the latency from any of those Regions will be acceptable for our business case. So there is a chance to make the Region selection based on sustainability.

Amazon has published a website to showcase its sustainability actions, like wind farm and solar farm projects. To drive sustainability, we can check the renewable energy projects on a map and choose Regions near those projects: https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true

In addition to the region selection, there are also other sustainability aspects to the geographical placement of workloads. AWS provides excellent solutions to extend your reach without having to clone the full-scale service to each region where we have users. Depending on our use case, it might be possible to have the service running in only one region and still offer low latencies and sustainability benefits throughout the globe. This could be achieved, for example, by utilizing local caching, connection pooling, edge caching, and distributed data stores.

Scale the services for sustainability

The apparent path to sustainability is to stop wasting resources (and money) and optimize our infrastructure to meet actual needs. Resource management is typically quite well managed if we are utilizing serverless architectures. But if we manage the workloads ourselves, it requires analyzing the effect of users on load and capacity utilization and responding to changes by scaling the resources as needed. To drive sustainability, choose the right-sized EC2 instance types for the job and leverage auto-scaling mechanisms to scale the resources up and down as needed.

People are equal; services and data are not

It also pays off from a sustainability point of view to define SLAs for our services and data. Not all parts of our service are of the same business criticality. Everything doesn’t have to be load-balanced. By leveraging asynchronous design patterns, our system can still stay operative and respond according to our SLAs even if some service parts are occasionally down.

And same applies to data. By scoping the data by SLAs, we can define which data needs to be available in milliseconds and which data could be retrieved from the archive in minutes or hours instead of milliseconds. As you can imagine, the services providing millisecond request times are far more energy-consuming than the services used to retrieve data in hours. So it’s our choice again. And it also pays off to eliminate assets that we don’t need anymore - we all have those old reports, images, data sets, and so forth, slumbering forgotten on our platforms.

Optimize software and architecture for cutting emissions

One of the most efficient ways to drive sustainability is asynchronous design patterns. By leveraging queues, pipelines, serialization, and scheduled jobs for requests that don’t require immediate processing, we can optimize the resource consumption so that services do the heavy-lifting with optimal resources and very high utilization. We can utilize many excellent AWS services for asynchronous tasks depending on the use case, such as Amazon SQS, Amazon MQ, AWS Step Functions, AWS Lambda, Amazon EventBridge, AWS Glue, and AWS Batch.

There’s also one crucial sustainability aspect of microservices architecture, especially for the ones built on resources we manage ourselves. There is always some overhead for running any workload, especially when running the workloads on dedicated EC2 instances. Therefore we should pay attention to and analyze the usage of each microservice in our architecture. If there are microservices that we aren’t utilizing anymore, shut those down. And if there are microservices that have the same kind of SLA and have low resource requirements, it might be a resource-wise decision to combine those services as one larger microservice.

The next one might sound quite obvious but still is not in the cloud era, having virtually endless capacity at our fingertips. Optimize the code to use more efficient algorithms to do the job, utilize a code profiler for optimizing the resources, monitor the performance of the code, and utilize hardware acceleration where applicable. Also, pay attention to data transfer patterns. Transfer data only when needed. And learn to take advantage of more effective file formats for data processing, such as Parquet, and pay attention to database indexes to ensure efficient query execution.

Final tips

The list of optimization targets could continue for a while. The fun fact with sustainability in the cloud is that being sustainable is typically cheaper than not being sustainable. The thing that costs here is lifting the stuff – making the change happen.

Did you know that you can see the estimated carbon footprint of your workloads in AWS? You can find the tool in AWS Console under Billing Dashboard/Cost & Usage Reports. Read more about the tool here: https://aws.amazon.com/blogs/aws/new-customer-carbon-footprint-tool/

Thank you for reaching here! Let us know if you would like NordHero to help you with your carbon footprint on AWS.