High Availability for Compute and DNS

What it is

High availability (HA) means a workload keeps serving users when a component fails. On AWS the basic unit of failure to design around is the Availability Zone (AZ), a separate data center group inside a Region. A Region is a wider failure domain, which matters for disaster recovery.

For the compute tier the pattern is simple: spread instances across at least two AZs, put a load balancer in front, replace unhealthy instances automatically, and use DNS to steer users away from a failed endpoint.

How it works

Choosing a load balancer

Cross zone load balancing spreads requests evenly across targets in all enabled AZs. It is on by default for an ALB and off by default for an NLB. Without it, an AZ with fewer targets receives the same share of traffic as a larger one and can be overloaded.

Deregistration delay lets in flight requests finish before a target is removed during a deployment or scale in.

Health checks

A load balancer sends health check requests to each target and stops routing to those that fail. An Auto Scaling group uses EC2 status checks by default. Switch its health check type to ELB, so an instance that fails the application check is replaced, not just left out of rotation.

aws autoscaling update-auto-scaling-group --auto-scaling-group-name web-asg \
  --health-check-type ELB --health-check-grace-period 300

The grace period gives new instances time to boot before checks count. Set it too short and healthy instances are killed in a loop.

Put the group in subnets of at least two AZs, and the group keeps the instance count balanced across them. If an AZ fails, the group launches replacements in the surviving zones.

Route 53 routing policies

Amazon Route 53 answers DNS queries and can check endpoint health.

Health checks can monitor an endpoint, combine other health checks (calculated), or follow a CloudWatch alarm. The alarm type lets you fail over on things Route 53 cannot reach, such as a private resource.

A failover record uses an alias to a load balancer and evaluates target health.

{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "app.example.com",
      "Type": "A",
      "SetIdentifier": "primary",
      "Failover": "PRIMARY",
      "HealthCheckId": "11111111-2222-3333-4444-555555555555",
      "AliasTarget": {
        "HostedZoneId": "Z0000000EXAMPLE",
        "DNSName": "primary-alb-123.us-east-1.elb.amazonaws.com",
        "EvaluateTargetHealth": true
      }
    }
  }]
}

Alias records work at the zone apex, cost nothing for queries to AWS targets and follow the target's IP changes.

DNS caching and faster failover

DNS failover depends on record time to live (TTL) and on resolvers honoring it. Use a short TTL for records you may need to switch. For faster and more predictable failover, use AWS Global Accelerator, which gives static anycast IP addresses and shifts traffic to healthy endpoints without waiting for DNS caches.

Amazon CloudFront origin groups offer a similar failover for content: if the primary origin returns chosen error codes, CloudFront requests the secondary.

Multi Region compute

For Regional failure, run a second stack in another Region and use latency or failover routing between them. Keep the stack definition in code, and keep AMIs, container images and configuration replicated to the second Region.

Availability targets and SLAs

A service level agreement (SLA) states an uptime promise. AWS publishes an SLA per service, usually as a monthly uptime percentage. If AWS misses it, you receive service credits and must file a claim; the SLA is not a guarantee that the service stays up.

Translate the business requirement, such as "no more than a few minutes of downtime a year", into a percentage and design to it.

Combine components with two rules.

• In series (each one is required): multiply. Two components at 99.9% give about 99.8%, so every extra hard dependency lowers the result.
• In parallel (any one is enough): availability is 1 minus (1 minus a) to the power n. Two independent 99% components give 99.99%.

Multi-AZ and Multi-Region designs put redundant copies in parallel. The math assumes independent failures, so a shared dependency such as a single database or a global control plane caps the result at that dependency's availability. Each extra tier of redundancy adds cost and complexity, so match it to the target.