AWS added four Regions to Aurora DSQL multi-Region cluster support on July 31. The new Regions are Europe (Stockholm), Europe (Spain), Asia Pacific (Mumbai), and Asia Pacific (Singapore). Cloud architects, database owners, and application platform leaders who lacked a supported Region pair in those areas now have a live option.
TL;DR
- -AWS added Europe (Stockholm), Europe (Spain), Asia Pacific (Mumbai), and Asia Pacific (Singapore) to Aurora DSQL multi-Region cluster support on July 31, bringing the total to 16 Regions.
- -Each multi-Region cluster gives both paired Regions a writable endpoint on a single logical database, with strong consistency and 99.99% single-Region and 99.999% multi-Region availability.
- -Cloud architects evaluating Aurora DSQL for resilience or data residency should confirm their target Region pair is on the supported list and whether strong cross-Region consistency fits their latency needs.
What Aurora DSQL Multi-Region Clusters Actually Do
Aurora DSQL is a serverless, distributed relational database built for transactional workloads. It is PostgreSQL-compatible. Familiar drivers, object-relational mappings (ORMs), frameworks, and SQL features carry over.
A multi-Region cluster connects two Regions into a single logical database. Both Regions get a writable endpoint. Reads and writes are available in either Region at the same time. That is the active-active part. AWS documentation states the database remains available even if one Region becomes unavailable, and Aurora DSQL automatically routes requests to healthy infrastructure without manual intervention.
Aurora DSQL provides ACID transactions with strong consistency, snapshot isolation, and cross-Region durability. ACID stands for atomicity, consistency, isolation, and durability. It means the database does not leave transactions in a partial or ambiguous state. AWS documentation notes that in a failover context, you don't have to be concerned about eventual consistency or missing data.
AWS states that the active-active architecture provides 99.99% single-Region and 99.999% multi-Region availability.
The Full Region Picture After This Launch
Multi-Region clusters are now available in 16 Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central), Canada West (Calgary), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Spain), and Europe (Stockholm).
Single-Region clusters go further. They cover all 16 of those Regions plus Asia Pacific (Hong Kong), Asia Pacific (Melbourne), Asia Pacific (Sydney), and South America (São Paulo). Teams with data residency needs in those four locations can use the single-Region tier today.
Confirm your specific Region pair against the current Aurora DSQL documentation before settling on a topology.
Why Geography Matters for This Decision
The Stockholm and Spain additions expand EU choices. Six European Regions now appear on the multi-Region supported list: Frankfurt, Ireland, London, Paris, Spain, and Stockholm. Teams with policies requiring EU-only storage now have more Region pairs to choose from. Whether a specific pair satisfies a given residency requirement depends on your applicable policy and compliance review.
Mumbai and Singapore are major AWS Regions for South Asia and Southeast Asia. Adding them means a transactional application serving users across those areas can now run with a writable endpoint in both peered Regions rather than routing all writes to a single home Region.
Strong cross-Region consistency is a key feature here. Before committing to a topology, consider modeling the distance between your chosen Region pair against your transaction profile. The right pair depends on where your users are and what your workload requires.
Aurora DSQL automatically scales compute, I/O, and storage based on workload without provisioning instances or managing maintenance windows. That removes one operational variable when comparing it to a provisioned alternative.
What to Check Before Adopting
The July 31 expansion narrows the geography gap that may have blocked Aurora DSQL adoption. Three questions are worth working through now.
First, does your target Region pair appear on the supported list? Confirm both Regions before designing the cluster topology. Multi-Region clusters are configured through the AWS CLI or SDK, using languages including Python, C++, JavaScript, Java, Rust, Ruby, .NET, and Golang.
Second, does strong consistency fit your workload's latency needs? The feature suits correctness-critical applications. Test your transaction profile against the specific Region pair you plan to use before committing.
Third, does your data residency policy permit the specific Region pair you need? Frankfurt, Ireland, London, Paris, Spain, and Stockholm all appear on the multi-Region supported list. The policy decision about which Regions are acceptable belongs to your compliance and legal review.
Aurora DSQL is available through the AWS Free Tier for initial testing, which removes the cost barrier from early evaluation.
Sources and supporting resources