Buried inside the “here’s a fourth Availability Zone” press release was the actual headline for anyone doing serious ML work in the UK: EC2 Trn3 eu-west-2d capacity is now live in the London Region. Before this, if you wanted Trainium accelerators for training and your compliance team wanted the data to stay in-country, you were stuck waiting or shipping workloads elsewhere. Now you don’t have to choose.
This is a different problem than the “extend your HA architecture” story most people will write about eu-west-2d. This one’s about actually standing up a training cluster on the new capacity, and getting the placement, networking, and reservation strategy right so it doesn’t fall over — or get preempted — the moment it matters.
What Trn3 Actually Buys You Here
Per AWS’s own numbers on the Trn3 UltraServers page, Trainium3 delivers roughly 4.4x the performance and 3.9x the memory bandwidth of Trn2 UltraServers, with UltraServers scaling to 144 chips (up to 362 FP8 PFLOPs) and stitching into EC2 UltraClusters for multi-thousand-chip jobs. That’s a meaningfully different class of hardware than what most eu-west-2 customers have had local access to, and it changes the calculus on whether you train in-Region at all versus shipping data to us-east-1 or us-west-2.
Step One: Check What EC2 Trn3 eu-west-2d Capacity Is Actually Available
Instance availability by AZ isn’t guaranteed evenly, especially for a capacity-constrained accelerator family on a brand-new zone. Check before you plan around it:
aws ec2 describe-instance-type-offerings \
--location-type availability-zone \
--filters Name=location,Values=eu-west-2d Name=instance-type,Values=trn3.* \
--region eu-west-2Step Two: Reserve, Don’t Hope
Accelerated capacity gets contended fast, especially in a Region and AZ this new. On-Demand Capacity Reservations targeted at eu-west-2d let you guarantee the instances exist when your training run kicks off:
aws ec2 create-capacity-reservation \
--instance-type trn3.32xlarge \
--instance-platform Linux/UNIX \
--availability-zone eu-west-2d \
--instance-count 16 \
--instance-match-criteria targeted \
--end-date-type limited \
--end-date 2026-09-30T00:00:00ZFor anything running longer or recurring, look at EC2 Capacity Blocks for ML rather than open-ended reservations — they’re purpose-built for training jobs with a known start and duration. Details are in the Capacity Reservations documentation.
Step Three: Cluster Placement, Not Just AZ Placement
An AZ tells the scheduler roughly where your instances live. A cluster placement group tells it to pack them close together on low-latency, high-throughput network paths — which matters enormously for distributed training where every all-reduce step is network-bound:
aws ec2 create-placement-group \
--group-name trn3-training-cluster \
--strategy cluster
aws ec2 run-instances \
--instance-type trn3.32xlarge \
--image-id ami-0examplemlbase \
--placement AvailabilityZone=eu-west-2d,GroupName=trn3-training-cluster \
--count 16 \
--key-name ml-training-key \
--security-group-ids sg-0123456789abcdef0 \
--subnet-id subnet-0eu2dtraining01The EC2 placement groups guide covers the tradeoffs — cluster placement groups are strict about being single-AZ, which is fine here since you’re deliberately pinning to eu-west-2d anyway.
Networking: Don’t Skimp on EFA
Trn3 UltraServers lean on Elastic Fabric Adapter for the inter-node communication that makes distributed training viable at scale. If you’re used to standard ENI setups from CPU-bound workloads, this is the part that trips people up — EFA needs to be explicitly enabled on the network interface and your AMI needs the EFA driver installed. Skipping this step is the single most common reason a “16-node Trn3 cluster” performs like four nodes worth of throughput.
aws ec2 create-network-interface \
--subnet-id subnet-0eu2dtraining01 \
--interface-type efa \
--groups sg-0123456789abcdef0Wire It Into Your Existing ML Pipeline
If you’re already running SageMaker training jobs, you don’t have to hand-roll EC2 instances at all — SageMaker can target eu-west-2d directly once capacity is available there, and it’ll manage placement groups and EFA configuration for you. That’s the pragmatic path for most teams; the manual EC2 route above is for anyone who needs tighter control over topology or is running a custom orchestration layer (Ray, Slurm, or similar) on top of raw instances.
Storage: Keep the Data Close to the Chips
Training throughput on Trn3 is high enough that S3 alone, without a caching layer, will bottleneck your data loader. If your training data lives in S3, pair it with FSx for Lustre mounted in eu-west-2d so reads don’t cross AZ boundaries on every epoch — cross-AZ data transfer is both a latency hit and a line item on your bill you don’t need. Checkpoint frequently to S3 (standard practice for any multi-hour training job — hardware failures happen, and a UltraServer job dying eight hours in with no checkpoint is a genuinely bad day), but keep the hot training set local to the AZ.
Monitoring: Watch the Chips, Not Just the Instances
Standard EC2 CloudWatch metrics (CPU, network) tell you almost nothing useful about whether a Trainium3 job is healthy. Install the Neuron monitoring tools and ship device-level metrics — accelerator utilization, HBM memory usage, collective communication time — into CloudWatch so you can tell the difference between “training is compute-bound and healthy” and “training is stalled on a bad collective op”:
neuron-monitor --config neuron-monitor-config.json | \
neuron-monitor-cloudwatch --namespace TrainiumTraining/eu-west-2dA stalled collective operation across 16 UltraServers wastes accelerator-hours fast, and generic instance metrics will look perfectly fine the entire time it’s happening.
Spot, On-Demand, or Capacity Blocks?
For a brand-new AZ with limited initial capacity, don’t default to On-Demand and hope. If your training job can tolerate interruption and checkpointing (most can, if you built it right), EC2 Spot on Trn3 in eu-west-2d can meaningfully cut cost — but expect thinner Spot pools in a zone this new, since capacity hasn’t had time to build up. For anything with a hard deadline, Capacity Blocks for ML are the more predictable choice: you commit to a start time and duration and AWS guarantees the capacity, which matters more than saving 40% when a research deadline is on the line.
The Real Takeaway
A new Availability Zone landing with Trn3 and P6 capacity isn’t just an infrastructure footnote — for UK and EU teams with data residency constraints, it’s the difference between training locally and shipping workloads (and the compliance headaches that come with it) across the Atlantic. Reserve the capacity, get your placement groups and EFA config right, and eu-west-2d becomes a real training environment instead of a line item in a Region map.
At Enkompass (enkompass.net), this is our home turf. We’ve stood up Trainium and GPU training clusters from scratch, including the capacity reservation and placement group details everyone forgets until their first run stalls. 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.