こんにちは、yassanです。
今回は、【入門】セキュリティグループ数の上限についての考え方【EC2】 を紹介します。
セキュリティグループには、最大1,000までの上限ルールがあります。
規模の大きい開発やセキュリティを細かく設定する場合は、この上限が意外と効いてきます。
今回は、そんなセキュリティグループの上限について紹介します。
申請方法とトラブルシューティングまで紹介してますので、今まさに困っている方もご参考ください。
セキュリティグループ上限の考え方について
AWS公式ドキュメントでは、下記の通りで紹介されています。
デフォルトのセキュリティグループの制限は増減できます。最大制限は、セキュリティグループごとのルールとインターフェイスごとのセキュリティグループという 2 つの制限に基づいて計算されます。ネットワークインターフェイスごとのセキュリティグループの制限にセキュリティグループごとのルールの制限を掛けた値は 1,000 を超えることはできません。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/increase-security-group-rule-limit/
たとえば、ネットワークインターフェイスごとのセキュリティグループの制限を 10 に増やす場合、現在の制限に基づいてセキュリティグループごとのルールの制限を 100 に変更して、最大制限を 1,000 に維持することができます。
要約すると、
セキュリティグループごとの最大ルール数 × EC2（厳密にはENI）あたりにアタッチするセキュリティグループの最大数 = 1,000 という計算になり、
この1,000という数字が上限となっています。
1,000という数字を超えなければ、掛け算の元となる数字は柔軟に変化可能です。
セキュリティグループごとの最大ルール数とは、1セキュリティグループあたりのインバウンドルール・アウトバウンドルールのことを指します。
デフォルトの最大ルール数は、60です。
上限緩和申請をすることで、50～300まで変更することができます。
セキュリティグループごとの最大ルール数は、インバウンドルールとアウトバウンドルールそれぞれ別々にカウントします。
例えば、最大ルール数が100の場合は、インバウンドルール・アウトバウンドルールそれぞれ100個のルールを設定することができます。
EC2あたりにアタッチするセキュリティグループの最大数は、文字通りアタッチするセキュリティグループの数です。
デフォルトの最大数は、5です。
上限緩和申請をすることで、3～16まで変更することができます。
理屈上は、下記の通りの使い分けになります。
| 各ネットワークインターフェイスのセキュリティグループ | 各セキュリティグループのルール | 各ネットワークインターフェイスのルールの合計 |
|---|---|---|
| 5 (デフォルト) | 60 (デフォルト) | 300 (デフォルト) |
| 10 | 100 | 1000 (最大) |
| 16 (最大) | 62 | 992 (最大) |
| 10 | 50 (デフォルトより低い) | 500 |
| 3 (デフォルトより低い) | 300 | 900 |
上限緩和申請について
では、実際に上限緩和申請をやってみましょう。
ここでは、例としてセキュリティグループの最大ルール数を60か100に変更してみます。
AWSマネジメントコンソールの右上のメニューから [Service Quots] を選択します。
一覧から [Amazon Virtual Private Cloud (Amazon VPC)] を選択します。
一覧から、[Inbound or outbound tules per security group] を選択し、[クォータの引き上げ申請] を選択します。
EC2あたりにアタッチするセキュリティグループの最大数の場合は、[Security groups per network interface] を選択します。
新たに設定したい上限数を記載して、 [リクエスト] を選択します。
これで申請は完了です。
僕の体感では、問題なければ30分~1時間程度で承認・適応されます。
トラブルシューティング
（諸事情により画面キャプチャはございません。ご了承ください。）
申請をしてもなかなか承認されない場合、上限を超えた申請をしている場合があります。
例えば、上記のセキュリティグループごとの最大ルール数を100にしたまま、
EC2あたりにアタッチするセキュリティグループの最大数を12に申請すると、計算上、100 × 12 = 1,200 で 1,000をオーバーしてしまいます。
その場合、申請後のステータスが「クォータの引き上げ」のまま止まってしまっています。
「クォーターの引き上げ」をクリックすると、詳細を確認することができます。
AWSサポートのIDが発行されているはずなので、AWSサポートのページでサポートメッセージを確認できます。
AWSサポートから、おそらく
「この申請内容では1,000の上限数を上回り、他のリソースに影響を与えるかもしれません。1,000を超えないように数字を調整してください」という内容のメールが来ているはずです。
AWSサポートの指示に従って、調整した数字を回答すると対応してくれますので、試してみてください。
以上となります。
ここまで読んでいただき、ありがとうございました！
AWS学習におすすめの書籍
AWSについて、しっかりと基礎から学びたい、実践的なスキルを身につけたいと考えている方向けに、おすすめの書籍を紹介します。
これらの書籍は、実際にAWSエンジニアとして働く僕が参考にしている書籍です。
AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ
AWSを使いこなすための前提となるITインフラの知識が足りない初学者にとって、どこからどのように学べばよいのかがわかりづらくなっています。そこで本書では、AWS学習サイト運営YouTuberである監修者自身が実サービスの導入で習得しながら体系化した「学習ロードマップ」に沿って、AWSのサービスとIT技術をやさしく解説していきます。
著者が作成した学習ロードマップに沿って、AWSやインフラストラクチャを体系的に学ぶことができます。
付属のロードマップの完成度が高く、学習に迷ったときや復習にも使えます。
これからAWSエンジニアを目指す方や、インフラストラクチャを基礎から学びたい方におすすめです。
Amazon Web Services 業務システム設計・移行ガイド
オンプレミス上に構築された業務システムをAWS上に移行するための「サービスの選定」「ネットワーク設計・構築」「サーバとデータの移し方」「運用・監視体制の構築」など。これまで多くの企業にAWSを導入し、コンサルティングフェーズから実際の設計・開発、運用フェーズまでの全行程に携わってきた著者陣のノウハウを凝縮して、一般的な企業にAWSを導入する際のベストプラクティスをお届けします。
実務を想定した様々なユースケースとそれに対するベストプラクティスを、設計構築から運用まで幅広くカバーして紹介しています。
タイトルからは移行に焦点を当てたように見えますが、僕としては移行に限らずエンタープライズとしてAWSを利用する上で知っておくべきことが記されていると思います。
より実践的な知識やノウハウを身に着けたい方、初学者から一皮むけたい方におすすめです。
