1. Situation
The application already runs on two servers in different Availability Zones (AZs), and a load balancer can send requests to either one. That makes the application tier highly available. The database is still different: both servers depend on one Amazon RDS database instance in one AZ. RDS is AWS's managed relational database service.
The application connects through an RDS endpoint, which is a DNS name such as orders-db.abc123.us-east-1.rds.amazonaws.com. The application uses that stable name instead of hardcoding the database instance's IP address. RDS can later change which database instance the name points to.
The load balancer can route around a failed application instance. The Auto Scaling group can replace unhealthy compute. But every request still depends on one database instance in one Availability Zone.
If that database becomes unavailable, the healthy application servers have nowhere to read or write business data. The web tier is highly available on paper, yet the application is down.
The business now gives four requirements:
- Continue after a database instance or Availability Zone failure.
- Recover from an accidental deletion or bad deployment.
- Scale read traffic if reporting and product queries grow.
- Keep the application usable while database connections move to a replacement writer.
These requirements sound similar because each one involves another copy of the data. However, each copy has a different purpose: staying available, serving more reads, recovering old data, or helping the application reconnect.
This study uses the classic RDS Multi-AZ DB instance deployment. It has one primary DB instance, which is the active database that serves reads and writes, and one standby DB instance in another AZ. The standby is kept ready to become the new primary if needed.
RDS copies changes to this standby synchronously, meaning the standby is kept closely aligned with the primary as writes occur. This makes it suitable for managed failover, but the application cannot use this classic standby for reporting queries.
A read replica works differently. It normally receives changes asynchronously, after they occur on the primary. It can serve reads, but it may briefly be behind the primary. That delay is called replication lag.
2. Naive Design
Naive option 1: one database in one Availability Zone
application -> single-AZ RDS DB instance
This is simple and may be appropriate for development or a workload that can tolerate database downtime. It is not highly available.
If that instance or its AZ becomes unavailable, the application must wait for the database to recover or for an operator to restore it. Adding more application servers does not help because every server still depends on the same unavailable database.
Naive option 2: add a read replica and call it failover
A read replica is useful for read scaling, but it normally has its own endpoint and may be behind the primary because replication is asynchronous. It does not automatically become the application's writer during a normal DB instance failure.
An operator can promote a read replica, which stops replication and turns it into an independent DB instance. The team must then redirect the application to that instance. Promotion and traffic redirection are separate recovery steps, unlike managed Multi-AZ failover.
That is not the same experience as managed Multi-AZ failover.
Naive option 3: enable Multi-AZ and remove backups
The standby receives the database's current state. If the application drops a table, overwrites a balance, or runs a destructive migration, that bad change can reach the standby too.
A standby protects against the current database becoming unavailable. It does not preserve yesterday's correct data after today's bad change.
Naive option 4: assume connections never break
Even automatic failover causes a short transition. Existing database sessions can break, and transactions that were running may fail. A connection pool is the reusable set of database connections kept by the application. After failover, that pool may still contain connections to the old primary.
RDS can finish promoting the standby while the application continues using broken connections. Database availability and application recovery are therefore related, but they are not the same thing.
3. What Breaks
Follow three failures that need three different responses.
Failure story 1: the primary instance stops responding
At 10:00, the application sends traffic to its usual RDS endpoint. At 10:01, the primary instance becomes unavailable.
In a Single-AZ design, RDS has no prepared standby to promote. The service must wait for the original database to recover or for another recovery action, so the database remains unavailable longer.
This failure needs Multi-AZ: a current standby in another AZ and an automatic way to make it the new primary.
Failure story 2: an operator deletes valid data
At 14:00, a migration mistakenly deletes rows. The database remains healthy and continues accepting queries. Multi-AZ replication faithfully copies the new state.
The database infrastructure is healthy, so failover would not help—the standby contains the same bad deletion. This failure needs historical recovery: a backup from before 14:00.
Failure story 3: the standby is promoted but users still see errors
RDS updates the endpoint so that new connections can reach the promoted standby. Existing TCP connections do not move to that new database. Some requests may fail during the change, and the application's connection pool may continue handing out broken connections to the old primary.
The application must discard broken connections, resolve the endpoint again, and open new connections. Retries should be bounded, meaning limited in number and separated by short waits. Writes need extra care because the database may have committed a transaction even if the application never received the success response.
These stories lead to a useful rule:
4. AWS Architecture
Build the database architecture one responsibility at a time.
Step 1: place RDS in private database subnets
Create a DB subnet group, which is a list of subnets where RDS is allowed to place database resources. Include private database subnets in at least two AZs so RDS has placement options across separate failure locations. A private database subnet has no direct internet route to the database.
The subnet group is configuration, not a network hop. Application traffic does not pass through it; RDS uses it when choosing subnets and private IP addresses for database resources.
For a normal web application, set the database's public accessibility to false. The application servers reach it through private VPC networking; internet users reach the application, not the database port.
The subnet group provides placement options. It does not by itself create a standby or enable failover.
Step 2: enable a Multi-AZ DB instance deployment
For the central scenario, configure RDS with one primary DB instance and one synchronous standby in another Availability Zone.
During normal operation, the primary serves the application's database traffic. RDS keeps the standby ready for failure, but the standby is not an additional read server in this deployment type. Reporting queries cannot be sent to it.
If RDS detects a failure it supports—such as an unhealthy primary host or loss of connectivity—it automatically promotes the standby. RDS then changes the DNS record for the existing endpoint so that the name points to the new primary.
The important distinction is: the endpoint name stays the same, but the database IP address behind the name can change.
| Moment | Endpoint used by the application | Database behind the endpoint | Connection consequence |
|---|---|---|---|
| Normal operation | The configured RDS endpoint | Primary in AZ A | Existing connections use the current primary. |
| During failover | The same RDS endpoint name | DNS is being updated | Existing sessions can fail while the writer changes. |
| After failover | The same RDS endpoint name | Promoted standby in AZ B | The application resolves the name and opens new connections. |
Step 3: add automated backups for recovery
Enable automated backups and choose how many days RDS should retain the recovery history. This retention period determines how far back the team can restore. During that window, point-in-time recovery (PITR) can rebuild the database at a selected restorable time—for example, just before an accidental deletion.
PITR creates a new DB instance from backups and transaction logs. It leaves the current production database unchanged; it does not press a rewind button on the running instance.
A manual snapshot is a user-created backup that represents one named point in time. Create one before a risky migration when a clear pre-change checkpoint would help. Also test the restore process: having a backup is useful only if the team knows how to restore, validate, and use it.
Step 4: make the application failover-aware
Give each application instance a connection pool with a maximum size. This is a bounded connection pool: it reuses connections but cannot open an unlimited number. After failover, the pool must remove broken connections and create new ones through the RDS endpoint.
Retry temporary connection failures with backoff, meaning the application waits longer between attempts instead of retrying continuously. Database writes need a safety check. Imagine the database commits CreateOrder, but the connection breaks before the success response reaches the application. Repeating the same write blindly could create the order twice.
Use an idempotency key, unique database constraint, transaction identifier, or a business-specific check to recognize that the write may already have succeeded. The goal is not merely to retry—it is to retry without performing the business action twice.
RDS Proxy is an optional managed service that sits between the application and supported RDS databases. The application connects to the proxy endpoint, and the proxy reuses a smaller pool of database connections. During failover, it can continue accepting connections and redirect them to the new primary, reducing some DNS and connection-management disruption. It does not make unsafe retries safe or replace backups and transaction design.
Step 5: add read capacity only when reads are the bottleneck
Add read replicas only when measurements show that read queries are overloading the primary. The application must deliberately send suitable read-only work—such as reports—to the replica's separate endpoint. Writes still go to the primary.
Because replication is asynchronous, the replica can briefly return older data. For example, a user might update an address on the primary and immediately read the old address from the replica. Do not send a read-after-write workflow to a replica unless that temporary staleness is acceptable.
5. Request Or Data Flow
Follow three separate flows: a normal database request, an infrastructure failover, and recovery from bad data.
Lifecycle 1: normal request
- A user request reaches an application instance through the load balancer.
- The application obtains database credentials from a secure store such as Secrets Manager.
- The application connects to the RDS endpoint.
- DNS directs that connection to the current primary DB instance.
- The primary commits the transaction while RDS synchronously keeps the standby current for failover.
- The application returns the result to the user.
Lifecycle 2: database failover
RDS is responsible for detecting the database failure, promoting the standby, and updating the endpoint's DNS record. The application is responsible for handling broken connections and retrying safe work.
A long transaction may be rolled back, and requests already in progress may return errors. These errors can be normal during a short failover window. Monitoring should also alert when they continue long enough to suggest that the database or application did not recover.
Lifecycle 3: bad-data recovery
- Operators identify the last known good time.
- RDS restores to that point as a new DB instance.
- The team validates the restored data and application compatibility.
- The team decides whether to move the whole application to the restored instance, copy only the missing data, or combine the restored data with valid changes made after the restore time.
- If the application moves, the team updates its connection settings, credentials, DNS records, and security-group rules to reach the new instance.
Failover automatically replaces unavailable infrastructure with a current standby. Point-in-time restore creates a separate historical database that the team must validate and deliberately put into use. Cutover is the planned step of moving application traffic to that restored database.
6. Security Controls
Protect the network boundary
Keep RDS in private database subnets and set public accessibility to false for the normal architecture.
Use security-group referencing so the database accepts connections from the application tier rather than from a broad IP range:
The database security group's inbound rule should use the application security group as its source. In plain terms: “Allow database-port traffic only from resources carrying the application security group.” Avoid allowing 0.0.0.0/0—every IPv4 address—an office IP range added for convenience, or the entire VPC when the application tier can be identified precisely.
Protect the credentials and database identity
Store database credentials in AWS Secrets Manager or another approved secret store. Rotate them according to engine and application requirements.
Two permission systems are involved. IAM controls AWS management actions such as creating, modifying, snapshotting, restoring, or deleting an RDS instance. Database users and database roles control SQL actions inside the engine, such as selecting from or updating a table. Permission to modify RDS does not automatically grant permission to query application tables, or vice versa.
Protect data and administrative actions
Use encryption at rest with AWS Key Management Service (AWS KMS), the AWS service that controls the encryption keys, when required. Use TLS to encrypt data while it travels between the application and database. If a snapshot is encrypted with a KMS key, the identity copying, sharing, or restoring that snapshot also needs permission to use that key.
Protect destructive control-plane actions—AWS API operations that change the RDS resource itself. Examples include deleting the DB instance, shortening backup retention, disabling deletion protection, or making the database publicly reachable.
Enable the database engine logs, audit capabilities, and performance tools that match the workload and compliance needs. Send useful measurements and alarms to Amazon CloudWatch, AWS's monitoring service, so the team can see failures and performance problems.
7. Resilience Controls
A highly available relational application needs several layers because different failures need different controls. Two disaster-recovery terms also appear in this table: recovery time objective (RTO) is the target time for restoring service, while recovery point objective (RPO) is the amount of recent data loss the business can tolerate.
| Failure | Primary control | What still needs work |
|---|---|---|
| DB instance or supported AZ failure | Multi-AZ automatic failover | Application reconnect and retry behavior |
| Accidental delete or bad migration | Automated backups, PITR, snapshots | Restore validation and data cutover |
| Read overload | Read replicas, query tuning, caching | Replica lag and read routing |
| Connection storm—too many clients connect at once | Bounded pooling or RDS Proxy | Connection limits, controlled waiting, and monitoring |
| Entire Region unavailable | Cross-Region recovery design | Replication, routing, RTO, and RPO planning |
Multi-AZ protects against supported instance and AZ failures inside one AWS Region. It does not automatically create a database or traffic-switching plan in another Region.
RTO and RPO are business targets, not features that Multi-AZ chooses for you. A cross-Region design must decide how data is copied, how traffic moves, how long recovery may take, and how much recent data could be lost.
Monitor both availability and workload health: RDS events, active connections, CPU, free memory, storage space, storage latency, replica lag, deadlocks, and slow queries. The exact alarms depend on the database engine and application, but the goal is to see both “the database is down” and “the database is alive but overloaded.”
Test failover deliberately, first outside production and later through carefully controlled production exercises. Measure the complete user-visible recovery time. RDS may finish failover before the application's connection pools and retries recover.
Test backup restoration separately. A successful failover test proves that the current standby can take over. It does not prove that the team can restore, validate, and use data from before yesterday's accidental deletion.
8. Performance Controls
Before buying a larger database, inspect the work it is already doing:
- Find queries that are slow or run very frequently.
- Review indexes and execution plans, which show how the database decided to find and combine the requested rows.
- Remove unnecessary database round trips—for example, many small queries that could be one query.
- Set a maximum connection-pool size across all application instances.
- Use measurements to choose compute, memory, storage, and input/output operations per second (IOPS), which describes how many storage operations the database can perform each second.
Adding application servers can make the database problem worse. Ten servers with connection pools of 100 can attempt 1,000 database connections. Scaling the stateless application tier horizontally does not create more capacity in the single relational writer.
Use read replicas when reads—not writes—are the bottleneck and those reads can tolerate slightly old data. Reporting, analytics, and some product browsing often fit. A workflow that must immediately show a user's latest change usually does not.
Use Amazon ElastiCache when the application repeatedly reads the same popular data. The team must decide how long cached data may be old and how the cache is refreshed or removed after a change. A cache can reduce database load, but the database remains the durable source of truth.
In this study's classic Multi-AZ DB instance deployment, the standby exists for failover and cannot serve application reads. RDS Multi-AZ DB clusters are a different deployment type with readable standby instances, and Aurora has its own writer-and-reader architecture. Identify the deployment type before deciding whether a standby can serve reads.
9. Cost Controls
Each feature adds cost because it solves a different problem:
| Choice | What you pay for | What you gain |
|---|---|---|
| Multi-AZ DB instance deployment | Standby capacity and replicated storage behavior | Managed same-Region failover |
| Read replica | Additional database instance and storage | More read capacity and a separate read endpoint |
| Longer backup retention and snapshots | Additional backup storage when usage exceeds included storage | More recovery history |
| RDS Proxy | Managed proxy capacity | Connection reuse and improved connection resilience |
| Larger instance or provisioned IOPS | More database capacity | Higher compute, memory, or storage performance |
Single-AZ costs less because no standby capacity is maintained. That saving is not a valid tradeoff when the requirement explicitly says the production database must survive an instance or AZ failure automatically.
A read replica saves no work unless the application sends suitable read queries to it. Confirm that reads are the bottleneck and plan how those reads reach the replica before paying for one.
Choose capacity from measurements, but remember that instance size is only one cost source. Inefficient queries and indexes can force a larger instance. Excess storage, long snapshot retention, RDS Proxy, replicas, and cross-Region copies also add cost.
Aurora may be a better fit for some MySQL- or PostgreSQL-compatible workloads, especially when its cluster architecture or scaling features match the requirements. It is not automatically cheaper or required. Choose between RDS engines and Aurora from compatibility, availability, scaling, operations, and cost—not from the service name alone.
10. Exam Variants
For each exam question, ask: What failed or became overloaded, and what outcome is required? Availability, read scaling, historical recovery, connection control, and cross-Region disaster recovery have different answers.
| Requirement signal | Likely answer | Why |
|---|---|---|
| Automatically continue after an RDS instance or AZ problem | RDS Multi-AZ | RDS maintains a standby in another AZ and manages promotion. |
| The primary is overloaded by read-heavy traffic | Read replicas | They provide separate endpoints and database capacity for suitable reads. |
| Recover data from before an accidental deletion | Automated backups and PITR | The standby contains the current state; PITR creates a historical copy in a new instance. |
| Keep the relational database off the internet | Private DB subnets and security groups | The application tier connects privately, and its security group is allowed to reach the database port. |
| Many short-lived connections overwhelm the database | RDS Proxy or bounded application pooling | Reusing and limiting connections protects database memory and CPU. |
| Create a named recovery point before a risky migration | Manual DB snapshot | The snapshot records a deliberate pre-change checkpoint that persists until deleted. |
| Recover a relational database in another Region | Cross-Region backup or replica strategy | Multi-AZ protects one Region; another Region requires a separate copy and recovery plan. |
| Use readable standbys with managed Multi-AZ availability | RDS Multi-AZ DB cluster, where supported | This is a different architecture from the classic DB instance deployment with one non-readable standby. |
Watch for requirements that need more than one answer
Suppose an exam question says:
A production MySQL database must fail over automatically after an Availability Zone failure and must recover to a specific time after an accidental deletion.
The question contains two independent requirements:
infrastructure failure -> Multi-AZ
bad data -> automated backups and PITR
Multi-AZ answers “How does the database stay available after infrastructure failure?” PITR answers “How do we recover older data after a valid but harmful change?” The complete answer needs both.
11. Common Traps
| Trap | Better reasoning |
|---|---|
| "A read replica is the normal automatic failover target." | A classic read replica is mainly for read scaling. Promoting it and redirecting the application are separate actions. Multi-AZ provides the managed failover path. |
| "The Multi-AZ standby can serve reports." | The standby in a classic Multi-AZ DB instance deployment is reserved for failover and cannot serve application reads. |
| "No RDS standby can serve reads." | RDS Multi-AZ DB clusters have readable standbys. Always identify whether the question describes a DB instance deployment or a DB cluster deployment. |
| "Multi-AZ means multi-Region." | AZs are isolated locations inside one Region. Multi-AZ does not create a database copy in another Region. |
| "Multi-AZ replaces backups." | The standby copies good and bad changes. Historical recovery still requires automated backups or snapshots. |
| "PITR rolls the production database backward in place." | RDS creates a new restored DB instance and leaves production unchanged. The team must validate the restored instance and move or reconcile data. |
| "The RDS endpoint guarantees uninterrupted sessions." | The endpoint name remains stable, but its destination changes. Existing database connections can still break and must be reopened. |
| "Retry every failed write immediately." | The first write may have committed even when its response was lost. Retry only when an idempotency key, constraint, or business check prevents duplicate work. |
| "More application instances always improve capacity." | Every application instance can open more database connections. Scaling the application tier can overload a database that did not scale with it. |
| "A private database needs no security-group design." | Private routing removes a direct internet path. Security groups still decide exactly which resources may connect to the database port. |
Final Mental Model: One-Minute Review
Final Architecture Map
The final diagram shows three copies of database data, but each copy solves a different problem. Read the table first, then follow the arrows in the diagram.
| Term | Exact job | Remember it as |
|---|---|---|
| RDS endpoint | Gives the application a stable database name even when the writer behind it changes | The database's published phone number |
| Primary DB instance | Serves the application's normal reads and writes | The active records clerk |
| Multi-AZ standby | Maintains a synchronous current copy for managed failover in another AZ | The prepared relief clerk |
| Automated backups and PITR | Restore historical data into a new DB instance after a bad change | The database time machine |
| Read replica | Receives an asynchronous copy for additional read capacity | The reporting clerk |
| Reconnect and safe retry logic | Helps the application recover when failover breaks existing connections | Redialing carefully after the clerk changes |
Do not choose a database copy merely because the question says “high availability” or “replication.” Ask what the copy must do. The standby replaces a failed primary, the read replica serves additional reads, and backups recreate older data. None of them removes the application's responsibility to reconnect and retry safely during failover.
12. Related Topics
Read Amazon RDS for the overall managed database model, including engines, subnet groups, storage, backups, and security.
Read RDS Multi-AZ vs Read Replicas if availability and read scaling still feel like the same requirement.
Read RDS And Aurora Recovery Choices for snapshots, point-in-time recovery, backup replication, and disaster-recovery comparisons.
Read Amazon Aurora when the workload may need Aurora's cluster storage, reader endpoints, replica promotion, or global database options.
Read AWS Secrets Manager for database credential storage and rotation patterns.
Official AWS references: