VPCピアリングの「門番」を攻略せよ！セキュリティグループによるクロスアカウント制御の極意
こんにちは！インフラエンジニアとして日々クラウドの海を泳いでいるSREです。
AWSを触り始めると必ずぶつかるのが「VPC」という概念ですよね。最初は「一つの巨大な社内ネットワーク」として構築していても、規模が大きくなると「AプロジェクトとBプロジェクトでVPCを分けたい」「本番環境と開発環境は完全に分離したい」というニーズが出てきます。
そこで登場するのがVPCピアリング。二つのVPCを直接つなぐ「専用のトンネル」を作るようなものですが、ここで一番頭を悩ませるのが「セキュリティ」です。
今日は、その中でも少し高度で、かつ現場でめちゃくちゃ重宝する「セキュリティグループのクロスアカウント参照」について、郵便配達の仕組みに例えて優しく解説していきます。
—
1. VPCピアリングとセキュリティグループ、何が難しいの？
まず、VPCピアリングは「二つのVPCをまたぐトンネル」です。このトンネルを通るパケットをどう制御するか、これがインフラエンジニアの腕の見せ所です。
普通、セキュリティグループ（SG）でアクセス許可を出すとき、こんな風に書きますよね。
- 「IPアドレス
10.0.1.0/24からの通信を許可する」
これでも動きます。でも、もし相手のVPCでIPアドレスが変更になったり、サブネットが増えたりしたらどうでしょう？ルールを全部書き直さないといけませんよね。これでは管理が大変です。
そこで登場するのが「セキュリティグループIDによる参照」です。
—
2. 郵便配達で例える「セキュリティグループ参照」
イメージしてください。あなたは「Aさん（Webサーバー）」に手紙を届けたい「配達員（パケット）」です。
- IP指定の場合：
「住所が 10.0.1.5 の人に届けろ」という指示。引っ越し（IP変更）をしたら、配達員はもう届けられません。
- SG参照の場合：
「名札に『会員証（特定のセキュリティグループ）』を持っている人だけに届けろ」という指示。これなら、たとえその人が引っ越し（IPが変わる）をしても、名札さえ持っていれば正しく届けられますよね。
「IPアドレスという住所ではなく、名札という属性で制御する」。これがセキュリティグループ参照の神髄です。
—
3. クロスアカウントの壁を越える
さらに、相手が「別のアカウント」にある場合、単に名札を指定するだけではエラーになります。AWSは「他人から勝手に自分の家の門番（SG）を参照される」のを防ぐためです。
ここで必要なのが、「許可リスト（参照設定）」です。
設定の手順はたったの2ステップ
1. 受け手側（WebサーバーがいるVPC）： 「〇〇アカウントの、△△というセキュリティグループからの参照を許可するよ！」と設定する。
2. 送り手側（アプリケーションサーバーがいるVPC）： 「あっちのサーバーのセキュリティグループIDを指名して通信を許可する！」と設定する。
これだけで、たとえアカウントが違っても、安全かつスマートに通信を通すことができます。
—
4. 実践！CLIで設定してみよう
頭で理解したところで、実際に現場で使うコマンドの例を見てみましょう。
手順1：受け手側での許可設定
まずは、自分の家の門番に「あっちのアカウントからの訪問者は通していいよ」と伝えます。
# 受け手側のVPCで実行
# 相手のアカウントID（123456789012）からの参照を許可
aws ec2 authorize-security-group-ingress \
--group-id sg-0123456789abcdef0 \
--ip-permissions '[{"IpProtocol": "-1", "UserIdGroupPairs": [{"GroupId": "sg-9876543210fedcba", "UserId": "123456789012"}]}]'手順2：送り手側での通信許可
次に、自分のサーバーから「あのSGを持っている相手になら繋いでいいよ」と設定します。
# 送り手側のVPCで実行
# 相手のセキュリティグループIDを指定するだけ！
aws ec2 authorize-security-group-ingress \
--group-id sg-9876543210fedcba \
--protocol tcp \
--port 80 \
--source-group sg-0123456789abcdef0—
5. 現場のSREからのアドバイス
この手法、本当に便利で美しいのですが、いくつか注意点があります。
- 依存関係に注意： 参照されている側のセキュリティグループを削除しようとすると、エラーが出て消せません。「誰かに参照されている」という事実は、AWSがしっかりと管理してくれています。
- ピアリングの維持： もちろん、VPCピアリング自体が有効でないと通信は届きません。パケットは「ピアリングというトンネル」を通り、「セキュリティグループという門番」を通過する、という二段構えで考えてくださいね。
まとめ：なぜこれがベストプラクティスなのか？
IPアドレスをルールに書くと、ネットワーク構成が変わるたびに「穴あけ作業」が発生し、ミスも増えます。しかし、セキュリティグループIDによる参照を使えば、「関係性」を定義するだけで管理が完了します。
「住所」ではなく「人（役割）」で管理する。これこそが、クラウド時代のネットワーク設計の基本です。
最初は少し難しく感じるかもしれませんが、一度設定してしまえば、その後は環境の変化を恐れる必要がなくなります。ぜひ、次のプロジェクトで試してみてください。皆さんのインフラが、より堅牢でスマートなものになることを応援しています！
コメント