AWS Curriculum: Deciding Between EC2 Hosted vs. Managed Databases

This curriculum provides a strategic framework for determining the optimal hosting environment for database workloads on AWS. It covers the spectrum from "unmanaged" (Self-hosted on EC2) to "fully managed" (RDS, DynamoDB, etc.) services, focusing on the trade-offs between administrative overhead and granular control.

## Prerequisites

Before beginning this module, learners should have a foundational understanding of the following:

• Cloud Computing Basics: Familiarity with the AWS Shared Responsibility Model.
• AWS Core Services: Basic knowledge of Amazon VPC (Networking) and Amazon EC2 (Compute).
• Database Fundamentals: Understanding the difference between Relational (SQL) and Non-Relational (NoSQL) data models.
• Administrative Tasks: Awareness of standard DB tasks such as patching, backups, and OS-level configurations.

## Module Breakdown

## Learning Objectives per Module

Module 1: The Managed Spectrum

• Objective: Define "Managed Resources" and explain how they "hide" underlying complexity.
• Key Concept: The "Rule of Thumb" — If you can edit it, you own it.

Module 2: Databases on EC2

• Objective: Identify scenarios where SSH access and OS-level configuration are mandatory.
• Key Concept: Administrative burden vs. total control.

Module 3: Amazon RDS & Aurora

• Objective: List the six (or seven) supported database engines and explain Multi-AZ deployments for high availability.
• Key Concept: Automated backups and patching windows.

Module 4: NoSQL and Beyond

• Objective: Distinguish between RDS (Relational) and DynamoDB (NoSQL) based on latency and scale requirements.

## Visual Anchors

The Management Trade-off Scale

Management Effort vs. Customization

## Success Metrics

How to know you have mastered this curriculum:

1. Justification Ability: You can provide a business-case justification for choosing EC2 over RDS (e.g., "We require a specific Oracle plugin not supported by RDS").
2. Responsibility Mapping: You can accurately draw the line of responsibility for OS patching in both EC2 and RDS scenarios.
3. Engine Identification: You can list the primary engines supported by RDS (MySQL, MariaDB, Oracle, PostgreSQL, SQL Server, and Aurora).
4. Architectural Design: You can design a high-availability architecture using Multi-AZ RDS instances without manual intervention.

## Examples

[!TIP] Real-World Scenario 1: The Legacy Application A company has a 15-year-old application that requires a specific version of the Linux Kernel and a custom filesystem driver to run its database.

• Choice: Amazon EC2.
• Why: RDS does not allow OS-level access or custom kernel modifications.

[!IMPORTANT] Real-World Scenario 2: Rapid Growth Startup A mobile gaming startup expects its user base to grow from 1,000 to 1,000,000 in three months. They have a small engineering team with no dedicated Database Administrator (DBA).

• Choice: Amazon RDS / Aurora.
• Why: Automated scaling, patching, and backups allow the team to focus on application code rather than "care and feeding" of the server.

## Real-World Application

• Cloud Architect: You will use these principles to design cost-effective and resilient infrastructures for clients.
• DevOps Engineer: You will implement automation for database deployments, understanding when to use RDS APIs vs. configuration management (like Ansible) for EC2.
• Database Administrator (DBA): Your role shifts from manual patching and hardware provisioning to performance tuning and logical schema design.

## Comparison Table: EC2 vs. RDS