Dual-Cloud Serverless Deployment with Terraform
Role Fit
This project is best aligned with junior Cloud Engineer roles that mention AWS or Azure exposure, infrastructure as code, CI/CD, and troubleshooting. It demonstrates repeatable deployment rather than manual portal-based configuration.
Project Summary
This project is a small infrastructure and deployment lab built around one idea: take the same lightweight Python API and publish it through two serverless paths from one repository. The point is not application complexity. The point is to practise repeatable cloud delivery, Terraform structure, CI/CD validation, and post-deployment checks in a way that can be explained clearly.
What this project is meant to prove
- infrastructure changes should be reproducible, not portal-only
- one small service is enough to demonstrate deployment discipline
- cloud work is stronger when build, validation, logging, and teardown are thought about together
- a dual-cloud comparison makes trade-offs easier to explain than a single isolated deployment
Tools and Technologies
- Terraform
- GitHub Actions
- AWS Lambda
- API Gateway
- Azure Functions
- Python
- CloudWatch
- Azure Monitor
Intended Build
- one small Python API
- one AWS Lambda plus API Gateway path
- one Azure Functions HTTP path
- Terraform provisioning for both environments
- GitHub Actions workflow for validation and deployment
- logging, rollback notes, and teardown documentation
Delivery Scope
1. Application and Infrastructure
- Write the small API locally
- Create Terraform structure for AWS and Azure
- Deploy manually once to confirm the baseline
2. CI/CD Workflow
- Add formatting and validation checks
- Add plan stage
- Add deployment on merge to main
- Handle secrets and environment-specific variables carefully
3. Operations and Cost Control
- Review logs in CloudWatch and Azure Monitor
- Add simple rollback guidance
- Document teardown steps
- Record cost-control guardrails
What a finished version should show
- a simple architecture view for both clouds
- the Terraform layout and why it was split that way
- the GitHub Actions flow used to validate and deploy
- example responses from both environments
- notes about rollback, teardown, and spend control
- a short comparison of AWS and Azure operational differences
Evidence worth capturing
- a successful GitHub Actions run
- Terraform plan and apply output
- one AWS response and one Azure response
- CloudWatch and Azure Monitor visibility
- one example of a deployment issue or validation decision that had to be fixed
Technical Assumptions
The application remains intentionally simple. The value of the project is in disciplined delivery, infrastructure design, and safe automation rather than application complexity.
Key Risks
- Accidental spend
- Weak IAM or RBAC permissions
- Broken Terraform state
- Poor secrets handling in the pipeline
Current State
This project is still being built, but the scope is intentionally narrow. That is deliberate. I want the finished version to show a clear deployment pipeline, real operational checks, and a documented comparison between two serverless platforms rather than a large app with weak infrastructure explanation.
Interview Talking Point
A strong interview explanation for this project is to describe one design trade-off clearly, for example why serverless was chosen over virtual machines, how IAM or RBAC scope was kept narrow, or how spend would be controlled in a real environment.