Q: What is Amazon Aurora?

Amazon Aurora is a relational database engine that combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Amazon Aurora MySQL delivers up to five times the performance of MySQL without requiring any changes to most MySQL applications; similarly, Amazon Aurora PostgreSQL delivers up to three times the performance of PostgreSQL. Amazon RDS manages your Amazon Aurora databases, handling time-consuming tasks such as provisioning, patching, backup, recovery, failure detection and repair. You pay a simple monthly charge for each Amazon Aurora database instance you use. There are no upfront costs or long-term commitments required.

Q: What does "MySQL compatible" mean?

It means that most of the code, applications, drivers and tools you already use today with your MySQL databases can be used with Aurora with little or no change. The Amazon Aurora database engine is designed to be wire-compatible with MySQL 5.6 using the InnoDB storage engine. Certain MySQL features like the MyISAM storage engine are not available with Amazon Aurora.

Q: What does “PostgreSQL compatible” mean?

It means that most of the code, applications, drivers and tools you already use today with your PostgreSQL databases can be used with Aurora with little or no change. The Amazon Aurora database engine is designed to be wire-compatible with PostgreSQL 9.6, and supports the same set of PostgreSQL extensions that are supported with RDS for PostgreSQL 9.6, making it easy to move applications between the two engines.  

Q: How do I try Amazon Aurora?

To try Amazon Aurora, sign in to the AWS console, select RDS under the Database category, and choose Amazon Aurora as your database engine.

Q: How much does Amazon Aurora cost?

Please see our pricing page for current pricing information.

Q. Amazon Aurora replicates each chunk of my database volume six ways across three Availability Zones. Does that mean that my effective storage price will be three or six times what is shown on the pricing page?

No. Amazon Aurora’s replication is bundled into the price. You are charged based on the storage your database consumes at the database layer, not the storage consumed in Amazon Aurora’s virtualized storage layer.

Q. In which AWS regions is Amazon Aurora available?

Please see our pricing page for current information on regions and prices.

Q: How can I migrate from MySQL to Amazon Aurora and vice versa?

You have several options. You can use the standard mysqldump utility to export data from MySQL and mysqlimport utility to import data to Amazon Aurora, and vice-versa. You can also use Amazon RDS’s DB Snapshot migration feature to migrate an RDS MySQL DB Snapshot to Amazon Aurora using the AWS Management Console. Migration completes for most customers in under an hour, though the duration depends on format and data set size. For more information see the Amazon Aurora Data Export and Import Guide.

Q: How can I migrate from PostgreSQL to Amazon Aurora and vice versa?

You have several options. You can use the standard pg_dump utility to export data from PostgreSQL and pg_restore utility to import data to Amazon Aurora, and vice-versa. You can also use Amazon RDS’s DB Snapshot migration feature to migrate an RDS PostgreSQL 9.6 DB Snapshot to Amazon Aurora using the AWS Management Console. Migration completes for most customers in under an hour, though the duration depends on format and data set size. For more information see the Amazon Aurora Data Export and Import Guide.

Q: Does Amazon Aurora participate in the AWS Free Tier?

Not at this time. The AWS Free Tier for Amazon RDS offers benefits for Micro DB Instances; Amazon Aurora does not currently offer Micro DB Instance support. Please see our pricing page for current pricing information.

Q: What are IOs in Amazon Aurora and how are they calculated?

IOs are input/output operations performed by the Aurora database engine against its SSD-based virtualized storage layer. Every database page read operation counts as one IO. The Aurora database engine issues reads against the storage layer in order to fetch database pages not present in the buffer cache. Each database page is 16KB in Aurora MySQL and 8KB in Aurora PostgreSQL.

Aurora was designed to eliminate unnecessary IO operations in order to reduce costs and to ensure resources are available for serving read/write traffic. Write IOs are only consumed when pushing transaction log records to the storage layer for the purpose of making writes durable. Write IOs are counted in 4KB units. For example, a transaction log record that is 1024 bytes will count as one IO operation. However, concurrent write operations whose transaction log is less than 4KB can be batched together by the Aurora database engine in order to optimize I/O consumption. Unlike traditional database engines Amazon Aurora never pushes modified database pages to the storage layer, resulting in further IO consumption savings.

You can see how many IOs your Aurora instance is consuming by going to the AWS Console. To find your IO consumption, go to the RDS section of the console, look at your list of instances, select your Aurora instances, then look for the “Billed read operations” and “Billed write operations” metrics in the monitoring section.

Q: Do I need to change client drivers to use Amazon Aurora PostgreSQL?

No, Amazon Aurora will work with standard PostgreSQL database drivers.

Q: What is Amazon Aurora Serverless?

At re:Invent 2017, we announced the preview for Amazon Aurora Serverless, a new configuration of the MySQL-compatible edition that can save you valuable time, effort and cost by automatically scaling database capacity up and down to match your application needs.

Q: How can I get started with Amazon Aurora Serverless?

Amazon Aurora Serverless is now available in Preview for the MySQL-compatible edition of Amazon Aurora. You can sign up to request participation. We will announce general availability at a future date.

Q: What does "five times the performance of MySQL" mean?

Amazon Aurora delivers significant increases over MySQL performance by tightly integrating the database engine with an SSD-based virtualized storage layer purpose-built for database workloads, reducing writes to the storage system, minimizing lock contention and eliminating delays created by database process threads. Our tests with SysBench on r3.8xlarge instances show that Amazon Aurora delivers over 500,000 SELECTs/sec and 100,000 UPDATEs/sec, five times higher than MySQL running the same benchmark on the same hardware. Detailed instructions on this benchmark and how to replicate it yourself are provided in the Amazon Aurora MySQL Performance Benchmarking Guide.

Q: What does "three times the performance of PostgreSQL" mean?

Amazon Aurora delivers significant increases over PostgreSQL performance by tightly integrating the database engine with an SSD-based virtualized storage layer purpose-built for database workloads, reducing writes to the storage system, minimizing lock contention and eliminating delays created by database process threads. Our tests with SysBench on r4.16xlarge instances show that Amazon Aurora delivers SELECTs/sec and UPDATEs/sec over three times higher than PostgreSQL running the same benchmark on the same hardware. Detailed instructions on this benchmark and how to replicate it yourself are provided in the Amazon Aurora PostgreSQL Performance Benchmarking Guide.

Q: How do I optimize my database workload for Amazon Aurora MySQL?

Amazon Aurora is designed to be compatible with MySQL 5.6, so that existing MySQL applications and tools can run without requiring modification. However, one area where Amazon Aurora improves upon MySQL is with highly concurrent workloads. In order to maximize your workload’s throughput on Amazon Aurora, we recommend building your applications to drive a large number of concurrent queries and transactions.

Q: How do I optimize my database workload for Amazon Aurora PostgreSQL?

Amazon Aurora is designed to be compatible with PostgreSQL 9.6, so that existing PostgreSQL applications and tools can run without requiring modification. However, one area where Amazon Aurora improves upon PostgreSQL is with highly concurrent workloads. In order to maximize your workload’s throughput on Amazon Aurora, we recommend building your applications to drive a large number of concurrent queries and transactions.

Q: What are the minimum and maximum storage limits of an Amazon Aurora database?

The minimum storage is 10GB. Based on your database usage, your Amazon Aurora storage will automatically grow, up to 64 TB, in 10GB increments with no impact to database performance. There is no need to provision storage in advance.

Q: How do I scale the compute resources associated with my Amazon Aurora DB Instance?

You can scale the compute resources allocated to your DB Instance in the AWS Management Console by selecting the desired DB Instance and clicking the Modify button. Memory and CPU resources are modified by changing your DB Instance class.

When you modify your DB Instance class, your requested changes will be applied during your specified maintenance window. Alternatively, you can use the "Apply Immediately" flag to apply your scaling requests immediately. Both of these options will have an availability impact for a few minutes as the scaling operation is performed. Bear in mind that any other pending system changes will also be applied.

Q: How do I enable backups for my DB Instance?

Automated backups are always enabled on Amazon Aurora DB Instances. Backups do not impact database performance.

Q: Can I take DB Snapshots and keep them around as long as I want?

Yes, and there is no performance impact when taking snapshots. Note that restoring data from DB Snapshots requires creating a new DB Instance.

Q: If my database fails, what is my recovery path?

Amazon Aurora automatically maintains 6 copies of your data across 3 Availability Zones and will automatically attempt to recover your database in a healthy AZ with no data loss. In the unlikely event your data is unavailable within Amazon Aurora storage, you can restore from a DB Snapshot or perform a point-in-time restore operation to a new instance. Note that the latest restorable time for a point-in-time restore operation can be up to 5 minutes in the past.

Q: What happens to my automated backups and DB Snapshots if I delete my DB Instance?

You can choose to create a final DB Snapshot when deleting your DB Instance. If you do, you can use this DB Snapshot to restore the deleted DB Instance at a later date. Amazon Aurora retains this final user-created DB Snapshot along with all other manually created DB Snapshots after the DB Instance is deleted. Only DB Snapshots are retained after the DB Instance is deleted (i.e., automated backups created for point-in-time restore are not kept).

Q: Can I share my snapshots with another AWS account?

Yes. Aurora gives you the ability to create snapshots of your databases, which you can use later to restore a database. You can share a snapshot with a different AWS account, and the owner of the recipient account can use your snapshot to restore a DB that contains your data. You can even choose to make your snapshots public – that is, anybody can restore a DB containing your (public) data. You can use this feature to share data between your various environments (production, dev/test, staging, etc.) that have different AWS accounts, as well as keep backups of all your data secure in a separate account in case your main AWS account is ever compromised.

Q: Will I be billed for shared snapshots?

There is no charge for sharing snapshots between accounts. However, you may be charged for the snapshots themselves, as well as any databases you restore from shared snapshots. Learn more about Aurora pricing.

Q: Can I automatically share snapshots?

We do not support sharing automatic DB snapshots. To share an automatic snapshot, you must manually create a copy of the snapshot, and then share the copy.

Q: How many accounts can I share snapshots with?

You may share manual snapshots with up to 20 AWS account IDs. If you want to share the snapshot with more than 20 accounts, you can either share the snapshot as public, or contact support for increasing your quota.

Q: In which regions can I share my Aurora snapshots?

You can share your Aurora snapshots in all AWS regions where Aurora is available.

Q. Can I share my Aurora snapshots across different regions?

No. Your shared Aurora snapshots will only be accessible by accounts in the same region as the account that shares them.

Q: Can I share an encrypted Aurora snapshot?

Yes, you can share encrypted Aurora snapshots.

Q: How does Amazon Aurora improve my database’s fault tolerance to disk failures?

Amazon Aurora automatically divides your database volume into 10GB segments spread across many disks. Each 10GB chunk of your database volume is replicated six ways, across three Availability Zones. Amazon Aurora is designed to transparently handle the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability. Amazon Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.

Q: How does Aurora improve recovery time after a database crash?

Unlike other databases, after a database crash Amazon Aurora does not need to replay the redo log from the last database checkpoint (typically 5 minutes) and confirm that all changes have been applied, before making the database available for operations. This reduces database restart times to less than 60 seconds in most cases. Amazon Aurora moves the buffer cache out of the database process and makes it available immediately at restart time. This prevents you from having to throttle access until the cache is repopulated to avoid brownouts.

Q: What kind of replicas does Aurora support?

Amazon Aurora MySQL and Amazon Aurora PostgreSQL support Amazon Aurora Replicas, which share the same underlying volume as the primary instance. Updates made by the primary are visible to all Amazon Aurora Replicas. With Amazon Aurora MySQL, you can also create MySQL Read Replicas based on MySQL’s binlog-based replication engine. In MySQL Read Replicas, data from your primary instance is replayed on your replica as transactions. For most use cases, including read scaling and high availability, we recommend using Amazon Aurora Replicas.

You have the flexibility to mix and match these two replica types based on your application needs:

Feature Amazon Aurora Replicas MySQL Replicas
Number of replicas Up to 15 Up to 5
Replication type Asynchronous (milliseconds) Asynchronous (seconds)
Performance impact on primary Low High
Act as failover target Yes (no data loss) Yes (potentially minutes of data loss)
Automated failover Yes No
Support for user-defined replication delay No Yes
Support for different data or schema vs. primary No Yes

Q. Can I have cross-region replicas with Amazon Aurora?

Yes, with Aurora MySQL you can setup a cross-region Aurora Replica from the RDS console. The cross-region replication is based on single threaded MySQL binlog replication and the replication lag will be influenced by the change/apply rate and delays in network communication between the specific regions selected. Aurora PostgreSQL does not currently support cross-region replicas.

Q. Can I create Aurora Read Replicas on the cross-region replica cluster?
Yes, you can add Aurora Replicas on the cluster that will share the same underlying storage as the cross-region replica. The cross-region replica acts as the primary on the cluster and the Aurora Replicas on the cluster will typically lag behind the primary by 10s of milliseconds.

Q. Can I failover my application from my current primary to the cross-region replica?
Yes, you can promote your cross-region replica to be the new primary from the RDS console. The promotion process typically takes a few minutes depending on your workload. The cross-region replication will stop once you initiate the promotion process.

Q: Can I prioritize certain replicas as failover targets over others?

A: Yes. You can assign a promotion priority tier to each instance on your cluster. When the primary instance fails, Amazon RDS will promote the replica with the highest priority to primary. If there is contention between 2 or more replicas in the same priority tier, then Amazon RDS will promote the replica that is the same size as the primary instance. For more information on failover logic, read the Amazon Aurora User Guide.

Q: Can I modify priority tiers for instances after they have been created?

A: You can modify the priority tier for an instance at any time. Simply modifying priority tiers will not trigger a failover.

Q: Can I prevent certain replicas from being promoted to the primary instance?

A: You can assign lower priority tiers to replicas that you don’t want promoted to the primary instance. However, if the higher priority replicas on the cluster are unhealthy or unavailable for some reason, then Amazon RDS will promote the lower priority replica.

Q: How can I improve upon the availability of a single Amazon Aurora database?

You can add Amazon Aurora Replicas. Amazon Aurora Replicas share the same underlying storage as the primary instance. Any Amazon Aurora Replica can be promoted to become primary without any data loss and therefore can be used for enhancing fault tolerance in the event of a primary DB Instance failure. To increase database availability, simply create 1 to 15 replicas, in any of 3 AZs, and Amazon RDS will automatically include them in failover primary selection in the event of a database outage.

Q: What happens during failover and how long does it take?

Failover is automatically handled by Amazon Aurora so that your applications can resume database operations as quickly as possible without manual administrative intervention.

  • If you have an Amazon Aurora Replica, in the same or a different Availability Zone, when failing over, Amazon Aurora flips the canonical name record (CNAME) for your DB Instance to point at the healthy replica, which is in turn is promoted to become the new primary. Start-to-finish, failover typically completes within 30 seconds.
  • If you do not have an Amazon Aurora Replica (i.e. single instance), Aurora will first attempt to create a new DB Instance in the same Availability Zone as the original instance. If unable to do so, Aurora will attempt to create a new DB Instance in a different Availability Zone. From start to finish, failover typically completes in under 15 minutes.

Your application should retry database connections in the event of connection loss.

Q: If I have a primary database and an Amazon Aurora Replica actively taking read traffic and a failover occurs, what happens?

Amazon RDS will automatically detect a problem with your primary instance and begin routing your read/write traffic to an Amazon Aurora Replica. On average, this failover will complete within 30 seconds. In addition, the read traffic that your Amazon Aurora Replicas were serving will be briefly interrupted.

Q: How far behind the primary will my replicas be?

Since Amazon Aurora Replicas share the same data volume as the primary instance, there is virtually no replication lag. We typically observe lag times in the 10s of milliseconds. For MySQL Read Replicas, the replication lag can grow indefinitely based on change/apply rate as well as delays in network communication. However, under typical conditions, under a minute of replication lag is common.

Q: What is Amazon Aurora Multi-Master?

At re:Invent 2017, we announced the preview for Amazon Aurora Multi-Master, a new feature of the Aurora MySQL-compatible edition that adds the ability to scale out write performance across multiple Availability Zones, allowing applications to direct read/write workloads to multiple instances in a database cluster and operate with higher availability.

Q: How can I get started with Amazon Aurora Multi-Master?

Amazon Aurora Multi-Master is now available in Preview for the MySQL-compatible edition of Amazon Aurora. You can sign up to request participation. We will announce general availability at a future date.

Q: Can I use Amazon Aurora in Amazon Virtual Private Cloud (Amazon VPC)?

Yes, all Amazon Aurora DB Instances must be created in a VPC. With Amazon VPC, you can define a virtual network topology that closely resembles a traditional network that you might operate in your own datacenter. This gives you complete control over who can access your Amazon Aurora databases.

Q: Does Amazon Aurora encrypt my data in transit and at rest?

Yes. Amazon Aurora uses SSL (AES-256) to secure the connection between the database instance and the application. Amazon Aurora allows you to encrypt your databases using keys you manage through AWS Key Management Service (KMS). On a database instance running with Amazon Aurora encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, snapshots, and replicas in the same cluster. Encryption and decryption are handled seamlessly. For more information about the use of KMS with Amazon Aurora, see the Amazon RDS User's Guide.

Q: Can I encrypt an existing unencrypted database?

Currently, encrypting an existing unencrypted Aurora instance is not supported. To use Amazon Aurora encryption for an existing unencrypted database, create a new DB Instance with encryption enabled and migrate your data into it.

Q: How do I access my Amazon Aurora database?

Access to Amazon Aurora databases must be done through the database port entered on database creation. This is done to provide an additional layer of security for your data. Step by step instructions on how to connect to your Amazon Aurora database is provided in the Amazon Aurora Connectivity Guide.

Q: Can I use Amazon Aurora with applications that require HIPAA compliance?

A: Yes, the MySQL- and PostgreSQL-compatible editions of Aurora are HIPAA-eligible, so you can use them to build HIPAA-compliant applications and store healthcare related information, including protected health information (PHI) under an executed Business Associate Agreement (BAA) with AWS. If you already have an executed BAA, no action is necessary to begin using these services in the account(s) covered by your BAA. If you do not have an executed BAA with AWS, or have any other questions about HIPAA-compliant applications on AWS, please contact us.

Q: On which instance sizes will Performance Insights be available?

All non-micro instance sizes. As RDS introduces new instance sizes, Performance Insights will be made available on those that have sufficient performance.

Q: When will Performance Insights be available for RDS for PostgreSQL, Aurora MySQL, RDS for MySQL, RDS for Oracle, RDS for SQL Server and RDS for MariaDB?

Performance Insights will be initially available on Aurora PostgreSQL, followed soon after by Aurora MySQL. Additional engines will be added over time.

Q: How does Performance Insights show me the cause of performance problems?

Performance problems appear in the Performance Insights section of the RDS console as spikes in the database load graph. One look at this graph can quickly tell you what type of resources your application has been spending time and resources on in the database. The console allows you to zoom in to any period within the retention time. By selecting the periods of high load, customers can display a list of SQL statements, ordered by overall contribution to load.

Q: How does Performance Insights know about load in my RDS DB instance?

Performance Insights samples the state of all of the connected sessions in your DB instance every second. If a session is spending time in a database-related operation, Performance Insights records the sample time, the type of operation (I/O, CPU, locking, etc.), the current SQL statement and several other session attributes. Over periods of time, this sampled data is used to characterize how sessions are contributing to load in your database instance.

Q: Can performance data be queried from inside the RDS instance?

No. The Performance Insights sampling process does not populate any tables in the database, nor does it present data to be retrieved from within the database via SQL.

Q: Can I see what is happening on my instance in real time?

Yes. By default, Performance Insights displays a moving one hour window of performance data. The feature is designed to present the latest performance information within a few seconds of real time.

Q: How much does Performance Insights cost?

Performance Insights includes 24 hours of retained data and console access. Performance Insights while in preview, offers a free tier that includes a trailing 24 hours of performance data retention. Pricing for longer term data rentention will be announced.

Q: How far back can I look at performance data stored in Performance Insights?

You can see 24 hours of performance history. Options for longer retention will be announced at a future date.

Q: Can I turn off Performance Insights on new instances, even though it is enabled by default?

Yes. The option for Performance Insights is selected by default in the AWS Console when you use the instance creation wizard. You can de-select the option in the wizard to prevent Performance Insights from being enabled, or you can disable Performance Insights in an enabled instance my modifying the instance.

Q: Does Performance Insights work on RDS database instances using encrypted storage?

Yes. Performance Insights does not read the data you store in your database.

Q: What is DB load and why is it the primary measure used in Performance Insights to detect performance issues?

DB load is a time series showing how much time a customer’s applications are spending in the database, and how they are spending that time. DB Load is measured in units of average active sessions (AAS). An active session is a connection (session) that has submitted work to the database engine and is waiting for a response from it. For example, if you submit a SQL statement to a database instance, that session is considered “active” during the time that the instance is processing that query. By counting the number of sessions that are active in an instance at a given moment, we can provide a metric which, averaged over time periods, can show how busy an instance is, and how much time sessions are spending waiting for the instance to respond; this is DB Load. Performance Insights counts active sessions and records each session’s attributes about every second using a lightweight sampling mechanism. The sampled data is encrypted and aggregated to a variety of granularities and served in the DB Load chart. Console users can select the timeframe they want to view.

Q: Do I have to do anything special to my database to enable Performance Insights?

No. However, Performance Insights will work even better on some database engines when additional performance tracking is enabled. For instance, when the pg_stat_statement extension is enabled on RDS PostgreSQL or Aurora PostgreSQL, Performance Insights will use the PostgreSQL-native SQL identifier to identify the statement, and will be able to collect the full text of longer statements. In MySQL, enabling the Performance Schema will allow Performance Insights to collect much richer and deeper detail on wait events affecting the database.

Q: Will enabling Performance Insights affect my database performance?

The Performance Insights agent is designed to stay out of the way of your database workloads. Performance Insights runs at a lower priority than the other processes on your instance, and monitors the health of the host and database. When Performance Insights detects heavy load or depleted resources, it backs off from the usual frequency of data gathering, still collecting data, but only when it is safe to do so. Database options, such as pg_stat_statement in RDS PostgreSQL and Aurora Postgres, and Performance Schema in MySQL may use some database resources and potentially affect performance. Whether enabling these options will affect a particular system depends on the application workload. AWS recommends testing any database options against your workload prior to enabling them on a production system.

Q: Should I keep using Enhanced Monitoring or just use Performance Insights?

Customers using Enhanced Monitoring to monitor O/S metrics should continue to obtain that data via Enhanced Monitoring. In the months to come, that data, as well as an extensive colletion of database metrics, will also become available via the Performance Insights console and an API. At that point, customers will be able to obtain all performance data from Performance Insights. Enhanced Monitoring will remain available for those customers who prefer to use it, but we will encourage customers to standardize their database monitoring on Performance Insights.

Q: Is the data stored in Performance Insights encrypted?

Yes. Performance Insights encrypts all potentially sensitive data using your own KMS key. Data is encrypted in flight and at rest. AWS personnel cannot access or see any potentially sensitive performance data. Only your users on your AWS account with full access to RDS can view Performance Insights. You can revoke RDS’s grant for your KMS key, which enables us to process and display your performance data, at any time.

Q: If I turn off Performance Insights, does AWS retain the data or is it deleted?

Performance data retention free tier is restricted to one day. Disabling Performance Insights on an instance causes your performance data for that instance to be deleted.

Q: What happens to Performance Insights data retention when I stop my RDS database instance?

Stopping an RDS instance that has Performance Insights enabled has no effect on retention or visibility of historical data for that instance. The period during which the instance was stopped will simply contain no data.

Q: How would I interface Performance Insights with my existing performance tools?

In the future, Performance Insights will expose a publicly available API designed to enable customers and third parties to take advantage of the valuable data in Performance Insights.

Q: Is there any way for third party performance tools to integrate with Performance Insights?

In the future, Performance Insights will expose a publicly available API designed to enable customers and third parties to take advantage of the valuable data in Performance Insights.

Q: Will Performance Insights be available in all AWS Regions RDS is?

Yes. Performance Insights will initially be available in four regions: US East (N. Virginia, Ohio), US West (Oregon), and EU (Ireland). Over time, the feature will be made available in all reguions where RDS is supported.

Q: Can I turn on Performance Insights on existing instances or only on new ones?

Yes, Performance Insights can be enabled on existing instances by modifying the instance to enable Performance Insights. It can be enabled on new instances by specifying that Performance Insights should be enabled when creating the instance.

Q: Does Performance Insights use any of the storage on my database instance?

No, Performance Insights does not consume storage space on your RDS instances.

Q: How will Performance Insights be different, if at all, when running against different database engines?

Performance Insights is designed to present a common approach, look and feel to tuning across all database engines in RDS. Because certain attributes like wait events and SQL identifiers vary by engine type, these will naturally vary in Performance Insights as well, when working with different database engines. One of the core tenets of Performance Insights is that existing concepts, identifiers, and attributes in a database engine should remain intact. Performance Insights will generally not re-interpret or rename wait events an other engine-specific attributes, but will present them faithfully as reported by the database engine.

Q: Does Performance Insights work on Multi-AZ instances and Read Replica instances?

Yes. If an RDS database uses Multi-AZ and has Performance Insights enabled, then Performance Insights will remain enabled when and if that instance fails over to the other availability zone. Because Read Replicas are independent instances, customers can either enable or disable Performance Insights on those instances.

Q: Can I export my data from Performance Insights?

In the future, Performance Insights will be adding functionality to export data.

Q: Can I re-import my data to Performance Insights later in order to do performance analysis?

No. Performance Insights only shows data that has been collected directly from an instance. Data obtained via the Performance Insights will be available in the moths to come via an API and then analysis can be done using one of the analytics-oriented services in AWS, such as Amazon Athena, Amazon Redshift, Amazon Redshift Spectrum, and Amazon Quicksight.