Cloud SRE Practices: Adapt SRE for AWS, GCP, Azure (2026)

An SRE team’s mandate to treat operations as a software problem, with error budgets and SLOs, doesn’t magically transfer to the cloud.

Imagine you’re running a web service.

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend-service:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

This Nginx config is straightforward. It proxies requests to a backend service running on backend-service:8080. If the backend is slow or down, Nginx will eventually time out or return an error. Your SRE team, armed with Prometheus and Grafana, would monitor Nginx’s error rates, latency, and the health of backend-service. They’d define an SLO like "99.9% of requests to example.com served within 500ms" and use an error budget to decide when to pause feature development and focus on reliability.

Now, let’s move this to AWS. Instead of a single Nginx server, you might have an Application Load Balancer (ALB) distributing traffic to an Auto Scaling Group (ASG) of EC2 instances running your backend application.

Here’s where the SRE thinking needs adaptation. The ALB itself becomes a critical component, and its health and configuration are now part of your system’s reliability.

The Mental Model:

Your cloud infrastructure isn’t a static set of servers; it’s a dynamic, managed system provided by the cloud vendor. Your SRE job shifts from managing the servers to managing the cloud services that manage the servers and your application.

• Abstraction Layers: You’re now dealing with higher levels of abstraction. Instead of OS patches, you’re thinking about ALB target group health check configurations. Instead of network interface cards, you’re configuring VPC subnets and security groups.
• Shared Responsibility: Remember the cloud provider’s shared responsibility model. They handle the physical infrastructure, networking fabric, and the underlying hypervisors. You’re responsible for your data, applications, operating systems, and network configurations within the cloud.
• Managed Services as Building Blocks: Services like ALBs, RDS, SQS, Lambda, and EKS are your new primitives. Understanding their failure modes, performance characteristics, and how to integrate them reliably is paramount.
• Configuration as Code: Just as you’d version-control your application code, you must version-control your cloud infrastructure. Tools like Terraform, CloudFormation, or Pulumi are essential for defining and deploying your infrastructure in a repeatable and auditable way.

Example in Action (AWS):

Let’s say your backend is a Python Flask app.

Application Code (app.py):

from flask import Flask, request
import time

app = Flask(__name__)

@app.route('/')
def hello_world():
    # Simulate some work
    time.sleep(0.1)
    return 'Hello, Cloud SRE!'

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

Terraform for Infrastructure:

resource "aws_lb" "main" {
  name               = "my-app-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = aws_subnet.public[*].id
  security_groups    = [aws_security_group.alb.id]
}

resource "aws_lb_target_group" "main" {
  name     = "my-app-tg"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    path                = "/"
    protocol            = "HTTP"
    matcher             = "200-399"
    interval            = 30
    timeout             = 5
    healthy_threshold   = 3
    unhealthy_threshold = 3
  }
}

resource "aws_lb_listener" "main" {
  load_balancer_arn = aws_lb.main.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.main.arn
  }
}

resource "aws_launch_template" "main" {
  name_prefix   = "my-app-lt-"
  image_id      = "ami-0abcdef1234567890" # Replace with a valid AMI ID
  instance_type = "t3.micro"

  user_data = base64encode(<<-EOF
              #!/bin/bash
              sudo apt-get update -y
              sudo apt-get install -y python3-pip
              pip3 install flask
              echo 'from flask import Flask; import time; app = Flask(__name__); @app.route("/"); def hello_world(): time.sleep(0.1); return "Hello, Cloud SRE!"; if __name__ == "__main__": app.run(host="0.0.0.0", port=8080)' > /home/ubuntu/app.py
              python3 /home/ubuntu/app.py &
              EOF
              )
}

resource "aws_autoscaling_group" "main" {
  desired_capacity    = 2
  max_size            = 5
  min_size            = 1
  vpc_zone_identifier = aws_subnet.public[*].id

  launch_template {
    id      = aws_launch_template.main.id
    version = "$Latest"
  }

  target_group_arns = [aws_lb_target_group.main.arn]
}

In this setup, your SRE concerns shift:

• ALB Health Checks: The health_check block in aws_lb_target_group is your new "is the server up?" check. If the health check fails 3 times in a row (unhealthy_threshold=3) after 30-second intervals, the ALB stops sending traffic to that instance.
• ASG Scaling: The aws_autoscaling_group ensures you have enough instances. If the ALB sees too many unhealthy instances, the ASG might launch new ones based on the launch_template.
• Monitoring CloudWatch Metrics: You’d monitor ALB metrics like HealthyHostCount, UnHealthyHostCount, RequestCount, and HTTPCode_Target_5XX_Count. For the ASG, you’d watch CPUUtilization (if you add scaling policies) and GroupInServiceInstances.

The crucial insight is that your application is running on compute instances managed by an ASG, behind an ALB. Your SLO now applies to the latency and error rate as perceived by the user, which means it’s impacted by the ALB’s performance, the ASG’s ability to scale, and the health of the individual instances as reported to the ALB.

The one thing most people don’t grasp is how deeply the cloud provider’s internal mechanisms for health checking, load balancing, and auto-scaling can influence your application’s availability, often in ways that aren’t immediately obvious from your application logs alone. For instance, if your application starts returning 503s under load, the ALB’s health checks might start failing, leading to the ASG taking instances out of service and potentially worsening the problem if new instances take time to warm up.

Understanding the interplay between your application’s behavior, the cloud service configurations, and the cloud provider’s automated responses is the core of cloud SRE.

The next challenge is integrating this with a robust CI/CD pipeline that deploys infrastructure changes and application updates without disrupting the error budget.