Sustainability is an important topic. This is not without a reason, since sustainability is key in preserving our planet. The combined world of sustainability and cloud is getting more and more traction. The investements pay off: we get more capabilities to work with and now it’s time to start harvesting. The urgency is also there. ICT, including cloud, is responsible for 3% of the global greenhouse gasses emissions. We, as consumers of cloud resource, easily have impact since making changes to your cloud environment can be done easily (e.g. no hardware to write off).
This blog is written to provide some practical tips to get started on sustainability. Before we start it’s important to become familiar with some terminology.
While talking about it won’t take long before anyone will start about scope 1, 2 or 3. The brief definition of the scopes:
Scope 1: All direct emissions.
Scope 2: Indirect emissions associated with, for example, the generation of electricity which has been purchased for your own consumption.
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.
Any gas that absorbs infrared radiation in the atmosphere. CHG is the abbreviation for greenhouse gas.
Metric tons of carbon dioxide equivalents (MTCO2e)
The unit of measurement for calculating impact. The unit “CO2e” represents an amount of a GHG whose atmospheric impact has been standardized to that of one unit mass of carbon dioxide (CO2), based on the global warming potential (GWP) of the gas.
Let’s dive into the details.
1. If you can’t measure it, you can’t improve it.
Last year AWS launched the AWS Customer Carbon Footprint Tool. This tool is available for AWS customers at no cost. It can be launched via the AWS console and provides insights in scope 1 and 2 CHG emissions, expressed in MTCO2e. These insights can be used to measure and report via data visualizations. Drill-downs can be made based on summary, by geography, by service, by statistics over time and by the path to 100% renewable energy.
First start is to zoom in on the summary, geography (note: these don not map 1:1 with AWS Regions) and finally the AWS services. Once you understand where you can improve you can start planning and applying changes. The progress of your improvements can be tracked by viewing the statistics over time. Side note here: AWS currently updates the data/reports after three months. So measuring impact requires patience. Rumor has it that this will be improved (anytime soon ofcourse).
2. Reduce waste and usage
For directly reducing emissions it’s important to start reducing waste and usage. Remove any unused and right-size underutilized resources. Less powerful underlying hardware requires less power and cooling to run and therefore will lower your emissions immediately.
For long-term improvements companies need to change their culture and add sustainability as a non-function requirement. With adding this to the list of requirements the goal can be met on the long-term and will scale across the entire company.
Also establish a GreenOps practice. My collegue Mudit Gupta wrote a blog about GreenOps.
AWS regions are running datacenters on local grids. Each grid is different and not all grids are equally using renewable energy. Taking sustainability into account as non-functional requirement for region selection can drastically reduce your emissions. AWS Architecture Blog has a blog post on How to select a Region for your workload based on sustainability goals.
Align SLA with sustainability goals
More performance always feels better. The more responsive your website is the better the experience. But often the last bits of performance optimizations come with a big penalty when it comes to resource consumption. Sometimes it can be worth to consider optimizing performance instead of maximizing performance.
Asynchronuous and decoupled applications allow more precise scaling and reduce idle time. This will reduce emissions.
Select the right instance types by not only selecting on dimensions (cores, memory, etc.), but also consider different architectures. ARM-based processor such as AWS’ Graviton allow better performance per watt of energy use compared to x86 processors. Doing this during projectime will save you from rebuilding your application (ARM and x86 are not compatible and requires recompiling).
Use storage solutions that best supports your workloads. SSD drives are consuming more energy and are usefull for frequently accessed data, but less efficient for data archives. Use magnetic storage for archival-class storage.
Use Trusted Advisor to identify under-utilized instances. The tool provides insights and recommendations that can be followed up with much effort.
Not all programming languages are written to be compute effective. Choosing the right language can reduce the usage of compute resources. The study Energy Efficiency across Programming Languages is a nice read and giving more information about the most popular programming languages and their memory and energy consumption. Please be aware that selecting the right language alone is not enough to make your software architecture efficient. It is the combination of the language and the overall design. Even with the most efficient languages one can write very inefficient software.
Sustainability is on the intersection with FinOps. They mutually support each other and have a lot of the same thinking in common. Improving costs will most likely improve your cost-effiency and visa versa. For example: reducing waste and usage will reduces cost, but obviously also improve sustainability. Emissions for something you didn’t needed in the first place are always 100% useless and at the same time right-sizing will bring the emissions closer to the minimum you can do.
This blog is just a brief introduction to the topic and far from compleet. So expect more to come! If you have any questions, feel free to reach out.