RDS and Aurora Architecture

Amazon RDS and Amazon Aurora let AWS teams run relational databases without building the undifferentiated parts of database operations: host provisioning, storage allocation, patch orchestration, backups, replica creation, monitoring hooks, and high-availability replacement workflows. The outcome of this lesson is practical: you should be able to look at a workload, choose between a standard RDS engine and Aurora, explain what fails over when an Availability Zone has a problem, and verify that an application connects through the right endpoint with the right recovery expectations.

In this course’s database and analytics section, RDS and Aurora are the managed relational foundation. They sit between application architectures that need SQL transactions and analytics services that consume durable business data later. The important design skill is knowing where AWS manages the database platform and where you still own schema design, query behavior, credentials, connectivity, capacity choices, and recovery objectives.

How RDS Is Built

Amazon RDS is a managed control plane wrapped around familiar database engines such as PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server. A DB instance is the compute boundary: it has a DB instance class, memory, CPU, networking, parameter groups, option groups where supported, a maintenance window, backup settings, and security group attachments. Storage is allocated to the instance using supported storage types, and AWS automates volume management, snapshots, replacement hosts, and supported maintenance activities.

A Multi-AZ RDS deployment creates a synchronous standby in a different Availability Zone for high availability. Applications do not write to both copies. They connect to the DB instance endpoint, and RDS keeps the standby ready. During a failover, RDS promotes the standby and moves the endpoint target. The application normally sees a broken connection or short outage, then reconnects to the same DNS name. Read scaling is a different feature: read replicas are separate asynchronous copies with their own endpoints. They can reduce read pressure, but they can lag behind the writer and should not be used for read-after-write paths unless the application tolerates stale data.

How Aurora Differs Internally

Aurora changes the architecture by separating database compute from a distributed storage volume. An Aurora DB cluster has one shared cluster volume spread across multiple Availability Zones. The writer and reader DB instances attach to that volume rather than owning independent full copies of storage. Aurora storage is replicated across Availability Zones, grows automatically within service limits, and is designed so compute failover does not require copying the database files to a new host.

The cluster has several endpoint types. The cluster endpoint routes to the current writer and is used for writes and strongly current reads. The reader endpoint load balances across available Aurora replicas and is used for read traffic that can tolerate replica behavior. Instance endpoints target a specific DB instance and are useful for diagnostics or special routing, but they create more operational coupling. Aurora replicas usually fail over faster than traditional replica promotion because they already use the shared storage volume. The trade-off is that Aurora-specific behavior, endpoints, costs, and engine compatibility details must be understood before treating it as a drop-in replacement.

Configuration Anatomy

The main RDS and Aurora design objects are the subnet group, security group, DB instance or DB cluster, engine version family, parameter group, backup configuration, encryption key, monitoring settings, and endpoint. A subnet group controls which private subnets the database may use. Security groups control network reachability, usually allowing database port access only from application security groups or controlled administration paths. Parameter groups set engine behavior such as connection limits, logging, timeouts, and memory-related settings. Backup retention, snapshot policy, deletion protection, and final snapshot behavior determine how reversible operational mistakes are.

The following valid JSON shows a narrow security group ingress rule shape used by infrastructure tooling. It allows PostgreSQL only from an application security group, not from the internet.

{
  "IpPermissions": [
    {
      "IpProtocol": "tcp",
      "FromPort": 5432,
      "ToPort": 5432,
      "UserIdGroupPairs": [
        {
          "GroupId": "sg-0123456789abcdef0",
          "Description": "Application tasks only"
        }
      ]
    }
  ]
}

The deterministic behavior of this rule is simple: traffic to port 5432 is accepted only when it originates from a network interface associated with the referenced security group. A laptop IP address, a different application tier, or a public scanner is not included by this rule.

Example 1: Single-AZ Development Database

A development environment often starts with a single RDS instance in private subnets, automated backups enabled, no public access, and a small instance class. This keeps cost low and gives developers a real relational engine. The expected behavior is that an Availability Zone or host failure can interrupt the database until RDS repairs or replaces capacity. That is acceptable only if the environment can be recreated or restored and the service objective allows downtime.

set -euo pipefail

aws rds describe-db-instances \
  --db-instance-identifier dev-orders \
  --query 'DBInstances[0].{Engine:Engine,MultiAZ:MultiAZ,PubliclyAccessible:PubliclyAccessible,BackupRetention:BackupRetentionPeriod}' \
  --output json

For a private single-AZ development instance with backups retained for seven days, the output shape should be similar to this: engine name populated, MultiAZ set to false, PubliclyAccessible set to false, and BackupRetention set to 7. If PubliclyAccessible is true, the database may still be protected by security groups, but the network placement no longer matches the intended private-only design.

Example 2: Multi-AZ RDS Production Writer

A production transactional service that uses standard PostgreSQL or MySQL commonly uses RDS Multi-AZ. The application uses one writer endpoint, a connection pool with conservative maximum connections, and retry logic for failed transactions that are safe to retry. The important behavior is not that failover is invisible. It is that AWS performs standby promotion and endpoint remapping while the application reconnects cleanly.

CREATE TABLE orders (
  order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  order_status VARCHAR(32) NOT NULL,
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX orders_customer_created_idx
  ON orders (customer_id, created_at);

This schema example supports a common application query: list recent orders for one customer. The index begins with customer_id, so the engine can find that customer’s rows without scanning every order. During an RDS failover, committed rows remain on the promoted standby because Multi-AZ replication is synchronous for the high-availability copy. In-flight transactions may fail and must be retried by the application according to business rules.

Example 3: Aurora Cluster With Read Scaling

Aurora is often chosen when a workload needs a managed relational database with faster replica failover, multiple read replicas, storage growth without manual volume resizing, or Aurora-specific features. A common pattern is to send write and read-after-write requests to the cluster endpoint while routing dashboard, search, or reporting reads to the reader endpoint. This separates user-facing correctness from read throughput.

set -euo pipefail

aws rds describe-db-clusters \
  --db-cluster-identifier prod-orders-cluster \
  --query 'DBClusters[0].{Writer:Endpoint,Readers:ReaderEndpoint,MultiAZ:MultiAZ,Encrypted:StorageEncrypted}' \
  --output json

The expected output has a writer endpoint, a reader endpoint, Encrypted set to true, and cluster members in more than one Availability Zone when the cluster is designed for high availability. If a reader fails, Aurora removes it from the reader endpoint target set. If the writer fails and a healthy replica is available, Aurora promotes a replica and updates the cluster endpoint to the new writer. Existing connections still break; endpoint continuity does not preserve TCP sessions.

Design Choices and Trade-Offs

Choose standard RDS when you need a familiar managed engine, predictable instance-based cost, engine features that are not Aurora-compatible, or a smaller workload that does not need Aurora’s distributed storage model. Choose Aurora when the workload benefits from cluster endpoints, faster replica-based failover, storage that grows automatically, and read scaling using multiple replicas. The choice should be tied to measured behavior: write throughput, read concurrency, failover tolerance, replica lag tolerance, feature compatibility, licensing, and total cost.

Single-AZ is a cost and simplicity choice, not a high-availability design. Multi-AZ RDS improves availability but does not scale reads unless separate read replicas are added. Read replicas improve read capacity but introduce asynchronous lag. Larger instance classes add CPU and memory, but they do not fix missing indexes or unbounded connection pools. Storage performance settings can help I/O-bound workloads, but inefficient queries can consume any storage budget. Aurora Serverless can reduce capacity management for variable workloads, but applications must still handle scaling events, connection pooling, and cold or warm capacity behavior according to the selected configuration.

Failure Modes and Troubleshooting

Symptom: application timeouts after a failover. The likely cause is stale pooled connections or clients caching DNS too long. Diagnose by checking RDS events, application connection errors, and whether new connections to the DB endpoint succeed. Correct by using the RDS or Aurora endpoint name, setting reasonable DNS and pool lifetimes, retrying idempotent operations, and ensuring the application opens fresh connections after failure.

Symptom: readers return old data. The likely cause is asynchronous replica lag on read replicas or Aurora readers under load. Diagnose with replica lag metrics and by comparing a write followed immediately by reads from writer and reader endpoints. Correct by routing read-after-write operations to the writer endpoint, reducing expensive reader queries, adding reader capacity where appropriate, or changing the user flow to tolerate eventual consistency.

Symptom: database CPU is high and scaling up gives little relief. The likely cause is inefficient SQL, missing indexes, excessive connection count, or lock contention. Diagnose with Performance Insights, slow query logs, database wait events, and query plans. Correct by adding targeted indexes, rewriting queries, bounding connection pools, batching noisy jobs, or separating analytical reads from the transactional writer.

Symptom: restore test takes longer than the recovery objective. The likely cause is an untested restore path, large data volume, missing automation, or dependent applications that cannot point to a restored endpoint quickly. Diagnose by timing a snapshot restore or point-in-time restore in a non-production environment. Correct by documenting restore steps, automating parameter and security group attachment, rehearsing endpoint cutover, and adjusting recovery objectives or architecture if the measured time is unacceptable.

Security, Performance, and Reliability Implications

Security starts with private network placement, restricted security groups, encryption at rest, TLS-capable client configuration, and secrets stored in a managed secret store instead of source code. IAM can control management-plane actions such as creating snapshots or modifying instances, while database users and roles still control SQL permissions inside the engine. Audit logs, slow query logs, and connection logs should be enabled according to the engine and compliance need, with care not to expose sensitive query parameters unnecessarily.

Performance depends on query plans, working set size, indexes, connection management, storage I/O, and replica routing. A common mistake is letting serverless functions create unbounded direct database connections. Use a pooler or managed proxy pattern when bursty compute would otherwise exhaust database connections. Reliability depends on Multi-AZ or clustered design, tested backups, deletion protection for important databases, maintenance planning, event monitoring, and application behavior during broken connections. Managed databases reduce operational labor, but they do not remove the need for schema discipline and recovery testing.

Hands-On Lab: Inspect an RDS or Aurora Design

Prerequisites: an AWS account with read access to RDS, CloudWatch, and EC2 security groups; AWS CLI configured; and one non-production RDS instance or Aurora cluster. Do not run this lab against a database you are not allowed to inspect.

  1. Set a shell variable for the target identifier: export DB_ID=your-db-or-cluster-name.
  2. Describe the instance or cluster and record engine, encryption, endpoint, backup retention, and Multi-AZ or cluster member placement.
  3. Inspect security groups attached to the database and confirm that inbound database access is limited to application or administration sources.
  4. Check recent RDS events for failover, maintenance, backup, or storage messages.
  5. Review CloudWatch metrics for CPU, connections, free storage where applicable, read/write latency, and replica lag where applicable.
  6. Verify that an application or test host connects through the endpoint name rather than a resolved IP address.
set -euo pipefail

: "${DB_ID:?Set DB_ID to an RDS DB instance or Aurora cluster identifier}"

aws rds describe-db-instances \
  --db-instance-identifier "$DB_ID" \
  --query 'DBInstances[0].{Endpoint:Endpoint.Address,Engine:Engine,MultiAZ:MultiAZ,Encrypted:StorageEncrypted,BackupRetention:BackupRetentionPeriod,SecurityGroups:VpcSecurityGroups[*].VpcSecurityGroupId}' \
  --output json

Verification: the command should return one JSON object for an RDS DB instance. Confirm that encryption and backup retention match the environment standard, the endpoint is a DNS name, and the security group list is expected. For Aurora, use the earlier describe-db-clusters command instead and verify writer and reader endpoints. Cleanup: this lab is read-only. Remove the shell variable with unset DB_ID. If you created any temporary test database user or security group rule outside these steps, remove it after verification.

Assessment Exercises

  1. An order service writes a row and immediately displays the order confirmation. Which Aurora endpoint should the confirmation read use, and what bug could appear if it uses the reader endpoint?
  2. A team enables RDS read replicas and expects automatic writer failover to a read replica. Explain the difference between Multi-AZ standby behavior and asynchronous read replica behavior.
  3. During an incident, new database connections work but old application workers keep failing. Name two diagnostics and two application-side corrections.
  4. A dashboard query increases CPU on the production writer every morning. Propose an RDS or Aurora routing change and one database-level improvement that should be tested before scaling the instance.
  5. Your restore drill misses the recovery time objective. Identify what evidence you would collect before deciding between automation improvements, architectural changes, or a revised objective.

Summary

RDS manages traditional relational engines around DB instances, storage, backups, patching, and high-availability options. Aurora keeps the relational programming model but uses a cluster architecture with distributed shared storage and writer, reader, and instance endpoints. Good architecture comes from matching those mechanisms to workload requirements: private connectivity, encrypted storage, right-sized compute, tested backups, clear replica semantics, bounded connections, and application retry behavior that assumes failover breaks active sessions.