2026-08-26（水）RDS (Aurora), S3 (Glacier)

1. 【この範囲の全体像】

本範囲は、AWSが提供する主要な「データストア」の目的別アーキテクチャの選定境界を学ぶ極めて重要なエリアです [p.126]。

基幹業務を支えるトランザクション処理（OLTP）に最適な RDS (Aurora) [p.126, p.135]、ペタバイト級の大規模分析（OLAP）に特化した Redshift [p.138]、そして低コストでの長期保管に特化した S3 Glacier [p.103] のそれぞれの特性を正しく理解する必要があります。

試験では、「データの性質」と「要求されるアクセス速度・コスト制約」から、最もベストプラクティスに適合する組み合わせを見抜く力が問われます [p.128]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
リレーショナルデータベース (RDB) [p.126, p.127]	データを表形式（テーブル）で表現し、SQLを用いて厳格な一貫性を持つトランザクション（OLTP）を処理するデータモデル。代表例は Amazon RDS や Amazon Aurora [p.126, p.127]。
NoSQLデータベース [p.127]	キー値（Key-Value）やドキュメントなど柔軟なスキーマを持ち、高い水平スケーラビリティと超高速な応答性能を実現するデータベース。代表例は Amazon DynamoDB [p.127, p.143]。
Amazon Aurora [p.135, p.136]	クラウド向けに最適化して再設計された、AWS独自の高性能リレーショナルデータベース。3つのAZにまたがって計6つのデータコピーを自動作成する高可用ストレージ（最大128TBまで自動拡張）を備え、ミリ秒単位でのフェイルオーバーに対応 [p.135, p.136]。
Amazon Redshift [p.138, p.139]	大規模データ（ペタバイト級）の集計・分析（DWH：データウェアハウス）に特化したマネージドサービス [p.138]。データを列単位で管理する「列指向型（カラムナ）アーキテクチャ」を採用し、不要なディスクI/Oを極限まで減らして集計処理を高速化する [p.139]。
Redshift Spectrum [p.142]	Amazon S3のバケット上にあるデータを、Redshiftクラスターに物理ロードすることなく、外部テーブルとして定義して直接SQLクエリを実行する拡張機能。容量コストの削減と柔軟なアドホック分析を両立する [p.142]。
S3 Glacier ストレージクラス群 [p.103, p.104]	データのアクセス頻度や取り出し可能速度（ミリ秒〜最大12時間）に応じて、保管コストを極限まで引き下げるためのアーカイブ専用ストレージクラス（Instant / Flexible / Deep Archive） [p.103, p.104]。

3. 【試験で問われる比較ポイント】

① トランザクション処理（RDS / Aurora） vs 大規模データ分析（Redshift） [p.126-128, p.138, p.139]

比較項目	Amazon RDS / Amazon Aurora [p.126, p.135]	Amazon Redshift [p.138, p.139]
主な処理対象	OLTP (オンライン取引処理) [p.126]	OLAP (オンライン分析処理) / DWH [p.138]
データ構造	行指向（ローデータ単位の素早い更新・参照に最適） [p.126]	列指向（カラムナ：特定の列の合計や平均などの集計に特化） [p.139]
得意なユースケース	ECサイトの決済処理、ユーザーのアカウント登録、在庫管理 [p.126]	過去数年分の売上トレンドのバッチ集計、ログの統計解析 [p.138, p.139]
スケールの方向性	主に垂直スケール（スケールアップ）またはリードレプリカ分散 [p.58, p.132]	リーダーノードとコンピューティングノードの増設（並列スケールアウト） [p.138]

② S3 Glacier 3つのアーカイブクラスの使い分け [p.103]

比較項目	S3 Glacier Instant Retrieval [p.103]	S3 Glacier Flexible Retrieval [p.103]	S3 Glacier Deep Archive [p.103]
取り出し所要時間	ミリ秒単位（即時取り出し可能） [p.103]	数分〜数時間 [p.103]	最大12時間（もっとも遅い） [p.103]
容量単価	3つの中では高め（低頻度アクセス Standard-IA と同等） [p.103]	中程度 [p.103]	最安（AWSで最も低いデータ保管コスト） [p.103]
最低保管期間	最低90日間（早期削除ペナルティあり） [p.103]	最低90日間 [p.103]	最低180日間（長期保存が前提） [p.103]
決定的な選定基準	「アクセスは年に数回だが、必要時は即座（ミリ秒）に取り出したい」 [p.103]	「1年に数回の監査時などに、数時間待ってからバッチ取得できればよい」 [p.103]	「法的なコンプライアンス等で7年〜10年以上、データを極めて安価に眠らせておきたい」 [p.103]

4. 【ひっかけ注意ポイント】

ひっかけ①：過去ログの大規模な集計処理に対して「RDSインスタンスのスケールアップ」で解決させる罠 [p.58, p.138, p.139]
- 罠パターン: 「数テラバイトにおよぶ過去の履歴データをRDSに蓄積して集計クエリを実行しているが、処理時間がかかりすぎている。インスタンスタイプをスケールアップしてCPUを強化する設計が最適である。」
- なぜ間違いか: トランザクション用のRDS（行指向）は、テーブルの全行を走査して特定の列（例：売上の合計）を計算する際、不要な列データまで全てディスクからメモリにロードするためディスクI/Oがボトルネックになります。いくらCPUを強化しても根本解決にはなりません [p.128, p.139]。
- ベストプラクティス: 大規模データのバッチ集計が必要な場合は、列ごとにデータを保持し不要なI/Oを発生させない Amazon Redshift へデータを移行（またはロード）するのが正解です [p.138, p.139]。
ひっかけ②：S3 Glacier Deep Archive 内のオブジェクトを直接・即時に別アプリケーションへ配信できるとする罠 [p.103]
- 罠パターン: 「コストを極限まで下げるため、Webサイトにたまに表示する過去動画を S3 Glacier Deep Archive クラスへ遷移させた。ユーザーからの動画リクエストがあった際、S3から即時に読み出して配信するように設計する。」
- なぜ間違いか: Glacier Flexible Retrieval および Deep Archive 内のデータは、「アーカイブ状態（冷えた状態）」にあるため、S3のAPI（GetObject）を直接実行して即時読み取ることは物理的に不可能です [p.103]。
- ベストプラクティス: これらからデータを読み出すには、あらかじめ一時的にアクティブなストレージ層（S3 Standardなど）へ複製（復元・リストア）するためのリクエスト（最大12時間待機）を実行しなければなりません [p.103]。ミリ秒単位の即時取り出し性能を維持しながらアーカイブコストを下げたい場合は、必ず Glacier Instant Retrieval を指定する必要があります [p.103]。
ひっかけ③：書き込みクエリの処理遅延ボトルネックを「RDSのリードレプリカ増設」で解消する罠 [p.132, p.133]
- 罠パターン: 「アプリケーションからの書き込み（INSERT/UPDATE）リクエストが急増してデータベース（RDS）が過負荷になっている。書き込み処理性能を高めるために、複数のリードレプリカを作成した。」
- なぜ間違いか: 前述の通り、リードレプリカは仕様上「参照（Read）専用」であり、非同期でマスターからデータを受け取るクローンです。アプリケーションから書き込み処理をリードレプリカへルーティングしても、書き込みは実行できずエラーになります [p.132, p.133]。
- ベストプラクティス: 書き込みスケーラビリティが限界に達した場合は、RDSの前段に Amazon SQS などの非同期キューを挟んでバッファリングする設計（デカップリング）を適合させます [p.220]。