Green IT and Cloud: How to Reduce Your Infrastructure Carbon Footprint

Cloud's Carbon Context: The Numbers

The global ICT sector accounts for 4% of total greenhouse gas emissions, according to the International Energy Agency (IEA). Data centres represent a significant portion of this footprint, with global electricity consumption estimated at 200 TWh per year. The good news: public cloud is structurally more energy-efficient than on-premise infrastructure, with utilisation rates of 65–80% versus 10–15% in private data centres.

Hyperscalers post Power Usage Effectiveness (PUE) figures well below the global average (1.58 according to the Uptime Institute): AWS achieves a mean PUE of 1.2, Google Cloud 1.1 (best in class), and OVH 1.3 on its newest data centres. A PUE of 1.0 would be perfect (100% of energy goes to compute); 1.2 means 20% is lost to cooling and power distribution.

But simply migrating to the cloud does not automatically green your IT estate. How you use the cloud determines your actual footprint.

Measuring Your Footprint with the AWS Customer Carbon Footprint Tool

The AWS Customer Carbon Footprint Tool, available from the AWS Cost Management console, provides a monthly estimate of your CO2 emissions by service and region, expressed in metric tonnes of CO2 equivalent (tCO2e). The tool also calculates the savings achieved compared to an equivalent on-premise data centre.

# Access via AWS CLI
aws ce get-carbon-footprint-summary   --billing-period-start 2024-01-01   --billing-period-end 2024-12-31   --region eu-west-1

# Sample output
{
  "carbonFootprintSummary": {
    "estimatedCarbonAbated": {
      "amount": 12.4,
      "unit": "METRIC_TON_OF_CO2E"
    },
    "estimatedCarbonEmissions": {
      "amount": 3.2,
      "unit": "METRIC_TON_OF_CO2E"
    }
  }
}

Use this tool to establish your quarterly baseline and set a reduction target (for example, -10% per year). Carbon reduction and cost reduction are generally correlated: the less you waste, the less you pay and the less you emit.

Selecting Low-Carbon Regions

The carbon intensity of electricity varies considerably across AWS regions, depending on the local energy mix. Deploying workloads in eu-north-1 rather than ap-southeast-1 can reduce the carbon footprint by a factor of 30.

AWS Region	Location	Carbon intensity (gCO2eq/kWh)	Main source
eu-north-1	Stockholm	~12	Hydropower
eu-west-1	Ireland	~240	Offshore wind
us-west-2	Oregon	~275	Hydro + wind
eu-central-1	Frankfurt	~338	German mix
us-east-1	Virginia	~415	US East mix
ap-southeast-1	Singapore	~408	Natural gas

Practical strategy: deploy latency-sensitive workloads in your primary region (eu-west-1 for most European companies), and batch and deferred processing workloads in eu-north-1 or us-west-2.

Graviton3: 60% More Energy-Efficient

AWS Graviton3 processors (ARM architecture) deliver up to 60% better performance per watt compared to equivalent x86 instances (m6i, c6i, r6i). This efficiency translates into a double saving: less energy consumed and an AWS price 15–20% lower.

# Comparison: m6i.xlarge (x86) vs m7g.xlarge (Graviton3)
# m6i.xlarge : 4 vCPU, 16 GB RAM → ~$0.192/h (eu-west-1)
# m7g.xlarge : 4 vCPU, 16 GB RAM → ~$0.163/h (eu-west-1)
# Saving     : ~15% on cost + 60% on energy efficiency per watt

# Terraform: enforce Graviton3 for an EKS node group
resource "aws_eks_node_group" "graviton" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "graviton3-workers"
  instance_types  = ["t4g.medium"]  # Graviton3
  ami_type        = "AL2_ARM_64"

  scaling_config {
    desired_size = 3
    max_size     = 10
    min_size     = 1
  }
}

Progressive migration recommended: start with workloads without x86 binary dependencies (applications compiled in Go, Python, Node.js), then migrate Java applications (modern JVMs are fully ARM-compatible).

Rightsizing with AWS Compute Optimizer

An oversized instance wastes energy continuously — an EC2 server at 15% CPU utilisation still consumes 60–70% of its peak power draw. AWS Compute Optimizer analyses CloudWatch metrics over the past 14 days and identifies under-utilised EC2 instances, Auto Scaling groups, and Lambda functions.

aws compute-optimizer get-ec2-instance-recommendations   --filters name=Finding,values=OVER_PROVISIONED   --region eu-west-1   --output json |   jq '.instanceRecommendations[] | {
    instance: .instanceArn,
    current: .currentInstanceType,
    recommended: .recommendationOptions[0].instanceType,
    saving: .recommendationOptions[0].estimatedMonthlySavings.value
  }'

On average, 30% of EC2 instances are oversized. Systematically applying Compute Optimizer recommendations reduces the compute bill by 20–30% and proportionally reduces the associated carbon footprint.

S3 Intelligent-Tiering: Reducing Storage Emissions

S3 storage consumes energy proportional to the volume stored, regardless of access frequency. S3 Intelligent-Tiering automatically moves objects not accessed for 30 days to a low-cost (and low-footprint) tier, then to Glacier if inactivity exceeds 90 days.

# S3 lifecycle rule to Intelligent-Tiering then Glacier
resource "aws_s3_bucket_lifecycle_configuration" "green" {
  bucket = aws_s3_bucket.data.id

  rule {
    id     = "intelligent-tiering-and-archive"
    status = "Enabled"

    transition {
      days          = 30
      storage_class = "INTELLIGENT_TIERING"
    }

    transition {
      days          = 90
      storage_class = "GLACIER_IR"
    }

    expiration {
      days = 2555  # 7 years — legal compliance
    }
  }
}

Green Architecture Patterns: Event-Driven vs Always-On

An ECS Fargate container running 24/7 to handle an average of 2 requests per hour consumes energy continuously. A Lambda function only consumes energy during execution — typically a few milliseconds per invocation. For irregular workloads, serverless is systematically greener.

Similarly, Spot Instances use AWS spare capacity. From a marginal carbon perspective, this capacity would be consumed regardless — using Spots for batch jobs amounts to reusing an already-allocated resource, while reducing your bill by 60–90% compared to on-demand instances.

# Schedule non-critical workloads outside business hours
# EventBridge Scheduler: stop dev instances at night
resource "aws_scheduler_schedule" "stop_dev" {
  name = "stop-dev-instances"

  flexible_time_window { mode = "OFF" }
  schedule_expression = "cron(0 19 ? * MON-FRI *)"  # 7pm on weekdays

  target {
    arn      = "arn:aws:scheduler:::aws-sdk:ec2:stopInstances"
    role_arn = aws_iam_role.scheduler.arn
    input = jsonencode({
      Filters = [{
        Name   = "tag:Environment"
        Values = ["development"]
      }]
    })
  }
}

CSRD Compliance: Cloud Emissions in Scope 3

The European CSRD directive (Corporate Sustainability Reporting Directive), mandatory for large EU companies from fiscal year 2024 (reporting in 2025), requires disclosure of greenhouse gas emissions under Scopes 1, 2, and 3. Cloud usage emissions fall under Scope 3 — category 11 (use of sold products) for your customers, or Scope 2 (indirect energy consumption) if you are the end user.

The AWS Customer Carbon Footprint Tool provides the data needed to feed your CSRD cloud reporting. Export monthly reports, consolidate them by calendar year, and integrate them into your sustainability report. Move2Cloud can help you set up an automated Green IT dashboard via AWS QuickSight.

Conclusion

Cloud Green IT rests on four concrete levers: measure (Customer Carbon Footprint Tool), choose the right regions (eu-north-1, eu-west-1), adopt Graviton3, and eliminate waste (rightsizing, automatic shutdown, S3 Intelligent-Tiering). These actions are both environmentally responsible and financially beneficial — a rare convergence of interests. In a CSRD context, they also give you the traceability needed for your reporting obligations.