Deploy a Workload in the eu-west-2d Availability Zone

AWS added a fourth zone to the London Region, and rather than just reading about it, let’s actually put something in it. This walkthrough deploys a real, load-balanced EC2 workload into the new eu-west-2d Availability Zone — from confirming access, through subnetting, to a working Auto Scaling Group behind an Application Load Balancer spanning all four zones.

Prerequisites

• An AWS account with permissions for EC2, VPC, and Elastic Load Balancing (AdministratorAccess or an equivalent scoped policy is fine for this walkthrough)
• AWS CLI v2 installed and configured (aws configure) with a default Region of eu-west-2
• An existing VPC in eu-west-2 with subnets already in eu-west-2a/b/c (or willingness to create one from scratch — this guide assumes an existing VPC)
• Roughly 30 minutes and a workload you don’t mind spinning up (we’ll use a small `t3.micro` for the demo — swap in your real instance type)

What We’re Building in the eu-west-2d Availability Zone

A private subnet in eu-west-2d, an Auto Scaling Group that spans all four AZs, and an Application Load Balancer that routes traffic across all of them — so you finish with a genuinely more resilient deployment, not just a lone EC2 instance sitting in a new zone.

1. Confirm eu-west-2d is available to your account

   New Availability Zones aren’t always auto-enabled on every existing account. Check first:

   aws ec2 describe-availability-zones \
     --region eu-west-2 \
     --query 'AvailabilityZones[].{Name:ZoneName,State:State}' \
     --output table

   Confirm eu-west-2d shows State: available. If it’s missing entirely, consult the Availability Zones documentation — some accounts need to opt in to newly added zones. See also the official eu-west-2d announcement.

2. Grab your VPC and existing subnet details

   aws ec2 describe-vpcs --region eu-west-2 \
     --query 'Vpcs[].{VpcId:VpcId,CIDR:CidrBlock}' --output table
   
   aws ec2 describe-subnets --region eu-west-2 \
     --filters "Name=vpc-id,Values=vpc-0abc123456789ef01" \
     --query 'Subnets[].{Id:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock}' \
     --output table

   Note an unused CIDR block for your new subnet — for example, if a/b/c use 10.0.10.0/24, 10.0.20.0/24, 10.0.30.0/24, use 10.0.40.0/24 for eu-west-2d.

3. Create a private subnet in eu-west-2d

   aws ec2 create-subnet \
     --vpc-id vpc-0abc123456789ef01 \
     --cidr-block 10.0.40.0/24 \
     --availability-zone eu-west-2d \
     --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=private-eu-west-2d}]'

   Save the returned SubnetId — you’ll need it in the next steps. Full options are in the VPC subnet guide.

4. Associate the subnet with your route table

   aws ec2 associate-route-table \
     --subnet-id subnet-0new2dprivate01 \
     --route-table-id rtb-0existingprivate01

   Use the same private route table your other three private subnets use, so NAT/internet routing behaves consistently.

5. Create a security group (or reuse your existing app SG)

   aws ec2 create-security-group \
     --group-name web-tier-sg \
     --description "Web tier - HTTP from ALB only" \
     --vpc-id vpc-0abc123456789ef01
   
   aws ec2 authorize-security-group-ingress \
     --group-id sg-0webtier01 \
     --protocol tcp --port 80 \
     --source-group sg-0albsg01

6. Create a launch template

   aws ec2 create-launch-template \
     --launch-template-name web-tier-lt \
     --version-description v1 \
     --launch-template-data '{
       "ImageId": "ami-0examplewebbase",
       "InstanceType": "t3.micro",
       "SecurityGroupIds": ["sg-0webtier01"]
     }'

7. Stand up an Auto Scaling Group across all four subnets

   aws autoscaling create-auto-scaling-group \
     --auto-scaling-group-name web-tier-asg \
     --launch-template "LaunchTemplateName=web-tier-lt,Version=1" \
     --min-size 4 --max-size 8 --desired-capacity 4 \
     --vpc-zone-identifier "subnet-aaa111,subnet-bbb222,subnet-ccc333,subnet-0new2dprivate01"

   This is the step that actually puts a running instance in eu-west-2d — the ASG will now distribute across all four zones evenly.



8. Create (or update) your Application Load Balancer to span all four AZs

   aws elbv2 create-load-balancer \
     --name web-alb \
     --subnets subnet-pub-aaa subnet-pub-bbb subnet-pub-ccc subnet-pub-2d \
     --security-groups sg-0albsg01 \
     --scheme internet-facing --type application

   If you already have an ALB, extend it instead:

   aws elbv2 set-subnets \
     --load-balancer-arn arn:aws:elasticloadbalancing:eu-west-2:123456789012:loadbalancer/app/web-alb/abc123 \
     --subnets subnet-pub-aaa subnet-pub-bbb subnet-pub-ccc subnet-pub-2d

   Note: you’ll need a public subnet in eu-west-2d too if your ALB is internet-facing — repeat step 3 with a public CIDR and an internet-gateway route.

9. Verify instances actually landed in eu-west-2d

   aws ec2 describe-instances \
     --filters "Name=tag:aws:autoscaling:groupName,Values=web-tier-asg" \
     --query 'Reservations[].Instances[].{Id:InstanceId,AZ:Placement.AvailabilityZone,State:State.Name}' \
     --output table

   You should see at least one running instance with AZ: eu-west-2d. If you don’t, double-check the ASG’s VPCZoneIdentifier and confirm the desired capacity is high enough to actually spread across four zones.

10. Confirm the ALB is healthy across all zones

    aws elbv2 describe-target-health \
      --target-group-arn arn:aws:elasticloadbalancing:eu-west-2:123456789012:targetgroup/web-tg/abc123

    Look for healthy targets registered from each of the four AZs before you call this done — see the target group health check docs if any targets stay stuck in unhealthy.

11. Tag everything for cost visibility

    Before you call this finished, make sure the new subnet, instances, and any reservations are tagged consistently with the rest of your environment — it’s the difference between a clean cost report next month and a mystery line item nobody can explain:

    aws ec2 create-tags \
      --resources subnet-0new2dprivate01 \
      --tags Key=Environment,Value=production Key=Zone,Value=eu-west-2d Key=CostCenter,Value=platform-eng

12. Prove the resilience actually works

    Don’t take “the ASG spans four AZs” on faith — test it. Temporarily set eu-west-2d instances out of service and confirm the ALB routes around them cleanly, then bring them back:

    # Find instances in eu-west-2d and deregister them from the target group
    aws elbv2 deregister-targets \
      --target-group-arn arn:aws:elasticloadbalancing:eu-west-2:123456789012:targetgroup/web-tg/abc123 \
      --targets Id=i-0eu2dinstance01
    
    # Confirm traffic still flows and no errors spike, then re-register
    aws elbv2 register-targets \
      --target-group-arn arn:aws:elasticloadbalancing:eu-west-2:123456789012:targetgroup/web-tg/abc123 \
      --targets Id=i-0eu2dinstance01

    If your error rate or latency moved when you pulled eu-west-2d out of rotation, your load balancer or health checks aren’t configured correctly yet — fix that before you consider this deployment done, not after an actual AZ event forces the issue.

What You Built

You now have a web tier that’s genuinely distributed across four independent fault domains in eu-west-2 instead of three, with a load balancer routing traffic to all of them and an Auto Scaling Group that will keep it that way as capacity scales up or down. If eu-west-2d ever has a bad day, three other zones keep serving traffic without you doing anything — which is the entire point of a Multi-AZ design in the first place. From here, the natural next steps are extending your data tier (RDS, ElastiCache) with the same deliberateness, and if you’re running accelerated workloads, layering in Capacity Reservations so Trn3/P6 instances are guaranteed to be there when you need them.

If something in this walkthrough didn’t behave as expected, the usual suspects are a security group missing the ALB-to-instance rule, a route table not associated with the new subnet, or an IAM policy that doesn’t cover the new subnet’s resource ARN. Re-run the describe-instances and describe-target-health commands from steps 9 and 10 first — they’ll tell you whether the problem is placement (instance never launched in eu-west-2d) or routing (instance is there but unreachable), which narrows down the fix considerably.

At Enkompass (enkompass.net), this is our home turf. We’ve run this exact multi-AZ extension for clients the same week a Region grew a new zone, catching the hardcoded-AZ-list gotchas before they became 2 AM pages. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.