Amazon RDS and Aurora are managed services that make running relational databases almost worry-free. For a data engineer, they replace the tedious work of setting up, patching, and backing up a database server manually. This directly helps you pass the DEA-C01 exam because a major topic is deploying and managing database instances without getting bogged down in server maintenance.
Jump to a section
A simple way to picture Amazon RDS and Aurora: Managed Relational Databases for Data Engineering
An Amazon RDS database instance is like renting a fully managed apartment. When you rent a managed apartment, the building manager handles all the maintenance and repairs. They fix the plumbing, replace the roof, and ensure the heating works. You, as a tenant, just bring your furniture and live there.
In contrast, a traditional on-premises database is like owning a house. If your house needs a new boiler, you must call the plumber, pay for the part, and schedule the repair. You are responsible for everything. With RDS, AWS is the building manager. They automatically apply security patches, back up your data, and replicate it across multiple floors (Availability Zones) for protection. If the server hardware fails, AWS simply moves your 'apartment' to another physical server without you noticing.
Amazon Aurora takes this analogy further. Aurora is like a luxury penthouse in a skyscraper designed from the ground up for performance. It uses a special plumbing system (a distributed storage layer) that is much faster and more reliable than a standard apartment. Aurora auto-scales the storage independently of the compute, so you never run out of space. The rental price is also more cost-effective for high performance, because the building manager has optimised the entire infrastructure for speed and efficiency.
Relational databases store data in tables with rows and columns, like a spreadsheet. They use a language called SQL (Structured Query Language) to ask questions and change data. For example, a retail database might have a 'Customers' table and an 'Orders' table, linked by a customer ID.
Before cloud computing, a team would buy a physical server, install a database engine (like MySQL or PostgreSQL), and assign a system administrator to keep it running. This was expensive and slow. Amazon RDS (Relational Database Service) changes this. RDS is a managed service that runs the database engine for you. AWS handles the operational heavy lifting.
When you launch an RDS instance, you choose a database engine. The main choices are MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Amazon Aurora. You also choose the instance size (how much CPU and memory) and the storage amount. AWS then provisions a virtual server (an EC2 instance in the background) and installs the chosen database engine on it.
Key features of RDS include:
Automated backups: RDS can automatically take snapshots of your database daily and store transaction logs for point-in-time recovery (PITR). This means you can restore your database to any second within a retention period of up to 35 days.
Multi-AZ (Availability Zone) deployment: This creates a synchronously replicated standby copy of your database in a different Availability Zone. If the primary AZ fails, AWS automatically fails over to the standby, minimising downtime.
Read Replicas: You can create read-only copies of your database to handle read-heavy workloads. These are asynchronous replicas and are great for scaling analytics or reporting queries.
Automatic patching: AWS manages the underlying operating system and database engine patches, applying them during a defined maintenance window.
Storage auto-scaling: RDS can automatically increase your storage size when it detects that you are running low on space, preventing outages.
Amazon Aurora is a proprietary database engine built by AWS, designed to be compatible with MySQL and PostgreSQL. It is not a standard MySQL or PostgreSQL; rather, it re-implements their wire-protocols. This means your existing code for MySQL or PostgreSQL works with Aurora, but under the hood, Aurora is completely different.
Key features of Aurora include:
Distributed storage: Aurora separates the compute (CPU/RAM) from the storage layer. The storage is automatically replicated across three Availability Zones, with six copies of your data. This provides extreme durability.
Higher performance: Aurora claims up to five times the throughput of standard MySQL and three times the throughput of standard PostgreSQL, due to its optimised storage and I/O system.
Auto-scaling storage: Storage in Aurora grows automatically from 10 GB up to 128 TB, with no downtime. You pay only for what you use.
Fast cloning: You can create a clone of a database that is copy-on-write, meaning it initially uses no extra storage and only grows as data changes. This is useful for testing.
Global Database: Aurora can span multiple AWS Regions for disaster recovery or low-latency global reads.
In summary, RDS gives you the comfort of a managed service with the flexibility of multiple database engines. Aurora gives you the extreme performance and scalability of a cloud-native database. Both are fully managed, meaning you do not manage the operating system, the hardware, or the database software itself. You only manage your data: schemas, users, permissions, and queries.
For the DEA-C01 exam, you will be tested on which features belong to which service, what the benefits are, and how to choose between them. You must also know the key configuration options: instance class, storage type, Multi-AZ, Read Replicas, backup retention, and the different database engines.
Choose Database Engine and Edition
Select the database engine you need: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, or Amazon Aurora. Each has different licensing costs and features. For the DEA-C01 exam, know which engines are open-source (MySQL, PostgreSQL, MariaDB) and which are commercial (Oracle, SQL Server). Aurora is a unique option.
Configure Instance Specifications
Choose the instance class (e.g., db.t3.micro for small, db.r5.large for memory-intensive) and storage amount (GB). Also choose the storage type: General Purpose SSD (gp2/gp3), Provisioned IOPS SSD (io1), or Magnetic (not recommended). Storage auto-scaling can be enabled to avoid running out of space.
Set up High Availability and Connectivity
Decide if you need Multi-AZ for failover. Configure the VPC, subnet group, and public accessibility. You must set up security groups to control inbound traffic. For exam, know that Multi-AZ requires a secondary subnet in a different Availability Zone.
Configure Backup and Maintenance
Set the automated backup retention period (0-35 days) and the backup window. Define the maintenance window for updates and patching. Ensure you understand that manual snapshots are not deleted automatically, while automated backups are deleted when you delete the DB instance.
Deploy and Verify Connectivity
Click 'Create database' and wait for the instance to be 'Available'. Then connect using a database client, using the endpoint (hostname), port, and credentials you set. Use test queries to verify the database is working. This step confirms that all networking and security groups are configured correctly.
Create Read Replicas or Cross-Region Replicas (Optional)
If you need to scale read traffic, create one or more Read Replicas. For Aurora, you can also create a Global Database for cross-region replication. This step is often tested: knowing how to improve read performance versus disaster recovery.
Let us walk through a realistic scenario at a company called 'ShopCloud', an e-commerce platform. The company is migrating from their on-premises SQL Server database to AWS because their current server keeps running out of storage and crashes during holiday sales.
The senior data engineer, Priya, is tasked with setting up the new database. She first chooses Amazon RDS for PostgreSQL because the team wants to use open-source and save on licensing costs. She does - Create a new DB instance: She navigates to the RDS console, clicks 'Create database', selects PostgreSQL, and chooses a db.r5.large instance (4 vCPU, 16 GB RAM) to handle their expected traffic. She configures 200 GB of General Purpose (gp2) SSD storage with storage auto-scaling enabled.
Next, she configures High Availability: She enables Multi-AZ. RDS immediately provisions a standby database in a second Availability Zone. AWS synchronously replicates every write to both databases. This ensures that if the primary AZ fails, the database automatically switches to the standby within a minute or two.
For disaster recovery, she sets automated backups with a retention period of 7 days. She also enables point-in-time recovery so they can restore to any second within that week. She schedules the maintenance window for 3 AM on Sundays, when traffic is lowest.
The development team at ShopCloud wants a reporting database that does not slow down the main production database. Priya creates a Read Replica of the production database. This replica is asynchronous, meaning it lags slightly behind the primary. The reporting team connects their queries to the Read Replica endpoint, leaving the main database free for customer transactions.
After a few months, ShopCloud's traffic explodes. The main database is getting 50,000 writes per second and is starting to slow down. Priya needs a serious performance boost. She decides to migrate from RDS PostgreSQL to Amazon Aurora PostgreSQL. She creates an Aurora cluster from a snapshot of her RDS instance. The migration takes a few hours, but it is a straightforward process.
Once on Aurora, the performance improves dramatically. Aurora's distributed storage automatically scales from 200 GB to 2 TB as more orders come in, with no downtime. Priya also enables Aurora Auto Scaling for read capacity, which automatically creates and deletes new read replicas based on CPU usage. The cost is lower than the equivalent RDS MySQL instance because the storage I/O costs are more efficient.
Priya also creates a Global Database for their disaster recovery requirements. She sets up a secondary Aurora cluster in the Europe (London) region. This replicates data asynchronously but at a very low latency. If the primary region in US-East fails, they can promote the London cluster to be the primary and keep the business running.
The project is a success. ShopCloud now has a highly available, scalable, and cost-effective database. The team never thinks about hardware failure, patching, or storage limits. They simply focus on writing better queries and analysing customer data.
On the DEA-C01 exam, the topic 'Deploy and manage relational database instances on AWS' is heavily tested. You will see questions that force you to differentiate between RDS, Aurora, and managing your own database on EC2. Traps are everywhere.
Here are the specific question patterns:
Multi-AZ vs Read Replicas: The exam loves to ask whether a scenario requires high availability (Multi-AZ) or scaling for reads (Read Replicas). Multi-AZ is for failover; it does not help with read performance. Read Replicas improve read performance but do not provide automatic failover. If the scenario says 'improve read performance after a crash', the answer is always 'Read Replicas' because Multi-AZ alone does not offload queries.
Aurora scaling limits: They will ask 'What is the maximum storage for Aurora?' The answer is 128 TB. They will try to confuse you with '64 TB' or 'Unlimited'. You must remember that RDS storage can auto-scale but Aurora starts at 10 GB and goes to 128 TB.
Backup retention: RDS allows automated backup retention up to 35 days. Long-term backups (for years) require manual snapshots. The exam will ask 'How to keep backups for 1 year?' The answer is manual snapshots, not automated backups.
Engine selection: They ask which engine is best for 'high performance' or 'enterprise features'. If the scenario mentions Oracle compatibility or legacy apps, the answer is RDS Oracle. If it mentions 'cloud-native' or 'high throughput', the answer is Aurora MySQL or Aurora PostgreSQL. If the scenario mentions open-source and cost, answer RDS MySQL or RDS PostgreSQL.
Multi-AZ for Aurora: Aurora is already multi-AZ by design (six copies across three AZs). Therefore, Multi-AZ for Aurora is a concept that is different from RDS Multi-AZ. Do not confuse the feature names.
Read Replica lag: Aurora Read Replicas are asynchronous. The exam will test that they are 'eventually consistent' and can have lag. Do not assume they are synchronous.
Storage types: RDS supports gp2, gp3, io1, and magnetic. Aurora only uses one internal storage type that is automatically provisioned. The exam may ask about cost optimisation.
Encryption: RDS and Aurora both support encryption at rest using AWS KMS. If the question is 'how to enable encryption after creation', the answer is you cannot directly; you must create a manual snapshot (encrypted) and restore it.
The trap patterns are usually: giving a scenario that wants high availability but listing 'Read Replica' as an option. Another trap is asking about storage for Aurora vs RDS and listing the limits incorrectly. Always read the scenario carefully: is the priority 'minimising downtime' (Multi-AZ) or 'handling more read traffic' (Read Replicas)?
You must memorise the default port numbers: MySQL 3306, PostgreSQL 5432, Oracle 1521, SQL Server 1433, Aurora is the same as its compatible engine.
Finally, the exam tests the concept of 'instance provisioning'. They may ask: 'Which service provides automatic storage scaling?' The answer is both RDS (via the 'Storage Auto Scaling' feature) and Aurora (inherently). But the trap is that RDS requires you to enable the feature, while Aurora does it by default.
In summary, know the difference between managed (RDS/Aurora) and unmanaged (EC2 self-managed). Know the RDS backup window, retention period, and snapshot vs automated backup. Know Aurora's distributed storage and its compatibility with MySQL/PostgreSQL. Practise the port numbers and the Multi-AZ vs Replica types.
Amazon RDS is a managed service that supports multiple database engines including MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora.
Aurora is a proprietary, cloud-optimised relational database engine compatible with MySQL and PostgreSQL, providing higher performance and availability.
Multi-AZ deployments provide high availability by synchronously replicating data to a standby instance in a different Availability Zone; they do not improve read performance.
Read Replicas are used to offload read traffic from the primary database and are asynchronously replicated, meaning they can have some lag.
RDS automated backups have a maximum retention period of 35 days; for longer-term retention, you must take manual snapshots.
Aurora automatically replicates your data six times across three Availability Zones for extreme durability and can scale storage from 10 GB up to 128 TB automatically.
These come up on the exam all the time. Here's how to tell them apart.
Amazon RDS (standard engine)
Uses standard MySQL, PostgreSQL, etc. engines off the shelf.
Storage is on EBS volumes (gp2, gp3, io1). Maximum 16 TB for MySQL.
Replicas: Up to 15 asynchronous Read Replicas.
Storage: Manual scaling or auto-scaling (if enabled) up to 16 TB.
Performance: Limited to the performance of the underlying EBS volumes.
Cost: Pay for allocated storage regardless of usage.
Amazon Aurora
A custom-built, cloud-optimised engine compatible with MySQL/PostgreSQL wire protocol.
Storage is a distributed, auto-replicated volume across 3 AZs (6 copies). Up to 128 TB.
Replicas: Up to 15 Aurora Replicas with low-latency replication.
Storage auto-scales from 10 GB to 128 TB automatically.
Performance: Up to 5x throughput of standard MySQL.
Cost: Pay for storage consumed plus I/O operations; often cheaper per transaction.
Multi-AZ (RDS)
Purpose: High availability and automatic failover.
Replication: Synchronous replication to a standby in a different AZ.
Standby is not active for reads or writes until failover.
Cost: You pay for the primary and standby instance compute + storage.
Impact on performance: No impact on write latency.
Use case: Minimising downtime during AZ failure.
Read Replicas (RDS)
Purpose: Scaling read traffic and offloading queries.
Replication: Asynchronous replication; data is eventually consistent.
All replicas are active and can serve SELECT queries.
Cost: You pay for the primary and each replica's compute + storage.
Impact on performance: Can temporarily increase write latency slightly.
Use case: Reporting, analytics, or high-read workloads.
Automated Backups (RDS)
Automatic daily backups with point-in-time recovery up to 35 days.
Deleted when the DB instance is deleted (unless you specify final snapshot).
Retention period configurable from 0 to 35 days.
Cost: Included in the instance cost (no extra charge for storage up to 100% of DB size).
Cannot be shared across accounts directly.
Used for short-term recovery.
Manual Snapshots (RDS)
Manual on-demand snapshot you initiate.
Persist even after the DB instance is deleted.
No automatic retention limit; you must manually delete them.
Cost: You pay for the snapshot storage in Amazon S3.
Can be copied and shared across AWS accounts.
Used for long-term retention and disaster recovery.
Mistake
Amazon RDS and Amazon Aurora are two completely separate services that have nothing in common.
Correct
Aurora is a specific database engine that runs within the Amazon RDS service. Aurora is a type of RDS instance, just like MySQL or PostgreSQL. They share the same management console, concepts like Multi-AZ, Read Replicas, and backup settings.
Aurora is often marketed as a separate product, leading people to think it is not part of RDS. In the AWS console, you launch both from the same RDS section. This confusion causes mistakes when the exam asks about 'RDS features' – Aurora still uses those features.
Mistake
Read Replicas are always synchronously updated, so they are identical to the primary at all times.
Correct
Read Replicas in RDS and Aurora are asynchronous. This means there is a small lag between the primary writing data and the replica receiving it. The data is 'eventually consistent', not 'strongly consistent'.
People understand the word 'replica' as a perfect copy, but the technical mechanism for performance reasons uses asynchronous replication. Beginners assume synchronous because it sounds safer. The exam uses this to test understanding of read consistency.
Mistake
If you enable Multi-AZ on RDS, you automatically get two readable copies of your database for better read performance.
Correct
Multi-AZ provisions a standby replica that is not used for reads or writes unless a failover occurs. It sits idle to ensure high availability. For offloading read queries, you need separate Read Replicas, not Multi-AZ.
The phrase 'standby copy' misleads people into thinking it is another active server. In reality, the standby is passive to maintain synchronous replication. The exam tests this by offering 'Multi-AZ' as a solution for read performance; the correct answer is 'Read Replicas'.
Mistake
You must manually scale the storage on an RDS instance when it gets full, or the database will crash.
Correct
RDS offers Storage Auto Scaling. You can enable it to automatically increase the storage when the free space drops below a threshold (typically 10%). Aurora does this automatically without any setting at all.
This misconception comes from experience with on-premises databases where you had to manually add disks. Older AWS documentation also made it less obvious. Beginners think they have to constantly watch storage levels.
Mistake
Amazon Aurora is always more expensive than RDS MySQL, so it is never worth using for small workloads.
Correct
Aurora can be more cost-effective for many workloads because it uses a distributed storage system that reduces I/O costs and improves performance. For write-heavy workloads or those requiring high durability, Aurora often costs less per transaction. For very low-traffic, tiny databases, RDS MySQL may be cheaper.
Aurora's billing model includes I/O charges, while RDS MySQL includes I/O in the storage cost. People see the 'per GB' cost of Aurora and think it is always higher. They miss the overall cost of operation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
RDS is a managed service where AWS handles patching, backups, and hardware maintenance. Running a database on EC2 means you are responsible for everything: installing the database software, applying patches, managing backups, and handling failover.
Aurora is compatible with MySQL and PostgreSQL only. To migrate an Oracle database, you would use the AWS Database Migration Service (DMS) to move the data, but you would need to convert your schema and code to PostgreSQL or MySQL first.
You can modify the DB instance from the AWS Management Console, CLI, or SDK. Choose the 'Reset master password' option, enter the new password, and AWS applies the change. The instance will not reboot automatically unless you specify a reboot.
The instance is terminated and you stop paying for compute and storage. The final snapshot remains in your account as a manual snapshot, and you will be charged for the storage it uses. You can restore a new instance from this snapshot later.
Aurora Serverless is a variant of Aurora that automatically scales compute capacity up and down based on workload, and you pay only for the capacity you consume. It still uses the same distributed storage layer. It is useful for intermittent workloads.
Yes. For RDS MySQL, MariaDB, PostgreSQL, and Oracle, you can create up to 15 Read Replicas. For Aurora, you can create up to 15 Aurora Replicas per cluster. These replicas can be cross-Region as well.
You've finished Amazon RDS and Aurora: Managed Relational Databases for Data Engineering. Continue through the DEA-C01 study guide to build a complete picture of the exam.
Done with this chapter?