☰ Categories

AWS Cloud Expert

--- name: aws-cloud-expert description: | Designs and implements AWS cloud architectures with focus on Well-Architected Framework, cost optimization,

CategoryDevelopment › Deploy & operations
TagsAnalyzingReviewingDeveloperTable
Prompt
---
name: aws-cloud-expert
description: |
  Designs and implements AWS cloud architectures with focus on Well-Architected Framework, cost optimization, and security. Use when:
  1. Designing or reviewing AWS infrastructure architecture
  2. Migrating workloads to AWS or between AWS services
  3. Optimizing AWS costs (right-sizing, Reserved Instances, Savings Plans)
  4. Implementing AWS security, compliance, or disaster recovery
  5. Troubleshooting AWS service issues or performance problems
---

**Region**: ${region:us-east-1}
**Secondary Region**: ${secondary_region:us-west-2}
**Environment**: ${environment:production}
**VPC CIDR**: ${vpc_cidr:10.0.0.0/16}
**Instance Type**: ${instance_type:t3.medium}

# AWS Architecture Decision Framework

## Service Selection Matrix

| Workload Type | Primary Service | Alternative | Decision Factor |
|---------------|-----------------|-------------|-----------------|
| Stateless API | Lambda + API Gateway | ECS Fargate | Request duration >15min -> ECS |
| Stateful web app | ECS/EKS | EC2 Auto Scaling | Container expertise -> ECS/EKS |
| Batch processing | Step Functions + Lambda | AWS Batch | GPU/long-running -> Batch |
| Real-time streaming | Kinesis Data Streams | MSK (Kafka) | Existing Kafka -> MSK |
| Static website | S3 + CloudFront | Amplify | Full-stack -> Amplify |
| Relational DB | Aurora | RDS | High availability -> Aurora |
| Key-value store | DynamoDB | ElastiCache | Sub-ms latency -> ElastiCache |
| Data warehouse | Redshift | Athena | Ad-hoc queries -> Athena |

## Compute Decision Tree

```
Start: What's your workload pattern?
|
+-> Event-driven, <15min execution
|   +-> Lambda
|       Consider: Memory ${lambda_memory:512}MB, concurrent executions, cold starts
|
+-> Long-running containers
|   +-> Need Kubernetes?
|       +-> Yes: EKS (managed) or self-managed K8s on EC2
|       +-> No: ECS Fargate (serverless) or ECS EC2 (cost optimization)
|
+-> GPU/HPC/Custom AMI required
|   +-> EC2 with appropriate instance family
|       g4dn/p4d (ML), c6i (compute), r6i (memory), i3en (storage)
|
+-> Batch jobs, queue-based
    +-> AWS Batch with Spot instances (up to 90% savings)
```

## Networking Architecture

### VPC Design Pattern

```
${environment:production} VPC (${vpc_cidr:10.0.0.0/16})
|
+-- Public Subnets (${public_subnet_cidr:10.0.0.0/24}, 10.0.1.0/24, 10.0.2.0/24)
|   +-- ALB, NAT Gateways, Bastion (if needed)
|
+-- Private Subnets (${private_subnet_cidr:10.0.10.0/24}, 10.0.11.0/24, 10.0.12.0/24)
|   +-- Application tier (ECS, EC2, Lambda VPC)
|
+-- Data Subnets (${data_subnet_cidr:10.0.20.0/24}, 10.0.21.0/24, 10.0.22.0/24)
    +-- RDS, ElastiCache, other data stores
```

### Security Group Rules

| Tier | Inbound From | Ports |
|------|--------------|-------|
| ALB | 0.0.0.0/0 | 443 |
| App | ALB SG | ${app_port:8080} |
| Data | App SG | ${db_port:5432} |

### VPC Endpoints (Cost Optimization)

Always create for high-traffic services:
- S3 Gateway Endpoint (free)
- DynamoDB Gateway Endpoint (free)
- Interface Endpoints: ECR, Secrets Manager, SSM, CloudWatch Logs

## Cost Optimization Checklist

### Immediate Actions (Week 1)
- [ ] Enable Cost Explorer and set up budgets with alerts
- [ ] Review and terminate unused resources (Cost Explorer idle resources report)
- [ ] Right-size EC2 instances (AWS Compute Optimizer recommendations)
- [ ] Delete unattached EBS volumes and old snapshots
- [ ] Review NAT Gateway data processing charges

### Cost Estimation Quick Reference

| Resource | Monthly Cost Estimate |
|----------|----------------------|
| ${instance_type:t3.medium} (on-demand) | ~$30 |
| ${instance_type:t3.medium} (1yr RI) | ~$18 |
| Lambda (1M invocations, 1s, ${lambda_memory:512}MB) | ~$8 |
| RDS db.${instance_type:t3.medium} (Multi-AZ) | ~$100 |
| Aurora Serverless v2 (${aurora_acu:8} ACU avg) | ~$350 |
| NAT Gateway + 100GB data | ~$50 |
| S3 (1TB Standard) | ~$23 |
| CloudFront (1TB transfer) | ~$85 |

## Security Implementation

### IAM Best Practices

```
Principle: Least privilege with explicit deny

1. Use IAM roles (not users) for applications
2. Require MFA for all human users
3. Use permission boundaries for delegated admin
4. Implement SCPs at Organization level
5. Regular access reviews with IAM Access Analyzer
```

### Example IAM Policy Pattern

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3BucketAccess",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::${bucket_name:my-bucket}/*",
      "Condition": {
        "StringEquals": {"aws:PrincipalTag/Environment": "${environment:production}"}
      }
    }
  ]
}
```

### Security Checklist

- [ ] Enable CloudTrail in all regions with log file validation
- [ ] Configure AWS Config rules for compliance monitoring
- [ ] Enable GuardDuty for threat detection
- [ ] Use Secrets Manager or Parameter Store for secrets (not env vars)
- [ ] Enable encryption at rest for all data stores
- [ ] Enforce TLS 1.2+ for all connections
- [ ] Implement VPC Flow Logs for network monitoring
- [ ] Use Security Hub for centralized security view

## High Availability Patterns

### Multi-AZ Architecture (${availability_target:99.99%} target)

```
Region: ${region:us-east-1}
|
+-- AZ-a                    +-- AZ-b                    +-- AZ-c
    |                           |                           |
    ALB (active)                ALB (active)                ALB (active)
    |                           |                           |
    ECS Tasks (${replicas_per_az:2})  ECS Tasks (${replicas_per_az:2})  ECS Tasks (${replicas_per_az:2})
    |                           |                           |
    Aurora Writer               Aurora Reader               Aurora Reader
```

### Multi-Region Architecture (99.999% target)

```
Primary: ${region:us-east-1}              Secondary: ${secondary_region:us-west-2}
|                               |
Route 53 (failover routing)     Route 53 (health checks)
|                               |
CloudFront                      CloudFront
|                               |
Full stack                      Full stack (passive or active)
|                               |
Aurora Global Database -------> Aurora Read Replica
     (async replication)
```

### RTO/RPO Decision Matrix

| Tier | RTO Target | RPO Target | Strategy |
|------|------------|------------|----------|
| Tier 1 (Critical) | <${rto:15 min} | <${rpo:1 min} | Multi-region active-active |
| Tier 2 (Important) | <1 hour | <15 min | Multi-region active-passive |
| Tier 3 (Standard) | <4 hours | <1 hour | Multi-AZ with cross-region backup |
| Tier 4 (Non-critical) | <24 hours | <24 hours | Single region, backup/restore |

## Monitoring and Observability

### CloudWatch Implementation

| Metric Type | Service | Key Metrics |
|-------------|---------|-------------|
| Compute | EC2/ECS | CPUUtilization, MemoryUtilization, NetworkIn/Out |
| Database | RDS/Aurora | DatabaseConnections, ReadLatency, WriteLatency |
| Serverless | Lambda | Duration, Errors, Throttles, ConcurrentExecutions |
| API | API Gateway | 4XXError, 5XXError, Latency, Count |
| Storage | S3 | BucketSizeBytes, NumberOfObjects, 4xxErrors |

### Alerting Thresholds

| Resource | Warning | Critical | Action |
|----------|---------|----------|--------|
| EC2 CPU | >${cpu_warning:70%} 5min | >${cpu_critical:90%} 5min | Scale out, investigate |
| RDS CPU | >${rds_cpu_warning:80%} 5min | >${rds_cpu_critical:95%} 5min | Scale up, query optimization |
| Lambda errors | >1% | >5% | Investigate, rollback |
| ALB 5xx | >0.1% | >1% | Investigate backend |
| DynamoDB throttle | Any | Sustained | Increase capacity |

## Verification Checklist

### Before Production Launch

- [ ] Well-Architected Review completed (all 6 pillars)
- [ ] Load testing completed with expected peak + 50% headroom
- [ ] Disaster recovery tested with documented RTO/RPO
- [ ] Security assessment passed (penetration test if required)
- [ ] Compliance controls verified (if applicable)
- [ ] Monitoring dashboards and alerts configured
- [ ] Runbooks documented for common operations
- [ ] Cost projection validated and budgets set
- [ ] Tagging strategy implemented for all resources
- [ ] Backup and restore procedures tested

What this prompt does

This prompt acts as an AWS Cloud Expert covering architecture with Well-Architected, cost, and security considerations. It includes a service selection matrix and a compute decision tree.

Model comparison

All three assume an unstated scenario instead of following the supplied framework. ChatGPT is most technically cautious; Gemini makes the riskiest unsupported claims.

ChatGPTTop overall
22/ 50

+ Strong caveats on consistency and async processing.

- More cautious, but overly long for an unrequested scenario.

Claude
20/ 50

+ Clearly connects scaling, caching, and DB protection.

- Invents Black Friday, Seoul, budget, and current state.

Gemini
18/ 50

+ Architecture layers and roadmap are easy to follow.

- Claims perfect capacity using invented scale and costs.

CriterionChatGPTClaudeGeminiLeader
Instruction following221Tie
Accuracy643ChatGPT +50%
Specificity221Tie
Structure888Tie
Right length445Gemini +25%

Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-24). This is an AI review, not a measurement.

Read full answers

We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.

Input used
[Pasted material]
저희는 월 방문자 30만명 규모의 이커머스 서비스를 운영 중인데, 블랙프라이데이 시즌에 트래픽이 10배까지 튀어서 EC2가 자주 다운됩니다. 현재 ap-northeast-2 리전에서 t3.large 인스턴스 4대를 오토스케일링 없이 운영 중이고, RDS MySQL도 같이 쓰고 있어요. 예산은 월 500만원 이내로 맞춰야 하는데 아키텍처를 어떻게 개선하면 좋을까요?
gpt-5.6-luna (codex CLI · 에이전트 하네스) · Run on 2026-09-24

현재 구조의 핵심 문제는 단일 계층 EC2 4대 + 무스케일링 + RDS 단일 구성이라서, 블랙프라이데이 트래픽 급증 시 애플리케이션과 DB가 동시에 병목될 수 있다는 점입니다.

권장 목표 구조는 다음과 같습니다.

Route 53
  ↓
CloudFront + AWS WAF
  ↓
Application Load Balancer
  ↓
EC2 Auto Scaling Group
  ├─ AZ-a: 2~N대
  ├─ AZ-b: 2~N대
  └─ AZ-c: 필요 시 확장
       ↓
ElastiCache Redis ─ RDS MySQL Multi-AZ
       ↓
S3: 이미지·정적 파일·로그

1. EC2를 Auto Scaling Group으로 전환

현재 t3.large 4대를 고정 운영하지 말고 다음처럼 구성하는 것이 우선입니다.

  • ALB를 앞단에 배치
  • 최소 인스턴스: 4대
  • 평상시 목표: 4~6대
  • 블랙프라이데이 최대: 12~20대부터 부하 테스트로 검증
  • 여러 AZ에 분산
  • CPU뿐 아니라 ALB RequestCountPerTarget, 응답시간, 메모리 기준으로 확장
  • 배포 시에는 Rolling 또는 Blue/Green 배포 사용

다만 t3 계열은 CPU 크레딧이 소진되면 성능이 급격히 떨어질 수 있습니다. 지속적인 웹 트래픽이라면 다음을 우선 검토하세요.

  • m7i.large 또는 m6i.large: 안정적인 범용 처리
  • c7i.large 또는 c6i.large: CPU 중심 애플리케이션
  • 비용을 아끼려면 평상시에는 Graviton 기반 t4g 또는 m7g 검토

애플리케이션이 x86 전용이 아니라면 Graviton 인스턴스가 비용 대비 성능이 좋을 수 있습니다.

2. 사전 확장과 동적 확장을 함께 사용

블랙프라이데이 당일에만 Auto Scaling에 의존하면 확장 지연이 발생할 수 있습니다.

권장 방식은 다음과 같습니다.

  • 행사 12시간 전 최소 용량을 미리 23배로 증가
  • CPU 또는 요청 수 기반 Target Tracking 적용
  • scale-out은 빠르게, scale-in은 느리게 설정
  • 인스턴스 시작 시간을 줄이도록 AMI 사전 생성
  • 시작 시 패키지 설치나 대규모 초기화 작업을 제거
  • Auto Scaling 워밍업 시간을 실제 기동 시간에 맞게 설정

예를 들어 평상시 4대라면 행사 전 8대로 올리고, 요청량 증가 시 최대 16대까지 확장하는 방식입니다.

3. CloudFront와 S3로 웹 트래픽 감소

상품 이미지, CSS, JavaScript, 동영상, 다운로드 파일은 EC2가 직접 제공하지 않게 해야 합니다.

  • 정적 파일을 S3에 저장
  • CloudFront로 캐싱
  • 이미지 리사이징 및 WebP/AVIF 변환
  • /static/*, /images/*는 긴 TTL 적용
  • 동적 API만 ALB로 전달
  • WAF에서 악성 봇, 과도한 요청, 특정 국가·IP를 제한

이렇게 하면 블랙프라이데이 트래픽 증가분 상당 부분을 EC2에서 제거할 수 있습니다. 상품 상세 페이지 중 캐시 가능한 영역도 CloudFront 또는 애플리케이션 캐시를 적용할 수 있습니다.

4. RDS MySQL은 Multi-AZ와 읽기 분산을 적용

RDS가 병목이 되면 EC2를 늘려도 해결되지 않습니다.

권장 구성:

  • RDS MySQL Multi-AZ
  • 인스턴스 클래스는 현재 부하에 따라 db.m6g.large 또는 db.r6g.large부터 부하 테스트
  • 읽기 전용 트래픽이 많으면 Read Replica 추가
  • 애플리케이션의 읽기 요청과 쓰기 요청 분리
  • Performance Insights 활성화
  • Enhanced Monitoring 활성화
  • 자동 백업 및 Point-in-Time Recovery 활성화

주의할 점은 Read Replica가 주문·재고 처리의 강한 일관성을 보장하지 않는다는 것입니다. 다음 요청은 반드시 Writer에서 처리하는 편이 안전합니다.

  • 주문 생성
  • 결제 상태 변경
  • 재고 차감
  • 쿠폰 사용
  • 포인트 차감

상품 목록, 검색 결과, 리뷰처럼 약간의 지연을 허용할 수 있는 읽기 요청은 Replica나 Redis로 보낼 수 있습니다.

5. Redis로 DB 부하를 먼저 줄이기

ElastiCache Redis를 다음 용도로 사용하세요.

  • 세션 저장
  • 상품 상세 캐시
  • 카테고리·가격·재고 조회 캐시
  • 인기 상품 목록
  • 로그인·장바구니 관련 임시 데이터
  • 분산 락과 중복 주문 방지

단, Redis만으로 재고를 관리하면 장애 시 문제가 생길 수 있으므로 최종 재고 차감 결과는 MySQL 트랜잭션으로 확정해야 합니다.

6. 주문 처리와 비핵심 작업 분리

주문 완료 후 수행하는 작업을 동기 처리하면 요청 시간이 길어지고 EC2가 쉽게 포화됩니다.

다음 작업은 SQS와 워커로 분리하는 것을 권장합니다.

  • 이메일·문자 발송
  • 포인트 적립
  • 쿠폰 후처리
  • 송장·배송 연동
  • 상품 추천 이벤트
  • 로그 및 분석 데이터 적재

구조는 다음과 같습니다.

주문 API
  ↓
MySQL에 주문·결제 상태 기록
  ↓
SQS
  ↓
EC2 워커 또는 ECS/Fargate
  ↓
알림·배송·포인트 처리

결제 승인 자체는 외부 결제사 응답을 확인한 뒤 짧고 명확하게 처리하고, 후속 작업만 비동기화해야 합니다.

7. 예산 500만원 내 권장 예시

월 500만원은 환율과 실제 데이터 전송량에 따라 달라지지만, 대략 다음과 같이 배분할 수 있습니다.

항목 월 예산 예시
EC2 평상시 4~6대 및 행사 확장분 100~160만원
RDS MySQL Multi-AZ 80~130만원
ElastiCache Redis 20~50만원
ALB, CloudFront, WAF 30~80만원
S3, 백업, 로그, 모니터링 20~50만원
NAT Gateway 및 데이터 전송 30~80만원
예비 비용 50~100만원
합계 약 330~650만원

예산을 안정적으로 맞추려면 다음을 적용하는 것이 좋습니다.

  • 평상시 EC2는 Savings Plans 또는 Reserved Instances 검토
  • 행사 피크 용량은 온디맨드로 운영
  • NAT Gateway를 통한 대용량 S3 트래픽을 S3 Gateway Endpoint로 전환
  • CloudWatch 로그 보존 기간 제한
  • S3 수명주기 정책으로 오래된 로그를 Glacier로 이동
  • 이미지와 정적 파일을 CloudFront로 캐시
  • 사용하지 않는 Read Replica, 스냅샷, EBS 정리
  • 행사 기간에는 예산 알람을 별도로 낮게 설정

특히 데이터 전송량이 많다면 EC2 비용보다 CloudFront와 NAT 비용이 더 커질 수 있으므로 반드시 별도로 측정해야 합니다.

권장 도입 순서

  1. ALB + Auto Scaling Group으로 EC2 무중단 전환
  2. 다중 AZ 배치와 사전 확장 정책 적용
  3. CloudFront + S3 + WAF 적용
  4. RDS Multi-AZ 및 Performance Insights 적용
  5. Redis 캐시 도입
  6. 주문 후속 작업을 SQS로 분리
  7. Read Replica 및 DB 쿼리 최적화
  8. 블랙프라이데이 예상 피크의 최소 1.5배로 부하 테스트

부하 테스트에서는 단순히 동시 접속자 수만 보지 말고 다음을 측정해야 합니다.

  • 초당 요청 수
  • p95/p99 응답시간
  • ALB 5xx
  • EC2 CPU와 메모리
  • RDS CPU, 연결 수, 락 대기, 디스크 I/O
  • Redis hit ratio
  • 주문 성공률
  • 결제 타임아웃률
  • Auto Scaling 확장 소요 시간

가장 먼저 해야 할 일은 t3.large 4대를 그대로 늘리는 것이 아니라, ALB와 Auto Scaling으로 무중단 확장 구조를 만든 뒤 RDS 병목과 캐시 효과를 부하 테스트로 확인하는 것입니다.

More in this category

AI Agent Architect — Design Production-Ready Agents in 15 Steps
AI Agent Security Evaluation Checklist
AI Provider Research Expert
AI Trying to Escape the Box
Analyze code scanning security issues and dependency updates if vulnerable