AWS DEA-C01 문제로 공부하기 — Day 03
IAM 역할 보안, 보안 그룹 트러블슈팅, Neptune 쿼리 언어, DynamoDB 고처리량, Glue 워크플로 병렬 처리까지 — 5문제 핵심 정리.
AWS 보안 모범 사례에서 Lambda·Glue가 RDS에 접근할 때는 IAM 역할 기반 임시 자격증명을 사용해야 합니다. 장기 액세스 키·하드코딩된 자격증명은 보안 위험이 높아 DEA-C01 보안 도메인에서 단골 오답 패턴으로 출제됩니다.
AWS Step Functions가 여러 Lambda 함수와 AWS Glue 작업을 조율하는 데이터 파이프라인이 있습니다. 이 Lambda 함수와 Glue 작업은 동일한 VPC에 위치한 여러 RDS 데이터베이스에 접근해야 하며, 네트워크 연결은 이미 구성되어 있습니다. 자격증명 보안을 가장 강화하는 방법은 무엇일까요?
- ARDS 접근 권한을 가진 IAM 역할을 생성하고, Lambda 및 Glue가 해당 역할을 수임(Assume)할 수 있는 별도 IAM 역할을 구성합니다.✅ IAM 역할 수임(Role Assumption) — 직원이 특정 업무용 출입증을 일시 빌리는 것. Lambda·Glue가 자신의 역할로 RDS 접근 역할을 임시로 수임해 단기 자격증명으로 접근. 장기 키 없이 동작하므로 가장 안전.
- BRDS 접근 권한이 있는 IAM 사용자를 만들고, 각 Lambda 함수와 Glue 작업에 이 사용자 자격증명을 할당합니다.❌ IAM 사용자(IAM User) — 장기 액세스 키를 발급받는 고정 신분증. Lambda·Glue에 IAM 사용자를 "할당"하는 개념 자체가 없고, 장기 키 노출 위험이 있음. IAM 역할을 써야 함.
- CAWS 계정 루트 사용자로 장기 액세스 키를 발급하여 Lambda 및 Glue 코드에 직접 포함하고, 분기마다 갱신합니다.❌ 루트 사용자(Root User) — AWS 계정의 최고 권한 마스터 키. 루트 키를 코드에 하드코딩하는 것은 AWS 보안의 최악의 패턴. 유출 시 계정 전체 탈취 가능.
- DJDBC 연결 문자열에 RDS 접속 정보(ID/PW)를 포함하여 Lambda 함수와 Glue 작업에서 직접 사용합니다.❌ 연결 문자열에 자격증명 하드코딩 — 소스 코드나 설정 파일에 ID/PW가 평문으로 노출됨. 코드 저장소에 커밋되는 순간 보안 사고. Secrets Manager나 IAM 역할로 대체해야 함.
| 방식 | 비유 | 자격증명 유형 | 보안 수준 |
|---|---|---|---|
| IAM 역할 수임 | 🏷️ 업무용 임시 출입증 | 단기 임시 자격증명 | ✓ 최고 |
| IAM 사용자 액세스 키 | 🔑 장기 고정 열쇠 | 장기 액세스 키 | 중간 |
| 코드 하드코딩 | 📄 평문 메모지 | 노출된 자격증명 | ✗ 위험 |
| 루트 사용자 키 | 💣 마스터 폭발물 | 계정 전체 권한 키 | ✗ 최악 |
Lambda · Glue 자격증명 → IAM 역할 (임시 자격증명, 자동 갱신)
루트 사용자 키 = 무조건 오답
코드 하드코딩 = 무조건 오답
IAM 역할 수임 = AWS 보안 모범 사례AWS 보안 그룹(Security Group)에서 같은 그룹 내 리소스끼리 통신하려면 보안 그룹 자체를 소스로 지정하는 인바운드 규칙이 필요합니다. DNS 이름은 소스로 사용할 수 없으며, 이 패턴이 DEA-C01 네트워킹 트러블슈팅 유형으로 출제됩니다.
VPC 프라이빗 서브넷에서 동일한 보안 그룹을 공유하는 AWS Glue 작업과 Amazon RDS 인스턴스가 있습니다. 보안 담당자가 이 보안 그룹의 규칙을 변경했고, 변경 후 특정 IP의 SSH 인바운드 트래픽만 허용하는 단일 규칙만 남았습니다. 그 결과 Glue 작업이 RDS에 연결하지 못하게 되었습니다. 연결을 복구하는 올바른 방법은 무엇일까요?
- A모든 UDP 포트에서의 TCP 트래픽을 허용하는 인바운드 규칙을 추가하고, RDS 인스턴스의 프라이빗 IP를 소스로 지정합니다.❌ UDP(User Datagram Protocol) — 비연결형 프로토콜. "UDP 포트에서 TCP 트래픽"은 논리적으로 모순된 표현. RDS(MySQL/PostgreSQL)는 TCP를 사용하며, 소스를 IP로 고정하면 탄력적이지 못함.
- B모든 TCP 포트의 TCP 트래픽을 허용하는 인바운드 규칙을 추가하고, 소스를 해당 보안 그룹 자체로 지정합니다.✅ 보안 그룹을 소스로 설정 — 아파트 동일 세대 열쇠를 소지한 사람만 출입 허용하는 것. Glue와 RDS가 같은 보안 그룹에 속하므로, 보안 그룹 자체를 소스로 지정하면 그룹 내 모든 리소스 간 통신이 허용됨. IP 변경에도 자동 대응.
- C모든 TCP 포트의 TCP 트래픽을 허용하는 인바운드 규칙을 추가하고, RDS 인스턴스의 DNS 이름을 소스로 지정합니다.❌ 보안 그룹 소스에는 IP 주소, CIDR 블록, 보안 그룹 ID만 지정 가능. DNS 이름은 소스로 사용 불가 — AWS 콘솔에서 아예 입력이 안 됨.
- D기존 SSH 규칙의 소스를 RDS IP로 바꾸고, 동일한 소스·대상·프로토콜로 아웃바운드 규칙을 추가합니다.❌ SSH(포트 22)를 수정해봤자 RDS 연결(MySQL 3306, PostgreSQL 5432 등)에는 아무 영향 없음. 포트 자체가 다름. 아웃바운드 규칙도 이 문제와 무관.
| 소스 유형 | 예시 | 사용 가능? | 동적 대응 |
|---|---|---|---|
| IP/CIDR | 10.0.1.5/32 | ✓ | IP 바뀌면 수동 수정 |
| 보안 그룹 ID | sg-0abc1234 | ✓ 권장 | 자동 대응 ✓ |
| DNS 이름 | rds.ap-northeast-2... | ✗ 불가 | - |
| UDP에서 TCP | 모순된 표현 | ✗ 불가 | - |
같은 보안 그룹 내 리소스 간 통신 → 보안 그룹 ID를 소스로 지정
소스에 DNS 이름 = 불가 (오답 패턴)
UDP에서 TCP = 논리 모순 (오답 패턴)Amazon Neptune은 AWS의 완전 관리형 그래프 데이터베이스입니다. Gremlin(Property Graph)과 SPARQL(RDF Graph) 두 가지 쿼리 언어를 지원하며, SQL 계열은 지원하지 않습니다.
개발팀이 Amazon Neptune 기반의 그래프 애플리케이션을 새로 구축하려 합니다. Neptune에서 그래프 데이터를 조회하고 탐색하기 위해 사용할 수 있는 쿼리 언어 두 가지는 무엇일까요?
- ASPARQL (스파클)✅ SPARQL(스파클 — SPARQL Protocol and RDF Query Language) — RDF(Resource Description Framework) 그래프용 쿼리 언어. 웹의 링크드 데이터를 표현하는 트리플(주어-서술어-목적어) 구조를 쿼리. Neptune의 RDF 엔진이 지원.
- BGremlin (그렘린)✅ Gremlin(그렘린) — Apache TinkerPop 프레임워크의 그래프 순회(Traversal) 언어. SNS 친구 추천·사기 탐지처럼 노드와 엣지로 연결된 Property Graph를 탐색. Neptune의 Property Graph 엔진이 지원.
- CSQL❌ SQL(Structured Query Language) — 관계형 DB(테이블) 전용 쿼리 언어. Neptune은 그래프 DB라 SQL을 지원하지 않음. RDS·Redshift·Aurora 등에서 사용.
- DANSI SQL❌ ANSI SQL — 미국 표준 협회(ANSI)가 정의한 표준 SQL. SQL의 한 종류로 Neptune에서 지원하지 않음.
- ESpark SQL❌ Spark SQL — Apache Spark의 대용량 분산 데이터 처리용 SQL 엔진. EMR·Glue에서 사용. Neptune과 무관.
| 모델 | 쿼리 언어 | 비유 | 사용 사례 |
|---|---|---|---|
| Property Graph | Gremlin | 🕸️ 친구 관계 지도 | SNS, 추천, 사기 탐지 |
| RDF Graph | SPARQL | 🔗 웹 링크드 데이터 | 지식 그래프, 온톨로지 |
| 관계형 DB | SQL / ANSI SQL | 📊 엑셀 테이블 | RDS, Redshift, Aurora |
| 분산 처리 | Spark SQL | ⚡ 대용량 병렬 처리 | EMR, Glue |
Amazon Neptune → Gremlin + SPARQL
Gremlin = Property Graph (노드·엣지 탐색)
SPARQL = RDF Graph (트리플 구조)
SQL 계열 = Neptune에서 지원 안 함Amazon DynamoDB는 초당 수만 건 이상의 읽기·쓰기를 밀리초 이내에 처리하는 완전 관리형 NoSQL 데이터베이스입니다. DynamoDB API를 통한 직접 접근을 지원해 애플리케이션 통합이 쉬우며, DEA-C01에서 고처리량 + API 접근 조합으로 자주 출제됩니다.
실시간 이벤트 로그를 수집하는 시스템을 설계하고 있습니다. 다른 서비스들이 이 시스템의 특정 레코드에 API를 통해 안정적으로 접근해야 하며, 매초 4,000건 이상의 쓰기와 6,500건 이상의 읽기를 동시에 처리할 수 있어야 합니다. 이 요건을 가장 잘 충족하는 스토리지 솔루션은 무엇일까요?
- A필요한 읽기·쓰기 용량을 프로비저닝한 Amazon DynamoDB 테이블을 생성하고, DynamoDB API로 모든 읽기·쓰기 작업을 처리합니다.✅ Amazon DynamoDB — 완전 관리형 키-값·문서 NoSQL DB. 초당 수만 건 읽기·쓰기를 한 자릿수 밀리초로 처리. 프로비저닝된 용량(Provisioned Capacity)으로 필요한 RCU(읽기)/WCU(쓰기) 단위 예약 → 4,000 쓰기 + 6,500 읽기 안정적으로 보장. DynamoDB API로 직접 접근.
- BS3에 로그 파일을 저장하고, Glue 데이터 카탈로그에 스키마를 등록한 뒤 Redshift Spectrum 외부 테이블로 읽기 작업을 처리합니다.❌ Redshift Spectrum — S3의 데이터를 Redshift에서 외부 테이블로 쿼리하는 기능. 분석용 배치 쿼리에 적합하지 초당 수천 건의 실시간 쓰기/읽기에는 부적합.
- CKEY 분포 스타일의 Amazon Redshift 테이블을 생성하고, Redshift Data API로 읽기·쓰기 작업을 처리합니다.❌ Amazon Redshift — 열 기반 데이터 웨어하우스. 대용량 분석 쿼리에 최적화되어 있고 초당 수천 건의 개별 행 쓰기에는 적합하지 않음.
- DEVEN 분포 스타일의 Amazon Redshift 테이블을 생성하고, JDBC 커넥터로 모든 읽기·쓰기 작업을 처리합니다.❌ Redshift + JDBC는 C와 같은 이유로 부적합. 추가로 JDBC 영구 연결 관리 오버헤드까지 발생.
| 서비스 | 초당 처리량 | API 접근 | 적합 워크로드 |
|---|---|---|---|
| DynamoDB | 수만 건/초 ✓ | DynamoDB API ✓ | 실시간 고빈도 읽기·쓰기 |
| Redshift | 수백 건/초 | Data API(비동기) | 대용량 분석 쿼리 |
| RDS/Aurora | 수천 건/초 | JDBC/ODBC | OLTP 트랜잭션 |
| S3+Spectrum | 배치만 가능 | 없음 | 데이터 레이크 분석 |
"초당 수천 건 읽기·쓰기 + API 접근" → DynamoDB
DynamoDB = 실시간 고처리량, 밀리초 응답, API 직접 접근
Redshift = 대용량 분석 쿼리, 고빈도 개별 쓰기에는 부적합AWS Glue 워크플로(Workflow)는 여러 Glue 작업을 병렬 또는 순차로 실행하고 의존성을 관리합니다. 15GiB 메모리 같은 대용량 처리는 G.2X 워커(16GiB)로 처리하며, Lambda의 최대 10GB 메모리 제한을 초과합니다.
미디어 분석팀이 매일 500GB 규모의 CSV 파일을 S3에서 Parquet 형식으로 변환하는 파이프라인을 설계하고 있습니다. 두 개의 변환 작업이 동시에(병렬로) 실행되어야 하며 각각 최대 15GiB의 메모리를 필요로 합니다. 두 작업이 모두 완료된 후에만 상관관계 분석 작업이 시작되어야 합니다. 가장 적합한 솔루션은 무엇일까요?
- AAWS Step Functions로 여러 Lambda 함수를 병렬 실행하고, 두 함수가 완료된 후 세 번째 Lambda를 실행하는 워크플로를 구성합니다.❌ AWS Lambda — 최대 실행 시간 15분, 최대 메모리 10GB. 15GiB(=15,360MB) 메모리 요건을 Lambda는 충족 불가. 500GB 대용량 장기 처리에도 부적합.
- BAmazon EMR로 두 작업을 실행하고, 각 작업 완료 메시지를 Amazon SQS 큐로 받아 Lambda로 세 번째 작업을 트리거합니다.❌ EMR + SQS + Lambda 조합은 기술적으로 가능하지만 구성이 복잡하고 비용도 높음. 세 번째 프로세스도 Lambda라면 메모리 제한 문제 재발. Glue 워크플로로 더 단순하게 해결 가능.
- CAWS Glue 워크플로를 구성하여 두 변환 작업을 병렬 실행하고, 완료 후 상관관계 분석 작업이 자동으로 시작되도록 트리거를 설정합니다.✅ AWS Glue 워크플로(Workflow) — 공장 라인에서 두 작업반이 동시에 일하고, 둘 다 끝나면 검수반이 시작하는 구조. Glue 작업은 G.2X 워커(16GiB 메모리)로 15GiB 요건 충족. 병렬 실행 + 완료 후 순차 트리거 모두 워크플로 내장 기능으로 처리. 추가 서비스 불필요.
- DAmazon MWAA로 Glue 작업 흐름을 DAG로 정의하고, 두 작업 완료 후 세 번째 작업이 실행되도록 의존성을 구성합니다.❌ Amazon MWAA — 완전 관리형 Airflow. 강력하지만 시간당 환경 비용이 발생하고 Glue 워크플로만으로 가능한 것에 과도한 레이어 추가. 비용 효율적이지 않음.
| 워커 유형 | 메모리 | vCPU | 적합 워크로드 |
|---|---|---|---|
| G.025X | 4GiB | 2 | 소형 ETL |
| G.1X | 8GiB | 4 | 중형 ETL |
| G.2X | 16GiB ✓ | 8 | 대형 ETL, 15GiB 요건 충족 |
| G.4X | 32GiB | 16 | 초대형 ETL |
| Lambda | 최대 10GB | - | 15GiB 요건 불충족 ✗ |
"병렬 실행 → 완료 후 순차 실행" → Glue Workflow
"15GiB 메모리 필요" → G.2X 워커 (16GiB)
Lambda 최대 메모리 = 10GB → 15GiB 요건이면 Lambda는 오답!
