Lesson 123 · AWS Learning Path

AWS 123: Amazon RDS engines and components

Anil Jalela · Published Oct 26, 2025 · 12 min read

Why this lesson matters

Understand what RDS manages and what the database owner still manages across supported relational engines.

Amazon RDS manages infrastructure around supported relational engines; it does not manage the learner's schema, SQL, users, application transactions, or business recovery. This lesson separates every AWS-managed and customer-managed component before later lessons add availability, replicas, backup, proxy, and Aurora.

What you will be able to do

By the end, you can:

• explain amazon rds engines and components in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+----------------------+
|  Application query   |
+----------------------+
           |
           v
+-------------------------------------+
|  RDS endpoint and network controls  |
+-------------------------------------+
                  |
                  v
+------------------------------+
|  Managed engine and storage  |
+------------------------------+
               |
               v
+------------------------------------+
|  Backup, monitoring, and operator  |
+------------------------------------+

For Amazon RDS, the important boundary is this: A DB instance or cluster lives in a Region, uses subnet and security groups, stores data on managed storage, and exposes an endpoint. Engine features and deployment choices vary. The engine, version, class, storage, network placement, encryption, maintenance, backups, monitoring, parameter groups, and ownership match the requirement. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.

Architecture decision table

What Amazon RDS manages

RDS provisions a database host, managed storage, endpoint, monitoring integration, backup facilities, maintenance workflow, and supported high-availability/replica options. Depending on engine and deployment, AWS handles host replacement, infrastructure patching, storage management, automated backups, and failover orchestration.

The customer still owns:

• engine/edition/version and licensing decision;
• schemas, tables, constraints, indexes, SQL, stored code, extensions/options, and data quality;
• database accounts/roles/grants and master credential protection;
• VPC, subnets, routes, SGs, public-access choice, DNS, TLS, and client drivers;
• instance class, storage type/size/IOPS/throughput, autoscaling limit, parameter/option groups;
• backup retention, snapshots/copies, deletion protection, restore drills, and application cutover;
• maintenance windows, upgrades, compatibility tests, monitoring, alarms, incident response, and cost.

No normal SSH/root access exists to the managed RDS host. If an application requires unsupported OS agents, filesystem changes, kernel tuning, or unrestricted superuser behavior, evaluate RDS Custom where supported or self-managed database on EC2, including the much larger operational burden.

Supported relational engine directions

Aurora MySQL/PostgreSQL-compatible engines are cluster-based RDS services with a different storage architecture and are taught in AWS 128. Compatibility tests are mandatory before moving between standard RDS and Aurora.

Resource hierarchy and request path

application host / Lambda / container
       |
       | DNS + TCP + TLS + database authentication
       v
RDS endpoint:port -> DB instance or Multi-AZ DB cluster member
       |                    |
       |                    +-> parameter/option groups
       |                    +-> managed storage and transaction logs
       |                    +-> backup/replica/failover paths
       v
VPC subnet-group placement + ENI + security groups
       |
       +-> CloudWatch metrics/logs, Enhanced Monitoring, Database Insights, events

The RDS API/Console is the control plane; SQL protocol traffic to the endpoint is the data plane. IAM permission to DescribeDBInstances does not grant a PostgreSQL/MySQL login. Database credentials do not grant ModifyDBInstance. IAM database authentication, where supported, bridges token generation to a configured database user but still preserves both policy layers.

Networking from zero

A DB subnet group lists subnets, normally in at least two AZs. RDS chooses placement from that group. The subnet group does not create routes or permit clients. A private design uses subnets without direct internet ingress, SG inbound from the application SG on the exact DB port, return path, DNS support, and an administration path such as SSM-managed host/VPN - not public exposure.

PubliclyAccessible=true controls public addressing/DNS behavior in conjunction with subnet/VPC setup. A “public subnet” alone does not make a DB reachable, and an SG opening 0.0.0.0/0 is unsafe even if the current route happens to block it. Test from one approved client and one denied client.

RDS control-plane interface endpoints (PrivateLink) let private clients call RDS APIs; they do not carry PostgreSQL/MySQL/Oracle/SQL Server application connections to the DB endpoint.

Compute and storage

Choose DB instance class from engine/version support, CPU architecture, vCPU, memory, network/EBS bandwidth, local optimization, and licensing. Burstable classes can hide sustained CPU-credit exhaustion. A class modification can cause downtime/failover and needs a change window.

RDS storage choices vary by engine:

• General Purpose SSD (gp3 and legacy gp2) balances cost/performance; gp3 can decouple supported IOPS/throughput from size within limits.
• Provisioned IOPS SSD (io1/io2 Block Express where supported) targets sustained latency/IOPS requirements with provisioned cost.
• Magnetic storage is legacy and should not be selected for new designs.
• Storage autoscaling can increase allocated capacity up to a configured maximum; it does not scale down. Low free storage and autoscaling constraints require alarms.

Storage performance is constrained by database page access, queue depth, instance EBS bandwidth, provisioned IOPS/throughput, storage size, snapshots/backups, and engine checkpoints. Increasing IOPS cannot fix a table scan caused by a missing index.

Parameter groups, option groups, and maintenance

A parameter group is a version-family-specific collection of engine settings. Dynamic parameters can apply without restart; static parameters enter pending-reboot. Default groups cannot be edited, so create named custom groups through IaC and document every override/reversal.

Option groups enable engine-specific persistent features for supported engines. Some options are permanent or affect backups/licensing. Verify exact engine edition/version and removal behavior.

Maintenance includes OS/platform patches, engine minor/major versions, CA rotation, and instance/storage changes. AutoMinorVersionUpgrade does not remove the need to test current upgrade targets. Major upgrades require explicit compatibility and rollback planning. “Apply immediately” can combine pending modifications and cause unexpected interruption; inspect all pending values first.

Security layers

1. IAM controls RDS API actions and, where configured, database token generation.
2. VPC routing, NACLs, and SGs control TCP reachability.
3. TLS authenticates/encrypts the database connection when correctly validated against the current RDS CA.
4. Database users/roles/grants control schemas and SQL.
5. KMS encryption protects storage, logs, backups, snapshots, and replicas according to service behavior.
6. Secrets Manager can store/rotate credentials through supported rotation logic; an application role receives only GetSecretValue for the required secret and KMS decrypt path.

Encryption choice has creation-time/migration consequences. To encrypt an unencrypted deployment, the normal pattern can require snapshot/copy/restore or engine-specific migration, not an in-place toggle. Protect key deletion because an encrypted snapshot retained for years is useless without its key.

Build sequence for a learning database

1. Record engine/version, class, storage, Region/AZ design, cost estimate, deletion time, and owner.
2. Create private subnets/routes and a DB subnet group; create SG ingress only from an approved test-client SG.
3. Create custom parameter/option groups with documented defaults and changes.
4. Create a Secrets Manager secret or generated master credential path; never place a password in shell history, IaC parameters, or evidence.
5. Create encrypted RDS with backup retention, maintenance window, deletion protection appropriate to environment, logs/monitoring, and tags.
6. Wait with a bounded waiter; inspect events on delay.
7. Connect from the approved client with TLS and CA validation. Create a non-master application role/schema.
8. Run positive transaction, unauthorized-user, denied-network, restart/failover where approved, backup/restore, and monitoring tests.
9. Delete in reviewed reverse order or record retained state. Final snapshot policy must be explicit; never choose “skip final snapshot” by habit.

Worked decisions

Small PostgreSQL learning workload

Use the smallest supported class/storage that meets lab requirements, private networking, short backup retention, generated secret, TLS, and immediate timed cleanup. Do not promise free usage; current free-tier/account eligibility and public IPv4 charges must be checked.

Commercial SQL Server application

Select edition from exact feature needs before class sizing because licensing dominates. Validate Multi-AZ mode, AD integration, native backup support, collation, SQL Agent/features, and migration downtime. Aurora is not a compatible substitute.

Workload requiring host agent

Standard RDS rejects arbitrary OS agent installation. Evaluate RDS Custom support/perimeter or EC2. The choice trades managed convenience for patching, backup, HA, monitoring, and automation ownership.

Steady high-I/O PostgreSQL

Use Database Insights/query plans to separate inefficient SQL from real storage need, then benchmark gp3 and provisioned IOPS under production-shaped load. Include instance EBS limits and backup/failover behavior.

Required evidence

• Current engine/version/Region support query and rejected alternative.
• Full network and identity path with an approved and denied client.
• Parameter diff, pending-reboot status, maintenance/change plan, and rollback artifact.
• Committed transaction plus query/schema evidence using a least-privilege application user.
• Metrics, engine logs, events, storage/connection evidence, and one diagnosed failure.
• Snapshot/PITR restore into a new instance, integrity checks, measured RPO/RTO, and cleanup.
• Complete cost and retained-resource ledger.

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Open RDS, then Databases, and inspect an approved database or supplied capture.
2. Read Engine, Region and AZ, Connectivity, Storage, Configuration, Maintenance, Monitoring, and Backup sections.
3. Open Subnet groups, Parameter groups, and Option groups and explain why each is separate.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws rds describe-db-instances --query 'DBInstances[].{Id:DBInstanceIdentifier,Engine:Engine,Version:EngineVersion,Class:DBInstanceClass,Status:DBInstanceStatus,Public:PubliclyAccessible,Encrypted:StorageEncrypted}' --output table
aws rds describe-db-subnet-groups --query 'DBSubnetGroups[].{Name:DBSubnetGroupName,State:SubnetGroupStatus,Vpc:VpcId}' --output table

Expected interpretation

Available proves the control plane considers the instance ready. It does not prove client DNS, routes, security groups, credentials, schema health, query latency, or restore readiness.

Practical work

Create p06-rds-blueprint.md for a private MySQL-compatible order database. Record engine/version policy, two-AZ subnets, SG path, encryption, secrets, backups, monitoring, maintenance, and ownership.

Diagnose this topic from its own evidence

Trace connection failures in order: endpoint/DNS, route/NACL/SG, listener/port, TLS/CA, database identity, schema grant, then SQL. Trace performance through query plan/locks, connections, CPU/memory, instance network/EBS limits, storage IOPS/throughput, and background maintenance. Trace changes through RDS events, pending values, parameter status, engine logs, and CloudTrail. Never make the DB public or grant master/admin to hide the failed layer.

Cost and cleanup

DB instance hours, storage, I/O or IOPS, backup beyond allowance, data transfer, monitoring, and optional features can charge.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Understand what RDS manages and what the database owner still manages across supported relational engines.

1. Which scope or ownership boundary must be proved first?

Expected direction: A DB instance or cluster lives in a Region, uses subnet and security groups, stores data on managed storage, and exposes an endpoint. Engine features and deployment choices vary.

1. What evidence is strong enough to accept the result?

Expected direction: The engine, version, class, storage, network placement, encryption, maintenance, backups, monitoring, parameter groups, and ownership match the requirement.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid treating RDS as serverless by default, exposing it publicly for convenience, or assuming AWS owns schema and query design.

1. Which cost dimensions and retained resources need an owner?

Expected direction: DB instance hours, storage, I/O or IOPS, backup beyond allowance, data transfer, monitoring, and optional features can charge.

Lesson acceptance

Pass with an exact engine/version decision, complete private resource diagram, managed-responsibility explanation, secure credential/TLS path, full storage/parameter/maintenance plan, positive and denied transactions, monitored failure, tested restore, upgrade/rollback evidence, cost model, and final resource inventory.

Official sources

• Amazon RDS User Guide
• RDS security
• AWS databases
• Database decision guide