🐱 Build: Use AWS Services to Build a CatGram App

Aaron Rose

5 min read

This article was originally published on Medium.

Stop memorizing services. Start thinking like an architect. Click through real decisions to build your first scalable app.

What Makes This Different

Forget step-by-step tutorials where you mindlessly copy commands. This is about thinking like an architect. Each decision point forces you to consider real constraints: cost, scale, reliability, and simplicity.

You won’t just learn what AWS services do — you’ll discover when and why to use them. By the end, you’ll have architected a complete application and developed the mental framework to tackle any system design challenge.

Ready to think through your first cloud architecture?

The Challenge

You’re building CatGram — Instagram for cats. Simple concept: users upload cat photos, the app creates thumbnails, stores metadata, and serves photos to other users.

Your first user just hit “upload photo” from their phone. What happens next?

Think like an architect. Consider costs, scaling, and simplicity.

📱 Step 1: The Upload

Scenario: Sarah’s phone has a 4MB photo of her tabby, Mr. Whiskers.

Your Challenge: Where should this photo land when it hits your AWS infrastructure?

Think about:

• File storage that can handle any size
• Something that can trigger other processes
• Cost-effective for a startup

What’s your choice?

A) Directly into a database (RDS)

B) An S3 bucket

C) Store it on an EC2 instance

D) Email it to yourself

Answer: B) S3 bucket

Why S3 wins:

• Built for files: Handles any file size, image formats, metadata
• Event triggers: Can notify other services when files arrive
• Durability: 99.999999999% (11 9’s) durability
• Cost: Pay only for what you store, no servers to maintain

Why others don’t work:

• RDS: Databases aren’t meant for large binary files
• EC2: You’d have to manage storage, backups, scaling yourself
• Email: Please don’t

⚡ Step 2: Something’s Happening

Scenario: The photo is now safely in S3. But it’s just… sitting there. Your app needs to create thumbnails, extract metadata, maybe scan for inappropriate content.

Your Challenge: How does your system know a new photo arrived?

Think about:

• You can’t constantly check S3 (expensive, slow)
• The system should react immediately
• You want this to work for 1 photo or 1 million photos

What triggers your processing?

A) Check S3 every 30 seconds with a cron job

B) S3 automatically sends an event notification

C) The user clicks “I’m done uploading”

D) Your intern manually checks S3 all day

Answer: B) S3 automatically sends an event notification

Why event-driven wins:

• Instant: No waiting or polling delays
• Efficient: Only runs when needed
• Scalable: Works the same for 1 upload or 1000 simultaneous uploads
• Reliable: AWS handles the event delivery

S3 Event Types:

• s3:ObjectCreated:* - New file uploaded
• s3:ObjectRemoved:* - File deleted
• Plus many others

Why others fail:

• Cron job: Wastes money checking empty buckets, delays processing
• User clicking: Users forget, users leave, users aren’t reliable
• Manual checking: Your intern will quit

🤖 Step 3: The Worker

Scenario: S3 just sent an event: “New cat photo uploaded!” Now something needs to actually process it — resize it, create thumbnails, maybe run it through an AI that detects if it’s actually a cat.

Your Challenge: What should handle this processing work?

Think about:

• This happens irregularly (sometimes 0 photos/hour, sometimes 100)
• Processing takes 5–30 seconds per photo
• You’re a startup watching every dollar

What processes the photos?

A) An EC2 instance running 24/7

B) Lambda function (serverless)

C) Your laptop when you remember to check

D) A Kubernetes cluster

Answer: B) Lambda function (serverless)

Why Lambda is perfect here:

• Pay per use: Only charged when actually processing photos
• Auto-scaling: Handles 1 photo or 1000 photos simultaneously
• No servers: AWS manages everything — you just write the code
• Event integration: Connects directly to S3 events

Cost comparison:

• EC2 24/7: ~$180/month minimum (t3.medium)
• Lambda: ~$0.20 per 1M requests + compute time
• For a new app processing 1000 photos/month: Lambda = ~$0.02, EC2 = $180

Why others don’t work:

• 24/7 EC2: Expensive overkill for sporadic work
• Your laptop: Not scalable, not reliable, not professional
• Kubernetes: Way too complex for this simple task

💾 Step 4: The Database Decision

Scenario: Your Lambda function just finished processing Mr. Whiskers’ photo. It created three thumbnail sizes and extracted metadata (camera type, location, etc.). Now you need to store this information so your app can display photos to users.

Your Challenge: Where should you store the photo metadata and user information?

Think about:

• Fast reads (users want instant photo loading)
• User profiles, photo metadata, likes, comments
• Potential for viral growth

Your database choice:

A) DynamoDB (NoSQL)

B) RDS MySQL (SQL)

C) Store everything in S3 as JSON files

D) Excel spreadsheet in the cloud

Answer: Depends on your needs, but let’s say A) DynamoDB

Why DynamoDB for CatGram:

• Speed: Single-digit millisecond response times
• Scaling: Handles sudden viral growth automatically
• Serverless fit: No servers to manage, pairs well with Lambda
• Cost-effective: Pay for what you use

Sample data structure:

Photos Table:
- PhotoID (primary key)
- UserID, Timestamp, S3Key
- ThumbnailURLs, Metadata, Tags

Users Table:
- UserID (primary key)  
- Username, Email, ProfilePic
- FollowerCount, PhotoCount

When you might choose RDS instead:

• Complex relationships between data
• Need ACID transactions
• Team already knows SQL well
• Reporting and analytics requirements

Why others don’t work:

• S3 JSON files: Not a database, no querying capabilities
• Excel: We’re building an app, not managing a bake sale

🌐 Step 5: Serving Users

Scenario: Another user, Jake, opens CatGram and scrolls through photos. Your app needs to load dozens of thumbnails quickly. Jake is in Australia, your S3 bucket is in us-east-1.

Your Challenge: How do you make photos load fast for global users?

Think about:

• Network latency across oceans
• Popular photos requested frequently
• Bandwidth costs

Your solution:

A) Tell users to move closer to Virginia

B) CloudFront (CDN)

C) Copy S3 buckets to every AWS region

D) Compress everything to 1KB

Answer: B) CloudFront (CDN)

Why CloudFront solves this:

• Global edge locations: 400+ locations worldwide
• Caching: Popular cat photos cached closer to users
• Cost savings: Reduced data transfer from S3
• Speed: Milliseconds instead of seconds for global users

How it works:

1. Jake in Sydney requests cat photo
2. CloudFront checks local cache in Sydney
3. If not cached, fetches from S3 once, serves Jake
4. Next user in Sydney gets cached version (instant)

Bonus benefits:

• DDoS protection: Built-in security
• HTTPS: Free SSL certificates
• Custom domains: catgram.com instead of ugly S3 URLs

Why others fail:

• Move to Virginia: Not a scalable user acquisition strategy
• Copy to all regions: Expensive, complex to manage
• 1KB compression: Ever tried to see a 1KB cat photo? Not cute.

🎯 The Complete Architecture

Congratulations! You just architected a scalable photo-sharing app:

User uploads photo →
S3 (storage) →
S3 Event triggers →
Lambda (processing) →
DynamoDB (metadata) →
CloudFront (global delivery) →
Happy users worldwide

Your tech stack:

• Storage: S3
• Processing: Lambda
• Database: DynamoDB
• CDN: CloudFront
• Total servers managed: 0

💰 Cost Reality Check

For 10,000 photos/month with 100,000 views:

• S3: ~$2.30
• Lambda: ~$0.50
• DynamoDB: ~$1.25
• CloudFront: ~$1.00
• Total: ~$5/month

Same app on traditional servers: $200–500/month minimum

🚀 What You Just Learned

You didn’t just memorize AWS services — you learned to think in systems:

• Event-driven architecture: One service triggers another
• Serverless economics: Pay for what you use, not what you provision
• Global scale considerations: Users are everywhere
• Cost optimization: Choose services that match your usage patterns

Most importantly: You can now look at any app idea and start thinking, “What services would I need for this?”

Aaron Rose is a software engineer and technology writer.