Five Production-Style Builds Across RDS, Aurora, DynamoDB & ElastiCache
Part of my AWS learning journey. Instead of practicing RDS, Aurora, DynamoDB, and ElastiCache as isolated labs, I built five small connected projects instead, each one following the same production discipline: a dedicated environment, IAM least privilege, validation, failover or performance testing, and cleanup.
Full repository: github.com/tejasshinkar/Aws-Database-mini-projects
Concepts:
AWS RDS and Elasticache: https://dev.to/tejas_shinkar/aws-rds-elastic-cache-managed-databases-multi-az-failover-in-memory-caching-5dce
AWS Aurora and Dynamodb: https://dev.to/tejas_shinkar/aws-aurora-elasticache-patterns-dynamodb-the-complete-data-layer-1k3e
📋 Projects Covered
| # | Project | Main AWS Services | Type |
|---|---|---|---|
| 1 | RDS + EC2 Application | EC2, RDS, IAM, Security Groups, Python/Flask | Lab |
| 2 | RDS High Availability + Read Replica | RDS, Multi-AZ, Read Replica, EC2 | Lab |
| 3 | Aurora High Availability + Failover | Amazon Aurora, RDS | Lab |
| 4 | DynamoDB Design + Performance | DynamoDB, Partition/Sort Keys, GSI, LSI | Lab |
| 5 | DynamoDB + ElastiCache for Valkey | DynamoDB, ElastiCache for Valkey, EC2, IAM, Python | Lab |
Approach Applied Across All Five
Every project in this set followed the same working process rather than five unrelated one-off exercises:
- Understand the AWS service or architecture pattern before building it.
- Create and configure the required AWS resources.
- Apply IAM and network-security controls appropriate to the workload.
- Implement or test the actual solution, not just provision it.
- Troubleshoot configuration and permission issues as they came up.
- Capture evidence through screenshots and test results.
- Document the implementation and the cleanup process.
- Remove unused AWS resources to avoid unnecessary charges.
Project 1 — RDS + EC2 Application
A Flask application hosted on EC2, connected to an Amazon RDS database. The focus was on wiring the application and database together the way a real deployment would, using IAM and Security Groups to control access rather than hardcoding database credentials into the application.
Skills exercised: RDS configuration and database connectivity, EC2 administration and application hosting, IAM roles and least-privilege access, Security Groups and network troubleshooting.
Project 2 — RDS High Availability + Read Replica
Took the same RDS + EC2 foundation further to explore how RDS handles availability and read scaling in practice: Multi-AZ for automatic failover, and a Read Replica for offloading read traffic from the primary instance.
Skills exercised: RDS Multi-AZ concepts, Read Replica configuration, database high availability and scalability concepts.
Project 3 — Aurora High Availability + Failover
Moved from standard RDS engines to Amazon Aurora specifically to work with its replication model, cluster endpoints, and failover behavior directly, rather than only reading about how Aurora's architecture is supposed to behave.
Skills exercised: Aurora replication and failover concepts, cluster endpoint behavior, database high availability patterns.
Project 4 — DynamoDB Design + Performance
A shift out of the relational world entirely: designing a DynamoDB table's partition keys, sort keys, Global Secondary Indexes, and Local Secondary Indexes, then testing how those design decisions actually affect access patterns and performance under load.
Skills exercised: DynamoDB data modeling and key design, performance testing and access-pattern evaluation, NoSQL schema design trade-offs.
Project 5 — DynamoDB + ElastiCache for Valkey
Added a caching layer in front of DynamoDB and implemented the lazy-loading (cache-aside) pattern along with cache invalidation, the same approach that shows up constantly in systems that can't afford to hit the database on every single read.
Skills exercised: ElastiCache for Valkey integration, lazy loading and cache-aside architecture, cache invalidation strategy, Python automation with the AWS SDK (Boto3).
Repository Structure
aws-database-mini-projects/
│
├── README.md
│
├── 01-rds-ec2-application/
├── 02-rds-ha-read-replica/
├── 03-aurora-ha-failover/
├── 04-dynamodb-design-performance/
└── 05-dynamodb-elasticache-valkey/
Each project directory contains its own README, implementation details, and test evidence where applicable.
Technologies Used
- Cloud: Amazon Web Services
- Compute: Amazon EC2
- Relational Databases: Amazon RDS, Amazon Aurora
- NoSQL Database: Amazon DynamoDB
- Caching: ElastiCache for Valkey
- Networking: VPC, Security Groups, Subnets
- Security: AWS IAM
- Automation: Python, Boto3
- Version Control: Git and GitHub
Key Takeaways
- Connecting an EC2-hosted application to a managed database is straightforward technically, but doing it with least-privilege IAM and scoped Security Groups instead of hardcoded credentials is what makes it production-appropriate.
- RDS Multi-AZ and Read Replicas solve two different problems, availability and read scaling, and shouldn't be conflated with each other.
- Aurora's replication and failover behavior is different enough from standard RDS that it's worth testing directly rather than assuming the concepts transfer one-to-one.
- Good DynamoDB performance starts at the schema design stage. Partition key, sort key, and index choices made early determine what access patterns are actually efficient later.
- A cache is only as good as its invalidation strategy. Lazy loading solves the "don't cache what nobody asked for" problem, but it has to be paired with a real invalidation approach or it just serves stale data faster.
- The habit that mattered most across all five projects wasn't any single AWS service. It was the repeated discipline of scoping access, validating the result, and cleaning up afterward.
These projects were built for learning, experimentation, and portfolio development. Resource configurations are simplified compared with a real production environment, and all AWS resources were deleted or stopped after testing to avoid unexpected costs.
Top comments (0)