Amazon Aurora

(1)

Amazon Aurora

User Guide for Aurora

Amazon Aurora: User Guide for Aurora

(2)

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

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-eﬀectiveness 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 ﬁve 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 conﬁguration and administration.

Aurora is part of the managed database service Amazon Relational Database Service (Amazon RDS).

Amazon RDS is a web service that 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 Amazon Relational Database Service User Guide.

The following points illustrate how Aurora relates to the standard MySQL and PostgreSQL engines available in Amazon RDS:

• You choose Aurora 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-eﬀective 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 Amazon RDS for MySQL and Amazon RDS for PostgreSQL applications to Aurora.

Before using Amazon Aurora, you should complete the steps in Setting up your environment for Amazon Aurora (p. 84), and then review the concepts and features of Aurora in Amazon Aurora DB clusters (p. 3).

Topics

• Amazon Aurora DB clusters (p. 3)

• Amazon Aurora versions (p. 5)

• Regions and Availability Zones (p. 11)

• Supported features in Amazon Aurora by AWS Region and Aurora DB engine (p. 19)

• Amazon Aurora connection management (p. 32)

• Aurora DB instance classes (p. 54)

• Amazon Aurora storage and reliability (p. 64)

(16)

• Amazon Aurora security (p. 67)

• High availability for Amazon Aurora (p. 68)

• Replication with Amazon Aurora (p. 70)

• DB instance billing for Aurora (p. 72)

(17)

Aurora DB clusters

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 DB instance – Supports read and write operations, and performs all of the data modiﬁcations to the cluster volume. Each Aurora DB cluster has one primary DB instance.

• Aurora Replica – Connects to the same storage volume as the primary DB instance and 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 oﬄoad read workloads from the primary DB instance.

The following diagram illustrates the relationship between the cluster volume, the primary DB instance, and Aurora Replicas in an Aurora DB cluster.

NoteThe preceding information applies to all the Aurora clusters that use single-master replication.

These include provisioned clusters, parallel query clusters, global database clusters, serverless clusters, and all MySQL 8.0-compatible, 5.7-compatible, and PostgreSQL-compatible clusters.

Aurora clusters that use multi-master replication have a diﬀerent arrangement of read/write and read-only DB instances. All DB instances in a multi-master cluster can perform write operations. There isn't a single DB instance that performs all the write operations, and there aren't any read-only DB instances. Therefore, the terms primary instance and Aurora Replica don't apply to multi-master clusters. When we discuss clusters that might use multi-master replication, we refer to writer DB instances and reader DB instances.

(18)

Aurora DB clusters

The Aurora cluster illustrates the separation of compute capacity and storage. For example, an Aurora conﬁguration 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).

(19)

Aurora versions

Amazon Aurora versions

Amazon Aurora reuses code and maintains compatibility with the underlying MySQL and PostgreSQL DB engines. However, Aurora has its own version numbers, release cycle, time line for version deprecation, and so on. The following section explains the common points and diﬀerences. This information can help you to decide such things as which version to choose and how to verify which features and ﬁxes are available in each version. It can also help you to decide how often to upgrade and how to plan your upgrade process.

Topics

• Relational databases that are available on Aurora (p. 5)

• Diﬀerences in version numbers between community databases and Aurora (p. 5)

• Amazon Aurora major versions (p. 6)

• Amazon Aurora minor versions (p. 7)

• Amazon Aurora patch versions (p. 7)

• Learning what's new in each Amazon Aurora version (p. 7)

• Specifying the Amazon Aurora database version for your database cluster (p. 7)

• Default Amazon Aurora versions (p. 7)

• Automatic minor version upgrades (p. 8)

• How long Amazon Aurora major versions remain available (p. 8)

• How often Amazon Aurora minor versions are released (p. 9)

• How long Amazon Aurora minor versions remain available (p. 9)

• Long-term support for selected Amazon Aurora minor versions (p. 9)

• Manually controlling if and when your database cluster is upgraded to new versions (p. 9)

• Required Amazon Aurora upgrades (p. 10)

• Testing your DB cluster with a new Aurora version before upgrading (p. 10)

Relational databases that are available on Aurora

The following relational databases are available on Aurora:

• Amazon Aurora MySQL-Compatible Edition. For usage information, see Working with Amazon Aurora MySQL (p. 750). For a detailed list of available versions, see Database engine updates for Amazon Aurora MySQL (p. 1086).

• Amazon Aurora PostgreSQL-Compatible Edition. For usage information, see Working with Amazon Aurora PostgreSQL (p. 1279). For a detailed list of available versions, see Amazon Aurora PostgreSQL updates (p. 1602).

Diﬀerences in version numbers between community databases and Aurora

Each Amazon Aurora version is compatible with a speciﬁc community database version of either MySQL or PostgreSQL. You can ﬁnd the community version of your database using the version function and the Aurora version using the aurora_version function.

Examples for Aurora MySQL and Aurora PostgreSQL are shown following.

(20)

Amazon Aurora major versions

mysql> select version();

+---+

| version() | +---+

| 5.7.12 | +---+

mysql> select aurora_version(), @@aurora_version;

+---+---+

| aurora_version() | @@aurora_version | +---+---+

| 2.08.1 | 2.08.1 | +---+---+

postgres=> select version();

--- PostgreSQL 11.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.9.3, 64-bit (1 row)

postgres=> select aurora_version();

aurora_version --- 3.2.2

For more information, see Checking Aurora MySQL versions using SQL (p. 1088) and Identifying versions of Amazon Aurora PostgreSQL (p. 1602).

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. The following example shows the mapping between community MySQL and PostgreSQL versions and the corresponding Aurora versions.

Community major version Aurora major version

MySQL 5.6 Aurora MySQL 1

PostgreSQL 9.6 Aurora PostgreSQL 1

PostgreSQL 10 Aurora PostgreSQL 2. Not applicable for version

10.18 and higher versions. For these versions, the Aurora version is the same as the major.minor version of the PostgreSQL community version and a third digit in patch location.

11.13 amd higher versions. For these versions, the Aurora version is the same as the major.minor version of the PostgreSQL community version and a third digit in patch location.

12.8 and higher versions. For these versions, the Aurora version is the same as the major.minor

(21)

Amazon Aurora minor versions

Community major version Aurora major version

version of the PostgreSQL community version and a third digit in patch location.

13.3 and higher versions. For these versions, the Aurora version is the same as the major.minor version of the PostgreSQL community version and a third digit in patch location.

Amazon Aurora minor versions

Aurora versions use the major.minor.patch scheme. An Aurora minor version provides incremental community and Aurora-speciﬁc improvements to the service, for example new features and bug ﬁxes.

Aurora minor versions are always mapped to a speciﬁc community version. However, some community versions might not have an Aurora equivalent.

Amazon Aurora patch versions

Aurora versions use the major.minor.patch scheme. An Aurora patch version includes important bug ﬁxes added to a minor version after its initial release (for example, Aurora MySQL 2.04.0, 2.04.1, ..., 2.04.9). While each new minor version provides new Aurora features, new patch versions within a speciﬁc minor version are primarily used to resolve important issues.

For more information on patching, see Maintaining an Amazon Aurora DB cluster (p. 446).

Learning what's new in each Amazon Aurora version

Each new Aurora version comes with release notes that list the new features, ﬁxes, other enhancements, and so on that apply to each version.

For Aurora MySQL release notes, see Database engine updates for Amazon Aurora MySQL version 2 (p. 1113) and Database engine updates for Amazon Aurora MySQL version 1 (p. 1200). For Aurora PostgreSQL release notes, see Amazon Aurora PostgreSQL releases and engine versions (p. 1604).

Specifying the Amazon Aurora database version for your database cluster

You can specify any currently available version (major and minor) when creating a new DB cluster using the Create database operation in the AWS Management Console, the AWS CLI, or the

CreateDBCluster API operation. Not every Aurora database version is available in every AWS Region.

To learn how to create Aurora clusters, see Creating an Amazon Aurora DB cluster (p. 125). To learn how to change the version of an existing Aurora cluster, see Modifying an Amazon Aurora DB cluster (p. 375).

Default Amazon Aurora versions

When a new Aurora minor version contains signiﬁcant improvements compared to a previous one, it's marked as the default version for new DB clusters. Typically, we release two default versions for each major version per year.

(22)

Automatic minor version upgrades

We recommend that you keep your DB cluster upgraded to the most current default minor version, because that version contains the latest security and functionality ﬁxes.

Automatic minor version upgrades

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 only performs the automatic upgrade if all DB instances in your cluster have this setting turned on. Auto minor version upgrades are performed to the default minor version. We typically schedule automatic upgrades twice a year for DB clusters that have the Auto minor version upgrade setting set to Yes. These upgrades are started during the maintenance window that you specify for your cluster.

For more information, see Enabling automatic upgrades between minor Aurora MySQL versions (p. 1093) and Automatic minor version upgrades for PostgreSQL (p. 1699).

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 the following dates to plan your testing and upgrade cycles. These dates represent the earliest date that an upgrade to a newer version might be required. If Amazon extends support for an Aurora version for longer than originally stated, we plan to update this table to reﬂect the later date.

Database community version Aurora version Expected date for upgrading to a newer version

MySQL 5.6 1 February 28, 2023, 00:00:00

UTC

MySQL 5.7 2 February 29, 2024

MySQL 8.0 3

PostgreSQL 9.6 1 January 31, 2022

PostgreSQL 10 January 31, 2023

PostgreSQL 13

Varies depending on the minor version of the Aurora PostgreSQL release. For more information, see Amazon Aurora major versions (p. 6).

January 31, 2026

Before we ask that you upgrade to a newer major version and to help you plan, we provide a reminder at least 12 months in advance. We do so to communicate the detailed upgrade process. Details include the timing of certain milestones, the impact on your DB clusters, and the actions that we recommend that you take. We always recommend that you thoroughly test your applications against new database versions before performing a major version upgrade.

After this 12-month period, an automatic upgrade to the subsequent major version might be applied to any database cluster still running the older version. If so, the upgrade is started during scheduled maintenance windows.

(23)

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 ﬁxes.

How long Amazon Aurora minor versions remain available

We intend to make each Amazon Aurora minor version of a particular major version available for at least 12 months. At the end of this period, Aurora might apply an auto minor version upgrade to the subsequent default minor version. Such an upgrade is started during the scheduled maintenance window for any cluster that is still running the older minor version.

We might replace a minor version of a particular major version sooner than the usual 12-month period if there are critical matters such as security issues, or if the major version has been deprecated.

Before beginning automatic upgrades of minor versions, we generally provide a reminder three months in advance. We do so to communicate the detailed upgrade process. Details include the timing of certain milestones, the impact on your DB clusters, and the actions that we recommend that you take.

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. We generally provide a reminder six months before the end of this period. We do so to communicate the detailed upgrade process. Details include the timing of certain milestones, the impact on your DB clusters, and the actions that we recommend that you take.

LTS minor versions include only bug 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. We do this patching to help ensure that you benefit from cumulative security and stability fixes. We might patch an LTS minor version more frequently if there are critical fixes, such as for security, that need to be applied.

NoteIf you want to remain on an LTS minor version for the duration of its lifecycle, make sure to turn oﬀ Auto minor version upgrade for your DB instances. To avoid automatically upgrading your DB cluster from the LTS minor version, set Auto minor version upgrade to No on all DB instances in your Aurora cluster.

For the version numbers of all Aurora LTS versions, see Aurora MySQL long-term support (LTS) releases (p. 1089) and Aurora PostgreSQL long-term support (LTS) releases (p. 1701).

Manually controlling if and when your database cluster is upgraded to new versions

Auto minor version upgrades are performed to the default minor version. We typically schedule automatic upgrades twice a year for DB clusters that have the Auto minor version upgrade setting set to Yes. These upgrades are started during customer-speciﬁed maintenance windows. If you want to turn oﬀ automatic minor version upgrades, set Auto minor version upgrade to No on any DB instance within

(24)

Required Amazon Aurora upgrades

an Aurora cluster. Aurora performs an automatic minor version upgrade only if all DB instances in your cluster have the setting turned on.

Because major version upgrades involve some compatibility risk, they don't occur automatically. You must initiate these, except in the case of a major version deprecation, as explained earlier. We always recommend that you thoroughly test your applications with new database versions before performing a major version upgrade.

For more information about upgrading a DB cluster to a new Aurora major version, see Upgrading Amazon Aurora MySQL DB clusters (p. 1092) and Upgrading the PostgreSQL DB engine for Aurora PostgreSQL (p. 1692).

Required Amazon Aurora upgrades

For certain critical ﬁxes, we might perform a managed upgrade to a newer patch level within the same minor version. These required upgrades happen even if Auto minor version upgrade is turned oﬀ. Before doing so, we communicate the detailed upgrade process. Details include the timing of certain milestones, the impact on your DB clusters, and the actions that we recommend that you take. Such managed upgrades are performed automatically. Each such upgrade is started 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 Aurora DB cluster (p. 405) and Creating a DB cluster snapshot (p. 498).

(25)

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.

NoteFor information about ﬁnding the Availability Zones for an AWS Region, see Describe Your Availability Zones in the Amazon EC2 documentation.

Amazon operates state-of-the-art, highly-available data centers. Although rare, failures can occur that aﬀect the availability of DB instances that are in the same location. If you host all your DB instances in a single location that is aﬀected by such a failure, none of your DB instances will be available.

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, by setting the AWS_DEFAULT_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 Conﬁguring the AWS Command Line Interface, speciﬁcally the sections about environment variables and command line options.

Amazon RDS supports special AWS Regions called AWS GovCloud (US) that 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 speciﬁc regulatory and compliance requirements.

For more information, see What is AWS GovCloud (US)?

To create or work with an Amazon RDS DB instance in a speciﬁc AWS Region, use the corresponding regional service endpoint.

NoteAurora 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.

(26)

AWS Regions

When you view your resources, you see only the resources that are tied to the AWS Region that you speciﬁed. 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 (p. 12)

• Aurora PostgreSQL Region availability (p. 14)

Aurora MySQL Region availability

The following table shows the AWS Regions where Aurora MySQL is currently available and the endpoint for each Region.

Region

Name Region Endpoint Protocol

US East

(Ohio) us-east-2 rds.us-east-2.amazonaws.com HTTPS

US East (N.

Virginia) us-east-1 rds.us-east-1.amazonaws.com HTTPS

US West (N.

California)

us-west-1 rds.us-west-1.amazonaws.com HTTPS

US West

(Oregon) us-west-2 rds.us-west-2.amazonaws.com HTTPS

Africa (Cape Town)

af-south-1 rds.af-south-1.amazonaws.com HTTPS

Asia Paciﬁc (Hong Kong)

ap-east-1 rds.ap-east-1.amazonaws.com HTTPS

Asia Paciﬁc (Jakarta)

ap-

southeast-3 rds.ap-southeast-3.amazonaws.com HTTPS

Asia Paciﬁc (Mumbai)

ap-

south-1 rds.ap-south-1.amazonaws.com HTTPS

AsiaPaciﬁc (Osaka)

ap-northeast-3 rds.ap-northeast-3.amazonaws.com HTTPS

(27)

AWS Regions

Region

Asia Paciﬁc (Seoul)

ap-

northeast-2 rds.ap-northeast-2.amazonaws.com HTTPS

AsiaPaciﬁc (Singapore)

ap-southeast-1 rds.ap-southeast-1.amazonaws.com HTTPS

Asia Paciﬁc (Sydney)

ap-

AsiaPaciﬁc (Tokyo)

Canada

(Central) ca-

central-1 rds.ca-central-1.amazonaws.com HTTPS

Europe

(Frankfurt) eu-

central-1 rds.eu-central-1.amazonaws.com HTTPS

Europe

(Ireland) eu-west-1 rds.eu-west-1.amazonaws.com HTTPS

Europe

(London) eu-west-2 rds.eu-west-2.amazonaws.com HTTPS

Europe

(Milan) eu-

south-1 rds.eu-south-1.amazonaws.com HTTPS

Europe

(Paris) eu-west-3 rds.eu-west-3.amazonaws.com HTTPS

Europe

(Stockholm) eu-north-1 rds.eu-north-1.amazonaws.com HTTPS Middle

East(Bahrain)

me-

south-1 rds.me-south-1.amazonaws.com HTTPS

South America (SãoPaulo)

sa-east-1 rds.sa-east-1.amazonaws.com HTTPS

AWSGovCloud (US-East)

us-gov-

east-1 rds.us-gov-east-1.amazonaws.com HTTPS

AWS GovCloud (US-West)

us-gov-

west-1 rds.us-gov-west-1.amazonaws.com HTTPS

(28)

AWS Regions

Aurora PostgreSQL Region availability

The following table shows the AWS Regions where Aurora PostgreSQL is currently available and the endpoint for each Region.

Region

US East

(Ohio) us-east-2 rds.us-east-2.amazonaws.com HTTPS

US East (N.

Virginia) us-east-1 rds.us-east-1.amazonaws.com HTTPS

US West (N.

California)

us-west-1 rds.us-west-1.amazonaws.com HTTPS

US West

(Oregon) us-west-2 rds.us-west-2.amazonaws.com HTTPS

Africa (Cape Town)

af-south-1 rds.af-south-1.amazonaws.com HTTPS

Asia Paciﬁc (Hong Kong)

ap-east-1 rds.ap-east-1.amazonaws.com HTTPS

Asia Paciﬁc (Jakarta)

ap-

AsiaPaciﬁc (Mumbai)

ap-south-1 rds.ap-south-1.amazonaws.com HTTPS

Asia Paciﬁc (Osaka)

ap-

Asia Paciﬁc (Seoul)

ap-

AsiaPaciﬁc (Singapore)

ap-southeast-1 rds.ap-southeast-1.amazonaws.com HTTPS

Asia Paciﬁc (Sydney)

ap-

AsiaPaciﬁc (Tokyo)

(29)

Availability Zones

Region

Canada

(Central) ca-

central-1 rds.ca-central-1.amazonaws.com HTTPS

Europe

(Frankfurt) eu-

central-1 rds.eu-central-1.amazonaws.com HTTPS

Europe

(Ireland) eu-west-1 rds.eu-west-1.amazonaws.com HTTPS

Europe

(London) eu-west-2 rds.eu-west-2.amazonaws.com HTTPS

Europe

(Milan) eu-

south-1 rds.eu-south-1.amazonaws.com HTTPS

Europe

(Paris) eu-west-3 rds.eu-west-3.amazonaws.com HTTPS

Europe

(Stockholm) eu-north-1 rds.eu-north-1.amazonaws.com HTTPS Middle

East (Bahrain)

me-south-1 rds.me-south-1.amazonaws.com HTTPS

South America (São Paulo)

sa-east-1 rds.sa-east-1.amazonaws.com HTTPS

AWSGovCloud (US-East)

us-gov-

east-1 rds.us-gov-east-1.amazonaws.com HTTPS

AWS GovCloud (US-West)

us-gov-

west-1 rds.us-gov-west-1.amazonaws.com HTTPS

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, thus associating that instance with a specific AZ chosen by Aurora.

Each Aurora DB cluster hosts copies of its storage in three separate AZs. 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 if you don't specify an AZ. If an AWS Region has fewer than three AZs, Aurora isn't available in that Region.

To learn how to specify the AZ when you create a cluster or add instances to it, see VPC, subnets, and AZs (p. 125).

(30)

Local time zone for DB clusters

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 in the cluster parameter group for your DB cluster to one of the supported values listed later in this section. For Aurora MySQL, the name of this parameter is time_zone. 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. If other Aurora DB clusters are using the same cluster parameter group, then 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 (p. 344).

After you set the local time zone, all new connections to the database reﬂect the change. If you have any open connections to your database when you change the local time zone, you won'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, then the replication master DB cluster and the replica use diﬀerent parameter groups (parameter groups are unique to an AWS Region). To use the same local time zone for each instance, you must set the time zone parameter in the parameter groups for both the replication master 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. If you restore a DB cluster to a point in time, then the local time zone for the restored DB cluster is the time zone setting from the parameter group of the restored DB cluster.

You can set your local time zone to one of the values listed in the following table. 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 If your DB cluster is in the South America (Sao Paulo) Region 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/Fortaleza.

America/Guatemala

(31)

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/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

(32)

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

(33)

Supported Aurora features by Region and engine

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 speciﬁc versions of each database engine, and across AWS Regions. You can use the tables in this section to identify Aurora database engine version support and availability in a given AWS Region for the following features:

Topics

• Backtracking in Aurora (p. 19)

• Aurora global databases (p. 21)

• Aurora machine learning (p. 23)

• Aurora parallel queries (p. 26)

• Amazon RDS Proxy (p. 27)

• Aurora Serverless v1 (p. 29)

• Data API for Aurora Serverless (p. 31)

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.

The tables use the following patterns to specify version numbers and level of support:

• Version x.y – The speciﬁc version alone is supported.

• Version x.y and higher – The version and all minor versions are also supported. For example, "version 10.11 and higher" means that versions 10.11, 10.11.1, and 10.12 are also supported.

• - – The feature is not currently available for that particular Aurora feature for the given Aurora database engine, or in that speciﬁc AWS Region.

Backtracking in Aurora

By using backtracking in Aurora, you return the state of an Aurora cluster to a speciﬁc point in time, without restoring data from a backup. It completes within seconds, even for large databases. For more information, see Backtracking an Aurora DB cluster (p. 821).

Aurora backtracking is available for Aurora MySQL only. It's not available for Aurora PostgreSQL.

Region Aurora MySQL 5.6 Aurora MySQL 5.7 Aurora MySQL 8.0

US East (Ohio) Version 5.6.10a Version 2.06 and higher - US East (N.

Virginia) Version 5.6.10a Version 2.06 and higher -

US West (N.

California) Version 5.6.10a Version 2.06 and higher -

US West

(Oregon) Version 5.6.10a Version 2.06 and higher -

(34)

Backtracking in Aurora

Region Aurora MySQL 5.6 Aurora MySQL 5.7 Aurora MySQL 8.0

Africa (Cape

Town) - - -

Asia Paciﬁc

(Hong Kong) - - -

Asia Paciﬁc

(Jakarta) - - -

Asia Paciﬁc

(Mumbai) Version 5.6.10a Version 2.06 and higher -

Asia Paciﬁc

(Osaka) Version 5.6.10a; version 1.22

and higher Version 2.07.3 and higher -

Asia Paciﬁc

(Seoul) Version 5.6.10a Version 2.06 and higher -

Asia Paciﬁc

(Singapore) Version 5.6.10a Version 2.06 and higher -

Asia Paciﬁc

(Sydney) Version 5.6.10a Version 2.06 and higher -

Asia Paciﬁc

(Tokyo) Version 5.6.10a Version 2.06 and higher -

Canada

(Central) Version 5.6.10a Version 2.06 and higher -

China (Beijing) - - -

China

(Ningxia) - - -

Europe

(Frankfurt) Version 5.6.10a Version 2.06 and higher -

Europe

(Ireland) Version 5.6.10a Version 2.06 and higher -

Europe

(London) Version 5.6.10a Version 2.06 and higher -

Europe (Milan) - - -

Europe (Paris) Version 5.6.10a Version 2.06 and higher - Europe

(Stockholm) - - -

Middle East

(Bahrain) - - -

South America (São Paulo)

- - -

Amazon Aurora

Amazon Aurora

User Guide for Aurora

Amazon Aurora: User Guide for Aurora

Table of Contents

What is Amazon Aurora?

Amazon Aurora DB clusters

Amazon Aurora versions

Relational databases that are available on Aurora

Diﬀerences in version numbers between community databases and Aurora

Amazon Aurora major versions

Amazon Aurora minor versions

Amazon Aurora patch versions

Learning what's new in each Amazon Aurora version

Specifying the Amazon Aurora database version for your database cluster

Default Amazon Aurora versions

Automatic minor version upgrades

How long Amazon Aurora major versions remain available

How often Amazon Aurora minor versions are released

How long Amazon Aurora minor versions remain available

Long-term support for selected Amazon Aurora minor versions

Manually controlling if and when your database cluster is upgraded to new versions

Required Amazon Aurora upgrades

Testing your DB cluster with a new Aurora version before upgrading

Regions and Availability Zones

AWS Regions

Region availability

Aurora MySQL Region availability

Aurora PostgreSQL Region availability

Availability Zones

Local time zone for Amazon Aurora DB clusters

Supported features in Amazon Aurora by AWS Region and Aurora DB engine

Backtracking in Aurora