DevOps On AWS 04: S3, CloudFront và Lambda - Tối ưu chi phí và hiệu suất

Chào mừng bạn đến với bài thứ tư trong series "DevOps On AWS"! Sau khi đã tìm hiểu về AWS cơ bản và IAM, EC2 instances, và Load Balancer, hôm nay chúng ta sẽ khám phá bộ ba dịch vụ không thể thiếu trong hầu hết mọi ứng dụng AWS: S3 (Simple Storage Service), CloudFront và Lambda.

Ba dịch vụ này tạo thành một hệ sinh thái hoàn chỉnh: S3 để lưu trữ, CloudFront để phân phối nội dung nhanh chóng, và Lambda để xử lý logic mà không cần quản lý server. Trong thực tế, bạn sẽ thấy chúng xuất hiện trong gần như mọi project AWS - từ website tĩnh đơn giản đến hệ thống xử lý video phức tạp.

1. S3 (Simple Storage Service) - Kho lưu trữ không giới hạn

1.1. S3 là gì và tại sao nó quan trọng?

S3 (Simple Storage Service) là dịch vụ storage của AWS mà bạn có thể coi như một "ổ cứng khổng lồ trên internet". Khác với ổ cứng thông thường, S3 có thể lưu trữ không giới hạn dữ liệu và cho phép truy cập từ bất kỳ đâu trên thế giới.

Tại sao S3 lại được dùng nhiều đến vậy?

• Không giới hạn dung lượng: Từ vài MB đến hàng petabyte
• Độ bền cao (99.999999999%): AWS cam kết dữ liệu của bạn sẽ không bị mất
• Truy cập từ mọi nơi: Chỉ cần có internet là có thể download/upload
• Tích hợp sâu: Kết nối dễ dàng với hầu hết dịch vụ AWS khác
• Chi phí hợp lý: Trả tiền theo dung lượng sử dụng thực tế

1.2. Cấu trúc cơ bản của S3

S3 tổ chức dữ liệu theo cấu trúc:

AWS Account
├── Bucket 1 (my-website-bucket)
│   ├── index.html
│   ├── style.css
│   └── images/
│       ├── logo.png
│       └── banner.jpg
├── Bucket 2 (user-uploads)
│   ├── user123/
│   │   ├── avatar.jpg
│   │   └── documents/
│   └── user456/
└── Bucket 3 (app-logs)
    ├── 2025/01/01/
    ├── 2025/01/02/
    └── ...

Bucket: Giống như thư mục gốc, tên bucket phải duy nhất toàn cầu Object: File bạn lưu trữ, có thể là bất kỳ định dạng nào Key: Đường dẫn đến file trong bucket (như đường dẫn file trên máy tính)

1.3. Các Storage Classes - Chọn loại lưu trữ phù hợp

AWS cung cấp nhiều "hạng" storage khác nhau, mỗi loại có giá cả và tốc độ truy cập khác nhau:

🟢 S3 Standard (dùng thường xuyên):

• Giá: $0.023/GB/tháng
• Trường hợp sử dụng: Website content, mobile apps, game assets
• Thời gian truy cập: Tức thì

🟡 S3 Standard-IA (Infrequent Access - ít dùng):

• Giá: $0.0125/GB/tháng + phí lấy dữ liệu
• Trường hợp sử dụng: Backup, disaster recovery, data archiving
• Thời gian truy cập: Tức thì nhưng có phí khi download

🔵 S3 Glacier (lưu trữ lâu dài):

• Giá: $0.004/GB/tháng
• Trường hợp sử dụng: Sao lưu dài hạn, compliance archives
• Thời gian truy cập: Vài phút đến vài giờ

🟣 S3 Glacier Deep Archive (lưu trữ rất lâu dài):

• Giá: $0.00099/GB/tháng
• Trường hợp sử dụng: Lưu trữ 7-10 năm, regulatory archives
• Thời gian truy cập: 12-48 giờ

1.4. S3 vs EBS - Khi nào dùng cái nào?

Nhiều người mới học AWS thường bối rối không biết khi nào dùng S3, khi nào dùng EBS. Đây là sự khác biệt cốt lõi:

🏠 EBS (Elastic Block Store) - Ổ cứng của máy tính:

EC2 Instance
├── Root Volume (EBS) - /
├── Data Volume (EBS) - /data
└── Application Files

Đặc điểm EBS:

• Gắn trực tiếp vào EC2 instance như ổ cứng
• Hiệu suất cực nhanh (như SSD trên máy tính)
• Chỉ 1 instance có thể sử dụng tại một thời điểm
• Phù hợp cho: OS, database files, application data

🌐 S3 - Kho storage trên internet:

Internet
├── Website files (HTML, CSS, JS)
├── User uploads (Images, Videos)
├── Backups & Archives
└── Static content

Đặc điểm S3:

• Truy cập qua HTTP/HTTPS API
• Có thể truy cập từ nhiều nơi cùng lúc
• Độ trễ cao hơn EBS nhưng vẫn rất nhanh
• Phù hợp cho: Static files, backups, media content

1.5. Tình huống thực tế: Khi nào dùng EBS vs S3?

🔨 Dùng EBS khi:

Tình huống 1: Database Server

# MySQL database cần truy cập file liên tục
EC2 Instance (Database Server)
├── EBS Root Volume: OS và MySQL
├── EBS Data Volume: Database files (.mdb, .log)
└── EBS Backup Volume: Daily database dumps

Tình huống 2: Web Application với session storage

# Ứng dụng cần đọc/ghi file liên tục
EC2 Instance (Web Server)
├── EBS: Application code và cache
├── EBS: User session files
└── EBS: Temporary processing files

🌐 Dùng S3 khi:

Tình huống 1: Website tĩnh

# Portfolio website của designer
S3 Bucket (my-portfolio)
├── index.html
├── style.css
├── portfolio-images/
│   ├── project1.jpg
│   ├── project2.png
└── resume.pdf

Tình huống 2: Social Media App

# App chia sẻ ảnh như Instagram
S3 Bucket (user-content)
├── photos/
│   ├── original/user123/photo1.jpg
│   ├── thumbnail/user123/photo1_thumb.jpg
├── videos/
└── profile-pictures/

Tình huống 3: Log Storage

# Thu thập logs từ nhiều servers
S3 Bucket (application-logs)
├── 2025/01/01/
│   ├── server-01.log
│   ├── server-02.log
├── 2025/01/02/
└── analytics/
    ├── user-behavior.json
    └── performance-metrics.json

1.6. Ví dụ chi tiết: Xây dựng hệ thống upload file

Hãy cùng xem một ví dụ thực tế về việc xây dựng tính năng upload file cho một ứng dụng học online:

Kiến trúc hệ thống:

User Upload File
    ↓
Frontend (React/Vue)
    ↓
API Gateway + Lambda
    ↓
S3 Bucket (course-materials)
    ↓
CloudFront CDN (phân phối nhanh)

Quy trình xử lý chi tiết:

1. Teacher upload video bài giảng (500MB)

   • Frontend call API để lấy signed URL từ S3
   • Upload trực tiếp từ browser lên S3 (không qua server)
   • Lambda trigger khi upload xong để xử lý metadata

2. Teacher upload slide (5MB PDF)

   • Lưu vào S3 Standard để truy cập nhanh
   • Tự động tạo thumbnail preview (Lambda)
   • Sync với CDN để học viên download nhanh

3. System backup course data (hàng GB)

   • Chuyển sang S3 Glacier sau 30 ngày
   • Automated lifecycle policy
   • Tối ưu chi phí: từ $23/tháng xuống $4/tháng

2. CloudFront - CDN cho tốc độ toàn cầu

2.1. CloudFront là gì và vì sao cần CDN?

CloudFront là dịch vụ CDN (Content Delivery Network) của AWS. Để hiểu CDN, hãy tưởng tượng bạn có một cửa hàng bán bánh mì ở Hà Nội. Nếu khách ở TP.HCM muốn mua, họ phải bay ra Hà Nội - mất thời gian và tốn kém.

CDN giống như việc bạn mở thêm chi nhánh ở TP.HCM, Đà Nẵng, Cần Thơ... Khách hàng ở đâu thì mua ở chi nhánh gần nhất, nhanh và rẻ hơn.

Vấn đề khi không có CDN:

User ở Singapore
    ↓ (200ms latency)
Server ở Virginia, US
    ↓ (200ms latency)  
User nhận được file
# Tổng: 400ms + download time

Với CloudFront CDN:

User ở Singapore
    ↓ (10ms latency)
CloudFront Edge ở Singapore  
    ↓ (file đã được cache)
User nhận được file
# Tổng: 10ms + download time (nhanh gấp 40 lần!)

2.2. CloudFront hoạt động như thế nào?

Kiến trúc CloudFront:

Origin Server (S3 hoặc ALB)
    ↓
CloudFront Distribution
    ↓
450+ Edge Locations toàn thế giới
    ↓
User requests

Quy trình hoạt động:

1. User yêu cầu file: User ở Tokyo truy cập website
2. Chuyển hướng đến edge gần nhất: DNS chuyển hướng đến edge location Tokyo
3. Kiểm tra cache: Edge location kiểm tra xem có file trong cache không
4. Cache HIT: Nếu có → trả về ngay lập tức
5. Cache MISS: Nếu không có → lấy từ origin → cache lại → trả về user

2.3. CloudFront vs Cloudflare - So sánh chi tiết

Nhiều bạn thắc mắc nên chọn CloudFront hay Cloudflare. Đây là so sánh thực tế:

🟢 CloudFront - Ưu điểm:

Tích hợp sâu với AWS:

# Setup tự động với S3
S3 Bucket → CloudFront Distribution (1 click)
# Tích hợp với Certificate Manager (SSL miễn phí)
# Kết nối với Route 53, WAF, Shield

Giá cả hợp lý:

• Miễn phí: 1TB data transfer/tháng
• Giá theo bậc: $0.085/GB cho 10TB đầu tiên
• Không có phí cho requests từ S3 origin

🟡 Cloudflare - Ưu điểm:

Dễ cài đặt:

# Chỉ cần thay đổi nameserver
Domain → Cloudflare Nameserver → Done
# Không cần cấu hình phức tạp

Tính năng bảo mật mạnh:

• DDoS protection miễn phí
• Web Application Firewall
• Bot protection
• Analytics chi tiết

Khi nào chọn CloudFront:

• Toàn bộ hạ tầng đã chạy trên AWS
• Cần tích hợp với S3, Lambda@Edge
• Muốn quản lý tất cả trong 1 console AWS
• Có team DevOps để config chi tiết

Khi nào chọn Cloudflare:

• Website/app chạy trên nhiều cloud providers
• Cần setup nhanh, ít cấu hình
• Ưu tiên tính năng bảo mật
• Budget hạn chế (free plan của Cloudflare rất tốt)

2.4. Tình huống thực tế với CloudFront

Tình huống 1: Website thương mại điện tử

# Trước khi dùng CloudFront
User ở Việt Nam → Server ở US (300ms)
Thời gian tải: 3-5 giây
Bounce rate: 40%

# Sau khi dùng CloudFront  
User ở Việt Nam → Edge ở Singapore (20ms)
Thời gian tải: 0.5-1 giây  
Bounce rate: 15%
Doanh thu tăng: 25%

Setup CloudFront cho thương mại điện tử:

# Static assets (CSS, JS, Images)
Origin: S3 Bucket
Cache TTL: 24 giờ
Nén: Enabled

# Dynamic content (API calls)
Origin: Application Load Balancer
Cache TTL: 0 seconds (pass-through)
Headers: Forward all

Tình huống 2: Nền tảng streaming video

# Vấn đề: Video 100MB, user download từ S3 Virginia
User ở Úc → Download 100MB → 2 phút
Chi phí data transfer: $0.09/GB

# Giải pháp: CloudFront caching
User ở Úc → Edge Sydney → Download 100MB → 10 giây  
Chi phí: $0.085/GB (tiết kiệm 6%)
Trải nghiệm người dùng: Cải thiện 10x

Tối ưu cho video streaming:

# Adaptive bitrate streaming
video-720p.m3u8 → Cache 1 hour
video-1080p.m3u8 → Cache 1 hour
video-chunks/ → Cache 24 hours

# Range requests support
Byte-range requests: Enabled
Chunked transfer: Enabled

2.5. CloudFront Best Practices

Tối ưu cache:

# Static assets (CSS, JS, Images)
Cache-Control: max-age=31536000 (1 năm)
Versioning: style.v1.2.3.css

# Dynamic API responses
Cache-Control: max-age=300 (5 phút)
Vary: Authorization, Accept-Language

# User-specific content
Cache-Control: private, no-cache

Tối ưu chi phí:

# Chọn Price Class phù hợp
Price Class All: 450+ locations → $0.085/GB
Price Class 100: 100 locations → $0.075/GB  
Price Class 200: 200 locations → $0.080/GB

# Dự án ở châu Á → chọn Price Class 200
# Tiết kiệm 6% chi phí mà vẫn cover được châu Á

3. Lambda - Cuộc cách mạng Serverless Computing

3.1. Lambda là gì và tại sao Serverless lại hot?

AWS Lambda là dịch vụ "serverless computing" - bạn chỉ cần viết code, AWS lo phần còn lại. Không cần quan tâm server, OS, scaling, hay maintenance.

Serverless không có nghĩa là "không có server". Vẫn có server, nhưng AWS quản lý toàn bộ, bạn chỉ cần focus vào business logic.

Tại sao Serverless lại được ưa chuộng?

So sánh Traditional vs Serverless:

# Traditional Server (EC2)
- Phải maintain server 24/7
- Trả tiền cả khi server idle  
- Manual scaling lên/xuống
- Phải lo security patching, OS updates
- Chi phí: $50-200/tháng minimum

# Serverless (Lambda)
- Code chạy khi cần, tắt khi không dùng
- Trả tiền theo millisecond sử dụng
- Auto scaling 0 → 1000+ instances
- AWS lo tất cả infrastructure  
- Chi phí: $0 khi không có requests

3.2. Khi nào nên dùng Lambda?

✅ Hoàn hảo cho Lambda:

Trường hợp 1: Xử lý hình ảnh

User upload ảnh → S3 → Lambda trigger
Lambda: Resize ảnh (1920px → 800px, 400px, 200px)
Lưu thumbnails → S3
Cập nhật database → DynamoDB
Thời gian chạy: 3-5 giây
Chi phí: $0.0001 per request

Trường hợp 2: Scheduled Jobs

# Gửi email nhắc nhở hàng ngày
EventBridge (Cron: 0 9 * * *) → Lambda
Lambda: 
- Query users có tasks due today
- Tạo personalized emails  
- Send qua SES
Thời gian chạy: 5 phút/ngày → Chi phí: $1/tháng

❌ Không phù hợp cho Lambda:

Các tiến trình chạy lâu:

# Video processing 30 phút → Lambda timeout 15 phút (Thời gian sống tối đa của Lambda là 15 phút)
# Machine learning training 2 giờ → Lambda không đủ
# WebSocket connections 24/7 → Lambda expensive  
→ Nên dùng EC2 hoặc ECS

3.3. Lambda Limitations và cách xử lý

⏰ Timeout tối đa: 15 phút

# Vấn đề: Xử lý video 20 phút
Original video: 500MB → Process → 30 phút

# Giải pháp 1: Step Functions
Lambda 1: Split video thành chunks 5 phút
Lambda 2: Process từng chunk song song  
Lambda 3: Merge chunks lại
Tổng thời gian: 7 phút (process song song)

# Giải pháp 2: Async processing với SQS
User upload → SQS queue → Lambda consumer
Nếu timeout → Message back to queue → Retry

💾 Giới hạn Memory: 10GB

# Vấn đề: Load 15GB data vào memory
Dataset: 15GB CSV file → Process → OutOfMemory

# Giải pháp: Streaming processing
Lambda: Read file từng chunk 100MB
Process từng chunk → Write result → S3
Repeat until done
Memory usage: Stable 1GB

3.4. Lambda Triggers - Cách "đánh thức" Lambda

🎯 S3 Event Trigger:

# Tự động xử lý khi có file mới
S3 Upload → Lambda trigger
Trường hợp sử dụng: Resize images, scan viruses, extract metadata

⏰ EventBridge (CloudWatch Events):

# Thực thi theo lịch
Cron expressions: 0 */6 * * * (Mỗi 6 giờ)
EventBridge → Lambda
Trường hợp sử dụng: Data backup, tạo báo cáo

📨 SQS Queue Trigger:

# Xử lý bất đồng bộ với retry logic
API → SQS → Lambda (batch processing)
Dead letter queue cho failed messages
Trường hợp sử dụng: Email sending, data processing

3.5. Lambda "Cold Start" và tối ưu hóa

❄️ Vấn đề Cold Start:

# Lambda không được invoke trong 5 phút → Container bị shutdown
Next request → Cold start (500ms-2s latency)
Warm start → Fast response (5-50ms)

# Cold start components:
Container khởi tạo: 200ms
Runtime khởi tạo: 300ms  
Function khởi tạo: User code init time

🔥 Cách giảm Cold Start:

1. Provisioned Concurrency:

# Giữ sẵn containers warm 24/7
Lambda function → Provisioned concurrency: 10 instances
Chi phí: $0.0000097 per GB-second
Trade-off: Chi phí cao hơn nhưng no cold start

2. Tối ưu container reuse:

• Khởi tạo connections bên ngoài handler function
• Tái sử dụng database connections, HTTP clients
• Cache dữ liệu thường dùng trong memory

3. Chiến lược warm-up:

# EventBridge → Lambda ping every 4 minutes
EventBridge rule: rate(4 minutes)
Lambda: Check if ping request → return "pong"
Giữ container warm → No cold start
Chi phí: Tối thiểu (ping requests trong free tier)

3.6. Lambda Auto Scaling và hiệu suất

📈 Lambda Auto Scaling:

# Concurrent executions
Giới hạn mặc định: 1000 concurrent
Burst capacity: 500-3000 (tùy region)
Tốc độ scale: +500 instances per minute

# Ví dụ thực tế:
Traffic bình thường: 50 RPS → 50 concurrent Lambdas
Black Friday: 2000 RPS → Auto scale to 1000 concurrent
Thời gian scale: 1-2 phút để đạt full capacity

⚡ Tối ưu hiệu suất:

# Memory vs CPU trade-off
Memory: 128MB → CPU: 0.1 vCPU (slow)
Memory: 1024MB → CPU: 0.6 vCPU (faster)  
Memory: 3008MB → CPU: 1 vCPU (fastest)

# Sweet spot cho hầu hết workloads: 1024MB
Điểm tối ưu Cost vs Performance

3.7. API Gateway timeout và async patterns

⏱️ API Gateway timeout: 30 giây

# Vấn đề: Lambda processing 2 phút, API Gateway timeout 30s
Client → API Gateway → Lambda (2 min processing)
Sau 30s → API Gateway return 504 timeout
Lambda vẫn chạy nhưng client mất kết nối

🔄 Giải pháp Async Pattern:

Pattern 1: Job Status Polling

# Bước 1: Bắt đầu job, trả về job ID
POST /api/process-video
Response: { jobId: "abc123", status: "processing" }

# Bước 2: Client polling status  
GET /api/jobs/abc123
Response: { status: "processing", progress: 45% }

# Bước 3: Job hoàn thành
GET /api/jobs/abc123  
Response: { status: "completed", result: "s3://bucket/result.mp4" }

Pattern 2: WebSocket Notifications

# Cập nhật real-time qua WebSocket
Client → API Gateway WebSocket → Lambda
Lambda → Cập nhật job status → Push notification to client
Không cần polling, instant updates

4. Case Study tổng hợp: Video Processing Platform

Hãy cùng xây dựng một hệ thống thực tế kết hợp cả 3 services: Nền tảng xử lý video

4.1. Kiến trúc tổng quan

User Upload Video
    ↓
React Frontend → S3 Pre-signed URL
    ↓  
S3 Bucket (raw-videos)
    ↓ (S3 Event Trigger)
Lambda (Video Processor)
    ↓
- Tạo thumbnail (3 giây đầu)  
- Nén video (720p, 480p)
- Extract metadata
    ↓
S3 Bucket (processed-videos)
    ↓
CloudFront CDN
    ↓
User xem video nhanh từ CDN

4.2. Quy trình thực hiện

Bước 1: Upload workflow

// Frontend: React component
const uploadVideo = async (file) => {
  // Lấy signed URL từ API
  const { uploadUrl, videoId } = await fetch('/api/upload-url', {
    method: 'POST',
    body: JSON.stringify({ 
      fileName: file.name,
      fileSize: file.size 
    })
  }).then(r => r.json());
  
  // Upload trực tiếp lên S3
  await fetch(uploadUrl, {
    method: 'PUT',
    body: file
  });
  
  // Polling processing status
  const checkStatus = async () => {
    const status = await fetch(`/api/videos/${videoId}/status`)
      .then(r => r.json());
    
    if (status.progress < 100) {
      setTimeout(checkStatus, 2000); // Check every 2s
    } else {
      setVideoReady(status.processedUrl);
    }
  };
  
  checkStatus();
};

Bước 2: Lambda processing workflow

Lambda function sẽ xử lý các công việc sau:

• Download video từ S3
• Trích xuất thumbnail từ giây thứ 3
• Nén video sang 720p và 480p
• Upload processed files về S3
• Cập nhật trạng thái processing trong DynamoDB

4.3. Phân tích chi phí: Lambda vs EC2

💰 So sánh chi phí cho 1000 videos/tháng:

Phương pháp Lambda Serverless:

Thời gian compute: 5 phút/video × 1000 videos = 5000 phút  
Chi phí Lambda: 5000 phút × $0.0000166667/GB-second = $25
S3 storage: 100GB × $0.023 = $2.3
CloudFront: 500GB transfer × $0.085 = $42.5
Tổng: $69.8/tháng

Ưu điểm:
- Không cần quản lý servers
- Auto scaling 0 → 1000+ concurrent  
- Chỉ trả tiền khi có jobs
- Không có idle cost

Phương pháp EC2 Traditional:

Instance: c5.2xlarge (8 vCPU, 16GB) 24/7 = $250/tháng
Storage: 500GB EBS = $50/tháng  
Load Balancer: $18/tháng
CloudWatch monitoring: $10/tháng
Tổng: $328/tháng

Ưu điểm: 
- Hiệu suất có thể dự đoán
- Có thể custom OS, runtime
- Phù hợp cho consistent workloads

🏆 Kết luận: Lambda tiết kiệm 79% chi phí cho workloads không đều/không thể dự đoán

4.4. Monitoring và troubleshooting

Các CloudWatch Metrics quan trọng:

# Lambda metrics
Duration: Thời gian thực thi trung bình
Errors: Tỷ lệ lỗi %  
Throttles: Số requests bị giới hạn
ConcurrentExecutions: Số instances đang chạy

# S3 metrics  
NumberOfObjects: Tổng objects trong bucket
BucketSizeBytes: Tổng dung lượng bucket
AllRequests: Tổng số request

# CloudFront metrics
Requests: Tổng requests được phục vụ
BytesDownloaded: Tổng data transferred
4xxErrorRate: Tỷ lệ lỗi client %
OriginLatency: Thời gian fetch từ origin

Chiến lược xử lý lỗi:

• Thực hiện retry logic với exponential backoff
• Sử dụng Dead Letter Queues cho failed messages
• Thiết lập CloudWatch alarms cho error thresholds
• Log thông tin lỗi chi tiết để troubleshooting

5. Best Practices và bảo mật

5.1. S3 Security Best Practices

🔒 Bucket Policies và kiểm soát truy cập:

Nguyên tắc quyền tối thiểu:

• Chỉ cấp minimum permissions cần thiết
• Sử dụng IAM roles thay vì access keys
• Thực hiện bucket policies cho fine-grained control

🚫 Block Public Access:

# Mặc định: block tất cả public access
Block all public ACLs: Enabled
Block public bucket policies: Enabled  
Ignore public ACLs: Enabled
Restrict public bucket policies: Enabled

Mã hóa dữ liệu:

• Bật S3 default encryption
• Sử dụng AWS KMS keys cho sensitive data
• Cân nhắc client-side encryption cho dữ liệu cực kỳ nhạy cảm

5.2. Lambda Security Best Practices

🏷️ IAM Roles với quyền tối thiểu:

• Tạo specific roles cho từng Lambda function
• Giới hạn permissions đến đúng resources cần thiết
• Thường xuyên audit và cleanup unused permissions

🔐 Mã hóa Environment Variables:

# Mã hóa sensitive data với AWS KMS
Environment variables:
DATABASE_URL: encrypted
API_KEYS: encrypted  
JWT_SECRETS: encrypted

Bảo mật mạng:

• Deploy Lambda trong VPC khi cần truy cập private resources
• Sử dụng Security Groups để kiểm soát network access
• Thực hiện proper logging và monitoring

5.3. Chiến lược tối ưu chi phí

💡 S3 Intelligent Tiering:

# Tự động di chuyển objects giữa các access tiers
S3 Intelligent-Tiering:
- Frequent access: S3 Standard
- Infrequent access (30 days): S3 Standard-IA  
- Archive access (90 days): S3 Glacier
- Deep archive (180 days): S3 Glacier Deep Archive

# Tiết kiệm 40-60% chi phí tự động

📊 Tối ưu chi phí Lambda:

# Right-sizing memory allocation
128MB: $0.0000000021 per 100ms
1024MB: $0.0000001667 per 100ms (8x memory, 8x cost)

# Nhưng thời gian thực thi có thể nhanh 3x
128MB: 1000ms execution = $0.000021
1024MB: 300ms execution = $0.00005  
→ 1024MB actually rẻ hơn trong nhiều trường hợp!

Tối ưu CloudFront:

• Chọn Price Class phù hợp cho target audience
• Tối ưu cache behaviors cho different content types
• Sử dụng compression để giảm data transfer costs
• Monitor usage patterns và điều chỉnh accordingly

Kết luận

Trong bài viết thứ tư của series "DevOps On AWS", chúng ta đã khám phá bộ ba services cốt lõi cho hầu hết mọi ứng dụng hiện đại:

🗄️ S3 - Giải pháp lưu trữ toàn năng:

• Hiểu rõ khi nào dùng S3 vs EBS - static content vs application data
• Tối ưu Storage classes từ Standard đến Glacier Deep Archive
• Ví dụ thực tế từ static websites đến enterprise log storage

🌐 CloudFront - CDN toàn cầu:

• Tại sao cần CDN và cách CloudFront cải thiện user experience
• So sánh CloudFront vs Cloudflare với pros/cons thực tế
• Chiến lược tối ưu cho different content types

⚡ Lambda - Cuộc cách mạng Serverless:

• Khi nào dùng serverless vs traditional server approaches
• Lambda limitations và giải pháp (15-minute timeout, cold starts, etc.)
• Async patterns để xử lý long-running tasks
• Auto scaling và performance tuning techniques

🎬 Case Study toàn diện: Video processing platform kết hợp cả 3 services, từ upload → processing → delivery với phân tích chi phí chi tiết.

💡 Key Takeaways:

• S3 + CloudFront + Lambda = Nền tảng cho hầu hết AWS applications
• Tối ưu chi phí có thể tiết kiệm 60-80% khi thực hiện đúng cách
• Serverless patterns lý tưởng cho bursty/unpredictable workloads
• Bảo mật và monitoring cực kỳ quan trọng trong môi trường production

Bộ ba này sẽ xuất hiện trong hầu hết AWS projects mà bạn gặp phải. Master được chúng là nền tảng vững chắc cho hành trình AWS DevOps!

---

Xem thêm bài viết của tôi tại: codeeasy.blog

Tags: #AWS #DevOps #S3 #CloudFront #Lambda #Serverless #CDN #Storage