You want the same private object available in Sydney and Auckland. A
Pulp-style HTTP repo can do that too, but you end up
running a server and owning the network path. Here S3 does the heavy lifting:
publish once in Sydney, let replication Cross-Region Replication. S3 copies objects (and versions) from a primary bucket to a replica in another Region. copy to
Auckland, and have each consumer VPC read its local bucket through a
gateway VPC endpoint S3 gateway VPC endpoint. Route-table target that keeps S3 traffic on the AWS network; no hourly charge for the gateway itself. .
Once the object has replicated, Auckland keeps reading Auckland if Sydney is
down (and the other way around). That is not full multi-Region
HA High availability. Design goal of staying usable through failures; multi-Region HA usually needs failover routing, not only a replica bucket. though. You still publish to Sydney,
replication is async so RPO Recovery point objective. How much data you can afford to lose after a failure, measured as time. Asynchronous replication means RPO is greater than zero. is not zero, and
anything in a failed Region is still down.
Primary in ap-southeast-2, replica in ap-southeast-6,
filtered to a demo/ prefix.
Consumer VPCs
An S3 gateway endpoint S3 gateway VPC endpoint. Route-table target that keeps S3 traffic on the AWS network; no hourly charge for the gateway itself. per VPC,
locked with aws:SourceVpce Bucket policy condition key aws:SourceVpce. Limits which VPC endpoint IDs can access the bucket..
Publish and prove
Upload in Sydney, wait for the replica, curl from an SSM-managed EC2.
Tear down
Empty the versioned buckets and delete the lab with demo.sh down.
Expectation
Notes
Same object key
Different regional hostnames
Cross-region reads
Via the replica, not cross-Region PrivateLink
Cost while running
S3 + replication transfer + probe EC2 / SSM endpoints