AWS Glue를 VPC 환경에서 실행할 때 S3 연결 오류가 나는 원인 중 하나가 VPC Gateway Endpoint 라우팅 테이블 미설정입니다. 네트워크 경로 vs 권한 문제를 구분하는 것이 핵심이며, DEA-C01에서 Glue + VPC 트러블슈팅 유형으로 자주 출제됩니다.

• AS3 VPC 게이트웨이 엔드포인트로부터의 트래픽을 허용하도록 Glue 작업에 연결된 보안 그룹의 인바운드 규칙을 수정합니다.
  ✕ 보안 그룹(Security Group) — 출입구 경비원. Gateway Endpoint에는 경비원이 없음. 보안 그룹은 Interface Endpoint(전용 직통 전화선)에만 붙는 개념. Gateway는 라우팅 테이블이 담당.
• BGlue 작업이 대상 S3 버킷에 접근할 수 있도록 버킷 리소스 기반 정책에 명시적 허용 구문을 추가합니다.
  ✕ S3 버킷 정책(Bucket Policy) — 창고 출입 명단. IAM 권한은 이미 설정됐다고 전제되어 있음. 권한 문제가 아닌 네트워크 경로 문제. 명단 수정해봤자 길이 없으면 못 감.
• CGlue 연결 설정에서 S3 엔드포인트의 전체 도메인 이름(FQDN)이 올바르게 지정되어 있는지 확인합니다.
  ✕ FQDN(Fully Qualified Domain Name) — 완전 정규화 도메인 이름 (예: s3.ap-northeast-2.amazonaws.com). Gateway Endpoint는 도메인이 아닌 Prefix List(IP 대역 묶음) 기반으로 라우팅. FQDN 수정은 이 오류와 무관.
• DGlue 작업이 실행되는 서브넷의 라우팅 테이블에 S3 VPC 게이트웨이 엔드포인트를 향하는 경로가 등록되어 있는지 확인합니다.
  ✓ 라우팅 테이블(Routing Table) — 내비게이션 경로표. S3 Gateway Endpoint를 만들어도 VPC 서브넷의 라우팅 테이블에 "S3 → 엔드포인트" 경로가 등록되어야 트래픽이 흐름. 경로 없으면 차가 고속도로 무시하고 일반 인터넷으로 나가려다 차단 → 정확히 이 오류.

AWS Lake Formation의 행 수준 보안(Row-Level Security)은 데이터 레이크에서 국가·부서별 접근 제어를 운영 부담 없이 구현하는 핵심 기능입니다. 테이블을 나누거나 리전을 분리하지 않고도 단일 데이터셋에서 정책 기반으로 접근을 제한할 수 있어 DEA-C01 거버넌스·보안 도메인에서 자주 출제됩니다.

• A국가별로 별도의 테이블을 생성하고, 각 분석가에게 담당 국가의 테이블에 대한 접근 권한만 개별 부여합니다.
  ✕ 국가별 서류함 따로 만들기. 국가가 늘어날 때마다 테이블 생성 → 권한 부여 작업이 반복됨. 운영 최소화와 반대 방향.
• BS3 버킷을 AWS Lake Formation의 데이터 레이크 위치로 등록하고, Lake Formation의 행 수준 보안(Row-Level Security) 기능으로 접근 정책을 적용합니다.
  ✓ AWS Lake Formation — 데이터 레이크 중앙 거버넌스 서비스. 행 수준 보안(Row-Level Security, RLS) — 도서관 사서가 "이 직원은 한국 섹션만 열람 가능"이라고 출입증에 등록해두면 어느 책장을 열어도 자동 필터링되는 것. 데이터를 나누지 않고 정책 하나로 모든 접근을 제어. 국가 추가 시 조건값만 추가하면 끝.
• C고객 데이터를 해당 국가와 가장 가까운 AWS 리전으로 이동하고, 각 분석가에게 해당 리전 데이터에 대한 접근 권한을 부여합니다.
  ✕ 국가마다 창고 따로 짓기. 리전(Region) — AWS 물리 데이터센터 지역 단위. 리전별 데이터 이동 시 복제 비용 + 동기화 운영 발생. 접근 제어 문제를 인프라 분리로 해결하는 과도한 방법.
• D데이터를 Amazon Redshift로 이관하고, 국가별 뷰(View)를 생성한 뒤 국가마다 IAM 역할을 만들어 분석가에게 할당합니다.
  ✕ Amazon Redshift — 완전 관리형 클라우드 데이터 웨어하우스. 기술적으로 작동하지만 국가 추가 시마다 뷰 생성 → IAM(Identity and Access Management) 역할 생성 → 역할 매핑 3단계 반복. 운영 최소화 기준 미달.

AWS Data Exchange는 타사(3rd-party) 데이터셋을 AWS 환경에 직접 구독·통합할 수 있는 데이터 마켓플레이스입니다. 별도 파이프라인 구축 없이 구독 즉시 S3로 전달되기 때문에 운영 오버헤드가 가장 낮으며, DEA-C01에서 "타사 데이터 + 운영 최소화" 조합으로 자주 출제됩니다.

• AAWS Data Exchange를 통해 외부 데이터 제공업체의 데이터셋을 구독하고, API 호출로 분석 플랫폼에 통합합니다.
  ✓ AWS Data Exchange — 타사 데이터 마켓플레이스. 마트에서 완제품을 사는 것처럼, 수백 개 데이터 공급자의 데이터셋을 구독 즉시 S3로 자동 전달받는 서비스. 파이프라인 구축·계약 협상·전송 인프라 관리 불필요. 타사 데이터 통합에 특화된 유일한 AWS 서비스.
• BAWS DataSync를 사용하여 외부 제공업체 데이터를 API로 가져와 분석 플랫폼과 연동합니다.
  ✕ AWS DataSync — 온프레미스 ↔ AWS 스토리지 간 대용량 파일 자동 동기화 트럭. NAS·NFS·SMB 같은 내부 파일 시스템을 S3/EFS로 이전·동기화하는 서비스. 외부 타사 데이터 마켓플레이스 접근 기능 없음.
• CAmazon Kinesis Data Streams를 활용해 AWS CodeCommit 저장소에 있는 외부 데이터셋을 실시간으로 수집합니다.
  ✕ AWS CodeCommit — 소스 코드 저장소(Git 서버). Amazon Kinesis Data Streams — 실시간 스트리밍 데이터 컨베이어 벨트. 코드 저장소에 타사 데이터셋이 있을 이유가 없고, Kinesis는 실시간 이벤트 스트림 전용. 둘 다 이 시나리오와 무관.
• DAmazon Kinesis Data Streams와 Amazon ECR을 연동하여 외부 데이터를 수집하고 분석 플랫폼에 통합합니다.
  ✕ Amazon ECR(Elastic Container Registry) — 도커 컨테이너 이미지 창고. 컨테이너 이미지(앱 실행 패키지)를 저장하는 곳이지 데이터셋 저장소가 아님. 타사 데이터 통합과 전혀 관련 없음.

데이터 메시(Data Mesh)는 도메인별로 데이터를 분산 소유하면서 중앙에서 거버넌스를 통제하는 아키텍처입니다. AWS에서 구현할 때는 S3 + Athena(분산 저장·쿼리)와 Lake Formation(중앙 거버넌스·접근 제어) 조합이 핵심입니다.

• A데이터 저장에는 Amazon Aurora를, 분석에는 Amazon Redshift 프로비저닝 클러스터를 사용합니다.
  ✕ Amazon Aurora — 완전 관리형 관계형 DB(트랜잭션 처리용). Redshift 프로비저닝 클러스터 — 중앙 집중식 데이터 웨어하우스. 둘 다 중앙 집중식 구조라 데이터 메시의 "도메인별 분산 소유" 철학과 맞지 않음.
• B데이터 저장에는 Amazon S3를, 분석에는 Amazon Athena를 사용합니다.
  ✓ Amazon S3(Simple Storage Service) — 무한 확장 객체 저장소. 각 도메인팀이 자기 버킷을 독립 소유 가능. Amazon Athena — S3 위에서 SQL을 바로 실행하는 서버리스 쿼리 엔진. Glue Data Catalog와 네이티브 연동. 데이터를 옮기지 않고 제자리에서 분석 → 데이터 메시의 분산 소유 + 중앙 쿼리 구조에 최적.
• C중앙 집중식 데이터 관리와 접근 제어에 AWS Glue DataBrew를 활용합니다.
  ✕ AWS Glue DataBrew — 노코드(No-Code) 시각적 데이터 정제 도구. 요리사가 레시피 보며 재료 손질하는 것. 데이터 프로파일링·클렌징·변환을 GUI로 하는 도구이지, 거버넌스·접근 제어 서비스가 아님. 이름에 Glue가 들어가서 헷갈리기 쉬운 함정 보기.
• D데이터 저장에는 Amazon RDS를, 대규모 처리에는 Amazon EMR을 사용합니다.
  ✕ Amazon RDS(Relational Database Service) — 관계형 DB 관리 서비스. Amazon EMR(Elastic MapReduce) — EC2 기반 Spark/Hadoop 클러스터. RDS는 트랜잭션 DB라 데이터 메시 스토리지에 부적합. EMR은 클러스터 관리 부담이 크고 Glue Catalog와의 통합이 Athena보다 복잡.
• E중앙 집중식 데이터 거버넌스와 접근 제어에 AWS Lake Formation을 활용합니다.
  ✓ AWS Lake Formation — 데이터 레이크 중앙 거버넌스 서비스. 건물 전체 출입 관리 시스템. Glue Data Catalog 위에서 테이블·컬럼·행 단위 접근 제어를 한곳에서 관리. 각 도메인팀은 데이터를 분산 소유하면서 거버넌스는 Lake Formation이 중앙 통제 → 데이터 메시 핵심 요건 충족.

AWS Lambda 레이어(Layer)는 여러 Lambda 함수가 공유하는 코드·라이브러리를 한 곳에서 관리하는 기능입니다. 공통 스크립트를 레이어로 패키징하면 레이어 한 번 수정으로 연결된 모든 함수에 즉시 반영되어, DEA-C01에서 Lambda 코드 중복 제거 및 유지보수 효율화 문제로 자주 출제됩니다.

• APython 스크립트의 S3 경로를 각 Lambda 함수의 실행 컨텍스트 객체에 포인터로 저장합니다.
  ✕ 실행 컨텍스트(Execution Context) — Lambda 함수가 실행될 때 생성되는 임시 런타임 환경. 호출 간 재사용될 수 있지만 영구 저장소가 아님. 함수마다 컨텍스트가 분리되어 공유가 안 됨.
• BPython 유틸리티 코드를 Lambda 레이어로 패키징하여 각 Lambda 함수에 연결합니다.
  ✓ Lambda 레이어(Lambda Layer) — 여러 Lambda 함수가 공유하는 공통 코드 패키지. 건물 공용 화장실처럼 한 번 설치하면 모든 층(함수)이 사용. Python 스크립트를 레이어로 올리고 각 함수에 연결하면 레이어만 새 버전으로 업데이트하면 끝. 함수 코드는 손댈 필요 없음.
• C공유 S3 버킷에 저장된 Python 스크립트 경로를 각 Lambda 함수의 환경 변수로 설정합니다.
  ✕ 환경 변수(Environment Variable) — Lambda 함수 설정에 key-value로 저장하는 구성값. 환경 변수는 각 Lambda 함수에 개별 설정되는 값. 스크립트 경로를 변수로 저장해도 함수마다 일일이 수정해야 해서 문제가 그대로.
• D모든 Lambda 함수에 동일한 별칭(Alias)을 부여하고, 별칭을 통해 함수를 호출합니다.
  ✕ Lambda 별칭(Alias) — 특정 함수 버전을 가리키는 포인터 이름표. "prod", "dev" 같은 별칭으로 버전 전환에 사용. 배포 버전 관리·트래픽 분산용 기능이지, 공통 코드를 여러 함수에 공유하는 기능이 아님.