From Theory to Real-World Infrastructure π
As part of my 30 Days of AWS Terraform challenge, Day 22 was a major milestone where I moved beyond individual resources and built a production-style 2-tier architecture using Terraform.
This project was all about combining networking, security, compute, and database layers into a cohesive and secure system β just like real-world applications.
ποΈ The Goal: Build a Secure 2-Tier Architecture
The objective of this project was to design and deploy:
- Web Tier (Public Layer) β EC2 instances running a Flask application
- Database Tier (Private Layer) β MySQL RDS instance
These two layers communicate securely while maintaining strict isolation from public access.
π Architecture Overview
Web Tier (Public Subnet)
- EC2 instance running Flask app
- Accessible via Internet Gateway
- Uses User Data for automated setup
Database Tier (Private Subnet)
- Amazon RDS (MySQL)
- No public access
- Only accessible from Web Tier via Security Groups
βοΈ Core Infrastructure Components
To support this architecture, I provisioned:
π Networking
- Custom VPC
- Public & Private subnets
- Internet Gateway (for web tier)
- NAT Gateway (for private subnet outbound access)
π Security
- Security Groups with strict rules
- Principle of Least Privilege enforced
π Secrets Management
- AWS Secrets Manager for DB credentials
- No hardcoded sensitive data
π₯οΈ Compute
- EC2 instance with Flask app
- Automated setup via User Data
ποΈ Database
- RDS MySQL instance in private subnet
π§© Modular Terraform Architecture
One of the biggest highlights of Day 22 was applying Terraform Modules in a real project.
Instead of one large configuration file, I structured my code into reusable modules:
Module Structure:
- VPC Module β Networking setup
- Security Group Module β Access control
- RDS Module β Database provisioning
- Secrets Module β Credential management
- EC2 Module β Web server deployment
π Data Flow Between Modules
Terraform modules donβt communicate directly β so I used:
-
outputs.tfβ to expose values -
variables.tfβ to pass inputs
Example:
- VPC module outputs subnet IDs
- Root module passes them to EC2 & RDS modules
- Secrets module outputs credentials used by EC2
This pattern ensures:
βοΈ Loose coupling
βοΈ High reusability
βοΈ Clean architecture
π§ͺ Testing the Application
After deployment, I validated the setup by hitting:
-
/healthβ Application health check -
/db/infoβ Database connectivity
Seeing the Flask app successfully connect to the RDS instance was a huge win! π
π Security Best Practices Implemented
This project reinforced critical security principles:
βοΈ Private Database
- RDS placed in private subnet
- No direct internet exposure
βοΈ Controlled Access
- Only EC2 security group can access DB
βοΈ Secrets Management
- Credentials stored in AWS Secrets Manager
βοΈ Least Privilege
- Minimal permissions across components
π‘ Key Learnings from Day 22
- Modules are essential for scalable Terraform projects
- Networking design is critical for security
- Secrets should never be hardcoded
- Private subnets protect sensitive resources
- Testing validates real-world readiness
π§ Why This Project Matters
This was not just another Terraform lab β it was a real-world architecture simulation.
It taught me how to:
- Design secure systems
- Structure modular IaC
- Connect application & database layers
- Apply DevOps best practices
This is the kind of project that bridges the gap between learning and real engineering.
π Whatβs Next?
With only 8 days remaining, Iβm excited to explore:
- CI/CD integration
- Advanced security practices
- Multi-environment deployments
π― Final Thoughts
Day 22 was one of the most practical and rewarding days of this challenge.
It reinforced that:
π Good infrastructure is not just functional β itβs secure, modular, and scalable.
If you're learning Terraform, I highly recommend building projects like this to truly understand how cloud systems work.
Top comments (0)