+ Strong caveats on consistency and async processing.
- More cautious, but overly long for an unrequested scenario.
--- name: aws-cloud-expert description: | Designs and implements AWS cloud architectures with focus on Well-Architected Framework, cost optimization,
| Category | Development › Deploy & operations |
|---|---|
| Tags | AnalyzingReviewingDeveloperTable |
---
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 testedThis 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.
All three assume an unstated scenario instead of following the supplied framework. ChatGPT is most technically cautious; Gemini makes the riskiest unsupported claims.
+ Strong caveats on consistency and async processing.
- More cautious, but overly long for an unrequested scenario.
+ Clearly connects scaling, caching, and DB protection.
- Invents Black Friday, Seoul, budget, and current state.
+ Architecture layers and roadmap are easy to follow.
- Claims perfect capacity using invented scale and costs.
| Criterion | ChatGPT | Claude | Gemini | Leader |
|---|---|---|---|---|
| Instruction following | 2 | 2 | 1 | Tie |
| Accuracy | 6 | 4 | 3 | ChatGPT +50% |
| Specificity | 2 | 2 | 1 | Tie |
| Structure | 8 | 8 | 8 | Tie |
| Right length | 4 | 4 | 5 | Gemini +25% |
Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-24). This is an AI review, not a measurement.
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.
[Pasted material] 저희는 월 방문자 30만명 규모의 이커머스 서비스를 운영 중인데, 블랙프라이데이 시즌에 트래픽이 10배까지 튀어서 EC2가 자주 다운됩니다. 현재 ap-northeast-2 리전에서 t3.large 인스턴스 4대를 오토스케일링 없이 운영 중이고, RDS MySQL도 같이 쓰고 있어요. 예산은 월 500만원 이내로 맞춰야 하는데 아키텍처를 어떻게 개선하면 좋을까요?
현재 구조의 핵심 문제는 단일 계층 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: 이미지·정적 파일·로그
현재 t3.large 4대를 고정 운영하지 말고 다음처럼 구성하는 것이 우선입니다.
ALB RequestCountPerTarget, 응답시간, 메모리 기준으로 확장다만 t3 계열은 CPU 크레딧이 소진되면 성능이 급격히 떨어질 수 있습니다. 지속적인 웹 트래픽이라면 다음을 우선 검토하세요.
m7i.large 또는 m6i.large: 안정적인 범용 처리c7i.large 또는 c6i.large: CPU 중심 애플리케이션t4g 또는 m7g 검토애플리케이션이 x86 전용이 아니라면 Graviton 인스턴스가 비용 대비 성능이 좋을 수 있습니다.
블랙프라이데이 당일에만 Auto Scaling에 의존하면 확장 지연이 발생할 수 있습니다.
권장 방식은 다음과 같습니다.
예를 들어 평상시 4대라면 행사 전 8대로 올리고, 요청량 증가 시 최대 16대까지 확장하는 방식입니다.
상품 이미지, CSS, JavaScript, 동영상, 다운로드 파일은 EC2가 직접 제공하지 않게 해야 합니다.
/static/*, /images/*는 긴 TTL 적용이렇게 하면 블랙프라이데이 트래픽 증가분 상당 부분을 EC2에서 제거할 수 있습니다. 상품 상세 페이지 중 캐시 가능한 영역도 CloudFront 또는 애플리케이션 캐시를 적용할 수 있습니다.
RDS가 병목이 되면 EC2를 늘려도 해결되지 않습니다.
권장 구성:
db.m6g.large 또는 db.r6g.large부터 부하 테스트주의할 점은 Read Replica가 주문·재고 처리의 강한 일관성을 보장하지 않는다는 것입니다. 다음 요청은 반드시 Writer에서 처리하는 편이 안전합니다.
상품 목록, 검색 결과, 리뷰처럼 약간의 지연을 허용할 수 있는 읽기 요청은 Replica나 Redis로 보낼 수 있습니다.
ElastiCache Redis를 다음 용도로 사용하세요.
단, Redis만으로 재고를 관리하면 장애 시 문제가 생길 수 있으므로 최종 재고 차감 결과는 MySQL 트랜잭션으로 확정해야 합니다.
주문 완료 후 수행하는 작업을 동기 처리하면 요청 시간이 길어지고 EC2가 쉽게 포화됩니다.
다음 작업은 SQS와 워커로 분리하는 것을 권장합니다.
구조는 다음과 같습니다.
주문 API
↓
MySQL에 주문·결제 상태 기록
↓
SQS
↓
EC2 워커 또는 ECS/Fargate
↓
알림·배송·포인트 처리
결제 승인 자체는 외부 결제사 응답을 확인한 뒤 짧고 명확하게 처리하고, 후속 작업만 비동기화해야 합니다.
월 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 비용보다 CloudFront와 NAT 비용이 더 커질 수 있으므로 반드시 별도로 측정해야 합니다.
부하 테스트에서는 단순히 동시 접속자 수만 보지 말고 다음을 측정해야 합니다.
가장 먼저 해야 할 일은 t3.large 4대를 그대로 늘리는 것이 아니라, ALB와 Auto Scaling으로 무중단 확장 구조를 만든 뒤 RDS 병목과 캐시 효과를 부하 테스트로 확인하는 것입니다.