Module Objective: Add a database layer to a cloud architecture, choosing between relational and non-relational options, and secure and migrate that data appropriately.

Builds on Module 4: The database layer gives the compute layer somewhere durable to read and write structured application state.

Architectural Need for a Database

Once a compute layer runs application logic, that logic almost always needs to persist state beyond a single request — user accounts, orders, inventory — which is what a dedicated database layer provides, separate from the compute and storage layers already built.

🔵 Note Separating the database from the compute layer — rather than running a database on the same instance as the application — is itself a design decision that supports independent scaling and easier failover.

Database Layer Considerations

Choosing a database is an architectural decision driven by data model, consistency requirements, query complexity, and expected scale — the same relational-vs-non-relational framing introduced in AWS Academy Cloud Foundations, now applied to real design trade-offs.

ConsiderationQuestion to Ask
Data modelDoes the data have complex relationships needing joins, or simpler key-based access?
ConsistencyDoes every read need the absolute latest write, or is eventual consistency acceptable?
ScaleWill demand grow gradually, or does it need to handle unpredictable, massive spikes?
Operational overheadHow much of the database engine's management should AWS handle versus the team?
✅ Tip — Let the Access Pattern Decide As in Module 8 of AWS Academy Cloud Foundations, the actual read/write pattern of the application — not a general preference for SQL or NoSQL — should drive the database choice.

Amazon RDS in an Architectural Context

For the café case study's relational needs, Amazon RDS provides the managed database layer — with Multi-AZ deployment protecting against failure and read replicas offloading read-heavy traffic, both of which connect directly to the high-availability patterns from Module 9 of this course.

🔵 Note Placing an RDS instance in a private subnet (Module 6) rather than a public one is a standard security pattern — the database should only be reachable from the compute layer, never directly from the internet.

Amazon DynamoDB in an Architectural Context

For workloads needing very low, consistent latency at large scale with simpler access patterns — such as storing session state or user preferences — DynamoDB fits where a relational engine would require more operational effort to scale to the same level.

✅ Tip — RDS and DynamoDB Can Coexist It's common in a real architecture for RDS to hold core transactional data (orders, accounts) while DynamoDB handles a specific high-scale need (session state, shopping cart) within the same application.

Database Security Controls

A database layer needs security controls at multiple levels: network-level isolation, encryption, and access control — bringing together concepts from IAM, KMS, and VPC covered earlier.

ControlWhat It Protects
Network isolation (private subnet, security groups)Prevents direct internet access to the database
Encryption at rest (AWS KMS)Protects stored data even if underlying storage is somehow accessed
Encryption in transit (SSL/TLS)Protects data moving between the application and the database
IAM database authenticationUses temporary IAM-based credentials instead of long-lived database passwords
⚠️ Warning — A Database Layer Is a High-Value Target Because databases typically hold the most sensitive data in an architecture, security controls here deserve more scrutiny than almost any other layer — a gap here has an outsized impact.

Migrating Data into AWS Databases

For an existing on-premises database, AWS Database Migration Service and the AWS Schema Conversion Tool provide the path into RDS or Aurora with minimal downtime, as covered in AWS Academy Cloud Foundations Module 8.

🔵 Note Migration planning is itself an architectural decision — whether to migrate with the same engine (homogeneous) or convert to a different one (heterogeneous) affects both the tooling used and the testing effort required.

Key Terms for Module 5

database layer
The architectural tier responsible for durable, structured application state, separate from compute
private subnet placement
A security pattern that keeps a database reachable only from the compute layer, not the internet
IAM database authentication
Using temporary IAM-based credentials for database access instead of long-lived passwords
homogeneous migration
Migrating a database between instances of the same database engine

Review Questions

  1. Why is separating the database layer from the compute layer considered good architectural practice?
  2. What questions should drive the choice between a relational and non-relational database for a given workload?
  3. Why is a database instance typically placed in a private subnet rather than a public one?
  4. What is the difference between a homogeneous and a heterogeneous database migration?