RDS

RDS Multi-AZ – High Availability & Failover

RDS Multi-AZ Instance Deployment
~ Last updated on : ~ jayendrapatil ~ 1 Comment

RDS Multi-AZ Deployment

  • RDS Multi-AZ deployments provide high availability and automatic failover support for DB instances
  • Multi-AZ helps improve the durability and availability of a critical system, enhancing availability during planned system maintenance, DB instance failure, and Availability Zone disruption.
  • A Multi-AZ DB instance deployment
    • has one standby DB instance that provides failover support but doesn’t serve read traffic.
    • There is only one row for the DB instance.
    • The value of Role is Instance or Primary.
    • The value of Multi-AZ is Yes.
  • A Multi-AZ DB cluster deployment
    • has two standby DB instances that provide failover support and can also serve read traffic.
    • There is a cluster-level row with three DB instance rows under it.
    • For the cluster-level row, the value of Role is Multi-AZ DB cluster.
    • For each instance-level row, the value of Role is Writer instance or Reader instance.
    • For each instance-level row, the value of Multi-AZ is 3 Zones.

RDS Multi-AZ DB Instance Deployment

  • RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different AZ.
  • RDS performs an automatic failover to the standby, so that database operations can be resumed as soon as the failover is complete.
  • RDS Multi-AZ deployment maintains the same endpoint for the DB Instance after a failover, so the application can resume database operation without the need for manual administrative intervention.
  • Multi-AZ is a high-availability feature and NOT a scaling solution for read-only scenarios; a standby replica can’t be used to serve read traffic. To service read-only traffic, use a Multi-AZ DB cluster or a Read Replica.
  • Failover times are typically 60–120 seconds for Multi-AZ DB instance deployments.
  • Multi-AZ deployments for MariaDB, MySQL, Oracle, PostgreSQL, and RDS Custom for SQL Server DB instances use the Amazon failover technology.
  • Microsoft SQL Server DB instances use SQL Server Database Mirroring (DBM), Always On Availability Groups (AGs), or block-level replication depending on the edition and version.
    • Database Mirroring is deprecated by Microsoft and will be removed in a future version of SQL Server. AWS recommends migrating to Always On AGs.
    • New (Nov 2025): RDS for SQL Server Web Edition now supports Multi-AZ using block-level replication, providing enterprise-grade availability without requiring Enterprise or Standard Edition licensing.

RDS Multi-AZ Instance Deployment

ENA Express for Multi-AZ Replication (May 2026)

  • Amazon RDS Multi-AZ instances now use ENA Express for replication traffic between Availability Zones.
  • ENA Express uses AWS’s Scalable Reliable Datagram (SRD) protocol to optimize network performance.
  • Delivers up to 25 Gbps single-flow bandwidth for cross-AZ replication traffic (previously up to 5 Gbps).
  • Leverages advanced congestion control and multi-pathing capabilities, reducing latency variability for Multi-AZ deployments.
  • Results in increased write throughput and lower write latencies for write-intensive database workloads.
  • Available at no additional charge for RDS for MariaDB, MySQL, PostgreSQL, Db2, and Oracle.
  • Supported for db.m6i.8xlarge and above instance classes in a Multi-AZ configuration.
  • To enable on existing instances, perform a stop/start or scale compute action.

RDS Multi-AZ DB Cluster Deployment

  • RDS Multi-AZ DB cluster deployment is a high-availability deployment mode of RDS with two readable standby DB instances.
  • RDS Multi-AZ DB cluster has a writer DB instance and two reader DB instances in three separate AZs in the same AWS Region.
  • With a Multi-AZ DB cluster, RDS semi-synchronously replicates data from the writer DB instance to both of the reader DB instances using the DB engine’s native replication capabilities.
  • Multi-AZ DB clusters provide high availability, increased capacity for read workloads, and lower write latency when compared to Multi-AZ DB instance deployments.
  • If an event of an outage, RDS manages failover from the writer DB instance to one of the reader DB instances. RDS does this based on which reader DB instance has the most recent change record.
  • Failover times are typically under 35 seconds for Multi-AZ DB clusters, compared to 60-120 seconds for Multi-AZ DB instance deployments.
  • Multi-AZ DB clusters support up to 2x faster transaction commit latency compared to Multi-AZ DB instance deployments.
  • Multi-AZ DB clusters are currently supported only for the MySQL (8.0, 8.4) and PostgreSQL DB engines.

RDS Mulit-AZ DB Cluster

Multi-AZ DB Cluster – Recent Enhancements (2024-2025)

  • IAM Database Authentication (Oct 2024): Multi-AZ DB clusters with two readable standbys now support AWS IAM database authentication, enabling centralized access management without storing password-based login credentials in the database.
  • Security Certificate Rotation (Mar 2024): Supports database security certificate rotation for an extra layer of security by validating connections made to RDS database instances and clusters.
  • C6gd Instance Support (Mar 2024): Multi-AZ DB clusters now support C6gd database instances for enhanced compute performance.
  • Minor Version Upgrades: Downtime for minor version upgrades is typically under 35 seconds, and can be further reduced to under 1 second by adding an open source or RDS Proxy to the deployment.

Multi-AZ DB Instance vs Multi-AZ DB Cluster

RDS Multi-AZ DB Instance vs DB Cluster

Feature Multi-AZ DB Instance Multi-AZ DB Cluster
Standby Instances 1 (not readable) 2 (readable)
Replication Synchronous Semi-synchronous (engine native)
Failover Time 60-120 seconds Typically under 35 seconds
Read Traffic Not supported on standby Supported on reader instances
Write Latency Standard Up to 2x faster transaction commits
Supported Engines MySQL, PostgreSQL, MariaDB, Oracle, SQL Server MySQL, PostgreSQL only
IAM DB Authentication Supported Supported (since Oct 2024)
ENA Express Supported (since May 2026) N/A (uses engine-native replication)

RDS Multi-AZ vs Read Replicas

RDS Mulit-AZ vs Multi-Region vs Read Replicas

RDS Extended Support and Multi-AZ

  • Starting March 1, 2024, Amazon RDS automatically charges for RDS Extended Support when running a major version past its end of standard support date.
  • Extended Support provides up to three additional years of critical security and bug fixes beyond a major version’s end of standard support date.
  • Key end-of-standard-support dates:
    • PostgreSQL 11 – February 29, 2024
    • PostgreSQL 12 – February 28, 2025
    • PostgreSQL 13 – February 28, 2026
    • MySQL 5.7 – February 29, 2024
  • Extended Support pricing increases over time (Year 1 → Year 2 → Year 3), making timely upgrades important for Multi-AZ deployments where charges apply to both primary and standby instances.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is deploying a new two-tier web application in AWS. The company has limited staff and requires high availability, and the application requires complex queries and table joins. Which configuration provides the solution for the company’s requirements?
    1. MySQL Installed on two Amazon EC2 Instances in a single Availability Zone (does not provide High Availability out of the box)
    2. Amazon RDS for MySQL with Multi-AZ
    3. Amazon ElastiCache (Just a caching solution)
    4. Amazon DynamoDB (Not suitable for complex queries and joins)
  2. What would happen to an RDS (Relational Database Service) multi-Availability Zone deployment if the primary DB instance fails?
    1. IP of the primary DB Instance is switched to the standby DB Instance.
    2. A new DB instance is created in the standby availability zone.
    3. The canonical name record (CNAME) is changed from primary to standby.
    4. The RDS (Relational Database Service) DB instance reboots.
  3. Will my standby RDS instance be in the same Availability Zone as my primary?
    1. Only for Oracle RDS types
    2. Yes
    3. Only if configured at launch
    4. No
  4. Is creating a Read Replica of another Read Replica supported?
    1. Only in certain regions
    2. Only with MySQL based RDS [Note: As of 2022+, cascading Read Replicas are now also supported for PostgreSQL (version 14.1+). Both MySQL and PostgreSQL support up to three levels of cascading replicas.]
    3. Only for Oracle RDS types
    4. No
  5. A user is planning to set up the Multi-AZ feature of RDS. Which of the below mentioned conditions won’t take advantage of the Multi-AZ feature?
    1. Availability zone outage
    2. A manual failover of the DB instance using Reboot with failover option
    3. Region outage
    4. When the user changes the DB instance’s server type
  6. When you run a DB Instance as a Multi-AZ deployment, the “_____” serves database writes and reads
    1. secondary
    2. backup
    3. stand by
    4. primary [Note: For Multi-AZ DB clusters, reader instances can also serve read traffic.]
  7. When running my DB Instance as a Multi-AZ deployment, can I use the standby for read or write operations?
    1. Yes
    2. Only with MSSQL based RDS
    3. Only for Oracle RDS instances
    4. No [Note: This applies to Multi-AZ DB instance deployments. Multi-AZ DB cluster deployments DO allow reader instances to serve read traffic.]
  8. Read Replicas require a transactional storage engine and are only supported for the _________ storage engine
    1. OracleISAM
    2. MSSQLDB
    3. InnoDB
    4. MyISAM
  9. A user is configuring the Multi-AZ feature of an RDS DB. The user came to know that this RDS DB does not use the AWS technology, but uses server mirroring to achieve replication. Which DB is the user using right now?
    1. MySQL
    2. Oracle
    3. MS SQL [Note: SQL Server now also supports Always On Availability Groups and block-level replication for Multi-AZ, depending on the edition and version. Database Mirroring is deprecated by Microsoft.]
    4. PostgreSQL
  10. If you have chosen Multi-AZ deployment, in the event of a planned or unplanned outage of your primary DB Instance, Amazon RDS automatically switches to the standby replica. The automatic failover mechanism simply changes the ______ record of the main DB Instance to point to the standby DB Instance.
    1. DNAME
    2. CNAME
    3. TXT
    4. MX
  11. When automatic failover occurs, Amazon RDS will emit a DB Instance event to inform you that automatic failover occurred. You can use the _____ to return information about events related to your DB Instance
    1. FetchFailure
    2. DescriveFailure
    3. DescribeEvents
    4. FetchEvents
  12. The new DB Instance that is created when you promote a Read Replica retains the backup window period.
    1. TRUE
    2. FALSE
  13. Will I be alerted when automatic failover occurs?
    1. Only if SNS configured
    2. No
    3. Yes
    4. Only if Cloudwatch configured
  14. Can I initiate a “forced failover” for my MySQL Multi-AZ DB Instance deployment?
    1. Only in certain regions
    2. Only in VPC
    3. Yes
    4. No
  15. A user is accessing RDS from an application. The user has enabled the Multi-AZ feature with the MS SQL RDS DB. During a planned outage how will AWS ensure that a switch from DB to a standby replica will not affect access to the application?
    1. RDS will have an internal IP which will redirect all requests to the new DB
    2. RDS uses DNS to switch over to standby replica for seamless transition
    3. The switch over changes Hardware so RDS does not need to worry about access
    4. RDS will have both the DBs running independently and the user has to manually switch over
  16. Which of the following is part of the failover process for a Multi-AZ Amazon Relational Database Service (RDS) instance?
    1. The failed RDS DB instance reboots.
    2. The IP of the primary DB instance is switched to the standby DB instance.
    3. The DNS record for the RDS endpoint is changed from primary to standby.
    4. A new DB instance is created in the standby availability zone.
  17. Which of these is not a reason a Multi-AZ RDS instance will failover?
    1. An Availability Zone outage
    2. A manual failover of the DB instance was initiated using Reboot with failover
    3. To autoscale to a higher instance class (Refer link)
    4. Master database corruption occurs
    5. The primary DB instance fails
  18. How does Amazon RDS multi Availability Zone model work?
    1. A second, standby database is deployed and maintained in a different availability zone from master, using synchronous replication. (Refer link)
    2. A second, standby database is deployed and maintained in a different availability zone from master using asynchronous replication.
    3. A second, standby database is deployed and maintained in a different region from master using asynchronous replication.
    4. A second, standby database is deployed and maintained in a different region from master using synchronous replication.
  19. A user is using a small MySQL RDS DB. The user is experiencing high latency due to the Multi AZ feature. Which of the below mentioned options may not help the user in this situation?
    1. Schedule the automated back up in non-working hours
    2. Use a large or higher size instance
    3. Use PIOPS
    4. Take a snapshot from standby Replica
  20. What is the charge for the data transfer incurred in replicating data between your primary and standby?
    1. No charge. It is free.
    2. Double the standard data transfer charge
    3. Same as the standard data transfer charge
    4. Half of the standard data transfer charge
  21. A user has enabled the Multi AZ feature with the MS SQL RDS database server. Which of the below mentioned statements will help the user understand the Multi AZ feature better?
    1. In a Multi AZ, AWS runs two DBs in parallel and copies the data asynchronously to the replica copy
    2. In a Multi AZ, AWS runs two DBs in parallel and copies the data synchronously to the replica copy
    3. In a Multi AZ, AWS runs just one DB but copies the data synchronously to the standby replica
    4. AWS MS SQL does not support the Multi AZ feature
  22. A company needs a highly available database solution with the lowest possible failover time. The application uses MySQL. Which RDS deployment option provides the fastest failover? [New Question]
    1. Multi-AZ DB instance deployment (Failover takes 60-120 seconds)
    2. Multi-AZ DB cluster deployment (Failover typically under 35 seconds)
    3. Single-AZ with Read Replicas (No automatic failover)
    4. Cross-Region Read Replica (Manual promotion required)
  23. Which of the following is a benefit of RDS Multi-AZ DB cluster deployment over Multi-AZ DB instance deployment? (Choose TWO) [New Question]
    1. Reader instances can serve read traffic
    2. Supports all RDS database engines
    3. Up to 2x faster transaction commit latency
    4. Uses synchronous replication
    5. Supports Oracle and SQL Server engines
  24. A company runs a write-intensive MySQL workload on RDS Multi-AZ. They notice high replication latency between the primary and standby instances. What recent AWS feature can help reduce this latency? [New Question]
    1. Enable Read Replicas for write offloading
    2. Enable ENA Express for Multi-AZ replication which uses AWS SRD protocol for up to 25 Gbps single-flow bandwidth
    3. Switch to asynchronous replication
    4. Enable Enhanced Monitoring

AWS Database Services Cheat Sheet – RDS, DynamoDB, Aurora

~ Last updated on : ~ jayendrapatil ~ 9 Comments

AWS Database Services Cheat Sheet

AWS Database Services

📋 Last Updated: June 2026

This cheat sheet has been updated to include Aurora DSQL, Aurora storage increase to 256 TiB, ElastiCache for Valkey, ElastiCache Serverless, Redshift Multi-AZ and Serverless, DynamoDB multi-Region strong consistency, zero-ETL integrations, RDS Multi-AZ DB Clusters with readable standbys, and RDS Extended Support.

Relational Database Service – RDS

  • provides Relational Database service
  • supports MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Aurora, and IBM Db2 (added in 2023) DB engines
  • as it is a managed service, shell (root ssh) access is not provided
  • manages backups, software patching, automatic failure detection, and recovery
  • supports use initiated manual backups and snapshots
  • daily automated backups with database transaction logs enables Point in Time recovery up to the last five minutes of database usage
  • snapshots are user-initiated storage volume snapshot of DB instance, backing up the entire DB instance and not just individual databases that can be restored as a independent RDS instance
  • RDS Security
    • support encryption at rest using KMS as well as encryption in transit using SSL endpoints
    • supports IAM database authentication, which prevents the need to store static user credentials in the database, because authentication is managed externally using IAM.
    • supports Encryption only during creation of an RDS DB instance
    • existing unencrypted DB cannot be encrypted and you need to create a snapshot, create an encrypted copy of the snapshot and restore as encrypted DB
    • supports Secrets Manager for storing and rotating secrets
    • for encrypted database
      • logs, snapshots, backups, read replicas are all encrypted as well
      • cross region replicas and snapshots are supported for encrypted instances
  • Multi-AZ deployment
    • provides high availability and automatic failover support and is NOT a scaling solution
    • maintains a synchronous standby replica in a different AZ
    • transaction success is returned only if the commit is successful both on the primary and the standby DB
    • Oracle, PostgreSQL, MySQL, and MariaDB DB instances use Amazon technology, while SQL Server DB instances use SQL Server Always On Availability Groups
    • snapshots and backups are taken from standby & eliminate I/O freezes
    • during automatic failover, its seamless and RDS switches to the standby instance and updates the DNS record to point to standby
    • failover can be forced with the Reboot with failover option
  • Multi-AZ DB Cluster (Readable Standbys)
    • provides a primary DB instance and two readable standby DB instances in different AZs
    • standby instances can serve read traffic, providing additional read capacity
    • uses semi-synchronous replication with transaction log-based replication
    • provides faster failover (typically under 35 seconds) compared to Multi-AZ instance deployment
    • supports MySQL and PostgreSQL engines
    • offers lower write latency compared to Multi-AZ instance deployments
  • Read Replicas
    • uses the PostgreSQL, MySQL, and MariaDB DB engines’ built-in replication functionality to create a separate Read Only instance
    • updates are asynchronously copied to the Read Replica, and data might be stale
    • can help scale applications and reduce read only load
    • requires automatic backups enabled
    • replicates all databases in the source DB instance
    • for disaster recovery, can be promoted to a full fledged database
    • can be created in a different region for disaster recovery, migration and low latency across regions
    • can’t create encrypted read replicas from unencrypted DB or read replica
  • RDS does not support all the features of underlying databases, and if required the database instance can be launched on an EC2 instance
  • RDS Components
    • DB parameter groups contains engine configuration values that can be applied to one or more DB instances of the same instance type for e.g. SSL, max connections etc.
    • Default DB parameter group cannot be modified, create a custom one and attach to the DB
    • Supports static and dynamic parameters
      • changes to dynamic parameters are applied immediately (irrespective of apply immediately setting)
      • changes to static parameters are NOT applied immediately and require a manual reboot.
  • RDS Monitoring & Notification
    • integrates with CloudWatch and CloudTrail
    • CloudWatch provides metrics about CPU utilization from the hypervisor for a DB instance, and Enhanced Monitoring gathers its metrics from an agent on the instance
    • Performance Insights is a database performance tuning and monitoring feature that helps illustrate the database’s performance and help analyze any issues that affect it
    • supports RDS Event Notification which uses the SNS to provide notification when an RDS event like creation, deletion or snapshot creation etc occurs
  • RDS Blue/Green Deployments
    • creates a staging (green) environment that mirrors the production (blue) environment
    • enables safer database updates, major version upgrades, and schema changes with minimal downtime (under 5 seconds)
    • supports Aurora MySQL, Aurora PostgreSQL, RDS for MySQL, RDS for MariaDB, and RDS for PostgreSQL
    • now supports Aurora Global Database (2025)
  • RDS Extended Support
    • allows running databases on a major engine version up to 3 years past its RDS end of standard support date at an additional cost
    • provides critical security and bug fixes after the community ends support for a major version
    • databases are automatically enrolled if not upgraded before the end of standard support date
  • Zero-ETL Integrations
    • RDS for MySQL and Aurora support zero-ETL integration with Amazon Redshift
    • enables near real-time analytics on transactional data without building ETL pipelines
    • data is automatically replicated to Amazon Redshift within seconds of being written

⚠️ RDS Custom for Oracle – End of Support (March 31, 2027)

AWS will end support for Amazon RDS Custom for Oracle on March 31, 2027. After this date, you will no longer be able to access the RDS Custom for Oracle console or resources.

Migration Options: Migrate to Amazon RDS for Oracle (standard) or run Oracle on Amazon EC2 bare metal instances.

Aurora

  • is a relational database engine that combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases
  • is a managed service and handles time-consuming tasks such as provisioning, patching, backup, recovery, failure detection and repair
  • is a proprietary technology from AWS (not open sourced)
  • provides PostgreSQL and MySQL compatibility
  • is “AWS cloud optimized” and claims 5x performance improvement over MySQL on RDS, over 3x the performance of PostgreSQL on RDS
  • scales storage automatically in increments of 10GB, up to 256 TiB (increased from 128 TiB in July 2025) with no impact to database performance. Storage is striped across 100s of volumes.
  • no need to provision storage in advance.
  • provides self-healing storage. Data blocks and disks are continuously scanned for errors and repaired automatically.
  • provides instantaneous failover
  • replicates each chunk of the database volume six ways across three Availability Zones i.e. 6 copies of the data across 3 AZ
    • requires 4 copies out of 6 needed for writes
    • requires 3 copies out of 6 need for reads
  • costs more than RDS (20% more) – but is more efficient
  • Read Replicas
    • can have 15 replicas while MySQL has 5, and the replication process is faster (sub 10 ms replica lag)
    • share the same data volume as the primary instance in the same AWS Region, there is virtually no replication lag
    • supports Automated failover for master in less than 30 seconds
    • supports Cross Region Replication using either physical or logical replication.
  • Security
    • supports Encryption at rest using KMS
    • supports Encryption in flight using SSL (same process as MySQL or Postgres)
    • Automated backups, snapshots and replicas are also encrypted
    • Possibility to authenticate using IAM token (same method as RDS)
    • supports protecting the instance with security groups
    • does not support SSH access to the underlying servers
  • Aurora I/O-Optimized
    • a cluster configuration that provides predictable pricing with no charges for I/O operations
    • ideal for I/O-intensive applications such as e-commerce, payment processing, and SaaS applications
    • can deliver up to 40% cost savings for I/O-intensive workloads
    • supports both Aurora Serverless and provisioned instances
    • can switch between I/O-Optimized and Standard configurations (once every 30 days to I/O-Optimized, back to Standard anytime)
  • Aurora Serverless
    • provides automated database instantiation and on-demand autoscaling based on actual usage
    • provides a relatively simple, cost-effective option for infrequent, intermittent, or unpredictable workloads
    • automatically starts up, shuts down, and scales capacity up or down based on the application’s needs. No capacity planning needed
    • Pay per second, can be more cost-effective
    • Aurora Serverless v1 reached end of life on March 31, 2025 – all clusters have been migrated to Aurora Serverless v2 (now simply called “Aurora Serverless”)
    • Aurora Serverless (v2) supports features like read replicas, Multi-AZ, Global Database, and logical replication that v1 did not
    • supports scale to zero capability and up to 30% better performance with smarter scaling (2026 enhancement)
  • Aurora Global Database
    • allows a single Aurora database to span multiple AWS regions.
    • provides Physical replication, which uses dedicated infrastructure that leaves the databases entirely available to serve the application
    • supports 1 Primary Region (read / write)
    • replicates across up to 5 secondary (read-only) regions, replication lag is less than 1 second
    • supports up to 16 Read Replicas per secondary region
    • recommended for low-latency global reads and disaster recovery with an RTO of < 1 minute
    • supports managed failover (Global Database Failover) which automates the cross-Region failover process, reducing operational overhead (introduced August 2023)
    • supports Blue/Green Deployments for Global Database (2025) for safer major version upgrades across all regions
    • supports a global writer endpoint for simplified application connectivity
  • Aurora Backtrack
    • Backtracking “rewinds” the DB cluster to the specified time
    • Backtracking performs in place restore and does not create a new instance. There is a minimal downtime associated with it.
  • Aurora Clone feature allows quick and cost-effective creation of Aurora Cluster duplicates
  • supports parallel or distributed query using Aurora Parallel Query, which refers to the ability to push down and distribute the computational load of a single query across thousands of CPUs in Aurora’s storage layer.
  • Aurora Optimized Reads
    • delivers up to 8x improved query latency for applications with datasets exceeding instance memory
    • uses local NVMe-based storage on Graviton-based instances to extend caching capacity
    • available for both PostgreSQL and MySQL compatible editions

Amazon Aurora DSQL (New – GA May 2025)

  • a serverless, distributed SQL database optimized for transaction processing
  • the fastest serverless distributed SQL database with active-active high availability
  • provides PostgreSQL compatibility (subset of features)
  • designed for 99.99% availability in single-Region and 99.999% availability in multi-Region configurations
  • delivers strong consistency for all reads and writes to any Regional endpoint
  • provides virtually unlimited scalability with zero infrastructure management and zero downtime maintenance
  • offers the fastest distributed SQL reads and writes with 4x faster reads and writes compared to other popular distributed SQL databases
  • employs an active-active deployment model where all database resources function as peers capable of handling both read and write traffic
  • supports up to 256 TiB of storage per database cluster
  • ideal for globally distributed applications requiring strong consistency, such as financial transactions, gaming, and SaaS applications

DynamoDB

  • fully managed NoSQL database service
  • synchronously replicates data across three facilities in an AWS Region, giving high availability and data durability
  • runs exclusively on SSDs to provide high I/O performance
  • provides provisioned table reads and writes
  • automatically partitions, reallocates, and re-partitions the data and provisions additional server capacity as data or throughput changes
  • creates and maintains indexes for the primary key attributes for efficient access to data in the table
  • DynamoDB Table classes currently support
    • DynamoDB Standard table class is the default and is recommended for the vast majority of workloads.
    • DynamoDB Standard-Infrequent Access (DynamoDB Standard-IA) table class which is optimized for tables where storage is the dominant cost.
  • supports Secondary Indexes
    • allows querying attributes other than the primary key attributes without impacting performance.
    • are automatically maintained as sparse objects
  • Local secondary index vs Global secondary index
    • shares partition key + different sort key vs different partition + sort key
    • search limited to partition vs across all partition
    • unique attributes vs non-unique attributes
    • linked to the base table vs independent separate index
    • only created during the base table creation vs can be created later
    • cannot be deleted after creation vs can be deleted
    • consumes provisioned throughput capacity of the base table vs independent throughput
    • returns all attributes for item vs only projected attributes
    • Eventually or Strongly vs Only Eventually consistent reads
    • size limited to 10Gb per partition vs unlimited
  • DynamoDB Consistency
    • provides Eventually consistent (by default) or Strongly Consistent option to be specified during a read operation
    • supports Strongly consistent reads for a few operations like Query, GetItem, and BatchGetItem using the ConsistentRead parameter
  • DynamoDB Throughput Capacity
    • supports On-demand and Provisioned read/write capacity modes
    • Provisioned mode requires the number of reads and writes per second as required by the application to be specified
    • On-demand mode provides flexible billing option capable of serving thousands of requests per second without capacity planning
    • On-demand pricing reduced by 50% in November 2024
    • supports switching from provisioned to on-demand up to 4 times in a rolling 24-hour period (2025 improvement)
  • DynamoDB Auto Scaling helps dynamically adjust provisioned throughput capacity on your behalf, in response to actual traffic patterns.
  • DynamoDB Adaptive capacity is a feature that enables DynamoDB to run imbalanced workloads indefinitely.
  • DynamoDB Global Tables
    • provide multi-active, cross-region replication capability of DynamoDB to support data access locality and regional fault tolerance for database workloads.
    • provide up to 99.999% availability
    • Multi-Region Strong Consistency (MRSC) – GA June 2025
      • enables applications to always read the latest version of data from any Region in a global table
      • provides zero RPO (Recovery Point Objective) for the highest application resilience
      • removes the need to manage consistency across multiple Regions manually
      • slightly higher write latencies compared to eventually consistent (MREC) mode
    • Global tables pricing reduced by up to 67% in November 2024
  • DynamoDB Streams provides a time-ordered sequence of item-level changes made to data in a table
  • DynamoDB Time to Live (TTL)
    • enables a per-item timestamp to determine when an item expiry
    • expired items are deleted from the table without consuming any write throughput.
  • DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x performance improvement – from milliseconds to microseconds – even at millions of requests per second.
  • DynamoDB Triggers (just like database triggers) are a feature that allows the execution of custom actions based on item-level updates on a table.
  • VPC Gateway Endpoints provide private access to DynamoDB from within a VPC without the need for an internet gateway or NAT gateway.
  • DynamoDB Zero-ETL Integrations
    • Zero-ETL with Amazon Redshift (GA October 2024) – automatically replicates DynamoDB tables into Redshift for SQL analytics without building ETL pipelines
    • Zero-ETL with Amazon OpenSearch Service – provides seamless, code-free data replication for vector search and near real-time analytics
    • enables analytics on DynamoDB data without impacting production workload performance

ElastiCache

  • managed web service that provides in-memory caching to deploy and run Valkey, Redis OSS, or Memcached protocol-compliant cache clusters
  • ElastiCache for Valkey (Recommended – default since October 2024)
    • Valkey is an open-source fork of Redis OSS 7.2, maintained by the Linux Foundation with contributions from AWS, Google, Microsoft, and others
    • is a drop-in replacement for Redis OSS – supports the same data structures, commands, and protocols
    • all features available with Redis OSS 7.2 are available in Valkey 7.2 and above
    • AWS recommends Valkey for new deployments and offers migration paths from existing Redis OSS clusters
    • like Redis OSS, supports Multi-AZ, Read Replicas and Snapshots
    • supports cluster mode for horizontal scaling
  • ElastiCache with Redis OSS
    • available up to version 7.1 (the last BSD-licensed release); now a maintenance track with no active new feature development from AWS
    • Redis 8.0+ is licensed under AGPLv3, which is not supported by ElastiCache
    • Standard support for versions 4 and 5 ends January 31, 2026; clusters will be enrolled in Extended Support after that date
    • like RDS, supports Multi-AZ, Read Replicas and Snapshots
    • Read Replicas are created across AZ within same region using Redis’s asynchronous replication technology
    • Multi-AZ differs from RDS as there is no standby, but if the primary goes down a Read Replica is promoted as primary
    • allows snapshots for backup and restore
    • AOF can be enabled for recovery scenarios, to recover the data in case the node fails or service crashes. But it does not help in case the underlying hardware fails
    • Enabling Redis Multi-AZ as a Better Approach to Fault Tolerance
  • ElastiCache with Memcached
    • can be scaled up by increasing size and scaled out by adding nodes
    • nodes can span across multiple AZs within the same region
    • cached data is spread across the nodes, and a node failure will always result in some data loss from the cluster
    • supports auto discovery
    • every node should be homogenous and of same instance type
  • ElastiCache Valkey/Redis vs Memcached
    • complex data objects vs simple key value storage
    • persistent vs non persistent, pure caching
    • automatic failover with Multi-AZ vs Multi-AZ not supported
    • scaling using Read Replicas vs using multiple nodes
    • backup & restore supported vs not supported
  • ElastiCache Serverless (launched November 2023)
    • creates a cache in under a minute with zero capacity planning
    • instantly scales capacity based on application traffic patterns
    • provides zero infrastructure management and zero downtime maintenance
    • supports Valkey 7.2+, Redis OSS 7.0+, and Memcached 1.6+
    • pay-per-use pricing based on data stored and requests executed
    • automatically provisions resources across multiple AZs for high availability
  • can be used for state management to keep the web application stateless

Redshift

  • fully managed, fast and powerful, petabyte scale data warehouse service
  • uses replication and continuous backups to enhance availability and improve data durability and can automatically recover from node and component failures
  • provides Massive Parallel Processing (MPP) by distributing & parallelizing queries across multiple physical resources
  • columnar data storage improving query performance and allowing advance compression techniques
  • now supports Multi-AZ deployments for RA3 clusters (GA 2024), running the data warehouse in two AZs simultaneously with 99.99% SLA
  • spot instances are NOT an option
  • Redshift Serverless
    • enables running and scaling analytics without provisioning or managing clusters
    • automatically scales compute up or down based on workload demands
    • AI-driven scaling and optimization (default for new workgroups since April 2026) uses machine learning to predict compute needs and automatically adjust resources
    • offers minimum capacity as low as 4 RPUs for cost-effective development workloads
    • supports Serverless Reservations (2025) for discounted pricing and cost predictability
    • pay-as-you-go pricing based on compute used
  • Zero-ETL Integrations
    • supports zero-ETL from Aurora MySQL, Aurora PostgreSQL, RDS for MySQL, DynamoDB, and self-managed databases
    • automatically replicates data from source to Redshift without building ETL pipelines
    • enables near real-time analytics on transactional data
  • Enhanced Security Defaults (2025)
    • new clusters default to public accessibility disabled, encryption enabled, and secure connections enforced

AWS RDS Proxy – Connection Pooling & IAM Auth

RDS Proxy
~ Last updated on : ~ jayendrapatil ~ 2 Comments

AWS RDS Proxy

  • fully managed, highly available database proxy for RDS that makes applications more secure, scalable, more resilient to database failures.
  • allows apps to pool and share DB connections established with the database
  • improves database efficiency by reducing stress on the database resources (e.g. CPU, RAM) by minimizing open connections and creation of new connections.
  • is serverless and scales automatically to accommodate your workload.
  • is highly available and deployed across multiple Availability Zones.
  • increases resiliency to database failures by automatically connecting to a standby DB instance while preserving application connections.
  • reduces RDS and Aurora failover time by up to 66%.
  • protects the database against oversubscription by providing control over the number of database connections that are created.
  • queues or throttles application connections that can’t be served immediately from the pool of connections.
  • supports RDS (MySQL, PostgreSQL, MariaDB, SQL Server) and Aurora (MySQL, PostgreSQL)
  • does NOT support RDS for Oracle or RDS for Db2.
  • is fully managed and there is no need to provision or manage any additional infrastructure.
  • required no code changes for most apps, just need to point to the RDS proxy endpoint instead of the RDS endpoint
  • enforce IAM Authentication for DB, and securely store credentials in AWS Secrets Manager
  • is never publicly accessible (must be accessed from VPC)
  • is priced per vCPU per hour of the underlying database instances (for provisioned) or per ACU per hour (for Aurora Serverless v2).

RDS Proxy

RDS Proxy Connection Pooling & Multiplexing

  • RDS Proxy maintains a pool of established connections to the database and reuses connections in this pool.
  • uses transaction-level multiplexing — by default, it can reuse a connection after each transaction in a session (called “borrowing” the connection).
  • translates a large number of client connections into a much smaller number of back-end database connections.
  • reduces the memory and CPU overhead for connection management on the database.
  • Connection pinning occurs when session state changes (e.g., SET statements, prepared statements, temporary tables) that cannot be shared. Pinned connections cannot be reused until the session ends.
  • to avoid pinning, move session configuration to the proxy’s initialization query or use session-state-compatible patterns.

RDS Proxy Endpoints

  • RDS Proxy supports creating additional endpoints beyond the default read/write endpoint.
  • Read-only endpoints route queries to Aurora Replicas or RDS read replicas, providing read scalability.
  • Cross-VPC endpoints allow accessing the proxy from a different VPC than the one the proxy resides in.
  • each endpoint has its own set of CloudWatch metrics for monitoring.
  • endpoints support IPv4, IPv6, or dual-stack network types.

RDS Proxy High Availability & Failover

  • reduces failover times for Aurora and RDS Multi-AZ databases by up to 66% by bypassing DNS cache propagation delays.
  • automatically connects to the new primary instance during failover while preserving application connections.
  • supports RDS Multi-AZ with two readable standbys for typically under 35-second failovers, 2x improved write latency, added read capacity, and reduced minor version upgrade downtime to typically under 1 second.
  • supports Blue/Green Deployments (since April 2026) — RDS Proxy actively monitors database instances during a Blue/Green Deployment switchover and automatically redirects connections to the Green environment, eliminating DNS propagation delays. Supported for RDS for PostgreSQL, RDS for MySQL, and RDS for MariaDB.

RDS Proxy IPv6 Support

  • RDS Proxy supports IPv6 (since September 2025), allowing applications to pool and share database connections using IPv6 addresses.
  • existing IPv4 endpoints remain available for backwards compatibility.
  • database must be configured for dual-stack mode to support IPv6 connections from the proxy.
  • endpoint network type can be set to IPV4, IPV6, or DUAL.

RDS Proxy Security

  • enforces IAM authentication for database access, eliminating hard-coded credentials in application code.
  • integrates with AWS Secrets Manager for centralized database credential management.
  • supports IAM authentication for both client-to-proxy and proxy-to-database connections (removing the need to store passwords in Secrets Manager).
  • is never publicly accessible — all connections must originate from within the VPC.
  • supports TLS/SSL connections between the application and the proxy.

RDS Proxy Use Cases

  • Serverless applications (Lambda) — Lambda functions create many short-lived connections; RDS Proxy pools them efficiently, preventing “too many connections” errors.
  • Unpredictable workloads — connection governance gracefully scales applications dealing with burst connection patterns.
  • Applications with idle connections — SaaS/eCommerce apps keep connections open for responsiveness; RDS Proxy holds idle connections without overprovisioning the database.
  • Applications requiring high availability — transparently tolerates database failures and routes traffic to new instances.
  • Multi-tenant SaaS — connection pooling supports multiple tenants efficiently with separate proxy endpoints per tenant or workload.

RDS Proxy Availability

  • available in most AWS Regions including AWS GovCloud (US-East and US-West) regions (since April 2025).
  • expanded to Asia Pacific (Malaysia), Asia Pacific (Thailand), and Mexico (Central) regions (April 2025).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company migrated one of its business-critical database workloads to an Amazon Aurora Multi-AZ DB cluster. The company requires a very low RTO and needs to improve the application recovery time after database failover. Which approach meets these requirements?
    1. Set the max_connections parameter to 16,000 in the instance-level parameter group.
    2. Modify the client connection timeout to 300 seconds.
    3. Create an Amazon RDS Proxy database proxy and update client connections to point to the proxy endpoint.
    4. Enable the query cache at the instance level.
  2. A company is running a serverless application on AWS Lambda that stores data in an Amazon RDS for MySQL DB instance. Usage has steadily increased, and recently there have been numerous “too many connections” errors when the Lambda function attempts to connect to the database. The company already has configured the database to use the maximum max_connections value that is possible. What should a SysOps administrator do to resolve these errors?
    1. Create a read replica of the database. Use Amazon Route 53 to create a weighted DNS record that contains both databases.
    2. Use Amazon RDS Proxy to create a proxy. Update the connection string in the Lambda function.
    3. Increase the value in the max_connect_errors parameter in the parameter group that the database uses.
    4. Update the Lambda function’s reserved concurrency to a higher value.
  3. A company needs to perform a major version upgrade on an Amazon Aurora MySQL cluster with minimal downtime. The cluster uses Amazon RDS Proxy for connection management. Which approach minimizes application disruption during the upgrade?
    1. Perform a direct in-place major version upgrade during the maintenance window.
    2. Create a new Aurora cluster, manually migrate data, and switch DNS records.
    3. Use Amazon RDS Blue/Green Deployments with RDS Proxy to perform the upgrade and switchover with minimal downtime.
    4. Take a snapshot, restore to a new cluster with the target version, and update the proxy target.
  4. A development team is building a multi-tenant SaaS application using AWS Lambda and Amazon Aurora PostgreSQL. Different tenants have different query patterns — some tenants perform heavy reads while others perform heavy writes. How should the team configure RDS Proxy to optimize performance?
    1. Create a single proxy with a large connection pool and use Lambda reserved concurrency to limit connections.
    2. Create separate Aurora clusters for each tenant with their own RDS Proxy.
    3. Create a single proxy with both a read/write default endpoint and additional read-only endpoints to route read traffic to Aurora Replicas.
    4. Disable connection multiplexing in RDS Proxy to ensure session affinity for each tenant.
  5. A company has an application using Amazon RDS Proxy with an Aurora PostgreSQL cluster. After deploying a new application version, they notice increased latency and CloudWatch shows high DatabaseConnectionsCurrentlySessionPinned metrics. What is the most likely cause and solution?
    1. The database is undersized; scale up the instance.
    2. The proxy has too few connections in the pool; increase MaxConnectionsPercent.
    3. The new application code uses session-level settings (SET statements or prepared statements) that cause connection pinning, reducing multiplexing efficiency. Move session configuration to the proxy’s initialization query.
    4. The proxy endpoint is misconfigured; recreate the proxy.

References

AWS RDS Monitoring & Notification

~ Last updated on : ~ jayendrapatil ~ 9 Comments

AWS RDS Monitoring & Notification

  • RDS integrates with CloudWatch and provides metrics for monitoring
  • CloudWatch alarms can be created over a single metric that sends an SNS message when the alarm changes state
  • RDS also provides SNS notification whenever any RDS event occurs
  • RDS events are also delivered natively to Amazon EventBridge, enabling advanced event-driven automation and routing to multiple targets beyond SNS.
  • RDS Performance Insights is a database performance tuning and monitoring feature that helps illustrate the database’s performance and help analyze any issues that affect it
  • CloudWatch Database Insights is the successor to Performance Insights, providing comprehensive database observability with fleet-wide monitoring, on-demand analysis, and advanced diagnostics.
  • RDS Recommendations provides automated recommendations for database resources.
  • Amazon DevOps Guru for RDS uses machine learning to detect anomalous database behaviors and provide proactive insights.
  • AWS Compute Optimizer for RDS provides rightsizing recommendations for RDS DB instances.

RDS CloudWatch Monitoring

  • RDS DB instance can be monitored using CloudWatch, which collects and processes raw data from RDS into readable, near real-time metrics.
  • Statistics are recorded so that you can access historical information and gain a better perspective on how the service is performing.
  • By default, RDS metric data is automatically sent to CloudWatch in 1-minute periods
  • CloudWatch RDS Metrics
    • BinLogDiskUsage – Amount of disk space occupied by binary logs on the master. Applies to MySQL read replicas.
    • CPUUtilization – Percentage of CPU utilization.
    • CPUCreditBalance – Number of CPU credits available (for burstable instance types like db.t3, db.t4g).
    • CPUCreditUsage – Number of CPU credits consumed (for burstable instance types).
    • DatabaseConnections – Number of database connections in use.
    • DiskQueueDepth – The number of outstanding IOs (read/write requests) waiting to access the disk.
    • EBSIOBalance% – Percentage of I/O credits remaining in the burst bucket (for instances with burst I/O capability).
    • EBSByteBalance% – Percentage of throughput credits remaining in the burst bucket.
    • FreeableMemory – Amount of available random access memory.
    • FreeStorageSpace – Amount of available storage space.
    • ReplicaLag – Amount of time a Read Replica DB instance lags behind the source DB instance.
    • SwapUsage – Amount of swap space used on the DB instance.
    • ReadIOPS – Average number of disk I/O operations per second.
    • WriteIOPS – Average number of disk I/O operations per second.
    • ReadLatency – Average amount of time taken per disk I/O operation.
    • WriteLatency – Average amount of time taken per disk I/O operation.
    • ReadThroughput – Average number of bytes read from disk per second.
    • WriteThroughput – Average number of bytes written to disk per second.
    • NetworkReceiveThroughput – Incoming (Receive) network traffic on the DB instance, including both customer database traffic and Amazon RDS traffic used for monitoring and replication.
    • NetworkTransmitThroughput – Outgoing (Transmit) network traffic on the DB instance, including both customer database traffic and Amazon RDS traffic used for monitoring and replication.

RDS Enhanced Monitoring

  • RDS provides metrics in real-time for the operating system (OS) that the DB instance runs on.
  • Enhanced Monitoring uses an agent on the instance to collect OS-level metrics with granularity as fine as 1 second (options: 1, 5, 10, 15, 30, or 60 seconds).
  • By default, Enhanced Monitoring metrics are stored for 30 days in the CloudWatch Logs, which are different from typical CloudWatch metrics.
  • Enhanced Monitoring metrics can be consumed from CloudWatch Logs and imported into CloudWatch as custom metrics for alarming and dashboarding.
  • Enhanced Monitoring is disabled by default; it can be enabled when creating or modifying a DB instance.
  • Enhanced Monitoring requires an IAM role to publish metrics to CloudWatch Logs.

CloudWatch vs Enhanced Monitoring Metrics

  • CloudWatch gathers metrics about CPU utilization from the hypervisor for a DB instance, and Enhanced Monitoring gathers its metrics from an agent on the instance.
  • Enhanced Monitoring metrics are useful to understand how different processes or threads on a DB instance use the CPU.
  • There might be differences between the measurements because the hypervisor layer performs a small amount of work. The differences can be greater if the DB instances use smaller instance classes because then there are likely more virtual machines (VMs) that are managed by the hypervisor layer on a single physical instance.

RDS Performance Insights

⚠️ End-of-Life Notice: AWS has announced Performance Insights will reach End of Life on July 31, 2026. After this date, the Performance Insights console experience, flexible retention periods (1-24 months), and their associated pricing will no longer be available. The Performance Insights API will continue to exist with no pricing changes.

Migration: Users should transition to CloudWatch Database Insights. If you don’t upgrade, DB instances using Performance Insights will default to the Standard mode of Database Insights.

  • Performance Insights is a database performance tuning and monitoring feature that helps check the database’s performance and helps analyze any issues that affect it.
  • Database load is measured using a metric called Average Active Sessions or AAS which is calculated by sampling memory to determine the state of each active database connection.
  • AAS is the total number of sessions divided by the total number of samples for a specific time period.
  • Performance Insights help visualize the database load and filter the load by waits, SQL statements, hosts, or users.
  • Supported on Amazon Aurora (MySQL and PostgreSQL), RDS for MySQL, RDS for PostgreSQL, RDS for Oracle, RDS for SQL Server, and RDS for MariaDB.

CloudWatch Database Insights

  • CloudWatch Database Insights is the next-generation database monitoring service that replaces and extends Performance Insights capabilities.
  • Provides comprehensive database observability for Amazon Aurora and Amazon RDS databases at scale.
  • Database Insights has two modes:
    • Standard Mode (default) – Analyze top contributors to DB load by dimension, query/graph/set alarms on metrics with up to 7 days retention, and define fine-grained access control policies.
    • Advanced Mode – Adds fleet-wide monitoring dashboards, SQL lock analysis (15 months retention), execution plan analysis, per-query statistics, slow SQL query analysis, on-demand performance analysis with ML-powered insights, viewing RDS events in CloudWatch, and cross-account cross-region monitoring.
  • Advanced mode retains 15 months of all metrics collected by Database Insights automatically.
  • On-demand analysis uses machine learning to compare a selected time period against normal baseline performance, identify anomalies, and provide specific remediation advice.
  • Fleet Health Dashboard enables monitoring databases simultaneously across hundreds of instances.
  • Supports cross-account and cross-region monitoring for centralized observability.
  • Integrates with CloudWatch Application Signals to view calling services.

RDS CloudTrail Logs

  • CloudTrail provides a record of actions taken by a user, role, or an AWS service in RDS.
  • CloudTrail captures all API calls for RDS as events, including calls from the console and from code calls to RDS API operations.
  • CloudTrail can help determine the request that was made to RDS, the IP address from which the request was made, who made the request, when it was made, and additional details.

RDS Database Activity Streams

  • Database Activity Streams provide a near real-time stream of database activity for monitoring and auditing purposes.
  • Activity data is collected and transmitted to Amazon Kinesis Data Streams.
  • From Kinesis, you can configure services such as Amazon Data Firehose and AWS Lambda to consume the stream and store the data.
  • Provides a protection mechanism for compliance and auditing, independent of the database itself (DBA cannot tamper with the audit logs).
  • Supports two modes:
    • Asynchronous mode – prioritizes database performance; activity stream events may be lost if the Kinesis stream becomes unavailable.
    • Synchronous mode – prioritizes accuracy of activity stream; database session may block until the event is written to the stream.
  • Uses AWS KMS for encryption of the activity stream.
  • Supported for RDS for Oracle, RDS for SQL Server (Multi-AZ), and Amazon Aurora.
  • Integrates with third-party database activity monitoring (DAM) tools for compliance.

RDS Recommendations

  • RDS provides automated recommendations for database resources.
  • The recommendations provide best practice guidance by analyzing DB instance configuration, usage, and performance data.
  • Recommendations cover areas such as:
    • DB instance class rightsizing
    • DB parameter group settings
    • Security best practices
    • Engine version upgrades
    • Backup and recovery configuration
    • Multi-AZ deployment enablement
  • Recommendations can be automated with notifications using EventBridge and Lambda.

Amazon DevOps Guru for RDS

  • Amazon DevOps Guru for RDS is an ML-powered capability that detects, diagnoses, and remediates database performance issues.
  • Uses data collected by Performance Insights to detect anomalous behaviors.
  • Provides both Reactive Insights (when issues are occurring) and Proactive Insights (before issues impact performance).
  • Proactive Insights detect potential issues that can lead to degraded database health in the future, such as:
    • Connections approaching configured limits
    • Memory nearing exhaustion
    • Idle transactions consuming resources
  • Provides detailed analysis of wait events and recommendations for remediation.
  • Requires Performance Insights to be enabled with a paid tier retention period.
  • Supported for Amazon Aurora (PostgreSQL and MySQL) and RDS for PostgreSQL.

AWS Compute Optimizer for RDS

  • AWS Compute Optimizer analyzes RDS database instance utilization metrics and provides rightsizing recommendations.
  • Helps identify idle RDS instances and choose the optimal DB instance class and provisioned IOPS settings.
  • Recommendations help reduce costs for over-provisioned workloads and increase performance for under-provisioned workloads.
  • Supports Amazon Aurora, RDS for MySQL, RDS for PostgreSQL, RDS for Oracle, RDS for SQL Server, and RDS for MariaDB.
  • Evaluates Graviton-based instance classes for improved price-performance ratios.
  • Analyzes the last 14 days of CloudWatch metrics to generate recommendations.

RDS Event Notification

  • RDS uses the SNS to provide notification when an RDS event occurs
  • RDS groups the events into categories, which can be subscribed so that a notification is sent when an event in that category occurs.
  • Event category for a DB instance, DB cluster, DB snapshot, DB cluster snapshot, DB security group, or for a DB parameter group can be subscribed
  • Event notifications are sent to the email addresses provided during subscription creation
  • Subscriptions can be easily turned off without deleting a subscription by setting the Enabled radio button to No in the RDS console or by setting the Enabled parameter to false using the CLI or RDS API.

RDS Events with Amazon EventBridge

  • Amazon RDS sends service events directly to Amazon EventBridge in near real time.
  • EventBridge provides more flexible event routing compared to traditional SNS-based event subscriptions.
  • EventBridge rules can be used to react to RDS events and trigger automated workflows, such as:
    • Lambda functions for custom notification formatting
    • Step Functions for complex remediation workflows
    • SNS topics for multi-channel alerting
    • SQS queues for event buffering and processing
  • Supports event patterns for filtering specific RDS event types (e.g., failovers, reboots, maintenance).
  • Can be combined with RDS native event notifications for comprehensive event management.

RDS Trusted Advisor

  • Trusted Advisor inspects the AWS environment and then makes recommendations when opportunities exist to save money, improve system availability and performance, or help close security gaps.
  • Trusted Advisor now evaluates across six categories: cost optimization, performance, resilience, security, operational excellence, and service limits.
  • Trusted Advisor has the following RDS-related checks:
    • RDS Idle DB Instances
    • RDS Security Group Access Risk
    • RDS Backups
    • RDS Multi-AZ
    • RDS Idle DB Connections
    • RDS Overutilized DB Instances
    • RDS Continuous Backup Not Enabled

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You run a web application with the following components Elastic Load Balancer (ELB), 3 Web/Application servers, 1 MySQL RDS database with read replicas, and Amazon Simple Storage Service (Amazon S3) for static content. Average response time for users is increasing slowly. What three CloudWatch RDS metrics will allow you to identify if the database is the bottleneck? Choose 3 answers
    1. The number of outstanding IOs waiting to access the disk
    2. The amount of write latency
    3. The amount of disk space occupied by binary logs on the master.
    4. The amount of time a Read Replica DB Instance lags behind the source DB Instance
    5. The average number of disk I/O operations per second.
  2. Typically, you want your application to check whether a request generated an error before you spend any time processing results. The easiest way to find out if an error occurred is to look for an __________ node in the response from the Amazon RDS API.
    1. Incorrect
    2. Error
    3. FALSE
  3. In the Amazon CloudWatch, which metric should I be checking to ensure that your DB Instance has enough free storage space?
    1. FreeStorage
    2. FreeStorageSpace
    3. FreeStorageVolume
    4. FreeDBStorageSpace
  4. A user is receiving a notification from the RDS DB whenever there is a change in the DB security group. The user does not want to receive these notifications for only a month. Thus, he does not want to delete the notification. How can the user configure this?
    1. Change the Disable button for notification to “Yes” in the RDS console
    2. Set the send mail flag to false in the DB event notification console
    3. The only option is to delete the notification from the console
    4. Change the Enable button for notification to “No” in the RDS console
  5. A sys admin is planning to subscribe to the RDS event notifications. For which of the below mentioned source categories the subscription cannot be configured?
    1. DB security group
    2. DB snapshot
    3. DB options group
    4. DB parameter group
  6. A user is planning to setup notifications on the RDS DB for a snapshot. Which of the below mentioned event categories is not supported by RDS for this snapshot source type?
    1. Backup (Refer link)
    2. Creation
    3. Deletion
    4. Restoration
  7. A system admin is planning to setup event notifications on RDS. Which of the below mentioned services will help the admin setup notifications?
    1. AWS SES
    2. AWS Cloudtrail
    3. AWS CloudWatch
    4. AWS SNS
  8. A user has setup an RDS DB with Oracle. The user wants to get notifications when someone modifies the security group of that DB. How can the user configure that?
    1. It is not possible to get the notifications on a change in the security group
    2. Configure SNS to monitor security group changes
    3. Configure event notification on the DB security group
    4. Configure the CloudWatch alarm on the DB for a change in the security group
  9. It is advised that you watch the Amazon CloudWatch “_____” metric (available via the AWS Management Console or Amazon Cloud Watch APIs) carefully and recreate the Read Replica should it fall behind due to replication errors.
    1. Write Lag
    2. Read Replica
    3. Replica Lag
    4. Single Replica
  10. A company wants to monitor its RDS database for performance anomalies using machine learning without setting up complex monitoring rules. Which AWS service provides ML-powered anomaly detection specifically for RDS databases?
    1. Amazon CloudWatch Anomaly Detection
    2. AWS Trusted Advisor
    3. Amazon DevOps Guru for RDS
    4. Amazon Inspector
  11. A database administrator needs to audit all SQL activities on an Amazon RDS for Oracle database for compliance requirements. The audit logs must be tamper-proof and cannot be modified by database administrators. Which feature should be used?
    1. Enhanced Monitoring
    2. CloudTrail Logs
    3. Performance Insights
    4. Database Activity Streams
  12. An organization is transitioning from RDS Performance Insights to the new monitoring solution. Which AWS service is the designated successor providing fleet-wide monitoring, on-demand ML-powered analysis, and lock diagnostics for RDS databases?
    1. Amazon DevOps Guru for RDS
    2. AWS Compute Optimizer
    3. Amazon CloudWatch Database Insights
    4. Amazon Managed Grafana
  13. A company needs to receive RDS events and trigger automated remediation workflows using Step Functions when a failover occurs. Which service should be used to capture RDS events and route them to the Step Function?
    1. Amazon SNS
    2. Amazon CloudWatch Alarms
    3. Amazon EventBridge
    4. AWS CloudTrail
  14. Which of the following is true about the difference between CloudWatch metrics and Enhanced Monitoring for RDS? (Choose 2)
    1. CloudWatch collects metrics from the hypervisor while Enhanced Monitoring collects from an agent on the instance
    2. Enhanced Monitoring provides metrics at 5-minute intervals only
    3. Enhanced Monitoring is useful for understanding how different processes or threads use the CPU
    4. CloudWatch provides more granular OS-level metrics than Enhanced Monitoring

AWS RDS DB Maintenance & Upgrades

~ Last updated on : ~ jayendrapatil

RDS DB Maintenance and Upgrades

  • Changes to a DB instance can occur when a DB instance is manually modified for e.g. DB engine version is upgraded, or when RDS performs maintenance on an instance

RDS Maintenance

  • RDS performs periodic maintenance on RDS resources, such as DB instances, and most often involves updates to the DB instance’s operating system (OS).
  • Maintenance items can either
    • be applied manually on a DB instance at one’s convenience
    • or wait for the automatic maintenance process initiated by RDS during the defined weekly maintenance window.
  • Maintenance window only determines when pending operations start but does not limit the total execution time of these operations.
  • Maintenance operations are not guaranteed to finish before the maintenance window ends and can continue beyond the specified end time.
  • Maintenance update availability can be checked both on the RDS console and by using the RDS API. And if an update is available, one can
    • Defer the maintenance items.
    • Apply the maintenance items immediately.
    • Schedule them to start during the next defined maintenance window
  • Maintenance items marked as
    • Required cannot be deferred indefinitely, if deferred AWS will send a notify the time when the update will be performed next
    • Available and can be deferred indefinitely and the update will not be applied to the DB instance.
  • Required patching is automatically scheduled only for patches that are related to security and instance reliability. Such patching occurs infrequently (typically once every few months) and seldom requires more than a fraction of your maintenance window.
  • Maintenance items require that RDS take the DB instance offline for a short time. Maintenance that requires DB instances to be offline includes scale compute operations, which generally take only a few minutes from start to finish, and required operating system or database patching.
  • Multi-AZ deployment for the DB instance reduces the impact of a maintenance event by following these steps:
    • Perform maintenance on standby.
    • Promote the standby to primary.
    • Perform maintenance on the old primary, which becomes the new standby.
  • When the database engine for the DB instance is modified in a Multi-AZ deployment, RDS upgrades both the primary and secondary DB instances at the same time. In this case, the database engine for the entire Multi-AZ deployment is shut down during the upgrade.

Multi-AZ DB Cluster Maintenance (Two Readable Standbys)

  • RDS Multi-AZ DB clusters (with two readable standbys) provide significantly reduced downtime during maintenance compared to traditional Multi-AZ DB instances.
  • Minor version upgrades and system maintenance updates can be completed with typically 35 seconds or less of downtime using Multi-AZ DB clusters.
  • Downtime can be further reduced to typically 1 second or less when combined with:
    • Amazon RDS Proxy
    • AWS Advanced JDBC Wrapper Driver
    • PgBouncer (for PostgreSQL)
    • ProxySQL (for MySQL)
  • During maintenance on a Multi-AZ DB cluster:
    • Maintenance is applied to the reader instances first
    • One of the reader instances is promoted to writer
    • Maintenance is then applied to the former writer
    • The process results in an automatic failover with minimal downtime

Operating System Updates

  • Upgrades to the operating system are most often for security issues and should be done as soon as possible.
  • OS updates on a DB instance can be applied at one’s convenience or can wait for the maintenance process initiated by RDS to apply the update during the defined maintenance window
  • DB instance is not automatically backed up when an OS update is applied and should be backup up before the update is applied

Database Engine Version Upgrade

  • DB instance engine version can be upgraded when a new DB engine version is supported by RDS.
  • Database version upgrades consist of major and minor version upgrades.
    • Major database version upgrades
      • can contain changes that are not backward-compatible
      • RDS doesn’t apply major version upgrades automatically
      • DB instance should be manually modified and thoroughly tested before applying it to the production instances.
      • RDS Blue/Green Deployments can be used to perform major version upgrades with minimal downtime (typically under 5 seconds with direct endpoint connections, or under 2 seconds with AWS Advanced JDBC Driver).
    • Minor version upgrades
      • Each DB engine handles minor version upgrade slightly differently
        for e.g. RDS automatically apply minor version upgrades to a DB instance running PostgreSQL, but must be manually applied to a DB instance running Oracle.
      • Auto Minor Version Upgrade (AmVU) setting controls whether RDS automatically applies minor version upgrades during the maintenance window.
      • In cases of critical security issues or when a version reaches its end-of-support date, RDS might apply a minor version upgrade even if Auto Minor Version Upgrade is disabled.
  • Amazon posts an announcement to the forums announcement page and sends a customer e-mail notification before upgrading an DB instance
  • Amazon schedule the upgrades at specific times through the year, to help plan around them, because downtime is required to upgrade a DB engine version, even for Multi-AZ instances.
  • RDS takes two DB snapshots during the upgrade process.
    • First DB snapshot is of the DB instance before any upgrade changes have been made. If the upgrade fails, it can be restored from the snapshot to create a DB instance running the old version.
    • Second DB snapshot is taken when the upgrade completes. After the upgrade is complete, database engine can’t be reverted to the previous version. For returning to the previous version, restore the first DB snapshot taken to create a new DB instance.
  • If the DB instance is using read replication, all of the Read Replicas must be upgraded before upgrading the source instance.
  • If the DB instance is in a Multi-AZ deployment, both the primary and standby replicas are upgraded at the same time and would result in an outage. The time for the outage varies based on your database engine, version, and the size of your DB instance.

AWS Organizations Upgrade Rollout Policy

  • AWS Organizations now supports upgrade rollout policies to centrally manage and stagger automatic minor version upgrades across multiple database resources and AWS accounts.
  • Allows defining upgrade sequences using simple orders (first, second, last) applied through account-level policies or resource tags.
  • When new minor versions become eligible for automatic upgrade, the policy ensures upgrades start with development environments first, allowing validation before proceeding to production.
  • Key features:
    • AWS Health notifications between phases for monitoring progress
    • Built-in validation periods to ensure stability
    • Ability to disable automatic progression at any time if issues are detected
  • Eliminates operational overhead of coordinating upgrades manually or through custom tools across hundreds of resources and accounts.
  • Available in all AWS commercial Regions and AWS GovCloud (US) Regions.
  • Manageable via AWS Management Console, CLI, SDKs, CloudFormation, or CDK.

RDS Maintenance Window

  • Every DB instance has a weekly maintenance window defined during which any system changes are applied.
  • Maintenance window is an opportunity to control when DB instance modifications 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 during the 30-minute maintenance window as defined
  • Maintenance events mostly complete during the 30-minute maintenance window, although larger maintenance events may take more time
  • 30-minute maintenance window is selected at random from an 8-hour block of time per region. If you don’t specify a preferred maintenance window when you create the DB instance, Amazon RDS assigns a 30-minute maintenance window on a randomly selected day of the week.
  • RDS will consume some of the resources on the DB instance while maintenance is being applied, minimally affecting performance.
  • For some maintenance events, a Multi-AZ failover may be required for a maintenance update to be complete.

RDS Blue/Green Deployments for Upgrades and Maintenance

  • RDS Blue/Green Deployments provide a safer and faster method for performing database upgrades and maintenance with minimal downtime.
  • A Blue/Green Deployment creates a staging environment (Green) that mirrors the production environment (Blue) and keeps them synchronized.
  • Supported use cases include:
    • Major version database engine upgrades
    • Minor version upgrades
    • Maintenance updates and OS patching
    • Instance scaling (compute changes)
    • Storage volume shrink (since November 2024) – the only native way to reduce RDS allocated storage
    • Parameter group changes
  • Switchover downtime is typically under 5 seconds for single-Region configurations (as of January 2026).
  • Applications using the AWS Advanced JDBC Driver typically see under 2 seconds of downtime due to eliminated DNS propagation delays.
  • No application endpoint changes are required after switchover.
  • Supported for Amazon Aurora and Amazon RDS engines including PostgreSQL, MySQL, and MariaDB in all AWS regions.
  • For PostgreSQL:
    • Uses physical replication by default for minor version upgrades (faster, lower lag)
    • Uses logical replication when performing major version upgrades
  • Blue/Green Deployments also support Aurora Global Databases (as of November 2025), including primary and all secondary regions.

RDS Extended Support

  • Amazon RDS Extended Support provides up to three additional years of critical security and bug fixes beyond a major version’s end of standard support date.
  • Available for Amazon Aurora MySQL, Aurora PostgreSQL, RDS for MySQL, and RDS for PostgreSQL.
  • Gives flexibility to upgrade, migrate, and transform databases at your own pace while still receiving security fixes from AWS.
  • Key characteristics:
    • Charged as a per vCPU-hour fee in addition to regular RDS instance charges.
    • Pricing increases over time: Year 1 and Year 2 are at the same rate, Year 3 pricing is doubled (approximately).
    • Charges apply to all instances including replicas and standbys in Multi-AZ configurations.
    • Reserved Instance discounts do NOT apply to Extended Support charges.
    • No charge for DB snapshots, but restoring a snapshot to an EOL version will trigger Extended Support enrollment and charges.
  • Automatic enrollment: After a major engine version reaches end of standard support, instances running that version are automatically enrolled in Extended Support and charges begin.
  • Opting out: You can prevent enrollment by specifying open-source-rds-extended-support-disabled for the --engine-lifecycle-support CLI option when creating or restoring instances.
  • Ending enrollment: Upgrade to a newer engine version still under standard support to stop Extended Support charges.
  • Extended Support charges appear as a separate line item on your bill (Usage Type: ‘ExtendedSupport’).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user has launched an RDS MySQL DB with the Multi AZ feature. The user has scheduled the scaling of instance storage during maintenance window. What is the correct order of events during maintenance window? 1. Perform maintenance on standby 2. Promote standby to primary 3. Perform maintenance on original primary 4. Promote original master back as primary
    1. 1, 2, 3, 4
    2. 1, 2, 3
    3. 2, 3, 4, 1
  2. Can I control if and when MySQL based RDS Instance is upgraded to new supported versions?
    1. No
    2. Only in VPC
    3. Yes
  3. A user has scheduled the maintenance window of an RDS DB on Monday at 3 AM. Which of the below mentioned events may force to take the DB instance offline during the maintenance window?
    1. Enabling Read Replica
    2. Making the DB Multi AZ
    3. DB password change
    4. Security patching
  4. A user has launched an RDS postgreSQL DB with AWS. The user did not specify the maintenance window during creation. The user has configured RDS to update the DB instance type from micro to large. If the user wants to have it during the maintenance window, what will AWS do?
    1. AWS will not allow to update the DB until the maintenance window is configured
    2. AWS will select the default maintenance window if the user has not provided it
    3. AWS will ask the user to specify the maintenance window during the update
    4. It is not possible to change the DB size from micro to large with RDS
  5. Can I test my DB Instance against a new version before upgrading?
    1. No
    2. Yes
    3. Only in VPC
  6. A company wants to perform a major version upgrade on their production RDS PostgreSQL database with minimal downtime. Which approach provides the least downtime?
    1. Perform an in-place major version upgrade during the maintenance window
    2. Use RDS Blue/Green Deployments to create a staging environment with the new version and switchover
    3. Create a read replica, promote it, and point the application to it
    4. Take a snapshot, restore it with the new engine version, and switch DNS
  7. An organization is managing hundreds of RDS instances across multiple AWS accounts. They want automatic minor version upgrades to roll out to development environments first before production. Which feature should they use?
    1. AWS Systems Manager Maintenance Windows
    2. RDS Blue/Green Deployments
    3. AWS Organizations Upgrade Rollout Policy
    4. AWS Config remediation rules
  8. A company is running RDS for PostgreSQL 11 which has reached end of standard support. They are not ready to upgrade to a newer version. What happens if they take no action?
    1. The database will be terminated after 90 days
    2. The database will be automatically upgraded to the latest version
    3. The database will be enrolled in RDS Extended Support with additional per-vCPU-hour charges
    4. The database will continue running with no changes or charges
  9. A company uses RDS Multi-AZ DB clusters with two readable standbys and wants to minimize downtime during minor version upgrades. What is the expected downtime?
    1. 5-10 minutes
    2. 1-2 minutes
    3. Typically 35 seconds or less, reducible to under 1 second with RDS Proxy
    4. Zero downtime
  10. Which of the following can be achieved using RDS Blue/Green Deployments? (Select THREE)
    1. Major version engine upgrades
    2. Storage volume shrink
    3. Cross-region replication setup
    4. Instance class scaling
    5. Enabling Multi-AZ on an existing single-AZ instance

References

AWS RDS Storage – gp3, io2, Magnetic, Storage Auto Scaling

~ Last updated on : ~ jayendrapatil ~ 5 Comments

AWS RDS Storage

  • RDS storage uses Elastic Block Store – EBS volumes for database and log storage.
  • RDS automatically stripes across multiple EBS volumes to enhance performance, depending on the amount of storage requested and the database engine.
  • For MariaDB, MySQL, PostgreSQL, and Db2 with 400 GiB or more storage, RDS stripes across 4 volumes. For Oracle, this threshold is 200 GiB. SQL Server does not support volume striping.

RDS Storage Types

  • RDS provides three storage types: Provisioned IOPS SSD (io2 Block Express and io1), General Purpose SSD (gp3 and gp2), and Magnetic (legacy, deprecated).
  • These storage types differ in performance characteristics and price, which allows tailoring of storage performance and cost to the database needs.
  • Db2, MySQL, MariaDB, PostgreSQL RDS DB instances can be created with up to 64 TiB of storage.
  • Oracle and SQL Server RDS DB instances support up to 256 TiB of storage with additional storage volumes (up to 64 TiB per volume, with up to 3 additional volumes).
  • RDS for Db2 doesn’t support the gp2 and magnetic storage types.

⚠️ Magnetic Storage Deprecated

Amazon RDS is deprecating magnetic storage on April 30, 2026.

AWS recommends upgrading magnetic storage volumes to gp3 or io2 before April 29, 2026. After April 29, 2026, Amazon RDS will begin forced migration of magnetic storage volumes to gp3 storage volumes.

The default storage type when restoring snapshots of magnetic volumes will be changed to gp3 by June 1, 2026.

Magnetic (Standard) – Legacy, Deprecated

  • Magnetic storage, also called standard storage, is a legacy storage type maintained only for backward compatibility.
  • AWS recommends using General Purpose SSD (gp3) or Provisioned IOPS SSD (io2) for all new storage needs.
  • Limited to a maximum size of 3 TiB and approximately 1,000 IOPS.
  • Does not support storage autoscaling, elastic volumes, or zero-ETL integrations with Amazon Redshift.
  • Does not allow storage type conversion or scaling when using the SQL Server database engine.
  • Magnetic storage is not reserved for a single DB instance, so performance can vary greatly depending on the demands placed on shared resources by other customers.

General Purpose SSD (gp3 – Recommended)

  • General Purpose SSD storage offers cost-effective storage ideal for a broad range of workloads running on medium-sized DB instances.
  • Amazon RDS offers two types of General Purpose storage: gp3 (recommended) and gp2 (previous generation).

gp3 Storage (Recommended)

  • gp3 allows you to customize storage performance independently of storage capacity.
  • Provides a baseline performance of 3,000 IOPS and 125 MiB/s at any volume size.
  • When storage size reaches the striping threshold (400 GiB for MySQL/MariaDB/PostgreSQL/Db2, 200 GiB for Oracle), baseline increases to 12,000 IOPS and 500 MiB/s due to volume striping across 4 volumes.
  • Can provision additional IOPS up to 64,000 IOPS and throughput up to 4,000 MiB/s (for non-SQL Server engines).
  • For SQL Server: up to 16,000 IOPS and 1,000 MiB/s (up to 80,000 IOPS and 2,000 MiB/s with June 2026 update).
  • Storage size ranges from 20 GiB to 65,536 GiB (16,384 GiB for SQL Server per volume).
  • Delivers single-digit millisecond latency consistently 99% of the time.
  • General Purpose gp3 is excellent for development/testing environments and most production workloads that are not latency-sensitive.

gp2 Storage (Previous Generation)

  • gp2 is the previous generation General Purpose SSD storage.
  • Baseline I/O performance of 3 IOPS per GiB, with a minimum of 100 IOPS.
  • Volumes below 1,000 GiB can burst to 3,000 IOPS using I/O credit balance.
  • Maximum of 64,000 IOPS for volumes 4,000 GiB and larger (with striping).
  • Cannot provision IOPS directly – IOPS varies with the allocated storage size.
  • AWS recommends using gp3 for new workloads as it provides predictable baseline performance without relying on burst credits.

Provisioned IOPS SSD (io2 Block Express – Recommended)

  • Provisioned IOPS storage is designed to meet the needs of I/O-intensive workloads, particularly database workloads, that are sensitive to storage performance and consistency in random access I/O throughput.
  • Amazon RDS offers two types of Provisioned IOPS storage: io2 Block Express (recommended) and io1 (previous generation).
  • For any production application that requires fast and consistent I/O performance, Amazon recommends Provisioned IOPS storage.
  • Provisioned IOPS storage is optimized for I/O intensive, online transaction processing (OLTP) workloads that have consistent performance requirements.

io2 Block Express (Recommended)

  • io2 Block Express provides the highest performance within the RDS storage portfolio.
  • Supports up to 256,000 IOPS, 4,000 MiB/s throughput, and up to 64 TiB per volume.
  • Delivers consistent sub-millisecond latency (99.9% of the time) on AWS Nitro-based instances.
  • Provides 99.999% durability (compared to 99.8-99.9% for other volume types).
  • IOPS to storage ratio of up to 1,000:1 on Nitro-based instances (500:1 for non-Nitro).
  • Available at the same price as io1 volumes.
  • You can upgrade from io1 to io2 Block Express without any downtime using the ModifyDBInstance API.
  • RDS delivers within 10 percent of the provisioned IOPS performance 99.9 percent of the time over a given year.

io1 Storage (Previous Generation)

  • io1 is the previous generation Provisioned IOPS storage.
  • Supports up to 256,000 IOPS (64,000 for SQL Server) and up to 4,000 MiB/s throughput.
  • IOPS to storage ratio of up to 50:1.
  • Delivers single-digit millisecond latency consistently 99.9% of the time.
  • AWS recommends upgrading to io2 Block Express for better performance, higher durability, and same cost.

Adding Storage and Changing Storage Type

  • DB instance can be modified to use additional storage and converted to a different storage type.
  • Storage allocated for a DB instance cannot be decreased directly (you cannot reduce the amount of storage on a volume after allocation).
  • Storage Volume Shrink (Nov 2024): Amazon RDS Blue/Green Deployments now supports shrinking storage volumes, allowing you to reduce storage size by creating a green environment with smaller storage and switching over.
  • For SQL Server DB instances, you can scale storage for only the General Purpose SSD (gp3/gp2) and Provisioned IOPS SSD (io1/io2) storage types.
  • During the scaling process, the DB instance will be available for reads and writes, but may experience performance degradation.
  • After modifying storage, you can’t make further storage modifications for 6 hours or until storage optimization has completed, whichever is longer.
  • While storage is being added, nightly backups are suspended and no other RDS operations can take place, including modify, reboot, delete, create Read Replica, and create DB Snapshot.

RDS Storage Autoscaling

  • RDS Storage Autoscaling continuously monitors actual storage consumption and scales capacity up automatically when actual utilization approaches provisioned storage capacity.
  • Enabled by setting a Maximum Storage Threshold – the upper limit to which RDS can automatically scale the storage.
  • RDS automatically increases storage when:
    • Free available space is less than 10% of the allocated storage
    • The low-storage condition lasts at least 5 minutes
    • At least 6 hours have passed since the last storage modification
  • Storage autoscaling increases storage by the greater of: 10 GiB, 10% of currently allocated storage, or the predicted storage growth for the next 7 hours based on the past hour’s growth rate.
  • Works with gp2, gp3, io1, and io2 storage types. Does not work with magnetic storage.
  • Storage autoscaling doesn’t scale storage during the storage-optimization state.
  • Supported for Single-AZ and Multi-AZ DB instances. Multi-AZ DB clusters with two readable standbys do not support native storage autoscaling.

Additional Storage Volumes

  • Available for RDS for Oracle and RDS for SQL Server (announced December 2025).
  • You can attach up to 3 additional storage volumes to your DB instance, in addition to the primary volume.
  • Each additional volume can be up to 64 TiB, enabling a total of up to 256 TiB per DB instance.
  • You can choose between gp3 and io2 storage types for each additional volume independently.
  • Allows mixing different storage types to optimize cost and performance based on data access patterns (e.g., frequently accessed data on io2, archival data on gp3).
  • Additional volumes can be added and removed (but the primary volume cannot be removed).
  • Volume names: For Oracle – rdsdbdata2, rdsdbdata3, rdsdbdata4. For SQL Server – H:, I:, J:.

Dedicated Log Volume (DLV)

  • A Dedicated Log Volume (DLV) stores database transaction logs on a separate volume from the volume containing database tables (announced October 2023).
  • Makes transaction write logging more efficient and consistent by eliminating I/O contention between data and log operations.
  • DLVs are created with a fixed size of 1,024 GiB and 3,000 Provisioned IOPS.
  • Supported only for PIOPS storage (io1 and io2 Block Express). Not supported for General Purpose storage (gp2/gp3).
  • Ideal for databases with large allocated storage, high IOPS requirements, or latency-sensitive workloads.
  • Supported for MariaDB 10.6.7+, MySQL 8.0.28+/8.4.3+, and PostgreSQL 13.10+/14.7+/15.2+/16+.
  • Moves redo logs and binary logs (MySQL/MariaDB) or WAL segments (PostgreSQL) to the separate volume.

Performance Metrics

  • Amazon RDS provides several metrics that can be used to determine how the DB instance is performing.
    • IOPS (ReadIOPS / WriteIOPS)
      • The number of I/O operations completed per second.
      • It is reported as the average IOPS for a given time interval.
      • RDS reports read and write IOPS separately on one minute intervals.
      • Total IOPS is the sum of the read and write IOPS.
      • Typical values for IOPS range from zero to tens of thousands per second.
      • Measured IOPS values are independent of the size of the individual I/O operation.
    • Latency (ReadLatency / WriteLatency)
      • The elapsed time between the submission of an I/O request and its completion.
      • It is reported as the average latency for a given time interval.
      • RDS reports read and write latency separately on one minute intervals in units of seconds.
      • Typical values for latency are in the millisecond (ms) range.
    • Throughput (ReadThroughput / WriteThroughput)
      • The number of bytes per second transferred to or from disk.
      • It is reported as the average throughput for a given time interval.
      • RDS reports read and write throughput separately on one minute intervals using units of bytes per second (B/s).
      • Typical values for throughput range from zero to the I/O channel’s maximum bandwidth.
    • Queue Depth
      • The number of I/O requests in the queue waiting to be serviced.
      • These are I/O requests that have been submitted by the application but have not been sent to the device because the device is busy servicing other I/O requests.
      • It is reported as the average queue depth for a given time interval.
      • RDS reports queue depth in one minute intervals. Typical values for queue depth range from zero to several hundred.
      • Time spent waiting in the queue is a component of Latency and Service Time (not available as a metric).

RDS Storage Facts

  • First time a DB instance is started and accesses an area of disk for the first time, the process can take longer than all subsequent accesses to the same disk area. This is known as the “first touch penalty“. Once an area of disk has incurred the first touch penalty, that area of disk does not incur the penalty again for the life of the instance, even if the DB instance is rebooted, restarted, or the DB instance class changes. Note that a DB instance created from a snapshot, a point-in-time restore, or a read replica is a new instance and does incur this first touch penalty.
  • RDS manages the DB instance and it reserves overhead space on the instance. While the amount of reserved storage varies by DB instance class and other factors, this reserved space can be as much as one or two percent of the total storage.
  • Provisioned IOPS provides a way to reserve I/O capacity by specifying IOPS. Like any other system capacity attribute, maximum throughput under load will be constrained by the resource that is consumed first, which could be IOPS, channel bandwidth, CPU, memory, or database internal resources.
  • io2 Block Express volumes support throughput scaling proportionally up to 0.256 MiB/s per provisioned IOPS. Maximum throughput of 4,000 MiB/s can be achieved at 256,000 IOPS with a 16-KiB I/O size.
  • EBS-optimized instances have a baseline and maximum IOPS rate enforced at the DB instance level. Combined IOPS from multiple volumes cannot exceed the instance-level threshold.
  • The maximum ratio of IOPS to allocated storage is 1,000:1 for io2 Block Express on Nitro-based instances, 500:1 for io2 on non-Nitro instances, and 50:1 for io1.

Factors That Impact RDS Storage Performance

  • Several factors can affect the performance of a DB instance, such as instance configuration, I/O characteristics, and workload demand.
  • System related activities also consume I/O capacity and may reduce database instance performance while in progress:
    • DB snapshot creation
    • Nightly backups
    • Multi-AZ standby creation
    • Read replica creation
    • Scaling storage
    • Changing storage types
  • System resources can constrain the throughput of a DB instance, but there can be other reasons for a bottleneck. Database could be the issue if:
    • Channel throughput limit is not reached
    • Queue depths are consistently low
    • CPU utilization is under 80%
    • Free memory available
    • No swap activity
    • Plenty of free disk space
    • Application has dozens of threads all submitting transactions as fast as the database will take them, but there is clearly unused I/O capacity
  • DB instance class determines the maximum bandwidth, throughput, and IOPS available. Using a current generation instance class with EBS-optimization and 10-gigabit network connectivity is recommended for best performance.
  • When modifying storage so it goes from one volume to four volumes (crossing the striping threshold), RDS provisions new volumes and transparently moves data, consuming significant IOPS and throughput.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. When should I choose Provisioned IOPS over Standard RDS storage?
    1. If you have batch-oriented workloads
    2. If you use production online transaction processing (OLTP) workloads
    3. If you have workloads that are not sensitive to consistent performance
  2. Is decreasing the storage size of a DB Instance permitted?
    1. Depends on the RDMS used
    2. Yes
    3. No (Direct decrease is not supported. However, Blue/Green Deployments can be used to achieve storage shrink since November 2024)
  3. Because of the extensibility limitations of striped storage attached to Windows Server, Amazon RDS does not currently support increasing storage on a _____ DB Instance using magnetic storage.
    1. SQL Server
    2. MySQL
    3. Oracle
  4. If I want to run a database in an Amazon instance, which is the most recommended Amazon storage option?
    1. Amazon Instance Storage
    2. Amazon EBS
    3. You can’t run a database inside an Amazon instance.
    4. Amazon S3
  5. For each DB Instance class, what is the maximum size of associated storage capacity?
    1. 5 TiB
    2. 16 TiB
    3. 64 TiB (per volume; up to 256 TiB with additional storage volumes for Oracle/SQL Server)
    4. 128 TiB
  6. Which RDS storage type provides the highest durability with 99.999% durability guarantee?
    1. General Purpose gp3
    2. General Purpose gp2
    3. Provisioned IOPS io2 Block Express
    4. Provisioned IOPS io1
  7. Which feature allows RDS to automatically increase storage capacity when running low on space?
    1. Elastic Volumes
    2. RDS Storage Autoscaling
    3. Dynamic Scaling
    4. Predictive Scaling
  8. What is the purpose of a Dedicated Log Volume (DLV) in Amazon RDS?
    1. To store database backups on a separate volume
    2. To store transaction logs on a separate volume from database tables for improved write performance
    3. To provide additional read capacity
    4. To enable cross-region replication
  9. A company needs to deploy an RDS for Oracle database that requires more than 64 TiB of storage. What should they do?
    1. Use multiple RDS instances with application-level sharding
    2. Migrate to Aurora
    3. Use additional storage volumes to scale up to 256 TiB per DB instance
    4. Use magnetic storage which has higher limits
  10. Which of the following statements about RDS gp3 storage is correct? (Choose 2)
    1. gp3 provides a baseline of 3,000 IOPS and 125 MiB/s regardless of volume size
    2. gp3 IOPS scales with volume size at 3 IOPS per GiB
    3. gp3 allows independent provisioning of IOPS and throughput from storage capacity
    4. gp3 requires burst credits for performance above baseline

📖 Related: AWS RDS Backup, Snapshots & Restore – Complete Guide

References

AWS Relational Database Service – RDS

~ Last updated on : ~ jayendrapatil ~ 15 Comments

Relational Database Service – RDS

  • Relational Database Service – RDS is a web service that makes it easier to set up, operate, and scale a relational database in the cloud.
  • provides cost-efficient, resizable capacity for an industry-standard relational database and manages common database administration tasks such as hardware provisioning, database setup, patching, and backups.
  • features & benefits
    • CPU, memory, storage, and IOPs can be scaled independently.
    • manages backups, software patching, automatic failure detection, and recovery.
    • automated backups can be performed as needed, or manual backups can be triggered as well. Backups can be used to restore a database, and the restore process works reliably and efficiently.
    • provides Multi-AZ high availability with a primary instance and a synchronous standby secondary instance that can failover seamlessly when a problem occurs.
    • provides elasticity & scalability by enabling Read Replicas to increase read scaling.
    • supports MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server, IBM Db2, and the MySQL-compatible and PostgreSQL-compatible Aurora DB engines
    • supports IAM users and permissions to control who has access to the RDS database service
    • databases can be further protected by putting them in a VPC, using SSL for data in transit and encryption for data in rest
    • However, as it is a managed service, shell (root ssh) access to DB instances is not provided, and this restricts access to certain system procedures and tables that require advanced privileges.
    • supports Blue/Green Deployments for safer database updates with minimal downtime
    • supports RDS Proxy for connection pooling and improved application availability

RDS Components

  • DB Instance
    • is a basic building block of RDS
    • is an isolated database environment in the cloud
    • each DB instance runs a DB engine. AWS currently supports MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server, IBM Db2, & Aurora DB engines
    • can be accessed from AWS command-line tools, RDS APIs, or the AWS Management RDS Console.
    • computation and memory capacity of a DB instance is determined by its DB instance class, which can be selected as per the needs
    • supports storage types: General Purpose SSD (gp3), Provisioned IOPS SSD (io1/io2 Block Express). Magnetic storage was deprecated on April 30, 2026.
    • each DB instance has a DB instance identifier, which is a customer-supplied name and must be unique for that customer in an AWS region. It uniquely identifies the DB instance when interacting with the RDS API and AWS CLI commands.
    • each DB instance can host multiple user-created databases or a single Oracle database with multiple schemas.
    • can be hosted in an AWS VPC environment for better control
    • supports latest generation Graviton4-based instance classes (M8g, R8g) for improved price-performance
  • Regions and Availability Zones
    • AWS resources are housed in highly available data center facilities in different areas of the world, these data centers are called regions which further contain multiple distinct locations called Availability Zones
    • Each AZ is engineered to be isolated from failures in other AZs and to provide inexpensive, low-latency network connectivity to other AZs in the same region
    • DB instances can be hosted in different AZs, an option called a Multi-AZ deployment.
      • RDS automatically provisions and maintains a synchronous standby replica of the DB instance in a different AZ.
      • Primary DB instance is synchronously replicated across AZs to the standby replica
      • Provides data redundancy, failover support, eliminates I/O freezes, and minimizes latency spikes during system backups.
  • Security Groups
    • security group controls the access to a DB instance, by allowing access to the specified IP address ranges or EC2 instances
  • DB Parameter Groups
    • A DB parameter group contains engine configuration values that can be applied to one or more DB instances of the same instance type
    • help define configuration values specific to the selected DB Engine for e.g. max_connections, force_ssl , autocommit
    • supports default parameter group, which cannot be edited.
    • supports custom parameter group, to override values
    • supports static and dynamic parameter groups
      • changes to dynamic parameters are applied immediately (irrespective of apply immediately setting)
      • changes to static parameters are NOT applied immediately and require a manual reboot.
  • DB Option Groups
    • Some DB engines offer tools or optional features that simplify managing the databases and making the best use of data.
    • RDS makes such tools available through option groups for e.g. Oracle Application Express (APEX), SQL Server Transparent Data Encryption, and MySQL Memcached support.

RDS Interfaces

  • RDS can be interacted with multiple interfaces
    • AWS RDS Management console
    • Command Line Interface
    • Programmatic Interfaces which include SDKs, libraries in different languages, and RDS API

RDS Storage

  • General Purpose SSD (gp3) – Default storage type
    • provides baseline performance of 3,000 IOPS and 125 MiB/s throughput included in the price of storage
    • can independently scale IOPS up to 64,000 and throughput up to 4,000 MiB/s (for SQL Server, up to 80,000 IOPS and 2,000 MiB/s as of June 2026)
    • supports storage sizes up to 64 TiB
    • cost-effective for most database workloads
  • Provisioned IOPS SSD (io1)
    • designed for I/O-intensive database workloads
    • supports up to 256,000 IOPS per DB instance
  • Provisioned IOPS SSD (io2 Block Express) – Launched March 2024
    • provides 99.999% durability (vs 99.9% for io1 and gp3)
    • consistent sub-millisecond latency
    • supports up to 64 TiB storage, 256,000 IOPS, and 4,000 MiB/s throughput
    • same price as io1 volumes
    • recommended for mission-critical database workloads
  • Magnetic (Standard) – DEPRECATED as of April 30, 2026
    • AWS recommends migrating existing magnetic storage instances to gp3 or io2 Block Express
    • no longer available for new DB instances

RDS Multi-AZ & Read Replicas

  • Multi-AZ deployment
    • provides high availability, durability, and automatic failover support
    • helps improve the durability and availability of a critical system, enhancing availability during planned system maintenance, DB instance failure, and Availability Zone disruption.
    • automatically provisions and manages a synchronous standby instance in a different AZ.
    • automatically fails over in case of any issues with the primary instance
    • A Multi-AZ DB instance deployment has one standby DB instance that provides failover support but doesn’t serve read traffic.
    • A Multi-AZ DB cluster deployment has two standby DB instances that provide failover support and can also serve read traffic.
      • provides a writer DB instance and two reader DB instances in three separate Availability Zones
      • supports MySQL and PostgreSQL engines
      • offers improved write latency, faster failover (typically under 35 seconds), and readable standby instances
      • uses semi-synchronous replication with transaction log-based approach
  • Read replicas
    • enable increased scalability and database availability in the case of an AZ failure.
    • allow elastic scaling beyond the capacity constraints of a single DB instance for read-heavy database workloads

RDS Proxy

  • Amazon RDS Proxy is a fully managed, highly available database proxy for RDS
  • establishes a pool of database connections and reuses them, improving application scalability and database efficiency
  • reduces the memory and CPU overhead for connection management on the database
  • improves application availability by automatically connecting to a standby DB instance during failovers while preserving connections
  • supports RDS for MySQL, PostgreSQL, MariaDB, SQL Server, and Aurora
  • enforces IAM authentication and securely stores credentials in AWS Secrets Manager
  • compute resources are serverless, automatically scaling based on database workload
  • supports Blue/Green Deployments to reduce switchover downtime by eliminating DNS propagation delays

RDS Blue/Green Deployments

  • Blue/Green Deployments create a staging environment (green) that mirrors the production environment (blue)
  • allows making and testing changes in the green environment without affecting production
  • use cases include major/minor version upgrades, parameter group changes, schema changes, and instance scaling
  • switchover typically completes in under a minute with built-in guardrails
  • supported for RDS for MySQL, MariaDB, and PostgreSQL
  • the green environment copies read replicas, storage configuration, DB snapshots, automated backups, Performance Insights, and Enhanced Monitoring from the blue environment

RDS Security

  • DB instance can be hosted in a VPC for the greatest possible network access control.
  • IAM policies can be used to assign permissions that determine who is allowed to manage RDS resources.
  • Security groups allow control of what IP addresses or EC2 instances can connect to the databases on a DB instance.
  • RDS supports encryption in transit using SSL connections
  • RDS supports encryption at rest to secure instances and snapshots at rest.
  • Network encryption and transparent data encryption (TDE) with Oracle DB instances
  • Authentication can be implemented using Password, Kerberos, and IAM database authentication.

RDS Backups, Snapshot

  • Automated backups
    • are enabled by default for a new DB instance.
    • enables recovery of the database to any point in time, with database change logs, during the backup retention period, up to the last five minutes of database usage.
    • backup retention period can be set from 0 to 35 days.
  • DB snapshots are manual, user-initiated backups that enable backup of the DB instance to a known state, and restore to that specific state at any time.

RDS Monitoring & Notification

  • RDS integrates with CloudWatch and provides metrics for monitoring
  • CloudWatch alarms can be created over a single metric that sends an SNS message when the alarm changes state
  • RDS also provides SNS notification whenever any RDS event occurs
  • RDS Performance Insights is a database performance tuning and monitoring feature that helps illustrate the database’s performance and help analyze any issues that affect it
  • RDS Recommendations provides automated recommendations for database resources.
  • Enhanced Monitoring provides real-time operating system metrics for the DB instance at granularity as fine as 1 second

RDS Optimized Writes & Optimized Reads

  • RDS Optimized Writes
    • improves write performance by up to 2x for MySQL and MariaDB workloads at no additional cost
    • writes 16 KiB data pages directly to storage without the doublewrite buffer
    • uses AWS Nitro System-based instances with support for 16 KiB atomic writes
    • available on db.r6gd, db.r7g, db.m6gd, db.m7g, and newer instance classes
  • RDS Optimized Reads
    • improves query processing performance by up to 50% for MySQL, MariaDB, and PostgreSQL
    • uses local NVMe-based SSD storage on supported instances to store ephemeral data such as temporary tables
    • reduces data access to/from network-based storage, improving read latency and throughput
    • available by default on NVMe-based instance classes (db.r6gd, db.m6gd, db.r8gd, db.m8gd, etc.)

RDS Extended Support

  • RDS Extended Support provides up to three additional years of critical security and bug fixes beyond a major version’s end of standard support date
  • gives more time to upgrade to a new major version while still receiving security fixes from AWS
  • RDS automatically enrolls databases in Extended Support when the major version reaches end of standard support
  • charged per vCPU-hour (starts at $0.100/vCPU-hour for Year 1-2, doubles to $0.200/vCPU-hour in Year 3)
  • currently applicable to:
    • MySQL 5.7 (standard support ended Feb 2024, Extended Support through June 2029)
    • MySQL 8.0 (standard support ending July 31, 2026)
    • PostgreSQL 11, 12, 13 (Extended Support available)
  • does not apply to Reserved Instance discounts – it is an additional charge

RDS Zero-ETL Integrations

  • Zero-ETL integrations make transactional data available in Amazon Redshift or Amazon SageMaker AI lakehouse in near real-time
  • eliminates the need to build and manage complex ETL data pipelines
  • supported for:
    • RDS for MySQL (GA since September 2024) – supports data filtering and multiple integrations
    • RDS for Oracle (GA since July 2025)
    • Aurora MySQL and Aurora PostgreSQL
  • target can be Amazon Redshift Serverless or provisioned cluster using RA3 instance types

RDS Custom

  • Amazon RDS Custom provides database administration access and customization of the database environment and operating system
  • combines the automation benefits of RDS with the flexibility needed for legacy, custom, and packaged applications
  • supports RDS Custom for SQL Server – enables features like SQL CLR, heterogeneous linked servers, and more than 100 databases per instance
  • RDS Custom for Oracle – End of Support: March 31, 2027
    • AWS will end support for RDS Custom for Oracle on March 31, 2027
    • after that date, you will no longer be able to access RDS Custom for Oracle resources
    • migration options: RDS for Oracle (standard), self-managed Oracle on EC2, or modernize to Aurora/PostgreSQL

RDS Pricing

  • Instance class
    • Pricing is based on the class (e.g., micro, large, xlarge) of the DB instance consumed.
  • Running time
    • Usage is billed in one-second increments, with a minimum of 10 mins.
  • Storage
    • Storage capacity provisioned for the DB instance is billed per GB per month
    • If the provisioned storage capacity is scaled within the month, the bill will be pro-rated.
  • I/O requests per month
    • Total number of storage I/O requests made in a billing cycle (applicable for gp2 storage).
  • Provisioned IOPS (per IOPS per month)
    • Provisioned IOPS rate, regardless of IOPS consumed, for RDS Provisioned IOPS (io1/io2) storage.
    • Provisioned storage for EBS volumes is billed in one-second increments, with a minimum of 10 minutes.
  • Backup storage
    • Automated backups & any active database snapshots consume storage
    • Increasing backup retention period or taking additional database snapshots increases the backup storage consumed by the database.
    • RDS provides backup storage up to 100% of the provisioned database storage at no additional charge for e.g., if you have 10 GB-months of provisioned database storage, RDS provides up to 10 GB-months of backup storage at no additional charge.
    • Most databases require less raw storage for a backup than for the primary dataset, so if multiple backups are not maintained, you will never pay for backup storage.
    • Backup storage is free only for active DB instances.
  • Data transfer
    • Internet data transfer out of the DB instance.
  • Reserved Instances
    • In addition to regular RDS pricing, reserved DB instances can be purchased
    • provides significant discounts (up to 72%) compared to On-Demand pricing for 1-year or 3-year commitments
  • Database Savings Plans
    • flexible pricing model offering savings in exchange for a commitment to a specific amount of usage ($/hour) over a 1-year term
    • covers both provisioned and serverless database usage
    • more flexible than Reserved Instances as it is not tied to specific instance configurations
  • RDS Extended Support
    • Additional per-vCPU-hour charge for databases running on major engine versions past end of standard support

Further Reading

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. What does Amazon RDS stand for?
    1. Regional Data Server.
    2. Relational Database Service
    3. Regional Database Service.
  2. How many relational database engines does RDS currently support?
    1. MySQL, Postgres, MariaDB, Oracle, Microsoft SQL Server, and IBM Db2
    2. Just two: MySQL and Oracle.
    3. Five: MySQL, PostgreSQL, MongoDB, Cassandra and SQLite.
    4. Just one: MySQL.
  3. If I modify a DB Instance or the DB parameter group associated with the instance, should I reboot the instance for the changes to take effect?
    1. No
    2. Yes
  4. What is the name of licensing model in which I can use your existing Oracle Database licenses to run Oracle deployments on Amazon RDS?
    1. Bring Your Own License
    2. Role Bases License
    3. Enterprise License
    4. License Included
  5. Will I be charged if the DB instance is idle?
    1. No
    2. Yes
    3. Only is running in GovCloud
    4. Only if running in VPC
  6. What is the minimum charge for the data transferred between Amazon RDS and Amazon EC2 Instances in the same Availability Zone?
    1. USD 0.10 per GB
    2. No charge. It is free.
    3. USD 0.02 per GB
    4. USD 0.01 per GB
  7. Does Amazon RDS allow direct host access via Telnet, Secure Shell (SSH), or Windows Remote Desktop Connection?
    1. Yes
    2. No
    3. Depends on if it is in VPC or not
  8. What are the two types of licensing options available for using Amazon RDS for Oracle?
    1. BYOL and Enterprise License
    2. BYOL and License Included
    3. Enterprise License and License Included
    4. Role based License and License Included
  9. A user plans to use RDS as a managed DB platform. Which of the below mentioned features is not supported by RDS?
    1. Automated backup
    2. Automated scaling to manage a higher load
    3. Automated failure detection and recovery
    4. Automated software patching
  10. A user is launching an AWS RDS with MySQL. Which of the below mentioned options allows the user to configure the InnoDB engine parameters?
    1. Options group
    2. Engine parameters
    3. Parameter groups
    4. DB parameters
  11. A user is planning to use the AWS RDS with MySQL. Which of the below mentioned services the user is not going to pay?
    1. Data transfer
    2. RDS CloudWatch metrics
    3. Data storage
    4. I/O requests per month
  12. A company needs to perform a major version upgrade of their RDS MySQL database with minimal downtime. Which feature should they use?
    1. Multi-AZ failover
    2. Read Replica promotion
    3. Blue/Green Deployments
    4. RDS Proxy
  13. An application using RDS MySQL experiences connection spikes from Lambda functions. Which RDS feature helps manage database connections efficiently?
    1. Multi-AZ DB Cluster
    2. Read Replicas
    3. RDS Optimized Reads
    4. RDS Proxy
  14. Which RDS storage type provides 99.999% durability and sub-millisecond latency for mission-critical workloads?
    1. General Purpose SSD (gp3)
    2. Provisioned IOPS (io1)
    3. Provisioned IOPS (io2 Block Express)
    4. Magnetic (Standard)
  15. A company wants to run near real-time analytics on their RDS MySQL transactional data without building ETL pipelines. Which feature should they use?
    1. Read Replicas
    2. RDS Proxy
    3. Zero-ETL integration with Amazon Redshift
    4. Multi-AZ DB Cluster
  16. What happens when an RDS database engine version reaches end of standard support and the customer does not upgrade?
    1. The database is automatically upgraded to the latest version
    2. The database is terminated
    3. The database is automatically enrolled in RDS Extended Support with additional charges
    4. The database continues to run with no changes
  17. Which RDS Multi-AZ deployment option provides readable standby instances? [Select TWO]
    1. Multi-AZ DB cluster deployment
    2. Multi-AZ DB instance deployment
    3. Read Replicas
    4. RDS Proxy

References

AWS RDS Best Practices

~ Last updated on : ~ jayendrapatil ~ 11 Comments

AWS RDS Best Practices

AWS recommends RDS best practices in terms of Monitoring, Performance, Security, and Operational Excellence.

RDS Basic Operational Guidelines

  • Monitoring
    • Memory, CPU, replica lag, and storage usage should be monitored.
    • CloudWatch can be setup for notifications when usage patterns change or when the capacity of deployment is approached, so that system performance and availability can be maintained.
  • Scaling
    • Scale up the DB instance when approaching storage capacity limits.
    • There should be some buffer in storage and memory to accommodate unforeseen increases in demand from the applications.
    • Enable RDS Storage Autoscaling to automatically scale storage when free storage space is low, helping avoid storage-full issues without manual intervention.
  • Backups
    • Enable Automatic Backups and set the backup window to occur during the daily low in WriteIOPS.
    • Use Multi-AZ to reduce the impact of backups on the primary DB instance.
  • Storage
    • Use General Purpose SSD (gp3) or Provisioned IOPS SSD (io2 Block Express) storage for all new instances.
    • Magnetic (standard) storage is deprecated as of May 1, 2026. Migrate existing magnetic storage instances to gp3 or io2 Block Express.
    • gp3 provides baseline performance of 3,000 IOPS and 125 MiB/s throughput, with the ability to independently scale IOPS up to 64,000 and throughput up to 4,000 MiB/s.
    • For latency-sensitive production workloads, use io2 Block Express which delivers sub-millisecond latency and up to 256,000 IOPS.
  • On a MySQL DB instance,
    • Do not create more than 10,000 tables using Provisioned IOPS or standard storage. Large numbers of tables will significantly increase database recovery time after a failover or database crash.
    • Avoid tables in the database growing too large. Provisioned storage limits restrict the maximum size of a MySQL table file to 16 TiB. Partition large tables so that file sizes are well under the 16 TiB limit. This can also improve performance and recovery time.
  • Performance
    • If the database workload requires more I/O than provisioned, recovery after a failover or database failure will be slow.
    • To increase the I/O capacity of a DB instance,
      • Migrate to a DB instance class with High I/O capacity.
      • Convert from magnetic storage to either General Purpose (gp3) or Provisioned IOPS (io2 Block Express) storage, depending on how much of an increase is needed.
      • If using Provisioned IOPS storage, provision additional throughput capacity.
    • Enable RDS Optimized Reads to achieve up to 2x faster complex query processing by leveraging local NVMe-based SSD storage for temporary tables.
    • Enable RDS Optimized Writes for MySQL and MariaDB to achieve up to 2x improvement in write transaction throughput at no additional cost.
  • Multi-AZ & Failover
    • Deploy applications in all Availability Zones, so if an AZ goes down, applications in other AZs will still be available.
    • Use RDS DB events to monitor failovers.
    • Set a TTL of less than 30 seconds, if the client application is caching the DNS data of the DB instances. As the underlying IP address of a DB instance can change after a failover, caching the DNS data for an extended time can lead to connection failures if the application tries to connect to an IP address that no longer is in service.
    • Multi-AZ requires the transaction logging feature to be enabled. Do not use features like Simple recovery mode, offline mode or Read-only mode which turn off transaction logging.
    • To shorten failover time
      • Ensure that sufficient Provisioned IOPS are allocated for your workload. Inadequate I/O can lengthen failover times. Database recovery requires I/O.
      • Use smaller transactions. Database recovery relies on transactions, so break up large transactions into multiple smaller transactions to shorten failover time.
      • Consider using RDS Proxy to reduce failover time by up to 79% for Aurora MySQL and 32% for RDS MySQL by maintaining application connections during failover.
    • Test failover for your DB instance to understand how long the process takes for your use case and to ensure that the application that accesses your DB instance can automatically connect to the new DB instance after failover.
    • Consider using Multi-AZ DB Cluster deployment for faster failovers (typically under 35 seconds) and readable standby instances.
  • Database Engine Versions
    • Regularly upgrade database engine versions to maintain security, performance, and compliance.
    • Enable automatic minor version upgrades for easier patching.
    • Schedule major version upgrades with proper testing in staging environments.
    • Be aware of RDS Extended Support charges that apply automatically after a major version reaches its end of standard support date. Plan upgrades before end-of-standard-support to avoid additional costs.
  • AWS Database Drivers
    • Use the AWS JDBC Driver, AWS Python Driver, or other AWS suite of drivers for faster switchover and failover times (single-digit seconds vs. tens of seconds for open-source drivers).
    • AWS drivers provide built-in support for authentication with AWS Secrets Manager, IAM, and Federated Identity.

Multi-AZ Deployment Options

  • RDS provides two Multi-AZ deployment options:
    • Multi-AZ DB Instance – One primary and one standby DB instance with synchronous replication. Failover time is typically 60–120 seconds.
    • Multi-AZ DB Cluster – One writer and two readable standby DB instances across three AZs with semi-synchronous replication. Failover time is typically under 35 seconds.
  • Multi-AZ DB Cluster Advantages:
    • Up to 2x faster transaction commit latency compared to Multi-AZ DB instance.
    • Two readable standby instances that can serve read traffic.
    • Faster automated failovers (typically under 35 seconds).
    • Supports RDS Optimized Writes and RDS Optimized Reads.
    • Supports gp3, io1, and io2 Block Express storage types.
    • IAM database authentication support.
  • Multi-AZ DB Cluster is supported for MySQL, PostgreSQL, and MariaDB engines.

DB Instance RAM Recommendations

  • An RDS performance best practice is to allocate enough RAM so that the working set resides almost completely in memory.
  • The working set is the data and indexes that are frequently in use on the instance.
  • Value of ReadIOPS should be small and stable.
  • ReadIOPS metric can be checked, using AWS CloudWatch while the DB instance is under load, to tell if the working set is almost all in memory.
  • If scaling up the DB instance class with more RAM results in a dramatic drop in ReadIOPS, the working set was not almost completely in memory.
  • Continue to scale up until ReadIOPS no longer drops dramatically after a scaling operation, or ReadIOPS is reduced to a very small amount.

RDS Security Best Practices

  • Do not use AWS root credentials to manage RDS resources; create IAM users for everyone.
  • Grant each user the minimum set of permissions required to perform his or her duties.
  • Use IAM groups to effectively manage permissions for multiple users.
  • Rotate your IAM credentials regularly.
  • Configure AWS Secrets Manager to automatically rotate the secrets for Amazon RDS, including the master user password.
  • Use IAM Database Authentication to authenticate to DB instances using IAM roles instead of database passwords. This eliminates the need to store credentials in the database and provides short-lived authentication tokens.
  • Use SSL/TLS connections to encrypt data in transit between applications and DB instances.
  • Enable encryption at rest using AWS KMS for database storage and backups.
  • Use AWS Security Hub to monitor RDS usage as it relates to security best practices.
  • Change the master user password using the AWS Management Console, CLI, or RDS API only (not SQL clients, which may unintentionally revoke privileges).

RDS Proxy

  • Amazon RDS Proxy is a fully managed, highly available database proxy that makes applications more scalable, more resilient to database failures, and more secure.
  • Connection Pooling: RDS Proxy establishes a pool of database connections and reuses them, reducing the stress on database compute and memory resources.
  • Improved Failover: RDS Proxy automatically connects to a standby DB instance while preserving application connections, reducing failover times significantly.
  • Security: RDS Proxy enforces IAM authentication and can retrieve credentials from AWS Secrets Manager, eliminating the need for database credentials in application code.
  • Best Use Cases:
    • Serverless and event-driven applications (e.g., AWS Lambda) with many short-lived connections.
    • Applications that open and close database connections rapidly.
    • Applications that require high availability with fast failover.
    • Applications that need to enforce IAM-based access to databases.
  • Supports MySQL, PostgreSQL, MariaDB, and SQL Server engines.

Blue/Green Deployments

  • Amazon RDS Blue/Green Deployments create a fully managed staging (green) environment that mirrors the production (blue) environment for safer database changes.
  • Key Benefits:
    • Perform major version upgrades, schema changes, and parameter group modifications with minimal downtime.
    • Test changes in the green environment while production continues to run on the blue environment.
    • Switchover typically completes in under a minute with built-in safeguards.
    • Automatic rollback if the switchover encounters issues.
  • Best Practices:
    • Thoroughly test the green environment before switching over.
    • Keep databases in the green environment read-only to avoid replication conflicts.
    • Make only replication-compatible schema changes.
    • Ensure data loading (lazy loading) is complete before switching over.
  • Supported for RDS for MySQL, MariaDB, and PostgreSQL.

CloudWatch Database Insights

  • Amazon CloudWatch Database Insights (successor to Performance Insights) provides database monitoring and analysis capabilities.
  • Note: Performance Insights is being replaced by CloudWatch Database Insights. The Performance Insights console experience reaches end-of-life on June 30, 2026. Migrate to the Advanced mode of Database Insights before that date.
  • Key Features:
    • Monitors database load using the DB Load metric based on active sessions.
    • On-demand analysis uses machine learning to identify performance bottlenecks and provide remediation advice.
    • Available for all RDS engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2.
  • Modes:
    • Standard mode – Included at no additional cost; provides 7 days of performance data history.
    • Advanced mode – Provides extended retention (up to 24 months), execution plans, and on-demand analysis features.

Using Enhanced Monitoring to Identify Operating System Issues

  • RDS provides metrics in real time for the operating system (OS) that your DB instance runs on.
  • Enhanced Monitoring provides granularity at 1, 5, 10, 15, 30, or 60 second intervals.
  • Enhanced Monitoring is available for all current generation DB instance classes.
  • Note: Previous generation instances (db.t1.micro, db.m1.small) have been deprecated since February 2023.

Using Metrics to Identify Performance Issues

  • To identify performance issues caused by insufficient resources and other common bottlenecks, you can monitor the metrics available for your Amazon RDS DB instance.
  • Performance metrics should be monitored on a regular basis to benchmark the average, maximum, and minimum values for a variety of time ranges to help identify performance degradation.
  • CloudWatch alarms can be set for particular metric thresholds to be alerted when they are reached or breached.
  • A DB instance has a number of different categories of metrics which includes CPU, memory, disk space, IOPS, db connections and network traffic, and how to determine acceptable values depends on the metric.
  • One of the best ways to improve DB instance performance is to tune the most commonly used and most resource-intensive queries to make them less expensive to run.
  • For Multi-AZ DB clusters, monitor replica lag – the time difference between the latest transaction on the writer DB instance and the latest applied transaction on a reader DB instance.

Recovery

  • MySQL
    • InnoDB is the recommended and supported storage engine for MySQL DB instances on Amazon RDS.
    • However, MyISAM performs better than InnoDB if you require intense, full-text search capability.
    • Point-In-Time Restore and snapshot restore features of Amazon RDS for MySQL require a crash-recoverable storage engine and are supported for the InnoDB storage engine only.
    • Although MySQL supports multiple storage engines with varying capabilities, not all of them are optimized for crash recovery and data durability.
    • MyISAM storage engine does not support reliable crash recovery and might prevent a Point-In-Time Restore or snapshot restore from working as intended which might result in lost or corrupt data when MySQL is restarted after a crash.
    • InnoDB instances can be migrated to Aurora, while MyISAM instances cannot.
    • MySQL table file size limit is 16 TiB (updated from 6 TB). Partition large tables well under this limit.
  • MariaDB
    • InnoDB is the recommended and supported storage engine for MariaDB DB instances on Amazon RDS.
    • Point-In-Time Restore and snapshot restore features of Amazon RDS for MariaDB require a crash-recoverable storage engine and are supported for the InnoDB storage engine only.
    • Although MariaDB supports multiple storage engines with varying capabilities, not all of them are optimized for crash recovery and data durability.
    • For e.g., although Aria is a crash-safe replacement for MyISAM, it might still prevent a Point-In-Time Restore or snapshot restore from working as intended. This might result in lost or corrupt data when MariaDB is restarted after a crash.

RDS Extended Support

  • Amazon RDS Extended Support provides up to three additional years of critical security and bug fixes beyond a major version’s end of standard support date.
  • Extended Support charges apply automatically when running a major version past its end of standard support date.
  • Best Practice: Plan and execute major version upgrades before the end-of-standard-support date to avoid Extended Support charges.
  • Use Blue/Green Deployments to perform major version upgrades with minimal downtime.
  • Currently supported MySQL versions: 8.0 and 8.4 (MySQL 5.7 under Extended Support).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are running a database on an EC2 instance, with the data stored on Elastic Block Store (EBS) for persistence At times throughout the day, you are seeing large variance in the response times of the database queries Looking into the instance with the isolate command you see a lot of wait time on the disk volume that the database’s data is stored on. What two ways can you improve the performance of the database’s storage while maintaining the current persistence of the data? Choose 2 answers
    1. Move to an SSD backed instance
    2. Move the database to an EBS-Optimized Instance
    3. Use Provisioned IOPs EBS
    4. Use the ephemeral storage on an m2.4xLarge Instance Instead
  2. Amazon RDS automated backups and DB Snapshots are currently supported for only the __________ storage engine
    1. InnoDB
    2. MyISAM
  3. A company wants to reduce the failover time for their Amazon RDS Multi-AZ deployment from approximately 60-120 seconds. Which approach would provide the fastest failover? Choose the correct answer.
    1. Use RDS Proxy in front of the Multi-AZ DB instance
    2. Migrate to a Multi-AZ DB Cluster deployment which provides failover typically under 35 seconds
    3. Increase the Provisioned IOPS on the DB instance
    4. Enable Enhanced Monitoring to detect failures faster
  4. A serverless application using AWS Lambda functions experiences database connection exhaustion on its Amazon RDS MySQL instance during peak traffic. What is the recommended solution?
    1. Increase the max_connections parameter in the DB parameter group
    2. Scale up to a larger DB instance class
    3. Deploy Amazon RDS Proxy to manage connection pooling and multiplexing
    4. Add a read replica to distribute the load
  5. A company wants to perform a major version upgrade of their production Amazon RDS for PostgreSQL database with minimal downtime. Which approach is recommended?
    1. Take a snapshot, restore to a new instance with the new version, and switch DNS
    2. Use the modify DB instance option to upgrade in-place during a maintenance window
    3. Use Amazon RDS Blue/Green Deployments to create a staging environment, test the upgrade, and switch over
    4. Create a read replica with the new version and promote it
  6. Which of the following are advantages of Amazon RDS Multi-AZ DB Cluster deployment over Multi-AZ DB Instance deployment? (Choose 3)
    1. Readable standby instances that can serve read traffic
    2. Faster automated failover (typically under 35 seconds)
    3. Support for all RDS database engines
    4. Up to 2x faster transaction commit latency
    5. Zero-downtime failover
  7. A company is running Amazon RDS for MySQL 5.7 which has reached end of standard support. What happens if they take no action? Choose the correct answer.
    1. The database will be automatically upgraded to MySQL 8.0
    2. The database will be terminated
    3. AWS will automatically charge RDS Extended Support fees for continued security patches
    4. The database will stop receiving any updates but continue running at the same cost
  8. Which storage type is AWS deprecating for Amazon RDS as of May 2026?
    1. General Purpose SSD (gp2)
    2. Magnetic (standard) storage
    3. Provisioned IOPS (io1)
    4. General Purpose SSD (gp3)

References

AWS Storage Options – RDS, DynamoDB & Database on EC2

~ Last updated on : ~ jayendrapatil ~ 17 Comments

AWS Storage Options Whitepaper with RDS, DynamoDB & Database on EC2 Cont.

Provides a brief summary for the Ideal Use cases, Anti-Patterns and other factors for Amazon RDS, DynamoDB & Databases on EC2 storage options

📝 Note: The original AWS Storage Services Overview whitepaper has been archived by AWS. This content is maintained and updated with current service capabilities for certification study reference. See the AWS Overview – Storage Services for the latest official guidance.

Amazon RDS

  • RDS is a fully managed relational database service supporting Amazon Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server database engines
  • RDS eliminates much of the administrative overhead associated with launching, managing, and scaling your own relational database on Amazon EC2 or in another computing environment.
  • RDS provides automated patching, backups, Multi-AZ high availability, read replicas, and monitoring out of the box.

Key Features (Updated 2024-2026)

  • Multi-AZ DB Cluster Deployments – deploys a primary and two readable standby instances across three AZs, providing faster failover (~35 seconds), improved commit latency via semisynchronous replication, and readable standbys (MySQL/PostgreSQL)
  • Blue/Green Deployments – creates a fully managed staging (green) environment that mirrors production (blue), allowing safe testing of major version upgrades and schema changes with minimal downtime switchover
  • RDS Proxy – a fully managed database proxy that pools and shares connections, improving application scalability, resilience to database failovers, and security via IAM/Secrets Manager authentication
  • RDS Data API – available for Aurora (Serverless v2 and provisioned), enables secure HTTP-based SQL execution without managing database drivers or connections
  • Aurora Serverless v2 – auto-scales database capacity in fine-grained increments based on application demand, scaling to hundreds of thousands of transactions per second
  • Aurora DSQL (launched Dec 2024) – a serverless, distributed SQL database with active-active multi-Region high availability, PostgreSQL-compatible, with strong consistency across all Regional endpoints
  • RDS Custom – provides OS and database access for Oracle and SQL Server when full administrative control is needed (Note: RDS Custom for Oracle reaches end of support March 31, 2027)
  • Graviton (ARM) Instances – M7g, R7g, M7i, R7i instance types offering better price-performance
  • gp3 Storage – baseline of 3,000 IOPS and 125 MiB/s, scalable up to 80,000 IOPS and 2,000 MiB/s per volume (up to 64 TiB per volume)
  • Extended Support – up to 3 additional years of critical security and bug fixes beyond community end-of-life for major engine versions

Ideal Usage Patterns

  • RDS is a great solution for cloud-based fully-managed relational database
  • RDS is also optimal for new applications with structured data that requires more sophisticated querying and joining capabilities than that provided by Amazon’s NoSQL database offering, DynamoDB.
  • RDS provides full compatibility with the databases supported and direct access to native database engines, code and libraries and is ideal for existing applications that rely on these databases
  • Applications requiring zero-downtime upgrades can leverage Blue/Green Deployments for safe major version changes
  • Serverless and event-driven applications benefit from RDS Proxy and Aurora Serverless v2 for connection management and auto-scaling

Anti-Patterns

  • Index and query-focused data
    • If the applications don’t require advanced features such as joins and complex transactions and is more oriented toward indexing and querying data, DynamoDB would be more appropriate for this needs
  • Numerous BLOBs
    • If the application makes heavy use of files (audio files, videos, images, etc), it is a better choice to use S3 to store the objects instead of database engines Blob feature and use RDS or DynamoDB only to save the metadata
  • Automated scalability
    • RDS provides vertical scaling (scale up) and limited horizontal scale-out via read replicas. For fully-automated serverless scaling, consider Aurora Serverless v2 or DynamoDB.
  • Complete control
    • RDS does not provide full OS-level admin access.
    • If the application requires complete OS-level control, consider RDS Custom (for Oracle/SQL Server) or a self-managed database on EC2.
  • Other database platforms
    • RDS supports Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server.
    • If any other database platform (such as IBM DB2, Informix, or Sybase) is needed, it should be deployed on a self-managed database on an EC2 instance.

Performance

  • RDS offers multiple storage types optimized for different workloads:
    • gp3 (General Purpose SSD) – baseline 3,000 IOPS, scalable up to 80,000 IOPS and 2,000 MiB/s throughput, up to 64 TiB per volume
    • io1/io2 (Provisioned IOPS SSD) – designed for I/O-intensive transactional workloads, up to 256,000 IOPS
  • Multi-AZ DB Cluster deployments provide improved write commit latency through optimized semisynchronous replication
  • Performance Insights provides a dashboard to monitor database load and identify bottlenecks
  • RDS Optimized Reads/Writes (Aurora) provide up to 2x faster query processing and 6x higher write throughput

Durability and Availability

  • RDS leverages Amazon EBS volumes as its data store
  • RDS provides database backups, for enhanced durability, which are replicated across multiple AZ’s
    • Automated backups
      • RDS automatically performs a full daily backup during the specified backup window, and captures DB transaction logs (up to 35-day retention)
    • User initiated backups (DB Snapshots)
      • User can initiate manual snapshots at any time; they are retained until explicitly deleted
  • Multi-AZ DB Instance – synchronously replicates data to a standby in another AZ with automatic failover (typically 60-120 seconds)
  • Multi-AZ DB Cluster – maintains a primary and two readable standbys across three AZs with faster failover (~35 seconds) and transaction log-based replication
  • RDS provides a DNS endpoint; in case of failure on the primary, it automatically fails over to the standby instance
  • RDS Read Replicas provide asynchronous replication for read scaling and can be promoted for disaster recovery (including cross-Region replicas)

Cost Model

  • RDS offers a tiered pricing structure based on instance size, deployment type (Single-AZ/Multi-AZ Instance/Multi-AZ Cluster), and AWS Region
  • Pricing components: DB instance hours, provisioned storage (per GB-month), I/O requests (for io1/io2), additional backup storage, and data transfer
  • Reserved Instances provide significant discounts (up to 69%) for 1-year or 3-year commitments
  • Aurora Serverless v2 charges per Aurora Capacity Unit (ACU) consumed per second

Scalability and Elasticity

  • RDS resources can be scaled in several dimensions: storage size, IOPS, instance compute capacity, and number of read replicas
  • Storage Auto Scaling automatically increases storage when approaching capacity limits
  • Aurora Auto Scaling automatically adjusts the number of Aurora Replicas based on demand
  • Aurora Serverless v2 scales compute capacity automatically in fine-grained increments (0.5 ACU) from minimum to maximum configured capacity
  • Read Replicas (up to 15 for Aurora, 5 for other engines) enable read scaling across AZs and Regions
  • Aurora Limitless Database provides horizontal write scaling by automatically sharding data across multiple writer instances

Interfaces

  • RDS APIs, AWS CLI, and the AWS Management Console provide management interfaces for creating, modifying, and managing DB instances
  • RDS Data API (Aurora) provides a secure HTTP endpoint for running SQL statements without managing database connections or drivers
  • Once a database is created, RDS provides a DNS endpoint for the database which can be used to connect using standard database drivers
  • Endpoint does not change over the lifetime of the instance, even during failover in Multi-AZ configurations
  • RDS Proxy endpoints provide connection pooling and improved failover handling for applications

Amazon DynamoDB

  • Amazon DynamoDB is a fully managed, serverless NoSQL database service that delivers single-digit millisecond performance at any scale.
  • DynamoDB offers zero infrastructure management, zero downtime maintenance, and automatic scaling to accommodate any workload demand.
  • DynamoDB provides both eventually-consistent reads (by default) and strongly-consistent reads (optional), as well as ACID transactions (TransactWriteItems, TransactGetItems) for coordinated operations across multiple items and tables.
  • Amazon DynamoDB handles data as follows:
    • DynamoDB stores structured data in tables, indexed by primary key, and allows low-latency read and write access to items.
    • DynamoDB supports rich data types: Scalar (String, Number, Binary, Boolean, Null), Document (List, Map), and Set (String Set, Number Set, Binary Set)
    • Tables do not have a fixed schema, so each data item can have a different number of attributes.
    • Primary key can either be a single-attribute partition key (hash key) or a composite partition key + sort key (hash-range key).
    • Local Secondary Indexes (LSI) – alternate sort key on the same partition key (defined at table creation)
    • Global Secondary Indexes (GSI) – alternate partition key and optional sort key, can be added/modified anytime

Key Features (Updated 2024-2026)

  • On-Demand Capacity Mode – pay-per-request pricing with no capacity planning; automatically scales to accommodate workload demand. 50% price reduction effective November 2024.
  • Global Tables – fully managed, multi-Region, multi-active replication with two consistency modes:
    • Multi-Region Eventual Consistency (MREC) – default mode, typically sub-second replication
    • Multi-Region Strong Consistency (MRSC) – GA 2025, provides zero RPO with strongly consistent reads/writes across all Regions
  • DynamoDB Accelerator (DAX) – fully managed, in-memory cache providing microsecond read latency for read-heavy workloads
  • Standard-IA Table Class – lower storage cost option (up to 60% cheaper storage) for infrequently accessed data
  • PartiQL – SQL-compatible query language for DynamoDB, enabling familiar SELECT, INSERT, UPDATE, DELETE syntax
  • Zero-ETL Integrations – seamless data replication to Amazon Redshift, OpenSearch Service, and SageMaker Lakehouse without building ETL pipelines
  • S3 Import/Export – bulk import data from S3 and export table data to S3 in DynamoDB JSON or Amazon Ion format
  • Point-in-Time Recovery (PITR) – continuous backups with per-second granularity, restorable to any point within a configurable 1-35 day window
  • Encryption at Rest – enabled by default using AWS owned keys, with options for AWS managed key or customer managed KMS key
  • DynamoDB Streams / Kinesis Data Streams – capture item-level changes for event-driven architectures, real-time analytics, and cross-Region replication

Ideal Usage Patterns

  • DynamoDB is ideal for applications that need a flexible NoSQL database with low read and write latencies, and the ability to scale storage and throughput up or down as needed without code changes or downtime.
  • Use cases requiring a highly available and scalable database e.g., mobile apps, gaming, digital ad serving, live voting, sensor networks, log ingestion, access control, metadata storage for S3 objects, e-commerce shopping carts, web session management, and serverless applications
  • Event-driven architectures leveraging DynamoDB Streams to trigger Lambda functions or downstream processing
  • Global applications requiring multi-Region active-active deployments with Global Tables

Anti-Patterns

  • Structured data with Join and/or Complex Transactions
    • If the application uses structured data and requires complex joins, multi-table transactions, or relationship infrastructure provided by traditional relational databases, RDS or Aurora would be a better choice. (Note: DynamoDB does support ACID transactions within and across tables, but not SQL-style joins.)
  • Large Blob data
    • DynamoDB has a maximum item size of 400 KB. For large media files, videos, etc., use S3 for storage and DynamoDB for metadata.
  • Large Objects with Low I/O rate
    • DynamoDB uses SSD drives and is optimized for high I/O workloads. If the application stores very large amounts of infrequently accessed data, S3 or the Standard-IA table class might be more cost-effective.
  • Complex ad-hoc analytics
    • For complex analytical queries across large datasets, use DynamoDB zero-ETL integration with Amazon Redshift or export to S3 for Athena queries.

Performance

  • SSDs and limited indexing on attributes provides single-digit millisecond latency at any scale.
  • Provisioned capacity mode – define exact read/write capacity units for predictable workloads with optional auto-scaling
  • On-demand capacity mode – automatically accommodates up to double previous peak traffic instantly, with further scaling within minutes
  • DAX (DynamoDB Accelerator) – in-memory cache providing microsecond response times for eventually consistent reads
  • DynamoDB automatically partitions data to maintain consistent performance as tables grow.

Durability and Availability

  • DynamoDB automatically and synchronously replicates data across three AZs in a Region for high availability and data protection against facility failures.
  • Global Tables provide multi-Region replication with 99.999% availability SLA (multi-Region)
  • PITR provides continuous backups for point-in-time restore capability
  • On-demand backups allow full table backups at any time without performance impact

Cost Model

  • DynamoDB offers two capacity modes:
    • On-Demand – pay per read/write request (no capacity planning). 50% price reduction since November 2024.
    • Provisioned – pay per hour for provisioned Read/Write Capacity Units (with optional auto-scaling and Reserved Capacity discounts)
  • Additional pricing components: data storage (per GB-month), Global Tables replication (per replicated write unit), backups, data export/import, DynamoDB Streams reads, and data transfer
  • Standard-IA table class reduces storage costs by up to 60% with higher per-request costs (ideal when storage dominates)
  • Global Tables pricing reduced by up to 67% (November 2024)

Scalability and Elasticity

  • DynamoDB is both highly-scalable and elastic with virtually unlimited storage and throughput capacity.
  • Data is automatically partitioned and re-partitioned as needed, while SSD storage provides predictable low-latency at any scale.
  • On-Demand mode provides truly serverless scaling with no capacity planning required
  • Provisioned mode with Auto Scaling automatically adjusts capacity based on utilization targets
  • DynamoDB can handle more than 10 trillion requests per day and support peaks of more than 100 million requests per second.

Interfaces

  • DynamoDB provides a low-level REST API, AWS SDKs in multiple languages, and the AWS CLI
  • PartiQL – SQL-compatible query language supported via Console, CLI, SDKs, and NoSQL Workbench
  • APIs provide both management and data interfaces: table management (create, list, delete, describe) and item operations (Get, Put, Update, Delete, Query, Scan, BatchWrite, BatchGet, TransactWrite, TransactGet)
  • DynamoDB Streams API – captures ordered sequence of item-level changes
  • NoSQL Workbench – visual tool for data modeling, visualization, and query development

Databases on EC2

  • EC2 with EBS volumes allows hosting a self-managed relational database with full OS and database administrative control
  • Ready-to-use, prebuilt AMIs are available from leading database vendors in AWS Marketplace
  • Note: With the introduction of RDS Custom (for Oracle and SQL Server), the need for self-managed databases on EC2 has decreased for these specific engines

Ideal Usage Patterns

  • Self-managed database on EC2 is ideal for applications that require a specific database platform not supported by Amazon RDS e.g., IBM DB2, Informix, Sybase, or specialized configurations
  • Applications requiring maximum level of administrative control and configurability including custom storage engines, specialized replication, or kernel-level tuning not available in RDS or RDS Custom
  • Database versions or configurations not yet supported by RDS

Anti-Patterns

  • Index and query-focused data
    • If the applications don’t require advanced features such as joins and complex transactions and is more oriented toward indexing and querying data, DynamoDB would be more appropriate
  • Numerous BLOBs
    • If the application makes heavy use of files (audio files, videos, images), use S3 for object storage and RDS or DynamoDB for metadata
  • Managed service available
    • If RDS supports the database engine and provides the needed features, RDS is preferred for reduced operational overhead. For Oracle/SQL Server requiring OS access, consider RDS Custom before self-managing on EC2.
  • Automated scalability
    • Self-managed databases require manual or scripted scaling operations. If fully-automated scaling is needed, DynamoDB, Aurora Serverless, or RDS with Auto Scaling may be better choices.

Performance

  • Performance depends on the EC2 instance type, number/configuration of EBS volumes, and database tuning
  • Scale up by choosing larger instance types (compute-optimized, memory-optimized) or Graviton-based instances for better price-performance
  • For storage: use gp3 or io2 Block Express EBS volumes. Use software RAID 0 (disk striping) across multiple EBS volumes for aggregated IOPS and bandwidth
  • Instance store (NVMe SSDs) can provide very high IOPS for temporary/cache workloads

Durability & Availability

  • Uses EBS for storage with same durability guarantees (99.999% availability for io2 Block Express)
  • Enhanced durability via EBS snapshots, cross-Region replication, or third-party backup tools (e.g., Oracle RMAN) to S3
  • High availability requires manual configuration: Multi-AZ replication, clustering solutions, or automated failover scripts

Cost Model

  • Cost determined by: EC2 instance size/type, EBS volume size and IOPS, data transfer, and any third-party database licensing costs
  • Savings Plans and Reserved Instances reduce EC2 compute costs for steady-state workloads
  • BYOL (Bring Your Own License) options available for Oracle, SQL Server, and other commercial databases

Scalability & Elasticity

  • Leverage EC2 scalability by creating AMIs for horizontal scaling, though database-specific clustering/sharding is required
  • Vertical scaling requires instance stop/start (brief downtime without clustering)
  • Auto Scaling groups can manage read replica fleets for read-heavy workloads

Comparison: RDS vs DynamoDB vs Database on EC2

Factor Amazon RDS DynamoDB Database on EC2
Type Managed Relational (SQL) Managed NoSQL (Key-Value/Document) Self-Managed Relational
Scaling Vertical + Read Replicas; Aurora Serverless for auto-scaling Fully automatic (on-demand) or provisioned with auto-scaling Manual vertical/horizontal
Availability Multi-AZ (2 or 3 AZs), automated failover Automatic across 3 AZs; Global Tables for multi-Region Manual HA configuration required
Admin Overhead Low (managed patching, backups) None (serverless) High (full responsibility)
Use Case Complex queries, joins, ACID transactions High-speed key-value access, flexible schema, massive scale Unsupported engines, full OS control

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following are use cases for Amazon DynamoDB? Choose 3 answers
    1. Storing BLOB data.
    2. Managing web sessions
    3. Storing JSON documents
    4. Storing metadata for Amazon S3 objects
    5. Running relational joins and complex updates.
    6. Storing large amounts of infrequently accessed data.
  2. A client application requires operating system privileges on a relational database server. What is an appropriate configuration for highly available database architecture?
    1. A standalone Amazon EC2 instance
    2. Amazon RDS in a Multi-AZ configuration
    3. Amazon EC2 instances in a replication configuration utilizing a single Availability Zone
    4. Amazon EC2 instances in a replication configuration utilizing two different Availability Zones

    Note: With the introduction of RDS Custom, this question’s context has evolved. RDS Custom for SQL Server now supports Multi-AZ. However, for full OS-level control beyond what RDS Custom offers, EC2 remains the answer.

  3. You are developing a new mobile application and are considering storing user preferences in AWS, which would provide a more uniform cross-device experience to users using multiple mobile devices to access the application. The preference data for each user is estimated to be 50KB in size. Additionally 5 million customers are expected to use the application on a regular basis. The solution needs to be cost-effective, highly available, scalable and secure, how would you design a solution to meet the above requirements?
    1. Setup an RDS MySQL instance in 2 availability zones to store the user preference data. Deploy a public facing application on a server in front of the database to manage security and access credentials
    2. Setup a DynamoDB table with an item for each user having the necessary attributes to hold the user preferences. The mobile application will query the user preferences directly from the DynamoDB table. Utilize STS. Web Identity Federation, and DynamoDB Fine Grained Access Control to authenticate and authorize access (DynamoDB provides high availability as it synchronously replicates data across three facilities within an AWS Region and scalability as it is designed to scale its provisioned throughput up or down while still remaining available. Also suitable for storing user preference data)
    3. Setup an RDS MySQL instance with multiple read replicas in 2 availability zones to store the user preference data. The mobile application will query the user preferences from the read replicas. Leverage the MySQL user management and access privilege system to manage security and access credentials.
    4. Store the user preference data in S3 Setup a DynamoDB table with an item for each user and an item attribute pointing to the user’ S3 object. The mobile application will retrieve the S3 URL from DynamoDB and then access the S3 object directly utilize STS, Web identity Federation, and S3 ACLs to authenticate and authorize access.
  4. A customer is running an application in US-West (Northern California) region and wants to setup disaster recovery failover to the Asian Pacific (Singapore) region. The customer is interested in achieving a low Recovery Point Objective (RPO) for an Amazon RDS multi-AZ MySQL database instance. Which approach is best suited to this need?
    1. Synchronous replication
    2. Asynchronous replication (Cross-Region Read Replicas use asynchronous replication. Note: DynamoDB Global Tables with MRSC now offers zero RPO across Regions for NoSQL workloads.)
    3. Route53 health checks
    4. Copying of RDS incremental snapshots
  5. You are designing a file-sharing service. This service will have millions of files in it. Revenue for the service will come from fees based on how much storage a user is using. You also want to store metadata on each file, such as title, description and whether the object is public or private. How do you achieve all of these goals in a way that is economical and can scale to millions of users?
    1. Store all files in Amazon Simple Storage Service (S3). Create a bucket for each user. Store metadata in the filename of each object, and access it with LIST commands against the S3 API.
    2. Store all files in Amazon S3. Create Amazon DynamoDB tables for the corresponding key-value pairs on the associated metadata, when objects are uploaded.
    3. Create a striped set of 4000 IOPS Elastic Load Balancing volumes to store the data. Use a database running in Amazon Relational Database Service (RDS) to store the metadata.
    4. Create a striped set of 4000 IOPS Elastic Load Balancing volumes to store the data. Create Amazon DynamoDB tables for the corresponding key-value pairs on the associated metadata, when objects are uploaded.
  6. Company ABCD has recently launched an online commerce site for bicycles on AWS. They have a “Product” DynamoDB table that stores details for each bicycle, such as, manufacturer, color, price, quantity and size to display in the online store. Due to customer demand, they want to include an image for each bicycle along with the existing details. Which approach below provides the least impact to provisioned throughput on the “Product” table?
    1. Serialize the image and store it in multiple DynamoDB tables
    2. Create an “Images” DynamoDB table to store the Image with a foreign key constraint to the “Product” table
    3. Add an image data type to the “Product” table to store the images in binary format
    4. Store the images in Amazon S3 and add an S3 URL pointer to the “Product” table item for each image
  7. A company needs to store IoT sensor data from thousands of devices. The data is small (under 1KB per reading), arrives at unpredictable rates, and must be queryable by device ID and timestamp with single-digit millisecond latency. Which database solution is most appropriate?
    1. Amazon RDS MySQL with Multi-AZ
    2. Self-managed Cassandra on EC2
    3. Amazon DynamoDB with on-demand capacity mode (DynamoDB with on-demand mode is ideal: handles unpredictable workloads without capacity planning, supports composite key (device ID as partition key, timestamp as sort key), and provides single-digit millisecond latency)
    4. Amazon Aurora Serverless
  8. A company wants to perform real-time analytics on data stored in their DynamoDB table without impacting production read/write performance. Which approach is the most operationally efficient?
    1. Create a read replica of the DynamoDB table
    2. Export data to S3 on a scheduled basis and query with Athena
    3. Use DynamoDB zero-ETL integration with Amazon Redshift (Zero-ETL integration provides near real-time data replication to Redshift without building custom pipelines or impacting DynamoDB performance)
    4. Use DynamoDB Streams with a Lambda function to copy data to RDS