Amazon S3 Multi-Region Access Points (MRAPs) provide a single global S3 endpoint in front of buckets located in multiple AWS Regions. Requests to that endpoint use the AWS global network and are routed toward an active bucket based on proximity and current routing state. For multi-Region applications, this replaces client-side region selection with one access-point alias while preserving per-bucket replication, policy, encryption, and lifecycle controls underneath.
Within AWS Architecture and Operations, MRAPs are most useful when the application already has a multi-Region data strategy. The global endpoint does not replicate objects by itself; S3 Replication rules still determine whether the buckets contain equivalent data.
The existing multi-Region disaster recovery article provides the broader resilience model. This page focuses on the S3-specific traffic, replication, failover, policy, and operational design.
The global endpoint solves traffic routing, not data synchronization
An MRAP creates a globally routable access-point alias that clients can use instead of individual regional bucket endpoints.
During normal active-active operation, S3 can route requests to a bucket in the closest active Region.
But object state only stays consistent across Regions when replication is configured appropriately. A perfectly healthy MRAP can route a read to a bucket that never received the object if replication was incomplete or intentionally one-way.
Active-active is optimized for locality and resilience
In active-active mode, all participating Regions are active and can receive requests through the MRAP.
This can reduce network distance for globally distributed clients and gives S3 another active destination if one Region has traffic disruption.
Use this mode when applications are designed for multi-writer/multi-reader semantics and the underlying buckets use replication rules that make data available where users may be routed.
Active-passive is the clearer disaster-recovery model
For explicit failover, configure one Region Active and another Passive. Passive buckets do not receive MRAP data requests while they are passive.
AWS failover controls switch routing status between the two Regions, typically redirecting traffic within about two minutes.
This pattern is easier to reason about for workloads with one primary writer and a warm standby, but it still requires the standby bucket to be fully replicated and writable before failover.
Two-way replication is essential when the failover Region can accept writes
AWS recommends two-way replication rules for failover architectures so objects written after failover replicate back toward the original Region.
Replica modification sync can also preserve relevant metadata changes across replicas.
Without reverse replication, the failover can succeed operationally while creating a new primary dataset that cannot fail back cleanly later.
Routing controls are independent from replication health
The MRAP failover API changes which bucket receives new requests; it does not wait for replication lag to reach zero.
Runbooks should check S3 replication metrics, failed operations, replication time-control status where used, and object-version parity for critical prefixes before switching writes.
Failover should be based on data readiness plus regional health, not simply the availability of the routing-control button.
TrafficDialPercentage is the control behind active and passive states
MRAP routing controls expose a traffic dial percentage per bucket/Region. Active maps to 100 and Passive to 0 for failover use.
Console failover swaps the two routing states automatically; API/CLI automation can submit route updates directly.
Keep failover automation idempotent: set the desired final routing state, then verify it, rather than issuing blind “toggle” operations whose outcome depends on prior state.
Control-plane requests have their own regional restrictions
AWS documents that MRAP control-plane operations and failover-control operations use specific supported Regions even though data-plane requests use the global endpoint.
Disaster-recovery tooling should therefore know which regional S3 Control endpoints it can call if the application’s primary Region is unavailable.
Store those endpoint choices and emergency credentials in recovery automation that does not depend on the failed Region.
Existing connections are not terminated by failover
When routing status changes, new requests are directed according to the new state, but existing connections are allowed to complete successfully or fail on their current path.
Applications should be prepared for a short transition period where outstanding requests still reference the former active Region.
Use idempotent object writes and request-level retries so failover does not create duplicate or ambiguous application transactions.
Policies should govern the MRAP and the underlying buckets together
MRAP access-point policy, bucket policy, IAM, KMS key policy, VPC/network controls, and object ownership all participate in authorization.
Test the exact production role through the global alias in every planned Region. A replicated encrypted object can still become unreadable after failover if the application lacks access to the regional KMS key or the target bucket policy.
Keep security configuration regionalized through infrastructure code rather than relying on replication to copy policy.
Opt-in Regions need lifecycle discipline
AWS notes that disabling an opt-in Region that remains active in an MRAP can cause requests routed there to fail.
Before disabling or decommissioning a Region, make it passive and verify traffic has shifted to another active bucket.
Regional lifecycle changes should therefore include MRAP route state, replication, bucket retention, and application monitoring—not just account-level Region enablement.
MRAPs succeed when one endpoint does not hide multiple data lifecycles
The mature design has explicit active-active or active-passive intent, two-way replication where failback writes matter, monitored replication lag, tested KMS/IAM in every Region, reliable failover automation, and application retries that tolerate the transition.
A global endpoint simplifies clients. It does not remove the engineering required to keep every regional bucket ready to serve the same business data safely.
Replication metrics should be segmented by prefix and business data class. A bucket can look nearly synchronized overall while one critical prefix contains failed operations or large backlog. For failover-critical data, alert on bytes/operations pending replication and replication latency separately from ordinary archive prefixes whose delay is less important.
Multi-writer active-active applications need conflict semantics at the application layer. S3 versioning and replication can preserve versions, but MRAP does not implement application-level conflict resolution when two Regions write competing versions of the same key. Use partitioned key ownership, unique object names, or an application conflict policy rather than assuming proximity routing creates a globally serializable object store.
Deletes should be tested explicitly. Replication of delete markers and permanent version deletions follows replication configuration, and recovery behavior can differ from ordinary PUT replication. A DR exercise should verify what happens when a user deletes an object before failover and whether the secondary reflects the intended delete state.
MRAP policy changes should have the same review level as a global load balancer. One access-point policy can affect traffic to every underlying bucket, and an overly broad allow can bypass carefully designed per-bucket expectations. Keep access-point and bucket policies in infrastructure code and test the production principal through the global alias.
Encryption needs regional key readiness. If buckets use SSE-KMS with different regional keys, replication roles and application roles need permission in every participating Region. During failover, a write can reach the secondary bucket correctly and still fail because the client, replication role, or S3 service lacks KMS permissions on that Region’s key.
Application retries should preserve object semantics. PUT/POST workflows need idempotency or unique keys because a client can retry after a connection error during the routing transition. GET/HEAD are simpler, but multipart uploads and conditional writes deserve dedicated testing across failover.
Observability should combine MRAP request metrics with bucket-level S3 metrics and replication status. CloudWatch can show traffic moving between Regions, but the operations team also needs 4xx/5xx, latency, bytes, replication failures, KMS errors, and application success. One dashboard should tell whether traffic shifted and whether the secondary could actually serve it.
Failback is a separate recovery event. After the original Region is restored, verify reverse replication has caught up, re-establish any intended primary-writer role, and then change routing state. Do not fail back merely because the Region is reachable; data divergence and KMS/IAM drift can make the original primary unsafe even after infrastructure health returns.
Use active-active only where the application can benefit from local access. If all writers and most readers live in one Region, an active-passive design may be easier to reason about and cheaper to test. Multi-Region Access Points are most valuable when the application genuinely needs one global S3 entry point rather than when they are added as a checkbox to an otherwise single-Region architecture.
Cost modeling should include data transfer and replication as well as MRAP request charges. Active-active designs can generate substantial replication traffic and cross-Region writes, especially for large mutable datasets. Compare that cost with the recovery and latency benefit, and consider whether some prefixes belong in regional buckets outside the MRAP because they do not need global access.
Object ownership and bucket versioning should be standardized across all participating buckets. Divergent settings can make failover behavior inconsistent even when replication technically succeeds. Use the same ownership controls, versioning, lifecycle, logging, and event-notification assumptions where the application expects buckets to be interchangeable.
Recovery testing should include a deliberately stale or failed replication condition. The runbook should know when to stop a planned failover because the secondary is not current enough and what business decision is required if the primary Region is unavailable anyway. This turns replication lag into an explicit recovery risk rather than a metric operators notice only after traffic has moved.
