당신처럼 AWS + 컨테이너 + ISO SaaS를 설계하는 입장에서는 이걸 이해하면 보안 설계, 트래픽 제어, 감사지표 설계까지 연결됩니다.
전체 구조 한눈에 이해하기
상단 레이어 (외부 → 내부)
Internet
↓
IGW (Internet Gateway)
↓
LB (Load Balancer)
↓
Node
↓
Pod
이 구조는 AWS EKS 또는 EC2 기반 Kubernetes 클러스터를 의미합니다.
VPC 영역
그림의 큰 박스가 VPC입니다.
VPC 안에는:
• Node 1
• Node 2
각 Node는 EC2 인스턴스라고 보면 됩니다.
트래픽 흐름 분석
Ingress (외부 → 내부)
1. 사용자가 HTTPS 요청
2. IGW를 통해 VPC 진입
3. Load Balancer 도착
4. 특정 Node로 전달
5. Node 내부 iptables 규칙 적용
6. veth 인터페이스 통해 Pod로 전달
Pod-to-Pod 통신
Pod1 (10.0.1.2)
→ veth0
→ vbr0 (bridge)
→ iptables
→ 다른 Pod
Kubernetes는 기본적으로:
모든 Pod는 서로 직접 통신 가능
이게 보안상 위험할 수 있음
→ 그래서 NetworkPolicy가 필요
Egress (내부 → 외부)
Pod
→ veth
→ vbr0
→ iptables
→ Node eth0 (172.16.2.11)
→ IGW
→ Internet
네트워크 인터페이스 이해
Node 레벨
• eth0 → 실제 EC2 네트워크 인터페이스
• 172.16.x.x → VPC IP
Pod 레벨
• 10.0.x.x → Pod 내부 IP
• veth → 가상 이더넷
• vbr0 → 브리지
보안 관점에서 중요한 지점
당신이 ISO 27001, 42001 기반 SaaS를 만든다면
이 구조에서 반드시 설계해야 할 것은:
Security Group (Node 레벨)
• 443만 허용
• SSH 차단 또는 Bastion만 허용
NetworkPolicy (Pod 레벨)
예:
• DB Pod는 App Pod만 접근
• App Pod는 Internet 접근 제한
Ingress Controller
• Nginx / ALB Ingress
• TLS termination 위치 명확히
실제 운영에서의 핵심 차이
초보 설계
모든 Pod가 모든 Pod 접근 가능
DB도 외부 노출
→ 심사에서 바로 지적
전문가 설계
Public Subnet
- ALB
Private Subnet
- Worker Nodes
- DB
NetworkPolicy
- 최소 권한
이 구조를 TRUSTIA에 적용하면
당신이 AI 자동 심사 엔진을 컨테이너화 한다면:
Pod-A: API
Pod-B: Scoring Engine
Pod-C: Report Generator
Pod-D: AI Engine
Pod-E: DB Proxy
그리고 NetworkPolicy:
• API → Scoring 허용
• Scoring → DB 허용
• AI Engine → 외부 LLM 허용
• 외부 → DB 직접 접근 금지
EC2 vs Kubernetes 네트워킹 차이
항목 EC2 단일 Kubernetes
네트워크 단순성 높음 낮음
격리 수준 낮음 높음
확장성 중간 매우 높음
운영 난이도 낮음 높음
전략적 판단
TRUSTIA가:
• 글로벌 SaaS
• AI 엔진 분리
• 고객별 테넌트 격리
• ISO 감사 대응
이라면 Kubernetes 구조가 장기적으로 유리합니다.
하지만:
• MVP
• 팀 1~3명
• 빠른 반복
이면 EC2 + Docker가 더 현실적입니다.
핵심 한 줄 정리
이 그림은 말합니다:
Kubernetes는 “서버”가 아니라 “네트워크 OS”다.
— 이춘곤(Mark) · ISC.studio · ISC출판 도서 안내
이 글은 저자의 Facebook에 처음 게시한 글입니다. Facebook 원문 보기
💬 댓글 (0)