· Interview · 11 min read
AWS 면접 질문 25선 — Solutions Architect & DevOps Professional 관점
AWS 자격증 보유자가 정리한 실무 면접 질문. VPC, IAM, EKS, Lambda부터 비용 최적화, 보안, 고가용성 설계까지 핵심만 압축.
네트워크 & VPC
1. VPC 설계 시 고려사항은?
- CIDR 범위: 향후 확장을 고려한 충분한 IP 대역 (/16 ~ /20)
- 서브넷 분리: Public/Private/DB 서브넷 3-tier 구성
- AZ 분산: 최소 2개 AZ에 서브넷 배치로 고가용성
- NAT Gateway: Private 서브넷의 아웃바운드 인터넷 접근
2. Transit Gateway(TGW)의 역할과 장점은?
TGW는 여러 VPC와 온프레미스 네트워크를 중앙 허브로 연결합니다.
기존 VPC Peering 대비 장점:
- N:N 연결이 아닌 Hub-Spoke 구조로 관리 단순화
- Route Table 중앙 관리
- Multi-Account 환경에서 NTW Account를 통한 통합 관리
- 대역폭 확장성
3. Security Group과 NACL의 차이는?
| 구분 | Security Group | NACL |
|---|---|---|
| 레벨 | 인스턴스(ENI) | 서브넷 |
| 상태 | Stateful (응답 자동 허용) | Stateless (인/아웃 별도) |
| 규칙 | 허용만 가능 | 허용 + 거부 |
| 평가 | 모든 규칙 평가 | 번호 순서대로 평가 |
4. PrivateLink와 VPC Endpoint의 차이는?
- Gateway Endpoint: S3, DynamoDB 전용. 라우팅 테이블 기반. 무료.
- Interface Endpoint (PrivateLink): 대부분의 AWS 서비스. ENI 기반. 과금.
PrivateLink는 트래픽이 AWS 네트워크 내부에서만 이동하므로 보안과 지연시간에 유리합니다.
IAM & 보안
5. IAM Role과 User의 차이, 언제 무엇을 쓰나요?
- User: 장기 자격증명 (Access Key). 사람에게 부여. 가능하면 사용 자제.
- Role: 임시 자격증명 (STS). 서비스, EC2, Lambda, Cross-Account 접근에 사용.
Best Practice: EC2/EKS에는 항상 IAM Role(Instance Profile/IRSA) 사용. Access Key 하드코딩 금지.
6. IRSA(IAM Roles for Service Accounts)를 설명해주세요.
EKS Pod에 IAM Role을 부여하는 방식입니다.
- OIDC Provider를 EKS 클러스터에 연결
- IAM Role에 Trust Policy로 특정 ServiceAccount 연결
- Pod의 ServiceAccount에 Role ARN 어노테이션 추가
노드 레벨 권한 대비 Pod 레벨 최소 권한을 구현할 수 있습니다.
7. WAF, Shield, GuardDuty의 역할은?
- WAF: L7 방화벽. SQL Injection, XSS, Rate Limiting 등 웹 공격 방어.
- Shield: DDoS 방어. Standard(무료) + Advanced(유료, 24/7 대응팀).
- GuardDuty: 위협 탐지. VPC Flow Logs, CloudTrail, DNS 로그 분석으로 이상 행위 감지.
8. Network Firewall은 어떤 경우에 사용하나요?
VPC 레벨의 방화벽으로, 인바운드/아웃바운드 트래픽을 도메인/IP/프로토콜 기반으로 제어합니다.
사용 사례:
- 아웃바운드 트래픽 도메인 필터링 (허용된 외부 API만 접근)
- IDS/IPS 기능 (Suricata 규칙 기반)
- TGW와 연동하여 중앙 집중형 보안 정책 적용
컴퓨팅 & 컨테이너
9. EKS에서 Fargate와 EC2 노드 그룹의 차이는?
| 구분 | EC2 Node Group | Fargate |
|---|---|---|
| 관리 | 노드 패치/업그레이드 필요 | 서버리스, AWS 관리 |
| 비용 | EC2 + EKS 요금 | vCPU/메모리 사용량 과금 |
| DaemonSet | 지원 | 미지원 |
| GPU | 지원 | 미지원 |
| 스케일링 | Cluster Autoscaler/Karpenter | 자동 |
10. Lambda의 Cold Start 문제와 해결책은?
Cold Start: 새 실행 환경 생성 시 초기화 지연 (100ms ~ 수초)
해결책:
- Provisioned Concurrency: 미리 실행 환경 유지 (비용 증가)
- SnapStart (Java): 초기화된 스냅샷에서 복원
- 패키지 크기 최소화, 의존성 줄이기
- VPC 연결 시 ENI 생성 지연 → VPC Lambda 최소화
11. Spot Instance 활용 전략은?
- 다양한 인스턴스 타입 혼합: 한 타입이 회수되어도 다른 타입으로 대체
- Spot Fleet / Karpenter: 자동으로 최적 인스턴스 선택
- Interruption Handler: 2분 전 알림 수신 → Graceful 종료
- Stateless 워크로드에 적합: 배치 작업, CI/CD Runner, 개발 환경
데이터 & 스토리지
12. S3 스토리지 클래스 선택 기준은?
| 클래스 | 용도 | 비용 |
|---|---|---|
| Standard | 자주 접근 | 높음 |
| Intelligent-Tiering | 패턴 불확실 | 자동 전환 |
| Standard-IA | 30일+ 보관, 가끔 접근 | 중간 |
| Glacier Instant | 아카이브, 즉시 접근 | 낮음 |
| Glacier Deep Archive | 장기 보관 (7-10년) | 최저 |
Lifecycle Policy로 자동 전환 설정합니다.
13. RDS Multi-AZ와 Read Replica의 차이는?
- Multi-AZ: 고가용성 목적. 동기 복제. 장애 시 자동 Failover. 읽기 트래픽 분산 불가.
- Read Replica: 읽기 성능 확장. 비동기 복제. 수동 승격 가능. Cross-Region 가능.
CI/CD & DevOps
14. CodePipeline vs GitLab CI vs Jenkins 비교
| 구분 | CodePipeline | GitLab CI | Jenkins |
|---|---|---|---|
| 관리 | AWS 관리형 | SaaS/Self-hosted | Self-hosted |
| AWS 연동 | 네이티브 | 플러그인 | 플러그인 |
| 유연성 | 낮음 | 높음 | 매우 높음 |
| 유지보수 | 최소 | 중간 | 높음 |
15. ECR 이미지 보안 관리는?
- 이미지 스캔: ECR Basic Scanning 또는 Inspector 연동
- 이미지 서명: Sigstore/Cosign으로 무결성 검증
- Lifecycle Policy: 오래된 이미지 자동 삭제
- Immutable Tag: 태그 덮어쓰기 방지
모니터링 & Observability
16. CloudWatch Metrics vs Prometheus 선택 기준은?
- CloudWatch: AWS 네이티브 메트릭, 관리 불필요, 비용 과금
- Prometheus: 커스텀 메트릭 유연, PromQL 강력, Self-hosted 관리 필요
실무: CloudWatch Application Signals로 SLO/SLI 관리하고, Prometheus + Grafana로 상세 대시보드 구축하는 하이브리드 방식을 사용합니다.
17. X-Ray와 Application Signals의 차이는?
- X-Ray: 분산 트레이싱. 요청 경로 추적, 병목 구간 식별.
- Application Signals: SLO/SLI 기반 모니터링. 서비스 맵, 에러율, 지연시간 자동 계측.
Application Signals는 X-Ray 위에 구축된 상위 레벨 Observability 도구입니다.
고가용성 & DR
18. Multi-Region 아키텍처 설계 시 고려사항은?
- 데이터 동기화: DynamoDB Global Tables, Aurora Global Database, S3 Cross-Region Replication
- DNS 기반 Failover: Route53 Health Check + Failover Routing
- 상태 관리: 세션을 ElastiCache/DynamoDB에 외부화
- 배포 전략: Region별 순차 배포로 영향 최소화
19. RTO와 RPO를 설명하고, 전략별 차이는?
- RTO (Recovery Time Objective): 복구까지 허용 가능한 최대 시간
- RPO (Recovery Point Objective): 허용 가능한 최대 데이터 손실량
| 전략 | RTO | RPO | 비용 |
|---|---|---|---|
| Backup & Restore | 시간 | 시간 | 최저 |
| Pilot Light | 분 | 분 | 낮음 |
| Warm Standby | 초~분 | 초 | 중간 |
| Active-Active | 0 | 0 | 최고 |
비용 최적화 (FinOps)
20. Reserved Instance vs Savings Plan 차이는?
- RI: 특정 인스턴스 타입/리전에 약정. 유연성 낮음. 할인율 높음.
- Savings Plan: 시간당 사용량 약정. Compute SP는 인스턴스 타입/리전/OS 유연. 관리 용이.
21. FinOps 비용 절감 경험을 말해주세요.
- Right-Sizing: CloudWatch 메트릭 기반 인스턴스 스펙 조정
- Spot Instance: Stateless 워크로드에 적용 (60-90% 절감)
- Savings Plan: 안정적 워크로드에 1년/3년 약정
- S3 Lifecycle: 오래된 데이터 자동 Glacier 전환
- 주간 비용 모니터링: Cost Explorer + 이상 비용 알림 설정
서버리스 & 이벤트 기반
22. EventBridge의 용도와 아키텍처 패턴은?
EventBridge는 이벤트 기반 아키텍처의 중앙 버스입니다.
사용 사례:
- AWS 서비스 이벤트 → Lambda 트리거 (예: Glue Job 실패 → 알림)
- 스케줄 기반 작업 실행 (cron 대체)
- Cross-Account 이벤트 전달
- SaaS 이벤트 통합
23. Step Functions은 어떤 경우에 사용하나요?
복잡한 워크플로우를 시각적으로 오케스트레이션합니다.
- ETL 파이프라인: Glue → 검증 → S3 → 알림
- 분기/병렬/재시도 로직이 있는 비즈니스 프로세스
- 장시간 실행 작업 (최대 1년)
- Lambda 체이닝 대비 에러 핸들링/상태 관리 용이
데이터 파이프라인
24. Glue와 EMR의 차이, 선택 기준은?
- Glue: 서버리스 ETL. 관리 불필요. Spark 기반. 간단한 변환 작업에 적합.
- EMR: 관리형 Hadoop/Spark 클러스터. 세밀한 설정 가능. 대규모/복잡한 작업에 적합.
선택 기준:
- 간단한 ETL → Glue
- 커스텀 라이브러리/복잡한 ML → EMR
- 비용 예측성 → Glue (DPU 과금)
25. Airflow와 Step Functions 비교
| 구분 | Airflow (MWAA) | Step Functions |
|---|---|---|
| 유연성 | Python 코드로 DAG 정의 | JSON/ASL 기반 |
| 복잡한 의존성 | 강점 | 제한적 |
| AWS 통합 | SDK 호출 | 네이티브 (200+ 서비스) |
| 비용 | 항시 실행 환경 | 실행 건당 과금 |
| 모니터링 | Airflow UI | Step Functions 콘솔 |
실무에서는 복잡한 데이터 파이프라인은 Airflow, 단순 AWS 서비스 오케스트레이션은 Step Functions을 사용합니다.
