Global vs Regional Services

When you build on AWS (Amazon Web Services, Amazon’s cloud platform), almost everything you create lives inside a single Region (a physical cluster of data centers in one part of the world, like us-east-1 in Northern Virginia). But a small set of services are global — they have no Region at all and behave the same everywhere. Knowing which is which saves you from confusing bugs, like “why can’t I see my EC2 server?” or “why is my bucket name already taken?” This page explains the split, why it exists, and the one tricky service that sits in the middle.

What “regional” means

A regional service stores its data and runs its resources inside the Region you picked. An EC2 instance (a virtual server) you launch in eu-west-1 (Ireland) does not appear if your console is set to us-east-1. The resource still exists — you’re just looking in the wrong place.

Most AWS services are regional. Examples: EC2 (virtual servers), VPC (your private network), RDS (managed databases), Lambda (serverless functions), SQS (message queues), DynamoDB tables, and EBS volumes (disks). Each Region is isolated from the others on purpose, so an outage in one Region doesn’t take down your resources in another.

Gotcha: The single most common beginner mistake is “my resource disappeared.” It didn’t — your console’s Region selector (top-right corner) is pointed somewhere else. Always check the Region first.

When this matters

• Latency: Put resources near your users. A database in Tokyo serving customers in Tokyo is fast; one in Virginia is slow.
• Compliance: Data-residency laws (like the EU’s GDPR) may require data to stay in a specific Region.
• Failover: To survive a Region-wide outage you must deliberately copy resources into a second Region — it does not happen automatically.

What “global” means

A global service has one control plane shared across all Regions. You don’t pick a Region for it; there’s just one view of it for your whole account. The handful of global services are:

Service	What it does	Why it’s global
IAM (Identity and Access Management)	Users, roles, and permissions	One identity must work in every Region
Route 53 (DNS)	Domain name resolution	DNS is a worldwide directory by nature
CloudFront (CDN)	Caches content at edge locations near users	Edge network spans the entire planet
AWS WAF (for CloudFront)	Web firewall rules attached to CloudFront	Must follow CloudFront’s global edge
AWS Organizations	Manages multiple AWS accounts	Account structure is account-wide

Because these are global, you’ll often see them pinned to a Region label of “Global” in the console, and many of their CLI calls are made against us-east-1 under the hood (for example, ACM certificates used by CloudFront must be requested in us-east-1).

Tip: AWS WAF has two flavors. The WAF that protects CloudFront is global (scope CLOUDFRONT). The WAF that protects regional resources like an Application Load Balancer is regional (scope REGIONAL). Same service name, different scope.

The S3 exception: regional buckets, global names

Amazon S3 (Simple Storage Service, AWS’s object storage) is where people get tripped up. An S3 bucket is regional — its data physically lives in the Region you create it in. But bucket names are drawn from a single global namespace. That means your bucket name must be unique across every AWS account on Earth.

So my-app-logs is almost certainly taken. Use something unlikely to collide, such as your company name plus a random suffix: acme-prod-logs-7f3a9b.

How to create a bucket — Console

1. Open the S3 console.
2. Choose Create bucket.
3. Enter a globally unique Bucket name (e.g. acme-prod-logs-7f3a9b).
4. Pick the AWS Region where the data should physically live.
5. Leave Block all public access enabled (the safe default).
6. Choose Create bucket.

How to create a bucket — CLI

aws s3api create-bucket \
  --bucket acme-prod-logs-7f3a9b \
  --region eu-west-1 \
  --create-bucket-configuration LocationConstraint=eu-west-1

Output:

{
    "Location": "http://acme-prod-logs-7f3a9b.s3.amazonaws.com/"
}

If the name is already in use anywhere in the world, you’ll get an error instead:

Output:

An error occurred (BucketAlreadyExists) when calling the CreateBucket operation:
The requested bucket name is not available. The bucket namespace is shared by
all users of the system. Please select a different name and try again.

Note: For Regions other than us-east-1 you must pass LocationConstraint. For us-east-1 you omit it — passing it there causes an error.

Seeing the difference in the CLI

You can prove the regional/global split yourself. IAM users are the same no matter what Region you target:

aws iam list-users --region ap-south-1
aws iam list-users --region us-east-1

Output: (identical in both Regions)

{
    "Users": [
        { "UserName": "deploy-bot", "UserId": "AIDA0A1B2C3D4E5F6G7H8" }
    ]
}

But EC2 instances are Region-specific. The same command in two Regions returns different results:

aws ec2 describe-instances --region us-east-1 \
  --query "Reservations[].Instances[].InstanceId"

Output:

[
    "i-0a1b2c3d4e5f"
]

aws ec2 describe-instances --region eu-west-1 \
  --query "Reservations[].Instances[].InstanceId"

Output: (empty — that instance lives in us-east-1)

[]

How this affects failover

Global services like Route 53 and CloudFront are themselves highly available worldwide, so you rarely design failover for them. The work is failing over your regional resources behind them. A common pattern: run your application in two Regions, then use Route 53 health checks to route traffic away from an unhealthy Region. CloudFront sits in front and serves cached content from edge locations regardless of which Region is currently active.

Cost note: Replicating data across Regions is not free. S3 Cross-Region Replication and inter-Region data transfer are billed per gigabyte (roughly $0.02/GB transferred out between Regions in 2026). Only replicate what you genuinely need for resilience.

Best practices

• Always confirm the Region selector before assuming a resource is missing.
• Pick a default Region close to your users and set it in your CLI profile so you don’t accidentally create resources in the wrong place.
• Treat IAM as account-wide: a policy change affects every Region instantly, so review it carefully.
• Choose S3 bucket names with a unique prefix or suffix to avoid global namespace collisions.
• Request ACM certificates for CloudFront in us-east-1, since CloudFront only reads certificates from there.
• For multi-Region resilience, replicate regional resources deliberately and front them with global Route 53 and CloudFront.
• Tag the WAF scope correctly: CLOUDFRONT for global, REGIONAL for load balancers and API Gateway.

Related Topics

• Regions and Availability Zones
• Choosing a Region
• Core services map
• What is AWS
• Install the AWS CLI