背景
EC2上にMariaDB（MySQL互換）を構築し、別のEC2からDB接続するハンズオンをコンソールで実施しました。ここで使った「SG参照（SG-to-SG）」という設定方法は、本番環境でも使われるセキュアな設計パターンです。
1. IP指定とSG参照の違い
IP指定: ソースに 123.456.78.901/32 を指定 → そのIPのみ許可
SG参照: ソースに sg-xxxxx を指定 → そのSGに属するEC2全体を許可
| 比較項目 | IP指定 | SG参照 |
|---|---|---|
| IPが変わった場合 | 設定変更が必要 | 自動的に制御（変更不要） |
| EC2を増やした場合 | 追加EC2のIPも個別設定が必要 | SGに追加するだけで自動許可 |
| 用途 | 自分のPCや外部サービスからの接続 | EC2間通信の制御 |
2. DBサーバのMySQLポートにクライアントSGを指定する
DBサーバSGのインバウンドルール:
タイプ: MySQL/Aurora
ソースタイプ: カスタム
ソース: my-ec2-mysql-client-sg （セキュリティグループを検索して選択）
ソースの入力欄にIPアドレスではなくセキュリティグループ名を入力すると、そのSGに属するEC2からの通信だけがマッチします。「クライアント役のEC2のセキュリティグループ」を作っておき、それをDBサーバ側のインバウンドルールのソースとして指定する、という2段構えの設計です。
3. 参照先のSGは先に作成する必要がある
③ クライアントSGを作成する（先に作成する必要がある）
④ DBサーバSGを作成する（③のSGを参照する）
DBサーバSGの作成時にクライアントSGを選択肢として指定するため、参照される側（クライアントSG）を先に作っておく必要があります。CloudFormationであればリソース間の依存関係は自動解決されますが、コンソールでは作成順序を自分で意識する必要があります。
4. 削除順序はSG参照の依存関係の逆順
① DBサーバSGを先に削除する
② クライアントSGを削除する
クライアントSGはDBサーバSGから参照されているため、参照している側（DBサーバSG）を先に削除しないと、依存関係エラーで削除に失敗します。作成時と削除時で意識すべき順序が逆になる点に注意が必要です。
5. EC2間通信はプライベートIPを使う
mysql -h 10.0.x.x -u handson -pHandson1234! sampledb
同じVPC内のEC2同士は、パブリックIPではなくプライベートIPで通信します。パブリックIP経由だと通信がインターネットを経由してしまい、セキュリティ上も効率上も好ましくありません。SG参照とプライベートIPはセットで使うのが基本形です。
まとめ
「IPではなくSGをソースに指定する」というSG参照の設計と、それに伴う作成・削除時の順序制約が、このハンズオンの核心でした。本番環境ではIP直接指定のルールは削除し、SG参照のみに絞るのがベストプラクティスです。UserDataによるMariaDBの自動セットアップ手順は元記事にまとめています。