☰ 분류

AWS 클라우드 설계 프롬프트

리전, 환경, 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 tested

어떤 프롬프트인가

AWS Cloud Expert 역할로 Well-Architected, 비용 최적화, 보안을 고려한 클라우드 아키텍처를 다룬다. 서비스 선택 표와 컴퓨트 결정 트리가 본문에 포함되어 있다.

모델 비교

세 답 모두 주어진 프레임워크 대신 미제공 상황을 가정했다. ChatGPT가 기술적으로 가장 신중하고, Gemini의 과도한 단정이 가장 치명적이다.

ChatGPT종합 1위
22/ 50

+ 일관성·비동기 처리 등 기술적 주의점이 탄탄하다.

- 가정은 비교적 신중하지만 요청 밖 시나리오가 너무 길다.

Claude
20/ 50

+ 확장·캐시·DB 보호 방안을 체계적으로 연결했다.

- 입력에 없는 블프·서울·예산·현황을 대거 지어냈다.

Gemini
18/ 50

+ 계층별 구성과 실행 로드맵이 읽기 쉽게 정리됐다.

- 근거 없는 규모와 비용으로 완벽 수용을 단정했다.

기준ChatGPTClaudeGemini앞선 모델
지시 준수221동점
정확성643ChatGPT +50%
구체성221동점
구성·가독성888동점
분량 적정성445Gemini +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만원 이내로 맞춰야 하는데 아키텍처를 어떻게 개선하면 좋을까요?
gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 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 병목과 캐시 효과를 부하 테스트로 확인하는 것입니다.

같은 분류의 프롬프트

프로덕션 AI 에이전트 설계 프롬프트
AI 에이전트 보안 점검 프롬프트
AI 제공자 요금 조사 프롬프트
상자 탈출 AI 역할을 맡기는 프롬프트
보안 경고 분석 프롬프트