AWS latency check.
Round-trip latency from your browser to every AWS region. Hit in parallel, median ms reported. Click rerun for a fresh measurement.
AWS latency check — browser-measured RTT to all 12 AWS regions using DynamoDB regional healthcheck endpoints.Measured live from your browser to 0 AWS region endpoints. Three samples per region in parallel, fetch(no-cors) + median ms reported, four-second timeout.
AWS · 0 regions
// endpoint used
dynamodb.<region>.amazonaws.com returns a tiny ~40-byte healthy: ... response on GET / — the same low-overhead endpoint used by other public AWS latency probes. Hit with fetch(no-cors).
// what it measures
Per region: 4 sequential samples, first discarded as TLS warm-up, median of the remaining 3 reported. Numbers approximate TCP + TLS + first-byte time — a few ms higher than raw ping, but the relative ordering between regions is accurate.
// what it doesn't
We don't persist runs, send your IP anywhere, or compare inter-region paths. For serious benchmarking, mtr beats browser fetch timing every time.
// aws latency faq
How does this AWS latency test work?
Your browser fires fetch(no-cors) requests at dynamodb.<region>.amazonaws.com in all 12 regions — the same ~40-byte healthcheck endpoint other public AWS probes use, chosen because it answers fast with minimal server-side work. Each region gets 4 sequential samples; the first is thrown away as TLS warm-up and the median of the remaining 3 is reported. Everything runs client-side: no backend, nothing logged. Numbers approximate TCP + TLS + first-byte time, so they sit a few ms above a raw ICMP ping.
What do AWS region names like us-east-1 mean?
AWS names regions geography-direction-number: us-east-1 is Northern Virginia, us-west-2 is Oregon, ap-south-1 is Mumbai, eu-central-1 is Frankfurt. The trailing number is launch order within that geography, not a quality ranking — us-east-2 (Ohio) is newer than us-east-1, not worse. Availability Zones append a letter: us-east-1a, us-east-1b. One gotcha: the letter-to-physical-datacenter mapping is shuffled per AWS account, so your us-east-1a is probably not the same building as someone else's us-east-1a.
Why does us-east-1 get so much attention?
It is AWS's oldest and largest region, and parts of AWS are quietly hardwired to it: IAM, the CloudFront control plane, and Route 53 are managed there, and ACM certificates used with CloudFront must be issued in us-east-1. It usually receives new services first and has some of the lowest prices. The flip side is blast radius — several famous AWS outages were us-east-1 incidents, which is exactly why many teams deliberately run production somewhere else.
Which AWS region should I choose?
Pick for your users' latency, not your own — run this test from where your traffic actually originates. Then weigh three more factors: price (us-east-1 and us-west-2 are among the cheapest, while sa-east-1 and ap-south-1 can cost 20-50% more for the same instance type), service availability (new services and instance families land in the big regions first), and data residency rules that may legally pin you to eu-central-1 or ca-central-1 regardless of the milliseconds.
What's the difference between a region and a CloudFront edge location?
Regions are full datacenter clusters where your EC2, RDS, and Lambda actually run — around 30-plus worldwide. CloudFront edge locations are 600-plus small PoPs that only cache content and terminate connections. A user can be 10 ms from an edge but 150 ms from your region; CloudFront and Global Accelerator exploit this by terminating TLS at the edge and carrying traffic to the region over AWS's backbone. A slow region in this test doesn't mean a CDN-fronted app will feel slow.
How big is inter-AZ versus inter-region latency?
Within one region, Availability Zones typically sit under 1-2 ms apart — close enough for synchronous replication, which is why RDS Multi-AZ and EBS replication stay inside a region. Between regions you're at the mercy of geography: us-east-1 to us-west-2 runs roughly 60-70 ms, and us-east-1 to ap-southeast-1 over 200 ms. That's why cross-region tools like S3 CRR, DynamoDB global tables, and Aurora Global Database are asynchronous by design. Replicate synchronously within a region, asynchronously across them.
Why is a nearby AWS region showing high latency for me?
Distance is only half the story — routing is the rest. Your ISP may hand traffic to AWS at a distant peering point, corporate VPNs often hairpin everything through a head office, and mobile carriers can add 30-50 ms before a packet even leaves their network. Run mtr or traceroute toward the region endpoint to see where the time actually goes. If your users hit this, AWS Global Accelerator gives them an anycast on-ramp to the AWS backbone at the nearest edge.