Amazon RDS FAQs

What is Amazon RDS?

Amazon Relational Database Service (Amazon RDS) is a managed 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 to focus on your applications and business.

Amazon RDS gives you access to the capabilities of a familiar RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle, or RDS for Db2 database. This means that the code, applications, and tools you already use today with your existing databases should work seamlessly with Amazon RDS. Amazon RDS can automatically back up your database and keep your database software up to date with the latest version. You benefit from the flexibility of being able to scale the compute resources or storage capacity associated with your relational database instance. In addition, Amazon RDS makes it easy to use replication 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 AWS services, there are no upfront investments required, and you pay only for the resources you use.

When would I use Amazon RDS vs. Amazon EC2 Relational Database AMIs?

Amazon Web Services provides a number of database alternatives for developers. Amazon RDS enables you to run a fully managed and fully featured relational database while offloading database administration. Using one of our many relational database AMIs on Amazon EC2 allows you to manage 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 Cloud Databases with AWS for guidance on which solution is best for you.

Are there hybrid or on-premises deployment options for Amazon RDS?

Yes, you can run Amazon RDS on premises using Amazon RDS on Outposts. Please see the Amazon RDS on Outposts FAQs for additional information.

Can I get help to learn more about and onboard to Amazon RDS?

Yes, Amazon RDS specialists are available to answer questions and provide support. Contact Us and you’ll hear back from us in one business day to discuss how AWS can help your organization.

How do I set up a connection between an application or a SQL based client running on an Amazon EC2 compute instance and my Amazon RDS database instance/cluster?

You can set up a connection between an EC2 compute instance and a new Amazon RDS database using the Amazon RDS console. On the “Create database” page, select “Connect to an EC2 compute resource” option in the Connectivity Section. When you select this option, Amazon RDS automates the manual networking set up tasks such as creating a VPC, security groups, subnets, and ingress/egress rules to establish a connection between your application and database.

Additionally, you can set up a connection between an existing Amazon RDS database and an EC2 compute instance. To do so, open the RDS console, select an RDS database from the database list page, and choose “Set up EC2 connection” from the "Action" menu dropdown list. Amazon RDS automatically sets up your related network settings to enable a secure connection between the selected EC2 instance and the RDS database.

This connectivity automation improves productivity for new users and application developers. Users can now quickly and seamlessly connect an application or a client using SQL on an EC2 compute instance to an RDS database within minutes.

How do I set up a connection between a serverless Lambda application and my Amazon RDS or Amazon Aurora database instance and/or cluster?

You can set up a connection between an AWS Lambda function and an Amazon RDS or Amazon Aurora database from the Amazon RDS console. On the RDS console, select an RDS or Aurora database from the database list page, and choose “Set up Lambda connection” from the "Action" menu. Amazon RDS automatically sets up your related network settings to enable a secure connection between the selected Lambda function and the RDS or Aurora database.

We recommend that you use RDS Proxy during this connection set up. You can set up this connection either by using an existing RDS Proxy or using a new RDS Proxy that you can auto create during the connection. This connectivity set up automation can improve productivity for new users and application developers. Users can now quickly and seamlessly connect a serverless application or Lambda function to an RDS or Aurora database within minutes.

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 AWS Command Line Interface. You can run one or more DB instances and each DB instance can support one or more databases or database schemas, depending on engine type.

How do I create a DB instance?

DB instances are simple to create using either the AWS Management Console, Amazon RDS APIs, or AWS Command Line Interface. To launch a DB instance using the AWS Management Console, click "RDS" and then the “Launch DB Instance” button on the Instances tab. From there, you can specify the parameters for your DB instance, including DB engine and version, license model, instance type, storage type and amount, and primary user credentials.

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 create-db-instance command.

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, DescribeDBInstances API or describe-db-instances command. 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.

How many DB instances can I run with Amazon RDS?

By default, customers are allowed to have up to a total of 40 Amazon RDS DB instances. Of those 40, up to 10 can be RDS for Oracle or RDS for SQL Server DB instances under the "License Included" model. All 40 can be used for Amazon Aurora, RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, and RDS for Oracle under the Bring Your Own Licence (BYOL) model. Note that RDS for SQL Server has a limit of up to 100 databases on a single DB instance. To learn more, see the Amazon RDS for SQL Server User Guide.

How many databases or schemas can I run within a DB instance?

• RDS for Amazon Aurora: No limit imposed by software

• RDS for MySQL: No limit imposed by software

• RDS for MariaDB: No limit imposed by software

• RDS for Oracle: 1 database per instance; no limit on the number of schemas per database imposed by software

• RDS for SQL Server: Up to 100 databases per instance

• RDS for PostgreSQL: No limit imposed by software

• RDS for Db2: Up to 1 database per instance

How do I import data into an Amazon RDS DB instance?

The following are a number of ways to import data into Amazon RDS:

• MySQL: mysqldump or mysqlimport utilities

• Oracle: Data Pump, import/export, or SQL Loader

• SQL Server: Import/Export Wizard, full backup files (.bak), or Bulk Copy Program (BCP)

• PostgreSQL: pg_dump

For more information on data import and export, refer to the Data Import Guide for MySQL, the Data Import Guide for Oracle, the Data Import Guide for SQL Server, the Data Import Guide for PostgreSQL, or the Data Import Guide for Db2.

In addition, AWS Database Migration Service can help you securely migrate databases to AWS.

What is a maintenance window? Will my DB instance be available during maintenance events?

The Amazon RDS maintenance window is your opportunity to control when DB instance modifications, database engine version upgrades, and software patching occurs, in the event they are requested or required. If a maintenance event is scheduled for a given week, it will be initiated during the maintenance window you identify.

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), database engine version upgrades, and required software patching. Required software 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, the ModifyDBInstance API, or the modify-db-instance command. 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. Please refer to the Amazon RDS User Guide for more information on maintenance operations.

What should I do if my queries seem to be running slowly?

For production databases, we encourage you to enable Enhanced Monitoring, which provides access to over 50 CPU, memory, file system, and disk I/O metrics. You can enable these features on a per-instance basis and you can choose the granularity (all the way down to 1 second). 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 DB instance, refer to the Amazon RDS User Guide.

If you are using RDS for MySQL or MariaDB, you can access the 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 RDS for 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 RDS for 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.

Which relational database engine versions does Amazon RDS support?

For the list of supported database engine versions, please refer to the documentation for each engine:

• Amazon Aurora

• Amazon RDS for PostgreSQL

• Amazon RDS for MySQL

• Amazon RDS for MariaDB

• Amazon RDS for SQL Server

• Amazon RDS for Oracle

• Amazon RDS for Db2

Does Amazon RDS provide guidelines for support of new DB engine versions?

Over time, Amazon RDS adds support for new major and minor database engine versions. The number of new versions supported will vary based on the frequency and content of releases and patches from the engine’s vendor or development organization and the outcome of a thorough vetting of these releases and patches by our database engineering team. However, as a general guidance, we aim to support new engine versions within 5 months of their general availability.

How do I specify which supported DB engine version I would like my DB instance to run?

You can specify any currently supported version (major and minor) when creating a new DB instance via the Launch DB Instance operation in the AWS Management Console or the CreateDBInstance API. Please note that not every database engine version is available in every AWS region.

How do I control if and when the engine version of my DB instance is upgraded to new supported versions?

Amazon RDS strives to keep your database instance up to date by providing you with newer versions of the supported database engines. After a new version of a database engine is released by the vendor or development organization, it is thoroughly tested by our database engineering team before it is made available in Amazon RDS.

We recommend that you keep your database instance upgraded to the most current minor version as it will contain the latest security and functionality fixes. Unlike major version upgrades, minor version upgrades only include database changes that are backward-compatible with previous minor versions (of the same major version) of the database engine. 

If a new minor version does not contain fixes that would benefit Amazon RDS customers, we may choose not to make it available in Amazon RDS. Soon after a new minor version is available in Amazon RDS, we will set it to be the preferred minor version for new DB instances. 

To manually upgrade a database instance to a supported engine version, use the Modify DB Instance command on the AWS Management Console or the ModifyDBInstance API and set the DB Engine Version parameter to the desired version. By default, the upgrade will be applied during your next maintenance window. You can also choose to upgrade immediately by selecting the Apply Immediately option in the console API.

If we determine that a new engine minor version contains significant bug fixes compared to a previously released minor version, we will schedule automatic upgrades for DB instances that have the Auto Minor Version Upgrade setting to “Yes”. These upgrades will be scheduled to occur during customer-specified maintenance windows.

We schedule them so you can plan around them because downtime is required to upgrade a DB engine version, even for Multi-AZ instances. If you wish to turn off automatic minor version upgrades you can do so by setting the Auto Minor Version Upgrade setting to “No”.

In the case of RDS for Oracle and RDS for SQL Server, if the upgrade to the next minor version requires a change to a different edition, then we may not schedule automatic upgrades even if you have enabled the Auto Minor Version Upgrade setting. The determination on whether to schedule automatic upgrades in such situations will be made on a case-by-case basis.

Since major version upgrades involve some compatibility risk, they will not occur automatically and must be initiated by you (except in the case of major version deprecation, see below). For more information about upgrading a DB instance to a new DB engine version, refer to the Amazon RDS User Guide.

Can I test my DB instance with 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 copy of your DB instance before deciding whether or not to upgrade your original DB instance.

For more information about restoring a DB snapshot, refer to the Amazon RDS User Guide.

Does Amazon RDS provide guidelines for deprecating database engine versions that are currently supported?

• We intend to support major version releases (e.g., MySQL 5.6, PostgreSQL 9.6) for at least 3 years after they are initially supported by Amazon RDS.

• We intend to support minor versions (e.g., MySQL 5.6.37, PostgreSQL 9.6.1) for at least 1 year after they are initially supported by Amazon RDS.

Periodically, we will deprecate major or minor engine versions. Major versions are made available at least until the community end of life for the corresponding community version or the version is no longer receiving software fixes or security updates. For minor versions, this is when a minor version has significant bugs or security issues that have been resolved in a later minor version.

While we strive to meet these guidelines, in some cases we may deprecate specific major or minor versions sooner, such as when there are security issues. In the unlikely event that such cases occur, Amazon RDS will automatically upgrade your database engine to address the issue. Specific circumstances may dictate different timelines depending on the issue being addressed.

What happens when an Amazon RDS DB engine version is deprecated?

When a minor version of a database engine is deprecated in Amazon RDS, we will provide a three (3) month period after the announcement before beginning automatic upgrades. At the end of this period, all instances still running the deprecated minor version will be scheduled for automatic upgrade to the latest supported minor version during their scheduled maintenance windows.

When a major version of the database engine is deprecated in Amazon RDS, we will provide a minimum six (6) month period after the announcement of a deprecation for you to initiate an upgrade to a supported major version. At the end of this period, an automatic upgrade to the next major version will be applied to any instances still running the deprecated version during their scheduled maintenance windows.

Why can I not create a particular version?

In some cases, we may deprecate specific major or minor versions without prior notice, such as when we discover a version does not meet our high quality, performance, or security bar. In the unlikely event that such cases occur, Amazon RDS will discontinue the creation of new database instances and clusters with these versions. Existing customers may continue to be able to run their databases. Specific circumstances may dictate different timelines depending on the issue being addressed.

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. db.t2.micro, db.m4.large) of the DB instance consumed. Partial DB instance hours consumed are billed in one-second increments with a 10 minute minimum charge following a billable status change, such as creating, starting, or modifying the DB instance class. For additional details, read our what's new announcement.

• 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 (for Amazon RDS Magnetic Storage and Amazon Aurora only)

• Provisioned IOPS per month – Provisioned IOPS rate, regardless of IOPS consumed (for Amazon RDS Provisioned IOPS (SSD) Storage only)

• Backup Storage – Backup storage is the storage associated with your automated database backups and any customer-initiated database snapshots. Increasing your backup retention period or taking additional database snapshots increases the backup storage consumed by your database.

• Data transfer – Internet data transfer in and out of your DB instance.

When does billing of my Amazon RDS DB instances begin and end? What defines billable Amazon RDS instance hours?

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 an instance failure. 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 stop or delete it to avoid being billed for additional instance hours. Partial DB instance hours consumed are billed in one-second increments with a 10 minute minimum charge following a billable status change, such as creating, starting, or modifying the DB instance class.

How will I be billed for a stopped DB instance?

While your database instance is stopped, you are charged for provisioned storage (including Provisioned IOPS) and backup storage (including manual snapshots and automated backups within your specified retention window), but not for DB instance hours.

How will I be billed for backups storage?

Free backup storage is provided up to your account's total provisioned database storage across the entire region. For example, if you have a MySQL DB instance with 100 GB of provisioned storage over the month, and a PostgreSQL DB instance with 150 GB of provisioned storage over the month, both in the same region and same account, we will provide 250 GB of backup storage in this account and region at no additional charge. You will only be charged for backup storage that exceeds this amount.

Each day, your account's total provisioned database storage in the region is compared against your total backup storage in the region, and only the excess backup storage is charged. For example, if you have exactly 10 GB of excess backup storage each day, you will be charged for 10 GB-month of backup storage for the month. Alternatively, if you have 300 GB of provisioned storage each day, and 500 GB of backup storage each day, but only for half the month, then you will only be charged for 100 GB-month of backup storage (not 200 GB-month), since the charge is calculated daily (prorated), and the backups did not exist for the entire month. Please note that the free backup storage is account-specific and region-specific.

The size of your backups are directly proportional to the amount of data on your instance. For example, if you have a DB instance with 100 GB of provisioned storage, but only store 5 GB of data on it, your first backup will only be approximately 5 GB (not 100 GB). Subsequent backups are incremental, and will only store the changed data on your DB instance. Please note that the backup storage size is not displayed in RDS Console nor in the DescribeDBSnapshots API response.

Why does my additional backup storage cost more than the 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.

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. db.t2.micro, db.m4.large) of the DB instance consumed. As with standard deployments in a single Availability Zone, Partial DB instance hours consumed are billed in one-second increments with a 10 minutes minimum charge following a billable status change, such as creating, starting, or modifying the DB instance class. 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. Internet data transfer in and out of your DB instance is charged the same as with a standard deployment.

What does the AWS Free Tier for Amazon RDS offer? For what time period will the AWS Free Tier for Amazon RDS be available to me?

The AWS Free Tier for Amazon RDS offer provides free use of Single-AZ Micro DB instances running MySQL, MariaDB, PostgreSQL, and SQL Server Express Edition. The free usage tier is capped at 750 instance hours per month. Customers also receive 20 GB of General Purpose (SSD) database storage and 20 GB of backup storage for free per month. New AWS accounts receive 12 months of AWS Free Tier access. Please see the AWS Free Tier FAQs for more information.

Can I run more than one DB instance under the AWS Free Usage Tier for Amazon RDS?

Yes. You can run more than one Single-AZ Micro DB instance simultaneously and be eligible for usage counted under the AWS Free Tier for Amazon RDS. However, any use exceeding 750 instance hours, across all Amazon RDS Single-AZ Micro DB instances and across all eligible database engines and regions, will be billed at standard Amazon RDS prices.

For example, if you run two Single-AZ Micro DB instances for 400 hours each in a single month, you will accumulate 800 instance hours of usage, of which 750 hours will be free. You will be billed for the remaining 50 hours at the standard Amazon RDS price.

A customer with access to the AWS Free Tier can use up to 750 instance hours of Micro instances running either MySQL, PostgreSQL, or SQL Server Express Edition. Any use exceeding 750 instance hours, across all Amazon RDS Single-AZ Micro DB instances and across all eligible database engines and regions, will be billed at standard Amazon RDS prices.

What is a reserved instance (RI)?

Amazon RDS reserved instances give you the option to reserve a DB instance for a one or three year term and in turn receive a significant discount compared to the on-demand instance pricing for the DB instance. There are three RI payment options -- No Upfront, Partial Upfront, All Upfront -- which enable you to balance the amount you pay upfront with your effective hourly price.

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 purchase a one- or three-year reservation and in return receive a lower effective hourly usage rate (compared with on-demand DB instances) for the duration of the term. Unless you purchase reserved instances in a Region, all DB instances will be billed at on-demand hourly rates.

Do reserved instances include a capacity reservation? How many reserved instances can I purchase?

Amazon RDS reserved instances are purchased for a Region rather than for a specific Availability Zone. As RIs are not specific to an Availability Zone, they are not capacity reservations. This means that even if capacity is limited in one Availability Zone, reservations can still be purchased in the Region and the discount will apply to matching usage in any Availability Zone within that Region. You can purchase up to 40 reserved DB instances. If you wish to run more than 40 DB instances, please complete the Amazon RDS DB Instance request form.

How do I determine which initial DB instance class and storage capacity are appropriate for my needs? How do I scale the compute resources and/or storage capacity associated with my Amazon RDS Database Instance?

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 information about the DB instance classes available, please refer to the Amazon RDS User Guide. You can scale the compute resources and storage capacity allocated to your DB instance with the AWS Management Console (selecting the desired DB instance and clicking the Modify button), the Amazon RDS API, or the AWS Command Line Interface. 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.

How do I choose among the Amazon RDS storage types?

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, the ModifyDBInstance API, or the modify-db-instance command.

Choose the storage type most suited for your workload.

• High-performance OLTP workloads: Amazon RDS Provisioned IOPS (SSD) Storage

• Database workloads with moderate I/O requirements: Amazon RDS General Purpose (SSD) Storage

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 7 days but can be set to up to 35 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, 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, CreateDBSnapshot API, or create-db-snapshot command and are kept until you explicitly delete them.

The snapshots which Amazon RDS performs for enabling automated backups are available to you for copying (using the AWS console or the 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. 

Alternatively, 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 if so desired). This is done to enable you to create multiple DB Instances from a specific DB Snapshot or point in time.

What is Amazon Virtual Private Cloud (VPC) and how does it work with Amazon RDS?

Amazon VPC lets you create a virtual networking environment in a private, isolated section of the 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 data center.

One way that you can take advantage of VPC is when 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 Amazon 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.

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

By default, Amazon RDS chooses the optimal configuration parameters for your DB Instance taking into account the instance class and storage capacity. However, if you want to change them, you can do so using the AWS Management Console, the Amazon RDS APIs, or the AWS Command Line Interface. 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.

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, your 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. More information about Multi-AZ deployments is in the Amazon RDS User Guide.

What does it mean to run a DB Instance as a read replica?

Read replicas make it easier to take advantage of supported engines' 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 in 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 a supported engine'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 supported engines' 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.

What is Amazon CloudWatch Database Insights?

CloudWatch Database Insights is a monitoring and metrics solution that simplifies and enhances database troubleshooting. It automates telemetry collection, including metrics, logs, and traces, removing the need for manual setup and configuration. By consolidating this telemetry into Amazon CloudWatch, CloudWatch Database Insights provides a unified view of database performance and health.

What is Amazon RDS Proxy?

Amazon RDS Proxy is a fully managed, highly available database proxy feature for Amazon RDS. RDS Proxy makes applications more scalable, more resilient to database failures, and more secure. Amazon RDS Proxy is a fully managed, highly available, and easy-to-use database proxy feature of Amazon RDS that enables your applications to: 1) improve scalability by pooling and sharing database connections, 2) improve availability by reducing database failover times by up to 66% and preserving application connections during failovers, and 3) improve security by optionally enforcing AWS IAM authentication to databases and securely storing credentials in AWS Secrets Manager.

What engines support Amazon RDS Blue/Green Deployments?

Amazon RDS Blue/Green Deployments are available in Amazon Aurora MySQL-Compatible Edition, Amazon Aurora PostgreSQL-Compatible Edition, Amazon RDS for MySQL, Amazon RDS for MariaDB, and Amazon RDS for PostgreSQL. 

How does Amazon RDS Optimized Writes write data files differently than MySQL?

MySQL protects users from data loss by writing data in 16KiB pages in memory twice to durable storage—first to the “doublewrite buffer” and then to table storage. Amazon RDS Optimized Writes write your 16KiB data pages directly to your data files reliably and durably in one step using the Torn Write Prevention feature of the AWS Nitro System.

All Amazon RDS for MySQL users should implement Amazon RDS Optimized Writes for up to 2x improved write transaction throughput. Applications with write-heavy workloads, such as digital payments, financial trading, and online gaming applications will find this feature especially helpful.

How do Amazon RDS Optimized Reads speed up query performance?

Workloads that use temporary objects in MySQL and MariaDB for query processing benefit from Amazon RDS Optimized Reads. Optimized Reads place temporary objects on the database instance's NVMe-based instance storage, instead of the Amazon Elastic Block Store volume. This helps to speed up complex query processing by up to 2X.