2026-08-28（金）RDS (Aurora), S3 (Glacier)

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

本範囲は、AWSが提供する耐久性に優れたオブジェクトストレージであるAmazon S3 / S3 Glacier [11, p.101] と、高可用・高性能なデータベースサービスであるAmazon RDS / Amazon Aurora [11, p.129, p.135] の総復習セクションです。

試験では、耐久性とコスト効率を最大化するS3の各種ストレージクラス選定やライフサイクル管理 [11, p.103, p.104]、高可用なデータベース設計の王道であるRDSのMulti-AZとリードレプリカの使い分け [11, p.131, p.132]、そして画期的な分散共有ストレージ構造を持つAuroraの機能特性について、シナリオに基づいたロジカルな設計判断能力が問われます [11, p.135, p.136]。

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

キーワード	説明
Amazon S3 (Simple Storage Service) / S3 Glacier [11, p.101]	物理的に離れた3つのAZへ自動的にデータを同期複製し、99.999999999%（11ナイン）の超高耐久性を備えた、容量無制限のオブジェクトストレージ [11, p.101, p.102]。
ライフサイクル管理 [11, p.104]	オブジェクトの作成後の経過日数に応じて、ストレージクラスを段階的に自動移行（移行アクション）させたり、自動削除（有効期限アクション）したりしてコストを最適化する管理機能 [11, p.104]。
オブジェクトロック [11, p.105]	データの削除・上書きを防止するWORM（Write Once, Read Many）機能 [11, p.105]。管理者でもポリシー解除ができない「コンプライアンスモード」と、特定のBypass権限があれば解除可能な「ガバナンスモード」があります [11, p.105, p.106]。
署名付きURL (Presigned URL) [11, p.110]	AWSアカウントやIAM権限を持たない外部ユーザーに対し、期限付きの一時的なセキュリティ認証情報を提供して、S3オブジェクトの安全なアップロードやダウンロードを限定的に許可するURL [11, p.110]。
S3 Transfer Acceleration [11, p.112]	CloudFrontのグローバルエッジロケーションを経由して、インターネット経由での遠隔地からS3バケットへのデータアップロードを高速化・安定化させる機能 [11, p.112]。
S3 Select / Glacier Select [11, p.112]	SQL文を使用して、S3に格納されたオブジェクト（CSVやJSON）から必要な一部のレコード行や列データのみを直接フィルタリング抽出して返す機能 [11, p.112]。データ転送量と後段の処理スループットを劇的に改善します [11, p.112]。
Amazon RDS (Relational Database Service) [11, p.129]	フルマネージドなリレーショナルデータベース [11, p.129]。自動バックアップやマイナーパッチ適用など、構築・管理の大部分をAWS側が自動で担います [11, p.129]。
Multi-AZ（RDS） [11, p.131]	プライマリAZ障害に備え、別AZへ待機インスタンス（スタンバイ）を「同期複製」で配置する高可用性・災害復旧（DR）設計 [11, p.131]。障害時はDNSレコードが自動的に書き換えられ、アプリ側コードを変更することなく自動フェイルオーバーします [11, p.131]。
リードレプリカ（RDS） [11, p.132]	マスターDBの負荷を抑える目的で配置する、参照専用の複製インスタンス（最大5台） [11, p.132]。データ複製は「非同期」で行われ、参照負荷のスケールアウトや、必要に応じたプライマリDBへの昇格に対応します [11, p.132]。
Amazon Aurora [11, p.135]	AWSがクラウドネイティブに最適化設計したデータベース [11, p.135]。3つのAZにまたがる共用のクラスターボリュームへ6つのデータコピーを自動保持し、最大15台のレプリカ拡張や30秒未満の高速フェイルオーバーを実現します [11, p.135, p.136]。
クラスターエンドポイント（Aurora） [11, p.136]	Auroraクラスターに接続する際、データの書き込み（Write）を担当するプライマリインスタンスへ自動接続するための単一の接続窓口（FQDN） [11, p.136]。
リーダーエンドポイント（Aurora） [11, p.136]	Auroraレプリカ群への読み取り（Read）処理接続を全自動でロードバランシング（負荷分散）するための参照専用のエンドポイント [11, p.136]。

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

① 予算とアクセス頻度に基づくS3ストレージクラスの決定境界 [11, p.103]

ストレージクラス	最小保管日数	取り出し速度・遅延	試験で出題される選定キーワード [11, p.103]
S3 標準 [11, p.103]	なし	即時（ミリ秒）	🎯 「頻繁にアクセスされるアクティブデータ、Web静的アセット、開発中のファイル」
S3 標準-IA [11, p.103]	30日間	即時（ミリ秒）	🎯 「アクセス頻度は低いが、いざ必要になった際にはミリ秒での即時アクセスが必須なバックアップ」
S3 Intelligent-Tiering [11, p.103]	なし	即時（ミリ秒）	🎯 「アクセスパターンが予測不可能、または絶えず変化するデータを、運用負荷なしで自動コスト最適化したい」
S3 One Zone-IA [11, p.103]	30日間	即時（ミリ秒）	🎯 「 1つのAZのみに格納（耐障害性は低い）。他データから容易に再生成できる、最もコストを抑えたい二次データ」
S3 Glacier Instant Retrieval [11, p.103]	90日間	即時（ミリ秒）	🎯 「年に数回しかアクセスしない長期アーカイブだが、取り出し時にミリ秒単位の即時返却が必須な場合」
S3 Glacier Flexible Retrieval [11, p.103]	90日間	数分〜数時間	🎯 「一般的なデータアーカイブ・災害復旧（DR）データ。数分から数時間の取り出し猶予が許される最安級ストレージ」
S3 Glacier Deep Archive [11, p.103]	180日間	12時間以内	🎯 「年に1〜2回アクセスするかどうか。法的な長期監査データなどで、取り出しに12時間待てる最安のストレージクラス」

② DB高可用・負荷分散の決定境界：RDS Multi-AZ vs リードレプリカ [11, p.131, p.132]

比較項目	RDS Multi-AZ [11, p.131]	リードレプリカ (Read Replica) [11, p.132]
主な役割・動機	高可用性（HA）の確保と障害復旧（DR：災害対策） [11, p.131]。	読み取り（参照）アクセスのパフォーマンス拡張 [11, p.132]。
データの同期方法	同期レプリケーション（スタンバイ側への書き込み完了を待つため、整合性が100%担保される） [11, p.131]。	非同期レプリケーション（プライマリへの書き込み後に順次複製。わずかに反映ラグが発生する） [11, p.132]。
インスタンスの稼働数	アクティブDB（直接接続可能）は1台のみ。スタンバイDBは直接接続不可（待機状態） [11, p.131]。	すべてのレプリカ（最大5台）に直接読み取り接続可能。各レプリカを個別にスケール可能 [11, p.132]。
障害時の挙動	プライマリ障害時にスタンバイへ全自動でフェイルオーバー（DNS自動書き換え、アプリ変更不要） [11, p.131]。	プライマリ障害時に自動フェイルオーバー先には選ばれない（手動またはスクリプトでプライマリに昇格させる必要あり） [11, p.132]。
決定的な選定シグナル	🎯 「データベースサーバーが物理被災した際、手動の切り替え操作なしに数分以内で自動的にシステム復旧させたい」 [11, p.131]	🎯 「 BI分析ツールやユーザーからの大量のSELECTクエリによって、マスターDBのCPU使用率が飽和している」 [11, p.132]。

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

ひっかけ①：VPC内のプライベートなEC2からS3バケットへの大容量データ転送に「NATゲートウェイ」を配置する罠 [11, p.37, p.107, p.302]
- なぜ間違いか（コスト最適化の観点）: NATゲートウェイは「処理されたデータ転送量（1GBあたり）」に対して従量課金が発生します [11, p.302]。毎日テラバイト（TB）クラスの巨大データをNAT経由で転送させると、データ処理料だけで莫大なインフラコストが請求されてしまいます。
- ベストプラクティス: 「 S3用のVPCエンドポイント（ゲートウェイ型：Gateway Endpoint） 」をVPCのルートテーブルにデプロイします [11, p.107]。ゲートウェイエンドポイントは、データ処理にかかる従量課金が完全無料であり、AWSのバックボーン（閉域網）を直接ルーティングするため、コストとパフォーマンスの双方において極めて優れた絶対のベストプラクティスとなります [11, p.107]。
ひっかけ②：本番稼働している既存の「非暗号化RDSデータベース」をオンラインのまま暗号化有効に設定変更する罠 [11, p.134]
- なぜ間違いか（セキュリティ設計の制約）: RDSの仕様上、一度「非暗号化」で作成・デプロイされた既存リレーショナルデータベースを、後からオンライン設定変更で暗号化有効へ直接一発変換することはできません [11, p.134]。
- ベストプラクティス: 以下の手順を正確に踏む必要があります [11, p.134]：
  1. 稼働中RDSデータベースの 「手動DBスナップショット」を取得 する [11, p.134]。
  2. そのスナップショットを 「暗号化を有効化」に設定して新規にスナップショットとしてコピー（暗号化複製） する [11, p.134]。
  3. 暗号化された新規スナップショットから 「新規DBインスタンス」として復元（リストア） させ、接続先を切り替えた上で古い非暗号化DBを安全に破棄する [11, p.134]。
ひっかけ③：S3で独自ドメインの静的Webホスティングを行う際、「バケット名」を任意のわかりやすい名前に設定する罠 [11, p.108]
- なぜ間違いか（S3 Webサイトホスティングの仕様制限）: S3をWebサーバーとして独自ドメイン公開（※CloudFrontを使用しないダイレクトな公開）する場合、「S3のバケット名」と「公開したい独自ドメイン名（完全修飾ドメイン名：FQDN）」が1文字違わず完全に一致していなければならない という強固なルール制限があります [11, p.108]。バケット名がドメインと異なると、DNSでの名前解決が正常にS3バケットを特定できず通信エラーを招きます。
- ベストプラクティス: www.my-company.com でサイトを公開する場合は、必ずバケット名も www.my-company.com という名前で作成する必要があります [11, p.108]（※ただし、前段にAmazon CloudFrontを配置して独自ドメインHTTPS化を組む場合は、この名前一致制限は不要となり、自由なバケット名で構築できます [11, p.108, p.161]）。