Design your next Azure Infrastructure with Sustainability in mind

We always rush to create our Azure landing zone with compliance, security standards, and best practices, which is always the need of the hour. But at the same time, we need to start thinking about Sustainability

It is always easy to open any cloud portal and spin up a new Virtual machine and at the same time it is also necessary to understand what happens in the background and how to correct things at design time

The objective of this blog is not to reduce any security or best practices for any production or non-production environment, but we also have to change our mindset and think in terms of Sustainability, at least starting with non-Production or Developer environments wherever possible.

Below are a few areas where we can apply sustainability practices:

Compute

• Virtual Machines: This is one of the areas where we have larger control over the Infrastructure on the cloud. Below are the few best practices where we can think of reducing carbon footprint during design time:
  
  • Use B-series VMs: B-series VM are used for typically idle applications that have sudden usage bursts. B-series VMs use baseline-level CPU power having you paying only for the minimal usage. When there’s a sudden burst, CPU power increases and you pay extra for the extra used capacity.
  • Azure Spot Virtual Machines: This allows you to take advantage of our unused capacity at significant cost savings. At any point in time when Azure needs the capacity back, the Azure infrastructure will evict Azure Spot Virtual Machines. Therefore, Azure Spot Virtual Machines are great for workloads that can handle interruptions like batch processing jobs, dev/test environments, large compute workloads and more.
  • Auto-Shutdown: It is recommended to implement the auto-shutdown option for your virtual machine if you are using non-production or Dev/Test lab virtual machines, this will enable us to save compute power.

• Azure App Service: This is one of the areas where we are dependent on Azure’s underlying infrastructure when deploying applications such as PaaS. But still, there are few things which we can manage
  • Autoscaling: It is recommended to implement autoscaling for your service plan, this will scale hardware when needed if traffic grows. So, you don’t have to procure additional hardware in future
  • Slots: It is recommended to enable slots for your App service in a non-production environment, which will eliminate the need of having multiple hardware allocations for different environment

• Serverless:
  • Azure Functions with a consumption-based plan is a great example that is used to replace your classic Web API with Azure Http Trigger functions. Classic web jobs with timer or queue trigger. This will remove the need for having a dedicated plan and save lots of CPU usage when not required
  • SQL Database serverless: The serverless compute tier for single databases in Azure SQL Database is parameterized by a compute autoscaling range and an auto-pause delay. The configuration of these parameters shapes the database performance experience and compute
  • Logic Apps Is another Azure serverless resource that can be used as a background service and can be used to create workflows and orchestrate workflows

Storage

• Storage Account is the heart of many Azure resources like virtual machines, web apps, functions etc. So, it is always necessary to think of below recommended practices
  • Redundancy: When spinning up a new Virtual machine Azure recommends higher storage, which is not required in case of a non-production or development environment. So it is recommended to use LRS (Locally Redundant Storage)  as Other Redundancy options will need more storage and more CPU, which creates an impact on the environment. LRS replicates your storage account three times within a single data center in the primary region. LRS provides at least 99.999999999% (11 nines) durability of objects over a given year
  • Life Cycle Management: There is an option to enable life cycle management whenever we are using Blobs. It is recommended to enable the same for your non-Production environment which will remove older files and limit hardware space and management on the cloud

Backup & Logs

• Geo-Redundant Backup: Geo-Redundant backup is always needed for Ransomware attacks, but should be enabled only for production, which will save CPUs that are needed to store replicas
• Backup duration: Limit the duration for your logs e.g., which are stored in Log Analytics if not required

Above are a few steps where we can keep sustainability in control during design time.