Amazon CLF-C02: 핵심 데이터베이스 서비스 — 학습 가이드

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

다음의 일부입니다: AWS Cloud Practitioner CLF-C02 — 학습 가이드. 검증된 답안으로 연습하기: Amazon 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

관리형 관계형 데이터베이스: Amazon RDS 및 Amazon Aurora

Amazon RDS는 완전 관리형 관계형 엔진(MySQL, PostgreSQL, MariaDB, SQL Server, Oracle)을 제공하며, 자동 백업, 고가용성을 위한 다중 AZ(Multi-AZ), 스케일링을 위한 읽기 전용 복제본, 스냅샷 기반 복원 기능을 갖추고 있습니다. Aurora는 MySQL 및 PostgreSQL과 호환되는 특수 목적용 엔진으로, 분산된 내결함성 스토리지 계층에서 컴퓨팅을 분리하여 더 높은 처리량, 빠른 장애 복구, 그리고 백트랙(backtrack) 및 리전 간 복제를 위한 Global Database와 같은 기능을 제공합니다. 요금 모델에는 유연한 용량을 위한 온디맨드 인스턴스, 예측 가능한 비용 절감을 위한 예약 인스턴스 또는 Savings Plans, 그리고 가변적인 워크로드에 비용을 맞추기 위한 Aurora Serverless의 서버리스 또는 오토스케일링 용량 모델이 포함됩니다. 주요 아키텍처 결정은 읽기/쓰기 프로필, 지연 시간 요구 사항, 운영 허용 범위에 따라 달라집니다. 호환성 및 라이선스 요구 사항이 중요할 때는 RDS를, 더 높은 성능, 스토리지 오토스케일링 또는 글로벌 읽기가 필요할 때는 Aurora를 선택하세요. 실무에서 흔히 겪는 함정으로는 쓰기 집약적인 워크로드에 대한 IOPS 부족, 프로덕션 환경에서 Multi-AZ 활성화 누락, 기본 마스터 자격 증명 유지, 지정 시간 복구(point-in-time recovery) 테스트 미실시 등이 있습니다. 규정 준수를 위해 AWS KMS를 사용하여 저장 데이터 암호화를 활성화하고, 전송 중 데이터 암호화를 위해 TLS를 강제하며, 자동 백업 및 스냅샷이 보존 기간 및 리전 간 DR 목표를 충족하는지 확인해야 합니다.

NoSQL, 캐싱, 그래프 데이터베이스: DynamoDB, ElastiCache, Amazon Neptune

대규모 키-값 및 문서 워크로드의 경우, Amazon DynamoDB는 한 자릿수 밀리초의 지연 시간, 자동 파티셔닝, 그리고 두 가지 용량 모드(오토스케일링을 포함한 프로비저닝 모드와 예측 불가능한 트래픽을 위한 온디맨드 모드)를 제공합니다. DynamoDB Streams, 글로벌 테이블, 지정 시간 복구(PITR)와 같은 기능은 복제, 변경 데이터 캡처, 백업을 지원합니다. 흔한 함정은 파티션 키를 잘못 설계하여 핫 파티션과 스로틀링을 유발하는 것입니다. 먼저 데이터 액세스 패턴을 모델링해야 합니다. 지연 시간이 짧은 인메모리 워크로드에는 ElastiCache를 사용하세요. Redis는 영속성, 클러스터링, pub/sub을 제공하며, Memcached는 간단한 멀티스레드 캐싱을 제공합니다. 마이크로초 단위의 캐싱이 필요한 읽기 집약적인 DynamoDB 워크로드에는 DAX를 사용하세요. 관계 중심의 그래프 쿼리에는 Gremlin과 SPARQL을 지원하는 완전 관리형 그래프 데이터베이스인 Amazon Neptune을 사용합니다. 요금 결정: DynamoDB 온디맨드는 사용하기 쉽지만 트래픽이 꾸준히 높을 경우 더 비쌉니다. 오토스케일링이 포함된 프로비저닝 모드와 예약 용량(Reserved Capacity)을 사용하면 훨씬 저렴할 수 있습니다. ElastiCache의 캐시 크기, 제거 정책, 영속성 선택은 비용과 복구에 영향을 미칩니다. 관리형 NoSQL, 인메모리 캐시, 그래프 데이터베이스 중에서 선택할 때는 내구성, 일관성 모델, 운영 복잡성을 평가해야 합니다.

DynamoDB vs RDS/Aurora: 대규모 확장성, 유연한 스키마, 단일 테이블 설계에는 DynamoDB를, 복잡한 SQL 쿼리, 트랜잭션, 관계 무결성에는 RDS/Aurora를 사용합니다.
ElastiCache (Redis) vs DAX: 범용 인메모리 워크로드 및 영속성에는 Redis를, 클라이언트 측 통합이 포함된 DynamoDB 전용 읽기 캐시에는 DAX를 사용합니다.
Neptune: 순회 및 그래프 분석이 애플리케이션의 핵심일 때 사용합니다.

분석 및 데이터 레이크 패턴: Amazon Redshift, Athena, S3 스토리지 선택

Amazon Redshift는 복잡한 분석 쿼리와 높은 동시성에 최적화된 컬럼 기반의 페타바이트급 데이터 웨어하우스입니다. 최신 Redshift(RA3 노드)는 컴퓨팅과 관리형 스토리지를 분리하여 컴퓨팅을 독립적으로 확장하고 S3를 관리형 스토리지로 활용하여 비용을 절감할 수 있게 해줍니다. Redshift Spectrum은 데이터 레이크 통합을 위해 S3의 데이터를 직접 쿼리합니다. 파일에 대한 임시(ad-hoc) SQL 쿼리에는 Amazon Athena가 서버리스, 쿼리당 과금(스캔된 TB당 청구) 분석을 제공하며 S3의 CSV/Parquet/JSON에 이상적입니다. 파일 형식과 압축을 최적화하면 비용을 크게 줄일 수 있습니다. S3는 여러 스토리지 클래스를 제공합니다. 액세스 패턴을 알 수 없는 경우 S3 Intelligent-Tiering이 검색 요금 없이 비용을 최소화하기 위해 액세스 티어 간에 객체를 자동으로 이동시킵니다. 장기 아카이브의 경우 검색 지연 시간과 요금이 적용되는 S3 Glacier 또는 Glacier Deep Archive를 고려하세요. 비용 상충 관계에는 스토리지 대 컴퓨팅이 포함됩니다. 스캔 양을 줄이기 위해 압축, 파티셔닝, 컬럼 형식을 사용하고, 예측 가능한 성능을 위해 Redshift 동시성 확장(concurrency scaling) 및 워크로드 관리(workload management)를 고려하세요. 분석과 연계된 머신 러닝 워크로드의 경우, 대규모 훈련에는 GPU EC2 패밀리(P 또는 G 시리즈)가 필요할 수 있지만, 대부분의 분석 DB 워크로드는 GPU보다는 최적화된 CPU와 컬럼 기반 실행에 의존합니다.

마이그레이션, 백업, 보안 및 운영 모범 사례

데이터베이스를 마이그레이션하고 보호하려면 서비스와 정책을 올바르게 조합해야 합니다. AWS Database Migration Service (DMS)는 최소한의 다운타임으로 동종 및 이기종 마이그레이션을 처리합니다. Schema Conversion Tool은 다른 엔진 유형으로 이전할 때 데이터베이스 스키마를 변환하는 데 도움이 됩니다. 백업 및 정책 기반 보호를 위해서는 네이티브 엔진 기능(RDS 자동 백업 및 스냅샷, DynamoDB PITR)과 함께 AWS Backup을 사용하여 중앙 집중식 교차 서비스 백업 정책 및 교차 계정 또는 교차 리전 복사본을 관리해야 합니다. 보안에는 최소 권한 IAM 정책, 전송 중 암호화(TLS) 및 저장 시 암호화(KMS), 네트워크 제어가 포함되어야 합니다. 보안 그룹은 인스턴스에 연결하는 상태 저장(stateful) 호스트 수준 방화벽인 반면, 네트워크 ACL은 상태 비저장(stateless) 서브넷 수준 필터입니다. 둘은 상호 보완적이지만 동작 방식은 다릅니다. 공동 책임 모델에 따라 AWS는 클라우드 인프라를 관리하고, 고객은 데이터, IAM, 자체 관리형 인스턴스의 OS 수준 패치, 보안 암호 및 액세스 자격 증명의 키 교체를 관리합니다. CloudFormation, AWS CLI 또는 SDK를 사용한 운영 자동화를 통해 반복 가능한 환경 프로비저닝이 가능합니다. 흔히 저지르는 실수로는 루트 계정에 의존하거나, 광범위한 IAM 정책을 그대로 두거나, 키 교체를 소홀히 하거나, CloudWatch, VPC Flow Logs 또는 AWS Config를 사용한 모니터링을 실패하는 것 등이 있습니다. 대용량 데이터 전송의 경우, AWS Snowball 또는 DataSync를 사용하여 전송 중 암호화 및 무결성 검증을 통해 테라바이트/페타바이트 규모의 데이터를 안전하게 이동하는 것을 고려하십시오.

실용적인 문제: 사용 사례 시나리오

시나리오: AcmeRetail은 온프레미스 MySQL OLTP 데이터베이스와 온프레미스 NFS 공유에 저장된 대용량의 과거 CSV 판매 파일을 사용하여 시즌별 이커머스 플랫폼을 운영하고 있습니다. 이들의 AWS 계정에는 프라이빗 서브넷이 있는 VPC와 데이터 센터로 연결되는 Transit Gateway가 있습니다. 이들은 최소한의 다운타임으로 트랜잭션 데이터베이스를 마이그레이션하고, 과거 데이터를 BI용으로 쿼리할 수 있도록 만들어야 합니다.

과제: 거의 제로에 가까운 다운타임으로 프로덕션 데이터베이스를 이전하고, 과거 CSV에 대한 확장 가능한 분석을 활성화하며, 백업, 암호화, 최소 권한 액세스를 보장해야 합니다.

권장 접근 방식:

AWS Database Migration Service (DMS)를 사용하고, 필요한 경우 Schema Conversion Tool을 함께 사용하여 MySQL을 Amazon Aurora (MySQL 호환)로 마이그레이션합니다. 다운타임을 최소화하기 위해 지속적인 복제를 구성합니다.
AWS DataSync 또는 Snowball(매우 큰 볼륨의 경우)을 사용하여 과거 CSV를 Amazon S3로 전송하고, Intelligent-Tiering을 사용하여 S3에 저장한 다음, 쿼리 효율성을 위해 AWS Glue ETL을 사용하여 Parquet 형식으로 변환합니다.
BI 쿼리를 위해 Amazon Redshift (RA3)를 프로비저닝하거나 S3 데이터(Parquet)에 대해 Amazon Athena를 사용합니다. 웨어하우스와 데이터 레이크 쿼리를 결합해야 하는 경우 Redshift Spectrum을 사용합니다.
자동화된 백업(RDS 자동 백업 및 스냅샷)을 구현하고, KMS 키로 암호화를 활성화하며, 최소 권한 IAM 역할 및 보안 그룹으로 액세스를 제한하고, AWS Backup으로 백업 정책을 중앙에서 관리합니다.

근거: 지속적인 DMS 복제는 트랜잭션 시스템의 다운타임을 거의 제로에 가깝게 마이그레이션할 수 있게 해줍니다. S3 + Parquet + Athena/Redshift 조합은 분석 비용과 스캔 크기를 최소화합니다. KMS, 백업, 최소 권한 IAM은 가용성, 보안, 비용 관리를 위한 공동 책임 모델 및 운영 모범 사례에 부합합니다.

← 핵심 스토리지 서비스 · 모든 도메인 · 네트워킹 및 콘텐츠 전송 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →