データベースサービス

AWSデータベースサービスは、完全マネージドなリレーショナルエンジン（Amazon RDSおよびAmazon Aurora）・専用NoSQLエンジン（Amazon DynamoDB）・インメモリキャッシュ（Amazon ElastiCacheおよびAmazon MemoryDB for Redis）・グラフ（Amazon Neptune）・分析（Amazon Redshift）・ドキュメント（Amazon DocumentDB）・時系列（Amazon Timestream）向けの特化型エンジン、さらにAWS DMSおよびAWS Schema Conversion Toolによるマイグレーションツールから構成される。CLF-C02のタスクステートメント3.4では、各サービスが属するカテゴリ・代表的なユースケース・Amazon RDS・Amazon Aurora・Amazon DynamoDB間の主なトレードオフを理解することが求められる。本章ではスコープ内のすべてのAWSデータベースサービスを解説し、よく混同されるペアを比較し、CLF-C02試験のブループリントに合わせたシナリオ練習・暗記コールアウト・FAQで締めくくる。

AWSデータベースサービスとは何か？

AWSデータベースサービスとは、セルフマネージドのインフラストラクチャ上でデータベースを運用する際の運用負荷を取り除く、専用かつ完全マネージドなデータストアのポートフォリオだ。EC2インスタンスをプロビジョニングし、データベースエンジンをインストールし、パッチを適用し、バックアップを設定し、ゼロから高可用性を構築する代わりに、ワークロードの形状に合ったAWSデータベースサービスを選べばよい。リレーショナル・キーバリュー・ドキュメント・グラフ・カラム型分析・インメモリ・時系列の各タイプがある。CLF-C02試験では、各サービスを認識し、それがリレーショナルか非リレーショナルかを把握し、シナリオのプロンプトに対応付ける能力が問われる。

Amazon RDSはフラッグシップのマネージドリレーショナルデータベースだ。Amazon AuroraはRDSプラットフォームの上に構築されたAWSネイティブのリレーショナルエンジンだ。Amazon DynamoDBはフラッグシップのマネージドNoSQLサービスだ。AWS DMSは既存のデータベースを最小のダウンタイムでこれらのAWSデータベースサービスに移行するツールだ。RDS・Aurora・DynamoDB・DMSが試験問題の大部分をカバーし、ElastiCache・Neptune・Redshift・DocumentDB・Timestream・MemoryDBはシナリオ問題のディストラクターとして登場する。

AWSデータベースサービスが存在する理由

オンプレミスのデータベースはキャパシティ計画・ライセンス管理・パッチ適用・バックアップテープのローテーション・手動フェイルオーバーの演習を必要とする。AWSデータベースサービスへの移行は、これらの設備投資と人件費を従量課金の運用コストに変換する。AWSデータベースサービスはAWS Identity and Access Management・Amazon CloudWatch・AWS Backup・AWS Key Management Serviceとも統合されており、Amazon RDS・Amazon Aurora・Amazon DynamoDB・AWS DMSパイプラインを横断してセキュリティ・可観測性・データ保護が一貫して機能する。

CLF-C02のブループリントにおける本トピックの位置づけ

AWS CLF-C02試験ガイドのタスクステートメント3.4では、AWSデータベースサービスの識別を求める。このトピックはドメイン3（クラウド技術とサービス、試験全体の34%）に属する。Amazon RDS・Amazon Aurora・Amazon DynamoDB間の選択を求めるシナリオ問題と、特定のワークロード（例: グラフトラバーサルではAmazon Neptune、時系列テレメトリではAmazon Timestream）をどのAWSデータベースサービスが処理するかを問う想起問題に直面することになる。

やさしい解説: AWSデータベースサービス

サービス名がまだ抽象的に感じられる場合、この3つの類比でAWSデータベースサービスを日常的な言葉に置き換えてみよう。試験当日にAWSデータベースサービスのシナリオ問題を目にしたとき、最も記憶に残った類比を活用すること。

Analogy 1 — 巨大フードコートの厨房

AWSデータベースサービスを巨大なフードコートの中の異なる厨房として考えよう。Amazon RDSはシェフが自ら料理するが、食洗機の管理・換気・食材補充は建物側が担う、設備の整ったヨーロッパスタイルの厨房だ。Amazon Auroraはシェフ独自のAWSが設計した厨房であり、ストレージ層をクラウド規模向けに再設計しているため、通常のMySQLの厨房より5倍速く、通常のPostgreSQL厨房より3倍速い。Amazon DynamoDBはラーメンの自動販売機だ。シェフも不要、メニューの交渉も不要、キーを指定すれば1桁ミリ秒でボウルが出てくる。Amazon ElastiCacheは出来上がった料理を温めておくパススルーウィンドウであり、空腹のお客様が厨房を待たなくて済む。AWS DMSは、お客様を食事抜きにせずに古いビルからフードコートへレストラン全体を移転させる引っ越し会社だ。

Analogy 2 — 公共図書館

図書館を組織のデータだと想像しよう。Amazon RDSは参考文献コーナーであり、本が厳格な分類体系で棚に整理されている。構造化されたテーブルを横断するSQLクエリに最適だ。Amazon Auroraは同じ参考文献コーナーだが、AWSが設計したロボット書架システムで一度に5冊の本を取り出せる。Amazon DynamoDBはクロークルームだ。番号札（パーティションキー）を渡せば中身を気にせず即座に荷物を返してくれる。Amazon Redshiftは過去数十年分の新聞をスキャンしてアーカイブした地下保管庫であり、研究者が何年分ものデータを横断する分析クエリを実行できる。Amazon Neptuneは家系図室であり、人々の関係をつなぐ家系図が管理されている。Amazon DocumentDBは雑誌コーナーであり、各号が自己完結したドキュメントだ。AWS DMSは利用者が本を借り続ける中で古い図書館の内容を新しい支店に搬送する引っ越し業者だ。

Analogy 3 — 持ち込み参照可能な試験

アプリケーションを持ち込み参照可能な試験を受ける学生として想像しよう。Amazon RDSは製本されたテキスト。すべてのページが索引付けされ、相互参照の一貫性が保証されており、章をまたいでつなぐ記述問題（JOIN）に回答できる。Amazon Auroraは同じ内容の高速印刷版の教科書。目次は同じだが、ページを素早くめくれる。Amazon DynamoDBはカンニングペーパーだ。1つのキーに1つの答えが即座に返るが、JOINも即興のSQLもなく、どの事実を含めるかを事前に計画しなければならない。後から再編成するのは苦痛だ。ElastiCacheは短期記憶だ。最初の50個の事実を暗記しておくことで、テキストをその都度開かずに済む。Amazon Timestreamは試験中の毎秒の記録を残すストップウォッチログであり、後から分析できる。AWS DMSは読み続ける中でテキストを新しいバインダーにコピーする書記係だ。

コア動作原則：マネージド対セルフマネージドデータベース

CLF-C02の根本的な区別はマネージド対セルフマネージドだ。Amazon EC2インスタンス上でMySQL・PostgreSQL・Oracle・SQL Serverを実行する場合、オペレーティングシステムのパッチ適用・データベースエンジンの更新・バックアップ・フェイルオーバーの自動化・高可用性の設定のすべてを自分で担う。Amazon RDS・Amazon Aurora・Amazon DynamoDBなどのAWSデータベースサービスを使う場合は、AWSが差別化されていない重労働を引き受ける。OSパッチ適用・エンジンのパッチ適用・自動バックアップ・ポイントインタイムリカバリ・Multi-AZレプリケーション・リードレプリカのプロビジョニングが含まれる。

AWSデータベースサービスにおける責任共有

AWS責任共有モデルの下では、AWSはクラウドのセキュリティ（物理ホスト・ハイパーバイザー・Amazon RDSやAmazon AuroraなどのAWSデータベースサービスのマネージドエンジンパッチ）に責任を負う。クラウド内のセキュリティはお客様の責任のまま残る。データベースユーザー・テーブルレベルの権限・AWS KMS経由の暗号化キーの選択・セキュリティグループによるネットワークアクセス制御・Amazon CloudWatch LogsとAWS CloudTrailによる監査ログが含まれる。Amazon DynamoDBはさらに線を押し上げる。DynamoDBはサーバーレスであるため、AWSがストレージ層のすべてを運用する。

認識が必要なストレージパラダイム

• リレーショナル（SQL）: Amazon RDSエンジンとAmazon Aurora — 構造化スキーマ・ACIDトランザクション・SQLジョイン。
• キーバリュー / ドキュメント（NoSQL）: Amazon DynamoDB — 水平スケーリング・スキーマレス・1桁ミリ秒のレイテンシ。
• インメモリ: Amazon ElastiCacheとAmazon MemoryDB for Redis — キャッシュ・リーダーボード・セッションストア向けのマイクロ秒の読み取り。
• グラフ: Amazon Neptune — ソーシャルネットワーク・不正検出などの関係性重視のワークロード。
• データウェアハウス / OLAP: Amazon Redshift — ペタバイト規模のカラム型分析。
• ドキュメント: Amazon DocumentDB — JSONドキュメント向けのMongoDBとの互換性。
• 時系列: Amazon Timestream — IoTセンサーとDevOps監視データ。

Amazon RDS — フラッグシップのマネージドリレーショナルデータベース

Amazon RDS（Relational Database Service）は、大多数の受験者が最初にAWSデータベースサービスと聞いて連想するAWSサービスだ。Amazon RDSは6つのデータベースエンジンを実行する。MySQL・PostgreSQL・MariaDB・Oracle・Microsoft SQL Server・Amazon Auroraだ（AuroraはAmazon RDSのエンジンオプションであると同時に独立したサービスとしてもブランド化されている）。Amazon RDSはライフサイクル全体を自動化する。プロビジョニング・パッチ適用・バックアップ・監視・フェイルオーバーだ。

Amazon RDSのコア機能

• 設定可能な保持期間（最大35日）によるポイントインタイムリカバリを含む自動バックアップ。
• 高可用性のために2番目のアベイラビリティゾーンのスタンバイにプライマリを同期的にレプリケートするMulti-AZデプロイメント。
• 読み取りスケーリングと災害復旧のためのリードレプリカ（MySQL・MariaDB・PostgreSQLで最大5台、Auroraで最大15台）。
• AWS KMSによる保存時の暗号化とSSL/TLSによる転送時の暗号化。
• メトリクス用のAmazon CloudWatchとクエリレベルの可観測性のためのAmazon RDS Performance Insightsとの統合。

Amazon RDSを選ぶべき場合

アプリケーションが標準的なSQLで構築されており、ACIDトランザクション・構造化スキーマ・JOIN・馴染みのあるツールが必要な場合はAmazon RDSを選ぶこと。代表的なワークロードには、商取引プラットフォーム・コンテンツ管理システム・ERPバックエンド・MySQL・PostgreSQL・SQL Serverをすでに使っているあらゆる基幹業務アプリケーションが含まれる。Amazon RDSはデータモデリングとアプリケーションレベルのチューニングを除くすべての運用タスクを取り除く。

Amazon RDSの料金モデルの概要

Amazon RDSはDBインスタンスの時間単位・プロビジョニングされたストレージのGB-月単位・io1/io2ボリュームのIOPS単位・無料割り当てを超えるバックアップストレージ・クロスリージョンのデータ転送で課金される。Amazon RDSにリザーブドインスタンスを使用して1年または3年をコミットすれば、オンデマンド料金と比較して最大69%の節約が可能だ。

Amazon Aurora — AWSネイティブの高性能リレーショナルデータベース

Amazon Auroraは（a）Amazon RDS内のエンジンオプションであり、（b）独立してブランド化されているAWSネイティブのリレーショナルデータベースエンジンだ。Amazon AuroraはMySQLとの互換性とPostgreSQLとの互換性を持ち、既存のドライバーとSQLがそのまま動作する。変わるのはストレージ層だ。Amazon Auroraはエンジンのディスクサブシステムを、3つのアベイラビリティゾーンにまたがる分散型・自己修復型・6方向レプリケーション・SSDバックアップのファブリックに置き換える。

Amazon Auroraが高速な理由

Amazon AuroraはAWSのベンチマークによれば、RDS上の標準MySQLの最大5倍、RDS上の標準PostgreSQLの最大3倍のスループットを実現する。この速度向上は、REDOログ処理をストレージ層にオフロードすることで、ネットワーク越しにフルデータページを書き込む必要をなくしたことによる。

Amazon Auroraのデプロイオプション

• Aurora Provisioned — DBインスタンスクラス（コンピューティング）を選び、稼働時間分を支払う。
• Aurora Serverless v2 — 需要に応じて細かい粒度のACU（Auroraキャパシティユニット）でキャパシティがスケールする。スパイク型または開発用ワークロードに最適。
• Aurora Global Database — プライマリクラスターを最大5つのセカンダリAWSリージョンに拡張し、通常1秒未満のレプリケーションラグでグローバルな低レイテンシ読み取りとクロスリージョン災害復旧を実現する。

Amazon DynamoDB — あらゆるスケールでのサーバーレスNoSQL

Amazon DynamoDBは、あらゆるスケールで1桁ミリ秒のレイテンシを実現する完全マネージド・サーバーレス・キーバリューおよびドキュメントのNoSQLデータベースだ。DynamoDBには管理すべきサーバーも、プロビジョニングするストレージも、パッチを適用するクラスターもない。テーブルを作成し、パーティションキー（および任意でソートキー）を定義すれば、Amazon DynamoDBがキャパシティ・3つのアベイラビリティゾーンへのレプリケーション・バックアップを処理する。

Amazon DynamoDBのキャパシティモード

• オンデマンド — 読み取りリクエストユニットと書き込みリクエストユニットあたりの支払い。予測不能なワークロードに最適。
• プロビジョニード — RCU（読み取りキャパシティユニット）とWCU（書き込みキャパシティユニット）を宣言する。予測可能なワークロードで安価であり、Auto Scalingと組み合わせることができる。

Amazon DynamoDBの主な機能

• グローバルテーブル: グローバルに分散したアプリのためのアクティブ-アクティブのマルチリージョンレプリケーション。通常数秒以内でレプリケーションされる。
• DynamoDB Streams: AWS Lambdaとのイベント駆動パターンに統合された順序付き変更ログ。
• DynamoDB Accelerator（DAX）: DynamoDBの前段にあるインメモリキャッシュで、マイクロ秒の読み取りを実現する。
• 最大35日間のポイントインタイムリカバリと継続的バックアップ（AWS Backupとの統合あり）。
• テーブル・アイテム・属性レベルでのIAMポリシーによる細かいアクセス制御。

Amazon DynamoDBを選ぶべき場合

大規模でのレイテンシの予測可能性が必要で、アクセスパターンが既知でシンプル（キーによる検索・キーによる書き込み）、かつサーバーサイドのJOINや複雑なアドホッククエリが不要な場合はAmazon DynamoDBを選ぶこと。一般的なユースケースには、ゲームリーダーボード・セッションストア・IoTデバイス状態・ショッピングカート・ユーザープロファイル・毎秒数百万リクエストにゼロからスケールする必要があるあらゆるサーバーレスマイクロサービスが含まれる。

Amazon ElastiCache — サブミリ秒の読み取りのためのインメモリキャッシュ

Amazon ElastiCacheは、2つのエンジン（ElastiCache for RedisとElastiCache for Memcached）をサポートする完全マネージドなインメモリデータストアだ。ElastiCacheはメインのAWSデータベースサービス（Amazon RDS・Amazon Aurora・Amazon DynamoDB）の前段に配置され、ホットアイテム・セッショントークン・認証状態・事前計算済みフィードをキャッシュする。

ElastiCache for Redis対ElastiCache for Memcached

• ElastiCache for Redis — リッチなデータ型（リスト・セット・ソート済みセット・ハッシュ・ストリーム）・レプリケーション・永続化・pub/sub・Luaスクリプティング・自動フェイルオーバーつきMulti-AZ・暗号化。
• ElastiCache for Memcached — マルチスレッド・純粋なキャッシュ・永続化なし・レプリケーションなし・水平シャーディングのみ。

Amazon MemoryDB for Redis — 耐久性のあるインメモリ主要データベース

Amazon MemoryDB for RedisはElastiCacheと主要ストアの境界を曖昧にする。MemoryDBはRedis APIを使用しながら、アベイラビリティゾーンをまたいで書き込みを永続化する分散トランザクションログによってMulti-AZの耐久性を追加する。マイクロ秒の読み取りと1桁ミリ秒の書き込みの耐久性が必要なアプリケーション（リアルタイムバンキング・ゲームの状態・ストリーミングプラットフォームなど）は、ElastiCacheと別の耐久性ストアの組み合わせの代わりに、MemoryDBを主要データベースとして使用できる。

Amazon Neptune — マネージドグラフデータベース

Amazon Neptuneは、プロパティグラフ（Apache TinkerPop Gremlin）とRDF（SPARQL）の両クエリモデルをサポートする完全マネージドなグラフデータベースだ。グラフデータベースはデータをノードとエッジとしてモデル化し、関係性が主要なクエリターゲットである場合に最適だ。代表的なAmazon Neptuneのワークロードには、ソーシャルネットワーク・不正検出・知識グラフ・推薦エンジン・アイデンティティ解決が含まれる。CLF-C02試験では、「高度に接続されたデータ」や「関係性のトラバーサル」が強調されているシナリオでAmazon Neptuneが正解となる。

Amazon Redshift — ペタバイト規模のデータウェアハウス

Amazon Redshiftは、オンライン分析処理（OLAP）向けに設計された、完全マネージドなカラム型・大規模並列処理のデータウェアハウスだ。Redshiftはテラバイト〜ペタバイトの構造化・半構造化データに対する複雑な分析クエリに最適化されている。Redshift SpectrumはAmazon S3に直接保存されているデータまでクエリを拡張し、Redshift Serverlessはスパイク型の分析ワークロードのキャパシティ計画を不要にする。

Amazon DocumentDB — MongoDB互換のドキュメントストア

Amazon DocumentDB（MongoDB互換）は、MongoDB 3.6・4.0・5.0のAPIをサポートするマネージドドキュメントデータベースだ。自己記述型のJSONドキュメントを保存するアプリケーション（商品カタログ・コンテンツ管理・スキーマが変化するユーザープロファイルなど）は、運用をAWSにオフロードしながらAmazon DocumentDBをMongoDBのドロップイン代替として使用できる。DocumentDBはAmazon Auroraと同様にコンピューティングとストレージを分離し、クラスターあたり最大15台のリードレプリカをスケールできる。

Amazon Timestream — 時系列データベース

Amazon Timestreamは、IoTテレメトリ・DevOps可観測性・産業センサーデータ向けの専用時系列データベースだ。時系列データには独自のパターンがある。高書き込みボリューム・追記専用の書き込み・時間ベースのクエリ（直近1分・直近1時間・ローリングウィンドウ）・「ホット」から「コールド」へとデータが古くなることだ。Amazon Timestreamは階層型ストレージ（最近のデータはインメモリ、古いデータは磁気ストレージ）と、汎用のリレーショナルエンジンでは実装が面倒な組み込みの時系列分析関数を持つ。

AWS Database Migration Service（AWS DMS）

AWS Database Migration Serviceは、データベースをAWSに迅速かつ安全に移行する。ソースデータベースはマイグレーション中も完全に稼働し続けるため、それに依存するアプリケーションのダウンタイムを最小化する。AWS DMSは広大なマトリックスのソースおよびターゲットエンジンをサポートする。

同種移行対異種移行

• 同種移行 — ソースとターゲットのエンジンが同じ場合（例：オンプレミスのMySQL → Amazon RDS for MySQL；Oracle → Amazon RDS for Oracle）。AWS DMSがデータ移動を直接処理する。
• 異種移行 — ソースとターゲットのエンジンが異なる場合（例：Oracle → Amazon Aurora PostgreSQL；SQL Server → Amazon RDS for PostgreSQL）。データのためのAWS DMSと、テーブル・ビュー・ストアドプロシージャなどのスキーマオブジェクトのためのAWS Schema Conversion Tool（AWS SCT）を組み合わせる。

AWS Schema Conversion Tool（AWS SCT）

AWS SCTはソースデータベースのスキーマとアプリケーションコードの大部分（ビュー・ストアドプロシージャ・関数）をターゲットエンジンと互換性のある形式に変換する。自動変換できないオブジェクトは評価レポートで手動書き換えのためにフラグが立てられる。AWS SCTとAWS DMSはペアで使う。SCTがスキーマのシェルを移動し、DMSがデータを移動し（継続的にレプリケーション）する。

継続的なデータレプリケーション

AWS DMSは1回限りのフルロード・フルロードに続く変更データキャプチャ（CDC）・CDCのみの継続レプリケーションを実行できる。CDCモードはソースとターゲットを同期した状態に保ち、準備ができたらカットオーバーできる。典型的なダウンタイムは日単位ではなく分単位だ。

AWSデータベースサービスの比較マトリックス

試験ではシナリオのキーワードから正しいAWSデータベースサービスに素早くマッピングできる受験者が報われる。以下の比較でポートフォリオを1つの参照ビューに凝縮する。

リレーショナル対NoSQL

Amazon RDSとAmazon Auroraはリレーショナルだ。厳格なスキーマ・SQLクエリ・ACIDトランザクション・テーブル間のJOINを持つ。Amazon DynamoDBはNoSQLキーバリュー/ドキュメントだ。柔軟な属性・パーティションキーによるアクセス・手動チューニングなしの水平スケールを持つ。

マネージド対サーバーレス

Amazon RDSとAmazon Aurora Provisionedはマネージドだ。インスタンスクラスを選択して時間単位で支払う。Amazon DynamoDB（オンデマンド）とAurora Serverless v2はサーバーレスだ。リクエスト単位またはスケールされたキャパシティユニット単位で支払う。Amazon ElastiCacheとAmazon MemoryDB for Redisはマネージドのノードベースクラスターだ。

専用エンジンのまとめ

• RDBMS: Amazon RDS（6エンジン）、Amazon Aurora（AWSネイティブ）。
• キーバリュー / ドキュメントNoSQL: Amazon DynamoDB。
• インメモリキャッシュ: Amazon ElastiCache（Redis・Memcached）。
• インメモリ耐久性DB: Amazon MemoryDB for Redis。
• グラフ: Amazon Neptune。
• データウェアハウス / 分析: Amazon Redshift。
• ドキュメント（MongoDB互換）: Amazon DocumentDB。
• 時系列: Amazon Timestream。
• 台帳（不変・暗号学的検証可能）: Amazon QLDB（CLF-C02では基礎的な認識のみ）。
• ワイドカラム: Amazon Keyspaces for Apache Cassandra（CLF-C02では基礎的な認識のみ）。

覚えるべき重要数値

• Amazon RDSは6エンジンをサポート（MySQL・PostgreSQL・MariaDB・Oracle・SQL Server・Amazon Aurora）。
• Amazon AuroraはMySQLの最大5倍・PostgreSQLの最大3倍のスループットを実現し、3つのAZにわたる6方向レプリケーションストレージを持つ。
• Amazon Aurora Global Databaseは最大5つのセカンダリリージョンをサポート。
• Amazon DynamoDBは1桁ミリ秒のレイテンシを提供し、DAX経由でマイクロ秒まで縮まる。
• Amazon RDSの自動バックアップは最大35日間保持。DynamoDBのポイントインタイムリカバリも35日間。
• Amazon RDSはソースあたり最大5台のリードレプリカをサポート（MySQL/PostgreSQL/MariaDB）。Auroraは最大15台。

AWSデータベースサービスの頻出ひっかけ問題

CLF-C02の問題バンクは以下のポイントを繰り返し出題する。試験当日前に1つずつ確認すること。

罠1: Amazon RDS対Amazon DynamoDBの選択

問題はワークロードを記述してどのAWSデータベースサービスが適合するかを尋ねる。シナリオにSQL・JOIN・トランザクション整合性・「リレーショナル」が言及されている場合はAmazon RDSが正解だ。シナリオにキーバリューアクセス・毎秒数百万リクエスト・大規模スケール・「NoSQL」が言及されている場合はAmazon DynamoDBが正解だ。シナリオに「1桁ミリ秒のレイテンシでのあらゆるスケールのスキーマレスキーバリュー検索」とある場合、正解はAmazon DynamoDBであり、Amazon RDSではない。

罠2: AuroraはRDSエンジンであり独立したブランドでもある

Amazon AuroraはAmazon RDS内のエンジンオプションであり（RDSの管理プレーンを継承してバックアップ・監視・パッチ適用を行う）、独立してブランド化されたサービスでもある。なぜならAWSがストレージ層を書き直してAurora Global DatabaseやAurora Serverless v2などのネイティブクラウド機能を提供する高スループットを実現したからだ。試験目的では、パフォーマンス・クラウド規模のストレージ・グローバルデプロイを強調するシナリオでは、AWSネイティブの高性能RDSエンジンとしてAmazon Auroraを扱うこと。

罠3: ElastiCacheは主要データベースではない

「データベースの読み取り負荷を軽減する」「セッションキャッシュ」「サブミリ秒のリーダーボード」が言及されているシナリオはAmazon ElastiCacheを呼ぶ。耐久性・トランザクション・正規のソースが言及されているシナリオは呼ばない。

罠4: RedshiftはOLTPではない

RedshiftはOLAP用のデータウェアハウスだ。「SQL」とあってもユーザー向けのトランザクションアプリケーションには選ばないこと。

罠5: DMS単独対DMS + SCT

異種移行にはAWS DMSとAWS SCTの両方が必要だ。同種移行にはAWS DMSのみが必要だ。「OracleからPostgreSQLへの移行」を記述する問題が典型的な異種のトリガーであり、正しい答えのペアはAWS DMS + AWS SCTだ。

罠6: EC2上のセルフマネージドデータベース

EC2上でどのようなデータベースでも実行できるが、CLF-C02試験はシナリオが低運用オーバーヘッド・自動バックアップ・高可用性を優先する場合、EC2ホスト型データベースよりAWSデータベースサービスを好む傾向がある。「最小限の運用負荷」が正解のキーワードであれば、EC2ホスト型データベースよりAmazon RDS・Amazon Aurora・Amazon DynamoDBに傾くこと。

AWSデータベースサービス対AWSストレージサービス — 境界線を理解する

Amazon S3はデータを保存するためにデータベースと混同されることがある。S3はオブジェクトストレージだ。耐久性とスループットに最適化されており、インデックス付きの行レベルのクエリやACIDトランザクションには対応していない。Amazon RDS・Amazon Aurora・Amazon DynamoDBはレコードを返してスキーマ（リレーショナル）またはアクセスパターン（NoSQL）を強制するAWSデータベースサービスだ。CLF-C02試験ガイドがタスクステートメント3.4（AWSデータベースサービス）をタスクステートメント3.6（AWSストレージサービス）と区別して扱う理由がここにある。

現実のパターン：正しいAWSデータベースサービスの選択

現実的なAWSソリューションは通常、複数のAWSデータベースサービスを組み合わせる。小売プラットフォームを例に考えよう。

• Amazon RDS for PostgreSQLまたはAmazon Aurora PostgreSQL — ACIDトランザクションとJOINが必要な注文・請求書・顧客レコード。
• Amazon DynamoDB — 大規模スケールでのショッピングカート・セッション状態・商品カタログ検索。
• Amazon ElastiCache for Redis — 話題の商品のリーダーボードとキャッシュされた検索結果。
• Amazon Redshift — 数年分の販売履歴を横断するビジネスインテリジェンスクエリ。
• Amazon Neptune — 顧客・商品・購入行動をつなぐ推薦グラフ。
• AWS DMS — マイグレーション期間中にレガシーのオンプレミスOracleシステムからAmazon Auroraへの継続レプリケーション。

CLF-C02ではこのモザイクを設計することは求められないが、1つのシナリオの一文を正しいAWSデータベースサービスに対応付けることは求められる。

AWSデータベースサービス全体のセキュリティと可観測性

すべてのAWSデータベースサービスは、認証のためのAWS Identity and Access Management・保存時の暗号化のためのAWS KMS・メトリクスのためのAmazon CloudWatch・API監査のためのAWS CloudTrail・集中バックアップポリシーのためのAWS Backupと統合されている。Amazon RDS・Amazon Aurora・Amazon DynamoDBはさらにVPCベースのネットワーク分離をサポートし、Amazon DynamoDBはAWSサービスエンドポイント経由（AWS PrivateLink経由のVPCエンドポイントを含む）でアクセスされる。転送時の暗号化は、Amazon RDSとAmazon AuroraではSSL/TLS、Amazon DynamoDBではHTTPSで強制される。

AWSデータベースサービスのコストレバー

• Amazon RDS — エンジン・インスタンスクラス・ストレージタイプ（gp3対io1/io2）・Multi-AZのオン/オフ・リザーブドインスタンスの期間を選択。
• Amazon Aurora — Provisioned対Serverless v2。ストレージは使った分だけ自動スケールして支払う。
• Amazon DynamoDB — オンデマンド対プロビジョニングキャパシティ・DAXキャッシュサイズ・グローバルテーブルレプリケーションコスト。
• Amazon ElastiCache — ノードタイプと数・リザーブドノード割引。
• Amazon Redshift — Provisioned対Serverless・リザーブドノード・Redshift Spectrumのスキャンデータ。
• AWS DMS — レプリケーションインスタンスのサイズと時間・クロスリージョンデータ転送。

重要数値と必ず覚える事実

• Amazon RDSは6エンジンをサポート（MySQL・MariaDB・PostgreSQL・Oracle・SQL Server・Amazon Aurora）。
• Amazon Aurora: MySQLとPostgreSQLの互換性、最大MySQL比5倍/PostgreSQL比3倍のパフォーマンス。
• Amazon Auroraのストレージ: 3つのアベイラビリティゾーンにわたる6コピー。
• Amazon DynamoDB: サーバーレスNoSQLキーバリュー/ドキュメント、1桁ミリ秒のレイテンシ、マルチリージョンのアクティブ-アクティブのためのグローバルテーブル。
• Amazon ElastiCache: Redis（リッチなデータ型、レプリケーション）またはMemcached（マルチスレッド、シンプルなキャッシュ）。
• Amazon MemoryDB for Redis: 耐久性のあるRedis互換の主要データベース。
• Amazon Neptune: グラフ（Gremlin + SPARQL）。
• Amazon Redshift: 分析向けペタバイト規模のカラムデータウェアハウス。
• Amazon DocumentDB: MongoDB互換のドキュメントストア。
• Amazon Timestream: 専用時系列データベース。
• AWS DMS: 最小ダウンタイムでの同種・異種移行、CDCベースの継続レプリケーション。
• AWS SCT: 異種移行のためのスキーマ変換。AWS DMSとペアで使う。

タスク3.4の練習問題のキュー

CLF-C02試験でこれらのキーワードを見たら、AWSデータベースサービスに即座にマッピングすること。

• 「リレーショナル」「SQL」「JOIN」「ACID」「既存のPostgreSQL/MySQL/Oracle/SQL Serverのワークロード」 → Amazon RDS。
• 「クラウドネイティブのパフォーマンス、MySQL/PostgreSQL互換、1秒以内のRPOでのクロスリージョン災害復旧」 → Amazon Aurora。
• 「キーバリュー」「1桁ミリ秒」「サーバーレスNoSQL」「シンプルなアクセスパターンでの大規模スケール」 → Amazon DynamoDB。
• 「キャッシュ」「インメモリ」「サブミリ秒の読み取り」「データベースの負荷を軽減」 → Amazon ElastiCache（RedisまたはMemcached）。
• 「耐久性のあるRedis主要DB」「Multi-AZ永続性を持つインメモリ」 → Amazon MemoryDB for Redis。
• 「グラフ」「関係性」「ソーシャルネットワーク」「不正リングの検出」 → Amazon Neptune。
• 「データウェアハウス」「分析」「ペタバイト規模の集計」 → Amazon Redshift。
• 「MongoDB互換」「JSONドキュメント」 → Amazon DocumentDB。
• 「時系列」「IoTテレメトリ」「監視メトリクス」 → Amazon Timestream。
• 「最小ダウンタイムで既存データベースを移行」 → AWS DMS（エンジンが異なる場合はAWS SCTを追加）。

FAQ — AWSデータベースサービスの頻出問題

1. Amazon RDSとAmazon DynamoDBの主な違いは何か？

Amazon RDSは6つのSQLエンジン（MySQL・MariaDB・PostgreSQL・Oracle・SQL Server・Amazon Aurora）の1つを実行するマネージドリレーショナルデータベースであり、JOIN・トランザクション・構造化スキーマをサポートする。Amazon DynamoDBはあらゆるスケールで1桁ミリ秒のレイテンシを実現するサーバーレスNoSQLキーバリューおよびドキュメントデータベースだが、SQL JOINはサポートしない。リレーショナル構造が必要なシナリオではAmazon RDSを選ぶ。大規模スケール・サーバーレス運用・シンプルなキーベースのアクセスパターンを重視するシナリオではAmazon DynamoDBを選ぶ。

2. Amazon AuroraはAmazon RDSの一部か、独自のサービスか？

両方だ。Amazon AuroraはAmazon RDS内のエンジンオプションであり（バックアップ・監視・パッチ適用のためのRDS管理プレーンを継承する）、独立してブランド化されたサービスでもある。なぜならAWSがストレージ層を書き直してAurora Global DatabaseやAurora Serverless v2などのネイティブクラウド機能で高スループットを実現したからだ。試験目的では、クラウド規模のパフォーマンスまたはグローバルデプロイを強調するシナリオでは、AWSネイティブの高性能RDSエンジンとしてAmazon Auroraを扱うこと。

3. Amazon DynamoDBの代わりにAmazon ElastiCacheを使うべき場合はいつか？

Amazon ElastiCacheは主要データベースの前段にあるキャッシュだ。読み取りがホットで繰り返しが多い場合（セッショントークン・リーダーボード・キャッシュ済み検索）にプライマリストアにアクセスせずにマイクロ秒の応答時間が欲しい場合はElastiCacheを使うこと。Amazon DynamoDBは正規のデータストア自体だ。耐久性があり、複数のAZにわたってレプリケートされ、ポイントインタイムリカバリでサポートされている。シナリオが正規のソースとしての耐久性を必要とする場合はDynamoDBが勝つ。シナリオが既存のデータベースからの読み取りトラフィックをオフロードする必要がある場合はElastiCacheが勝つ。

4. AWS DMSとAWS Schema Conversion Tool（AWS SCT）の違いは何か？

AWS DMSはデータを移動する。ソースデータベースからターゲットデータベースへ最小ダウンタイムで行をレプリケートし、継続的な変更データキャプチャレプリケーションを含む。AWS SCTはデータベースオブジェクト（テーブル・ビュー・ストアドプロシージャ・関数）を異なるエンジン間で変換する。例えばOracle PL/SQLからPostgreSQL PL/pgSQLへの変換だ。同種移行（両側が同じエンジン）にはAWS DMSのみが必要だ。異種移行（エンジンが異なる）にはAWS DMSとAWS SCTの両方が必要だ。

5. AWSデータベースサービスの代わりにAmazon EC2上でデータベースを実行できるか？

できる。どのデータベースエンジンでもEC2インスタンスにセルフインストールできる。その場合、すべての運用タスクを自分で担う。OSパッチ適用・エンジンアップグレード・バックアップ・フェイルオーバーの自動化・高可用性設計だ。「最小限の運用オーバーヘッド」「完全マネージド」「管理するインフラストラクチャなし」を強調するCLF-C02の問題では、EC2ホスト型データベースよりAWSデータベースサービス（Amazon RDS・Amazon Aurora・Amazon DynamoDB）が優先される。シナリオがカスタムまたはサポートされていないエンジン、OSレベルの特定の制御、またはマネージドサービスを禁じるライセンシングを明示的に言及する場合のみEC2ホスト型を選ぶこと。

6. IoTセンサーデータにはどのAWSデータベースサービスを選ぶべきか？

Amazon Timestreamは、IoTテレメトリ・DevOpsメトリクス・産業センサーストリームのための専用時系列データベースだ。階層型ストレージ（インメモリのホット層 + 磁気のコールド層）と組み込みの時系列分析関数を提供する。CLF-C02では、タイムスタンプ付きのセンサーデータ・監視イベント・時間経過に伴うローリングウィンドウ集計に言及するあらゆるシナリオがAmazon Timestreamにマッピングされるべきだ。

7. AWSデータベースサービスはデータを自動的に暗号化するか？

ほとんどのAWSデータベースサービスは、AWS KMSによる保存時の暗号化とSSL/TLSまたはHTTPSによる転送時の暗号化をサポートする。Amazon RDSとAmazon Auroraでは、AWS KMSキー（AWSマネージドまたはカスタマーマネージド）を使用してデータベース作成時に保存時の暗号化を有効化する。Amazon DynamoDBはデフォルトですべての新規テーブルをAWS所有キーを使用して保存時に暗号化し、AWSマネージドまたはカスタマーマネージドKMSキーへのアップグレードオプションも提供する。AWS責任共有モデルの下では、AWSが暗号化機能を提供し、お客様がそれを有効にしてキーを選択する責任を持つ。

参考資料

• Amazon RDS: https://aws.amazon.com/rds/
• Amazon Aurora: https://aws.amazon.com/rds/aurora/
• Amazon DynamoDB: https://aws.amazon.com/dynamodb/
• Amazon ElastiCache: https://aws.amazon.com/elasticache/
• Amazon Neptune: https://aws.amazon.com/neptune/
• Amazon Redshift: https://aws.amazon.com/redshift/
• Amazon DocumentDB: https://aws.amazon.com/documentdb/
• Amazon Timestream: https://aws.amazon.com/timestream/
• Amazon MemoryDB for Redis: https://aws.amazon.com/memorydb/
• AWS Database Migration Service: https://aws.amazon.com/dms/
• AWS Schema Conversion Tool: https://aws.amazon.com/dms/schema-conversion-tool/
• AWS CLF-C02試験ガイド: https://d1.awsstatic.com/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf