# What is Amazon Aurora? Amazon Aurora (Aurora) is a fully managed relational database engine that's compatible with MySQL and PostgreSQL. You already know how MySQL and PostgreSQL combine the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. The code, tools, and applications you use today with your existing MySQL and PostgreSQL databases can be used with Aurora. With some workloads, Aurora can deliver up to five times the throughput of MySQL and up to three times the throughput of PostgreSQL without requiring changes to most of your existing applications. Aurora includes a high-performance storage subsystem. Its MySQL- and PostgreSQL-compatible database engines are customized to take advantage of that fast distributed storage. The underlying storage grows automatically as needed. An Aurora cluster volume can grow to a maximum size of 128 tebibytes (TiB). Aurora also automates and standardizes database clustering and replication, which are typically among the most challenging aspects of database configuration and administration. Aurora is part of the managed database service Amazon Relational Database Service (Amazon RDS). Amazon RDS makes it easier to set up, operate, and scale a relational database in the cloud. If you are not already familiar with Amazon RDS, see the [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html). To learn more about the variety of database options available on Amazon Web Services, see [Choosing the right database for your organization on AWS](https://aws.amazon.com/getting-started/decision-guides/databases-on-aws-how-to-choose/). **Topics** + [ ## Amazon RDS shared responsibility model ](#aur-shared-resp) + [ ## How Amazon Aurora works with Amazon RDS ](#aurora-rds-comparison) + [ # Amazon Aurora DB clusters ](Aurora.Overview.md) + [ # Amazon Aurora versions ](Aurora.VersionPolicy.md) + [ # Regions and Availability Zones ](Concepts.RegionsAndAvailabilityZones.md) + [ # Supported features in Amazon Aurora by AWS Region and Aurora DB engine ](Concepts.AuroraFeaturesRegionsDBEngines.grids.md) + [ # Amazon Aurora endpoint connections ](Aurora.Overview.Endpoints.md) + [ # Amazon AuroraDB instance classes ](Concepts.DBInstanceClass.md) + [ # Amazon Aurora storage ](Aurora.Overview.StorageReliability.md) + [ # Amazon Aurora reliability ](Aurora.Overview.Reliability.md) + [ # Amazon Aurora security ](Aurora.Overview.Security.md) + [ # High availability for Amazon Aurora ](Concepts.AuroraHighAvailability.md) + [ # Replication with Amazon Aurora ](Aurora.Replication.md) + [ # DB instance billing for Aurora ](User_DBInstanceBilling.md) + [ # Amazon Aurora on the AWS Free Tier ](aurora-free-tier.md) ## Amazon RDS shared responsibility model Amazon RDS is responsible for hosting the software components and infrastructure of DB instances and DB clusters. You are responsible for query tuning, which is the process of adjusting SQL queries to improve performance. Query performance is highly dependent on database design, data size, data distribution, application workload, and query patterns, which can vary greatly. Monitoring and tuning are highly individualized processes that you own for your RDS databases. You can use Amazon RDS Performance Insights and other tools to identify problematic queries. ## How Amazon Aurora works with Amazon RDS The following points illustrate how Amazon Aurora relates to the standard MySQL and PostgreSQL engines available in Amazon RDS: + You choose Aurora MySQL or Aurora PostgreSQL as the DB engine option when setting up new database servers through Amazon RDS. + Aurora takes advantage of the familiar Amazon Relational Database Service (Amazon RDS) features for management and administration. Aurora uses the Amazon RDS AWS Management Console interface, AWS CLI commands, and API operations to handle routine database tasks such as provisioning, patching, backup, recovery, failure detection, and repair. + Aurora management operations typically involve entire clusters of database servers that are synchronized through replication, instead of individual database instances. The automatic clustering, replication, and storage allocation make it simple and cost-effective to set up, operate, and scale your largest MySQL and PostgreSQL deployments. + You can bring data from Amazon RDS for MySQL and Amazon RDS for PostgreSQL into Aurora by creating and restoring snapshots, or by setting up one-way replication. You can use push-button migration tools to convert your existing RDS for MySQL and RDS for PostgreSQL applications to Aurora. Before using Amazon Aurora, complete the steps in [Setting up your environment for Amazon Aurora](CHAP_SettingUp_Aurora.md), and then review the concepts and features of Aurora in [Amazon Aurora DB clusters](Aurora.Overview.md). # Amazon Aurora DB clusters An Amazon Aurora *DB cluster* consists of one or more DB instances and a cluster volume that manages the data for those DB instances. An Aurora *cluster volume* is a virtual database storage volume that spans multiple Availability Zones, with each Availability Zone having a copy of the DB cluster data. Two types of DB instances make up an Aurora DB cluster: + **Primary (writer) DB instance** – Supports read and write operations, and performs all of the data modifications to the cluster volume. Each Aurora DB cluster has one primary DB instance. + **Aurora Replica (reader DB instance) **– Connects to the same storage volume as the primary DB instance but supports only read operations. Each Aurora DB cluster can have up to 15 Aurora Replicas in addition to the primary DB instance. Maintain high availability by locating Aurora Replicas in separate Availability Zones. Aurora automatically fails over to an Aurora Replica in case the primary DB instance becomes unavailable. You can specify the failover priority for Aurora Replicas. Aurora Replicas can also offload read workloads from the primary DB instance. The following diagram illustrates the relationship between the cluster volume, the writer DB instance, and reader DB instances in an Aurora DB cluster. ![\[Amazon Aurora DB cluster architecture diagram showing storage layer, database instances, and client connections.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora_architecture.png) **Note** The preceding information applies to all Aurora DB clusters—provisioned, parallel query, Aurora Global Database, Aurora Serverless, Aurora MySQL-Compatible, and Aurora PostgreSQL-Compatible. The Aurora DB cluster illustrates the separation of compute capacity and storage. For example, an Aurora configuration with only a single DB instance is still a cluster, because the underlying storage volume involves multiple storage nodes distributed across multiple Availability Zones (AZs). Input/output (I/O) operations in Aurora DB clusters are counted the same way, regardless of whether they're on a writer or reader DB instance. For more information, see [Storage configurations for Amazon Aurora DB clusters](Aurora.Overview.StorageReliability.md#aurora-storage-type). # Amazon Aurora versions With Amazon Aurora, you can choose the [supported relational database engine](#Aurora.VersionPolicy.SupportedEngines) that best fits your application requirements while maintaining compatibility with the underlying engines. Aurora reuses the database engine code from supported engines, so you can leverage existing skills, tools, and libraries for those engines. When you create a cluster, you [specify the Amazon Aurora database engine version](#Aurora.VersionPolicy.ChoosingVersion) that you want to use. The version that you choose determines compatibility and available features. This documentation explains the common points and differences between Amazon Aurora and the corresponding database engines. With this information, you can determine the software version that you should select and how to verify the available features and bug fixes in each version. You can also use this reference to determine an appropriate upgrade cadence and plan for your upgrade. ## Supported database engines for Amazon Aurora database clusters The following relational databases are available on Amazon Aurora. Aurora reuses code and maintains compatibility with the underlying DB engines. However, Aurora has unique version numbers, release cycles, and timelines for version deprecation. Each new Aurora version comes with release notes that list the new features, fixes, and other changes and enhancements that apply to each version. | Aurora database | User guide | Available versions | Release notes | | --- | --- | --- | --- | | Amazon Aurora MySQL-Compatible Edition | [Working with Amazon Aurora MySQL](Aurora.AuroraMySQL.md) | [Database engine updates for Amazon Aurora MySQLLong-term support (LTS) and beta releases for Amazon Aurora MySQL](AuroraMySQL.Updates.md) | [Release Notes for Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html) | | Amazon Aurora PostgreSQL-Compatible Edition | [Working with Amazon Aurora PostgreSQL](Aurora.AuroraPostgreSQL.md) | [Database engine updates for Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md) | [Release Notes for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html) | ## Specifying the Amazon Aurora database version for your database cluster When you create a new DB cluster with the **Create database** operation in the AWS Management Console or the AWS CLI, or with the `CreateDBCluster` API operation, you can specify any currently available Aurora database version (major or minor). To learn how to create Aurora clusters, see [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md). To learn how to change the version of an existing Aurora cluster, see [Modifying an Amazon Aurora DB cluster](Aurora.Modifying.md). **Note** Not every Aurora database version is available in every AWS Region. To learn more about Regions and the available versions in each AWS Region, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md) and [Supported Regions and DB engines for Aurora global databases](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md). # Amazon Aurora versioning Amazon Aurora versions are different from the upstream community databases that they’re compatible with. To help you maintain application compatibility and leverage the latest DB engine features, the following sections explain Aurora versioning conventions and how Aurora versions map to their respective community databases. For a list of the relational databases that are available on Amazon Aurora, see [Supported database engines for Amazon Aurora database clusters](Aurora.VersionPolicy.md#Aurora.VersionPolicy.SupportedEngines). ## Differences in version numbers between community databases and Aurora Each Amazon Aurora version is compatible with a specific version of its corresponding community database. You can find the community version of your database with the `version` function, and the Aurora version with the `aurora_version` function. The following examples show how to find the community version of your database for Aurora MySQL and Aurora PostgreSQL. ------ #### [ Aurora MySQL ] The `version` function returns the community version of your database for Aurora MySQL. ``` mysql> select version(); ``` Output example: ``` +------------------+ | version() | +------------------+ | 8.0.32 | +------------------+ ``` And the `aurora_version` function returns the Aurora version: ``` mysql> select aurora_version(), @@aurora_version; ``` Output example: ``` +------------------+------------------+ | aurora_version() | @@aurora_version | +------------------+------------------+ | 3.05.2 | 3.05.2 | +------------------+------------------+ ``` ------ #### [ Aurora PostgreSQL ] The `version` function returns the community version of your database for Aurora PostgreSQL. ``` postgres=> select version(); ``` Output example: ``` ----------------------------------------------------------------------------- PostgreSQL 11.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.9.3, 64-bit (1 row) ``` And the `aurora_version` function returns the Aurora version: ``` postgres=> select aurora_version(); ``` Output example: ``` aurora_version ---------------- 3.2.2 ``` ------ For more information, see [Checking Aurora MySQL versions using SQL](AuroraMySQL.Updates.Versions.md#AuroraMySQL.Updates.DBVersions) and [Identifying versions of Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions). ## Default Amazon Aurora versions The default version is the version that Aurora chooses automatically for database creation or upgrade when you don't manually specify a target engine version. For example, the following command shows the default engine version for Aurora PostgreSQL (sample output included). ``` aws rds describe-db-engine-versions \ --engine aurora-postgresql \ --default-only \ --query 'DBEngineVersions[0].EngineVersion' \ --output text 16.4 ``` Every major version has a corresponding default minor version. Thus, the default minor version is 16.*n* for Aurora PostgreSQL 16, with version number *n* changing when Aurora releases new default minor versions. Typically, Aurora releases two default minor versions for every major version per year. The following bash shell script shows the default minor versions for a set of Aurora PostgreSQL major versions (sample output included). ``` for major in 16 15 14 13 12 11; do echo -n "Default for Aurora PostgreSQL major version $major: " aws rds describe-db-engine-versions \ --engine aurora-postgresql \ --engine-version "$major" \ --default-only \ --query 'DBEngineVersions[0].EngineVersion' \ --output text done Default for Aurora PostgreSQL major version 16: 16.4 Default for Aurora PostgreSQL major version 15: 15.8 Default for Aurora PostgreSQL major version 14: 14.13 Default for Aurora PostgreSQL major version 13: 13.16 Default for Aurora PostgreSQL major version 12: 12.20 Default for Aurora PostgreSQL major version 11: 11.21 ``` If you enable automatic minor version upgrades for your Aurora DB cluster, Aurora uses either the default minor version or a newer minor version for a given major version. For example, if the default minor version for Aurora PostgreSQL 15 is 15.8, and newer version 15.10 is also available, Aurora can automatically upgrade to either 15.8 or 15.10. ## Amazon Aurora major versions Aurora versions use the `major.minor.patch` scheme. An *Aurora major version* refers to the MySQL or PostgreSQL community major version that Aurora is compatible with. Aurora MySQL and Aurora PostgreSQL major versions are available under standard support at least until community end of life for the corresponding community version. You can continue to run a major version past its Aurora end of standard support date for a fee. For more information, see [Amazon RDS Extended Support with Amazon Aurora](extended-support.md) and [Amazon Aurora pricing](https://aws.amazon.com/rds/aurora/pricing/). For more information on major versions and the release calendar for Aurora MySQL and Aurora PostgreSQL, see the following pages in the respective Release Notes: + [Release calendar for Aurora MySQL major versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.release-calendars.html#AuroraMySQL.release-calendars.major) + [Release calendar for Aurora PostgreSQL major versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/aurorapostgresql-release-calendar.html#aurorapostgresql.major.versions.supported) You can also view information about support dates for major engine versions by running the [describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) AWS CLI command or by using the [DescribeDBMajorEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS API operation. **Note** Amazon RDS Extended Support for Aurora MySQL version 2 starts on November 1, 2024, but you won't be charged until December 1, 2024. Between November 1 and November 30, 2024, all Aurora MySQL version 2 DB clusters are covered under Amazon RDS Extended Support. For more information, see [Amazon RDS Extended Support for selected Aurora versions](Aurora.VersionPolicy.Support.md#Aurora.VersionPolicy.ES). ### How long Amazon Aurora major versions remain available Amazon Aurora major versions remain available at least until community end of life for the corresponding community version. You can use Aurora end of standard support dates to plan your testing and upgrade cycles. These dates represent the earliest date that an upgrade to a newer version might be required. For more information on the dates, see [Amazon Aurora major versions](#Aurora.VersionPolicy.MajorVersions). Before Aurora asks you to upgrade to a newer major version and to help you plan, you receive a reminder at least 12 months in advance. The reminders communicate the following about the upgrade process. + The timing of certain milestones + The impact on your DB clusters + Recommended actions We recommend that you thoroughly test your applications with new database versions before upgrading your cluster to a new major version. After the major version reaches the Aurora end of standard support, any DB cluster still running the earlier version is automatically upgraded to an Extended Support version during a scheduled maintenance window. Extended Support charges may apply. For more information on Amazon RDS Extended Support, see [Using Amazon RDS Extended support](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/extended-support.html). ## Amazon Aurora minor versions Aurora versions use the `major.minor.patch` scheme. An *Aurora minor version* provides incremental community and Aurora-specific improvements to the service, for example new features and fixes. For more information on minor versions and the release calendar for Aurora MySQL and Aurora PostgreSQL, see the following pages in the respective Release Notes: + [Release calendar for Aurora MySQL minor versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.release-calendars.html#AuroraMySQL.release-calendars.minor) + [Release calendar for Aurora PostgreSQL minor versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/aurorapostgresql-release-calendar.html#aurorapostgresql.minor.versions.supported) The following sections describe details about the cadence and lifetime that you can expect for Aurora minor versions. **Topics** + [ ### How often Amazon Aurora minor versions are released ](#Aurora.VersionPolicy.MinorVersionCadence) + [ ### How long Amazon Aurora minor versions remain available ](#Aurora.VersionPolicy.MinorVersionLifetime) ### How often Amazon Aurora minor versions are released In general, Amazon Aurora minor versions are released quarterly. The release schedule might vary to pick up additional features or fixes. ### How long Amazon Aurora minor versions remain available Typically, Amazon Aurora makes every minor version of a particular major version available for at least 12 months. At the end of this period, Aurora might automatically upgrade your database to the default minor version or to a later version. Aurora begins the upgrade during the scheduled maintenance window for any DB cluster that is running the earlier minor version. In some cases, Aurora might replace a minor version of a particular major version sooner than the usual 12-month period. Reasons can include critical security issues or the end-of-support date for a major version. Before beginning automatic upgrades of minor versions that are approaching end of life, Aurora typically provides a reminder three months in advance. Aurora details the following about the upgrade process. + The timing of certain milestones + The impact on your DB clusters + Recommended actions Notifications with less than three months notice describe critical matters, such as security issues, that require quicker action. If the **Auto minor version upgrade** setting is enabled, you get a reminder but no RDS event notification. Aurora upgrades your database within a maintenance window after the mandatory upgrade deadline has passed. If the **Auto minor version upgrade** setting isn't enabled, you get a reminder and an Amazon RDS DB cluster event with a category of `maintenance` and ID of `RDS-EVENT-0156`. Aurora upgrades your database within the next maintenance window. Note that after a minor version reaches the Aurora end of standard support, no further patch versions will be released for that minor version. To receive critical bug fixes or CVEs, you must upgrade to a minor version with standard support. For more information about automatic minor version upgrades, see [Automatic minor version upgrades for Aurora DB clusters](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU). ## Amazon Aurora patch versions Aurora versions use the `major.minor.patch` scheme. An Aurora patch version includes important fixes added to a minor version after its initial release (for example, Aurora MySQL 3.04.0, 3.04.1, ..., 3.04.3). While each new minor version provides new Aurora features, new patch versions within a specific minor version are primarily used to resolve important issues. For more information on patching, see [Maintaining an Amazon Aurora DB cluster](USER_UpgradeDBInstance.Maintenance.md). # Upgrading Amazon Aurora DB clusters With Amazon Aurora, you can control and test upgrades to your DB clusters. Amazon Aurora provides options for automatic minor version upgrades, manual upgrade control, required upgrades, and pre-upgrade testing. You can keep your clusters up-to-date with the latest minor version, deferring non-critical upgrades, forcing upgrades for serious issues, and validating upgrade behavior in nonproduction environments. The following sections detail how to manage and test Aurora DB cluster upgrades using these capabilities. ## Automatic minor version upgrades for Aurora Automatic minor version upgrades periodically update your database to recent database engine versions. However, the upgrade might not always include the latest database engine version. If you need to keep your databases on specific versions at particular times, we recommend that you manually upgrade to the database versions that you need according to your required schedule. In cases of critical security issues or when a version reaches its end-of-support date, Amazon Aurora might apply a minor version upgrade even if you haven't enabled the **Auto minor version upgrade** option. For more information, see the upgrade documentation for your specific database engine. See [Upgrading the minor version or patch level of an Aurora MySQL DB cluster](AuroraMySQL.Updates.Patching.md) and [Performing a minor version upgrade](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md). You can stay up to date with Aurora minor versions by turning on **Auto minor version upgrade** for every DB instance in the Aurora cluster. Aurora performs the automatic upgrade only if all DB instances in your cluster have this setting turned on. If **Auto minor version upgrade** is **Yes** for your DB cluster, Aurora upgrades automatically to the default minor version or to a newer minor version. For example, if the default minor version is 15.8 for Aurora PostgreSQL 15, and version 15.10 exists, the target for the automatic upgrade could be either 15.8 or 15.10. Aurora typically schedules automatic upgrades twice a year for DB clusters that have automatic minor version upgrade enabled. These upgrades occur during the maintenance window that you specify for your cluster. For more information, see [Automatic minor version upgrades for Aurora DB clusters](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU). Automatic minor version upgrades are communicated in advance through an Amazon RDS DB cluster event with a category of `maintenance` and ID of `RDS-EVENT-0156`. For more information, see [Amazon RDS event categories and event messagesfor Aurora](USER_Events.Messages.md). ## Manually controlling upgrades of your DB clusters to new versions If you have the **Auto minor version upgrade** setting enabled, Aurora automatically upgrades your DB cluster to the default minor version or a newer minor version. Aurora typically schedules automatic upgrades twice a year for DB clusters that have the **Auto minor version upgrade** setting enabled. These upgrades are started during customer-specified maintenance windows. To turn off automatic minor version upgrades, disable **Auto minor version upgrade** on any DB instance within an Aurora cluster. Aurora performs an automatic minor version upgrade only if all DB instances in your cluster have the setting enabled. **Note** For mandatory upgrades such as minor-version end of life, Aurora upgrades the DB cluster even if the **Auto minor version upgrade** setting is disabled. You get a reminder but no RDS event notification. Aurora upgrades your cluster occur within a maintenance window after the mandatory upgrade deadline has passed. Because major version upgrades involve some compatibility risk, they don't occur automatically. You must initiate these, except if there is a major version deprecation. We recommend that you thoroughly test your applications with new database versions before upgrading your cluster to a major version. For more information about upgrading a DB cluster to a new Aurora major version, see [Upgrading Amazon Aurora MySQL DB clusters](AuroraMySQL.Updates.Upgrading.md) and [Upgrading Amazon Aurora PostgreSQL DB clusters](USER_UpgradeDBInstance.PostgreSQL.md). ## Required Amazon Aurora upgrades For certain critical fixes, Aurora might perform a managed upgrade to a newer patch level within the same minor version. In this case, Aurora upgrades your cluster even if **Auto minor version upgrade** is turned off. Before doing so, Aurora communicates the detailed upgrade process. Details include the timing of certain milestones, the impact on your DB clusters, and recommended actions. Such managed upgrades occur automatically within the cluster maintenance window. ## Testing your DB cluster with a new Aurora version before upgrading You can test the upgrade process and how the new version works with your application and workload. Use one of the following methods: + Clone your cluster using the Amazon Aurora fast database clone feature. Perform the upgrade and any post-upgrade testing on the new cluster. + Restore from a cluster snapshot to create a new Aurora cluster. You can create a cluster snapshot yourself from an existing Aurora cluster. Aurora also automatically creates periodic snapshots for you for each of your clusters. You can then initiate a version upgrade for the new cluster. You can experiment on the upgraded copy of your cluster before deciding whether to upgrade your original cluster. For more information on these ways to create new clusters for testing, see [Cloning a volume for an Amazon Aurora DB cluster](Aurora.Managing.Clone.md) and [Creating a DB cluster snapshot](USER_CreateSnapshotCluster.md). # Amazon Aurora version support If your Amazon Aurora DB has complex dependencies on specific database engine behavior, we recommend that you engage in extensive testing before you upgrade to newer database engine versions. There are long-term support options so that you can maintain your DB clusters on select Aurora engine versions even after they have been superseded by newer versions. The following sections explain the long-term support options for your Aurora DB clusters. ## Long-term support for selected Amazon Aurora minor versions For each Aurora major version, certain minor versions are designated as long-term-support (LTS) versions, and made available for at least three years. That is, at least one minor version per major version is made available for longer than the typical 12 months. Typically, Aurora reminds you six months before the end of this period. Aurora communicates the following about the upgrade process. + The timing of certain milestones + The impact on your DB clusters + Recommended actions Notifications with less than six months notice communicate critical matters, such as security issues, that necessitate quicker action. LTS minor versions include only critical fixes (through patch versions). An LTS version doesn't include new features released after its introduction. Once a year, DB clusters running on an LTS minor version are patched to the latest patch version of the LTS release. Aurora patches your clusters so that you benefit from cumulative security and stability fixes. If there are critical fixes, Aurora might patch an LTS minor version more frequently, such as for security, that need to be applied. **Note** If you want to remain on an LTS minor version for the duration of its lifecycle, make sure to disable automatic minor version upgrade for your DB instances. To avoid automatically upgrading your DB cluster from the LTS minor version, clear the **Enable auto minor version upgrade** check box on any DB instance in your Aurora cluster. For the version numbers of all Aurora LTS versions, see [Aurora MySQL long-term support (LTS) releases](AuroraMySQL.Update.SpecialVersions.md#AuroraMySQL.Updates.LTS) and [Using an Aurora PostgreSQL long-term support (LTS) release](AuroraPostgreSQL.Updates.LTS.md). ## Amazon RDS Extended Support for selected Aurora versions With Amazon RDS Extended Support, you can continue to run your database on a major engine version past the Aurora end of standard support date for an additional cost. During RDS Extended Support, Amazon RDS will supply patches for Critical and High CVEs as defined by the National Vulnerability Database (NVD) CVSS severity ratings. For more information, see [Amazon RDS Extended Support with Amazon Aurora](extended-support.md). RDS Extended Support is only available on certain Aurora versions. For more information, see [Amazon Aurora major versions](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MajorVersions). # Regions and Availability Zones Amazon cloud computing resources are hosted in multiple locations world-wide. These locations are composed of AWS Regions and Availability Zones. Each *AWS Region* is a separate geographic area. Each AWS Region has multiple, isolated locations known as *Availability Zones*. **Note** For information about finding the Availability Zones for an AWS Region, see [Describe your Availability Zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#availability-zones-describe) in the Amazon EC2 documentation. Amazon operates state-of-the-art, highly-available data centers. Although rare, failures can occur that affect the availability of DB instances that are in the same location. If you host all your DB instances in one location that is affected by such a failure, none of your DB instances will be available. ![\[AWS Region\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Con-AZ.png) It is important to remember that each AWS Region is completely independent. Any Amazon RDS activity you initiate (for example, creating database instances or listing available database instances) runs only in your current default AWS Region. The default AWS Region can be changed in the console, or by setting the [https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-region](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-region) environment variable. Or it can be overridden by using the `--region` parameter with the AWS Command Line Interface (AWS CLI). For more information, see [Configuring the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html), specifically the sections about environment variables and command line options. Amazon RDS supports special AWS Regions called AWS GovCloud (US). These are designed to allow US government agencies and customers to move more sensitive workloads into the cloud. The AWS GovCloud (US) Regions address the US government's specific regulatory and compliance requirements. For more information, see [What is AWS GovCloud (US)?](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html) To create or work with an Amazon RDS DB instance in a specific AWS Region, use the corresponding regional service endpoint. **Note** Aurora doesn't support Local Zones. ## AWS Regions Each AWS Region is designed to be isolated from the other AWS Regions. This design achieves the greatest possible fault tolerance and stability. When you view your resources, you see only the resources that are tied to the AWS Region that you specified. This is because AWS Regions are isolated from each other, and we don't automatically replicate resources across AWS Regions. ### Region availability When you work with an Aurora DB cluster using the command line interface or API operations, make sure that you specify its regional endpoint. **Topics** + [ #### Aurora MySQL Region availability ](#Aurora.Overview.Availability.MySQL) + [ #### Aurora PostgreSQL Region availability ](#Aurora.Overview.Availability.PostgreSQL) #### Aurora MySQL Region availability The following table shows the AWS Regions where Aurora MySQL is currently available and the endpoint for each Region. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.RegionsAndAvailabilityZones.html) #### Aurora PostgreSQL Region availability The following table shows the AWS Regions where Aurora PostgreSQL is currently available and the endpoint for each Region. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.RegionsAndAvailabilityZones.html) ## Availability Zones An Availability Zone is an isolated location in a given AWS Region. Each Region has multiple Availability Zones (AZ) designed to provide high availability for the Region. An AZ is identified by the AWS Region code followed by a letter identifier (for example, `us-east-1a`). If you create your VPC and subnets rather than using the default VPC, you define each subnet in a specific AZ. When you create an Aurora DB cluster, Aurora creates the primary instance in one of the subnets in the VPC's DB subnet group. It thus associates that instance with a specific AZ chosen by Aurora. Each Aurora DB cluster hosts copies of its storage in three separate AZs selected automatically by Aurora from the AZs in your DB subnet group. Every DB instance in the cluster must be in one of these three AZs. When you create a DB instance in your cluster, Aurora automatically chooses an appropriate AZ for that instance if you don't specify an AZ. Use the [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) Amazon EC2 command as follows to describe the Availability Zones within the specified Region that are enabled for your account. ``` aws ec2 describe-availability-zones --region region-name ``` For example, to describe the Availability Zones within the US East (N. Virginia) Region (us-east-1) that are enabled for your account, run the following command: ``` aws ec2 describe-availability-zones --region us-east-1 ``` To learn how to specify the AZ when you create a cluster or add instances to it, see [Configure the network for the DB cluster](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC). ## Local time zone for Amazon Aurora DB clusters By default, the time zone for an Amazon Aurora DB cluster is Universal Time Coordinated (UTC). You can set the time zone for instances in your DB cluster to the local time zone for your application instead. To set the local time zone for a DB cluster, set the time zone parameter to one of the supported values. You set this parameter in the cluster parameter group for your DB cluster. + For Aurora MySQL, the name of this parameter is `time_zone`. For information on best practices for setting the `time_zone` parameter, see [Optimizing timestamp operations](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.Performance.TimeZone). + For Aurora PostgreSQL, the name of this parameter is `timezone`. When you set the time zone parameter for a DB cluster, all instances in the DB cluster change to use the new local time zone. In some cases, other Aurora DB clusters might be using the same cluster parameter group. If so, all instances in those DB clusters change to use the new local time zone also. For information on cluster-level parameters, see [Amazon Aurora DB cluster and DB instance parameters](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups). After you set the local time zone, all new connections to the database reflect the change. In some cases, you might have open connections to your database when you change the local time zone. If so, you don't see the local time zone update until after you close the connection and open a new connection. If you are replicating across AWS Regions, the replication source DB cluster and the replica use different parameter groups. Parameter groups are unique to an AWS Region. To use the same local time zone for each instance, make sure to set the time zone parameter in the parameter groups for both the replication source and the replica. When you restore a DB cluster from a DB cluster snapshot, the local time zone is set to UTC. You can update the time zone to your local time zone after the restore is complete. In some cases, you might restore a DB cluster to a point in time. If so, the local time zone for the restored DB cluster is the time zone setting from the parameter group of the restored DB cluster. The following table lists some of the values to which you can set your local time zone. To list all of the available time zones, you can use the following SQL queries: + Aurora MySQL: `select * from mysql.time_zone_name;` + Aurora PostgreSQL: `select * from pg_timezone_names;` **Note** For some time zones, time values for certain date ranges can be reported incorrectly as noted in the table. For Australia time zones, the time zone abbreviation returned is an outdated value as noted in the table. | Time zone | Notes | | --- | --- | | `Africa/Harare` | This time zone setting can return incorrect values from 28 Feb 1903 21:49:40 GMT to 28 Feb 1903 21:55:48 GMT. | | `Africa/Monrovia` | | | `Africa/Nairobi` | This time zone setting can return incorrect values from 31 Dec 1939 21:30:00 GMT to 31 Dec 1959 21:15:15 GMT. | | `Africa/Windhoek` | | | `America/Bogota ` | This time zone setting can return incorrect values from 23 Nov 1914 04:56:16 GMT to 23 Nov 1914 04:56:20 GMT. | | `America/Caracas` | | | `America/Chihuahua` | | | `America/Cuiaba` | | | `America/Denver` | | | `America/Fortaleza` | In some cases, for a DB cluster in the South America (Sao Paulo) Region, time doesn't show correctly for a recently changed Brazil time zone. If so, reset the DB cluster's time zone parameter to `America/Fortaleza`. | | `America/Guatemala` | | | `America/Halifax` | This time zone setting can return incorrect values from 27 Oct 1918 05:00:00 GMT to 31 Oct 1918 05:00:00 GMT. | | `America/Manaus` | If your DB cluster is in the South America (Cuiaba) time zone and the expected time doesn't show correctly for the recently changed Brazil time zone, reset the DB cluster's time zone parameter to `America/Manaus`. | | `America/Matamoros` | | | `America/Monterrey` | | | `America/Montevideo` | | | `America/Noronha` | | | `America/Phoenix` | | | `America/Tijuana` | | | `Asia/Ashgabat` | | | `Asia/Baghdad` | | | `Asia/Baku` | | | `Asia/Bangkok` | | | `Asia/Beirut` | | | `Asia/Calcutta` | | | `Asia/Kabul` | | | `Asia/Karachi` | | | `Asia/Kathmandu` | | | `Asia/Muscat ` | This time zone setting can return incorrect values from 31 Dec 1919 20:05:36 GMT to 31 Dec 1919 20:05:40 GMT. | | `Asia/Riyadh ` | This time zone setting can return incorrect values from 13 Mar 1947 20:53:08 GMT to 31 Dec 1949 20:53:08 GMT. | | `Asia/Seoul` | This time zone setting can return incorrect values from 30 Nov 1904 15:30:00 GMT to 07 Sep 1945 15:00:00 GMT. | | `Asia/Shanghai` | This time zone setting can return incorrect values from 31 Dec 1927 15:54:08 GMT to 02 Jun 1940 16:00:00 GMT. | | `Asia/Singapore` | | | `Asia/Taipei` | This time zone setting can return incorrect values from 30 Sep 1937 16:00:00 GMT to 29 Sep 1979 15:00:00 GMT. | | `Asia/Tehran` | | | `Asia/Tokyo` | This time zone setting can return incorrect values from 30 Sep 1937 15:00:00 GMT to 31 Dec 1937 15:00:00 GMT. | | `Asia/Ulaanbaatar` | | | `Atlantic/Azores` | This time zone setting can return incorrect values from 24 May 1911 01:54:32 GMT to 01 Jan 1912 01:54:32 GMT. | | `Australia/Adelaide` | The abbreviation for this time zone is returned as CST instead of ACDT/ACST. | | `Australia/Brisbane` | The abbreviation for this time zone is returned as EST instead of AEDT/AEST. | | `Australia/Darwin ` | The abbreviation for this time zone is returned as CST instead of ACDT/ACST. | | `Australia/Hobart` | The abbreviation for this time zone is returned as EST instead of AEDT/AEST. | | `Australia/Perth` | The abbreviation for this time zone is returned as WST instead of AWDT/AWST. | | `Australia/Sydney ` | The abbreviation for this time zone is returned as EST instead of AEDT/AEST. | | `Brazil/East` | | | `Canada/Saskatchewan` | This time zone setting can return incorrect values from 27 Oct 1918 08:00:00 GMT to 31 Oct 1918 08:00:00 GMT. | | `Europe/Amsterdam` | | | `Europe/Athens` | | | `Europe/Dublin` | | | `Europe/Helsinki` | This time zone setting can return incorrect values from 30 Apr 1921 22:20:08 GMT to 30 Apr 1921 22:20:11 GMT. | | `Europe/Paris` | | | `Europe/Prague` | | | `Europe/Sarajevo` | | | `Pacific/Auckland` | | | `Pacific/Guam` | | | `Pacific/Honolulu` | This time zone setting can return incorrect values from 21 May 1933 11:30:00 GMT to 30 Sep 1945 11:30:00 GMT. | | `Pacific/Samoa` | This time zone setting can return incorrect values from 01 Jan 1911 11:22:48 GMT to 01 Jan 1950 11:30:00 GMT. | | `US/Alaska` | | | `US/Central` | | | `US/Eastern` | | | `US/East-Indiana` | | | `US/Pacific` | | | `UTC` | | # Supported features in Amazon Aurora by AWS Region and Aurora DB engine Aurora MySQL- and PostgreSQL-compatible database engines support several Amazon Aurora and Amazon RDS features and options. The support varies across specific versions of each database engine, and across AWS Regions. To identify Aurora database engine version support and availability for a feature in a given AWS Region, you can use the following sections. Some of these features are Aurora-only capabilities. For example, Aurora Serverless, Aurora global databases, and support for integration with AWS machine learning services aren't supported by Amazon RDS. Other features, such as Amazon RDS Proxy, are supported by both Amazon Aurora and Amazon RDS. **Topics** + [ ## Table conventions ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.TableConventions) + [Blue/Green Deployments](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md) + [Aurora cluster configurations](Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.md) + [Database activity streams](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md) + [Exporting cluster data to Amazon S3](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ExportClusterToS3.md) + [Exporting snapshot data to Amazon S3](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ExportSnapshotToS3.md) + [Aurora global databases](Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.md) + [IAM database authentication](Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.md) + [Kerberos authentication](Concepts.Aurora_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md) + [Aurora machine learning](Concepts.Aurora_Fea_Regions_DB-eng.Feature.Aurora_ML.md) + [Performance Insights](Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.md) + [Zero-ETL integrations](Concepts.Aurora_Fea_Regions_DB-eng.Feature.Zero-ETL.md) + [RDS Proxy](Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.md) + [Secrets Manager integration](Concepts.Aurora_Fea_Regions_DB-eng.Feature.SecretsManager.md) + [Aurora Serverless v2](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md) + [RDS Data API](Concepts.Aurora_Fea_Regions_DB-eng.Feature.Data_API.md) + [Zero-downtime patching (ZDP)](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ZDP.md) + [Aurora PostgreSQL Limitless Database](Concepts.Aurora_Fea_Regions_DB-eng.Feature.AuroraLimitless.md) + [Engine-native features](Concepts.Aurora_Fea_Regions_DB-eng.Feature.EngineNativeFeatures.md) ## Table conventions The tables in the feature sections use the following patterns to specify version numbers and level of support: + **Version x.y** – The specific version alone is supported. + **Version x.y and higher** – The specified version and all higher minor versions of its major version are supported. For example, "version 10.11 and higher" means that versions 10.11, 10.11.1, and 10.12 are supported. # Supported Regions and Aurora DB engines for Blue/Green Deployments A blue/green deployment copies a production database environment in a separate, synchronized staging environment. By using Amazon RDS Blue/Green Deployments, you can make changes to the database in the staging environment without affecting the production environment. For example, you can upgrade the major or minor DB engine version, change database parameters, or make schema changes in the staging environment. When you are ready, you can promote the staging environment to be the new production database environment. For more information, see [Using Amazon Aurora Blue/Green Deployments for database updates](blue-green-deployments.md). ## Blue/Green Deployments with Aurora MySQL The Blue/Green Deployments feature is available for all versions of Aurora MySQL in all AWS Regions, including Aurora MySQL clusters configured as Aurora Global Database. ## Blue/Green Deployments with Aurora PostgreSQL The following Regions and engine versions are available for Blue/Green Deployments with Aurora PostgreSQL, including Aurora PostgreSQL clusters configured as Aurora Global Database. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | Aurora PostgreSQL 12 | Aurora PostgreSQL 11 | | --- | --- | --- | --- | --- | --- | --- | --- | | All AWS Regions | Version 17.4 and higher | Version 16.1 and higher | Version 15.4 and higher | Version 14.9 and higher | Version 13.12 and higher | Version 12.16 and higher | Version 11.21 and higher | # Supported Regions and Aurora DB engines for cluster storage configurations Amazon Aurora has two DB cluster storage configurations, Aurora I/O-Optimized and Aurora Standard. For more information, see [Storage configurations for Amazon Aurora DB clusters](Aurora.Overview.StorageReliability.md#aurora-storage-type). ## Aurora I/O-Optimized Aurora I/O-Optimized is available in all AWS Regions for the following Amazon Aurora versions: + Aurora MySQL version 3.03.1 and higher + Aurora PostgreSQL versions 17.4 and higher, 16.1 and higher, 15.2 and higher, 14.7 and higher, and 13.10 and higher ## Aurora Standard Aurora Standard is available in all AWS Regions for all Aurora MySQL and Aurora PostgreSQL versions. # Supported Regions and Aurora DB engines for database activity streams By using database activity streams in Aurora, you can monitor and set alarms for auditing activity in your Aurora database. For more information, see [Monitoring Amazon Aurora with Database Activity Streams](DBActivityStreams.md). Database activity streams aren't supported for the following features: + Aurora Serverless v2 + Babelfish for Aurora PostgreSQL **Topics** + [ ## Database activity streams with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.amy) + [ ## Database activity streams with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.apg) ## Database activity streams with Aurora MySQL The following Regions and engine versions are available for database activity streams with Aurora MySQL. | Region | Aurora MySQL version 3 | Aurora MySQL version 2 | | --- | --- | --- | | US East (N. Virginia) | All available versions | Aurora version 2.11 and higher | | US East (Ohio) | All available versions | Aurora version 2.11 and higher | | US West (N. California) | All available versions | Aurora version 2.11 and higher | | US West (Oregon) | All available versions | Aurora version 2.11 and higher | | Africa (Cape Town) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (Hong Kong) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (Hyderabad) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (Jakarta) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (Malaysia) | Not available | Not available | | Asia Pacific (Melbourne) | Not available | Not available | | Asia Pacific (Mumbai) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (New Zealand) | Not available | Not available | | Asia Pacific (Osaka) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (Seoul) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (Singapore) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (Sydney) | All available versions | Aurora version 2.11 and higher | | Asia Pacific (Taipei) | Not available | Not available | | Asia Pacific (Thailand) | Not available | Not available | | Asia Pacific (Tokyo) | All available versions | Aurora version 2.11 and higher | | Canada (Central) | All available versions | Aurora version 2.11 and higher | | Canada West (Calgary) | Not available | Not available | | China (Beijing) | Not available | Not available | | China (Ningxia) | Not available | Not available | | Europe (Frankfurt) | All available versions | Aurora version 2.11 and higher | | Europe (Ireland) | All available versions | Aurora version 2.11 and higher | | Europe (London) | All available versions | Aurora version 2.11 and higher | | Europe (Milan) | All available versions | Aurora version 2.11 and higher | | Europe (Paris) | All available versions | Aurora version 2.11 and higher | | Europe (Spain) | All available versions | Aurora version 2.11 and higher | | Europe (Stockholm) | All available versions | Aurora version 2.11 and higher | | Europe (Zurich) | Not available | Not available | | Israel (Tel Aviv) | Not available | Not available | | Middle East (Bahrain) | All available versions | Aurora version 2.11 and higher | | Mexico (Central) | Not available | Not available | | Middle East (UAE) | All available versions | Aurora version 2.11 and higher | | South America (São Paulo) | All available versions | Aurora version 2.11 and higher | ## Database activity streams with Aurora PostgreSQL The following Regions and engine versions are available for database activity streams with Aurora PostgreSQL. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | Aurora PostgreSQL 12 | Aurora PostgreSQL 11 | | --- | --- | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | US East (Ohio) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | US West (N. California) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | US West (Oregon) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Africa (Cape Town) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (Hong Kong) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (Hyderabad) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (Jakarta) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (Malaysia) | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Melbourne) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Mumbai) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (New Zealand) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Osaka) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (Seoul) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (Singapore) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (Sydney) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Asia Pacific (Taipei) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Thailand) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Tokyo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Canada (Central) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Canada West (Calgary) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | China (Beijing) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | China (Ningxia) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Europe (Frankfurt) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Europe (Ireland) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Europe (London) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Europe (Milan) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Europe (Paris) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Europe (Spain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Europe (Stockholm) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Europe (Zurich) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Israel (Tel Aviv) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Mexico (Central) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Middle East (Bahrain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | Middle East (UAE) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | | South America (São Paulo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | All available versions | All available versions | All available versions | Version 11.9 and version 11.13 and higher | # Supported Regions and Aurora DB engines for exporting cluster data to Amazon S3 You can export Aurora DB cluster data to an Amazon S3 bucket. After the data is exported, you can analyze the exported data directly through tools like Amazon Athena or Amazon Redshift Spectrum. For more information, see [Exporting DB cluster data to Amazon S3](export-cluster-data.md). Exporting cluster data to S3 is available in the following AWS Regions: + US East (N. Virginia) + US East (Ohio) + US West (N. California) + US West (Oregon) + Asia Pacific (Hong Kong) + Asia Pacific (Hyderabad) + Asia Pacific (Jakarta) + Asia Pacific (Malaysia) + Asia Pacific (Melbourne) + Asia Pacific (Mumbai) + Asia Pacific (New Zealand) + Asia Pacific (Osaka) + Asia Pacific (Seoul) + Asia Pacific (Singapore) + Asia Pacific (Sydney) + Asia Pacific (Taipei) + Asia Pacific (Thailand) + Asia Pacific (Tokyo) + Canada (Central) + Canada West (Calgary) + China (Ningxia) + Europe (Frankfurt) + Europe (Ireland) + Europe (London) + Europe (Paris) + Europe (Spain) + Europe (Stockholm) + Europe (Zurich) + Israel (Tel Aviv) + Middle East (UAE) + Mexico (Central) + South America (São Paulo) **Topics** + [ ## Exporting cluster data to S3 with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ExportClusterToS3.ams) + [ ## Exporting cluster data to S3 with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ExportClusterToS3.apg) ## Exporting cluster data to S3 with Aurora MySQL All currently available Aurora MySQL engine versions support exporting DB cluster data to Amazon S3. For more information about versions, see [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html). ## Exporting cluster data to S3 with Aurora PostgreSQL All currently available Aurora PostgreSQL engine versions support exporting DB cluster data to Amazon S3. For more information about versions, see the [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html). # Supported Regions and Aurora DB engines for exporting snapshot data to Amazon S3 You can export Aurora DB cluster snapshot data to an Amazon S3 bucket. You can export manual snapshots and automated system snapshots. After the data is exported, you can analyze the exported data directly through tools like Amazon Athena or Amazon Redshift Spectrum. For more information, see [Exporting DB cluster snapshot data to Amazon S3](aurora-export-snapshot.md). Exporting snapshots to S3 is available in all AWS Regions except the following: + Asia Pacific (Malaysia) + Asia Pacific (New Zealand) + Asia Pacific (Taipei) + Asia Pacific (Thailand) + Mexico (Central) **Topics** + [ ## Exporting snapshot data to S3 with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ExportSnapshotToS3.ams) + [ ## Exporting snapshot data to S3 with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ExportSnapshotToS3.apg) ## Exporting snapshot data to S3 with Aurora MySQL All currently available Aurora MySQL engine versions support exporting DB cluster snapshot data to Amazon S3. For more information about versions, see [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html). ## Exporting snapshot data to S3 with Aurora PostgreSQL All currently available Aurora PostgreSQL engine versions support exporting DB cluster snapshot data to Amazon S3. For more information about versions, see the [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html). # Supported Regions and DB engines for Aurora global databases An *Aurora global database* is a single database that spans multiple AWS Regions, enabling low-latency global reads and disaster recovery from any Region-wide outage. It provides built-in fault tolerance for your deployment because the DB instance relies not on a single AWS Region, but upon multiple Regions and different Availability Zones. For more information, see [Using Amazon Aurora Global Database](aurora-global-database.md). **Topics** + [ ## Aurora global databases with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.amy) + [ ## Aurora global databases with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.GlobalDatabase.apg) ## Aurora global databases with Aurora MySQL The following Regions and engine versions are available for Aurora global databases with Aurora MySQL. | Region | Aurora MySQL version 3 | Aurora MySQL version 2 | | --- | --- | --- | | US East (N. Virginia) | Version 3.01.0 and higher | Version 2.07.0 and higher | | US East (Ohio) | Version 3.01.0 and higher | Version 2.07.0 and higher | | US West (N. California) | Version 3.01.0 and higher | Version 2.07.0 and higher | | US West (Oregon) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Africa (Cape Town) | Version 3.01.0 and higher | Version 2.07.1 and higher | | Asia Pacific (Hong Kong) | Version 3.01.0 and higher | Version 2.07.1 and higher | | Asia Pacific (Hyderabad) | Version 3.02.0 and higher | Version 2.11.2 and higher | | Asia Pacific (Jakarta) | Version 3.01.0 and higher | Version 2.07.6 and higher | | Asia Pacific (Malaysia) | Version 3.04.0 and higher | Version 2.07.6 and higher | | Asia Pacific (Melbourne) | Version 3.03.0 and higher | Version 2.07.6 and higher | | Asia Pacific (Mumbai) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Asia Pacific (New Zealand) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Asia Pacific (Osaka) | Version 3.01.0 and higher | Version 2.07.3 and higher | | Asia Pacific (Seoul) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Asia Pacific (Singapore) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Asia Pacific (Sydney) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Asia Pacific (Taipei) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Asia Pacific (Thailand) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Asia Pacific (Tokyo) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Canada (Central) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Canada West (Calgary) | Version 3.01.0 and higher | Version 2.07.0 and higher | | China (Beijing) | Version 3.01.0 and higher | Version 2.07.2 and higher | | China (Ningxia) | Version 3.01.0 and higher | Version 2.07.2 and higher | | Europe (Frankfurt) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Europe (Ireland) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Europe (London) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Europe (Milan) | Version 3.01.0 and higher | Version 2.07.1 and higher | | Europe (Paris) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Europe (Spain) | Version 3.02.0 and higher | Version 2.07.6 and higher | | Europe (Stockholm) | Version 3.01.0 and higher | Version 2.07.0 and higher | | Europe (Zurich) | Version 3.02.0 and higher | Version 2.07.6 and higher | | Israel (Tel Aviv) | Version 3.02.0 and higher | Version 2.07.6 and higher | | Mexico (Central) | Version 3.02.0 and higher | Version 2.07.6 and higher | | Middle East (Bahrain) | Version 3.01.0 and higher | Version 2.07.1 and higher | | Middle East (UAE) | Version 3.02.0 and higher | Version 2.07.6 and higher | | South America (São Paulo) | Version 3.01.0 and higher | Version 2.07.1 and higher | | AWS GovCloud (US-East) | Version 3.01.0 and higher | Version 2.07.0 and higher | | AWS GovCloud (US-West) | Version 3.01.0 and higher | Version 2.07.0 and higher | ## Aurora global databases with Aurora PostgreSQL The following Regions and engine versions are available for Aurora global databases with Aurora PostgreSQL. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | Aurora PostgreSQL 12 | Aurora PostgreSQL 11 | | --- | --- | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | US East (Ohio) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | US West (N. California) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | US West (Oregon) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Africa (Cape Town) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Hong Kong) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Hyderabad) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Jakarta) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Malaysia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Melbourne) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Mumbai) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (New Zealand) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Osaka) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Seoul) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Singapore) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Sydney) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Sydney) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Taipei) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Thailand) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Tokyo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Canada (Central) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Canada West (Calgary) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | China (Beijing) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | China (Ningxia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Frankfurt) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Ireland) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (London) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Milan) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Paris) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Spain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Stockholm) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Zurich) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Israel (Tel Aviv) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Mexico (Central) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Middle East (Bahrain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Middle East (UAE) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | South America (São Paulo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | AWS GovCloud (US-East) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | AWS GovCloud (US-West) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | # Supported Regions and Aurora DB engines for IAM database authentication With IAM database authentication in Aurora, you can authenticate to your DB cluster using AWS Identity and Access Management (IAM) database authentication. With this authentication method, you don't need to use a password when you connect to a DB cluster. Instead, you use an authentication token. For more information, see [IAM database authentication ](UsingWithRDS.IAMDBAuth.md). **Topics** + [ ## IAM database authentication with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.amy) + [ ## IAM database authentication with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.apg) ## IAM database authentication with Aurora MySQL IAM database authentication with Aurora MySQL is available in all Regions for the following versions: + Aurora MySQL 3 – All available versions + Aurora MySQL 2 – All available versions ## IAM database authentication with Aurora PostgreSQL IAM database authentication with Aurora PostgreSQL is available in all Regions for the following engine versions: + Aurora PostgreSQL 17 – All available versions + Aurora PostgreSQL 16 – All available versions + Aurora PostgreSQL 15 – All available versions + Aurora PostgreSQL 14 – All available versions + Aurora PostgreSQL 13 – All available versions + Aurora PostgreSQL 12 – All available versions + Aurora PostgreSQL 11 – All available versions # Supported Regions and Aurora DB engines for Kerberos authentication By using Kerberos authentication with Aurora, you can support external authentication of database users using Kerberos and Microsoft Active Directory. Using Kerberos and Active Directory provides the benefits of single sign-on and centralized authentication of database users. Kerberos and Active Directory are available with AWS Directory Service for Microsoft Active Directory, a feature of Directory Service. For more information, see [Kerberos authentication](database-authentication.md#kerberos-authentication). **Topics** + [ ## Kerberos authentication with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.KerberosAuthentication.amy) + [ ## Kerberos authentication with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.KerberosAuthentication.apg) + [ ## Active Directory(AD) security groups with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ActiveDirectory.apg) ## Kerberos authentication with Aurora MySQL The following Regions and engine versions are available for Kerberos Authentication with Aurora MySQL. | Region | Aurora MySQL version 3 | | --- | --- | | US East (N. Virginia) | Version 3.03.0 and higher | | US East (Ohio) | Version 3.03.0 and higher | | US West (N. California) | Version 3.03.0 and higher | | US West (Oregon) | Version 3.03.0 and higher | | Africa (Cape Town) | Not available | | Asia Pacific (Hong Kong) | Not available | | Asia Pacific (Jakarta) | Not available | | Asia Pacific (Malaysia) | Not available | | Asia Pacific (Melbourne) | Not available | | Asia Pacific (Mumbai) | Version 3.03.0 and higher | | Asia Pacific (New Zealand) | Not available | | Asia Pacific (Osaka) | Not available | | Asia Pacific (Seoul) | Version 3.03.0 and higher | | Asia Pacific (Singapore) | Version 3.03.0 and higher | | Asia Pacific (Sydney) | Version 3.03.0 and higher | | Asia Pacific (Taipei) | Not available | | Asia Pacific (Thailand) | Not available | | Asia Pacific (Tokyo) | Version 3.03.0 and higher | | Canada (Central) | Version 3.03.0 and higher | | Canada West (Calgary) | Not available | | China (Beijing) | Version 3.03.0 and higher | | China (Ningxia) | Version 3.03.0 and higher | | Europe (Frankfurt) | Version 3.03.0 and higher | | Europe (Ireland) | Version 3.03.0 and higher | | Europe (London) | Version 3.03.0 and higher | | Europe (Milan) | Not available | | Europe (Paris) | Version 3.03.0 and higher | | Europe (Spain) | Not available | | Europe (Stockholm) | Version 3.03.0 and higher | | Europe (Zurich) | Not available | | Israel (Tel Aviv) | Not available | | Mexico (Central) | Not available | | Middle East (Bahrain) | Not available | | Middle East (UAE) | Not available | | South America (São Paulo) | Version 3.03.0 and higher | | AWS GovCloud (US-East) | Version 3.03.0 and higher | | AWS GovCloud (US-West) | Version 3.03.0 and higher | ## Kerberos authentication with Aurora PostgreSQL The following Regions and engine versions are available for Kerberos Authentication with Aurora PostgreSQL. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | Aurora PostgreSQL 12 | Aurora PostgreSQL 11 | | --- | --- | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US East (Ohio) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US West (N. California) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US West (Oregon) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Africa (Cape Town) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Hong Kong) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Hyderabad) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Jakarta) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Malaysia) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Melbourne) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Mumbai) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (New Zealand) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Osaka) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Seoul) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Singapore) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Sydney) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Taipei) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Thailand) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Tokyo) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Canada (Central) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Canada West (Calgary) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | China (Beijing) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | China (Ningxia) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Frankfurt) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Ireland) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (London) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Milan) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Paris) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Spain) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Stockholm) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Zurich) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Israel (Tel Aviv) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Mexico (Central) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Middle East (Bahrain) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Middle East (UAE) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | South America (São Paulo) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | AWS GovCloud (US-East) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | AWS GovCloud (US-West) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | ## Active Directory(AD) security groups with Aurora PostgreSQL The following Regions and engine versions are available for ActiveDirectory with Aurora PostgreSQL. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | Aurora PostgreSQL 12 | Aurora PostgreSQL 11 | | --- | --- | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US East (Ohio) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US West (N. California) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US West (Oregon) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Africa (Cape Town) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Hong Kong) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Hyderabad) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Jakarta) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Malaysia) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Melbourne) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Mumbai) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (New Zealand) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Osaka) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Seoul) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Singapore) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Sydney) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Taipei) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Thailand) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Tokyo) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Canada (Central) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Canada West (Calgary) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | China (Beijing) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | China (Ningxia) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Frankfurt) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Ireland) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (London) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Milan) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Paris) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Spain) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Stockholm) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Zurich) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Israel (Tel Aviv) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Mexico (Central) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Middle East (Bahrain) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Middle East (UAE) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | South America (São Paulo) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | AWS GovCloud (US-East) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | AWS GovCloud (US-West) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | # Supported Regions and DB engines for Aurora machine learning By using Amazon Aurora machine learning, you can integrate your Aurora DB cluster with one of the following AWS machine learning services, depending on your needs. They each support specific machine learning use cases. Amazon Bedrock is a fully managed service that makes leading foundation models from AI companies available through an API, along with developer tooling to help build and scale generative AI applications. Amazon Comprehend is a *natural language processing* (NLP) service that's used to extract insights from documents. By using Aurora machine learning with Amazon Comprehend, you can determine the sentiment of text in your database tables. SageMaker AI is a full-featured *machine learning* service. Data scientists use Amazon SageMaker AI to build, train, and test machine learning models for a variety of inference tasks, such as fraud detection. By using Aurora machine learning with SageMaker AI, database developers can invoke the SageMaker AI functionality in SQL code. Not all AWS Regions support all machine learning services. Only certain AWS Regions support Aurora machine learning and thus provide access to these services from an Aurora DB cluster. The integration process for Aurora machine learning also differs by database engine. For more information, see [Using Amazon Aurora machine learning](aurora-ml.md). **Topics** + [ ## Aurora machine learning with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Aurora_ML.amy) + [ ## Aurora machine learning with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Aurora_ML.apg) ## Aurora machine learning with Aurora MySQL Amazon Bedrock is supported only on Aurora MySQL version 3.06 and higher. For information on Region availability for Amazon Bedrock, see [Model support by AWS Region](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html) in the *Amazon Bedrock User Guide*. Aurora machine learning with Amazon Comprehend and Amazon SageMaker AI is supported for Aurora MySQL in the AWS Regions listed in the table. In addition to having your version of Aurora MySQL available, the AWS Region must also support the service that you want to use. For a list of AWS Regions where Amazon SageMaker AI is available, see [Amazon SageMaker AI endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/sagemaker.html) in the *Amazon Web Services General Reference*. For a list of AWS Regions where Amazon Comprehend is available, see [Amazon Comprehend endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/comprehend.html) in the *Amazon Web Services General Reference*. | Region | Aurora MySQL version 3 | Aurora MySQL version 2 | | --- | --- | --- | | US East (N. Virginia) | Version 3.01.0 and higher | Version 2.07 and higher | | US East (Ohio) | Version 3.01.0 and higher | Version 2.07 and higher | | US West (N. California) | Version 3.01.0 and higher | Version 2.07 and higher | | US West (Oregon) | Version 3.01.0 and higher | Version 2.07 and higher | | Africa (Cape Town) | Not available | Not available | | Asia Pacific (Hong Kong) | Version 3.01.0 and higher | Version 2.07 and higher | | Asia Pacific (Hyderabad) | Version 3.01.0 and higher | Version 2.07 and higher | | Asia Pacific (Jakarta) | Version 3.01.0 and higher | Version 2.07 and higher | | Asia Pacific (Malaysia) | Version 3.04.0 and higher | Not available | | Asia Pacific (Melbourne) | Version 3.01.0 and higher | Version 2.07 and higher | | Asia Pacific (Mumbai) | Version 3.01.0 and higher | Version 2.07 and higher | | Asia Pacific (New Zealand) | Not available | Not available | | Asia Pacific (Osaka) | Version 3.01.0 and higher | Version 2.07.3 and higher | | Asia Pacific (Seoul) | Version 3.01.0 and higher | Version 2.07 and higher | | Asia Pacific (Singapore) | Version 3.01.0 and higher | Version 2.07 and higher | | Asia Pacific (Sydney) | Version 3.01.0 and higher | Version 2.07 and higher | | Asia Pacific (Taipei) | Not available | Not available | | Asia Pacific (Thailand) | Not available | Not available | | Asia Pacific (Tokyo) | Version 3.01.0 and higher | Version 2.07 and higher | | Canada (Central) | Version 3.01.0 and higher | Version 2.07 and higher | | Canada West (Calgary) | Version 3.01.0 and higher | Version 2.07 and higher | | China (Beijing) | Version 3.01.0 and higher | Version 2.07 and higher | | China (Ningxia) | Version 3.01.0 and higher | Version 2.07 and higher | | Europe (Frankfurt) | Version 3.01.0 and higher | Version 2.07 and higher | | Europe (Ireland) | Version 3.01.0 and higher | Version 2.07 and higher | | Europe (London) | Version 3.01.0 and higher | Version 2.07 and higher | | Europe (Milan) | Not available | Not available | | Europe (Paris) | Version 3.01.0 and higher | Version 2.07 and higher | | Europe (Spain) | Version 3.01.0 and higher | Version 2.07 and higher | | Europe (Stockholm) | Version 3.01.0 and higher | Version 2.07 and higher | | Europe (Zurich) | Version 3.01.0 and higher | Version 2.07 and higher | | Israel (Tel Aviv) | Version 3.01.0 and higher | Version 2.07 and higher | | Mexico (Central) | Not available | Not available | | Middle East (Bahrain) | Version 3.01.0 and higher | Version 2.07 and higher | | Middle East (UAE) | Version 3.01.0 and higher | Version 2.07 and higher | | South America (São Paulo) | Version 3.01.0 and higher | Version 2.07 and higher | | AWS GovCloud (US-East) | Version 3.01.0 and higher | Version 2.07 and higher | | AWS GovCloud (US-West) | Version 3.01.0 and higher | Version 2.07 and higher | ## Aurora machine learning with Aurora PostgreSQL For information on version support for Amazon Bedrock on Aurora PostgreSQL, see [Using Aurora PostgreSQL as a Knowledge Base for Amazon Bedrock](AuroraPostgreSQL.VectorDB.md). Aurora machine learning with Amazon Comprehend and Amazon SageMaker AI is supported for Aurora PostgreSQL in the AWS Regions listed in the table. In addition to having your version of Aurora PostgreSQL available, the AWS Region must also support the service that you want to use. For a list of AWS Regions where Amazon SageMaker AI is available, see [Amazon SageMaker AI endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/sagemaker.html) in the *Amazon Web Services General Reference*. For a list of AWS Regions where Amazon Comprehend is available, see [Amazon Comprehend endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/comprehend.html) in the *Amazon Web Services General Reference*. The following Regions and engine versions are available for Aurora machine learning with Aurora PostgreSQL. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | Aurora PostgreSQL 12 | Aurora PostgreSQL 11 | | --- | --- | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | US East (Ohio) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | US West (N. California) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | US West (Oregon) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Africa (Cape Town) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Hong Kong) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Hyderabad) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Jakarta) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Malaysia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Melbourne) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Mumbai) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (New Zealand) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Osaka) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Seoul) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Singapore) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Sydney) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Taipei) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Thailand) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Asia Pacific (Tokyo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Canada (Central) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Canada West (Calgary) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | China (Beijing) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | China (Ningxia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Europe (Frankfurt) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Europe (Ireland) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Europe (London) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Europe (Milan) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Europe (Paris) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Europe (Spain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Europe (Stockholm) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Europe (Zurich) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Israel (Tel Aviv) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Mexico (Central) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Middle East (Bahrain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | Middle East (UAE) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | South America (São Paulo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | AWS GovCloud (US-East) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | | AWS GovCloud (US-West) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.3 and higher | Version 12.4 and higher | Version 11.9, 11.12 and higher | # Supported Regions and Aurora DB engines for Performance Insights **Important** AWS has announced the end-of-life date for Performance Insights: June 30, 2026. After this date, Amazon RDS will no longer support the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing. The Performance Insights API will continue to exist with no pricing changes. Costs for the Performance Insights API will appear in your AWS bill with the cost of CloudWatch Database Insights. We recommend that you upgrade any DB clusters using the paid tier of Performance Insights to the Advanced mode of Database Insights before June 30, 2026. For information about upgrading to the Advanced mode of Database Insights, see [Turning on the Advanced mode of Database Insights for Amazon Aurora](USER_DatabaseInsights.TurningOnAdvanced.md). If you take no action, DB clusters using Performance Insights will default to using the Standard mode of Database Insights. With Standard mode of Database Insights, you might lose access to performance data history beyond 7 days and might not be able to use execution plans and on-demand analysis features in the Amazon RDS console. After June 30, 2026 only the Advanced mode of Database Insights will support execution plans and on-demand analysis. With CloudWatch Database Insights, you can monitor database load for your fleet of databases and analyze and troubleshoot performance at scale. For more information about Database Insights, see [Monitoring Amazon Aurora databases with CloudWatch Database Insights](USER_DatabaseInsights.md). For pricing information, see [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/). Performance Insights expands on existing Amazon RDS monitoring features to illustrate and help you analyze your database performance. With the Performance Insights dashboard, you can visualize the database load on your Amazon RDS DB instance load and filter the load by waits, SQL statements, hosts, or users. For more information, see [Overview of Performance Insights on Amazon Aurora](USER_PerfInsights.Overview.md). For the region, DB engine, and instance class support information for Performance Insights features, see [ Amazon Aurora DB engine, Region, and instance class support for Performance Insights features](USER_PerfInsights.Overview.Engines.md#USER_PerfInsights.Overview.PIfeatureEngnRegSupport). **Topics** + [ ## Performance Insights with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.amy) + [ ## Performance Insights with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.apg) + [ ## Performance Insights with Aurora Serverless ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.PerfInsights.serverless) ## Performance Insights with Aurora MySQL **Note** Engine version support is different for Performance Insights with Aurora MySQL if you have parallel query turned on. For more information on parallel query, see [Parallel query for Amazon Aurora MySQL](aurora-mysql-parallel-query.md). **Topics** + [ ### Performance Insights with Aurora MySQL and parallel query turned off ](#Feature.PerfInsights.regions.amy.pq) + [ ### Performance Insights with Aurora MySQL and parallel query turned on ](#Feature.PerfInsights.regions.amy.pqoff) ### Performance Insights with Aurora MySQL and parallel query turned off The following Regions and engine versions are available for Performance Insights with Aurora MySQL and parallel query turned off. | Region | Aurora MySQL version 3 | Aurora MySQL version 2 | | --- | --- | --- | | US East (N. Virginia) | All versions | All versions | | US East (Ohio) | All versions | All versions | | US West (N. California) | All versions | All versions | | US West (Oregon) | All versions | All versions | | Africa (Cape Town) | All versions | All versions | | Asia Pacific (Hong Kong) | All versions | All versions | | Asia Pacific (Hyderabad) | All versions | All versions | | Asia Pacific (Jakarta) | All versions | All versions | | Asia Pacific (Malaysia) | All versions | All versions | | Asia Pacific (Melbourne) | All versions | All versions | | Asia Pacific (Mumbai) | All versions | All versions | | Asia Pacific (New Zealand) | All versions | All versions | | Asia Pacific (Osaka) | All versions | All versions | | Asia Pacific (Seoul) | All versions | All versions | | Asia Pacific (Singapore) | All versions | All versions | | Asia Pacific (Sydney) | All versions | All versions | | Asia Pacific (Taipei) | All versions | All versions | | Asia Pacific (Thailand) | All versions | All versions | | Asia Pacific (Tokyo) | All versions | All versions | | Canada (Central) | All versions | All versions | | Canada West (Calgary) | All versions | All versions | | China (Beijing) | All versions | All versions | | China (Ningxia) | All versions | All versions | | Europe (Frankfurt) | All versions | All versions | | Europe (Ireland) | All versions | All versions | | Europe (London) | All versions | All versions | | Europe (Milan) | All versions | All versions | | Europe (Paris) | All versions | All versions | | Europe (Spain) | All versions | All versions | | Europe (Stockholm) | All versions | All versions | | Europe (Zurich) | All versions | All versions | | Israel (Tel Aviv) | All versions | All versions | | Mexico (Central) | All versions | All versions | | Middle East (Bahrain) | All versions | All versions | | Middle East (UAE) | All versions | All versions | | South America (São Paulo) | All versions | All versions | | AWS GovCloud (US-East) | All versions | All versions | | AWS GovCloud (US-West) | All versions | All versions | ### Performance Insights with Aurora MySQL and parallel query turned on The following Regions and engine versions are available for Performance Insights with Aurora MySQL and parallel query turned on. | Region | Aurora MySQL version 3 | Aurora MySQL version 2 | | --- | --- | --- | | US East (N. Virginia) | Not available | Version 2.09.0 and higher | | US East (Ohio) | Not available | Version 2.09.0 and higher | | US West (N. California) | Not available | Version 2.09.0 and higher | | US West (Oregon) | Not available | Version 2.09.0 and higher | | Africa (Cape Town) | Not available | Version 2.09.0 and higher | | Asia Pacific (Hong Kong) | Not available | Version 2.09.0 and higher | | Asia Pacific (Hyderabad) | Not available | All versions | | Asia Pacific (Jakarta) | Not available | Version 2.09.0 and higher | | Asia Pacific (Malaysia) | Not available | Version 2.09.0 and higher | | Asia Pacific (Melbourne) | Not available | Version 2.09.0 and higher | | Asia Pacific (Mumbai) | Not available | Version 2.09.0 and higher | | Asia Pacific (New Zealand) | Not available | Version 2.09.0 and higher | | Asia Pacific (Osaka) | Not available | Version 2.09.0 and higher | | Asia Pacific (Seoul) | Not available | Version 2.09.0 and higher | | Asia Pacific (Singapore) | Not available | Version 2.09.0 and higher | | Asia Pacific (Sydney) | Not available | Version 2.09.0 and higher | | Asia Pacific (Taipei) | Not available | Version 2.09.0 and higher | | Asia Pacific (Thailand) | Not available | Version 2.09.0 and higher | | Asia Pacific (Tokyo) | Not available | Version 2.09.0 and higher | | Canada (Central) | Not available | Version 2.09.0 and higher | | Canada West (Calgary) | Not available | Version 2.09.0 and higher | | China (Beijing) | Not available | Version 2.09.0 and higher | | China (Ningxia) | Not available | Version 2.09.0 and higher | | Europe (Frankfurt) | Not available | Version 2.09.0 and higher | | Europe (Ireland) | Not available | Version 2.09.0 and higher | | Europe (London) | Not available | Version 2.09.0 and higher | | Europe (Milan) | Not available | Version 2.09.0 and higher | | Europe (Paris) | Not available | Version 2.09.0 and higher | | Europe (Spain) | Not available | Version 2.09.0 and higher | | Europe (Stockholm) | Not available | Version 2.09.0 and higher | | Europe (Zurich) | Not available | Version 2.09.0 and higher | | Israel (Tel Aviv) | Not available | Version 2.09.0 and higher | | Mexico (Central) | Not available | Version 2.09.0 and higher | | Middle East (Bahrain) | Not available | Version 2.09.0 and higher | | Middle East (UAE) | Not available | Version 2.09.0 and higher | | South America (São Paulo) | Not available | Version 2.09.0 and higher | | AWS GovCloud (US-East) | Not available | Version 2.09.0 and higher | | AWS GovCloud (US-West) | Not available | Version 2.09.0 and higher | ## Performance Insights with Aurora PostgreSQL The following Regions and engine versions are available for Performance Insights with Aurora PostgreSQL. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | Aurora PostgreSQL 12 | Aurora PostgreSQL 11 | Aurora PostgreSQL 10 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US East (Ohio) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US West (N. California) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | US West (Oregon) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Africa (Cape Town) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Hong Kong) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Hyderabad) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Jakarta) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Malaysia) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Melbourne) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Mumbai) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (New Zealand) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Osaka) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Seoul) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Singapore) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Sydney) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Taipei) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Thailand) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Asia Pacific (Tokyo) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Canada (Central) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Canada West (Calgary) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | China (Beijing) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | China (Ningxia) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Frankfurt) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Ireland) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (London) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Milan) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Paris) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Spain) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Stockholm) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Europe (Zurich) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Israel (Tel Aviv) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Mexico (Central) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Middle East (Bahrain) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | Middle East (UAE) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | South America (São Paulo) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | AWS GovCloud (US-East) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | | AWS GovCloud (US-West) | All versions | All versions | All versions | All versions | All versions | All versions | All versions | All versions | ## Performance Insights with Aurora Serverless Aurora Serverless v2 supports Performance Insights for all MySQL-compatible and PostgreSQL-compatible versions. We recommend that you set the minimum capacity to at least 2 Aurora capacity units (ACUs). # Supported Regions and Aurora DB engines for zero-ETL integrations Amazon Aurora zero-ETL integrations is a fully managed solution for making transactional data available in Amazon Redshift or Amazon SageMaker after it's written to an Aurora cluster. For more information, see [Aurora zero-ETL integrations](zero-etl.md). **Topics** + [ ## Aurora MySQL zero-ETL integrations ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Zero-ETL-MySQL) + [ ## Aurora PostgreSQL zero-ETL integrations ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Zero-ETL-Postgres) ## Aurora MySQL zero-ETL integrations The following Regions and engine versions are available for Aurora MySQL zero-ETL integrations with Amazon Redshift and Amazon SageMaker. | Region | Zero-ETL integration with Amazon Redshift for Aurora MySQL version 3 | Zero-ETL integration with Amazon SageMaker for Aurora MySQL version 3 | | --- | --- | --- | | US East (N. Virginia) | Version 3.05.2 and higher | Version 3.05.2 and higher | | US East (Ohio) | Version 3.05.2 and higher | Version 3.05.2 and higher | | US West (N. California) | Version 3.05.2 and higher | Not available | | US West (Oregon) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Africa (Cape Town) | Version 3.05.2 and higher | Not available | | Asia Pacific (Hong Kong) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Asia Pacific (Hyderabad) | Version 3.05.2 and higher | Not available | | Asia Pacific (Jakarta) | Version 3.05.2 and higher | Not available | | Asia Pacific (Malaysia) | Not available | Not available | | Asia Pacific (Melbourne) | Version 3.05.2 and higher | Not available | | Asia Pacific (Mumbai) | Version 3.05.2 and higher | Not available | | Asia Pacific (New Zealand) | Not available | Not available | | Asia Pacific (Osaka) | Version 3.05.2 and higher | Not available | | Asia Pacific (Seoul) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Asia Pacific (Singapore) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Asia Pacific (Sydney) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Asia Pacific (Taipei) | Not available | Not available | | Asia Pacific (Thailand) | Not available | Not available | | Asia Pacific (Tokyo) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Canada (Central) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Canada West (Calgary) | Version 3.05.2 and higher | Not available | | China (Beijing) | Version 3.05.2 and higher | Not available | | China (Ningxia) | Version 3.05.2 and higher | Not available | | Europe (Frankfurt) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Europe (Ireland) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Europe (London) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Europe (Milan) | Version 3.05.2 and higher | Not available | | Europe (Paris) | Version 3.05.2 and higher | Not available | | Europe (Spain) | Version 3.05.2 and higher | Not available | | Europe (Stockholm) | Version 3.05.2 and higher | Version 3.05.2 and higher | | Europe (Zurich) | Version 3.05.2 and higher | Not available | | Israel (Tel Aviv) | Version 3.05.2 and higher | Not available | | Mexico (Central) | Not available | Not available | | Middle East (Bahrain) | Version 3.05.2 and higher | Not available | | Middle East (UAE) | Version 3.05.2 and higher | Not available | | South America (São Paulo) | Version 3.05.2 and higher | Version 3.05.2 and higher | | AWS GovCloud (US-East) | Not available | Not available | | AWS GovCloud (US-West) | Not available | Not available | ## Aurora PostgreSQL zero-ETL integrations The following Regions and engine versions are available for Aurora PostgreSQL zero-ETL integrations with Amazon Redshift and Amazon Sagemaker. | Region | Zero-ETL integration with Amazon Redshift for Aurora PostgreSQL version 17 | Zero-ETL integration with Amazon SageMaker for Aurora PostgreSQL version 17 | Zero-ETL integration with Amazon Redshift for Aurora PostgreSQL version 16 | Zero-ETL integration with Amazon SageMaker for Aurora PostgreSQL version 16 | | --- | --- | --- | --- | --- | | US East (Ohio) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | US East (N. Virginia) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | US West (N. California) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | US West (Oregon) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Africa (Cape Town) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Asia Pacific (Hong Kong) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Asia Pacific (Hyderabad) | Version 17.4 and higher | Version 16.4 and higher | Not available | Not available | | Asia Pacific (Jakarta) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Asia Pacific (Melbourne) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Asia Pacific (Malaysia) | Not available | Not available | | Asia Pacific (Malaysia) | Not available | Not available | | Asia Pacific (Mumbai) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Asia Pacific (New Zealand) | Not available | Not available | | Asia Pacific (Osaka) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Asia Pacific (Seoul) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Asia Pacific (Singapore) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Asia Pacific (Sydney) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Asia Pacific (Taipei) | Not available | Not available | | Asia Pacific (Thailand) | Not available | Not available | | Asia Pacific (Taipei) | Not available | Not available | | Asia Pacific (Thailand) | Not available | Not available | | Asia Pacific (Tokyo) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Canada (Central) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Canada West (Calgary) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | China (Beijing) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | China (Ningxia) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Europe (Frankfurt) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Europe (Ireland) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Europe (London) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Europe (Milan) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Europe (Paris) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Europe (Spain) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Europe (Stockholm) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | Europe (Zurich) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Israel (Tel Aviv) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Mexico (Central) | Not available | Not available | | Mexico (Central) | Not available | Not available | | Middle East (Bahrain) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | Middle East (UAE) | Version 17.4 and higher | Not available | Version 16.4 and higher | Not available | | South America (São Paulo) | Version 17.4 and higher | Version 17.4 and higher | Version 16.4 and higher | Version 16.4 and higher | | AWS GovCloud (US-East) | Not available | Not available | Not available | Not available | | AWS GovCloud (US-West) | Not available | Not available | Not available | Not available | # Supported Regions and Aurora DB engines for Amazon RDS Proxy Amazon RDS Proxy is a fully managed, highly available database proxy that makes applications more scalable by pooling and sharing established database connections. For more information about RDS Proxy, see [Amazon RDS Proxyfor Aurora](rds-proxy.md). **Topics** + [ ## Amazon RDS Proxy with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.amy) + [ ## Amazon RDS Proxy with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.apg) ## Amazon RDS Proxy with Aurora MySQL The following Regions and engine versions are available for RDS Proxy with Aurora MySQL. | Region | Aurora MySQL version 3 | Aurora MySQL version 2 | | --- | --- | --- | | US East (N. Virginia) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | US East (Ohio) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | US West (N. California) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | US West (Oregon) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Africa (Cape Town) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Hong Kong) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Hyderabad) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Jakarta) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Malaysia) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Melbourne) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Mumbai) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (New Zealand) | Not available | Not available | | Asia Pacific (Osaka) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Seoul) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Singapore) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Sydney) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Taipei) | Not available | Not available | | Asia Pacific (Thailand) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Asia Pacific (Tokyo) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Canada (Central) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Canada West (Calgary) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | China (Beijing) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | China (Ningxia) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Europe (Frankfurt) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Europe (Ireland) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Europe (London) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Europe (Milan) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Europe (Paris) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Europe (Spain) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Europe (Stockholm) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Europe (Zurich) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Israel (Tel Aviv) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Mexico (Central) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Middle East (Bahrain) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | Middle East (UAE) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | South America (São Paulo) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | AWS GovCloud (US-East) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | | AWS GovCloud (US-West) | Version 3.01.0 and higher | Version 2.07 and version 2.11 and higher | ## Amazon RDS Proxy with Aurora PostgreSQL The following Regions and engine versions are available for RDS Proxy with Aurora PostgreSQL. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | Aurora PostgreSQL 12 | Aurora PostgreSQL 11 | | --- | --- | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | US East (Ohio) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | US West (N. California) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | US West (Oregon) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Africa (Cape Town) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Hong Kong) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Hyderabad) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Jakarta) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Malaysia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Melbourne) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Mumbai) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (New Zealand) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Osaka) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Seoul) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Singapore) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Sydney) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Taipei) | Not available | Not available | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Thailand) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Asia Pacific (Tokyo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Canada (Central) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Canada West (Calgary) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | China (Beijing) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | China (Ningxia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Frankfurt) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Ireland) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (London) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Milan) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Paris) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Spain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Stockholm) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Europe (Zurich) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Israel (Tel Aviv) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Mexico (Central) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Middle East (Bahrain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | Middle East (UAE) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | South America (São Paulo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | AWS GovCloud (US-East) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | | AWS GovCloud (US-West) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.4 and higher | Version 12.8 and higher | Version 11.9 and version 11.13 and higher | # Supported Regions and Aurora DB engines for Secrets Manager integration With AWS Secrets Manager, you can replace hard-coded credentials in your code, including database passwords, with an API call to Secrets Manager to retrieve the secret programmatically. For more information about Secrets Manager, see [AWS Secrets Manager User Guide](https://docs.aws.amazon.com/secretsmanager/latest/userguide/). You can specify that Amazon Aurora manages the master user password in Secrets Manager for an Aurora DB cluster. Aurora generates the password, stores it in Secrets Manager, and rotates it regularly. For more information, see [Password management with Amazon Aurora and AWS Secrets Manager](rds-secrets-manager.md). Secrets Manager integration is available in all AWS Regions. # Supported Regions and Aurora DB engines for Aurora Serverless v2 Aurora Serverless v2 is an on-demand, auto-scaling feature designed to be a cost-effective approach to running intermittent or unpredictable workloads on Amazon Aurora. It automatically scales capacity up or down as needed by your applications. With Aurora Serverless v2, each cluster can contain a writer DB instance and multiple reader DB instances. You can combine Aurora Serverless v2 and traditional provisioned DB instances within the same cluster. For more information, see [Using Aurora Serverless v2](aurora-serverless-v2.md). **Topics** + [ ## Aurora Serverless v2 with Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.amy) + [ ## Aurora Serverless v2 with Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg) ## Aurora Serverless v2 with Aurora MySQL The following Regions and engine versions are available for Aurora Serverless v2 with Aurora MySQL. | Region | Aurora MySQL version 3 | | --- | --- | | US East (N. Virginia) | Version 3.02.0 and higher | | US East (Ohio) | Version 3.02.0 and higher | | US West (N. California) | Version 3.02.0 and higher | | US West (Oregon) | Version 3.02.0 and higher | | Africa (Cape Town) | Version 3.02.0 and higher | | Asia Pacific (Hong Kong) | Version 3.02.0 and higher | | Asia Pacific (Hyderabad) | Version 3.02.3 and higher | | Asia Pacific (Jakarta) | Version 3.02.0 and higher | | Asia Pacific (Malaysia) | Versions 3.04.3, 3.05.2, 3.06.1, 3.07.1, and higher | | Asia Pacific (Melbourne) | Version 3.02.3 and higher | | Asia Pacific (Mumbai) | Version 3.02.0 and higher | | Asia Pacific (New Zealand) | Versions 3.04.3 and higher, 3.08.0 and higher | | Asia Pacific (Osaka) | Version 3.02.0 and higher | | Asia Pacific (Seoul) | Version 3.02.0 and higher | | Asia Pacific (Singapore) | Version 3.02.0 and higher | | Asia Pacific (Sydney) | Version 3.02.0 and higher | | Asia Pacific (Taipei) | Versions 3.04.3 and higher, 3.08.1 and higher | | Asia Pacific (Thailand) | Versions 3.04.3 and higher, 3.08.0 and higher | | Asia Pacific (Tokyo) | Version 3.02.0 and higher | | Canada (Central) | Version 3.02.0 and higher | | Canada West (Calgary) | Version 3.04.0 and higher | | China (Beijing) | Version 3.02.2 and higher | | China (Ningxia) | Version 3.02.2 and higher | | Europe (Frankfurt) | Version 3.02.0 and higher | | Europe (Ireland) | Version 3.02.0 and higher | | Europe (London) | Version 3.02.0 and higher | | Europe (Milan) | Version 3.02.0 and higher | | Europe (Paris) | Version 3.02.0 and higher | | Europe (Spain) | Version 3.02.3 and higher | | Europe (Stockholm) | Version 3.02.0 and higher | | Europe (Zurich) | Version 3.02.3 and higher | | Israel (Tel Aviv) | Versions 3.02.3 and higher, 3.03.1 and higher | | Mexico (Central) | Versions 3.04.3 and higher, 3.08.0 and higher | | Middle East (Bahrain) | Version 3.02.0 and higher | | Middle East (UAE) | Version 3.02.3 and higher | | South America (São Paulo) | Version 3.02.0 and higher | | AWS GovCloud (US-East) | Version 3.02.2 and higher | | AWS GovCloud (US-West) | Version 3.02.2 and higher | The upper and lower ACU limits for Aurora Serverless v2 capacity might vary depending on your engine version. For details, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity). ## Aurora Serverless v2 with Aurora PostgreSQL The following Regions and engine versions are available for Aurora Serverless v2 with Aurora PostgreSQL. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | US East (Ohio) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | US West (N. California) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | US West (Oregon) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Africa (Cape Town) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Asia Pacific (Hong Kong) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Asia Pacific (Hyderabad) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.6 and higher | Version 13.9 and higher | | Asia Pacific (Jakarta) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Asia Pacific (Malaysia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.4 and higher | Version 14.6, 14.9 and higher | Version 13.9, 13.12 and higher | | Asia Pacific (Melbourne) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.6 and higher | Version 13.9 and higher | | Asia Pacific (Mumbai) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Asia Pacific (New Zealand) | Version 17.4 and higher | Version 16.8 and higher | Version 15.12 and higher | Version 14.17 and higher | Version 13.20 and higher | | Asia Pacific (Osaka) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Asia Pacific (Seoul) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Asia Pacific (Singapore) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Asia Pacific (Taipei) | Version 17.4 and higher | Version 16.6 and higher | Version 15.10 and higher | Version 14.15 and higher | Not available | | Asia Pacific (Sydney) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Asia Pacific (Thailand) | Version 17.4 and higher | Version 16.4 and higher | Version 15.8 and higher | Version 14.13 and higher | Not available | | Asia Pacific (Tokyo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Canada (Central) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Canada West (Calgary) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.6, 14.8 and higher | Version 13.9, 13.11 and higher | | China (Beijing) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | China (Ningxia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Europe (Frankfurt) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Europe (Ireland) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Europe (London) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Europe (Milan) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Europe (Paris) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Europe (Spain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.6 and higher | Version 13.9 and higher | | Europe (Stockholm) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Europe (Zurich) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.6 and higher | Version 13.9 and higher | | Israel (Tel Aviv) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.6 and higher | Version 13.9 and higher | | Mexico (Central) | Version 17.4 and higher | Version 16.4 and higher | Version 15.8 and higher | Version 14.13 and higher | Not available | | Middle East (Bahrain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | Middle East (UAE) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.6 and higher | Version 13.9 and higher | | South America (São Paulo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | AWS GovCloud (US-East) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | | AWS GovCloud (US-West) | Version 17.4 and higher | Version 16.1 and higher | Version 15.2 and higher | Version 14.3 and higher | Version 13.6 and higher | The upper and lower ACU limits for Aurora Serverless v2 capacity might vary depending on your engine version. For details, see [Aurora Serverless v2 capacity](aurora-serverless-v2.how-it-works.md#aurora-serverless-v2.how-it-works.capacity). # Supported Regions and Aurora DB engines for RDS Data API RDS Data API (Data API) provides a web-services interface to an Amazon Aurora DB cluster. Instead of managing database connections from client applications, you can run SQL commands against an HTTPS endpoint. For more information, see [Using the Amazon RDS Data API](data-api.md). **Topics** + [ ## Data API with Aurora PostgreSQL Serverless v2 and provisioned ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Data_API.apg) + [ ## Data API with Aurora MySQL Serverless v2 and provisioned ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Data_API.ams) + [ ## Data API with Aurora PostgreSQL Serverless v1 ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Data_API.apg-sv1) + [ ## Data API with Aurora MySQL Serverless v1 ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Data_API.amy) ## Data API with Aurora PostgreSQL Serverless v2 and provisioned The following Regions and engine versions are available for Data API with Aurora PostgreSQL Serverless v2 and provisioned DB clusters. | Region | Aurora PostgreSQL 17 | Aurora PostgreSQL 16 | Aurora PostgreSQL 15 | Aurora PostgreSQL 14 | Aurora PostgreSQL 13 | | --- | --- | --- | --- | --- | --- | | US East (N. Virginia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | US East (Ohio) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | US West (N. California) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | US West (Oregon) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Africa (Cape Town) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Hong Kong) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Hyderabad) | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Jakarta) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Malaysia) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Melbourne) | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Mumbai) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (New Zealand) | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Osaka) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Seoul) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Singapore) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Sydney) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Taipei) | Not available | Not available | Not available | Not available | Not available | | Asia Pacific (Thailand) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Asia Pacific (Tokyo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Canada (Central) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Canada West (Calgary) | Not available | Not available | Not available | Not available | Not available | | China (Beijing) | Not available | Not available | Not available | Not available | Not available | | China (Ningxia) | Not available | Not available | Not available | Not available | Not available | | Europe (Frankfurt) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Europe (Ireland) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Europe (London) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Europe (Milan) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Europe (Paris) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Europe (Spain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Europe (Stockholm) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Europe (Zurich) | Not available | Not available | Not available | Not available | Not available | | Israel (Tel Aviv) | Not available | Not available | Not available | Not available | Not available | | Middle East (Bahrain) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | Mexico (Central) | Not available | Not available | Not available | Not available | Not available | | Middle East (UAE) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | South America (São Paulo) | Version 17.4 and higher | Version 16.1 and higher | Version 15.3 and higher | Version 14.8 and higher | Version 13.11 and higher | | AWS GovCloud (US-East) | Not available | Not available | Not available | Not available | Not available | | AWS GovCloud (US-West) | Not available | Not available | Not available | Not available | Not available | ## Data API with Aurora MySQL Serverless v2 and provisioned The following Regions and engine versions are available for Data API with Aurora MySQL Serverless v2 and provisioned DB clusters. | Region | Aurora MySQL version 3 | | --- | --- | | US East (Ohio) | Version 3.07 and higher | | US East (N. Virginia) | Version 3.07 and higher | | US West (N. California) | Version 3.07 and higher | | US West (Oregon) | Version 3.07 and higher | | Africa (Cape Town) | Version 3.07 and higher | | Asia Pacific (Hong Kong) | Version 3.07 and higher | | Asia Pacific (Hyderabad) | Not available | | Asia Pacific (Jakarta) | Version 3.07 and higher | | Asia Pacific (Malaysia) | Version 3.07 and higher | | Asia Pacific (Melbourne) | Not available | | Asia Pacific (Mumbai) | Version 3.07 and higher | | Asia Pacific (New Zealand) | Not available | | Asia Pacific (Osaka) | Version 3.07 and higher | | Asia Pacific (Seoul) | Version 3.07 and higher | | Asia Pacific (Singapore) | Version 3.07 and higher | | Asia Pacific (Sydney) | Version 3.07 and higher | | Asia Pacific (Taipei) | Not available | | Asia Pacific (Thailand) | Version 3.07 and higher | | Asia Pacific (Tokyo) | Version 3.07 and higher | | Canada (Central) | Version 3.07 and higher | | Canada West (Calgary) | Not available | | China (Beijing) | Not available | | China (Ningxia) | Not available | | Europe (Frankfurt) | Version 3.07 and higher | | Europe (Ireland) | Version 3.07 and higher | | Europe (London) | Version 3.07 and higher | | Europe (Milan) | Version 3.07 and higher | | Europe (Paris) | Version 3.07 and higher | | Europe (Spain) | Version 3.07 and higher | | Europe (Stockholm) | Version 3.07 and higher | | Europe (Zurich) | Not available | | Israel (Tel Aviv) | Not available | | Mexico (Central) | Not available | | Middle East (Bahrain) | Version 3.07 and higher | | Middle East (UAE) | Version 3.07 and higher | | South America (São Paulo) | Version 3.07 and higher | | AWS GovCloud (US-East) | Not available | | AWS GovCloud (US-West) | Not available | ## Data API with Aurora PostgreSQL Serverless v1 The following Regions and engine versions are available for Data API with Aurora PostgreSQL Serverless v1. | Region | Aurora PostgreSQL 13 | Aurora PostgreSQL 11 | | --- | --- | --- | | US East (N. Virginia) | Version 13.9 | Version 11.18 | | US East (Ohio) | Version 13.9 | Version 11.18 | | US West (N. California) | Version 13.9 | Version 11.18 | | US West (Oregon) | Version 13.9 | Version 11.18 | | Africa (Cape Town) | Not available | Not available | | Asia Pacific (Hong Kong) | Not available | Not available | | Asia Pacific (Hyderabad) | Not available | Not available | | Asia Pacific (Jakarta) | Not available | Not available | | Asia Pacific (Malaysia) | Not available | Not available | | Asia Pacific (Melbourne) | Not available | Not available | | Asia Pacific (Mumbai) | Version 13.9 | Version 11.18 | | Asia Pacific (Osaka) | Not available | Not available | | Asia Pacific (Seoul) | Version 13.9 | Version 11.18 | | Asia Pacific (Singapore) | Version 13.9 | Version 11.18 | | Asia Pacific (Sydney) | Version 13.9 | Version 11.18 | | Asia Pacific (Thailand) | Not available | Not available | | Asia Pacific (Tokyo) | Version 13.9 | Version 11.18 | | Canada (Central) | Version 13.9 | Version 11.18 | | China (Beijing) | Not available | Not available | | China (Ningxia) | Not available | Not available | | Europe (Frankfurt) | Version 13.9 | Version 11.18 | | Europe (Ireland) | Version 13.9 | Version 11.18 | | Europe (London) | Version 13.9 | Version 11.18 | | Europe (Milan) | Not available | Not available | | Europe (Paris) | Version 13.9 | Version 11.18 | | Europe (Spain) | Version 13.9 | Version 11.18 | | Europe (Stockholm) | Not available | Not available | | Europe (Zurich) | Not available | Not available | | Israel (Tel Aviv) | Not available | Not available | | Middle East (Bahrain) | Not available | Not available | | Middle East (UAE) | Not available | Not available | | South America (São Paulo) | Not available | Not available | | AWS GovCloud (US-East) | Not available | Not available | | AWS GovCloud (US-West) | Not available | Not available | ## Data API with Aurora MySQL Serverless v1 The following Regions and engine versions are available for Data API with Aurora MySQL Serverless v1. | Region | Aurora MySQL version 2 | | --- | --- | | US East (N. Virginia) | Version 2.11.3 | | US East (Ohio) | Version 2.11.3 | | US West (N. California) | Version 2.11.3 | | US West (Oregon) | Version 2.11.3 | | Africa (Cape Town) | Not available | | Asia Pacific (Hong Kong) | Not available | | Asia Pacific (Hyderabad) | Not available | | Asia Pacific (Jakarta) | Not available | | Asia Pacific (Malaysia) | Not available | | Asia Pacific (Melbourne) | Not available | | Asia Pacific (Mumbai) | Version 2.11.3 | | Asia Pacific (Osaka) | Not available | | Asia Pacific (Seoul) | Version 2.11.3 | | Asia Pacific (Singapore) | Version 2.11.3 | | Asia Pacific (Sydney) | Version 2.11.3 | | Asia Pacific (Thailand) | Not available | | Asia Pacific (Tokyo) | Version 2.11.3 | | Canada (Central) | Version 2.11.3 | | Canada West (Calgary) | Not available | | China (Beijing) | Not available | | China (Ningxia) | Version 2.11.3 | | Europe (Frankfurt) | Version 2.11.3 | | Europe (Ireland) | Version 2.11.3 | | Europe (London) | Version 2.11.3 | | Europe (Milan) | Not available | | Europe (Paris) | Version 2.11.3 | | Europe (Spain) | Version 2.11.3 | | Europe (Stockholm) | Not available | | Europe (Zurich) | Not available | | Israel (Tel Aviv) | Not available | | Middle East (Bahrain) | Not available | | Middle East (UAE) | Not available | | South America (São Paulo) | Not available | | AWS GovCloud (US-East) | Not available | | AWS GovCloud (US-West) | Not available | # Supported Regions and Aurora DB engines for zero-downtime patching (ZDP) Performing upgrades for Aurora DB clusters involves the possibility of an outage when the database is shut down and while it's being upgraded. By default, if you start the upgrade while the database is busy, you lose all the connections and transactions that the DB cluster is processing. If you wait until the database is idle to perform the upgrade, you might have to wait a long time. The zero-downtime patching (ZDP) feature attempts, on a best-effort basis, to preserve client connections through an Aurora upgrade. If ZDP completes successfully, application sessions are preserved and the database engine restarts while the upgrade is in progress. The database engine restart can cause a drop in throughput lasting for a few seconds to approximately one minute. For detailed information on the conditions and engine versions where ZDP is available for Aurora MySQL upgrades, see [Using zero-downtime patching](AuroraMySQL.Updates.ZDP.md). For detailed information on the conditions and engine versions where ZDP is available for Aurora PostgreSQL upgrades, see [Minor release upgrades and zero-downtime patching](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp). # Supported Regions Aurora PostgreSQL Limitless Database Amazon Aurora PostgreSQL Limitless Database provides automated horizontal scaling to process millions of write transactions per second and manages petabytes of data while maintaining the simplicity of operating inside a single database. With Aurora PostgreSQL Limitless Database, you can focus on building high-scale applications without having to build and maintain complex solutions for scaling your data across multiple DB instances to support your workloads. For more information, see [Using Amazon Aurora PostgreSQL Limitless Database](limitless.md). Aurora PostgreSQL Limitless Database is available in all AWS Regions except Asia Pacific (Taipei). # Supported Regions and DB engines for Aurora engine-native features Aurora database engines also support additional features and functionality specifically for Aurora. Some engine-native features might have limited support or restricted privileges for a particular Aurora DB engine, version, or Region. **Topics** + [ ## Engine-native features for Aurora MySQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.EngineNativeFeatures.amy) + [ ## Engine-native features for Aurora PostgreSQL ](#Concepts.Aurora_Fea_Regions_DB-eng.Feature.EngineNativeFeatures.apg) ## Engine-native features for Aurora MySQL Following are the engine-native features for Aurora MySQL. + [Advanced Auditing](AuroraMySQL.Auditing.md) + [Backtrack](AuroraMySQL.Managing.Backtrack.md) + [Fault injection queries](AuroraMySQL.Managing.FaultInjectionQueries.md) + [In-cluster write forwarding](aurora-mysql-write-forwarding.md) + [Parallel query](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-planning) ## Engine-native features for Aurora PostgreSQL Following are the engine-native features for Aurora PostgreSQL. + [Babelfish](babelfish.md) + [Fault injection queries](AuroraPostgreSQL.Managing.FaultInjectionQueries.md) + [Query plan management](AuroraPostgreSQL.Optimize.md) # Amazon Aurora endpoint connections Amazon Aurora typically involves a cluster of DB instances instead of a single instance. Each connection is handled by a specific DB instance. When you connect to an Aurora cluster, the host name and port that you specify point to an intermediate handler called an *endpoint*. Aurora uses the endpoint mechanism to abstract these connections. Thus, you don't have to hardcode all the hostnames or write your own logic for balancing and rerouting connections when some DB instances aren't available. For certain Aurora tasks, different instances or groups of instances perform different roles. For example, the primary instance handles all data definition language (DDL) and data manipulation language (DML) statements. Up to 15 Aurora Replicas handle read-only query traffic. **Topics** + [ ## Types of Aurora endpoints ](#Aurora.Overview.Endpoints.Types) + [ ## Viewing the endpoints for an Aurora cluster ](#Aurora.Endpoints.Viewing) + [ ## How Aurora endpoints work with high availability ](#Aurora.Overview.Endpoints.HA) + [ # Cluster endpoints for Amazon Aurora ](Aurora.Endpoints.Cluster.md) + [ # Reader endpoints for Amazon Aurora ](Aurora.Endpoints.Reader.md) + [ # Instance endpoints for Amazon Aurora ](Aurora.Endpoints.Instance.md) + [ # Custom endpoints for Amazon Aurora ](Aurora.Endpoints.Custom.md) ## Types of Aurora endpoints Using endpoints, you can map each connection to the appropriate instance or group of instances based on your use case. For example, to perform DDL statements you can connect to whichever instance is the primary instance. To perform queries, you can connect to the reader endpoint, with Aurora automatically performing connection-balancing among all the Aurora Replicas. For clusters with DB instances of different capacities or configurations, you can connect to custom endpoints associated with different subsets of DB instances. For diagnosis or tuning, you can connect to a specific instance endpoint to examine details about a specific DB instance. An endpoint is represented as an Aurora-specific URL that contains a host address and a port. The following types of endpoints are available from an Aurora DB cluster. **Cluster endpoint** Connect to the primary instance of your cluster to develop and test applications, and perform transformations like `INSERT` statements and DDL, DML, and ETL operations. Find the cluster endpoint location by using the AWS Management Console, AWS CLI, or Amazon RDS API, as described in [Viewing the endpoints for an Aurora cluster](#Aurora.Endpoints.Viewing). For more information about cluster endpoints, see [Cluster endpoints for Amazon Aurora](Aurora.Endpoints.Cluster.md). **Reader endpoint** Perform queries. Aurora automatically performs connection-balancing among all the Aurora Replicas. Find the reader endpoint location by using the AWS Management Console, AWS CLI, or Amazon RDS API, as described in [Viewing the endpoints for an Aurora cluster](#Aurora.Endpoints.Viewing). For more information about reader endpoints, see [Reader endpoints for Amazon Aurora](Aurora.Endpoints.Reader.md). **Instance endpoint** Examine details about a specific DB instance for diagnosis or tuning. You can find the instance endpoint location for each of your instances in the AWS Management Console only, on the instance detail page for your instance. For more information about instance endpoints, see [Instance endpoints for Amazon Aurora](Aurora.Endpoints.Instance.md). **Custom endpoint** Connect to different subsets of DB instances on the DB cluster. This is useful when you have different instance capacities and configurations within your DB cluster. Find the custom endpoint locations by using the AWS Management Console, AWS CLI, or Amazon RDS API, as described in [Viewing the endpoints for an Aurora cluster](#Aurora.Endpoints.Viewing). For more information about custom endpoints, see [Custom endpoints for Amazon Aurora](Aurora.Endpoints.Custom.md). **Aurora Global Database writer endpoint** Aurora Global Database has a special kind of endpoint that serves the same purpose as the cluster endpoint of a standalone Aurora cluster. It handles both write and read requests. When a secondary cluster becomes the new primary cluster due to a switchover or failover, Aurora automatically switches this endpoint to point to the cluster endpoint of the new primary cluster, in the other AWS Region. That way, you don't have to encode the AWS Region into the connection string for your application, and you don't have to change the connection string when the layout of the global database changes. Aurora creates this endpoint when you set up an Aurora Global Database, for example by choosing **Add Region** for an Aurora cluster in the AWS Management Console. For information on how you can use this type of endpoint with Aurora Global Database, see [Connecting to Amazon Aurora Global Database](aurora-global-database-connecting.md). ## Viewing the endpoints for an Aurora cluster While you can only find the instance endpoint location on the instance detail page in the AWS Management Console, you can use the console, AWS CLI, or Amazon RDS API to find the locations of cluster, reader, and custom endpoints. ------ #### [ Console ] In the AWS Management Console, find the cluster endpoint, the reader endpoint, and any custom endpoints in the instance details page for your cluster. You see the instance endpoint in the detail page for each instance. When you connect, append the associated port number, following a colon, to the endpoint name shown on the detail page. ------ #### [ AWS CLI ] With the AWS CLI, you find the writer, reader, and any custom endpoints in the output of the [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) command. For example, the following command shows the endpoint attributes for all clusters in your current AWS Region. ``` aws rds describe-db-clusters --query '*[].{Endpoint:Endpoint,ReaderEndpoint:ReaderEndpoint,CustomEndpoints:CustomEndpoints}' ``` ------ #### [ Amazon RDS API ] With the Amazon RDS API, you retrieve the endpoints by calling the [DescribeDBClusterEndpoints](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterEndpoints.html) operation. ------ ## How Aurora endpoints work with high availability For clusters where high availability is important, use the cluster endpoint for read/write or general-purpose connections and the reader endpoint for read-only connections. The writer and reader endpoints manage DB instance failover better than instance endpoints do. Unlike the instance endpoints, the writer and reader endpoints automatically change which DB instance they connect to if a DB instance in your cluster becomes unavailable. For more information about cluster and reader endpoints, see [Cluster endpoints for Amazon Aurora](Aurora.Endpoints.Cluster.md) and [Reader endpoints for Amazon Aurora](Aurora.Endpoints.Reader.md). If the primary DB instance of a DB cluster fails, Aurora automatically fails over to a new primary DB instance. It does so by either promoting an existing Aurora Replica to a new primary DB instance or creating a new primary DB instance. If a failover occurs, you can use the cluster endpoint to reconnect to the newly promoted or created primary DB instance, or use the reader endpoint to reconnect to one of the Aurora Replicas in the DB cluster. During a failover, the reader endpoint might direct connections to the new primary DB instance of a DB cluster for a short time after an Aurora Replica is promoted to the new primary DB instance. If you design your own application logic to manage connections to instance endpoints, you can manually or programmatically discover the resulting set of available DB instances in the DB cluster. Use the [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) AWS CLI command or [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) RDS API operation to find the DB cluster and reader endpoints, DB instances, whether DB instances are readers, and their promotion tiers. You can then confirm their instance classes after failover and connect to an appropriate instance endpoint. For more information about failovers, see [Fault tolerance for an Aurora DB cluster](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance). For more information about high availability in Amazon Aurora, see [High availability for Amazon Aurora](Concepts.AuroraHighAvailability.md). # Cluster endpoints for Amazon Aurora A *cluster endpoint* (or *writer endpoint*) for an Aurora DB cluster connects to the current primary DB instance for that DB cluster. This endpoint is the only one that can perform write operations such as DDL statements. Because of this, the cluster endpoint is the one that you connect to when you first set up a cluster or when your cluster only contains a single DB instance. Each Aurora DB cluster has one cluster endpoint and one primary DB instance. You use the cluster endpoint for all write operations on the DB cluster, including inserts, updates, deletes, and DDL changes. You can also use the cluster endpoint for read operations, such as queries. The cluster endpoint provides failover support for read/write connections to the DB cluster. If the current primary DB instance of a DB cluster fails, Aurora automatically fails over to a new primary DB instance. During a failover, the DB cluster continues to serve connection requests to the cluster endpoint from the new primary DB instance, with minimal interruption of service. The following example illustrates a cluster endpoint for an Aurora MySQL DB cluster. ``` mydbcluster.cluster-c7tj4example.us-east-1.rds.amazonaws.com:3306 ``` Each Aurora cluster has a single built-in cluster endpoint, whose name and other attributes are managed by Aurora. You can't create, delete, or modify this kind of endpoint. You use the cluster endpoint when you administer your cluster, perform extract, transform, load (ETL) operations, or develop and test applications. The cluster endpoint connects to the primary instance of the cluster. The primary instance is the only DB instance where you can create tables and indexes, run `INSERT` statements, and perform other DDL and DML operations. The physical IP address pointed to by the cluster endpoint changes when the failover mechanism promotes a new DB instance to be the read/write primary instance for the cluster. If you use any form of connection pooling or other multiplexing, be prepared to flush or reduce the time-to-live for any cached DNS information. Doing so ensures that you don't try to establish a read/write connection to a DB instance that became unavailable or is now read-only after a failover. # Reader endpoints for Amazon Aurora A *reader endpoint* for an Aurora DB cluster provides connection-balancing support for read-only connections to the DB cluster. Use the reader endpoint for read operations, such as queries. By processing those statements on the read-only Aurora Replicas, this endpoint reduces the overhead on the primary instance. It also helps the cluster to scale the capacity to handle simultaneous `SELECT` queries, proportional to the number of Aurora Replicas in the cluster. Each Aurora DB cluster has one reader endpoint. If the cluster contains one or more Aurora Replicas, the reader endpoint balances each connection request among the Aurora Replicas. In that case, you can only perform read-only statements such as `SELECT` in that session. If the cluster only contains a primary instance and no Aurora Replicas, the reader endpoint connects to the primary instance. In that case, you can perform write operations through the endpoint. The following example illustrates a reader endpoint for an Aurora MySQL DB cluster. ``` mydbcluster.cluster-ro-c7tj4example.us-east-1.rds.amazonaws.com:3306 ``` You use the reader endpoint for read-only connections for your Aurora cluster. This endpoint uses a connection-balancing mechanism to help your cluster handle a query-intensive workload. The reader endpoint is the endpoint that you supply to applications that do reporting or other read-only operations on the cluster. The reader endpoint balances connections to available Aurora Replicas in an Aurora DB cluster. It doesn't balance individual queries. If you want to balance each query to distribute the read workload for a DB cluster, open a new connection to the reader endpoint for each query. Each Aurora cluster has a single built-in reader endpoint, whose name and other attributes are managed by Aurora. You can't create, delete, or modify this kind of endpoint. If your cluster contains only a primary target (instance or DB shard group) and no Aurora Replicas, the reader endpoint connects to the primary instance. In that case, you can perform write operations through this endpoint. **Tip** Through RDS Proxy, you can create additional read-only endpoints for an Aurora cluster. These endpoints perform the same kind of connection-balancing as the Aurora reader endpoint. Applications can reconnect more quickly to the proxy endpoints than the Aurora reader endpoint if reader instances become unavailable. The proxy endpoints can also take advantage of other proxy features such as multiplexing. For more information, see [Using reader endpoints with Aurora clusters](rds-proxy-endpoints.md#rds-proxy-endpoints-reader). # Instance endpoints for Amazon Aurora An *instance endpoint* connects to a specific DB instance within an Aurora cluster. Each DB instance in a DB cluster has its own unique instance endpoint. So there is one instance endpoint for the current primary DB instance of the DB cluster, and there is one instance endpoint for each of the Aurora Replicas in the DB cluster. The instance endpoint provides direct control over connections to the DB cluster, for scenarios where using the cluster endpoint or reader endpoint might not be appropriate. For example, your client application might require more fine-grained connection balancing based on workload type. In this case, you can configure multiple clients to connect to different Aurora Replicas in a DB cluster to distribute read workloads. For an example that uses instance endpoints to improve connection speed after a failover for Aurora PostgreSQL, see [Fast failover with Amazon Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.FastFailover.md). For an example that uses instance endpoints to improve connection speed after a failover for Aurora MySQL, see [MariaDB Connector/J failover support - case Amazon Aurora](https://mariadb.org/mariadb-connectorj-failover-support-case-amazon-aurora/). The following example illustrates an instance endpoint for a DB instance in an Aurora MySQL DB cluster. ``` mydbinstance.c7tj4example.us-east-1.rds.amazonaws.com:3306 ``` Each DB instance in an Aurora cluster has its own built-in instance endpoint, whose name and other attributes are managed by Aurora. You can't create, delete, or modify this kind of endpoint. You might be familiar with instance endpoints if you use Amazon RDS. However, with Aurora you typically use the writer and reader endpoints more often than the instance endpoints. In day-to-day Aurora operations, the main way that you use instance endpoints is to diagnose capacity or performance issues that affect one specific instance in an Aurora cluster. While connected to a specific instance, you can examine its status variables, metrics, and so on. Doing this can help you determine what's happening for that instance that's different from what's happening for other instances in the cluster. In advanced use cases, you might configure some DB instances differently than others. In this case, use the instance endpoint to connect directly to an instance that is smaller, larger, or otherwise has different characteristics than the others. Also, set up failover priority so that this special DB instance is the last choice to take over as the primary instance. We recommend that you use custom endpoints instead of the instance endpoint in such cases. Doing so simplifies connection management and high availability as you add more DB instances to your cluster. # Custom endpoints for Amazon Aurora A *custom endpoint* for an Aurora cluster represents a set of DB instances that you choose. When you connect to the endpoint, Aurora performs connection balancing and chooses one of the instances in the group to handle the connection. You define which instances this endpoint refers to, and you decide what purpose the endpoint serves. An Aurora DB cluster has no custom endpoints until you create one. You can create up to five custom endpoints for each provisioned Aurora cluster or Aurora Serverless v2 cluster. The custom endpoint provides balanced database connections based on criteria other than the read-only or read/write capability of the DB instances. For example, you might define a custom endpoint to connect to instances that use a particular AWS instance class or a particular DB parameter group. Then you might tell particular groups of users about this custom endpoint. For example, you might direct internal users to low-capacity instances for report generation or ad hoc (one-time) querying, and direct production traffic to high-capacity instances. Because the connection can go to any DB instance that is associated with the custom endpoint, we recommend that you make sure that all the DB instances within that group share some similar characteristic. Doing so ensures that the performance, memory capacity, and so on, are consistent for everyone who connects to that endpoint. This feature is intended for advanced users with specialized kinds of workloads where it isn't practical to keep all the Aurora Replicas in the cluster identical. With custom endpoints, you can predict the capacity of the DB instance used for each connection. When you use custom endpoints, you typically don't use the reader endpoint for that cluster. The following example illustrates a custom endpoint for a DB instance in an Aurora MySQL DB cluster. ``` myendpoint.cluster-custom-c7tj4example.us-east-1.rds.amazonaws.com:3306 ``` You use custom endpoints to simplify connection management when your cluster contains DB instances with different capacities and configuration settings. Previously, you might have used the CNAMES mechanism to set up Domain Name Service (DNS) aliases from your own domain to achieve similar results. By using custom endpoints, you can avoid updating CNAME records when your cluster grows or shrinks. Custom endpoints also mean that you can use encrypted Transport Layer Security/Secure Sockets Layer (TLS/SSL) connections. Instead of using one DB instance for each specialized purpose and connecting to its instance endpoint, you can have multiple groups of specialized DB instances. In this case, each group has its own custom endpoint. This way, Aurora can perform connection balancing among all the instances dedicated to tasks such as reporting or handling production or internal queries. The custom endpoints distribute connections across instances passively, using DNS to return the IP address of one of the instances randomly. If one of the DB instances within a group becomes unavailable, Aurora directs subsequent custom endpoint connections to one of the other DB instances associated with the same endpoint. **Topics** + [ # Considerations for custom endpoints in Amazon Aurora ](Aurora.Endpoints.Custom.Considerations.md) + [ # Creating a custom endpoint ](aurora-custom-endpoint-creating.md) + [ # Viewing custom endpoints ](aurora-endpoint-viewing.md) + [ # Editing a custom endpoint ](aurora-endpoint-editing.md) + [ # Deleting a custom endpoint ](aurora-endpoints-custom-deleting.md) + [ # AWS CLI examples for custom endpoints for Amazon Aurora ](Aurora.Endpoint.Tutorial.md) # Considerations for custom endpoints in Amazon Aurora Use the following sections to manage, specify properties, and use membership rules for custom endpoints. **Topics** + [ ## Managing custom endpoints ](#Aurora.Endpoints.Custom.Managing) + [ ## Specifying properties for custom endpoints ](#Aurora.Endpoints.Custom.Properties) + [ ## Membership rules for custom endpoints ](#Aurora.Endpoints.Custom.Membership) ## Managing custom endpoints Because newly created Aurora clusters have no custom endpoints, you must create and manage these objects yourself. You do so using the AWS Management Console, AWS CLI, or Amazon RDS API. **Note** You must also create and manage custom endpoints for Aurora clusters restored from snapshots. Custom endpoints are not included in the snapshot. You create them again after restoring, and choose new endpoint names if the restored cluster is in the same region as the original one. To work with custom endpoints from the AWS Management Console, you navigate to the details page for your Aurora cluster and use the controls under the **Custom Endpoints** section. To work with custom endpoints from the AWS CLI, you can use these operations: + [create-db-cluster-endpoint](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster-endpoint.html) + [describe-db-cluster-endpoints](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-endpoints.html) + [modify-db-cluster-endpoint](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-endpoint.html) + [delete-db-cluster-endpoint](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster-endpoint.html) To work with custom endpoints through the Amazon RDS API, you can use the following functions: + [CreateDBClusterEndpoint](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBClusterEndpoint.html) + [DescribeDBClusterEndpoints](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterEndpoints.html) + [ModifyDBClusterEndpoint](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterEndpoint.html) + [DeleteDBClusterEndpoint](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBClusterEndpoint.html) ## Specifying properties for custom endpoints The maximum length for a custom endpoint name is 63 characters. The name format is the following: ``` endpoint_name.cluster-custom-customer_DNS_identifier.AWS_Region.rds.amazonaws.com ``` You can't reuse the same custom endpoint name for more than one cluster in the same AWS Region. The custom DNS identifier is a unique identifier associated with your AWS account in a particular AWS Region. Each custom endpoint has an associated type that determines which DB instances are eligible to be associated with that endpoint. Currently, the type can be `READER` or `ANY`. The following considerations apply to the custom endpoint types: + You can't select the custom endpoint type in the AWS Management Console. All the custom endpoints you create through the AWS Management Console have a type of `ANY`. You can set and modify the custom endpoint type using the AWS CLI or Amazon RDS API. + Only reader DB instances can be part of a `READER` custom endpoint. + Both reader and writer DB instances can be part of an `ANY` custom endpoint. Aurora directs connections to cluster endpoints with type `ANY` to any associated DB instance with equal probability. The `ANY` type applies to clusters using any replication topology. + If you try to create a custom endpoint with a type that isn't appropriate based on the replication configuration for a cluster, Aurora returns an error. ## Membership rules for custom endpoints When you add a DB instance to a custom endpoint or remove it from a custom endpoint, any existing connections to that DB instance remain active. You can define a list of DB instances to include in, or exclude from, a custom endpoint. We refer to these lists as *static* and *exclusion* lists, respectively. You can use the inclusion/exclusion mechanism to further subdivide the groups of DB instances, and to make sure that the set of custom endpoints covers all the DB instances in the cluster. Each custom endpoint can contain only one of these list types. In the AWS Management Console: + The choice is represented by the check box **Attach future instances added to this cluster**. When you keep the check box clear, the custom endpoint uses a static list containing only the DB instances specified on the page. When you choose the check box, the custom endpoint uses an exclusion list. In this case, the custom endpoint represents all DB instances in the cluster (including any that you add in the future) except the ones not selected on the page. + The console doesn't allow you to specify the endpoint type. Any custom endpoint created using the console is of type `ANY`. Therefore, Aurora doesn't change the membership of the custom endpoint when DB instances change roles between writer and reader due to failover or promotion. In the AWS CLI and Amazon RDS API: + You can specify the endpoint type. Therefore, when the endpoint type is set to `READER`, endpoint membership is automatically adjusted during failovers and promotions. For example, a custom endpoint with type `READER` includes an Aurora Replica that is then promoted to be a writer DB instance. The new writer instance is no longer part of the custom endpoint. + You can add individual members to and remove them from the lists after they change their roles. Use the [modify-db-cluster-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/modify-db-cluster-endpoint.html) AWS CLI command or [ModifyDBClusterEndpoint](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterEndpoint.html) API operation. You can associate a DB instance with more than one custom endpoint. For example, suppose that you add a new DB instance to a cluster, or that Aurora adds a DB instance automatically through the autoscaling mechanism. In these cases, the DB instance is added to all custom endpoints for which it is eligible. Which endpoints the DB instance is added to is based on the custom endpoint type of `READER` or `ANY`, plus any static or exclusion lists defined for each endpoint. For example, if the endpoint includes a static list of DB instances, newly added Aurora Replicas aren't added to that endpoint. Conversely, if the endpoint has an exclusion list, newly added Aurora Replicas are added to the endpoint, if they aren't named in the exclusion list and their roles match the type of the custom endpoint. If an Aurora Replica becomes unavailable, it remains associated with any custom endpoints. For example, it remains part of the custom endpoint when it is unhealthy, stopped, rebooting, and so on. However, you can't connect to it through those endpoints until it becomes available again. # Creating a custom endpoint Create a custom endpoint using the AWS Management Console, AWS CLI, or the Amazon RDS API. ## Console To create a custom endpoint with the AWS Management Console, go to the cluster detail page and choose the `Create custom endpoint` action in the **Endpoints** section. Choose a name for the custom endpoint, unique for your user ID and region. To choose a list of DB instances that remains the same even as the cluster expands, keep the check box **Attach future instances added to this cluster** clear. When you choose that check box, the custom endpoint dynamically adds any new instances as you add them to the cluster. ![\[Create custom endpoint page with fields for endpoint identifier, instance type selection, and static/exclusion options.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AuroraCreateCustomEndpoint.png) You can't select the custom endpoint type in the AWS Management Console. All custom endpoints you create through the AWS Management Console have a type of `ANY`. ## AWS CLI To create a custom endpoint with the AWS CLI, run the [create-db-cluster-endpoint](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster-endpoint.html) command. The following command creates a custom endpoint attached to a specific cluster. Initially, the endpoint is associated with all the Aurora Replica instances in the cluster. A subsequent command associates it with a specific set of DB instances in the cluster. For Linux, macOS, or Unix: ``` aws rds create-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-sample \ --endpoint-type reader \ --db-cluster-identifier cluster_id aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-sample \ --static-members instance_name_1 instance_name_2 ``` For Windows: ``` aws rds create-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-sample ^ --endpoint-type reader ^ --db-cluster-identifier cluster_id aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier custom-endpoint-doc-sample ^ --static-members instance_name_1 instance_name_2 ``` ## RDS API To create a custom endpoint with the RDS API, run the [CreateDBClusterEndpoint](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBClusterEndpoint.html) operation. # Viewing custom endpoints ## Console To view custom endpoints with the AWS Management Console, go to the cluster detail page for the cluster and look under the **Endpoints** section. This section contains information only about custom endpoints. The details for the built-in endpoints are listed in the main **Details** section. To see the details for a specific custom endpoint, select its name to bring up the detail page for that endpoint. The following screenshot shows how the list of custom endpoints for an Aurora cluster is initially empty. ![\[Endpoints page with no custom endpoints.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AuroraCustomEndpointEmptyList.png) After you create some custom endpoints for that cluster, they are shown under the **Endpoints** section. ![\[Endpoints page with two custom endpoints.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AuroraCustomEndpointList.png) Clicking through to the detail page shows which DB instances the endpoint is currently associated with. ![\[DB instances associated with a custom endpoint.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AuroraCustomEndpointDetail.png) To see the additional detail of whether new DB instances added to the cluster are automatically added to the endpoint also, open the **Edit** page for the endpoint. ## AWS CLI To view custom endpoints with the AWS CLI, run the [describe-db-cluster-endpoints](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-endpoints.html) command. The following command shows the custom endpoints associated with a specified cluster in a specified region. The output includes both the built-in endpoints and any custom endpoints. For Linux, macOS, or Unix: ``` aws rds describe-db-cluster-endpoints --region region_name \ --db-cluster-identifier cluster_id ``` For Windows: ``` aws rds describe-db-cluster-endpoints --region region_name ^ --db-cluster-identifier cluster_id ``` The following shows some sample output from a `describe-db-cluster-endpoints` command. The `EndpointType` of `WRITER` or `READER` denotes the built-in read/write and read-only endpoints for the cluster. The `EndpointType` of `CUSTOM` denotes endpoints that you create and choose the associated DB instances. One of the endpoints has a non-empty `StaticMembers` field, denoting that it is associated with a precise set of DB instances. The other endpoint has a non-empty `ExcludedMembers` field, denoting that the endpoint is associated with all DB instances *other than* the ones listed under `ExcludedMembers`. This second kind of custom endpoint grows to accommodate new instances as you add them to the cluster. ``` { "DBClusterEndpoints": [ { "Endpoint": "custom-endpoint-demo.cluster-c7tj4example.ca-central-1.rds.amazonaws.com", "Status": "available", "DBClusterIdentifier": "custom-endpoint-demo", "EndpointType": "WRITER" }, { "Endpoint": "custom-endpoint-demo.cluster-ro-c7tj4example.ca-central-1.rds.amazonaws.com", "Status": "available", "DBClusterIdentifier": "custom-endpoint-demo", "EndpointType": "READER" }, { "CustomEndpointType": "ANY", "DBClusterEndpointIdentifier": "powers-of-2", "ExcludedMembers": [], "DBClusterIdentifier": "custom-endpoint-demo", "Status": "available", "EndpointType": "CUSTOM", "Endpoint": "powers-of-2.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com", "StaticMembers": [ "custom-endpoint-demo-04", "custom-endpoint-demo-08", "custom-endpoint-demo-01", "custom-endpoint-demo-02" ], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:powers-of-2" }, { "CustomEndpointType": "ANY", "DBClusterEndpointIdentifier": "eight-and-higher", "ExcludedMembers": [ "custom-endpoint-demo-04", "custom-endpoint-demo-02", "custom-endpoint-demo-07", "custom-endpoint-demo-05", "custom-endpoint-demo-03", "custom-endpoint-demo-06", "custom-endpoint-demo-01" ], "DBClusterIdentifier": "custom-endpoint-demo", "Status": "available", "EndpointType": "CUSTOM", "Endpoint": "eight-and-higher.cluster-custom-123456789012.ca-central-1.rds.amazonaws.com", "StaticMembers": [], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHYQKFU6J6NV5FHU", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:eight-and-higher" } ] } ``` ## RDS API To view custom endpoints with the RDS API, run the [DescribeDBClusterEndpoints.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterEndpoints.html.html) operation. # Editing a custom endpoint You can edit the properties of a custom endpoint to change which DB instances are associated with the endpoint. You can also change an endpoint between a static list and an exclusion list. If you need more details about these endpoint properties, see [Membership rules for custom endpoints](Aurora.Endpoints.Custom.Considerations.md#Aurora.Endpoints.Custom.Membership). You can continue connecting to and using a custom endpoint while the changes from an edit action are in progress. ## Console To edit a custom endpoint with the AWS Management Console, you can select the endpoint on the cluster detail page, or bring up the detail page for the endpoint, and choose the **Edit** action. ![\[Editing a custom endpoint.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AuroraEditCustomEndpoint.png) ## AWS CLI To edit a custom endpoint with the AWS CLI, run the [modify-db-cluster-endpoint](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-endpoint.html) command. The following commands change the set of DB instances that apply to a custom endpoint and optionally switches between the behavior of a static or exclusion list. The `--static-members` and `--excluded-members` parameters take a space-separated list of DB instance identifiers. For Linux, macOS, or Unix: ``` aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier my-custom-endpoint \ --static-members db-instance-id-1 db-instance-id-2 db-instance-id-3 \ --region region_name aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier my-custom-endpoint \ --excluded-members db-instance-id-4 db-instance-id-5 \ --region region_name ``` For Windows: ``` aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier my-custom-endpoint ^ --static-members db-instance-id-1 db-instance-id-2 db-instance-id-3 ^ --region region_name aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier my-custom-endpoint ^ --excluded-members db-instance-id-4 db-instance-id-5 ^ --region region_name ``` ## RDS API To edit a custom endpoint with the RDS API, run the [ModifyDBClusterEndpoint.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBClusterEndpoint.html.html) operation. # Deleting a custom endpoint Delete a custom endpoint using the AWS Management Console, AWS CLI, or the Amazon RDS API. ## Console To delete a custom endpoint with the AWS Management Console, go to the cluster detail page, select the appropriate custom endpoint, and select the **Delete** action. ![\[Delete custom endpoint page.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AuroraDeleteCustomEndpoint.png) ## AWS CLI To delete a custom endpoint with the AWS CLI, run the [delete-db-cluster-endpoint](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster-endpoint.html) command. The following command deletes a custom endpoint. You don't need to specify the associated cluster, but you must specify the region. For Linux, macOS, or Unix: ``` aws rds delete-db-cluster-endpoint --db-cluster-endpoint-identifier custom-end-point-id \ --region region_name ``` For Windows: ``` aws rds delete-db-cluster-endpoint --db-cluster-endpoint-identifier custom-end-point-id ^ --region region_name ``` ## RDS API To delete a custom endpoint with the RDS API, run the [DeleteDBClusterEndpoint](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBClusterEndpoint.html) operation. # AWS CLI examples for custom endpoints for Amazon Aurora The following tutorial uses AWS CLI examples with Unix shell syntax to show how you might define a cluster with several "small" DB instances and a few "big" DB instances, and create custom endpoints to connect to each set of DB instances. To run similar commands on your own system, you should be familiar enough with the basics of working with Aurora clusters and AWS CLI usage to supply your own values for parameters such as region, subnet group, and VPC security group. This example demonstrates the initial setup steps: creating an Aurora cluster and adding DB instances to it. This is a heterogeneous cluster, meaning not all the DB instances have the same capacity. Most instances use the AWS instance class `db.r4.4xlarge`, but the last two DB instances use `db.r4.16xlarge`. Each of these sample `create-db-instance` commands prints its output to the screen and saves a copy of the JSON in a file for later inspection. ``` aws rds create-db-cluster --db-cluster-identifier custom-endpoint-demo --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.04.0 --master-username $MASTER_USER --manage-master-user-password \ --db-subnet-group-name $SUBNET_GROUP --vpc-security-group-ids $VPC_SECURITY_GROUP \ --region $REGION for i in 01 02 03 04 05 06 07 08 do aws rds create-db-instance --db-instance-identifier custom-endpoint-demo-${i} \ --engine aurora --db-cluster-identifier custom-endpoint-demo --db-instance-class db.r4.4xlarge \ --region $REGION \ | tee custom-endpoint-demo-${i}.json done for i in 09 10 do aws rds create-db-instance --db-instance-identifier custom-endpoint-demo-${i} \ --engine aurora --db-cluster-identifier custom-endpoint-demo --db-instance-class db.r4.16xlarge \ --region $REGION \ | tee custom-endpoint-demo-${i}.json done ``` The larger instances are reserved for specialized kinds of reporting queries. To make it unlikely for them to be promoted to the primary instance, the following example changes their promotion tier to the lowest priority. This example specifies the `--manage-master-user-password` option to generate the master user password and manage it in Secrets Manager. For more information, see [Password management with Amazon Aurora and AWS Secrets Manager](rds-secrets-manager.md). Alternatively, you can use the `--master-password` option to specify and manage the password yourself. ``` for i in 09 10 do aws rds modify-db-instance --db-instance-identifier custom-endpoint-demo-${i} \ --region $REGION --promotion-tier 15 done ``` Suppose that you want to use the two "bigger" instances only for the most resource-intensive queries. To do this, you can first create a custom read-only endpoint. Then you can add a static list of members so that the endpoint connects only to those DB instances. Those instances are already in the lowest promotion tier, making it unlikely either of them will be promoted to the primary instance. If one of them is promoted to the primary instance, it becomes unreachable through this endpoint because we specified the `READER` type instead of the `ANY` type. The following example demonstrates the create and modify endpoint commands, and sample JSON output showing the initial and modified state of the custom endpoint. ``` $ aws rds create-db-cluster-endpoint --region $REGION \ --db-cluster-identifier custom-endpoint-demo \ --db-cluster-endpoint-identifier big-instances --endpoint-type reader { "EndpointType": "CUSTOM", "Endpoint": "big-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com", "DBClusterEndpointIdentifier": "big-instances", "DBClusterIdentifier": "custom-endpoint-demo", "StaticMembers": [], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU", "ExcludedMembers": [], "CustomEndpointType": "READER", "Status": "creating", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:big-instances" } $ aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier big-instances \ --static-members custom-endpoint-demo-09 custom-endpoint-demo-10 --region $REGION { "EndpointType": "CUSTOM", "ExcludedMembers": [], "DBClusterEndpointIdentifier": "big-instances", "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU", "CustomEndpointType": "READER", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:big-instances", "StaticMembers": [ "custom-endpoint-demo-10", "custom-endpoint-demo-09" ], "Status": "modifying", "Endpoint": "big-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com", "DBClusterIdentifier": "custom-endpoint-demo" } ``` The default `READER` endpoint for the cluster can connect to either the "small" or "big" DB instances, making it impractical to predict query performance and scalability when the cluster becomes busy. To divide the workload cleanly between the sets of DB instances, you can ignore the default `READER` endpoint and create a second custom endpoint that connects to all other DB instances. The following example does so by creating a custom endpoint and then adding an exclusion list. Any other DB instances you add to the cluster later will be added to this endpoint automatically. The `ANY` type means that this endpoint is associated with eight instances in total: the primary instance and another seven Aurora Replicas. If the example used the `READER` type, the custom endpoint would only be associated with the seven Aurora Replicas. ``` $ aws rds create-db-cluster-endpoint --region $REGION --db-cluster-identifier custom-endpoint-demo \ --db-cluster-endpoint-identifier small-instances --endpoint-type any { "Status": "creating", "DBClusterEndpointIdentifier": "small-instances", "CustomEndpointType": "ANY", "EndpointType": "CUSTOM", "Endpoint": "small-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com", "StaticMembers": [], "ExcludedMembers": [], "DBClusterIdentifier": "custom-endpoint-demo", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:small-instances", "DBClusterEndpointResourceIdentifier": "cluster-endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY" } $ aws rds modify-db-cluster-endpoint --db-cluster-endpoint-identifier small-instances \ --excluded-members custom-endpoint-demo-09 custom-endpoint-demo-10 --region $REGION { "DBClusterEndpointIdentifier": "small-instances", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:c7tj4example:cluster-endpoint:small-instances", "DBClusterEndpointResourceIdentifier": "cluster-endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY", "CustomEndpointType": "ANY", "Endpoint": "small-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com", "EndpointType": "CUSTOM", "ExcludedMembers": [ "custom-endpoint-demo-09", "custom-endpoint-demo-10" ], "StaticMembers": [], "DBClusterIdentifier": "custom-endpoint-demo", "Status": "modifying" } ``` The following example checks the state of the endpoints for this cluster. The cluster still has its original cluster endpoint, with `EndPointType` of `WRITER`, which you would still use for administration, ETL, and other write operations. It still has its original `READER` endpoint, which you wouldn't use because each connection to it might be directed to a "small" or "big" DB instance. The custom endpoints make this behavior predictable, with connections guaranteed to use one of the "small" or "big" DB instances based on the endpoint you specify. ``` $ aws rds describe-db-cluster-endpoints --region $REGION { "DBClusterEndpoints": [ { "EndpointType": "WRITER", "Endpoint": "custom-endpoint-demo.cluster-c7tj4example.ca-central-1.rds.amazonaws.com", "Status": "available", "DBClusterIdentifier": "custom-endpoint-demo" }, { "EndpointType": "READER", "Endpoint": "custom-endpoint-demo.cluster-ro-c7tj4example.ca-central-1.rds.amazonaws.com", "Status": "available", "DBClusterIdentifier": "custom-endpoint-demo" }, { "Endpoint": "small-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com", "CustomEndpointType": "ANY", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:small-instances", "ExcludedMembers": [ "custom-endpoint-demo-09", "custom-endpoint-demo-10" ], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-6RDDXQOC3AKKZT2PRD7ST37BMY", "DBClusterIdentifier": "custom-endpoint-demo", "StaticMembers": [], "EndpointType": "CUSTOM", "DBClusterEndpointIdentifier": "small-instances", "Status": "modifying" }, { "Endpoint": "big-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com", "CustomEndpointType": "READER", "DBClusterEndpointArn": "arn:aws:rds:ca-central-1:111122223333:cluster-endpoint:big-instances", "ExcludedMembers": [], "DBClusterEndpointResourceIdentifier": "cluster-endpoint-W7PE3TLLFNSHXQKFU6J6NV5FHU", "DBClusterIdentifier": "custom-endpoint-demo", "StaticMembers": [ "custom-endpoint-demo-10", "custom-endpoint-demo-09" ], "EndpointType": "CUSTOM", "DBClusterEndpointIdentifier": "big-instances", "Status": "available" } ] } ``` The final examples demonstrate how successive database connections to the custom endpoints connect to the various DB instances in the Aurora cluster. The `small-instances` endpoint always connects to the `db.r4.4xlarge` DB instances, which are the lower-numbered hosts in this cluster. ``` $ mysql -h small-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com -u $MYUSER -p mysql> select @@aurora_server_id; +-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-02 | +-------------------------+ $ mysql -h small-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com -u $MYUSER -p mysql> select @@aurora_server_id; +-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-07 | +-------------------------+ $ mysql -h small-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com -u $MYUSER -p mysql> select @@aurora_server_id; +-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-01 | +-------------------------+ ``` The `big-instances` endpoint always connects to the `db.r4.16xlarge` DB instances, which are the two highest-numbered hosts in this cluster. ``` $ mysql -h big-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com -u $MYUSER -p mysql> select @@aurora_server_id; +-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-10 | +-------------------------+ $ mysql -h big-instances.cluster-custom-c7tj4example.ca-central-1.rds.amazonaws.com -u $MYUSER -p mysql> select @@aurora_server_id; +-------------------------+ | @@aurora_server_id | +-------------------------+ | custom-endpoint-demo-09 | +-------------------------+ ``` # Amazon AuroraDB instance classes The DB instance class determines the computation and memory capacity of an Amazon Aurora DB instance. The DB instance class that you need depends on your processing power and memory requirements. A DB instance class consists of both the DB instance class type and the size. For example, db.r6g is a memory-optimized DB instance class type powered by AWS Graviton2 processors. Within the db.r6g instance class type, db.r6g.2xlarge is a DB instance class. The size of this class is 2xlarge. For more information about instance class pricing, see [Amazon RDS pricing](https://aws.amazon.com/rds/pricing/). For more information about DB instance class types, supported DB engines, supported AWS Regions, or hardware specifications for DB instance classes, see the following sections. **Topics** + [ # DB instance class types ](Concepts.DBInstanceClass.Types.md) + [ # Supported DB engines for DB instance classes ](Concepts.DBInstanceClass.SupportAurora.md) + [ # Determining DB instance class support in AWS Regions ](Concepts.DBInstanceClass.RegionSupportAurora.md) + [ # Hardware specifications for DB instance classesfor Aurora ](Concepts.DBInstanceClass.Summary.md) # DB instance class types Amazon Aurora supports DB instance classes for the following use cases: + [Aurora Serverless v2](#Concepts.DBInstanceClass.Types.serverless-v2) + [Memory-optimized](#Concepts.DBInstanceClass.Types.memory) + [Burstable-performance](#Concepts.DBInstanceClass.Types.burstable) + [Optimized Reads](#Concepts.DBInstanceClass.Types.optimized-reads) For more information about Amazon EC2 instance types, see [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) in the Amazon EC2 documentation. ## Aurora Serverless v2 instance class type The following Aurora Serverless v2 type is available: + **db.serverless** – A special DB instance class type used by Aurora Serverless v2. Aurora adjusts the compute, memory, and network resources dynamically as the workload changes. For usage details, see [Using Aurora Serverless v2](aurora-serverless-v2.md). ## Memory-optimized instance class types The memory-optimized X family supports the following instance classes: + **db.x2g** – Instance classes optimized for memory-intensive applications and powered by AWS Graviton2 processors. These instance classes offer low cost per GiB of memory. You can modify a DB instance to use one of the DB instance classes powered by AWS Graviton2 processors. To do so, complete the same steps as with any other DB instance modification. The memory-optimized R family supports the following instance class types: + **db.r8g** – Instance classes powered by AWS Graviton4 processors. These instance classes are ideal for running memory-intensive workloads. These instances offer larger instance sizes with up to 3x more vCPUs and memory than the seventh-generation AWS Graviton3-based db.r7g instances. They are powered by the AWS Nitro System, a combination of dedicated hardware and lightweight hypervisor. + You can modify a DB instance to use one of the DB instance classes powered by AWS Graviton4 processors. To do so, complete the same steps as with any other DB instance modification. + **db.r8i** – Instance classes powered by Intel Xeon 6 processors. These instance classes are ideal for running memory-intensive workloads that benefit from high-performance local storage, including in-memory databases, real-time big data analytics, large in-memory caches, scientific computing applications requiring scratch space, and data processing applications needing high-speed local storage. + **db.r7g** – Instance classes powered by AWS Graviton3 processors. These instance classes are ideal for running memory-intensive workloads. You can modify a DB instance to use one of the DB instance classes powered by AWS Graviton3 processors. To do so, complete the same steps as with any other DB instance modification. They are powered by the AWS Nitro System, a combination of dedicated hardware and lightweight hypervisor. + **db.r7i** – Instance classes powered by 4th Generation Intel Xeon Scalable processors. These instance classes are SAP-Certified and are ideal for running memory-intensive workloads. You can modify a DB instance to use one of the DB instance classes powered by 4th Generation Intel Xeon Scalable processors. To do so, complete the same steps as with any other DB instance modification. They are powered by the AWS Nitro System, a combination of dedicated hardware and lightweight hypervisor. + **db.r6g** – Instance classes powered by AWS Graviton2 processors. These instance classes are ideal for running memory-intensive workloads. They are powered by the AWS Nitro System, a combination of dedicated hardware and lightweight hypervisor. + You can modify a DB instance to use one of the DB instance classes powered by AWS Graviton2 processors. To do so, complete the same steps as with any other DB instance modification. + **db.r6i** – Instance classes powered by 3rd Generation Intel Xeon Scalable processors. These instance classes are SAP-Certified and are an ideal fit for memory-intensive workloads. + **db.r5** – Instance classes optimized for memory-intensive applications. These instance classes offer improved networking and Amazon Elastic Block Store (Amazon EBS) performance. They are powered by the AWS Nitro System, a combination of dedicated hardware and lightweight hypervisor. + **db.r4** – These instance classes are supported only for Aurora MySQL 2.x and Aurora PostgreSQL 11 and 12 versions. For all Aurora DB clusters that use db.r4 DB instance classes, we recommend that you upgrade to a higher generation instance class as soon as possible. The db.r4 instance classes aren't available for the Aurora I/O-Optimized cluster storage configuration. ## Burstable-performance instance class types The following burstable-performance DB instance class types are available: + **db.t4g** – General-purpose instance classes powered by Arm-based AWS Graviton2 processors. These instance classes deliver better price performance than previous burstable-performance DB instance classes for a broad set of burstable general-purpose workloads. Amazon RDS db.t4g instances are configured for Unlimited mode. This means that they can burst beyond the baseline over a 24-hour window for an additional charge. You can modify a DB instance to use one of the DB instance classes powered by AWS Graviton2 processors. To do so, complete the same steps as with any other DB instance modification. + **db.t3** – Instance classes that provide a baseline performance level, with the ability to burst to full CPU usage. The db.t3 instances are configured for Unlimited mode. These instance classes provide more computing capacity than the previous db.t2 instance classes. They are powered by the AWS Nitro System, a combination of dedicated hardware and lightweight hypervisor. We recommend using these instance classes only for development and test servers, or other non-production servers. + **db.t2** – Instance classes that provide a baseline performance level, with the ability to burst to full CPU usage. The db.t2 instances are configured for Unlimited mode. We recommend using these instance classes only for development and test servers, or other non-production servers. The db.t2 instance classes aren't available for the Aurora I/O-Optimized cluster storage configuration. **Note** We recommend using the T DB instance classes only for development, test, or other nonproduction servers. For more detailed recommendations for the T instance classes, see [Using T instance classes for development and testing](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium). For DB instance class hardware specifications, see [Hardware specifications for DB instance classesfor Aurora](Concepts.DBInstanceClass.Summary.md). ## Optimized Reads instance class types The following Optimized Reads instance class types are available: + **db.r8gd** – Instance classes powered by Graviton4 processors. These instance classes are ideal for running memory-intensive workloads and offer local NVMe-based SSD block-level storage for applications that need high-speed, low latency local storage. They offer a maximum memory of 1.5 TiB and up to 11.4 TB of direct-attached NVMe-based SSD storage. + **db.r6gd** – Instance classes powered by AWS Graviton2 processors. These instance classes are ideal for running memory-intensive workloads and offer local NVMe-based SSD block-level storage for applications that need high-speed, low latency local storage. + **db.r6id** – Instance classes powered by 3rd Generation Intel Xeon Scalable processors. These instance classes are SAP-Certified and are an ideal fit for memory-intensive workloads. They offer a maximum memory of 1 TiB and up to 7.6 TB of direct-attached NVMe-based SSD storage. # Supported DB engines for DB instance classes The following tables show the supported DB instance classes for the Amazon Aurora DB engines. **db.serverless – Aurora Serverless v2 instance class with automatic capacity scaling** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.x2g – memory-optimized instance classes powered by AWS Graviton2 processors** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r6gd – Optimized Reads instance classes powered by AWS Graviton2 processors** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r6id – Optimized Reads instance classes** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r8g – memory-optimized instance classes powered by AWS Graviton4 processors** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r8gd – optimized reads instance classes powered by AWS Graviton4 processors** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r7g – memory-optimized instance classes powered by AWS Graviton3 processors** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r7i – memory-optimized instance classes** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r6g – memory-optimized instance classes powered by AWS Graviton2 processors** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r6i – memory-optimized instance classes** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r5 – memory-optimized instance classes** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.r4 – memory-optimized instance classes** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.t4g – burstable-performance instance classes powered by AWS Graviton2 processors** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.t3 – burstable-performance instance classes** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) **db.t2 – burstable-performance instance classes** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.SupportAurora.html) # Determining DB instance class support in AWS Regions To determine the DB instance classes supported by each DB engine in a specific AWS Region, you can take one of several approaches. You can use the AWS Management Console, the [Amazon RDS Pricing](https://aws.amazon.com/rds/pricing/) page, or the [describe-orderable-db-instance-options](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-orderable-db-instance-options.html) AWS CLI command. **Note** When you perform operations with the AWS Management Console, it automatically shows the supported DB instance classes for a specific DB engine, DB engine version, and AWS Region. Examples of the operations that you can perform include creating and modifying a DB instance. **Contents** + [ ## Using the Amazon RDS pricing page to determine DB instance class support in AWS Regions ](#Concepts.DBInstanceClass.RegionSupportAurora.PricingPage) + [ ## Using the AWS CLI to determine DB instance class support in AWS Regions ](#Concepts.DBInstanceClass.RegionSupportAurora.CLI) + [ ### Listing the DB instance classes that are supported by a specific DB engine version in an AWS Region ](#Concepts.DBInstanceClass.RegionSupportAurora.CLI.Example1) + [ ### Listing the DB engine versions that support a specific DB instance class in an AWS Region ](#Concepts.DBInstanceClass.RegionSupportAurora.CLI.Example2) ## Using the Amazon RDS pricing page to determine DB instance class support in AWS Regions You can use the [Amazon Aurora Pricing](https://aws.amazon.com/rds/pricing/) page to determine the DB instance classes supported by each DB engine in a specific AWS Region. **To use the pricing page to determine the DB instance classes supported by each engine in a Region** 1. Go to [Amazon Aurora Pricing](https://aws.amazon.com/rds/aurora/pricing/). 1. Choose an Amazon Aurora engine in the **AWS Pricing Calculator** section. 1. In **Choose a Region**, choose an AWS Region. 1. In **Cluster Configuration Option**, choose a configuration option. 1. Use the section for compatible instances to view the supported DB instance classes. 1. (Optional) Choose other options in the calculator, and then choose **Save and view summary** or **Save and add service**. ## Using the AWS CLI to determine DB instance class support in AWS Regions You can use the AWS CLI to determine which DB instance classes are supported for specific DB engines and DB engine versions in an AWS Region. To use the AWS CLI examples following, enter valid values for the DB engine, DB engine version, DB instance class, and AWS Region. The following table shows the valid DB engine values. **** | Engine name | Engine value in CLI commands | More information about versions | | --- | --- | --- | | MySQL 5.7-compatible and 8.0-compatible Aurora | `aurora-mysql` | [ Database engine updates for Amazon Aurora MySQL version 2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.20Updates.html) and [ Database engine updates for Amazon Aurora MySQL version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) in the *Release Notes for Aurora MySQL* | | Aurora PostgreSQL | `aurora-postgresql` | [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html) | For information about AWS Region names, see [AWS RegionsAvailability Zones](Concepts.RegionsAndAvailabilityZones.md#Concepts.RegionsAndAvailabilityZones.Regions). The following examples demonstrate how to determine DB instance class support in an AWS Region using the [describe-orderable-db-instance-options](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-orderable-db-instance-options.html) AWS CLI command. **Topics** + [ ### Listing the DB instance classes that are supported by a specific DB engine version in an AWS Region ](#Concepts.DBInstanceClass.RegionSupportAurora.CLI.Example1) + [ ### Listing the DB engine versions that support a specific DB instance class in an AWS Region ](#Concepts.DBInstanceClass.RegionSupportAurora.CLI.Example2) ### Listing the DB instance classes that are supported by a specific DB engine version in an AWS Region To list the DB instance classes that are supported by a specific DB engine version in an AWS Region, run the following command. For Linux, macOS, or Unix: ``` aws rds describe-orderable-db-instance-options --engine engine --engine-version version \ --query "OrderableDBInstanceOptions[].{DBInstanceClass:DBInstanceClass,SupportedEngineModes:SupportedEngineModes[0]}" \ --output table \ --region region ``` For Windows: ``` aws rds describe-orderable-db-instance-options --engine engine --engine-version version ^ --query "OrderableDBInstanceOptions[].{DBInstanceClass:DBInstanceClass,SupportedEngineModes:SupportedEngineModes[0]}" ^ --output table ^ --region region ``` The output also shows the engine modes that are supported for each DB instance class. For example, the following command lists the supported DB instance classes for version 13.6 of the Aurora PostgreSQL DB engine in US East (N. Virginia). For Linux, macOS, or Unix: ``` aws rds describe-orderable-db-instance-options --engine aurora-postgresql --engine-version 15.3 \ --query "OrderableDBInstanceOptions[].{DBInstanceClass:DBInstanceClass,SupportedEngineModes:SupportedEngineModes[0]}" \ --output table \ --region us-east-1 ``` For Windows: ``` aws rds describe-orderable-db-instance-options --engine aurora-postgresql --engine-version 15.3 ^ --query "OrderableDBInstanceOptions[].{DBInstanceClass:DBInstanceClass,SupportedEngineModes:SupportedEngineModes[0]}" ^ --output table ^ --region us-east-1 ``` ### Listing the DB engine versions that support a specific DB instance class in an AWS Region To list the DB engine versions that support a specific DB instance class in an AWS Region, run the following command. For Linux, macOS, or Unix: ``` aws rds describe-orderable-db-instance-options --engine engine --db-instance-class DB_instance_class \ --query "OrderableDBInstanceOptions[].{EngineVersion:EngineVersion,SupportedEngineModes:SupportedEngineModes[0]}" \ --output table \ --region region ``` For Windows: ``` aws rds describe-orderable-db-instance-options --engine engine --db-instance-class DB_instance_class ^ --query "OrderableDBInstanceOptions[].{EngineVersion:EngineVersion,SupportedEngineModes:SupportedEngineModes[0]}" ^ --output table ^ --region region ``` The output also shows the engine modes that are supported for each DB engine version. For example, the following command lists the DB engine versions of the Aurora PostgreSQL DB engine that support the db.r5.large DB instance class in US East (N. Virginia). For Linux, macOS, or Unix: ``` aws rds describe-orderable-db-instance-options --engine aurora-postgresql --db-instance-class db.r7g.large \ --query "OrderableDBInstanceOptions[].{EngineVersion:EngineVersion,SupportedEngineModes:SupportedEngineModes[0]}" \ --output table \ --region us-east-1 ``` For Windows: ``` aws rds describe-orderable-db-instance-options --engine aurora-postgresql --db-instance-class db.r7g.large ^ --query "OrderableDBInstanceOptions[].{EngineVersion:EngineVersion,SupportedEngineModes:SupportedEngineModes[0]}" ^ --output table ^ --region us-east-1 ``` # Hardware specifications for DB instance classesfor Aurora In the table in this section, you can find hardware details about the Amazon RDS DB instance classes for Aurora. For information about Aurora DB engine support for each DB instance class, see [Supported DB engines for DB instance classes](Concepts.DBInstanceClass.SupportAurora.md). **Topics** + [ ## Hardware terminology for DB instance classesfor Aurora ](#Concepts.DBInstanceClass.hardware-terminology) + [ ## Hardware specifications for the memory-optimized instance classes ](#hw-specs-aur.mem-opt) + [ ## Hardware specifications for the burstable-performance instance classes ](#hardware-specifications.burstable-inst-classes) ## Hardware terminology for DB instance classesfor Aurora The following terminology is used to describe hardware specifications for DB instance classes: **vCPU** The number of virtual central processing units (CPUs). A *virtual CPU *is a unit of capacity that you can use to compare DB instance classes. Instead of purchasing or leasing a particular processor to use for several months or years, you are renting capacity by the hour. Our goal is to make a consistent and specific amount of CPU capacity available, within the limits of the actual underlying hardware. **ECU** The relative measure of the integer processing power of an Amazon EC2 instance. To make it easy for developers to compare CPU capacity between different instance classes, we have defined an Amazon EC2 Compute Unit. The amount of CPU that is allocated to a particular instance is expressed in terms of these EC2 Compute Units. One ECU currently provides CPU capacity equivalent to a 1.0–1.2 GHz 2007 Opteron or 2007 Xeon processor. **Memory (GiB)** The RAM, in gibibytes, allocated to the DB instance. There is often a consistent ratio between memory and vCPU. As an example, take the db.r4 instance class, which has a memory to vCPU ratio similar to the db.r5 instance class. However, for most use cases the db.r5 instance class provides better, more consistent performance than the db.r4 instance class. **Max. EBS bandwidth (Mbps)** The maximum EBS bandwidth in megabits per second. Divide by 8 to get the expected throughput in megabytes per second. This figure refers to I/O bandwidth for local storage within the DB instance. It doesn't apply to communication with the Aurora cluster volume. **Network bandwidth** The network speed relative to other DB instance classes. For information on using Amazon CloudWatch metrics to monitor your Aurora DB instance throughput, see [Evaluating DB instance usage for Aurora MySQL with Amazon CloudWatch metrics](AuroraMySQL.BestPractices.CW.md) and [Evaluating DB instance usage for Aurora PostgreSQL with CloudWatch metrics](AuroraPostgreSQL_AnayzeResourceUsage.md#AuroraPostgreSQL_AnayzeResourceUsage.EvaluateInstanceUsage). ## Hardware specifications for the memory-optimized instance classes The following tables show the compute, memory, storage, and bandwidth specifications for the memory-optimized instance classes. **db.x2g – memory-optimized instance classes with AWS Graviton2 processors** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.x2g.16xlarge | 64 | — | 1024 | EBS-optimized only | 19,000 | 25 | | db.x2g.12xlarge | 48 | — | 768 | EBS-optimized only | 14,250 | 20 | | db.x2g.8xlarge | 32 | — | 512 | EBS-optimized only | 9,500 | 12 | | db.x2g.4xlarge | 16 | — | 256 | EBS-optimized only | 4,750 | Up to 10 | | db.x2g.2xlarge | 8 | — | 128 | EBS-optimized only | Up to 4,750 | Up to 10 | | db.x2g.xlarge | 4 | — | 64 | EBS-optimized only | Up to 4,750 | Up to 10 | | db.x2g.large | 2 | — | 32 | EBS-optimized only | Up to 4,750 | Up to 10 | **db.r8gd – memory-optimized instance classes powered by AWS Graviton4 processors and SSD storage** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r8gd.48xlarge | 192 | — | 1536 | 6 x 1900 NVMe SSD | 40,000 | 50 | | db.r8gd.24xlarge | 96 | — | 768 | 3 x 1900 NVMe SSD | 30,000 | 40 | | db.r8gd.16xlarge | 64 | — | 512 | 2 x 1900 NVMe SSD | 20,000 | 30 | | db.r8gd.12xlarge | 48 | — | 384 | 3 x 950 NVMe SSD | 15,000 | 22.5 | | db.r8gd.8xlarge | 32 | — | 256 | 1 x 1900 NVMe SSD | 10,000 | 15 | | db.r8gd.4xlarge | 16 | — | 128 | 1 x 950 NVMe SSD | Up to 10,000 | Up to 15 | | db.r8gd.2xlarge | 8 | — | 64 | 1 x 474 NVMe SSD | Up to 10,000 | Up to 15 | | db.r8gd.xlarge | 4 | — | 32 | 1 x 237 NVMe SSD | Up to 10,000 | Up to 12.5 | | db.r8gd.large | 2 | — | 16 | 1 x 118 NVMe SSD | Up to 10,000 | Up to 12.5 | **db.r8g – memory-optimized instance classes powered by AWS Graviton4 processors** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r8g.48xlarge | 192 | — | 1536 | EBS-optimized only | 40,000 | 50 | | db.r8g.24xlarge | 96 | — | 768 | EBS-optimized only | 30,000 | 40 | | db.r8g.16xlarge | 64 | — | 512 | EBS-optimized only | 20,000 | 30 | | db.r8g.12xlarge | 48 | — | 384 | EBS-optimized only | 15,000 | 22.5 | | db.r8g.8xlarge | 32 | — | 256 | EBS-optimized only | 10,000 | 15 | | db.r8g.4xlarge | 16 | — | 128 | EBS-optimized only | Up to 10,000 | Up to 15 | | db.r8g.2xlarge | 8 | — | 64 | EBS-optimized only | Up to 10,000 | Up to 15 | | db.r8g.xlarge | 4 | — | 32 | EBS-optimized only | Up to 10,000 | Up to 12.5 | | db.r8g.large | 2 | — | 16 | EBS-optimized only | Up to 10,000 | Up to 12.5 | **db.r7i – memory-optimized instance classes powered by 4th generation Intel Xeon Scalable processors** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r7i.48xlarge | 192 | — | 1536 | EBS-optimized only | 40,000 | 50 | | db.r7i.24xlarge | 96 | — | 768 | EBS-optimized only | 30,000 | 37.5 | | db.r7i.16xlarge | 64 | — | 512 | EBS-optimized only | 20,000 | 25 | | db.r7i.12xlarge | 48 | — | 384 | EBS-optimized only | 15,000 | 18.75 | | db.r7i.8xlarge | 32 | — | 256 | EBS-optimized only | 10,000 | 12.5 | | db.r7i.4xlarge | 16 | — | 128 | EBS-optimized only | Up to 10,000 | Up to 12.5 | | db.r7i.2xlarge | 8 | — | 64 | EBS-optimized only | Up to 10,000 | Up to 12.5 | | db.r7i.xlarge | 4 | — | 32 | EBS-optimized only | Up to 10,000 | Up to 12.5 | | db.r7i.large | 2 | — | 16 | EBS-optimized only | Up to 10,000 | Up to 12.5 | **db.r7g – memory-optimized instance classes with AWS Graviton3 processors** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r7g.16xlarge | 64 | — | 512 | EBS-optimized only | 20,000 | 30 | | db.r7g.12xlarge | 48 | — | 384 | EBS-optimized only | 15,000 | 22.5 | | db.r7g.8xlarge | 32 | — | 256 | EBS-optimized only | 10,000 | 15 | | db.r7g.4xlarge | 16 | — | 128 | EBS-optimized only | Up to 10,000 | Up to 15 | | db.r7g.2xlarge | 8 | — | 64 | EBS-optimized only | Up to 10,000 | Up to 15 | | db.r7g.xlarge | 4 | — | 32 | EBS-optimized only | Up to 10,000 | Up to 12.5 | | db.r7g.large | 2 | — | 16 | EBS-optimized only | Up to 10,000 | Up to 12.5 | **db.r6id – memory-optimized instance classes with 3rd generation Intel Xeon Scalable processors and SSD storage** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r6id.32xlarge | 128 | — | 1,024 | 4x1900 NVMe SSD | 40,000 | 50 | | db.r6id.24xlarge | 96 | — | 768 | 4x1425 NVMe SSD | 30,000 | 37.5 | **db.r6gd – memory-optimized instance classes with AWS Graviton2 processors and SSD storage** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r6gd.16xlarge | 64 | — | 512 | 2 x 1900 NVMe SSD | 19,000 | 25 | | db.r6gd.12xlarge | 48 | — | 384 | 2 x 1425 NVMe SSD | 13,500 | 20 | | db.r6gd.8xlarge | 32 | — | 256 | 1 x 1900 NVMe SSD | 9,000 | 12 | | db.r6gd.4xlarge | 16 | — | 128 | 1 x 950 NVMe SSD | 4,750 | Up to 10 | | db.r6gd.2xlarge | 8 | — | 64 | 1 x 474 NVMe SSD | Up to 4,750 | Up to 10 | | db.r6gd.xlarge | 4 | — | 32 | 1 x 237 NVMe SSD | Up to 4,750 | Up to 10 | **db.r6g – memory-optimized instance classes with AWS Graviton2 processors** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r6g.16xlarge | 64 | — | 512 | EBS-optimized only | 19,000 | 25 | | db.r6g.12xlarge | 48 | — | 384 | EBS-optimized only | 13,500 | 20 | | db.r6g.8xlarge | 32 | — | 256 | EBS-optimized only | 9,000 | 12 | | db.r6g.4xlarge | 16 | — | 128 | EBS-optimized only | 4,750 | Up to 10 | | db.r6g.2xlarge | 8 | — | 64 | EBS-optimized only | Up to 4,750 | Up to 10 | | db.r6g.xlarge | 4 | — | 32 | EBS-optimized only | Up to 4,750 | Up to 10 | | db.r6g.large | 2 | — | 16 | EBS-optimized only | Up to 4,750 | Up to 10 | **db.r6i – memory-optimized instance classes with 3rd Generation Intel Xeon Scalable processors** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r6i.32xlarge | 128 | — | 1,024 | EBS-optimized only | 40,000 | 50 | | db.r6i.24xlarge | 96 | — | 768 | EBS-optimized only | 30,000 | 37.5 | | db.r6i.16xlarge | 64 | — | 512 | EBS-optimized only | 20,000 | 25 | | db.r6i.12xlarge | 48 | — | 384 | EBS-optimized only | 15,000 | 18.75 | | db.r6i.8xlarge | 32 | — | 256 | EBS-optimized only | 10,000 | 12.5 | | db.r6i.4xlarge | 16 | — | 128 | EBS-optimized only | Up to 10,000 | Up to 12.5 | | db.r6i.2xlarge | 8 | — | 64 | EBS-optimized only | Up to 10,000 | Up to 12.5 | | db.r6i.xlarge | 4 | — | 32 | EBS-optimized only | Up to 10,000 | Up to 12.5 | | db.r6i.large | 2 | — | 16 | EBS-optimized only | Up to 10,000 | Up to 12.5 | **db.r5 – memory-optimized instance classes** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r5.24xlarge | 96 | 347 | 768 | EBS-optimized only | 19,000 | 25 | | db.r5.16xlarge | 64 | 264 | 512 | EBS-optimized only | 13,600 | 20 | | db.r5.12xlarge | 48 | 173 | 384 | EBS-optimized only | 9,500 | 12 | | db.r5.8xlarge | 32 | 132 | 256 | EBS-optimized only | 6,800 | 10 | | db.r5.4xlarge | 16 | 71 | 128 | EBS-optimized only | 4,750 | Up to 10 | | db.r5.2xlarge | 8 | 38 | 64 | EBS-optimized only | Up to 4,750 | Up to 10 | | db.r5.xlarge | 4 | 19 | 32 | EBS-optimized only | Up to 4,750 | Up to 10 | | db.r5.large | 2 | 10 | 16 | EBS-optimized only | Up to 4,750 | Up to 10 | **db.r4 – memory-optimized instance classes with Intel Xeon Scalable processors** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.r4.16xlarge | 64 | 195 | 488 | EBS-optimized only | 14,000 | 25 | | db.r4.8xlarge | 32 | 99 | 244 | EBS-optimized only | 7,000 | 10 | | db.r4.4xlarge | 16 | 53 | 122 | EBS-optimized only | 3,500 | Up to 10 | | db.r4.2xlarge | 8 | 27 | 61 | EBS-optimized only | 1,700 | Up to 10 | | db.r4.xlarge | 4 | 13.5 | 30.5 | EBS-optimized only | 850 | Up to 10 | | db.r4.large | 2 | 7 | 15.25 | EBS-optimized only | 425 | Up to 10 | ## Hardware specifications for the burstable-performance instance classes The following tables show the compute, memory, storage, and bandwidth specifications for the burstable-performance instance classes. **db.t4g – burstable-performance instance classes powered by AWS Graviton2 processors** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.t4g.large | 2 | — | 8 | EBS-optimized only | Up to 2,780 | Up to 5 | | db.t4g.medium | 2 | — | 4 | EBS-optimized only | Up to 2,085 | Up to 5 | **db.t3 – burstable-performance instance classes** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.t3.large | 2 | Variable | 8 | EBS-optimized only | Up to 2,048 | Up to 5 | | db.t3.medium | 2 | Variable | 4 | EBS-optimized only | Up to 1,536 | Up to 5 | | db.t3.small | 2 | Variable | 2 | EBS-optimized only | Up to 1,536 | Up to 5 | **db.t2 – burstable-performance instance classes** | Instance class | vCPU | ECU | Memory (GiB) | Instance storage (GiB) | Max. EBS bandwidth (Mbps) | Network bandwidth (Gbps) | | --- | --- | --- | --- | --- | --- | --- | | db.t2.medium | 2 | Variable | 4 | EBS only | — | Moderate | | db.t2.small | 1 | Variable | 2 | EBS only | — | Low | # Amazon Aurora storage Following, you can learn about the Aurora storage subsystem. Aurora uses a distributed and shared storage architecture that is an important factor in performance, scalability, and reliability for Aurora clusters. **Topics** + [ ## Overview of Amazon Aurora storage ](#Aurora.Overview.Storage) + [ ## What the cluster volume contains ](#aurora-storage-contents) + [ ## Storage configurations for Amazon Aurora DB clusters ](#aurora-storage-type) + [ ## How Aurora storage automatically resizes ](#aurora-storage-growth) + [ ## How Aurora data storage is billed ](#aurora-storage-data-billing) ## Overview of Amazon Aurora storage Aurora data is stored in the *cluster volume*, which is a single, virtual volume that uses solid state drives (SSDs). A cluster volume consists of copies of the data across three Availability Zones in a single AWS Region. Because the data is automatically replicated across Availability Zones, your data is highly durable with less possibility of data loss. This replication also ensures that your database is more available during a failover. It does so because the data copies already exist in the other Availability Zones and continue to serve data requests to the DB instances in your DB cluster. The amount of replication is independent of the number of DB instances in your cluster. Aurora uses separate local storage for nonpersistent, temporary files. This includes files that are used for such purposes as sorting large data sets during query processing, and building indexes. For more information, see [Temporary storage limits for Aurora MySQLTemporary storage limits](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage) and [Temporary storage limits for Aurora PostgreSQLTemporary storage limits](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.TempStorage). ## What the cluster volume contains The Aurora cluster volume contains all your user data, schema objects, and internal metadata such as the system tables and the binary log. For example, Aurora stores all the tables, indexes, binary large objects (BLOBs), stored procedures, and so on for an Aurora cluster in the cluster volume. The Aurora shared storage architecture makes your data independent from the DB instances in the cluster. For example, you can add a DB instance quickly because Aurora doesn't make a new copy of the table data. Instead, the DB instance connects to the shared volume that already contains all your data. You can remove a DB instance from a cluster without removing any of the underlying data from the cluster. Only when you delete the entire cluster does Aurora remove the data. ## Storage configurations for Amazon Aurora DB clusters Amazon Aurora has two DB cluster storage configurations: + **Aurora I/O-Optimized** – Improved price performance and predictability for I/O-intensive applications. You pay only for the usage and storage of your DB clusters, with no additional charges for read and write I/O operations. Aurora I/O-Optimized is the best choice when your I/O spending is 25% or more of your total Aurora database spending. You can choose Aurora I/O-Optimized when you create or modify a DB cluster with a DB engine version that supports the Aurora I/O-Optimized cluster configuration. You can switch from Aurora I/O-Optimized to Aurora Standard at any time. + **Aurora Standard** – Cost-effective pricing for many applications with moderate I/O usage. In addition to the usage and storage of your DB clusters, you also pay a standard rate per 1 million requests for I/O operations. Aurora Standard is the best choice when your I/O spending is less than 25% of your total Aurora database spending. You can switch from Aurora Standard to Aurora I/O-Optimized once every 30 days. When you switch between Aurora Standard and Aurora I/O-Optimized storage options for non-NVMe-based DB instances, there is no downtime. However, for NVMe-based DB instances, switching between Aurora I/O-Optimized and Aurora Standard storage options requires a database engine restart, which may cause a brief period of downtime. For information on AWS Region and version support, see [Supported Regions and Aurora DB engines for cluster storage configurations](Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.md). For more information on pricing for Amazon Aurora storage configurations, see [Amazon Aurora pricing](https://aws.amazon.com/rds/aurora/pricing/). For information on choosing the storage configuration when creating a DB cluster, see [Creating a DB cluster](Aurora.CreateInstance.md#Aurora.CreateInstance.Creating). For information on modifying the storage configuration for a DB cluster, see [Settings for Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings). ## How Aurora storage automatically resizes Aurora cluster volumes automatically grow as the amount of data in your database increases. For information about maximum Aurora cluster volume sizes for each engine version, see [Amazon Aurora size limits](CHAP_Limits.md#RDS_Limits.FileSize.Aurora). This automatic storage scaling is combined with a high-performance and highly distributed storage subsystem. These make Aurora a good choice for your important enterprise data when your main objectives are reliability and high availability. To display the volume status, see [Displaying volume status for an Aurora MySQL DB cluster](AuroraMySQL.Managing.VolumeStatus.md) or [Displaying volume status for an Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Managing.VolumeStatus.md). For ways to balance storage costs against other priorities, [Storage scaling](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling) describes how to monitor the Amazon Aurora metrics `AuroraVolumeBytesLeftTotal` and `VolumeBytesUsed` in CloudWatch. When Aurora data is removed, the space allocated for that data is freed. Examples of removing data include dropping or truncating a table. This automatic reduction in storage usage helps you to minimize storage charges. **Note** The storage limits and dynamic resizing behavior discussed here apply to persistent tables and other data stored in the cluster volume. For Aurora PostgreSQL, temporary table data is stored in the local DB instance. For Aurora MySQL version 2, temporary table data is stored by default in the cluster volume for writer instances and in local storage for reader instances. For more information, see [Storage engine for on-disk temporary tables](AuroraMySQL.CompareMySQL57.md#AuroraMySQL.StorageEngine57). For Aurora MySQL version 3, temporary table data is stored in the local DB instance or in the cluster volume. For more information, see [New temporary table behavior in Aurora MySQL version 3](ams3-temptable-behavior.md). The maximum size of temporary tables that reside in local storage is limited by the maximum local storage size of the DB instance. The local storage size depends on the instance class that you use. For more information, see [Temporary storage limits for Aurora MySQLTemporary storage limits](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage) and [Temporary storage limits for Aurora PostgreSQLTemporary storage limits](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.TempStorage). Some storage features, such as the maximum size of a cluster volume and automatic resizing when data is removed, depend on the Aurora version of your cluster. For more information, see [Storage scaling](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling). You can also learn how to avoid storage issues and how to monitor the allocated storage and free space in your cluster. ## How Aurora data storage is billed Even though an Aurora cluster volume can grow up to 256 tebibytes (TiB) for specific engine versions, you are only charged for the space that you use in an Aurora cluster volume. In earlier Aurora versions, the cluster volume could reuse space that was freed up when you removed data, but the allocated storage space would never decrease. Now when Aurora data is removed, such as by dropping a table or database, the overall allocated space decreases by a comparable amount. Thus, you can reduce storage charges by dropping tables, indexes, databases, and so on that you no longer need. **Tip** For earlier versions without the dynamic resizing feature, resetting the storage usage for a cluster involved doing a logical dump and restoring to a new cluster. That operation can take a long time for a substantial volume of data. If you encounter this situation, consider upgrading your cluster to a version that supports dynamic volume resizing. For information about which Aurora versions support dynamic resizing, and how to minimize storage charges by monitoring storage usage for your cluster, see [Storage scaling](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling). For information about Aurora backup storage billing, see [Understanding Amazon Aurora backup storage usage](aurora-storage-backup.md). For pricing information about Aurora data storage, see [Amazon RDS for Aurora pricing](https://aws.amazon.com/rds/aurora/pricing). # Amazon Aurora reliability Aurora is designed to be reliable, durable, and fault tolerant. You can architect your Aurora DB cluster to improve availability by doing things such as adding Aurora Replicas and placing them in different Availability Zones, and also Aurora includes several automatic features that make it a reliable database solution. **Topics** + [ ## Storage auto-repair ](#Aurora.Overview.AutoRepair) + [ ## Survivable page cache ](#Aurora.Overview.CacheWarming) + [ ## Recovery from unplanned restarts ](#Aurora.Overview.RestartRecovery) ## Storage auto-repair Because Aurora maintains multiple copies of your data in three Availability Zones, the chance of losing data as a result of a disk failure is greatly minimized. Aurora automatically detects failures in the disk volumes that make up the cluster volume. When a segment of a disk volume fails, Aurora immediately repairs the segment. When Aurora repairs the disk segment, it uses the data in the other volumes that make up the cluster volume to ensure that the data in the repaired segment is current. As a result, Aurora avoids data loss and reduces the need to perform a point-in-time restore to recover from a disk failure. ## Survivable page cache In Aurora, each DB instance's page cache is managed in a separate process from the database, which allows the page cache to survive independently of the database. (The page cache is also called the InnoDB *buffer pool* on Aurora MySQL and the *buffer cache* on Aurora PostgreSQL.) In the unlikely event of a database failure, the page cache remains in memory, which keeps current data pages "warm" in the page cache when the database restarts. This provides a performance gain by bypassing the need for the initial queries to execute read I/O operations to "warm up" the page cache. For Aurora MySQL, page cache behavior when rebooting and failing over is the following: + You can reboot the writer instance without rebooting the reader instances. + If the reader instances don't reboot when the writer instance reboots, they don't lose their page caches. + If the reader instances reboot when the writer instance reboots, they do lose their page caches. + When a reader instance reboots, the page caches on the writer and reader instances both survive. + When the DB cluster fails over, the effect is similar to when a writer instance reboots. On the new writer instance (previously the reader instance) the page cache survives, but on the reader instance (previously the writer instance), the page cache doesn't survive. For Aurora PostgreSQL, you can use cluster cache management to preserve the page cache of a designated reader instance that becomes the writer instance after failover. For more information, see [Fast recovery after failover with cluster cache management for Aurora PostgreSQL](AuroraPostgreSQL.cluster-cache-mgmt.md). ## Recovery from unplanned restarts Aurora is designed to recover from an unplanned restart almost instantaneously and continue to serve your application data without the binary log. Aurora recovers asynchronously on parallel threads, so that your database is open and available immediately after an unplanned restart. For more information, see [Fault tolerance for an Aurora DB cluster](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance) and [Optimizations to reduce database restart time](AuroraMySQL.MySQL80.md#ReducedRestartTime). The following are considerations for binary logging and unplanned restart recovery on Aurora MySQL: + Enabling binary logging on Aurora directly affects the recovery time after an unplanned restart, because it forces the DB instance to perform binary log recovery. + The type of binary logging used affects the size and efficiency of logging. For the same amount of database activity, some formats log more information than others in the binary logs. The following settings for the `binlog_format` parameter result in different amounts of log data: + `ROW` – The most log data + `STATEMENT` – The least log data + `MIXED` – A moderate amount of log data that usually provides the best combination of data integrity and performance The amount of binary log data affects recovery time. If there is more data logged in the binary logs, the DB instance must process more data during recovery, which increases recovery time. + To reduce computational overhead and improve recovery times with binary logging, you can use enhanced binlog. Enhanced binlog improves the database recovery time by up to 99%. For more information, see [Setting up enhanced binlog for Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). + Aurora does not need the binary logs to replicate data within a DB cluster or to perform point-in-time restore (PITR). + If you don't need the binary log for external replication (or an external binary log stream), we recommend that you set the `binlog_format` parameter to `OFF` to disable binary logging. Doing so reduces recovery time. For more information about Aurora binary logging and replication, see [Replication with Amazon Aurora](Aurora.Replication.md). For more information about the implications of different MySQL replication types, see [Advantages and disadvantages of statement-based and row-based replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) in the MySQL documentation. # Amazon Aurora security Security for Amazon Aurora is managed at three levels: + To control who can perform Amazon RDS management actions on Aurora DB clusters and DB instances, you use AWS Identity and Access Management (IAM). When you connect to AWS using IAM credentials, your AWS account must have IAM policies that grant the permissions required to perform Amazon RDS management operations. For more information, see [Identity and access management for Amazon Aurora](UsingWithRDS.IAM.md). If you are using IAM to access the Amazon RDS console, you must first log on to the AWS Management Console with your user credentials, and then go to the Amazon RDS console at [https://console.aws.amazon.com/rds](https://console.aws.amazon.com/rds). + Aurora DB clusters must be created in a virtual private cloud (VPC) based on the Amazon VPC service. To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance for Aurora DB clusters in a VPC, you use a VPC security group. You can make these endpoint and port connections using Transport Layer Security (TLS)/Secure Sockets Layer (SSL). In addition, firewall rules at your company can control whether devices running at your company can open connections to a DB instance. For more information on VPCs, see [Amazon VPC and Amazon Aurora](USER_VPC.md). + To authenticate logins and permissions for an Amazon Aurora DB cluster, you can take either of the following approaches, or a combination of them. + You can take the same approach as with a stand-alone DB instance of MySQL or PostgreSQL. Techniques for authenticating logins and permissions for stand-alone DB instances of MySQL or PostgreSQL, such as using SQL commands or modifying database schema tables, also work with Aurora. For more information, see [Security with Amazon Aurora MySQL](AuroraMySQL.Security.md) or [Security with Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md). + You can use IAM database authentication. With IAM database authentication, you authenticate to your Aurora DB cluster by using a user or IAM role and an authentication token. An *authentication token* is a unique value that is generated using the Signature Version 4 signing process. By using IAM database authentication, you can use the same credentials to control access to your AWS resources and your databases. For more information, see [IAM database authentication ](UsingWithRDS.IAMDBAuth.md). + You can use Kerberos authentication for Aurora PostgreSQL and Aurora MySQL. You can use Kerberos to authenticate users when they connect to your Aurora PostgreSQL and Aurora MySQLDB cluster. In this case, your DB cluster works with AWS Directory Service for Microsoft Active Directory to enable Kerberos authentication. AWS Directory Service for Microsoft Active Directory is also called AWS Managed Microsoft AD. Keeping all of your credentials in the same directory can save you time and effort. You have a centralized place for storing and managing credentials for multiple DB clusters. Using a directory can also improve your overall security profile. For more information, see [Using Kerberos authentication with Aurora PostgreSQL](postgresql-kerberos.md) and [Using Kerberos authentication for Aurora MySQL](aurora-mysql-kerberos.md). For information about configuring security, see [Security in Amazon Aurora](UsingWithRDS.md). ## Using SSL with Aurora DB clusters Amazon Aurora DB clusters support Secure Sockets Layer (SSL) connections from applications using the same process and public key as Amazon RDS DB instances. For more information, see [Security with Amazon Aurora MySQL](AuroraMySQL.Security.md) or [Security with Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md). # High availability for Amazon Aurora The Amazon Aurora architecture involves separation of storage and compute. Aurora includes some high availability features that apply to the data in your DB cluster. The data remains safe even if some or all of the DB instances in the cluster become unavailable. Other high availability features apply to the DB instances. These features help to make sure that one or more DB instances are ready to handle database requests from your application. **Topics** + [ ## High availability for Aurora data ](#Concepts.AuroraHighAvailability.Data) + [ ## High availability for Aurora DB instances ](#Concepts.AuroraHighAvailability.Instances) + [ ## High availability across AWS Regions with Aurora global databases ](#Concepts.AuroraHighAvailability.GlobalDB) + [ ## Fault tolerance for an Aurora DB cluster ](#Aurora.Managing.FaultTolerance) + [ ## High availability with Amazon RDS Proxy ](#Concepts.AuroraHighAvailability.Proxy) ## High availability for Aurora data Aurora stores copies of the data in a DB cluster across multiple Availability Zones in a single AWS Region. Aurora stores these copies regardless of whether the instances in the DB cluster span multiple Availability Zones. For more information on Aurora, see [Managing an Amazon Aurora DB cluster](CHAP_Aurora.md). When data is written to the primary DB instance, Aurora synchronously replicates the data across Availability Zones to six storage nodes associated with your cluster volume. Doing so provides data redundancy, eliminates I/O freezes, and minimizes latency spikes during system backups. Running a DB instance with high availability can enhance availability during planned system maintenance, and help protect your databases against failure and Availability Zone disruption. For more information on Availability Zones, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md). ## High availability for Aurora DB instances After you create the primary (writer) instance, you can create up to 15 read-only Aurora Replicas. The Aurora Replicas are also known as reader instances. Aurora Replicas use asynchronous replication to support high availability without affecting primary instance performance. During day-to-day operations, you can offload some of the work for read-intensive applications by using the reader instances to process `SELECT` queries. When a problem affects the primary instance, one of these reader instances takes over as the primary instance. This mechanism is known as *failover*. Many Aurora features apply to the failover mechanism. For example, Aurora detects database problems and activates the failover mechanism automatically when necessary. Aurora also has features that reduce the time for failover to complete. Doing so minimizes the time that the database is unavailable for writing during a failover. Aurora is designed to recover as quickly as possible, and the fastest path to recovery is often to restart or to fail over to the same DB instance. Restarting is faster and involves less overhead than failover. To use a connection string that stays the same even when a failover promotes a new primary instance, you connect to the cluster endpoint. The *cluster endpoint* always represents the current primary instance in the cluster. For more information about the cluster endpoint, see [Amazon Aurora endpoint connections](Aurora.Overview.Endpoints.md). **Tip** Within each AWS Region, Availability Zones (AZs) represent locations that are distinct from each other to provide isolation in case of outages. We recommend that you distribute the primary instance and reader instances in your DB cluster over multiple AZs to improve the availability of your DB cluster. That way, an issue that affects an entire AZ doesn't cause an outage for your cluster. You can set up a Multi-AZ DB cluster by making a simple choice when you create the cluster. You can use the AWS Management Console, the AWS CLI, or the Amazon RDS API. You can also convert an existing Aurora DB cluster into a Multi-AZ DB cluster by adding a new reader DB instance and specifying a different AZ. ## High availability across AWS Regions with Aurora global databases For high availability across multiple AWS Regions, you can set up Aurora global databases. Each Aurora global database spans multiple AWS Regions, enabling low latency global reads and disaster recovery from outages across an AWS Region. Aurora asynchronously replicates all data and updates from the primary AWS Region to each of the secondary Regions. For more information, see [Using Amazon Aurora Global Database](aurora-global-database.md). ## Fault tolerance for an Aurora DB cluster An Aurora DB cluster is fault tolerant by design. The cluster volume spans multiple Availability Zones (AZs) in a single AWS Region, and each Availability Zone contains a copy of the cluster volume data. This functionality means that your DB cluster can tolerate a failure of an Availability Zone without any loss of data and only a brief interruption of service. If the primary instance in a DB cluster fails, Aurora automatically fails over to a new primary instance in one of two ways: + By promoting an existing Aurora Replica to the new primary instance + By creating a new primary instance If the DB cluster has one or more Aurora Replicas, then an Aurora Replica is promoted to the primary instance during a failure event. A failure event results in a brief interruption, during which read and write operations fail with an exception. However, service is typically restored in less than 60 seconds, and often less than 30 seconds. To increase the availability of your DB cluster, we recommend that you create at least one or more Aurora Replicas in two or more different Availability Zones. **Tip** In Aurora MySQL, you can improve availability during a failover by having more than one reader DB instance in a cluster. In Aurora MySQL, Aurora restarts only the writer DB instance and the reader instance to which it fails over. Other reader instances in the cluster remain available during a failover to continue processing queries through connections to the reader endpoint. You can also improve availability during a failover by using RDS Proxy with your Aurora DB cluster. For more information, see [High availability with Amazon RDS Proxy](#Concepts.AuroraHighAvailability.Proxy). You can customize the order in which your Aurora Replicas are promoted to the primary instance after a failure by assigning each replica a priority. Priorities range from 0 for the highest priority to 15 for the lowest priority. If the primary instance fails, Amazon RDS promotes the Aurora Replica with the highest priority to the new primary instance. You can modify the priority of an Aurora Replica at any time. Modifying the priority doesn't trigger a failover. More than one Aurora Replica can share the same priority, resulting in promotion tiers. If two or more Aurora Replicas share the same priority, then Amazon RDS promotes the replica that is largest in size. If two or more Aurora Replicas share the same priority and size, then Amazon RDS promotes an arbitrary replica in the same promotion tier. **Note** Several factors are involved in identifying a failover target. After five unsuccessful failover attempts, promotion tiers are no longer considered. If the DB cluster doesn't contain any Aurora Replicas, then the primary instance is recreated in the same AZ during a failure event. A failure event results in an interruption during which read and write operations fail with an exception. Service is restored when the new primary instance is created, which typically takes less than 10 minutes. Promoting an Aurora Replica to the primary instance is much faster than creating a new primary instance. Suppose that the primary instance in your cluster is unavailable because of an outage that affects an entire AZ. In this case, the way to bring a new primary instance online depends on whether your cluster uses a Multi-AZ configuration: + If your provisioned or Aurora Serverless v2 cluster contains any reader instances in other AZs, Aurora uses the failover mechanism to promote one of those reader instances to be the new primary instance. + If your provisioned or Aurora Serverless v2 cluster only contains a single DB instance, or if the primary instance and all reader instances are in the same AZ, make sure to manually create one or more new DB instances in another AZ. **Note** Amazon Aurora also supports replication with an external MySQL database, or an RDS MySQL DB instance. For more information, see [Replication between Aurora and MySQL or between Aurora and another Aurora DB cluster (binary log replication)](AuroraMySQL.Replication.MySQL.md). ## High availability with Amazon RDS Proxy With RDS Proxy, you can build applications that can transparently tolerate database failures without needing to write complex failure handling code. The proxy automatically routes traffic to a new database instance while preserving application connections. It also bypasses Domain Name System (DNS) caches to reduce failover times by up to 66% for Aurora Multi-AZ databases. For more information, see [Amazon RDS Proxyfor Aurora](rds-proxy.md). # Replication with Amazon Aurora There are several replication options with Aurora. Each Aurora DB cluster has built-in replication between multiple DB instances in the same cluster. You can also set up replication with your Aurora cluster as the source or the target. When you replicate data into or out of an Aurora cluster, you can choose between built-in features such as Aurora global databases or the traditional replication mechanisms for the MySQL or PostgreSQL DB engines. You can choose the appropriate options based on which one provides the right combination of high availability, convenience, and performance for your needs. The following sections explain how and when to choose each technique. **Topics** + [ ## Aurora Replicas ](#Aurora.Replication.Replicas) + [ ## Replication with Aurora MySQL ](#Aurora.Replication.AuroraMySQL) + [ ## Replication with Aurora PostgreSQL ](#Aurora.Replication.AuroraPostgreSQL) ## Aurora Replicas When you create a second, third, and so on DB instance in an Aurora provisioned DB cluster, Aurora automatically sets up replication from the writer DB instance to all the other DB instances. These other DB instances are read-only and are known as Aurora Replicas. We also refer to them as reader instances when discussing the ways that you can combine writer and reader DB instances within a cluster. Aurora Replicas have two main purposes. You can issue queries to them to scale the read operations for your application. You typically do so by connecting to the reader endpoint of the cluster. That way, Aurora can spread the load for read-only connections across as many Aurora Replicas as you have in the cluster. Aurora Replicas also help to increase availability. If the writer instance in a cluster becomes unavailable, Aurora automatically promotes one of the reader instances to take its place as the new writer. An Aurora DB cluster can contain up to 15 Aurora Replicas. The Aurora Replicas can be distributed across the Availability Zones that a DB cluster spans within an AWS Region. The data in your DB cluster has its own high availability and reliability features, independent of the DB instances in the cluster. If you aren't familiar with Aurora storage features, see [Overview of Amazon Aurora storage](Aurora.Overview.StorageReliability.md#Aurora.Overview.Storage). The DB cluster volume is physically made up of multiple copies of the data for the DB cluster. The primary instance and the Aurora Replicas in the DB cluster all see the data in the cluster volume as a single logical volume. As a result, all Aurora Replicas return the same data for query results with minimal replica lag. This lag is usually much less than 100 milliseconds after the primary instance has written an update. Replica lag varies depending on the rate of database change. That is, during periods where a large amount of write operations occur for the database, you might see an increase in replica lag. **Note** Aurora Replica restarts automatically, when it loses communication with the writer DB instance for more than 60 seconds in the following Aurora PostgreSQL versions: 14.6 and older versions 13.9 and older versions 12.13 and older versions All Aurora PostgreSQL 11 versions With the read availability feature, the Aurora Replicas don't restart automatically. For more information on the read availability feature and the versions where it is applicable, see [Improving the read availability of Aurora Replicas](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Replicas.SRO). Aurora Replicas work well for read scaling because they are fully dedicated to read operations on your cluster volume. Write operations are managed by the primary instance. Because the cluster volume is shared among all DB instances in your DB cluster, minimal additional work is required to replicate a copy of the data for each Aurora Replica. To increase availability, you can use Aurora Replicas as failover targets. That is, if the primary instance fails, an Aurora Replica is promoted to the primary instance. There is a brief interruption during which read and write requests made to the primary instance fail with an exception. Promoting an Aurora Replica by failover is much faster than recreating the primary instance. If your Aurora DB cluster doesn't include any Aurora Replicas, then your DB cluster isn't available while your DB instance is recovering from the failure. When failover happens, some of the Aurora Replicas might be rebooted, depending on the DB engine version. For example, in Aurora MySQL, Aurora restarts only the writer DB instance and the failover target during a failover. For more information about the rebooting behavior of different Aurora DB engine versions, see [Rebooting an Amazon Aurora DB cluster or Amazon Aurora DB instance](USER_RebootCluster.md). For information about what happens to page caches when rebooting or failover, see [Survivable page cache](Aurora.Overview.Reliability.md#Aurora.Overview.CacheWarming). For high-availability scenarios, we recommend that you create one or more Aurora Replicas. These should be of the same DB instance class as the primary instance and in different Availability Zones for your Aurora DB cluster. For more information about Aurora Replicas as failover targets, see [Fault tolerance for an Aurora DB cluster](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance). You can't create an encrypted Aurora Replica for an unencrypted Aurora DB cluster. You can't create an unencrypted Aurora Replica for an encrypted Aurora DB cluster. **Tip** You can use Aurora Replicas within an Aurora cluster as your only form of replication to keep your data highly available. You can also combine the built-in Aurora replication with the other types of replication. Doing so can help to provide an extra level of high availability and geographic distribution of your data. For details on how to create an Aurora Replica, see [Adding Aurora Replicas to a DB cluster](aurora-replicas-adding.md). ## Replication with Aurora MySQL In addition to Aurora Replicas, you have the following options for replication with Aurora MySQL: + Aurora MySQL DB clusters in different AWS Regions. + You can replicate data across multiple Regions by using an Aurora global database. For details, see [High availability across AWS Regions with Aurora global databases](Concepts.AuroraHighAvailability.md#Concepts.AuroraHighAvailability.GlobalDB) + You can create an Aurora read replica of an Aurora MySQL DB cluster in a different AWS Region, by using MySQL binary log (binlog) replication. Each cluster can have up to five read replicas created this way, each in a different Region. + Two Aurora MySQL DB clusters in the same Region, by using MySQL binary log (binlog) replication. + An RDS for MySQL DB instance as the source of data and an Aurora MySQL DB cluster, by creating an Aurora read replica of an RDS for MySQL DB instance. Typically, you use this approach for migration to Aurora MySQL, rather than for ongoing replication. For more information about replication with Aurora MySQL, see [Replication with Amazon Aurora MySQL](AuroraMySQL.Replication.md). ## Replication with Aurora PostgreSQL In addition to Aurora Replicas, you have the following options for replication with Aurora PostgreSQL: + An Aurora primary DB cluster in one Region and up to 10 read-only secondary DB clusters in different Regions by using an Aurora global database. Aurora PostgreSQL doesn't support cross-Region Aurora Replicas. However, you can use Aurora global database to scale your Aurora PostgreSQL DB cluster's read capabilities to more than one AWS Region and to meet availability goals. For more information, see [Using Amazon Aurora Global Database](aurora-global-database.md). + Two Aurora PostgreSQL DB clusters in the same Region, by using PostgreSQL's logical replication feature. + An RDS for PostgreSQL DB instance as the source of data and an Aurora PostgreSQL DB cluster, by creating an Aurora read replica of an RDS for PostgreSQL DB instance. Typically, you use this approach for migration to Aurora PostgreSQL, rather than for ongoing replication. For more information about replication with Aurora PostgreSQL, see [Replication with Amazon Aurora PostgreSQL](AuroraPostgreSQL.Replication.md). # DB instance billing for Aurora Amazon RDS provisioned instances in an Amazon Aurora cluster are billed based on the following components: + DB instance hours (per hour) – Based on the DB instance class of the DB instance (for example, db.t2.small or db.m4.large). Pricing is listed on a per-hour basis, but bills are calculated down to the second and show times in decimal form. RDS usage is billed in 1-second increments, with a minimum of 10 minutes. For more information, see [Amazon AuroraDB instance classes](Concepts.DBInstanceClass.md). + Storage (per GiB per month) – Storage capacity that you have provisioned to your DB instance. If you scale your provisioned storage capacity within the month, your bill is prorated. For more information, see [Amazon Aurora storage](Aurora.Overview.StorageReliability.md). + Input/output (I/O) requests (per 1 million requests) – Total number of storage I/O requests that you have made in a billing cycle, for the Aurora Standard DB cluster configuration only. For more information on Amazon Aurora I/O billing, see [Storage configurations for Amazon Aurora DB clusters](Aurora.Overview.StorageReliability.md#aurora-storage-type). + Backup storage (per GiB per month) – *Backup storage *is the storage that is associated with automated database backups and any active database snapshots that you have taken. Increasing your backup retention period or taking additional database snapshots increases the backup storage consumed by your database. Per second billing doesn't apply to backup storage (metered in GB-month). For more information, see [Backing up and restoring an Amazon Aurora DB cluster](BackupRestoreAurora.md). + Data transfer (per GB) – Data transfer in and out of your DB instance from or to the internet and other AWS Regions. For useful examples, see the AWS blog post [Exploring Data Transfer Costs for AWS Managed Databases](https://aws.amazon.com/blogs/architecture/exploring-data-transfer-costs-for-aws-managed-databases). Amazon RDS provides the following purchasing options to enable you to optimize your costs based on your needs: + **On-Demand instances** – Pay by the hour for the DB instance hours that you use. Pricing is listed on a per-hour basis, but bills are calculated down to the second and show times in decimal form. RDS usage is now billed in 1-second increments, with a minimum of 10 minutes. + **Reserved instances** – Reserve a DB instance for a one-year or three-year term and get a significant discount compared to the on-demand DB instance pricing. With Reserved Instance usage, you can launch, delete, start, or stop multiple instances within an hour and get the Reserved Instance benefit for all of the instances. + **Aurora Serverless v2** – Aurora Serverless v2 provides on-demand capacity where the billing unit is Aurora capacity unit (ACU) hours instead of DB instance hours. Aurora Serverless v2 capacity increases and decreases, within a range that you specify, depending on the load on your database. You can configure a cluster where all the capacity is Aurora Serverless v2. Or you can configure a combination of Aurora Serverless v2 and on-demand or reserved provisioned instances. For information about how Aurora Serverless v2 ACUs work, see [How Aurora Serverless v2 works](aurora-serverless-v2.how-it-works.md). + **Aurora PostgreSQL Limitless Database** – Aurora PostgreSQL Limitless Database is an automated, horizontal scaling capability that scales beyond the write throughput and storage limits of a single DB instance. Limitless Database distributes the workload over multiple Aurora writer instances, while maintaining the ease of operating as a single database. Limitless Database provides on-demand capacity where the billing unit is Aurora capacity unit (ACU) hours in a DB shard group. For information about how Limitless Database ACUs work, see [Creating a DB cluster that uses Aurora PostgreSQL Limitless Database](limitless-cluster.md). For Aurora pricing information, see the [Aurora pricing page](https://aws.amazon.com/rds/aurora/pricing). **Topics** + [ # On-Demand DB instances for Aurora ](USER_OnDemandDBInstances.md) + [ # Reserved DB instances for Amazon Aurora ](USER_WorkingWithReservedDBInstances.md) # On-Demand DB instances for Aurora Amazon RDS on-demand DB instances are billed based on the class of the DB instance (for example, db.t3.small or db.m5.large). For Amazon RDS pricing information, see the [Amazon RDS product page](https://aws.amazon.com/rds/pricing). Billing starts for a DB instance as soon as the DB instance is available. Pricing is listed on a per-hour basis, but bills are calculated down to the second and show times in decimal form. Amazon RDS usage is billed in one-second increments, with a minimum of 10 minutes. In the case of billable configuration change, such as scaling compute or storage capacity, you're charged a 10-minute minimum. Billing continues until the DB instance terminates, which occurs when you delete the DB instance or if the DB instance fails. If you no longer want to be charged for your DB instance, you must stop or delete it to avoid being billed for additional DB instance hours. For more information about the DB instance states for which you are billed, see [Viewing DB instance statusin an Aurora cluster](accessing-monitoring.md#Overview.DBInstance.Status). ## Stopped DB instances While your DB instance is stopped, you're charged for provisioned storage, including Provisioned IOPS. You are also charged for backup storage, including storage for manual snapshots and automated backups within your specified retention window. You aren't charged for DB instance hours. ## Multi-AZ DB instances A Multi-AZ setup enhances data durability and availability by automatically provisioning and maintaining a synchronous standby replica in a different Availability Zone. Due to the additional resources and increased availability, Multi-AZ deployments are priced higher than Single-AZ deployments, and can cost approximately twice as much due to the additional standby instance and associated resources. Consider the following important details about Multi-AZ pricing: + **Compute costs**: Billed per DB instance-hour for both the primary and standby instances. + **Storage costs**: Charged per GB-month for the storage provisioned for both the primary and standby instances. + **Data transfer costs**: Replication between the primary and standby instances is included in the cost, but other data transfer charges might apply based on your usage. To accurately estimate your monthly costs based on your specific use case and AWS Region, you can use the AWS Pricing Calculator. This tool lets you to input your configuration details and provides a comprehensive cost breakdown. **Note** Pricing is subject to change. See the [Amazon RDS Pricing page](https://aws.amazon.com/rds/pricing/) for the most up-to-date information. # Reserved DB instances for Amazon Aurora Using reserved DB instances, you can reserve a DB instance for a one- or three-year term. Reserved DB instances provide you with a significant discount compared to on-demand DB instance pricing. Reserved DB instances are not physical instances, but rather a billing discount applied to the use of certain on-demand DB instances in your account. Discounts for reserved DB instances are tied to instance type and AWS Region. The general process for working with reserved DB instances is: First get information about available reserved DB instance offerings, then purchase a reserved DB instance offering, and finally get information about your existing reserved DB instances. For information about purchasing reserved DB instances and viewing the billing for reserved DB instances, see the following sections. + [Purchasing reserved DB instances for Amazon Aurora](USER_WorkingWithReservedDBInstances.WorkingWith.md) + [Viewing the billing for reserved DB instances for Amazon Aurora](reserved-instances-billing.md) ## Overview of reserved DB instances When you purchase a reserved DB instance in Amazon RDS, you purchase a commitment to getting a discounted rate, on a specific DB instance type, for the duration of the reserved DB instance. To use an Amazon RDS reserved DB instance, you create a new DB instance just like you do for an on-demand instance. The new DB instance that you create must have the same specifications as the reserved DB instance for the following: + AWS Region + DB engine (The DB engine's version number doesn't need to match.) + DB instance type If the specifications of the new DB instance match an existing reserved DB instance for your account, you are billed at the discounted rate offered for the reserved DB instance. Otherwise, the DB instance is billed at an on-demand rate. You can modify a DB instance that you're using as a reserved DB instance. If the modification is within the specifications of the reserved DB instance, part or all of the discount still applies to the modified DB instance. If the modification is outside the specifications, such as changing the instance class, the discount no longer applies. For more information, see [Size-flexible reserved DB instances](#USER_WorkingWithReservedDBInstances.SizeFlexible). **Topics** + [ ### Offering types ](#USER_WorkingWithReservedDBInstances.OfferingTypes) + [ ### Aurora DB cluster configuration flexibility ](#ReservedDBInstances.ClusterConfig) + [ ### Size-flexible reserved DB instances ](#USER_WorkingWithReservedDBInstances.SizeFlexible) + [ ### Aurora reserved DB instance billing examples ](#USER_WorkingWithReservedDBInstances.BillingExample) + [ ### Deleting a reserved DB instance ](#USER_WorkingWithReservedDBInstances.Cancelling) For more information about reserved DB instances, including pricing, see [Amazon RDS reserved instances](http://aws.amazon.com/rds/reserved-instances/#2). ### Offering types Reserved DB instances are available in three varieties—No Upfront, Partial Upfront, and All Upfront—that let you optimize your Amazon RDS costs based on your expected usage. **Note** Not all RDS instance classes support all Reserved Instance offering types. For example, some instance classes might not offer the No Upfront option. To confirm availability, review the Reserved Instance offerings in the AWS Management Console or use the `describe-reserved-db-instances-offerings` AWS CLI command. **No Upfront** This option provides access to a reserved DB instance without requiring an upfront payment. Your No Upfront reserved DB instance bills a discounted hourly rate for every hour within the term, regardless of usage, and no upfront payment is required. This option is only available as a one-year reservation. **Partial Upfront** This option requires a part of the reserved DB instance to be paid upfront. The remaining hours in the term are billed at a discounted hourly rate, regardless of usage. This option is the replacement for the previous Heavy Utilization option. **All Upfront** Full payment is made at the start of the term, with no other costs incurred for the remainder of the term regardless of the number of hours used. If you are using consolidated billing, all the accounts in the organization are treated as one account. This means that all accounts in the organization can receive the hourly cost benefit of reserved DB instances that are purchased by any other account. For more information about consolidated billing, see [Amazon RDS reserved DB instances](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidatedbilling-other.html#consolidatedbilling-rds) in the *AWS Billing and Cost Management User Guide*. ### Aurora DB cluster configuration flexibility You can use Aurora reserved DB instances with both DB cluster configurations: + Aurora I/O-Optimized – You pay only for the usage and storage of your DB clusters, with no additional charges for read and write I/O operations. + Aurora Standard – In addition to the usage and storage of your DB clusters, you also pay a standard rate per 1 million requests for I/O operations. Aurora automatically accounts for the price difference between these configurations. Aurora I/O-Optimized consumes 30% more normalized units per hour than Aurora Standard. For more information about Aurora cluster storage configurations, see [Storage configurations for Amazon Aurora DB clusters](Aurora.Overview.StorageReliability.md#aurora-storage-type). For more information about pricing for Aurora cluster storage configurations, see [Amazon Aurora pricing](https://aws.amazon.com/rds/aurora/pricing/). ### Size-flexible reserved DB instances When you purchase a reserved DB instance, one thing that you specify is the instance class, for example db.r5.large. For more information about DB instance classes, see [Amazon AuroraDB instance classes](Concepts.DBInstanceClass.md). If you have a DB instance, and you need to scale it to larger capacity, your reserved DB instance is automatically applied to your scaled DB instance. That is, your reserved DB instances are automatically applied across all DB instance class sizes. Size-flexible reserved DB instances are available for DB instances with the same AWS Region and database engine. Size-flexible reserved DB instances can only scale in their instance class type. For example, a reserved DB instance for a db.r6i.large can apply to a db.r6i.xlarge, but not to a db.r6id.large or db.r7g.large, because db.r6id.large and db.r7g.large are different instance class types. Size-flexible reserved DB instances are available for the following Aurora database engines: + Aurora MySQL + Aurora PostgreSQL You can compare usage for different reserved DB instance sizes by using normalized units per hour. For example, one unit of usage on two db.r3.large DB instances is equivalent to eight normalized units per hour of usage on one db.r3.small. The following table shows the number of normalized units per hour for each DB instance size. | Instance size | Normalized units per hour for one DB instance, Aurora Standard | Normalized units per hour for one DB instance, Aurora I/O-Optimized | Normalized units per hour for three DB instances (writer and two readers), Aurora Standard | Normalized units per hour for three DB instances (writer and two readers), Aurora I/O-Optimized | | --- | --- | --- | --- | --- | | small | 1 | 1.3 | 3 | 3.9 | | medium | 2 | 2.6 | 6 | 7.8 | | large | 4 | 5.2 | 12 | 15.6 | | xlarge | 8 | 10.4 | 24 | 31.2 | | 2xlarge | 16 | 20.8 | 48 | 62.4 | | 4xlarge | 32 | 41.6 | 96 | 124.8 | | 8xlarge | 64 | 83.2 | 192 | 249.6 | | 12xlarge | 96 | 124.8 | 288 | 374.4 | | 16xlarge | 128 | 166.4 | 384 | 499.2 | | 24xlarge | 192 | 249.6 | 576 | 748.8 | | 32xlarge | 256 | 332.8 | 768 | 998.4 | For example, suppose that you purchase a `db.t2.medium` reserved DB instance, and you have two running `db.t2.small` DB instances in your account in the same AWS Region. In this case, the billing benefit is applied in full to both instances. ![\[Applying a reserved DB instance in full to smaller DB instances\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/ri-db-instance-flex-full.png) Alternatively, if you have one `db.t2.large` instance running in your account in the same AWS Region, the billing benefit is applied to 50 percent of the usage of the DB instance. ![\[Applying a reserved DB instance in part to a larger DB instance\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/ri-db-instance-flex-partial.png) **Note** We recommend using the T DB instance classes only for development and test servers, or other non-production servers. For more details on the T instance classes, see [DB instance class types](Concepts.DBInstanceClass.Types.md). ### Aurora reserved DB instance billing examples The following examples illustrate the pricing for reserved DB instances for Aurora DB clusters using both the Aurora Standard and Aurora I/O-Optimized DB cluster configurations. #### Example using Aurora Standard The price for a reserved DB instance doesn't provide a discount for the costs associated with storage, backups, and I/O. The following example illustrates the total cost per month for a reserved DB instance: + An Aurora MySQL reserved Single-AZ db.r5.large DB instance class in US East (N. Virginia) at a cost of \$10.19 per hour, or \$1138.70 per month + Aurora storage at a cost of \$10.10 per GiB per month (assume \$145.60 per month for this example) + Aurora I/O at a cost of \$10.20 per 1 million requests (assume \$120 per month for this example) + Aurora backup storage at \$10.021 per GiB per month (assume \$130 per month for this example) Add all of these options (\$1138.70 \$1 \$145.60 \$1 \$120 \$1 \$130) with the reserved DB instance, and the total cost per month is \$1234.30. If you choose to use an on-demand DB instance instead of a reserved DB instance, an Aurora MySQL Single-AZ db.r5.large DB instance class in US East (N. Virginia) costs \$10.29 per hour, or \$1217.50 per month. So, for an on-demand DB instance, add all of these options (\$1217.50 \$1 \$145.60 \$1 \$120 \$1 \$130), and the total cost per month is \$1313.10. You save nearly \$179 per month by using the reserved DB instance. #### Example using an Aurora Standard DB cluster with two reader instances To use reserved instances for Aurora DB clusters, simply purchase one reserved instance for each DB instance in the cluster. Extending the first example, you have an Aurora MySQL DB cluster with one writer DB instance and two Aurora Replicas, for a total of three DB instances in the cluster. The two Aurora Replicas incur no extra storage or backups charges. If you purchase three db.r5.large Aurora MySQL reserved DB instances, your cost will be \$1234.30 (for the writer DB instance) \$1 2 \$1 (\$1138.70 \$1 \$120 I/O per Aurora Replica), for a total of \$1551.70 per month. The corresponding on-demand cost for an Aurora MySQL DB cluster with one writer DB instance and two Aurora Replicas is \$1313.10 \$1 2 \$1 (\$1217.50 \$1 \$120 I/O per instance) for a total of \$1788.10 per month. You save \$1236.40 per month by using the reserved DB instances. #### Example using Aurora I/O-Optimized You can reuse your existing Aurora Standard reserved DB instances with Aurora I/O-Optimized. To fully use the benefits of your reserved instance discounts with Aurora I/O-Optimized, you can buy 30% additional reserved instances similar to your current reserved instances. The following table shows examples of how to estimate the additional reserved instances when using Aurora I/O-Optimized. If the required reserved instances are a fraction, you can take advantage of the size flexibility available with reserved instances to get to a whole number. In these examples, "current" refers to the Aurora Standard reserved instances that you have now. Additional reserved instances are the number of Aurora Standard reserved instances that you must buy to maintain your current reserved instance discounts when using Aurora I/O-Optimized. | DB instance class | Current Aurora Standard reserved instances | Reserved instances required for Aurora I/O-Optimized | Additional reserved instances needed | Additional reserved instances needed, using size flexibility | | --- | --- | --- | --- | --- | | db.r6g.large | 10 | 10 \$1 1.3 = 13 | 3 \$1 db.r6g.large | 3 \$1 db.r6g.large | | db.r6g.4xlarge | 20 | 20 \$1 1.3 = 26 | 6 \$1 db.r6g.4xlarge | 6 \$1 db.r6g.4xlarge | | db.r6g.12xlarge | 5 | 5 \$1 1.3 = 6.5 | 1.5 \$1 db.r6g.12xlarge | One each of db.r6g.12xlarge, r6g.4xlarge, and r6g.2xlarge (0.5 \$1 db.r6g.12xlarge = 1 \$1 db.r6g.4xlarge \$1 1 \$1 db.r6g.2xlarge ) | | db.r6i.24xlarge | 15 | 15 \$1 1.3 = 19.5 | 4.5 \$1 db.r6i.24xlarge | 4 \$1 db.r6i.24xlarge \$1 1 \$1 db.r6i.12xlarge (0.5 \$1 db.r6i.24xlarge = 1 \$1 db.r6i.12xlarge) | #### Example using an Aurora I/O-Optimized DB cluster with two reader instances You have an Aurora MySQL DB cluster with one writer DB instance and two Aurora Replicas, for a total of three DB instances in the cluster. They use the Aurora I/O-Optimized DB cluster configuration. To use reserved DB instances for this cluster, you would need to buy four reserved DB instances of the same DB instance class. Three DB instances using Aurora I/O-Optimized consume 3.9 normalized units per hour, compared to 3 normalized units per hour for three DB instances using Aurora Standard. However, you save the monthly I/O costs for each DB instance. **Note** The prices in these examples are sample prices and might not match actual prices. For Aurora pricing information, see [Amazon Aurora pricing](https://aws.amazon.com/rds/aurora/pricing). ### Deleting a reserved DB instance The terms for a reserved DB instance involve a one-year or three-year commitment. You can't cancel a reserved DB instance. However, you can delete a DB instance that is covered by a reserved DB instance discount. The process for deleting a DB instance that is covered by a reserved DB instance discount is the same as for any other DB instance. You're billed for the upfront costs regardless of whether you use the resources. If you delete a DB instance that is covered by a reserved DB instance discount, you can launch another DB instance with compatible specifications. In this case, you continue to get the discounted rate during the reservation term (one or three years). # Purchasing reserved DB instances for Amazon Aurora You can use the AWS Management Console, the AWS CLI, and the RDS API to work with reserved DB instances. ## Console You can use the AWS Management Console to work with reserved DB instances as shown in the following procedures. **To get pricing and information about available reserved DB instance offerings** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Reserved instances**. 1. Choose **Purchase Reserved DB Instance**. 1. For **Product description**, choose the DB engine and licensing type. 1. For **DB instance class**, choose the DB instance class. 1. For **Deployment Option**, choose whether you want a Single-AZ or Multi-AZ DB instance deployment. **Note** Reserved Amazon Aurora *instances* always have the deployment option set to **Single-AZ DB instance**. However, when you create an Aurora DB *cluster*, the default deployment option is **Create an Aurora Replica or Reader in a different AZ** (Multi-AZ). You must purchase a reserved DB instance for each instance that you plan to use, including Aurora Replicas. Therefore, for Multi-AZ deployments on Aurora, you must purchase extra reserved DB instances. 1. For **Term**, choose the length of time to reserve the the DB instance. 1. For **Offering type**, choose the offering type. After you select the offering type, you can see the pricing information. **Important** Choose **Cancel** to avoid purchasing the reserved DB instance and incurring any charges. After you have information about the available reserved DB instance offerings, you can use the information to purchase an offering as shown in the following procedure. **To purchase a reserved DB instance** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the navigation pane, choose **Reserved instances**. 1. **Important** Before proceeding, verify that you are in the correct AWS Region. Reserved DB instances are Region-specific and cannot be transferred between Regions. Check the Region selector in the upper-right corner of the console to ensure you are purchasing the reserved instance in the intended Region. 1. Choose **Purchase reserved DB instance**. 1. For **Product description**, choose the DB engine and licensing type. 1. For **DB instance class**, choose the DB instance class. 1. For **Multi-AZ deployment**, choose whether you want a Single-AZ or Multi-AZ DB instance deployment. **Note** Reserved Amazon Aurora *instances* always have the deployment option set to **Single-AZ DB instance**. When you create an Amazon Aurora DB *cluster* from your reserved DB instance, the DB cluster is automatically created as Multi-AZ. Make sure to purchase a reserved DB instance for each DB instance that you plan to use, including Aurora Replicas. 1. For **Term**, choose the length of time you want the DB instance reserved. 1. For **Offering type**, choose the offering type. After you choose the offering type, you can see the pricing information. ![\[Purchase reserved DB instance console\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/reservedinstance-aur.png) 1. (Optional) You can assign your own identifier to the reserved DB instances that you purchase to help you track them. For **Reserved Id**, type an identifier for your reserved DB instance. 1. Choose **Submit**. Your reserved DB instance is purchased, then displayed in the **Reserved instances** list. After you have purchased reserved DB instances, you can get information about your reserved DB instances as shown in the following procedure. **To get information about reserved DB instances for your AWS account** 1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. In the **Navigation** pane, choose **Reserved instances**. The reserved DB instances for your account appear. To see detailed information about a particular reserved DB instance, choose that instance in the list. You can then see detailed information about that instance in the detail pane at the bottom of the console. ## AWS CLI You can use the AWS CLI to work with reserved DB instances as shown in the following examples. **Example of getting available reserved DB instance offerings** To get information about available reserved DB instance offerings, call the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-reserved-db-instances-offerings.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-reserved-db-instances-offerings.html). ``` aws rds describe-reserved-db-instances-offerings ``` This call returns output similar to the following: ``` 1. OFFERING OfferingId Class Multi-AZ Duration Fixed Price Usage Price Description Offering Type 2. OFFERING 438012d3-4052-4cc7-b2e3-8d3372e0e706 db.r3.large y 1y 1820.00 USD 0.368 USD mysql Partial Upfront 3. OFFERING 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f db.r3.small n 1y 227.50 USD 0.046 USD mysql Partial Upfront 4. OFFERING 123456cd-ab1c-47a0-bfa6-12345667232f db.r3.small n 1y 162.00 USD 0.00 USD mysql All Upfront 5. Recurring Charges: Amount Currency Frequency 6. Recurring Charges: 0.123 USD Hourly 7. OFFERING 123456cd-ab1c-37a0-bfa6-12345667232d db.r3.large y 1y 700.00 USD 0.00 USD mysql All Upfront 8. Recurring Charges: Amount Currency Frequency 9. Recurring Charges: 1.25 USD Hourly 10. OFFERING 123456cd-ab1c-17d0-bfa6-12345667234e db.r3.xlarge n 1y 4242.00 USD 2.42 USD mysql No Upfront ``` After you have information about the available reserved DB instance offerings, you can use the information to purchase an offering. To purchase a reserved DB instance, use the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/purchase-reserved-db-instances-offering.html](https://docs.aws.amazon.com/cli/latest/reference/rds/purchase-reserved-db-instances-offering.html) with the following parameters: + `--reserved-db-instances-offering-id` – The ID of the offering that you want to purchase. See the preceding example to get the offering ID. + `--reserved-db-instance-id` – You can assign your own identifier to the reserved DB instances that you purchase to help track them. **Example of purchasing a reserved DB instance** The following example purchases the reserved DB instance offering with ID *649fd0c8-cf6d-47a0-bfa6-060f8e75e95f*, and assigns the identifier of *MyReservation*. For Linux, macOS, or Unix: ``` aws rds purchase-reserved-db-instances-offering \ --reserved-db-instances-offering-id 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f \ --reserved-db-instance-id MyReservation ``` For Windows: ``` aws rds purchase-reserved-db-instances-offering ^ --reserved-db-instances-offering-id 649fd0c8-cf6d-47a0-bfa6-060f8e75e95f ^ --reserved-db-instance-id MyReservation ``` The command returns output similar to the following: ``` 1. RESERVATION ReservationId Class Multi-AZ Start Time Duration Fixed Price Usage Price Count State Description Offering Type 2. RESERVATION MyReservation db.r3.small y 2011-12-19T00:30:23.247Z 1y 455.00 USD 0.092 USD 1 payment-pending mysql Partial Upfront ``` After you have purchased reserved DB instances, you can get information about your reserved DB instances. To get information about reserved DB instances for your AWS account, call the AWS CLI command [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-reserved-db-instances.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-reserved-db-instances.html), as shown in the following example. **Example of getting your reserved DB instances** ``` aws rds describe-reserved-db-instances ``` The command returns output similar to the following: ``` 1. RESERVATION ReservationId Class Multi-AZ Start Time Duration Fixed Price Usage Price Count State Description Offering Type 2. RESERVATION MyReservation db.r3.small y 2011-12-09T23:37:44.720Z 1y 455.00 USD 0.092 USD 1 retired mysql Partial Upfront ``` ## RDS API You can use the RDS API to work with reserved DB instances: + To get information about available reserved DB instance offerings, call the Amazon RDS API operation [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeReservedDBInstancesOfferings.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeReservedDBInstancesOfferings.html). + After you have information about the available reserved DB instance offerings, you can use the information to purchase an offering. Call the [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PurchaseReservedDBInstancesOffering.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PurchaseReservedDBInstancesOffering.html) RDS API operation with the following parameters: + `--reserved-db-instances-offering-id` – The ID of the offering that you want to purchase. + `--reserved-db-instance-id` – You can assign your own identifier to the reserved DB instances that you purchase to help track them. + After you have purchased reserved DB instances, you can get information about your reserved DB instances. Call the [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeReservedDBInstances.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeReservedDBInstances.html) RDS API operation. # Viewing the billing for reserved DB instances for Amazon Aurora You can view the billing for your reserved DB instances in the Billing Dashboard in the AWS Management Console. **To view reserved DB instance billing** 1. Sign in to the AWS Management Console. 1. From the **account menu** at the upper right, choose **Billing Dashboard**. 1. Choose **Bill Details** at the upper right of the dashboard. 1. Under **AWS Service Charges**, expand **Relational Database Service**. 1. Expand the AWS Region where your reserved DB instances are, for example **US West (Oregon)**. Your reserved DB instances and their hourly charges for the current month are shown under **Amazon Relational Database Service for *Database Engine* Reserved Instances**. ![\[View monthly costs for a reserved DB instance\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/ri-db-billing1.png) The reserved DB instance in this example was purchased All Upfront, so there are no hourly charges. 1. Choose the **Cost Explorer** (bar graph) icon next to the **Reserved Instances** heading. The Cost Explorer displays the **Monthly EC2 running hours costs and usage** graph. 1. Clear the **Usage Type Group** filter to the right of the graph. 1. Choose the time period and time unit for which you want to examine usage costs. The following example shows usage costs for on-demand and reserved DB instances for the year to date by month. ![\[View usage costs for on-demand and reserved DB instances\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/ri-db-billing2.png) The reserved DB instance costs from January through June 2021 are monthly charges for a Partial Upfront instance, while the cost in August 2021 is a one-time charge for an All Upfront instance. The reserved instance discount for the Partial Upfront instance expired in June 2021, but the DB instance wasn't deleted. After the expiration date, it was simply charged at the on-demand rate. # Amazon Aurora on the AWS Free Tier Aurora PostgreSQL is also available on the [AWS Free Tier](https://aws.amazon.com/rds/free/) through the [Create with express configuration](CHAP_GettingStartedAurora.AuroraPostgreSQL.ExpressConfig.md). In addition to the express configuration limitations, the following restrictions apply when using Aurora PostgreSQL with the AWS Free Tier: + Only clusters created with express configuration are supported (full configuration is not available) + Up to 4 Aurora Capacity Units (ACUs) per cluster + Up to 1 GB storage per cluster + Maximum 2 clusters and 2 instances per account + Aurora Global Database and Zero-ETL integrations are not supported