Capstone

7 Portfolio Projects

Yeh 7 projects poore roadmap ka application hain — har ek project multiple buckets ke services ko ek real architecture mein combine karta hai. Yehi projects resume/GitHub pe dikhane laayak hain.

Jump to
01 Three-Tier Web Application02 Serverless REST API03 Automated CI/CD Pipeline04 Event-Driven File Processing System05 AI Document Analysis Pipeline06 Infrastructure as Code Stack (CDK)07 Production AI Chatbot

01 Three-Tier Web Application

Buckets used: Bucket 1, 2, 3, 4
Internet | [ ALB ] --- Public Subnet | [ EC2 App Servers x2 ] --- Private Subnet A | [ RDS Database (Multi-AZ) ] --- Private Subnet B
What
Classic web-app architecture: presentation (ALB), application (EC2), aur data (RDS) — teeno layers physically/logically separate.
Real org mein yeh kyun matter karta hai
Yeh sabse common enterprise pattern hai. 90% traditional web apps (na sirf startups, bade banks/e-commerce bhi) isi shape mein bante hain. Interview mein 'design a scalable web app' poochha jaaye toh yehi diagram banate hain.
Build steps
  • VPC banao (public + 2 private subnets, min 2 AZs for Multi-AZ)
  • ALB public subnet mein, target group EC2 instances ke liye
  • EC2 instances (app code) private subnet A mein, Auto Scaling Group ke saath
  • RDS Multi-AZ database private subnet B mein
  • Security Groups: ALB->EC2 (app port), EC2->RDS (db port) — koi direct internet access RDS ko nahi
  • App ko RDS se connect karo (connection string env variable se, credentials Secrets Manager se)
Tum kya seekhoge
  • VPC networking
  • Security Groups layering
  • Load balancing
  • App-to-DB connectivity
  • Multi-AZ failover

02 Serverless REST API

Buckets used: Bucket 2, 3, 4
Client | [ API Gateway ] | [ Lambda Function ] | [ DynamoDB Table ]
What
Ek fully serverless CRUD API — no servers to manage, auto-scales, pay-per-request.
Real org mein yeh kyun matter karta hai
Startups aur microservices teams isse bahut use karte hain — kam operational overhead, fast to build. GitHub pe templates bhi milte hain start karne ke liye.
Build steps
  • DynamoDB table banao (e.g. 'Items', partition key = id)
  • Lambda function likho (Python) jo CRUD operations kare (GET/POST/PUT/DELETE)
  • IAM role Lambda ko DynamoDB read/write access de (least privilege)
  • API Gateway REST API banao, har route (GET /items, POST /items) ko Lambda se integrate karo
  • Deploy karo aur Postman/curl se test karo
Tum kya seekhoge
  • API Gateway routing
  • Lambda handler patterns
  • DynamoDB CRUD
  • IAM role scoping

03 Automated CI/CD Pipeline

Buckets used: Bucket 5
GitHub push | [ CodePipeline ] | [ CodeBuild ] -> builds Docker image -> [ ECR ] | [ Deploy stage ] -> [ EC2 / ECS / EKS ]
What
Push-to-deploy automation — code likha, push kiya, baaki sab automatic.
Real org mein yeh kyun matter karta hai
Tumhara Philips/Cyient CI/CD background yahan directly kaam aayega — same mental model, bas AWS-native tooling. Har DevOps role mein yeh core expectation hai.
Build steps
  • GitHub repo connect karo CodePipeline se
  • buildspec.yml likho jo Docker image build kare
  • CodeBuild project banao jo image build karke ECR mein push kare
  • ECR se image ko ECS service pe deploy karne wala stage add karo
  • Ek code change push karke poora pipeline end-to-end trigger karo
Tum kya seekhoge
  • CI/CD orchestration
  • Docker build automation
  • ECR image registry
  • Deployment strategies

04 Event-Driven File Processing System

Buckets used: Bucket 2, 3, 5
[ S3 upload bucket ] | (event) [ EventBridge ] | [ Lambda processor ] | [ S3 processed bucket ] + [ SNS notification ]
What
File upload hote hi automatically process hoke ek dusri jagah save hoti hai, aur ek notification jaati hai.
Real org mein yeh kyun matter karta hai
Yeh pattern har jagah milta hai — image resizing, log processing, invoice parsing, data pipelines. Event-driven architecture ka bread-and-butter example.
Build steps
  • 2 S3 buckets banao: uploads aur processed
  • Lambda function likho jo file process kare (e.g. resize image, ya CSV parse kare)
  • EventBridge rule: uploads bucket 'Object Created' -> Lambda trigger
  • Processed file ko dusre bucket mein save karo
  • SNS topic banao, Lambda se ek notification publish karo (email/SMS)
Tum kya seekhoge
  • Event-driven design
  • Decoupled architecture
  • SNS notifications
  • S3-to-S3 workflows

05 AI Document Analysis Pipeline

Buckets used: Bucket 2, 3, 6
[ S3 upload (documents) ] | [ Lambda ] | [ Textract + Comprehend ] | [ DynamoDB (structured results) ]
What
Document upload karo, text/tables extract ho, sentiment/entities detect hon, sab structured form mein DynamoDB mein store ho.
Real org mein yeh kyun matter karta hai
AI service integration ka end-to-end example — 2026 mein yeh skill set almost har role mein expected hai, chahe pure ML role na bhi ho.
Build steps
  • S3 bucket banao documents ke liye
  • Lambda trigger karo jab document upload ho
  • Lambda Textract call kare (text/tables extract)
  • Extracted text ko Comprehend ko bhejo (sentiment/entities nikaalne ke liye)
  • Final structured result DynamoDB table mein save karo
Tum kya seekhoge
  • AI service chaining (Textract -> Comprehend)
  • End-to-end serverless workflow
  • Structured data storage

06 Infrastructure as Code Stack (CDK)

Buckets used: Bucket 5 (+ 2, 3, 4 as target infra)
[ CDK App (Python/TS) ] | defines -> VPC + ECS Cluster + RDS + Security Groups | [ cdk deploy ] -> CloudFormation -> actual AWS resources
What
Poora application stack — VPC, ECS cluster, RDS database, security groups — sab code se define aur deploy karo.
Real org mein yeh kyun matter karta hai
Senior/advanced roles mein IaC expected hota hai — infrastructure 'clickable' nahi, 'reviewable' (pull request) hona chahiye. Yeh production-grade practice hai.
Build steps
  • CDK app init karo (Python)
  • VPC construct define karo (public/private subnets)
  • ECS cluster + Fargate service construct define karo
  • RDS instance construct define karo (private subnet mein)
  • Security groups define karo jo layers ko properly isolate karein
  • `cdk diff` se preview karo, fir `cdk deploy`
Tum kya seekhoge
  • Full-stack IaC
  • Reusable constructs
  • Programmatic infrastructure review (diff before deploy)

07 Production AI Chatbot

Buckets used: Bucket 2, 3, 4, 6 — 2026 showcase piece
[ Frontend: S3 + CloudFront ] | [ API Gateway ] (chat endpoint) | [ Lambda orchestrator ] | [ Bedrock (Claude/Llama) ] + [ DynamoDB (conversation memory) ]
What
Ek full-stack AI-powered chatbot — static frontend, serverless backend, foundation model se powered, conversation history persist karta hai.
Real org mein yeh kyun matter karta hai
Yeh video ke hisaab se sabse strong 2026 portfolio piece hai — AI + serverless + full architecture, ek hi project mein. Resume/interview donon mein standout hota hai.
Build steps
  • Simple chat frontend (HTML/JS) banao, S3 mein host karo, CloudFront se serve karo
  • API Gateway banao chat endpoint ke saath (POST /chat)
  • Lambda orchestrator likho: request receive kare -> DynamoDB se pehle ki conversation history fetch kare -> Bedrock ko poora context bheje
  • Bedrock se response aaye, use frontend ko wapas bhejo
  • Response ko DynamoDB mein history ke saath save karo (agli baar context ke liye)
Tum kya seekhoge
  • Full-stack AI architecture
  • Conversation state management
  • Bedrock integration
  • CloudFront + S3 static hosting
Final Note
Saare 7 projects karne ke baad tum genuinely "AWS literate" ho — na ki 200 services memorize kiye, balki 15-20 core services ko deeply samajh ke real architectures bana paaye. Agla step: inhi projects ko apne resume/GitHub pe document karo with architecture diagrams.
← PreviousLab 9: Integration, Streaming & Networking+