Architecture Highlights

• Auto Scaling automatically replaces unhealthy instances and scales with load.
• ALB health checks on the application root keep only healthy instances in rotation.
• Zero-touch deployments via S3 ZIP bundles pulled in user data at boot.
• Private RDS with security groups that only allow traffic from the app tier.
• No direct public access to the database; traffic is always funneled through the app.

Example Application Endpoints

• / – Home page served by Flask.
• /db-write – Writes a test record to RDS to validate connectivity.
• /db-read – Reads back records to verify HA database setup.

Multi-Tenant Model

• Each tenant has a unique identifier that is propagated through the stack.
• Tenant context is validated at the edge (Cognito + API Gateway authorizers).
• Lambda functions enforce tenant isolation when reading or writing data.
• DynamoDB tables logically separate tenants’ records to prevent data leakage.
• Architecture is ready for per-tenant throttling, quotas, or plans in the future.

Authentication & Authorization

• Sign-up and sign-in flows handled by Amazon Cognito.
• JWT tokens passed from the frontend to API Gateway for every request.
• Lambda receives verified user identity and tenant info from request context.
• Role-based access control ready for admin vs. standard tenant users.

API & Data Layer

• REST APIs exposed via API Gateway for tenant-scoped operations (e.g., items).
• Lambda functions implement create/read/update/delete operations.
• DynamoDB tables such as a Tenants table and an Items table store SaaS data.
• All data access paths include tenant checks to maintain strict isolation.

CI/CD Flow

• Developer pushes to the main branch on GitHub.
• CodePipeline Source stage pulls the latest commit via CodeConnections.
• CodeBuild installs dependencies, runs pytest, and builds the Docker image.
• Image is tagged (commit hash + latest) and pushed to Amazon ECR.
• Build generates imagedefinitions.json for the ECS deploy action.
• CodePipeline updates the ECS Fargate service with the new image definition.

ECS Fargate & Blue/Green Deployment

• ECS service runs Fargate tasks in private subnets for better security.
• ALB is internet-facing and forwards traffic on port 80 to a target group.
• New deployment spins up a green task set with the new image.
• ALB health checks hit the /health endpoint before shifting traffic.
• Once healthy, traffic moves from the blue task set to the green one.
• Old tasks are drained and stopped, giving you zero-downtime rollouts.

Tech Stack & Testing

• Python 3.11 + Flask web app with / and /health routes.
• Pytest unit tests executed on every build.
• Docker-based workflow using a lightweight Python image.
• Buildspec-driven CodeBuild configuration (buildspec.yml).
• Terraform code in infra/ to codify core infrastructure.

Example Ingested Events

Application events are sent as newline-delimited JSON into the raw bucket:

  {"event_type": "page_view", "event_timestamp": "2025-12-03T12:00:00", "user_id": "u1", "page": "/home"}
  {"event_type": "page_view", "event_timestamp": "2025-12-03T12:01:00", "user_id": "u2", "page": "/pricing"}
  {"event_type": "signup",    "event_timestamp": "2025-12-03T12:02:00", "user_id": "u3", "plan": "pro"}
        

Lambda enforces schema, drops bad records, and can enrich events (e.g., geo, campaign, device).

Data Flow

• Producers upload raw JSON files to the event-pipeline-raw-<yourname> bucket.
• S3 ObjectCreated events trigger a Lambda function.
• Lambda reads the raw object, parses each event, and validates required fields.
• Cleaned events are grouped by (event_type, event_date).
• Lambda writes curated files to event-pipeline-curated-<yourname> using a partitioned S3 layout.

Transform & Partitioning Strategy

• Events are normalized into a consistent schema (timestamps, user IDs, dimensions).
• Bad records are logged and optionally sent to a dead-letter folder for inspection.
• Curated paths follow a hive-style layout:
  event_type=page_view/year=2025/month=12/day=03/...
• This layout optimizes Athena scans by pruning partitions at query time.
• Output format can be JSON or columnar (e.g., Parquet) for better compression and cost.

Analytics & Query Layer

• AWS Glue Crawler builds a table (e.g., events) in the event_pipeline_db database.
• Analysts query curated data directly from S3 using Amazon Athena.
• Athena query results are stored in event-pipeline-query-results-<yourname>.
• Optional: Redshift Serverless uses Spectrum to query the same external tables or load curated data into internal fact tables.

Monitoring, Security & Cost

• CloudWatch Logs capture Lambda execution details and transformation errors.
• Metrics and alarms notify via SNS if error rates or durations exceed thresholds.
• All buckets block public access; IAM roles are scoped to least privilege.
• S3, Athena, and Redshift are encrypted with KMS-managed keys.
• Pay-per-use design (Lambda, Athena, Redshift Serverless) keeps the pipeline cost-efficient.

Context & Problem

• Multi-tenant B2B SaaS platform running entirely on an EC2-based stack.
• All tenants share the same always-on capacity sized for combined peak load.
• AWS bill keeps trending up, even though many tenants are idle most of the month.
• Goal: reduce infrastructure cost in a measurable way without hurting SLAs.

Two Tenant Workload Patterns

• Tenant Type A – “Campaign” (Bursty / Occasional)
  Mostly idle, with short, intense campaigns where traffic spikes 50–100× normal. Very low average utilization but very high peak/average ratio.
• Tenant Type B – “Enterprise” (Continuous / High)
  Large customers using the app 24/7 across regions. Traffic is consistently high with only mild daily patterns and almost no idle time.
• Original EC2 cluster is forced to handle the worst-case combined peak of both types, so everyone pays for idle capacity.

Before vs After Architectures

Before – Shared EC2-Based Architecture

• Users → CloudFront → ALB → EC2 Auto Scaling Group in private subnets.
• Shared RDS / Aurora database and ElastiCache cluster across all tenants.
• Cluster must be sized for combined peak traffic of all tenants.
• Over-provisioned most of the time, leading to high fixed monthly cost.

After A – Serverless Path (Tenant Type A)

• Users → CloudFront → API Gateway → Lambda functions.
• DynamoDB (on-demand) as the multi-tenant data store for Type A tenants.
• S3 for static assets, uploads, and logs; optional SQS / EventBridge for async work.
• Pay-per-request model: near-zero cost when tenants are idle.
• Automatic scale-up during short campaign spikes without pre-provisioning servers.

After B – Managed Compute Path (Tenant Type B)

• Users → CloudFront → ALB → ECS services running on EC2 instances.
• Right-sized EC2 instances in an Auto Scaling group, covered by Savings Plans.
• RDS / Aurora with proper sizing and reserved capacity for continuous workloads.
• ElastiCache for caching and offloading hot reads from the database.
• Designed for high, predictable utilization where hourly pricing wins over per-request.

Modeled Cost Impact (Illustrative)

Numbers are modeled for portfolio/demo purposes to show relative differences, not exact AWS bills.

FinOps & Continuous Optimization

• Use Cost Explorer, Budgets, and Anomaly Detection to monitor trends and spikes.
• Tag resources by tenant type, environment, and architecture for chargeback/showback.
• Regularly review EC2 and RDS utilization to adjust instance types and commitments.
• Track DynamoDB and Lambda cost per 1,000 requests for serverless tenants.
• Continuously revisit architecture as tenant mix or traffic patterns change.