Amazon RDS FAQs

General

The Basics

Q: What is Amazon RDS?

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity, while managing time-consuming database administration tasks, freeing you up to focus on your applications and business.

Amazon RDS gives you access to the capabilities of a familiar MySQL, Oracle or SQL Server database. This means that the code, applications, and tools you already use today with your existing MySQL databases should work seamlessly with Amazon RDS. Amazon RDS automatically patches the database software and backs up your database, storing the backups for a user-defined retention period. You benefit from the flexibility of being able to scale the compute resources or storage capacity associated with your relational database instance via a single API call or few clicks of the AWS Management Console. In addition, Amazon RDS makes it easy to use replication (currenly supported for MySQL and Oracle database engines) to enhance database availability, improve data durability, or scale beyond the capacity constraints of a single database instance for read-heavy database workloads. As with all Amazon Web Services, there are no up-front investments required, and you pay only for the resources you use.

Q: What is a database instance (DB Instance)?

You can think of a DB Instance as a database environment in the cloud with the compute and storage resources you specify. You can create and delete DB Instances, define/refine infrastructure attributes of your DB Instance(s), and control access and security via the AWS Management Console, Amazon RDS APIs, and Command Line Tools. Multiple MySQL databases or SQL Server databases (up to 30) or Oracle database schemas can be created on a given DB Instance.

Q: What does Amazon RDS manage on my behalf?

Amazon RDS manages the work involved in setting up a relational database, from provisioning the infrastructure capacity you request to installing the database software. Once your database is running on its own DB Instance, Amazon RDS automates common administrative tasks, such as performing backups and patching the database software that powers your DB Instance. For optional Multi-AZ deployments (currently supported for MySQL and Oracle database engines), Amazon RDS also manages synchronous data replication across Availability Zones and automatic failover.

Since Amazon RDS provides native database access, you interact with the relational database software as you normally would. This means you’re still responsible for managing the database settings that are specific to your application. You’ll need to build the relational schema that best fits your use case and are responsible for any performance tuning to optimize your database for your application’s workflow.

Q: When would I use Amazon RDS vs. Amazon EC2 Relational Database AMIs vs. Amazon SimpleDB vs. Amazon DynamoDB?

Amazon Web Services provides a number of database alternatives for developers. Amazon RDS enables you to run a fully featured relational database while offloading database administration; Amazon SimpleDB provides simple index and query capabilities with seamless scalability; Amazon DynamoDB is a fully managed NoSQL database service that offers fast and predictable performance with seamless scalability; and using one of our many relational database AMIs on Amazon EC2 and Amazon EBS allows you to operate your own relational database in the cloud. There are important differences between these alternatives that may make one more appropriate for your use case. See Running Databases on AWS for guidance on which solution is best for you.

Q: How do I get started with Amazon RDS?

To sign up for Amazon RDS, you must click the “Sign up for Amazon RDS” button on the Amazon RDS detail page and complete the sign-up process. You must have an Amazon Web Services account; if you do not already have one, you will be prompted to create one when you begin the Amazon RDS sign-up process. After you are signed up for RDS, please refer to the Amazon RDS documentation, which includes our Getting Started Guide.

Once you have familiarized yourself with Amazon RDS, you can launch a DB Instance within minutes by using the AWS Management Console or Amazon RDS APIs.

Q: How do I create a DB Instance?

DB Instances are simple to create, using either the AWS Management Console, Amazon RDS APIs, or Command Line Tools. To launch a DB Instance using the AWS Management Console, click on the “Launch DB Instance” button on the “Amazon RDS” tab. From there, you can specify your DB Instance compute class, allocated storage, DB Engine, DB Engine version (optional), License Model (optional), DB Instance identifier, master user name, master user password, and whether your DB Instance should run as a Multi-AZ deployment. You also have the ability to change your DB Instance’s backup retention policy, preferred backup window, and scheduled maintenance window. Alternatively, you can create your DB Instance using the CreateDBInstance API or rds-create-db-instance command.

Q: How do I access my running DB Instance?

Once your DB Instance is available, you can retrieve its endpoint via the DB Instance description in the AWS Management Console or DescribeDBInstance API. Using this endpoint you can construct the connection string required to connect directly with your DB Instance using your favorite database tool or programming language. In order to allow network requests to your running DB Instance, you will need to authorize access. For a detailed explanation of how to construct your connection string and get started, please refer to our Getting Started Guide.

Q: How many DB Instances can I run with Amazon RDS?

By default, customers are allowed to have up to a total of 20 Amazon RDS DB instances. Of those 20, up to 10 can be Oracle or SQL Server DB Instances under the "License Included" model. All 20 can be used for MySQL or Oracle or SQL Server under the "BYOL" model. If your application requires more DB Instances, you can request additional DB Instances via this request form.

Q: How do I import data to Amazon RDS?

There are a number of simple ways to import data into Amazon RDS, such as with the mysqldump or mysqlimport utilities for MySQL; Data Pump, import/export or SQL Loader for Oracle; and Import/Export wizard or Bulk Copy Program (BCP) for SQL Server. For more information on data import and export, please refer to the Data Import Guide for MySQL or the Data Import Guide for Oracle or the Data Import Guide for SQL Server.

Q: Which relational database engines does Amazon RDS support?

Amazon RDS currently supports MySQL 5.1 and 5.5 (Community Edition) with InnoDB as the default database storage engine, Oracle Database 11gR2 and SQL Server 2008 R2.

If you are using MySQL, you can use Amazon RDS MySQL DB Engine Version Management for optional control over the MySQL minor version of your DB Instance.

If you are using Oracle, you can use Amazon RDS Oracle DB Engine Version Management for optional control over the patch level of your DB Instance.

If you are using SQL Server, you can use Amazon RDS SQL Server DB Engine Version Management for optional control over the patch level of your DB Instance.

Q: What storage engines does Amazon RDS for MySQL support?

The Point-In-Time-Restore and Snapshot Restore features of Amazon RDS for MySQL require a crash recoverable storage engine and are supported for InnoDB storage engine only. While MySQL supports multiple storage engines with varying capabilities, not all of them are optimized for crash recovery and data durability. For example, MyISAM storage engine does not support reliable crash recovery and may result in lost or corrupt data when MySQL is restarted after a crash, preventing Point-In-Time-Restore or Snapshot restore from working as intended. However, if you still choose to use MyISAM with Amazon RDS, following these steps may be helpful in certain scenarios for Snapshot Restore functionality.

If you would like to convert existing MyISAM tables to InnoDB tables, you can use alter table command (e.g., alter table TABLE_NAME engine=innodb;). Please bear in mind that MyISAM and InnoDB have different strengths and weaknesses, so you should fully evaluate the impact of making this switch on your applications before doing so.

In addition, Federated Storage Engine is currently not supported by Amazon RDS for MySQL.

Q: What is a maintenance window? Will my DB Instance be available during software maintenance?

You can think of the Amazon RDS maintenance window as an opportunity to control when DB Instance modifications (such as scaling DB Instance class) and software patching occur, in the event either are requested or required. If a “maintenance” event is scheduled for a given week, it will be initiated and completed at some point during the 30 minute maintenance window you identify.

The only maintenance events that require Amazon RDS to take your DB Instance offline are scale compute operations (which generally take only a few minutes from start-to-finish) or required software patching. Required patching is automatically scheduled only for patches that are security and durability related. Such patching occurs infrequently (typically once every few months) and should seldom require more than a fraction of your maintenance window. If you do not specify a preferred weekly maintenance window when creating your DB Instance, a 30 minute default value is assigned. If you wish to modify when maintenance is performed on your behalf, you can do so by modifying your DB Instance in the AWS Management Console or by using the ModifyDBInstance API. Each of your DB Instances can have different preferred maintenance windows, if you so choose.

Running your DB Instance as a Multi-AZ deployment can further reduce the impact of a maintenance event, as Amazon RDS will conduct maintenance via the following steps: 1) Perform maintenance on standby 2) Promote standby to primary 3) Perform maintenance on old primary, which becomes the new standby.

For more information on using the APIs or command line interface to specify your maintenance window, please refer to the Amazon RDS Developer Guide. For more information on Multi-AZ mode deployments, click here.

Q: What should I do if my queries seem to be running slow?

If you are using MySQL, you can access the MySQL slow query logs for your database to determine if there are slow-running SQL queries and, if so, the performance characteristics of each. You could set the "slow_query_log" DB Parameter and query the mysql.slow_log table to review the slow-running SQL queries. Please refer to the Amazon RDS User Guide to learn more.

If you are using Oracle, you can use the Oracle trace file data to identify slow queries. For more information on accessing trace file data, please refer to Amazon RDS User Guide.

If you are using SQL Server, you can use the client side SQL Server traces to identify slow queries. For information on accessing server side trace file data, please refer to Amazon RDS User Guide.

You may also want to check the CPU utilization metrics for your DB Instance via Amazon CloudWatch. High levels of CPU utilization can reduce query performance and in this case you may want to consider scaling your DB Instance class. For more information on monitoring your CPU utilization, read the Amazon RDS Monitoring Guide.

Billing

Q: How will I be charged and billed for my use of Amazon RDS?

You pay only for what you use, and there are no minimum or setup fees. You are billed based on:

• DB Instance hours – Based on the class (e.g. Standard Small, Large, Extra Large) of the DB Instance consumed. Partial DB Instance hours consumed are billed as full hours.
• Storage (per GB per month) – Storage capacity you have provisioned to your DB Instance. If you scale your provisioned storage capacity within the month, your bill will be pro-rated.
• I/O requests per month – Total number of storage I/O requests you have.
• Provisioned IOPS - You will be charged for the IOPS and storage you provision, regardless of whether you use them in a given month. If you are using Provisioned IOPS, you will not be charged for I/O requests. If you have I/O-intensive workloads, you may save money by switching to Provisioned IOPS.
• Backup Storage – Backup storage is the storage associated with your automated database backups and any active database snapshots you have taken. Increasing your backup retention period or taking additional database snapshots increases the backup storage consumed by your database. Amazon RDS provides backup storage up to 100% of your provisioned database storage at no additional charge. For example, if you have 10GB-months of provisioned database storage, we will provide up to 10GB-months of backup storage at no additional charge. Based upon our experience as database administrators, the vast majority of databases require less raw storage for a backup than for the primary data set, meaning that most customers will never pay for backup storage. Backup storage is only free for active DB Instances.
• Data transfer –Internet data transfer in and out of your DB Instance.

For Amazon RDS pricing information, please visit the pricing section on the Amazon RDS product page.

Q: When does billing of my Amazon RDS DB Instances begin and end?

Billing commences for a DB Instance as soon as the DB Instance is available. Billing continues until the DB Instance terminates, which would occur upon deletion or in the event of instance failure.

Q: What defines billable Amazon RDS instance hours?

DB Instance hours are billed for each hour your DB Instance is running in an available state. If you no longer wish to be charged for your DB Instance, you must terminate it to avoid being billed for additional instance-hours. Partial DB Instance hours consumed are billed as full hours.

Q: Why does additional backup storage cost more than allocated DB Instance storage?

The storage provisioned to your DB Instance for your primary data is located within a single Availability Zone. When your database is backed up, the backup data (including transactions logs) is geo-redundantly replicated across multiple Availability Zones to provide even greater levels of data durability. The price for backup storage beyond your free allocation reflects this extra replication that occurs to maximize the durability of your critical backups.

Q: How will I be billed for Multi-AZ DB Instance deployments?

If you specify that your DB Instance should be a Multi-AZ deployment, you will be billed according to the Multi-AZ pricing posted on the Amazon RDS pricing page. Multi-AZ billing is based on:

• Multi-AZ DB Instance Hours – Based on the class (e.g. Small, Large, Extra Large) of the DB Instance consumed. As with standard deployments in a single Availability Zone, partial DB Instance hours consumed are billed as full hours. If you convert your DB Instance deployment between standard and Multi-AZ within a given hour, you will be charged both applicable rates for that hour.
• Provisioned storage (for Multi-AZ DB Instance) – If you convert your deployment between standard and Multi-AZ within a given hour, you will be charged the higher of the applicable storage rates for that hour.
• I/O requests per month – Total number of storage I/O requests you have. Multi-AZ deployments consume a larger volume of I/O requests than standard DB Instance deployments, depending on your database write/read ratio. Write I/O usage associated with database updates will double as Amazon RDS synchronously replicates your data to the standby DB instance. Read I/O usage will remain the same.
• Backup Storage – Your backup storage usage will not change whether your DB Instance is a standard or Multi-AZ deployment. Backups will simply be taken from your standby to avoid I/O suspension on the DB Instance primary.
• Data transfer – You are not charged for the data transfer incurred in replicating data between your primary and standby.

Q: Do your prices include taxes?

Except as otherwise noted, our prices are exclusive of applicable taxes and duties, including VAT and applicable sales tax. For example, our prices for the Asia Pacific (Tokyo) Region are inclusive of Japan consumption tax.

Reserved Instances

Q: What are Amazon RDS Reserved Instances?

With Reserved Instances, you can now make a one-time, up-front payment to create a one or three year reservation to run your DB Instance in a specific Region and receive a significant discount off of the ongoing hourly usage charge. There are three Reserved Instance types (Light, Medium, and Heavy Utilization Reserved Instances) that enable you to balance the amount you pay upfront with your effective hourly price.

Q: How are Reserved Instances different from On-Demand DB Instances?

Functionally, Reserved Instances and On-Demand DB Instances are exactly the same. The only difference is how your DB Instance(s) are billed; with Reserved Instances, you make a one-time up-front payment and receive a lower ongoing hourly usage rate (compared with On-Demand DB Instances) for the duration of the term.

Q: How do I purchase and create Reserved Instances?

You can use the "Purchase Reserved DB Instance" option in the AWS Management Console. Alternatively, you can use the API tools, you can list the reservations available for purchase with the DescribeReservedDBInstancesOfferings API method and then purchase a DB Instance reservation by calling the PurchaseReservedDBInstancesOffering method.

Creating a Reserved Instance is no different than launching an On-Demand Instance. You simply use the rds-create-db-instance command, the CreateDBInstance API, or select the Launch DB Instance option from the AWS Management Console, specifying the DB Instance class and Region for which you made the reservation. So long as your reservation purchase was successful, Amazon RDS will apply the reduced hourly rate for which you are eligible to the new DB Instance.

Q: Will there always be reservations available for purchase?

Yes. Reserved Instances are purchased for the Region rather than for the Availability Zone. This means that even if capacity is limited in one Availability Zone, reservations can still be purchased in that Region and used in a different Availability Zone within that Region.

Q: How many Reserved Instances can I purchase?

You can purchase up to 20 Reserved DB Instances. If you wish to run more than 20 DB Instances please complete the Amazon RDS DB Instance request form.

Q: What if I have an existing DB Instance that I’d like to convert to a Reserved Instance?

Simply purchase a DB Instance reservation with the same DB Instance class, DB Engine and License Model within the same Region as the DB Instance you are currently running and would like to reserve. If the reservation purchase is successful, Amazon RDS will automatically apply your new hourly usage charge to your existing DB Instance.

Q: If I sign up for a Reserved Instance, when does the term begin? What happens to my DB Instance when the term ends?

Pricing changes associated with a Reserved Instance are activated once your request is received while the payment authorization is processed. You can follow the status of your reservation on the AWS Account Activity page or by using the DescribeReservedDBInstances API. If the one-time payment cannot be successfully authorized by the next billing period, the discounted price will not take effect.

When your reservation term expires, your Reserved Instance will revert to the appropriate On-Demand hourly usage rate for your DB Instance class and Region.

Q: How do I control which DB Instances are billed at the Reserved Instance rate?

The Amazon RDS APIs for creating, modifying, and deleting DB Instances do not distinguish between On-Demand and Reserved Instances so that you can seamlessly use both. When computing your bill, our system will automatically apply your Reservation(s), such that all eligible DB Instances are charged at the lower hourly Reserved DB Instance rate.

Q: If I scale my Reserved Instance class up or down, what happens to my reservation?

Each reservation is associated with the following set of attributes: DB Engine, DB Instance class, Deployment type, License Model and Region. Each reservation can only be applied to a DB Instance with the same attributes for the duration of the term. If you decide to modify any of these attributes of your running DB Instance class before the end of the reservation term, your hourly usage rates for that DB Instance will revert to on demand hourly rates. If you later modify the running DB Instance's attributes to match those of the original reservation, or create a new DB Instance with the same attributes as your original reservation, your reserved pricing will be applied to it until the end of your reservation term.

Q: Can I move a Reserved Instance from one Region or Availability Zone to another?

Each Reserved Instance is associated with a specific Region, which is fixed for the lifetime of the reservation and cannot be changed. Each reservation can, however, be used in any of the available AZs within the associated Region.

Q: Are Reserved Instances available for Multi-AZ Deployments?

Yes. When you call the DescribeReservedDBInstancesOfferings API, simply look for the Multi-AZ options listed among the DB Instance configurations available for purchase. If you want to purchase a reservation for a DB Instance with synchronous replication across multiple Availability Zones, specify one of these offerings in your PurchaseReservedDBInstancesOffering call.

Q: Are Reserved Instances available for Read Replicas?

A standard DB Instance reservation can also be applied to a Read Replica, provided the DB Instance class and Region are the same. When computing your bill, our system will automatically apply your Reservation(s), such that all eligible DB Instances are charged at the lower hourly Reserved Instance rate.

Q: Can I cancel a reservation?

The one-time payment for Reserved Instances is not refundable. However, you can choose to terminate your DB Instance at any time, at which point you will not incur any hourly usage charges.

Q: Can I exchange my existing Reserved Instances for the lower priced Reserved Instances that came out on March 5, 2012?

Generally, Reserved Instances are non-refundable. However, as a special exception, if you have purchased a 1-year Reserved Instance in the past 30 days or a 3-year Reserved Instance in the past 90 days, you can exchange it for one of the new Reserved Instances. When exchanging a Reserved Instance, upfront fees will be refunded on a pro-rata basis and hourly fees for instance-hours already used will not be refunded. If you would like to exchange a Reserved Instance for one of the new ones, please contact us.

Hardware and Scaling

Q: How do I determine which initial DB Instance class and storage capacity are appropriate for my needs?

In order to select your initial DB Instance class and storage capacity, you will want to assess your application’s compute, memory and storage needs. For more guidelines on picking the right DB Instance class and storage capacity, please refer to the Amazon RDS DB Instance Sizing Guide.

Q: How do I scale the compute resources and/or storage capacity associated with my Amazon RDS Database Instance?

You can scale the compute resources and storage capacity allocated to your DB Instance with the ModifyDBInstance API or the AWS Management Console (selecting the desired DB Instance and clicking the “Modify” button). Memory and CPU resources are modified by changing your DB Instance class, and storage available is changed when you modify your storage allocation. Please note that when you modify your DB Instance class or allocated storage, your requested changes will be applied during your specified maintenance window. Alternately, you can use the “apply-immediately” flag to apply your scaling requests immediately. Bear in mind that any other pending system changes will be applied as well.

Monitor the compute and storage resource utilization of your DB Instance, for no additional charge, via Amazon CloudWatch. You can access metrics such as CPU utilization, storage utilization, and network traffic by clicking the “Monitoring” tab for your DB Instance in the AWS Management Console or using the Amazon CloudWatch APIs. To learn more about monitoring your active DB Instances, read the Amazon RDS Monitoring Guide.

Please note that for SQL Server, because of the extensibility limitations of striped storage attached to a Windows Server environment, Amazon RDS does not currently support increasing storage. While we plan to support this functionality in the future, we recommend you to provision storage based on anticipated future storage growth. In the interim, if you need to increase the storage of a SQL Server DB Instance, you will need to export the data, create a new DB Instance with increased storage, and import the data into it. Please refer to the data import guide for SQL Server for more information.

Q: What is the hardware configuration for Amazon RDS Standard storage?

Amazon RDS uses EBS volumes for database and log storage. Depending on the size of storage requested, Amazon RDS automatically stripes across multiple EBS volumes to enhance IOPS performance. For MySQL and Oracle, for an existing DB Instance, you may observe some I/O capacity improvement if you scale up your storage. You can scale the storage capacity allocated to your DB Instance using the AWS Management Console or the ModifyDBInstance API.

However, for SQL Server, because of the extensibility limitations of striped storage attached to a Windows Server environment, Amazon RDS does not currently support increasing storage.

Q: Will my DB Instance remain available during scaling?

The storage capacity allocated to your DB Instance can be increased while maintaining DB Instance availability. However, when you decide to scale the compute resources available to your DB Instance up or down, your database will be temporarily unavailable while the DB Instance class is modified. This period of unavailability typically lasts only a few minutes, and will occur during the maintenance window for your DB Instance, unless you specify that the modification should be applied immediately.

Q: How can I scale my DB Instance beyond the largest DB Instance class and maximum storage capacity?

Amazon RDS supports a variety of DB Instance classes and storage allocations to meet different application needs. If your application requires more compute resources than the largest DB Instance class or more storage than the maximum allocation, you can implement partitioning, thereby spreading your data across multiple DB Instances.

Q: What is Amazon RDS Provisioned IOPS?

Amazon RDS Provisioned IOPS is a storage option designed to deliver fast, predictable, and consistent I/O performance. With Amazon RDS Provisioned IOPS, you specify an IOPS rate when creating a DB Instance, and Amazon RDS provisions that IOPS rate for the lifetime of the DB Instance. Amazon RDS Provisioned IOPS is optimized for I/O-intensive, transactional (OLTP) database workloads. For more details, please see the Amazon RDS User Guide.

Q: What are the minimum and maximum IOPS supported by Amazon RDS?

The IOPS supported by Amazon RDS varies by database engine. For more details, please see the Amazon RDS User Guide.

Q: When should I choose Provisioned IOPS over Standard RDS storage?

You should choose Provisioned IOPS storage if you need consistent performance and have database workloads that generate largely random I/O. Provisioned IOPS is ideal for production online transaction processing (OLTP) workloads. We recommend Provisioned IOPS, along with Multi-AZ, for your production, OLTP database workloads. For more details, please see the Amazon RDS User Guide.

Automated Backups and Database Snapshots

Q: What is the difference between automated backups and DB Snapshots?

Amazon RDS provides two different methods for backing up and restoring your DB Instance(s) automated backups and database snapshots (DB Snapshots).

The automated backup feature of Amazon RDS enables point-in-time recovery of your DB Instance. When automated backups are turned on for your DB Instance, Amazon RDS automatically performs a full daily snapshot of your data (during your preferred backup window) and captures transaction logs (as updates to your DB Instance are made). When you initiate a point-in-time recovery, transaction logs are applied to the most appropriate daily backup in order to restore your DB Instance to the specific time you requested. Amazon RDS retains backups of a DB Instance for a limited, user-specified period of time called the retention period, which by default is one day but can be set to up to thirty five days. You can initiate a point-in-time restore and specify any second during your retention period, up to the Latest Restorable Time. You can use the DescribeDBInstances API to return the latest restorable time for you DB Instance(s), which is typically within the last five minutes. Alternatively, you can find the Latest Restorable Time for a DB Instance by selecting it in the AWS Management Console and looking in the “Description” tab in the lower panel of the Console.

DB Snapshots are user-initiated and enable you to back up your DB Instance in a known state as frequently as you wish, and then restore to that specific state at any time. DB Snapshots can be created with the AWS Management Console or CreateDBSnapshot API and are kept until you explicitly delete them with the Console or DeleteDBSnapshot API.

The snapshots which Amazon RDS performs for enabling automated backups are available to you for copying (using the AWS console or the rds-copy-db-snapshot command)or for the snapshot restore functionality. You can identify them using the "automated" Snapshot Type. In addition, you can identify the time at which the snapshot has been taken by viewing the "Snapshot Created Time" field. Alernatively, the identifier of the "automated" snapshots also contains the time (in UTC) at which the snapshot has been taken.

Please note: When you perform a restore operation to a point in time or from a DB Snapshot, a new DB Instance is created with a new endpoint (the old DB Instance can be deleted with the AWS Management Console or DeleteDBInstance API, if so desired). This is done to enable you to create multiple DB Instances from a specific DB Snapshot or point in time.

Q: Do I need to enable backups for my DB Instance or is it done automatically?

By default and at no additional charge, Amazon RDS enables automated backups of your DB Instance with a 1 day retention period. Free backup storage is limited to the size of your provisioned database and only applies to active DB Instances. For example, if you have 10GB-months of provisioned database storage, we will provide at most 10GB-months of backup storage at no additional charge. If you would like to extend your backup retention period beyond one day, you can do so using the CreateDBInstance API (when creating a new DB Instance) or ModifyDBInstance API (for an existing DB Instance). You can use these APIs to change the RetentionPeriod parameter from 1 to the desired number of days. For more information on automated backups, please refer to the Amazon RDS Developer Guide.

Q: What is a backup window and why do I need it? Is my database available during the backup window?

The preferred backup window is the user-defined period of time during which your DB Instance is backed up. Amazon RDS uses these periodic data backups in conjunction with your transaction logs to enable you to restore your DB Instance to any second during your retention period, up to the LatestRestorableTime (typically up to the last five minutes). During the backup window, storage I/O may be suspended while your data is being backed up. This I/O suspension typically lasts a few minutes at most. This I/O suspension is avoided with Multi-AZ DB deployments, since the backup is taken from the standby.

Q: Where are my automated backups and DB Snapshots stored and how do I manage their retention?

Amazon RDS DB snapshots and automated backups are stored in S3.

You can use the AWS Management Console or ModifyDBInstance API to manage the period of time your automated backups are retained by modifying the RetentionPeriod parameter. If you desire to turn off automated backups altogether, you can do so by setting the retention period to 0 (not recommended). You can manage your user-created DB Snapshots via the DB Snapshots section of the AWS Management Console. Alternatively, you can see a list of the user-created DB Snapshots for a given DB Instance using the DescribeDBSnapshots API and delete snapshots with the DeleteDBSnapshot API.

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

When you delete a DB Instance, you can create a final DB Snapshot upon deletion; if you do, you can use this DB Snapshot to restore the deleted DB Instance at a later date. Amazon RDS retains this final user-created DB Snapshot along with all other manually created DB Snapshots after the DB Instance is deleted. Refer to the pricing page for details of backup storage costs.

Automated backups are deleted when the DB Instance is deleted. Only manually created DB Snapshots are retained after the DB Instance is deleted.

Security

Q: What is Amazon Virtual Private Cloud (VPC) and why may I want to use with Amazon RDS?

Amazon VPC lets you create a virtual networking environment in a private, isolated section of the Amazon Web Services (AWS) cloud, where you can exercise complete control over aspects such as private IP address ranges, subnets, routing tables and network gateways. With Amazon VPC, you can define a virtual network topology and customize the network configuration to closely resemble a traditional IP network that you might operate in your own datacenter.

One of the scenarios where you may want to use Amazon RDS in VPC is if you want to run a public-facing web application, while still maintaining non-publicly accessible backend servers in a private subnet. You can create a public-facing subnet for your webservers that has access to the Internet, and place your backend RDS DB Instances in a private-facing subnet with no Internet access. For more information about Amazon VPC, refer to the Amazon Virtual Private Cloud User Guide.

Q: How is using Amazon RDS inside a VPC different from using it outside?

The basic functionality of Amazon RDS is the same regardless of whether VPC is used. Amazon RDS manages backups, software patching, automatic failure detection, read replicas and recovery whether your DB Instances are deployed inside or outside a VPC.

Amazon RDS DB Instances deployed outside a VPC are assigned an external IP address (to which the Endpoint/DNS Name resolves) that provides connectivity from EC2 or the Internet. In Amazon VPC, Amazon RDS DB instances only have a private IP address (within a subnet that you define).

Q: What is a DB Subnet Group and why do I need one?

A DB Subnet Group is a collection of subnets that you may want to designate for your RDS DB Instances in a VPC. Each DB Subnet Group should have at least one subnet for every Availability Zone in a given Region. When creating a DB Instance in VPC, you will need to select a DB Subnet Group. Amazon RDS then uses that DB Subnet Group and your preferred Availability Zone to select a subnet and an IP address within that subnet. Amazon RDS creates and associates an Elastic Network Interface to your DB Instance with that IP address.

Please note that, we strongly recommend you use the DNS Name to connect to your DB Instance as the underlying IP address can change (e.g., during a failover).

For Multi-AZ deployments, defining a subnet for all Availability Zones in a Region will allow Amazon RDS to create a new standby in another Availability Zone should the need arise. You need to do this even for Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.

Q: How do I create an Amazon RDS DB Instance in VPC?

For a walk through example of creating a DB Instance in VPC, refer to the Amazon RDS User Guide.

Following are the pre-requisites necessary to create a DB Instances within a VPC:

• You need to have a VPC set up with at least one subnet created in every Availability Zone in the Region you want to deploy your DB Instance. For information on creating Amazon VPC and subnets refer to the Getting Started Guide for Amazon VPC.
• You need to have a DB Subnet Group defined for your VPC.
• You need to have a DB Security Group defined for your VPC (or you can use the default provided).
• In addition, you should allocate adequately large CIDR blocks to each of your subnets so that there are enough spare IP addresses for Amazon RDS to use during maintenance activities including scale compute and failover etc.

Q: How do I control network access to my DB Instance(s)?

Visit the Security Groups section of the Amazon RDS User Guide to learn about the different ways to control access to your DB Instances.

Q: How do I secure Amazon RDS DB Instances running within my VPC?

VPC Security Groups can be used to help secure DB Instances within an Amazon VPC. In addition, network traffic entering and exiting each subnet can be allowed or denied via network Access Control Lists (ACLs). All network traffic entering or exiting your VPC via your IPsec VPN connection can be inspected by your on-premise security infrastructure, including network firewalls, intrusion detection and prevention systems.

Q: How do I connect to an RDS DB Instance in VPC?

DB Instances deployed within a VPC can be accessed by EC2 Instances deployed in the same VPC. If these EC2 Instances are deployed in a public subnet with associated Elastic IPs, you can access the EC2 Instances via the internet.

DB Instances deployed within a VPC can be accessed from the Internet or from EC2 Instances outside the VPC via VPN or bastion hosts that you can launch in your public subnet, or using Amazon RDS's Publicly Accessible option:

• To use a bastion host, you will need to set up a public subnet with an EC2 instance that acts as a SSH Bastion. This public subnet must have an internet gateway and routing rules that allow traffic to be directed via the SSH host, which must then forward requests to the private IP address of your RDS DB instance.
• To use public connectivity, simply create your DB Instances with the Publicly Accessible option set to yes. With Publicly Accessible active, your DB Instances within a VPC will be fully accessible outside your VPC by default. This means you do not need to configure a VPN or bastion host to allow access to your instances.

You can also set up a VPN Gateway that extends your corporate network into your VPC, and allows access to the RDS DB instance in that VPC. Refer to the Amazon VPC User Guide for more details.

We strongly recommend you use the DNS Name to connect to your DB Instance as the underlying IP address can change (e.g., during failover).

Q: Can I move my existing DB instances outside VPC into my VPC?

You can take a snapshot of your DB Instance outside VPC and restore it to VPC by specifying the DB Subnet Group you want to use. Alternatively, you can perform a “Restore to Point in Time” operation as well.

Q: Can I move my existing DB instances from inside VPC to outside VPC?

Currently, direct migration of DB Instances from inside to outside VPC is not supported. For security reasons, a DB Snapshot of a DB Instance inside VPC cannot be restored to outside VPC. The same is true with “Restore to Point in Time” functionality. If you need to move your DB Instance from inside to outside VPC, you will need to export your data from your source DB Instance in your VPC to your target DB Instance deployed outside VPC.

Q: What precautions should I take to ensure that my DB Instances in VPC are accessible by my application?

You are responsible for modifying routing tables and networking ACLs in your VPC to ensure that your DB instance is reachable from your client instances in the VPC.

For Multi-AZ deployments, after a failover, your client EC2 instance and RDS DB Instance may be in different Availability Zones. You should configure your networking ACLs to ensure that cross-AZ communication is possible.

Q: Can I change the DB Subnet Group of my DB Instance?

An existing DB Subnet Group can be updated to add more subnets either for existing Availability Zones are for new Availability Zones added since the creation of the DB Instance. However, changing the DB Subnet Group of a deployed DB instance is not currently allowed.

Q: What is an Amazon RDS master user account and how is it different from an AWS account?

To begin using Amazon RDS you will need an AWS developer account. If you do not have one prior to signing up for Amazon RDS, you will be prompted to create one when you begin the sign-up process. A master user account is different from an AWS developer account and used only within the context of Amazon RDS to control access to your DB Instance(s). The master user account is a native database user account which you can use to connect to your DB Instance. You can specify the master user name and password you want associated with each DB Instance when you create the DB Instance. Once you have created your DB Instance, you can connect to the database using the master user credentials. Subsequently, you may also want to create additional user accounts so that you can restrict who can access your DB Instance.

Q: What privileges are granted to the master user for my DB Instance?

For MySQL, the default privileges for the master user include: create, drop, references, event, alter, delete, index, insert, select, update, create temporary tables, lock tables, trigger, create view, show view, alter routine, create routine, execute, trigger, create user, process, show databases, grant option.

For Oracle, the master user is granted the "dba" role. The master user inherits most of the privileges associated with the role. Please refer to the Amazon RDS User Guide for the list of restricted privileges and the corresponding alternatives to perform administrative tasks that may require these privileges.

For SQL Server, a user that creates a database is granted the "db_owner" role. Please refer to the Amazon RDS User Guide for the list of restricted privileges and the corresponding alternatives to perform administrative tasks that may require these privileges.

Q: Is there anything different about user management with Amazon RDS?

No, everything works the way you are familiar with when using a relational database you manage yourself.

Q: Can programs running on servers in my own data center access Amazon RDS databases?

Yes. You have to intentionally turn on the ability to access your database over the internet by configuring Security Groups. You can authorize access for only the specific IPs, IP ranges, or subnets corresponding to servers in your own data center.

Q: Can I encrypt connections between my application and my DB Instance using SSL?

Yes, however, this option is currently only supported for the MySQL and SQL Server engines.

Amazon RDS generates an SSL certificate for each DB Instance. For details on establishing an encrypted connection with Amazon RDS, please visit the Amazon RDS MySQL User Guide and SQL Server User Guide. Once an encrypted connection is established, data transferred between the DB Instance and your application will be encrypted during transfer. If you require your data to be encrypted while “at rest” in the database, your application must manage the encryption and decryption of data. Also note that SSL support within Amazon RDS is for encrypting the connection between your application and your DB Instance; it should not be relied on for authenticating the DB Instance itself.

While SSL offers security benefits, be aware that SSL encryption is a compute intensive operation and will increase the latency of your database connection. To learn more about how SSL works with MySQL or SQL Server, you can refer directly to the MySQL documentation found here or the MSDN SQL Server documentation found here.

Q: Can I require my DB instance to only accept encrypted connections?

For MySQL, after connecting to the DB Instance with the master username and password, you can use the GRANT statement to require SSL connections for specific users accounts. For example, you can use the following statement to require SSL connections on the user account encrypted_user:

GRANT USAGE ON *.* TO ‘encrypted_user’@’%’ REQUIRE SSL

DB Parameter Groups

Q: How do I choose the right configuration parameters for my DB Instance(s)?

Amazon RDS by default chooses the optimal configuration parameters for your DB Instance taking into account the DB Instance’s compute resource and storage capacity. However, if you want to change them, you can do so using our configuration management APIs. Please note that changing configuration parameters from recommended values can have unintended effects, ranging from degraded performance to system crashes, and should only be attempted by advanced users who wish to assume these risks. For more information on changing parameters, please refer to the Amazon RDS User Guide.

Q: What are DB Parameter groups? How are they helpful?

A database parameter group (DB Parameter Group) acts as a “container” for engine configuration values that can be applied to one or more DB Instances. If you create a DB Instance without specifying a DB Parameter Group, a default DB Parameter Group is used. This default group contains engine defaults and Amazon RDS system defaults optimized for the DB Instance you are running. However, if you want your DB Instance to run with your custom-specified engine configuration values, you can simply create a new DB Parameter Group, modify the desired parameters, and modify the DB Instance to use the new DB Parameter Group. Once associated, all DB Instances that use a particular DB Parameter Group get all the parameter updates to that DB Parameter Group. For more information on configuring DB Parameter Groups, please read the DB Parameter Group Deployment Guide.

Q: How do I see the current setting for my parameters for a given RDS DB Parameter Group?

You can use the AWS Management Console, Amazon RDS APIs, or Command Line Tools to see information about your DB Parameter Groups and their corresponding parameter settings.

Replication

Q: What types of replication does Amazon RDS support and when should I use each?

Amazon RDS supports MySQL, Oracle and SQL Server database engines. A customer can chose the database engine that best meets their requirements.

Amazon RDS provides two distinct replication options to serve different purposes.

If you are looking to use replication to increase database availability while protecting your latest database updates against unplanned outages, consider running your DB Instance as a Multi-AZ deployment. When you create or modify your DB Instance to run as a Multi-AZ deployment, Amazon RDS will automatically provision and manage a “standby” replica in a different Availability Zone (independent infrastructure in a physically separate location). In the event of planned database maintenance, DB Instance failure, or an Availability Zone failure, Amazon RDS will automatically failover to the standby so that database operations can resume quickly without administrative intervention. Multi-AZ deployments utilize synchronous replication, making database writes concurrently on both the primary and standby so that the standby will be up-to-date in the event a failover occurs. While our technological implementation for Multi-AZ DB Instances maximizes data durability in failure scenarios, it precludes the standby from being accessed directly or used for read operations. The fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments; to learn more about Multi-AZ deployments, please visit this FAQ section. Multi-AZ deployments are currently supported for the MySQL and Oracle database engines.

If you are looking to take advantage of MySQL’s built-in replication to scale beyond the capacity constraints of a single DB Instance for read-heavy database workloads, Amazon RDS for MySQL makes it easier with Read Replicas. You can create a Read Replica of a given “source” DB Instance using the AWS Management Console or CreateDBInstanceReadReplica API. Once the Read Replica is created, database updates on the source DB Instance will be propagated to the Read Replica. You can create multiple Read Replicas for a given source DB Instance and distribute your application’s read traffic amongst them. Unlike Multi-AZ deployments, Read Replicas use MySQL’s built-in replication and are subject to its strengths and limitations. In particular, updates are applied to your Read Replica(s) after they occur on the source DB Instance (“asynchronous” replication), and replication lag can vary significantly. This means recent database updates made to a standard (non Multi-AZ) source DB Instance may not be present on associated Read Replicas in the event of an unplanned outage on the source DB Instance. As such, Read Replicas do not offer the same data durability benefits as Multi-AZ deployments. While Read Replicas can provide some read availability benefits, they and are not designed to improve write availability. Read Replicas are currently supported for Amazon RDS for MySQL.

With Amazon RDS for MySQL, you can use Multi-AZ deployments and Read Replicas in conjunction to enjoy the complementary benefits of each. You can simply specify that a given Multi-AZ deployment is the source DB Instance for your Read Replica(s). That way you gain both the data durability and availability benefits of Multi-AZ deployments and the read scaling benefits of Read Replicas.

Multi-AZ Deployments

Q: What does it mean to run a DB Instance as a Multi-AZ deployment?

When you create or modify your DB Instance to run as a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous “standby” replica in a different Availability Zone. Updates to your DB Instance are synchronously replicated across Availability Zones to the standby in order to keep both in sync and protect your latest database updates against DB Instance failure. During certain types of planned maintenance, or in the unlikely event of DB Instance failure or Availability Zone failure, Amazon RDS will automatically failover to the standby so that you can resume database writes and reads as soon as the standby is promoted. Since the name record for your DB Instance remains the same, you application can resume database operation without the need for manual administrative intervention. With Multi-AZ deployments, replication is transparent: you do not interact directly with the standby, and it cannot be used to serve read traffic. If you are using Amazon RDS for MySQL and are looking to scale read traffic beyond the capacity constraints of a single DB Instance, you can deploy one or more Read Replicas .

Q: What is an Availability Zone?

Availability Zones are distinct locations within a Region that are engineered to be isolated from failures in other Availability Zones. Each Availability Zone runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. Common points of failures like generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados or flooding would only affect a single Availability Zone. Availability Zones within the same Region benefit from low-latency network connectivity.

Q: What do “primary” and “standby” mean in the context of a Multi-AZ deployment?

When you run a DB Instance as a Multi-AZ deployment, the “primary” serves database writes and reads. In addition, Amazon RDS provisions and maintains a “standby” behind the scenes, which is an up-to-date replica of the primary. The standby is “promoted” in failover scenarios. After failover, the standby becomes the primary and accepts your database operations. You do not interact directly with the standby (e.g. for read operations) at any point prior to promotion. If you are interested in scaling read traffic beyond the capacity constraints of a single DB Instance, please see the FAQs on Read Replicas.

Q: What are the benefits of a Multi-AZ deployment?

The chief benefits of running your DB Instance as a Multi-AZ deployment are enhanced database durability and availability. The increased availability and fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments.

Running your DB Instance as a Multi-AZ deployment safeguards your data in the unlikely event of a DB Instance component failure or loss of availability in one Availability Zone. For example, if a storage volume on your primary fails, Amazon RDS automatically initiates a failover to the standby, where all of your database updates are intact. This provides additional data durability relative to standard deployments in a single AZ, where a user-initiated restore operation would be required and updates that occurred after the latest restorable time (typically within the last five minutes) would not be available.

You also benefit from enhanced database availability when running your DB Instance as a Multi-AZ deployment. If an Availability Zone failure or DB Instance failure occurs, your availability impact is limited to the time automatic failover takes to complete (typically three to six minutes). The availability benefits of Multi-AZ also extend to planned maintenance. For example, with automated backups, I/O activity is no longer suspended on your primary during your preferred backup window, since backups are taken from the standby. In the case of patching or DB Instance class scaling, these operations occur first on the standby, prior to automatic fail over. As a result, your availability impact is limited to the time required for automatic failover to complete.

Another implied benefit of running your DB Instance as a Multi-AZ deployment is that DB Instance failover is automatic and requires no administration. In an Amazon RDS context, this means you are not required to monitor DB Instance events and initiate manual DB Instance recovery (via the RestoreDBInstanceToPointInTime or RestoreDBInstanceFromSnapshot APIs) in the event of an Availability Zone failure or DB Instance failure.

Q: Are there any performance implications of running my DB Instance as a Multi-AZ deployments?

You may observe elevated latencies relative to a standard DB Instance deployment in a single Availability Zone as a result of the synchronous data replication performed on your behalf.

Q: When running my DB Instance as a Multi-AZ deployment, can I use the standby for read or write operations?

No, the standby replica cannot serve read requests. Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits. As such, the feature uses synchronous replication between primary and standby. Our implementation makes sure the primary and the standby are constantly in sync, but precludes using the standby for read or write operations. If you are interested in a read scaling solution, please see the FAQs on Read Replicas .

Q: How do I set up a Multi-AZ DB Instance deployment?

In order to create a Multi-AZ DB Instance deployment, simply click the “Yes” option for “Multi-AZ Deployment” when launching a DB Instance with the AWS Management Console. Alternatively, if you are using the Amazon RDS APIs, you would call the CreateDBInstance API and set the “Multi-AZ” parameter to the value “true.” To convert an existing standard (single AZ) DB Instance to Multi-AZ, modify the DB Instance in the AWS Management Console or use the ModifyDBInstance API and set the Multi-AZ parameter to true.

Q: What events would cause Amazon RDS to initiate a failover to the standby replica?

Amazon RDS detects and automatically recovers from the most common failure scenarios for Multi-AZ deployments so that you can resume database operations as quickly as possible without administrative intervention. Amazon RDS automatically performs a failover in the event of any of the following:

• Loss of availability in primary Availability Zone
• Loss of network connectivity to primary
• Compute unit failure on primary
• Storage failure on primary

Note: When operations such as DB Instance scaling or system upgrades like OS patching are initiated for Multi-AZ deployments, for enhanced availability, they are applied first on the standby prior to an automatic failover. As a result, your availability impact is limited only to the time required for automatic failover to complete. Note that Amazon RDS Multi-AZ deployments do not failover automatically in response to database operations such as long running queries, deadlocks or database corruption errors.

Q: Will I be alerted when automatic failover occurs?

Yes, Amazon RDS will emit a DB Instance event to inform you that automatic failover occurred. You can use the DescribeEvents to return information about events related to your DB Instance, or click the “DB Events” section of the AWS Management Console.

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

Failover is automatically handled by Amazon RDS so that you can resume database operations as quickly as possible without administrative intervention. When failing over, Amazon RDS simply flips the canonical name record (CNAME) for your DB Instance to point at the standby, which is in turn promoted to become the new primary. We encourage you to follow best practices and implement database connection retry at the application layer. Failover times are a function of the time it takes crash recovery to complete. Start-to-finish, failover typically completes within three to six minutes.

Q: Can I initiate a “forced failover” for my Multi-AZ DB Instance deployment?

Amazon RDS will automatically failover without user intervention under a variety of failure conditions. In addition, Amazon RDS provides an option to initiate a failover when rebooting your instance. You can access this feature via the AWS Management Console or when using the RebootDBInstance API call.

Q: How do I control/configure Multi-AZ synchronous replication?

With Multi-AZ deployments, you simply set the “Multi-AZ” parameter to true. The creation of the standby, synchronous replication, and failover are all handled automatically. This means you cannot select the Availability Zone your standby is deployed in or alter the number of standbys available (Amazon RDS provisions one dedicated standby per DB Instance primary). The standby also cannot be configured to accept database read activity (click here for more details).

Q: Will my standby be in the same Region as my primary?

Yes. Your standby is automatically provisioned in a different Availability Zone of the same Region as your DB Instance primary.

Q: Can I see which Availability Zone my primary is currently located in?

Yes, you can gain visibility into the location of the current primary by using the AWS Management Console or DescribeDBInstances API.

Q: After failover, my primary is now located in a different Availability Zone than my other AWS resources (e.g. EC2 instances). Should I be concerned about latency?

Availability Zones are engineered to provide low latency network connectivity to other Availability Zones in the same Region. In addition, you may want to consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone failure. Multi-AZ deployments address this need for the database tier without administration on your part.

Q: How do DB Snapshots and automated backups work with my Multi-AZ deployment?

You interact with automated backup and DB Snapshot functionality in the same way whether you are running a standard deployment in a Single-AZ or Multi-AZ deployment. If you are running a Multi-AZ deployment, automated backups and DB Snapshots are simply taken from the standby to avoid I/O suspension on the primary. Please note that you may experience increased I/O latency (typically lasting a few minutes) during backups for both Single-AZ and Multi-AZ deployments.

Initiating a restore operation (point-in-time restore or restore from DB Snapshot) also works the same with Multi-AZ deployments as standard, Single-AZ deployments. New DB Instance deployments can be created with either the RestoreDBInstanceFromSnapshot or RestoreDBInstanceToPointInTime APIs. These new DB Instance deployments can be either standard or Multi-AZ, regardless of whether the source backup was initiated on a standard or Multi-AZ deployment.

MySQL

Read Replicas

Q: What does it mean to run a DB Instance as a Read Replica?

Read Replicas make it easy to take advantage of MySQL’s built-in replication functionality to elastically scale out beyond the capacity constraints of a single DB Instance for read-heavy database workloads. You can create a Read Replica with a few clicks of the AWS Management Console or using the CreateDBInstanceReadReplica API. Once the Read Replica is created, database updates on the source DB Instance will be replicated using MySQL’s native, asynchronous replication. You can create multiple Read Replicas for a given source DB Instance and distribute your application’s read traffic amongst them. Since Read Replicas use MySQL’s built-in replication, they are subject to its strengths and limitations. In particular, updates are applied to your Read Replica(s) after they occur on the source DB Instance, and replication lag can vary significantly. Read Replicas can be associated with Multi-AZ deployments to gain read scaling benefits in addition to the enhanced database write availability and data durability provided by Multi-AZ deployments .

Q: When would I want to consider using an Amazon RDS Read Replica?

There are a variety of scenarios where deploying one or more Read Replicas for a given source DB Instance may make sense. Common reasons for deploying a Read Replica include:

• Scaling beyond the compute or I/O capacity of a single DB Instance for read-heavy database workloads. This excess read traffic can be directed to one or more Read Replicas.
• Serving read traffic while the source DB Instance is unavailable. If your source DB Instance cannot take I/O requests (e.g. due to I/O suspension for backups or scheduled maintenance), you can direct read traffic to your Read Replica(s). For this use case, keep in mind that the data on the Read Replica may be “stale” since the source DB Instance is unavailable.
• Business reporting or data warehousing scenarios; you may want business reporting queries to run against a Read Replica, rather than your primary, production DB Instance.

Q: Which storage engines are supported for use with Read Replicas?

Read Replicas require a transactional storage engine and are only supported for the InnoDB storage engine.

Non-transactional engines such as MyISAM might prevent Read Replicas from working as intended. However, if you still choose to use MyISAM with Read Replicas, we advise you to watch the Amazon CloudWatch “Replica Lag” metric (available via the AWS Management Console or Amazon CloudWatch APIs) carefully and recreate the Read Replica should it fall behind due to replication errors. The same considerations apply to the use of temporary tables and any other non-transactional engines.

Q: How do I deploy a Read Replica for a given DB Instance?

You can create a Read Replica in minutes using the standard CreateDBInstanceReadReplica API or a few clicks of the Amazon RDS Management Console. When creating a Read Replica, you can identify it as a Read Replica by specifying a SourceDBInstanceIdentifier. The SourceDBInstanceIdentifier is the DB Instance Identifier of the “source” DB Instance from which you wish to replicate. As with a standard DB Instance, you can also specify the Availability Zone, DB Instance class, and preferred maintenance window. The MySQL version (e.g. MySQL 5.1.50) and storage allocation of a Read Replica is inherited from the source DB Instance. When you initiate the creation of a Read Replica, Amazon RDS takes a snapshot of your source DB Instance and begins replication. As a result, you will experience a brief I/O suspension on your source DB Instance as the snapshot occurs. The I/O suspension typically lasts on the order of one minute,, and is avoided if the source DB Instance is a Multi-AZ deployment (in the case of Multi-AZ deployments, snapshots are taken from the standby). Amazon RDS is also currently working on an optimization (to be released shortly) such that if you create multiple Read Replicas within a 30 minute window, all of them will use the same source snapshot to minimize I/O impact (“catch-up” replication for each Read Replica will begin after creation).

Amazon RDS Read Replicas are as easy to delete as they are to create; simply use the Amazon RDS Management Console or call the DeleteDBInstance API (specifying the DBInstanceIdentifier for the Read Replica you wish to delete).

When requesting the creation of a Read Replica, here are a couple of additional things to consider:

• If you are using a non-transactional engine such as MyISAM, you will need to perform the following steps to successfully set up your Read Replica. These steps are required in order to ensure that the Read Replica has a consistent copy of your data. Note that these steps are not required if all of your tables use a transactional engine such as InnoDB. 1. Stop all DML and DDL operations on non-transactional tables and wait for them to complete. SELECT statements can continue running. 2. Flush and lock those tables. 3. Create the Read Replica using the CreateDBInstanceReadReplica API. 4. Check the progress of the Replica creation using the DescribeDBInstances API. Once the Replica is available unlock the tables and resume normal database operations.

• If there are any long running transactions on your source RDS instance, wait for them to complete before requesting creation of a Read Replica from that source.

Q: How do I connect to my Read Replica(s)?

You can connect to a Read Replica just as you would connect to a standard DB Instance, using the DescribeDBInstance API or AWS Management Console to retrieve the endpoint(s) for you Read Replica(s). If you have multiple Read Replicas, it is up to your application to determine how read traffic will be distributed amongst them.

Q: How many Read Replicas can I create for a given source DB Instance?

At this point in time, Amazon RDS allows you to create up to five (5) Read Replicas for a given source DB Instance.

Q: Can I use a Read Replica to enhance database write availability or protect the data on my source DB Instance against failure scenarios?

If you are looking to use replication to increase database write availability and protect recent database updates against various failure conditions, we recommend you run your DB Instance as a Multi-AZ deployment. With Read Replicas and MySQL’s native, asynchronous replication, database writes occur on a Read Replica after they have already occurred on the source DB Instance, and this replication “lag” can vary significantly. In contrast, the replication used by Multi-AZ deployments is synchronous, meaning that all database writes are concurrent on the primary and standby. This protects your latest database updates, since they should be available on the standby in the event a failover is required. In addition, with Multi-AZ deployments replication is fully managed. Amazon RDS automatically monitors for DB Instance failure conditions or Availability Zone failure and initiates automatic failover to the standby if an outage occurs.

Q: Can I create a Read Replica with a Multi-AZ DB Instance deployment as its source?

Since Multi-AZ DB Instances address a different need than Read Replicas, it makes sense to use the two in conjunction for production deployments and to associate a Read Replica with a Multi-AZ DB Instance deployment. The “source” Multi AZ-DB Instance provides you with enhanced write availability and data durability, and the associated Read Replica would improve read traffic scalability.

Q: If my Read Replica(s) use a Multi-AZ DB Instance deployment as a source, what happens if Multi-AZ failover occurs?

In the event of a Multi-AZ failover, any associated and available Read Replicas should automatically resume replication once failover has completed (acquiring updates from the newly promoted primary).

Q: My Read Replica appears “stuck” after a Multi-AZ failover and is unable to obtain or apply updates from the source DB Instance. What do I do?

You may find in some cases that your Read Replica(s) aren’t able to receive or apply updates from their source Multi-AZ DB Instance after a Mulit-AZ failover. This is because some MySQL binlog events were not flushed to disk at the time of the failover. After the failover, the Read Replica may ask for binlogs from the source that it doesn’t have. This loss of MySQL binlogs during a crash is described in the MySQL document here.

Of particular relevance to this issue is the paragraph near the bottom that describes the MySQL sync-binlog parameter. This parameter controls how MySQL binlogs are flushed to disk, and when using InnoDB, how the binlogs and InnoDB logs may be kept in sync.

To resolve the current issue, you will need to delete the Read Replica and create a new one to replace it. To avoid this issue in the future, setting sync-binlog=1 will greatly reduce the chance that MySQL binlogs needed by the Read Replica will be lost during a crash/failover scenario. As the MySQL documentation explains, even this doesn’t completely resolve the issue. To further reduce the likelihood of hitting this issue, set innodb_support_xa=1. Note that there may be a performance penalty for setting these variables. Both sync_binlog and innodb_support_xa are dynamic variables, so if you find that the performance penalty is too great, you can reset them without taking an outage.

This is ultimately a choice between performance and improving the automatic resynchronization of Read Replicas after a source Multi-AZ failover. One of the advantages of Amazon RDS Read Replicas is that they can be quickly re-instantiated when synchronization issues arise by deleting and re-creating them. As such, you don’t have to take the performance hit from setting sync-binlog and/or innodb_support_xa if manually dropping out of sync Read Replicas and re-creating them meets your needs.

Q: Can I create a Read Replica of another Read Replica?

Creating a Read Replica of another Read Replica is not supported.

Q: Can my Read Replicas only accept database read operations?

Read Replicas are designed to serve read traffic. However, there may be use cases where advanced users wish to complete Data Definition Language (DDL) SQL statements against a Read Replica. Examples might include adding a database index to a Read Replica that is used for business reporting, without adding the same index to the corresponding source DB Instance. If you wish to enable operations other than reads for a given Read Replica, you will need to modify the active DB Parameter Group for the Read Replica, setting the “read_only” parameter to “0.”

Q: Can I promote my Read Replica into a “standalone” DB Instance?

Yes. Refer to the Amazon RDS User Guide for more details.

Q: Will my Read Replica be kept up-to-date with its source DB Instance?

Updates to a source DB Instance will automatically be replicated to any associated Read Replicas. However, with MySQL’s asynchronous replication technology, a Read Replica can fall behind its source DB Instance for a variety of reasons. Typical reasons include:

• Write I/O volume to the source DB Instance exceeds the rate at which changes can be applied to the Read Replica (this problem is particularly likely to arise if the compute capacity of a Read Replica is less than the source DB Instance)
• Complex or long-running transactions to the source DB Instance hold up replication to the Read Replica
• Network partitions or latency between the source DB Instance and a Read Replica

Read Replicas are subject to the strengths and weaknesses of MySQL replication. If you are using Read Replicas, you should be aware of the potential for lag between a Read Replica and its source DB Instance, or “inconsistency”. Click here for guidance on what to do if your Read Replica(s) fall significantly behind its source.

Q: How do I gain visibility into active Read Replica(s)?

You can use the standard DescribeDBInstances API to return a list of all the DB Instances you have deployed (including Read Replicas), or simply click on the “DB Instances” tab of the Amazon RDS Management Console.

Amazon RDS allows you to gain visibility into how far a Read Replica has fallen behind its source DB Instance by issuing a standard “Show Slave Status” MySQL command against the Read Replica. The “Seconds_Behind_Master” data returned by “Show Slave Status” is also published as an Amazon CloudWatch metric (“Replica Lag”) available via the AWS Management Console or Amazon CloudWatch APIs.

Q: My Read Replica has fallen significantly behind its source DB Instance. What should I do?

As discussed in the previous questions, “inconsistency” or lag between a Read Replica and its source DB Instance is common with MySQL asynchronous replication. If an existing Read Replica has fallen too far behind to meet your requirements, you can delete it and create a new one with the same endpoint by using the same DB Instance Identifier and Source DB Instance Identifier as the deleted Read Replica. Keep in mind that the re-creation process will be counter-productive at small lag levels (e.g. under five minutes of lag), and should be used with prudence (i.e. only when the Read Replica is significantly behind its source DB Instance). Also keep in mind that replica lag may naturally grow and shrink over time, depending on your source DB Instance’s steady-state usage pattern.

Scaling the DB Instance class of a Read Replica may reduce replication lag in some cases, particularly if your source DB Instance class is larger than your Read Replica DB Instance class. However, Read Replicas are not guaranteed to work in all cases. There may be scenarios and usage patterns where a Read Replica can never catch up with its source after initial creation, or otherwise remains too far behind its source to meet your use case requirements.

Q: I scaled the compute and/or storage capacity of my source DB Instance, should I scale the resources for associated Read Replica(s) as well?

For replication to work effectively, we recommend that Read Replicas have as much or more compute and storage resources as their respective source DB Instances. Otherwise replication lag is likely to increase or your Read Replica may run out of space to store replicated updates.

Q: Can I configure the replication between my source DB Instance and a Read Replica to use row-based replication?

By default, replication is set to mixed-format (which includes both row-based and statement-based replication), which should meet the requirements of most use cases. However, if you are an advanced user and wish to designate that row-based replication is used, you can do so on a session basis by using a SQL command to set the binlog_format for a DB Instance to “row.” To learn more about the difference between mixed-format replication and row-based replication you can visit MySQL documentation here

Q: Can DB Snapshots or automated backups be taken of Read Replicas?

No. If you are looking to increase database write availability by taking backups from your Read Replica instead of its source DB Instance, you can accomplish the same objective by running your DB Instance as a Multi-AZ deployment. Backups will then be initiated from the Multi-AZ standby to minimize availability impact.

Q: How do I delete a Read Replica? Will it be deleted automatically if its source DB Instance is deleted?

You can easily delete a Read Replica with a few clicks of the AWS Management Console or by passing its DB Instance identifier to the DeleteDBInstance API. A Read Replica will stay active and continue accepting read traffic even after its corresponding source DB Instance has been deleted. If you desire to delete the Read Replica in addition to the source DB Instance, you must explicitly delete the Read Replica using the DeleteDBInstance API or AWS Management Console.

Q: Can I directly access the binary logs for my Database Instance to manage my own replication?

Amazon RDS does not currently provide access to the binary logs for your Database Instance.

Q: How much do Read Replicas cost? When does billing begin and end?

A Read Replica is billed as a standard DB Instance and at the same rates. Click here for more information on DB Instance billing visit this FAQ. Just like a standard DB Instance, the rate per “DB Instance hour” for a Read Replica is determined by the DB Instance class of the Read Replica – please see Amazon RDS detail page for up-to-date pricing. You are not charged for the data transfer incurred in replicating data between your source DB Instance and Read Replica. Billing for a Read Replica begins as soon as the Read Replica has been successfully created (i.e. when status is listed as “active”). The Read Replica will continue being billed at standard Amazon RDS DB Instance hour rates until you issue a command to delete it.

DB Engine Version Management

Q: Can I control if and when the MySQL version powering Amazon RDS DB Instance is upgraded to new supported versions?

Amazon RDS allows you to control if and when the relational database software powering your DB Instance (i.e. MySQL) is upgraded to new versions supported by Amazon RDS. This provides you with the flexibility to maintain compatibility with specific MySQL versions, test new versions with your application before deploying in production, and perform version upgrades on your own terms and timelines.

Unless you specify otherwise, your DB Instance will automatically be upgraded to new MySQL minor versions as they are supported by Amazon RDS. This patching will occur during your scheduled maintenance window, and will be announced on the Amazon RDS Forum in advance. If you wish to turn off automatic version upgrades, you can do so by setting the AutoMinorVersionUpgrade parameter to “false.” Since major version upgrades involve some compatibility risk, they will not occur automatically and must be initiated by you.

This approach to database software patching puts you in the driver’s seat of version upgrades, but still offloads the work of patch application to Amazon RDS. You can learn more about version management by reading the FAQ entires that follow. Alternatively, you can reference our Developer Guide.

While DB Engine version management functionality is intended to give you as much control as possible over how patching occurs, Amazon RDS reserves the right to patch your DB Instance on your behalf in the event of a critical security vulnerability in the database software.

Q: How do I specify which supported MySQL Version I would like my DB Instance to run?

You can specify any currently supported version (minor and/or major) when creating a new DB Instance via the CreateDBInstance API. You simply pass in the desired version to the EngineVersion parameter upon create; if no version is specified, Amazon RDS will default to a supported version, typically the most recent version. If a major version (e.g. MySQL 5.1) is specified but a minor version is not, Amazon RDS will default to a recent release of the major version you have specified. To see a list of supported versions, as well as defaults for newly created DB Instances, simply use the DescribeDBEngineVersions API.

If you have opted out of automatically scheduled upgrades by setting the AutoMinorVersionUpgrade parameter to false but wish to manually initiate an upgrade to a supported minor version or major version release, you can do so using the ModifyDBInstance API. Simply specify the version you wish to upgrade to via the EngineVersion parameter. The upgrade will then be applied on your behalf either immediately (if the ApplyImmediately flag is set to true) or during the next scheduled maintenance window for your DB Instance.

Q: Can I test my DB Instance against a new version before upgrading?

Yes. You can do so by creating a DB Snapshot of your existing DB Instance, restoring from the DB Snapshot to create a new DB Instance, and then initiating a version upgrade for the new DB Instance. You can then experiment safely on the upgraded clone of your DB Instance before deciding whether or not to upgrade your original DB Instance.

Q: How does Amazon RDS distinguish between “major” and “minor” version releases?

In the context of MySQL, version numbers are organized as follows:

MySQL version = X.Y.Z

X = Major version, Y = Release level, Z = Version number within release series.

From the Amazon RDS standpoint, a version change would be considered major if either major version or release level is being changed. Example: going from 5.1.X -> 5.5.X. A version change would be considered minor if the version number within the release is being changed. Example: going from 5.1.45 -> 5.1.49.

As of today, Amazon RDS supports the MySQL major versions MySQL 5.1 and MySQL 5.5. We plan to support additional MySQL major versions in the future.

Q: Does Amazon RDS provide guidelinesfor supporting new MySQL version releases and/or deprecating MySQL versions that are currently supported?

Over time, we plan to support additional MySQL versions for Amazon RDS, both minor and major. The number of new version releases supported in a given year will vary based on the frequency and content of the MySQL version releases and the outcome of a thorough vetting of the release by our database engineering team. However, as a general guidance, we aim to support new MySQL versions within 3-5 months of their General Availability release.

In terms of deprecation policy:

• We intend to support major MySQL version releases, including MySQL 5.1, for 3 years after they are initially supported by Amazon RDS.
• We intend to support minor MySQL version releases (e.g. MySQL 5.1.45) for at least 1 year after they are initially supported by Amazon RDS.
• After a MySQL major or minor version has been “deprecated”, we expect to provide a three month grace period for you to initiate an upgrade to a supported version prior to an automatic upgrade being applied during your scheduled maintenance window.

Q: How do I create a MySQL 5.5 DB Instance or upgrade my existing MySQL 5.1 DB Instance to MySQL 5.5?

To create a new MySQL 5.5 DB Instance, use the “Launch DB Instance Wizard” in the AWS Management Console and select a version corresponding to MySQL 5.5 or simply call the CreateDBInstance API with the Engine Version parameter as “5.5”.

Currently, a direct upgrade from MySQL 5.1 to MySQL 5.5 is not supported. However, we intend to provide this functionality in the future. Meanwhile, if you would like to port your existing MySQL 5.1 database to MySQL 5.5, you can use mysqldump to export your database from your existing MySQL 5.1 DB Instance and import it into a new MySQL 5.5 DB Instance.

Oracle

Licensing and Support

Q: What types of licensing options are available with Amazon RDS for Oracle?

There are two types of licensing options available for using Amazon RDS for Oracle:

• Bring Your Own License (BYOL): In this licensing model, you can use your existing Oracle Database licenses to run Oracle deployments on Amazon RDS. To run a DB Instance under the BYOL model, you must have the appropriate Oracle Database license (with Software Update License & Support) for the DB Instance class and Oracle Database edition you wish to run. You must also follow Oracle's policies for licensing Oracle Database software in the cloud computing environment. DB Instances reside in the Amazon EC2 environment, and Oracle's licensing policy for Amazon EC2 is located here.
• License Included: In the "License Included" service model, you do not need separately purchased Oracle licenses; the Oracle Database software has been licensed by AWS. "License Included" pricing is inclusive of software, underlying hardware resources, and Amazon RDS management capabilities.

Q: Which Oracle Database Editions are available with Amazon RDS for Oracle?

Amazon RDS currently supports the following Oracle Database Editions under each of the licensing models below:

• BYOL: Standard Edition One (SE1), Standard Edition (SE) and Enterprise Edition (EE)
• License Included: Standard Edition One (SE1)

Q: What are the licensing policies to use Amazon RDS for Oracle?

• BYOL: To run a DB Instance under the BYOL model, you must have the appropriate Oracle Database license (with Software Update License & Support) for the DB Instance class and Oracle Database edition you wish to run. You must follow Oracle's policies for licensing Oracle Database software in the cloud computing environment. DB Instances reside in the Amazon EC2 environment, and Oracle's licensing policy for Amazon EC2 is located here.
• License Included: In the "License Included" service model, you do not need separately purchased Oracle licenses; the Oracle Database software has been licensed by AWS.

Q: How will Amazon RDS for Oracle be supported?

• BYOL: Under this model, you will continue to use your active Oracle support account and contact Oracle directly for Oracle Database specific service requests. If you have an active AWS Premium Support account, you can contact AWS Premium Support for Amazon RDS specific issues. Amazon Web Services and Oracle have multi-vendor support process for cases which require assistance from both organizations.
• License Included: In this model, if you have an active AWS Premium Support account, you should contact AWS Premium Support for both Amazon RDS and Oracle Database specific service requests.

Q: Can I change the licensing option for my DB Instance (e.g. from 'BYOL' to 'License Included')?

Yes, you can change your license options. However, you will need to delete your current DB Instance with a final snapshot and create a new DB Instance from that snapshot specifying the new licensing option you need.

DB Engine Version Management

Q: What are Amazon RDS DB Engine Versions for Oracle and how do they relate to Oracle Patch Sets?

In the context of Oracle, Amazon RDS DB Engine Versions are organized as follows:

DB Engine Versions for Oracle = X.Y.Z

X = Major version (for ex: 11.2), Y = Release level (for ex: 0.2), Z = version number within release series (for ex: v2). For example, a DB Engine version for Oracle could be 11.2.0.2.v2

Oracle releases Database Patch Set Updates (PSU) for supported release levels on a quarterly basis. (e.g. 11.2.0.2.1). The PSUs include security fixes and additional non-security fixes recommended by Oracle.

The Amazon RDS DB Engine Versions are built with a given PSU as a baseline and may contain additional fixes beyond it.

From the Amazon RDS standpoint, a version change would be considered major if either major version or release level is being changed. Example: going from 11.2.0.2.Z -> 11.2.0.4.Z. A version change would be considered minor if the version number within the release is being changed. Example: going from 11.2.0.2.v2 -> 11.2.0.2.v3.

As of today, Amazon RDS supports the major version 11.2 (11g Release 2). We plan to support additional major versions in the future.

Q: What is the patch set composition of my DB Engine Version for Oracle?

Refer to the Amazon RDS User Guide for details of the patch set composition of each DB Engine Version of Oracle.

Q: Can I control when my DB Instance could be upgraded to a new DB Engine Version for Oracle?

Amazon RDS allows you to control if and when the relational database software powering your DB Instance is upgraded to new versions supported by Amazon RDS. This provides you with the flexibility to maintain compatibility with specific Oracle database versions, test new versions with your application before deploying in production, and perform version upgrades on your own terms and timelines.

Unless you specify otherwise, your DB Instance will automatically be upgraded to new DB Engine Versions as they are supported by Amazon RDS. This patching will occur during your scheduled maintenance window, and will be announced on the Amazon RDS Forum in advance. If you wish to turn off automatic version upgrades, you can do so by setting the "Auto Minor Version Upgrade" field to "No". Since major version upgrades involve some compatibility risk, they will not occur automatically and must be initiated by you.

This approach to database software patching puts you in the driver’s seat of version upgrades, but still offloads the work of patch application to Amazon RDS. You can learn more about version management by reading the FAQ entires that follow. Alternatively, you can reference our Developer Guide.

While DB Engine version management functionality is intended to give you as much control as possible over how patching occurs, Amazon RDS may patch your DB Instance on your behalf in the event of a critical security vulnerability in the database software.

In the "License Included" model, the cost of the "Software Update License" is embedded in the hourly price, enabling access to Oracle Database software updates. However, under the BYOL model, you should have "Software Update License & Support" from Oracle to use Amazon RDS for Oracle Database.

Q: How do I specify which supported DB Engine Version I would like my DB Instance to run?

You can specify any currently supported version (minor and/or major) when creating a new DB Instance via the "Launch DB Instance" option in the AWS Management Console or the CreateDBInstance API.

If you have opted out of automatically scheduled upgrades by setting the AutoMinorVersionUpgrade parameter to false but wish to manually initiate an upgrade to a supported minor version or major version release, you can do so using the ModifyDBInstance API. Simply specify the version you wish to upgrade to via the EngineVersion parameter. The upgrade will then be applied on your behalf either immediately (if the "Apply Immediately" flag is set) or during the next scheduled maintenance window for your DB Instance.

Q: Can I test my DB Instance against a new version before upgrading?

Yes. You can do so by creating a DB Snapshot of your existing DB Instance, restoring from the DB Snapshot to create a new DB Instance, and then initiating a version upgrade for the new DB Instance. You can then experiment safely on the upgraded clone of your DB Instance before deciding whether or not to upgrade your original DB Instance.

Q: Does Amazon RDS provide guidelines for supporting new DB Engine Versions for Oracle and/or deprecating DB Engine Versions for Oracle that are currently supported?

Over time, we plan to support additional Oracle database versions for Amazon RDS, both minor and major. The number of new version releases supported in a given year will vary based on the frequency and content of the Oracle Patch Set Updates (PSUs) and the outcome of a thorough vetting of the release by our database engineering team. However, as a general guidance, we aim to support new Oracle Database versions within 3-5 months of their General Availability.

In terms of deprecation policy:

• We intend to support major version releases for 3 years after they are initially supported by Amazon RDS.
• We intend to support minor Oracle Database versions (e.g. 11.2.0.2.v2) for at least 1 year after they are initially supported by Amazon RDS.
• After a major or minor version has been “deprecated”, we expect to provide a three month grace period for you to initiate an upgrade to a supported version prior to an automatic upgrade being applied during your scheduled maintenance window.

Scaling

Q: Can I scale my DB Instance?

For the BYOL model, you may scale your DB Instances in accordance with the terms of your Oracle license(s).

For the License Included model, DB Instances running Oracle may be scaled up and down at any point, subject to the prevailing hourly pricing for each DB Instance class.

For more information on the scaling implications of Reserved DB Instances, see our Reserved DB Instance FAQ.

Q: Can I change the Oracle edition I'm running for a DB Instance (e.g. from Oracle 11g R2 SE1 to EE)?

For the BYOL model, you can migrate from one edition of Oracle software to another as long as you possess an unused Oracle license appropriate for the edition and class of DB Instance you plan to run. To change the edition and retain your data, you should take a snapshot of your running DB Instance and then create a new DB Instance of the desired edition from that snapshot. You should then delete the old DB Instance, unless you wish to keep it running and have the appropriate Oracle Database licenses.

For the License Included model, currently, only Oracle Standard Edition One is supported.

Options/Features

Q: What types of replication does Amazon RDS support for Oracle?

Amazon RDS for Oracle supports Multi-AZ deployments for both the License Included and Bring Your Own License (BYOL) licensing models.

Q: Does Amazon RDS use Oracle Data Guard for Multi-AZ deployments?

Oracle Data Guard is a High Availability feature available for Enterprise Edition of Oracle database. Amazon RDS currently uses a different synchronous replication technology and automatic failover functionality to provide Multi-AZ deployments for Oracle DB Instances. Multi-AZ deployments are available for all Oracle database editions supported by Amazon RDS.

Q: Will I need an additional license(s) if I use Multi-AZ deployments for my Oracle DB Instances under the "BYOL" licensing model?

Yes, we expect that you will need to use twice as many licenses for Multi-AZ deployments as you would for a corresponding Single-AZ deployment to account for the stand by DB Instance. However, you should review your Oracle Software Licensing Agreement and comply with Oracle’s licensing policies.

Q: Is Oracle RAC supported on Amazon RDS?

No, RAC is not currently supported.

Q: Which Enterprise Edition Options are supported on Amazon RDS?

Following Enterprise Edition Options are currently supported under the BYOL model:

• Advanced Security (Transparent Data Encryption, Native Network Encryption)
• Partitioning
• Management Packs (Diagnostic, Tuning)
• Advanced Compression
• Total Recall

Q: Which character sets are supported on Amazon RDS for Oracle?

Amazon RDS supports the thirty character sets in the Oracle "Recommended ASCII Database Character Sets" list. You can specify your desired character set when creating a new database instance. This is optional and the default character set is AL32UTF8. For more information, please refer to the Amazon RDS Documentation.

Q: Who manages the Oracle Wallet and Master Encryption Key when using Transparent Data Encryption on Amazon RDS?

Amazon RDS manages the Oracle Wallet and Master Encryption Key for the DB Instance.

How do I know if Amazon RDS supports a specific Oracle Database feature?

Oracle Database supports a number of features that vary with the edition of Oracle database you run. Refer to the Amazon RDS User Guide to know about the Oracle features that Amazon RDS currently supports.