Getting Started with AWS Aurora Global Database: Best Price

adminFebruary 19, 2024

0 64 13 minutes read

Aurora global databases are specifically designed for applications that have a global presence. These databases utilize read-only secondary DB clusters in different AWS Regions, enabling support for read operations closer to the application users. With the write forwarding feature, you can configure an Aurora global database to have secondary clusters send data directly to the primary cluster. For more detailed information on this topic, refer to the documentation on “Using write forwarding in an Amazon Aurora global database.”

Amazon Aurora Global Databases: Overview

Amazon Aurora Global Database is a service provided by Amazon Web Services (AWS) that is designed to support globally distributed applications. It allows a single Amazon Aurora database to span multiple AWS Regions, providing replication of data without impacting database performance. This enables fast local reads with low latency in each Region and offers disaster recovery capabilities in the event of a Region-wide outage.

Applications with a global presence, such as those in the financial, travel, or gaming industries, often require high availability and the ability to withstand Region-wide outages. In the past, achieving this level of availability required making tradeoffs between performance, availability, cost, and data integrity. With Aurora Global Database, storage-based replication is used, resulting in low latency replication of less than 1 second. The dedicated infrastructure ensures that your database remains fully available to serve application workloads. In the unlikely event of a Regional degradation or outage, one of the secondary Regions can be promoted to read and write capabilities in under 1 minute.

An Aurora global database provides two operations for changing the Region of the primary DB cluster: global database switchover and global database failover. These operations serve different scenarios and purposes.

1. Global database switchover

For planned operational procedures like Regional rotation, the recommended approach is to use global database switchover (previously known as “managed planned failover”). This feature allows you to relocate the primary cluster of a healthy Aurora global database to one of its secondary Regions without any data loss. To delve deeper into the topic, refer to the documentation on “Performing switchovers for Amazon Aurora global databases.”

2. Global database failover

In the event of an outage in the primary Region of your Aurora global database, you can recover by utilizing global database failover. This feature enables you to perform a failover of your primary DB cluster to another Region, known as cross-region failover. For detailed instructions and information, please refer to the documentation on “Performing managed failovers for Aurora global databases.”

Features.

Sub-second data access in any Region

Aurora Global Database allows for easy scaling of database reads worldwide and enables you to position your applications near your users. Regardless of the number and location of secondary Regions, your applications will have fast data access with replication latencies typically below 1 second. You can enhance scalability by creating up to 16 database instances in each Region, all of which remain continuously up to date.

Expanding your database to additional Regions does not affect performance. Cross-region replication utilizes dedicated infrastructure in the Aurora storage layer, ensuring that database resources in both primary and secondary Regions are fully available to meet application requirements.

Cross-Region disaster recovery

In the event of a performance degradation or outage in the primary Region, you can promote one of the secondary Regions within your Aurora cluster to assume read/write responsibilities. The recovery process can be completed in under 1 minute, even in the case of a complete Regional outage. This ensures that your application has a recovery point objective (RPO) of 1 second and a recovery time objective (RTO) of less than 1 minute, providing a robust foundation for a global business continuity plan.

Flexible pricing

With Aurora Global Database, you have the flexibility to configure your database clusters differently in the primary and secondary Regions. You can choose between the Amazon Aurora I/O-Optimized configuration for the primary Region and Aurora Standard (or vice versa) for the secondary Regions. For detailed pricing and information on Regional availability, please refer to the official documentation provided by Amazon Web Services (AWS).

Advantages of Amazon Aurora global databases

By using Aurora global databases, you can get the following advantages:

Global reads with local latency
By leveraging an Aurora global database, organizations with offices located worldwide can ensure that their primary sources of information are consistently updated in the primary AWS Region. This allows offices in other Regions to access this information locally, minimizing latency and improving overall performance.

Scalable secondary Aurora DB clusters

In a secondary AWS Region, you can scale your secondary clusters of an Aurora global database by adding more read-only instances, known as Aurora Replicas. Unlike a single Aurora cluster, which has a limit of 15 read-only replicas, a secondary cluster can support up to 16 read-only Aurora Replica instances.

Fast replication from primary to secondary Aurora DB clusters

The replication process of an Aurora global database has a minimal performance impact on the primary DB cluster. The DB instances’ resources are fully dedicated to handling application read and write workloads, ensuring optimal performance without compromising replication efficiency.

Recovery from Region-wide outages

Secondary clusters in an Aurora global database offer faster availability in a new primary AWS Region, resulting in a lower Recovery Time Objective (RTO) and reduced data loss, leading to a lower Recovery Point Objective (RPO) compared to traditional replication solutions.

Limitations of Amazon Aurora global databases

The following limitations currently apply to Aurora global databases:

Aurora global databases are available in specific AWS Regions and support specific versions of Aurora MySQL and Aurora PostgreSQL. You can find more details in the “Aurora global databases” documentation.

Aurora global databases have specific configuration requirements, including supported Aurora DB instance classes and a maximum number of AWS Regions. You can refer to the “Configuration requirements of an Amazon Aurora global database” documentation for more information.

For Aurora MySQL with MySQL 5.7 compatibility, global database switchovers require version 2.09.1 or a higher minor version.

Managed cross-region switchovers or failovers can only be performed on an Aurora global database if the primary and secondary DB clusters have the same major, minor, and patch-level engine versions. However, the patch levels can be different if the minor engine versions are compatible.

Database engine	Minor engine versions
Aurora PostgreSQL	Version 14.5 or higher minor version Version 13.8 or higher minor version Version 12.12 or higher minor version Version 11.17 or higher minor version

Getting started with AWS Aurora Global Databases

Amazon Aurora global database pricing

You need to create an Aurora global database in one of the following ways:

To create a new Aurora global database with new Aurora DB clusters and DB instances, you can follow these steps:

Refer to the “Creating an Amazon Aurora global database” documentation for instructions on creating the primary Aurora DB cluster.
Once the primary cluster is created, proceed to the “Adding an AWS Region to an Amazon Aurora global database” documentation for guidance on adding the secondary AWS Region to the global database.

If you have an existing Aurora DB cluster that supports the Aurora global database feature, you can add AWS Region to it. However, it’s important to note that this is only possible if your existing DB cluster uses a DB engine version that explicitly supports the Aurora global mode or is deemed global-compatible, as some versions may not have this mode explicitly defined.

To determine if you can add an AWS Region to your Aurora DB cluster for Aurora global clusters, you can check if the “Add region” option is available under the Actions menu when your Aurora DB cluster is selected in the AWS Management Console. If the option is present, you can use that DB cluster for your Aurora global cluster.

Before creating an Aurora global database, it is highly recommended to thoroughly understand all configuration requirements.

Configuration requirements of an Amazon Aurora global database

An Aurora global database is designed to span across a minimum of two AWS Regions. The primary AWS Region hosts an Aurora DB cluster with a single writer Aurora DB instance. In a secondary AWS Region, a read-only Aurora DB cluster is established, consisting entirely of Aurora Replicas. While at least one secondary AWS Region is mandatory, an Aurora global database can include up to five secondary AWS Regions.

Description	Primary AWS Region	Secondary AWS Regions
Aurora DB clusters	1	5 (maximum)
Writer instances	1	0
Read-only instances (Aurora replicas), per Aurora DB cluster	15 (max)	16 (total)
Read-only instances (max allowed, given the actual number of secondary Regions)	15 – s	s = total number of secondary AWS Regions

The Aurora DB clusters that make up an Aurora global database have the following specific requirements:

DB instance class requirements –

Aurora global databases require DB instance classes that are optimized for memory-intensive applications. For details about the memory-optimized DB instance classes, refer to the relevant documentation.
AWS Region requirements –

To set up an Aurora global database, you need a primary Aurora DB cluster in one AWS Region, along with at least one secondary Aurora DB cluster in a different Region. You have the flexibility to create up to five secondary (read-only) Aurora DB clusters, each residing in a distinct Region.
Naming requirements –

When creating Aurora DB clusters for an Aurora global database, it is essential to ensure that the names you assign are unique across all AWS Regions. Even if the DB clusters are located in different Regions, the names cannot be duplicated.

Capacity requirements for Aurora Serverless v2 –

For an Aurora Serverless v2 global database, the minimum capacity required for the DB cluster in the primary AWS Region is 8 Aurora Capacity Units (ACUs).

Creating an Amazon Aurora global database

To create an Aurora global database using the AWS Management Console, AWS CLI, or RDS API, follow these steps in an AWS Region that supports the Aurora global database feature:

Sign in to the AWS Management Console.
Choose the appropriate service for creating an Aurora global database (e.g., Amazon RDS).
Select the desired AWS Region for your primary Aurora DB cluster.
Choose a virtual private cloud (VPC) based on Amazon VPC for your Aurora DB cluster. If you prefer to use your own VPC, it is recommended to create it beforehand along with any related subnets, subnet groups, and security groups.
Proceed with the configuration of your Aurora DB cluster, specifying the necessary parameters such as DB instance class, storage, backup options, and security settings.
Add additional AWS Regions to your Aurora global database, following the provided steps for expanding to secondary Regions.

Adding an AWS Region to an Amazon Aurora global database

An Aurora global database requires at least one secondary Aurora DB cluster located in a different AWS Region than the primary DB cluster. You can attach up to five secondary DB clusters to your Aurora global database. However, as you add secondary DB clusters, the number of Aurora Replicas allowed for the primary DB cluster decreases.

For instance, if you have five secondary Regions, the primary DB cluster can have a maximum of 10 Aurora Replicas instead of the usual 15. This reduction is due to the allocation of resources to the secondary clusters. You can find more information on this in the “Configuration requirements of an Amazon Aurora global database” documentation.

The number of Aurora Replicas in the primary DB cluster determines the maximum number of secondary DB clusters you can add. The sum of the reader instances in the primary DB cluster and the number of secondary clusters cannot exceed 15. For example, if you have 14 reader instances in the primary DB cluster and one secondary cluster, you won’t be able to add another secondary cluster to the global database.

Creating a headless Aurora DB cluster in a secondary Region

Warning: When working with Aurora PostgreSQL, to create a headless cluster in a secondary AWS Region, you can utilize the AWS CLI or RDS API to add the secondary Region. During the process, you can skip the step of creating the reader DB instance for the secondary cluster. However, please note that at present, creating a headless cluster is not supported in the RDS Console. For detailed procedures using the CLI and API, refer to the documentation on adding an AWS Region to an Amazon Aurora global database.

To add a headless secondary Aurora DB cluster to your Aurora global database, follow these steps:

Sign in to the AWS Management Console and open the Amazon RDS console at https://console.aws.amazon.com/rds/.
In the navigation pane of the AWS Management Console, click on “Databases”.
Select the specific Aurora global database that requires a secondary Aurora DB cluster. Ensure that the primary Aurora DB cluster is in the “Available” state.
Click on the “Actions” button.
From the dropdown menu, choose “Add region”.
On the “Add a region” page, select the desired secondary AWS Region.
Note that you cannot choose an AWS Region that already has a secondary Aurora DB cluster for the same Aurora global database. Additionally, it cannot be in the same Region as the primary Aurora DB cluster.
Fill in the remaining fields for the secondary Aurora cluster in the new AWS Region. These fields include the same configuration options as for any Aurora DB cluster instance.
If you are working with an Aurora MySQL-based Aurora global database, disregard the “Enable read replica write forwarding” option. This option becomes irrelevant after you delete the reader instance.
Click on “Add region”. Once you have successfully added the Region to your Aurora global database, you will be able to see it in the list of Databases in the AWS Management Console, as shown in the provided screenshot.
To check the status of the secondary Aurora DB cluster and its reader instance, you can use either the AWS Management Console or the AWS CLI.

$ aws rds describe-db-clusters --db-cluster-identifier secondary-cluster-id --query '*[].[Status]' --output text

After adding a secondary Aurora DB cluster, it may take several minutes for its status to transition from “creating” to “available”. Once the Aurora DB cluster is available, you can proceed to delete the reader instance associated with it.

To delete the reader instance in the secondary Aurora DB cluster, select the instance and choose the “Delete” option.

In the event of an unplanned outage in the primary AWS Region, you can utilize the headless secondary Aurora DB cluster to manually recover your Amazon Aurora global database and restore its functionality.

Using a snapshot for your Amazon Aurora global database

Aurora Global Database Pricing

When it comes to pricing, Aurora offers options that suit your business needs. You can choose between predictable pay-as-you-go On-Demand pricing or Reserved Instance pricing. The charges are based on your database cluster configuration, including instances, storage, I/O, and any additional features you enable.

Aurora cluster configuration

With Aurora, you have the flexibility to configure your database clusters cost-effectively, regardless of the scaling needs or changing data access patterns of your applications. You can choose between the Amazon Aurora Standard and Amazon Aurora I/O-Optimized configurations to align with the price-performance and price-predictability requirements of your specific workload. The charges for your database instances, storage, and I/O will vary depending on the configuration option you select.

Aurora Standard provides cost-effective pricing for most applications on Aurora with typical data access patterns and moderate I/O usage. With Aurora Standard, you are charged for your database instances, storage, and pay-per-request I/O.

Aurora I/O-Optimized is designed to provide improved price performance for applications with high I/O demands. If your I/O spend exceeds 25% of your total Aurora database spend, you can save up to 40% on costs for I/O-intensive workloads by using Aurora I/O-Optimized. With this option, you only pay for your database instances and storage, and there are no charges for read and write I/O operations. Aurora I/O-Optimized ensures predictable pricing for all applications, regardless of evolving data access patterns or I/O usage, effectively eliminating variability in I/O spend.

Pricing by database instances

With Aurora, you have multiple pricing options to choose from. Amazon Aurora Serverless automatically adjusts capacity based on your application’s needs, and you pay only for the capacity you consume. Provisioned On-Demand Instances allow you to pay for database usage per instance hour without long-term commitments or upfront fees. Provisioned Reserved Instances offer additional savings.

Instance charges apply to both Aurora primary instances and Replicas, and the pricing will depend on the database cluster configuration you select. You can choose between Aurora Standard and Aurora I/O-Optimized configurations to align with your application’s price-performance and price-predictability requirements. All instances within a database cluster will be charged based on either the Aurora Standard or Aurora I/O-Optimized configuration.

Optimized Reads instances for Aurora PostgreSQL

Optimized Reads instances in Amazon Aurora PostgreSQL-Compatible Edition leverage local NVMe-based SSD block-level storage to enhance query latency for applications with data sets larger than the memory capacity of a database instance. It incorporates two key features: tiered caching and temporary objects.

Tiered caching significantly improves query latency, resulting in up to 8x faster performance. It also offers potential cost savings of up to 30% for read-heavy, I/O-intensive applications like operational dashboards, anomaly detection, and vector-based similarity searches.

In your database cluster, you have the flexibility to configure all instances to use either Aurora Standard or Aurora I/O-Optimized configuration, depending on your application’s price performance and price-predictability requirements.

See Also: