Original Architecture (EC2-based, Single AZ)
The original Bonzi-Corp infrastructure was a basic 3-tier deployment with single EC2 instances, no high availability, and manual scaling.
VPC: 10.0.0.0/16 — Single AZ (us-east-1a)
Public Subnet: 10.0.1.0/24
Web Server (EC2 t2.micro)
Apache httpd
Private Subnet: 10.0.2.0/24
App Server (EC2 t2.micro)
Java/Python on port 8080
RDS MySQL (db.t3.micro)
Single-AZ, 20GB
Issues with this Architecture
- Single point of failure (one instance per tier)
- No auto-scaling — can't handle traffic spikes
- Single AZ — entire stack goes down if AZ fails
- No load balancing
- Manual deployments, no CI/CD
- ~$67/month
Updated Architecture (Serverless)
The evolved architecture eliminates EC2 instances entirely, using S3 + CloudFront for static content and Lambda + API Gateway for the API layer.
Global / Edge Services
CloudFront CDN
S3 Static Hosting
API Gateway (HTTP)
VPC: 10.0.0.0/16 — Multi-AZ (us-east-1a + us-east-1b)
Private Subnets (Multi-AZ)
Lambda Function
Python 3.11 / 512MB
RDS MySQL (db.t3.micro)
Multi-AZ, Encrypted, 20GB
VPC Endpoint
Secrets Manager (private)
Benefits of this Architecture
- Zero EC2 instances to manage or patch
- Auto-scales to thousands of concurrent users
- Multi-AZ database with automatic failover
- Pay-per-request pricing (no idle costs)
- HTTPS termination at CloudFront edge
- No NAT Gateway — VPC Endpoint keeps traffic private
- Full monitoring: CloudWatch alarms, access logs, CloudTrail
- WAF with rate limiting (1000 req/5min per IP)
- ~$43/month at 5,000 users/day
Upgrade Path
Follow these steps to migrate from the original EC2-based architecture to the serverless stack. The deploy script handles most of the work automatically.
Prerequisites
- AWS CLI configured with appropriate IAM permissions
- Python 3 and pip3 installed locally
- Files:
deploy.sh, lambda_handler.py, bonziCorpEvolved.yaml, professional-index.html
Option A: Fresh Deploy (New Database)
Use this if you're starting from scratch or don't need existing data.
./deploy.sh us-east-1 bonziCorpEvolved
This creates everything: VPC, Lambda, API Gateway, RDS, CloudFront, and uploads the static site.
Option B: Use Existing Database
Use this if you already have an RDS instance with production data.
./deploy.sh us-east-1 bonziCorpEvolved \
--existing-db mydb.abc123.us-east-1.rds.amazonaws.com \
--db-secret-arn arn:aws:secretsmanager:us-east-1:123456789:secret:rds!db-xyz
Skips RDS creation. Lambda connects to your existing database using the provided Secrets Manager ARN.
Option C: Migrate Data Then Deploy
Use this for a clean cutover with data preserved.
- Snapshot your existing database:
aws rds create-db-snapshot --db-instance-identifier your-db --db-snapshot-identifier pre-migration
- Delete or decommission the old stack
- Run fresh deploy:
./deploy.sh us-east-1 bonziCorpEvolved
- Restore snapshot to the new RDS instance
Expected downtime: ~10-15 minutes during cutover.
What the Deploy Script Does
- Creates an S3 bucket for Lambda deployment packages
- Installs Python dependencies and zips the Lambda function
- Uploads the zip to S3
- Deploys/updates the CloudFormation stack (all infrastructure)
- Uploads the static HTML to the S3 website bucket
Subsequent deploys (code changes only) just re-package Lambda and update the function — no infrastructure downtime.