週4RDS / S3

2026-08-23（日）RDS (Aurora), S3 (Glacier)

この記事の目次
  1. 予習ポイント
  2. 図解イメージ（言葉で説明）
  3. 視聴後に自分でチェックしたい項目

1. 【予習ポイント】

  • データベース専用のセキュリティ障壁：「パブリックアクセス無効」の必然性 [p.38, p.50-51, p.134]
    • 理由: データベース（RDS等）には企業の最も機微なデータが格納されるため、インターネットから直接アクセス可能なグローバルIPアドレスを決して付与してはなりません [p.134]。データベースインスタンスは「プライベートサブネット」に隔離配置し、インターネットゲートウェイ（IGW）への直接のルーティング経路を排除します [p.38, p.50-51]。これにより、外部インターネット側からの直接の不正ハッキングや標的型攻撃を物理的に遮断するのが、AWSにおける絶対的なセキュリティベストプラクティスです [p.38, p.134]。
  • セキュリティグループの「相互連携（SGターゲット指定）」による最小権限の通信制御 [p.36, p.134]
    • 理由: データベースを守るセキュリティグループ（SG-DB）のインバウンドルールにおいて、特定の個別IPアドレス（例：10.0.1.50）を送信元として静的にルール登録するのは、EC2の再起動やAuto Scalingによる自動スケーリングでIPが変わった際に通信が切断される原因となります [p.36, p.68]。
    • 設計の解決策: 「Webサーバー用のセキュリティグループ（SG-Web）がアタッチされているインスタンスからの通信のみ、DB専用ポート（MySQLなら 3306、PostgreSQLなら 5432）でのアクセスを許可する」という、「セキュリティグループのID自体（例: sg-xxxxxx）」を送信元ターゲットに設定するマッピング技術を適用します [p.36, p.134]。これにより、EC2のIPアドレスが動的に増減・変動しても、通信許可設定が自動かつ安全に維持されます [p.36]。
  • 「マルチAZ（同期）」と「リードレプリカ（非同期）」の決定的な仕様・目的の違い [p.131-132]
    • マルチAZ（高可用性）: 1つのリージョン内の異なる2つのアベイラビリティゾーン（AZ）に、メインとなる「マスターDB」と待機用の「スタンバイDB」をそれぞれ配置し、データを「同期レプリケーション（同時書き込み）」して冗長化します [p.131]。マスターに物理障害が発生した際は、接続先FQDN（DNSレコード）がスタンバイのIPアドレスへ自動的に瞬時に書き換わり、アプリケーションを停止させずに自動フェイルオーバー（60〜120秒で完了）を行います [p.131]。
    • リードレプリカ（性能のスケールアウト）: 参照（検索）専用のDBインスタンスを別途追加し、データを「非同期レプリケーション」します [p.132]。読み込み（SELECT）クエリが極めて多いアプリケーションにおいて、マスターDBの処理負荷を下げて参照性能を分散拡張させる目的でデプロイします [p.132, p.133]。

2. 【図解イメージ（言葉で説明）】

「難攻不落の巨大お城の中にある『絶対開かない宝物庫』と、暗号鍵を持つ『お城の受付（Webサーバー）』の連携劇」

インターネットを通じて訪れるユーザーが、なぜ直接アクセスすることなく、EC2（Webサーバー）を介して安全にプライベートデータベースからデータを引き出せるのか、身近なお城の防衛網に例えて説明します。

  1. お城の外壁（パブリックサブネット ⇔ EC2上のWebサーバー） [p.38]: お城の外周である「パブリックサブネット」に、城外の一般市民（ユーザー）が唯一直接アクセスして対話できる「案内窓口（EC2上のWebサーバー）」が立っています [p.38]。この窓口は、敵の侵入に備えるため、窓口専用の「頑丈な鎧（セキュリティグループ SG-Web）」を身に纏って防御しています [p.36]。
  2. 地下深層の開かずの宝物庫（プライベートサブネット ⇔ パブリックアクセス無効のRDS） [p.38, p.134]: お城の最重要の台帳（顧客データ）が保管されている 「 RDSデータベース 」 は、要塞の地下深くにある隔離された部屋「プライベートサブネット」に格納されています [p.38]。この地下室には、外の世界（インターネット）から直接つながるハシゴや扉（パブリックIP）が最初から一切存在しません（パブリックアクセス無効） [p.38, p.134]。
  3. 鉄壁の関所（セキュリティグループ連携） [p.36, p.134]: 地下の宝物庫の扉の前には、厳重な「鉄格子のセキュリティ扉（データベース用のセキュリティグループ SG-DB）」が設置されています [p.36]。この鉄格子の認証センサーには、「 外壁の鎧（SG-Web）を身につけた本物の案内窓口（EC2）からの、合言葉（3306番ポートなど）のみを自動で通過させる 」 という、特別なセキュリティロックが施されています [p.36, p.134]。
  4. 案内人による代理取り出し（EC2からのSQLデータベース接続検証） [p.134]: 外の一般市民（ユーザー）が「自分のデータを取り出してほしい」と窓口に依頼すると、案内窓口（EC2）が代理としてこの鉄格子の扉を通過し、データベース（RDS）からデータを安全に引き出して、外の市民へ安全に手渡します [p.134]。データベースが直接外の脅威に晒されることは、これによって100%回避されます [p.134]。

3. 【視聴後に自分でチェックしたい項目】

  • ⬜︎ チェック1: 作成したRDSのネットワーク構成で「パブリックアクセス可能（Publicly Accessible）」が「なし（No/無効）」に設定されているか？ [p.134]
    • この設定により、データベースにインターネット経由で到達できるパブリックIPアドレスが割り当てられず、完全に隔離されたプライベートネットワーク閉域内にデプロイされていることを、AWSコンソール画面上で視認して確認できたか？ [p.38, p.134]
  • ⬜︎ チェック2: RDSデータベース側のセキュリティグループ（SG）のインバウンドルールに、EC2の「セキュリティグループID（例：sg-xxxxxx）」が送信元として正しく記述されているか？ [p.36, p.134]
    • EC2のローカルプライベートIPを静的に記述するのではなく、セキュリティグループID同士をマージさせる（紐付ける）ルールを適用することで、EC2のスケーリングや再起動時にも自動で通信が追従できる仕組みを理解できたか？ [p.36]
  • ⬜︎ チェック3: EC2インスタンス（Amazon Linux）にSSHでリモートログインし、データベース接続コマンド（例: mysql -h [RDSエンドポイント] -u admin -p）を実行した際、正常に認証プロンプトが表示されてログインが確立できたか？ [p.56, p.134, p.136]
    • もし接続がタイムアウト（接続失敗）してしまう場合、EC2のセキュリティグループのアウトバウンドルール、またはRDSのセキュリティグループのインバウンドルールのポート解放制限（3306ポート等）に設定不備がないかデバッグ確認できたか？ [p.36, p.134]
  • ⬜︎ チェック4: 今回の実習は無料利用枠のためシングル構成で作成したが、実際の企業の本番システムで可用性を担保するために必須となる「マルチAZ配置」のフェイルオーバーの仕組みを説明できるか？ [p.28, p.131]
    • 「スタンバイDBはアクティブにクエリを処理せず裏側で待機しており、マスター障害時に自動でDNSレコード（FQDN）が書き換わることで、アプリ側の接続先変更を伴わずに自動切り替えが行われる」プロセスを論理的に説明できるか？ [p.131]

📊 予習資料の整理が完了しました。ネットワーク（VPC）の境界設計と、データベース（RDS）へのアクセス制限を組み合わせるこの実習は、本試験における最も重要かつコアな「セキュアな設計（30%）」の実践そのものです！