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）を提供し、自動バックアップ、高可用性のためのMulti-AZ、スケーリングのためのリードレプリカ、スナップショットベースの復元機能を備えています。Auroraは、専用に構築されたMySQLおよびPostgreSQL互換のエンジンで、コンピュートを分散されたフォールトトレラントなストレージレイヤーから分離し、より高いスループット、高速なクラッシュリカバリ、そしてクロスリージョンレプリケーションのためのバックトラックやGlobal Databaseのような機能を提供します。料金モデルには、柔軟なキャパシティのためのオンデマンドインスタンス、予測可能なコスト削減のためのリザーブドインスタンスまたはSavings Plans、そして変動するワークロードに合わせてコストを調整するためのAurora Serverlessのサーバーレスまたは自動スケーリングキャパシティモデルが含まれます。主要なアーキテクチャの決定は、読み取り/書き込みプロファイル、レイテンシー要件、運用上の許容度に依存します。互換性やライセンスのニーズが優先される場合はRDSを、より高いパフォーマンス、ストレージの自動スケーリング、またはグローバルな読み取りが必要な場合はAuroraを選択します。実務者が陥りやすい一般的な罠は、書き込み負荷の高いワークロードに対してIOPSを過小にプロビジョニングすること、本番環境でMulti-AZを有効にし忘れること、デフォルトのマスター認証情報を保持し続けること、ポイントインタイムリカバリをテストしないことです。コンプライアンスのためには、AWS KMSを使用して保管時の暗号化を有効にし、転送中の暗号化のためにTLSを強制し、自動バックアップとスナップショットが保持期間とクロスリージョンDRの目標を満たしていることを検証します。

NoSQL、キャッシング、グラフデータベース: DynamoDB、ElastiCache、Amazon Neptune

大規模なキーバリューおよびドキュメントワークロード向けに、Amazon DynamoDBは1桁ミリ秒のレイテンシー、自動パーティショニング、そして2つのキャパシティモード（プロビジョニング済み（自動スケーリング付き）と予測不能なトラフィック向けのオンデマンド）を提供します。DynamoDB Streams、グローバルテーブル、ポイントインタイムリカバリ（PITR）などの機能が、レプリケーション、変更データキャプチャ、バックアップをサポートします。一般的な落とし穴は、ホットパーティションやスロットリングを引き起こす不適切なパーティションキーの設計です。まずデータアクセスパターンをモデル化することが重要です。低レイテンシーのインメモリワークロードにはElastiCacheを使用します。Redisは永続性、クラスタリング、pub/subを提供し、一方Memcachedはシンプルなマルチスレッドキャッシングです。マイクロ秒単位のキャッシングを必要とする読み取り負荷の高いDynamoDBワークロードにはDAXを使用します。関係中心のグラフクエリには、GremlinとSPARQLをサポートするフルマネージドのグラフデータベースであるAmazon Neptuneがあります。料金に関する決定：DynamoDBのオンデマンドは手軽ですが、安定して高いトラフィックがある場合はより高価になります。自動スケーリング付きのプロビジョニング済みモードとリザーブドキャパシティを組み合わせることで、はるかに安価にできます。ElastiCacheにおけるキャッシュのサイジング、削除ポリシー、永続性の選択は、コストとリカバリに影響します。マネージドNoSQL、インメモリキャッシュ、グラフデータベースの中から選択する際には、耐久性、整合性モデル、運用上の複雑さを評価してください。

DynamoDB vs RDS/Aurora: 大規模なスケール、スキーマフレキシブル、シングルテーブル設計にはDynamoDB。複雑なSQLクエリ、トランザクション、リレーショナル整合性にはRDS/Aurora。
ElastiCache (Redis) vs DAX: 汎用のインメモリワークロードと永続性にはRedis。DAXはクライアントサイドで統合されるDynamoDB専用の読み取りキャッシュ。
Neptune: トラバーサルとグラフ分析がアプリケーションの中核である場合に使用。

分析とデータレイクのパターン: Amazon Redshift、Athena、S3ストレージの選択肢

Amazon Redshiftは、複雑な分析クエリと高い同時実行性に最適化された、カラムナ（列指向）のペタバイト規模のデータウェアハウスです。最新のRedshift（RA3ノード）はコンピュートとマネージドストレージを分離しており、コンピュートを独立してスケールさせ、S3をマネージドストレージとして活用することでコストを削減できます。Redshift Spectrumは、データレイク統合のためにS3上のデータを直接クエリします。ファイルに対するアドホックなSQLクエリには、Amazon Athenaがサーバーレスのクエリ課金型分析（スキャンしたTBあたりの課金）を提供し、S3上のCSV/Parquet/JSONに最適です。フォーマットと圧縮を最適化することで、コストを大幅に削減できます。S3は複数のストレージクラスを提供します。アクセスパターンが不明な場合は、S3 Intelligent-Tieringがアクセス階層間でオブジェクトを自動的に移動させ、取り出し料金なしでコストを最小化します。長期アーカイブには、取り出しレイテンシーと料金が発生するS3 GlacierまたはGlacier Deep Archiveを検討してください。コストのトレードオフには、ストレージとコンピュートの比較が含まれます。スキャン量を減らすために、圧縮、パーティショニング、カラムナフォーマットを使用します。予測可能なパフォーマンスのためには、Redshiftのコンカレンシースケーリングとワークロード管理を検討してください。分析に関連する機械学習ワークロードでは、大規模なトレーニングにはGPU EC2ファミリー（PシリーズまたはGシリーズ）が必要になる場合がありますが、ほとんどの分析DBワークロードはGPUではなく、最適化されたCPUとカラムナ実行に依存しています。

移行、バックアップ、セキュリティ、および運用のベストプラクティス

データベースの移行と保護には、サービスとポリシーの適切な組み合わせが必要です。AWS Database Migration Service (DMS) は、最小限のダウンタイムで同種および異種の移行を処理します。Schema Conversion Tool は、異なるエンジンタイプ間で移行する際のデータベーススキーマの変換を支援します。バックアップとポリシーベースの保護には、RDS の自動バックアップとスナップショット、DynamoDB の PITR といったネイティブのエンジン機能と、AWS Backup を併用します。AWS Backup を使うことで、バックアップポリシーの一元管理、サービス横断のバックアップ、クロスアカウントまたはクロスリージョンでのコピーが可能になります。セキュリティには、最小権限の IAM ポリシー、転送中の暗号化 (TLS) と保管時の暗号化 (KMS)、およびネットワーク制御が含まれなければなりません。セキュリティグループはインスタンスにアタッチするステートフルなホストレベルのファイアウォールであり、ネットワーク ACL はステートレスなサブネットレベルのフィルターです。両者は補完的ですが、動作は異なります。責任共有モデルでは、AWS がクラウドのインフラストラクチャを管理し、顧客はデータ、IAM、セルフマネージドインスタンスの OS レベルのパッチ、シークレットやアクセス認証情報のキーローテーションを管理します。CloudFormation、AWS CLI、または SDK を使用した運用自動化により、再現可能な環境プロビジョニングが可能になります。よくある落とし穴は、ルートアカウントに依存すること、広範な権限を持つ IAM ポリシーをそのままにすること、キーローテーションを怠ること、CloudWatch、VPC Flow Logs、または AWS Config を使用したモニタリングを怠ることです。大規模なデータ転送には、AWS Snowball または DataSync を検討してください。これらを使用すると、転送中の暗号化と整合性検証により、テラバイト/ペタバイト単位のデータを安全に移動できます。

実践的な問題：ユースケースシナリオ

シナリオ：AcmeRetail は、オンプレミスの MySQL OLTP データベースと、オンプレミスの NFS 共有にある大規模な過去の CSV 形式の売上ファイルを使用して、季節性のある e コマースプラットフォームを運営しています。彼らの AWS アカウントには、プライベートサブネットを持つ VPC と、データセンターへの Transit Gateway があります。彼らは、トランザクションデータベースを最小限のダウンタイムで移行し、過去のデータを BI のためにクエリ可能にする必要があります。

課題：本番データベースをほぼゼロのダウンタイムで移行し、過去の CSV データに対してスケーラブルな分析を可能にし、バックアップ、暗号化、最小権限アクセスを確保すること。

推奨アプローチ：

AWS Database Migration Service (DMS) を使用し、必要に応じて Schema Conversion Tool を併用して、MySQL を Amazon Aurora (MySQL 互換) に移行します。継続的なレプリケーションを設定してダウンタイムを最小限に抑えます。
AWS DataSync または Snowball (非常に大容量の場合) を使用して、過去の CSV ファイルを Amazon S3 に転送します。S3 では Intelligent-Tiering を使用して保存し、クエリ効率を高めるために 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で時間制限付き練習 →