to-be-architecture

name	to-be-architecture
description	Design the target AWS architecture — ECS Fargate / EKS / Serverless choice, VPC topology with public-private-isolated subnets, managed database selection (RDS/Aurora/DynamoDB), IAM boundaries, and observability baseline (CloudWatch, X-Ray, Langfuse). Produces to-be-architecture.md with Mermaid diagram and compliance matrix. Use after modernization-strategy is approved.
argument-hint	[strategy-decision-path, target-compute (ecs|eks|serverless)]
user-invocable	true
model	claude-opus-4-7
allowed-tools	Read,Write,Edit,Grep,Glob,Bash,WebFetch,mcp__aws-documentation,mcp__aws-iac,mcp__aws-pricing,mcp__ecs,mcp__eks

언제 사용하나요

• strategy-decision.md 가 존재하고 decided_pattern 이 Rehost/Replatform/Refactor 중 하나일 때
• Container Orchestration 선택(ECS vs EKS) 과 VPC 토폴로지를 확정해야 할 때
• 매니지드 DB(RDS/Aurora/DynamoDB) 와 저장소(S3) 의 용량·성능·암호화 정책을 설계할 때
• 관측성(CloudWatch/X-Ray/Langfuse) 과 보안 통제(WAF/Shield/GuardDuty) baseline 을 정의할 때

언제 사용하지 않나요

• decided_pattern == Retire | Retain — 신규 아키텍처 설계 불필요
• decided_pattern == Repurchase — SaaS 도입이므로 AWS 상세 아키텍처 미해당
• 기존 To-Be 설계가 이미 존재하고 변경 사항이 없을 때

전제 조건

• .omao/plans/modernization/strategy-decision.md 존재 및 사용자 승인 완료
• AWS Organization·Account 설계(단일 vs Multi-Account)가 결정됨
• 대상 region 및 AZ 수(최소 2개) 확정

절차

Step 1. Compute Orchestration 선택

aws-samples container-orchestration-selection.md 기준으로 평가합니다.

조건	추천
팀 DevOps 성숙도 Low-Medium, 단순 Stateless 서비스	ECS Fargate
K8s 운영 경험 있음 + 복잡한 Pod 패턴 + Service Mesh	EKS
이벤트 기반 간헐 트래픽, 연간 1M 이하 요청	Lambda + API Gateway
GPU 추론 워크로드	EKS (GPU NodePool)

Step 2. VPC 토폴로지 설계

graph TB
  Internet((Internet)) --> ALB[ALB - Public Subnet]
  ALB --> AppTier[App Tier - Private Subnet]
  AppTier --> DB[(Aurora - Isolated Subnet)]
  AppTier --> S3[S3 via VPC Endpoint]
  AppTier --> Secrets[Secrets Manager]

• Public Subnet: ALB/NLB, NAT Gateway 전용
• Private Subnet: 애플리케이션 Task/Pod
• Isolated Subnet: Aurora, RDS, ElastiCache — NAT 없음, VPC Endpoint 만 허용
• 최소 2 AZ, CIDR /16, 서브넷 /20

Step 3. Managed Database 선택

워크로드 패턴	추천	근거
OLTP, 복잡한 JOIN	Aurora PostgreSQL	HA, serverless v2 옵션
단순 키-값, μs latency	DynamoDB	서버리스, 자동 스케일
기존 Oracle 호환성	RDS for Oracle 또는 Babelfish	마이그레이션 부담 최소
읽기 집약 + 캐시	ElastiCache Redis/Valkey	1ms 미만 응답

결정 시 기록 항목:

• 인스턴스 클래스(예: db.r6g.xlarge) 와 Multi-AZ 여부
• 저장 용량, IOPS 유형
• 암호화(KMS CMK), 백업 보존 기간
• 마이그레이션 도구(DMS, Schema Conversion Tool) 선택

Step 4. Observability Baseline

목적	도구
메트릭	CloudWatch Metrics + Prometheus (EKS 시)
로그	CloudWatch Logs + Fluent Bit
트레이싱	X-Ray (AWS native) 또는 OpenTelemetry → Langfuse (LLM 포함 시)
알람	CloudWatch Alarms + SNS → PagerDuty/Opsgenie
대시보드	CloudWatch Dashboards 또는 Grafana

LLM 추론 경로가 포함된 경우 Langfuse v3.x 를 OpenTelemetry 엔드포인트로 구성하여 trace 를 병렬 수집합니다.

Step 5. 보안 통제

• 네트워크: Security Group 0.0.0.0/0 인바운드 금지, ALB/NLB 내부 노출 시 Cognito/OIDC/mTLS
• IAM: Least privilege, IRSA (EKS) 또는 Task Role (ECS), 정적 Access Key 금지
• 데이터: KMS CMK, S3 Block Public Access, VPC Flow Logs 활성화
• 위협 탐지: GuardDuty, Security Hub, Config Rules
• WAF: OWASP Top 10 관리형 규칙 세트 적용

Step 6. Compliance Matrix

각 규제 항목에 대해 아키텍처 통제를 매핑합니다.

규제	요구사항	아키텍처 통제
ISMS-P	암호화 저장	KMS CMK (DB, S3, EBS)
전자금융감독규정	망분리	Isolated Subnet + VPC Endpoint
PCI-DSS	카드 정보 격리	Tokenization + 전용 VPC + WAF
SOC 2	감사 로그	CloudTrail + S3 (log archive account)

Step 7. Output 산출

.omao/plans/modernization/to-be-architecture.md 에 다음 섹션을 포함합니다.

# To-Be Architecture
- compute: ECS Fargate (2 AZ, service auto-scaling target 70% CPU)
- vpc: 10.0.0.0/16, subnets (public/private/isolated) × 2 AZ
- database: Aurora PostgreSQL 15 / r6g.xlarge / Multi-AZ / KMS CMK
- storage: S3 (versioning, SSE-KMS, Block Public Access)
- observability: CloudWatch + X-Ray + Langfuse (v3.x)
- security: WAF v2, GuardDuty, Security Hub, IRSA/Task Role
- compliance_matrix: (Step 6 표)
- mermaid_diagram: (Step 2 다이어그램)
- estimated_monthly_cost_usd: 12,400
- next_skill: containerization

Step 8. IaC 스케치 (선택)

mcp__aws-iac 를 사용하여 초기 CDK/Terraform 스케치를 생성합니다. 이는 Draft 이며, containerization skill 에서 확정됩니다.

좋은 예시

• ECS Fargate + Aurora PostgreSQL + CloudWatch + WAF — Replatform 표준 패턴
• EKS + Karpenter + Aurora Serverless v2 + OpenTelemetry — Refactor + 변동 트래픽 대응
• Lambda + API Gateway + DynamoDB — 이벤트 기반 서버리스 재설계

나쁜 예시 (금지)

• Public Subnet 에 Aurora 배치 — 망분리 원칙 위반
• 0.0.0.0/0 SG 인바운드 — 회사 정책 위반
• 단일 AZ 구성 — HA 요구사항 충족 불가
• KMS CMK 없이 SSE-S3 만 적용하면서 ISMS-P 대상이라고 주장
• Compliance Matrix 생략하고 아키텍처 결정

참고 자료

공식 문서

• AWS Well-Architected Framework — 5대 기둥
• Amazon ECS Developer Guide — ECS 공식 가이드
• Amazon EKS User Guide — EKS 공식 가이드
• AWS Prescriptive Guidance — VPC Design — VPC 보안 Best Practice

원천 방법론 (MIT-0)

• container-orchestration-selection.md (Kiro) — ECS vs EKS 의사결정

관련 문서 (내부)

• ../modernization-strategy/SKILL.md — 선행 skill
• ../containerization/SKILL.md — 후속 skill
• /home/ubuntu/workspace/oh-my-aidlcops/plugins/ai-infra/CLAUDE.md — LLM 경로가 포함된 아키텍처 연계