+ 일관성·비동기 처리 등 기술적 주의점이 탄탄하다.
- 가정은 비교적 신중하지만 요청 밖 시나리오가 너무 길다.
리전, 환경, VPC, 인스턴스 조건을 넣으면 AWS 서비스 선택, 컴퓨트 판단, 네트워크 아키텍처 방향을 정리합니다.
| 분류 | 개발 › 배포·운영 |
|---|---|
| 태그 | 분석검토개발자표 |
---
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 testedAWS Cloud Expert 역할로 Well-Architected, 비용 최적화, 보안을 고려한 클라우드 아키텍처를 다룬다. 서비스 선택 표와 컴퓨트 결정 트리가 본문에 포함되어 있다.
세 답 모두 주어진 프레임워크 대신 미제공 상황을 가정했다. ChatGPT가 기술적으로 가장 신중하고, Gemini의 과도한 단정이 가장 치명적이다.
+ 일관성·비동기 처리 등 기술적 주의점이 탄탄하다.
- 가정은 비교적 신중하지만 요청 밖 시나리오가 너무 길다.
+ 확장·캐시·DB 보호 방안을 체계적으로 연결했다.
- 입력에 없는 블프·서울·예산·현황을 대거 지어냈다.
+ 계층별 구성과 실행 로드맵이 읽기 쉽게 정리됐다.
- 근거 없는 규모와 비용으로 완벽 수용을 단정했다.
| 기준 | ChatGPT | Claude | Gemini | 앞선 모델 |
|---|---|---|---|---|
| 지시 준수 | 2 | 2 | 1 | 동점 |
| 정확성 | 6 | 4 | 3 | ChatGPT +50% |
| 구체성 | 2 | 2 | 1 | 동점 |
| 구성·가독성 | 8 | 8 | 8 | 동점 |
| 분량 적정성 | 4 | 4 | 5 | Gemini +25% |
gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-24). 측정값이 아니라 AI 심사 결과입니다.
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
[붙여 넣은 자료] 저희는 월 방문자 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 병목과 캐시 효과를 부하 테스트로 확인하는 것입니다.
| 프로덕션 AI 에이전트 설계 프롬프트 | |
| AI 에이전트 보안 점검 프롬프트 | |
| AI 제공자 요금 조사 프롬프트 | |
| 상자 탈출 AI 역할을 맡기는 프롬프트 | |
| 보안 경고 분석 프롬프트 |