The Problem
Your application runs in three Regions and each Region has its own S3 bucket. Clients scattered around the world hard-code Regional bucket names, you have to teach every service which bucket to hit, and DR failover means editing configuration in every consumer. You want one endpoint that automatically routes each request to the nearest healthy bucket.
The Solution
Create an S3 Multi-Region Access Point (MRAP). It gives you a global endpoint — <alias>.mrap.accesspoint.s3-global.amazonaws.com — that fronts a set of buckets across Regions. Requests travel over the AWS global network to the closest bucket, and you can fail traffic away from an unhealthy Region without touching any application code.
How It Works
The Endpoint
Every MRAP has a globally unique alias that becomes the DNS name. Clients treat it exactly like a bucket name in Signature Version 4 requests, but the endpoint is not tied to any Region:
1
mfzwi23gnjvgw.mrap.accesspoint.s3-global.amazonaws.com
Under the hood, MRAP uses AWS Global Accelerator anycast to steer TCP connections onto the AWS backbone from the nearest edge, then forwards to the currently active Region.
Creating an MRAP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
aws s3control create-multi-region-access-point \
--account-id 123456789012 \
--details '{
"Name": "global-app-data",
"PublicAccessBlock": {
"BlockPublicAcls": true,
"IgnorePublicAcls": true,
"BlockPublicPolicy": true,
"RestrictPublicBuckets": true
},
"Regions": [
{ "Bucket": "app-data-use1" },
{ "Bucket": "app-data-euw1" },
{ "Bucket": "app-data-apse2" }
]
}'
Creation takes a few minutes as AWS provisions the global endpoint.
Replicating Data Between the Regional Buckets
MRAP does not replicate anything by itself. You get a routing layer, not data sync. Pair it with S3 Cross-Region Replication rules in each direction for active-active. AWS provides a one-click flow that generates the full replication topology (all-to-all) when you set up MRAP replication.
Using the Endpoint From an SDK
The client SDK must speak SigV4A (signature version 4A) because a single signed request is valid in multiple Regions. Recent AWS SDKs support it natively — but you must pass the MRAP alias in ARN form or as a resolved endpoint:
1
2
3
4
5
6
7
8
9
import boto3
s3 = boto3.client("s3", region_name="us-east-1")
s3.put_object(
Bucket="arn:aws:s3::123456789012:accesspoint/mfzwi23gnjvgw.mrap",
Key="uploads/report.json",
Body=payload
)
The SDK signs the request with SigV4A and sends it to the global endpoint. AWS routes it to the nearest Region and stores the object in that Region’s bucket.
Failover Controls
Each Region in the MRAP is either Active or Passive. Traffic goes only to Active Regions:
1
2
3
4
5
6
7
8
aws s3control submit-multi-region-access-point-routes \
--account-id 123456789012 \
--mrap global-app-data \
--route-updates '[
{ "Bucket": "app-data-use1", "TrafficDialPercentage": 100 },
{ "Bucket": "app-data-euw1", "TrafficDialPercentage": 0 },
{ "Bucket": "app-data-apse2", "TrafficDialPercentage": 100 }
]'
The change is applied globally within seconds. This is your DR switch — flip a Region to 0 and all traffic drains away without redeploying anything.
Policies
MRAPs have their own access point policy and honor the underlying bucket policies. A request must be allowed by both. This lets you write one MRAP-scoped policy for global access rather than syncing bucket policies across Regions.
Cost Watch-Outs
You pay:
- Per-request charges on the MRAP itself
- A data routing cost per GB routed through the MRAP
- Underlying S3 request and storage costs
- Replication costs if you enable CRR
For low-volume convenience workloads MRAP is inexpensive; for petabyte-scale traffic the routing surcharge is meaningful. Model it before turning it on.
Why Not the Alternatives?
Route 53 latency-based routing to Regional bucket URLs — Route 53 can steer clients to a Region-specific endpoint, but each client now speaks to a different S3 bucket name. Signing, tooling, and failover are all client-side concerns. MRAP hides all of that behind one endpoint and one SigV4A signature.
CloudFront in front of S3 — CloudFront caches downloads at the edge. It does not give you active-active writes to multiple Regional buckets. MRAP is designed for reads and writes.
Application-level routing — Every consumer needs a Region map, health checks, and failover logic. Painful to maintain across many clients and languages.
Global Accelerator in front of an S3 bucket — Global Accelerator does not natively front S3. MRAP is the S3-integrated equivalent.
Key Takeaways
- MRAP gives you a single global endpoint —
<alias>.mrap.accesspoint.s3-global.amazonaws.com - Requests are routed over AWS backbone to the nearest healthy Region
- MRAP does not replicate data — pair it with CRR for active-active
- Use traffic dial percentages to drain a Region for DR without redeploying
- SDKs must support SigV4A to sign multi-Region requests
Never miss a story from us, subscribe to our newsletter