背景
パブリックサブネット（APサーバ）とプライベートサブネット（DBサーバ）に分離した2層構成をAWSコンソールで手動構築するハンズオンをやりました。プライベートサブネットに置いたDBサーバでパッケージインストールが失敗するという、地味だけど本質的な問題に対処する内容です。
1. プライベートサブネットはインターネットへの経路を持たない
パブリックサブネット: ルートテーブルに 0.0.0.0/0 → IGW のルートあり
プライベートサブネット: インターネット向けルートを意図的に追加しない
DBサーバをインターネットから完全に隔離するため、プライベートサブネットのルートテーブルにはインターネットゲートウェイへのルートを追加しません。この結果、DBサーバは外部との通信が一切できない状態になります。
2. その代償としてdnf installが失敗する
Amazon Linux 2023のパッケージリポジトリは実はS3上にホストされています。プライベートサブネットのEC2はインターネットに出られないため、UserDataでのdnf install -y mariadb105-serverが失敗し、DBサーバにMariaDBがインストールされないという事態が起こります。
3. S3 VPC Gateway Endpointで解決する
サービス: com.amazonaws.ap-northeast-1.s3（タイプ: Gateway）
ルートテーブル: プライベートルートテーブルにチェック
S3向けだけインターネットを経由せずアクセスできるGateway Endpointを作成し、プライベートルートテーブルに紐付けます。作成後にルートテーブルの「ルート」タブを確認すると、S3向けのルートが自動追加されていることが分かります。この設定だけで、プライベートサブネットのままパッケージインストールが可能になります。Gateway Endpointは無料という点も実務で採用しやすいポイントです。
4. APサーバを踏み台にしてプライベートサブネットのDBサーバへSSH接続する
# ローカルPCからAPサーバへキーペアをコピー
scp -i key.pem key.pem ec2-user@(APパブリックIP):~/.ssh/
# APサーバ上でパーミッション設定
chmod 400 ~/.ssh/key.pem
# APサーバからDBサーバへSSH接続
ssh -i ~/.ssh/key.pem ec2-user@(DBプライベートIP)
プライベートIPしか持たないDBサーバには直接SSH接続できません。パブリックサブネットにあるAPサーバを経由地点（踏み台/Bastion）として使い、まずAPサーバにキーペアをコピーしてから、APサーバ内から改めてDBサーバへSSH接続する、という2段階の手順になります。
5. DBサーバSGはAPサーバSGへの参照で守る
DBサーバSG インバウンド:
SSH(22) ソース: my-ap-sg（SG参照）
MySQL(3306) ソース: my-ap-sg（SG参照）
DBサーバのSGは、SSH・MySQLともにソースをIPアドレスではなくmy-ap-sg（APサーバのSG）で指定します。これにより「APサーバに割り当てられたSGを持つインスタンスからの通信のみ」を許可でき、DBサーバへの経路をAPサーバ経由に限定できます。
まとめ
プライベートサブネットの「インターネットに出られない」という制約が、パッケージインストールの失敗という具体的な形で現れる点と、S3 VPC Gateway Endpointによる無料での解決策がこのハンズオンの核心でした。踏み台SSH接続とSG参照の組み合わせは、実際のAWS本番環境でも標準的なDBサーバ保護パターンです。