今回は、AWSのセキュリティグループ（以降、SGと表記）/ネットワークACL（以降、ACLと表記）と
AzureのNSGの違いについて記載します。
■はじめに
AWSのSGとNACL、AzureのNSGについて少し触れておきます。
[AWSのSecurityGroupとNetworkACL]
・SGはNICもしくはEC2インスタンス/ALB/RDS等に対してアタッチします。
・ACLはサブネット（セグメント）に対してアタッチします。
[Azure]
・仮想マシンもしくはサブネット（セグメント）に対してアタッチします。
書き始めたばかりですが、この時点ですでに
「AWSでのSG/ACLの構成パターンも多岐にわたるし、AzureのNSGも関連付け先によって構成パターンが多岐にわたるから、比較したい項目を事前に定義しておかないと、比較にならないな」って思ったわけです。。。
なので今回は、仮想マシン（のNIC）にアタッチする時を想定して比較していこうと思います。
■混乱を招く理由
SGやACL/NSGを作成するだけであれば、それほど迷わずに作成できます。
混乱を招くのは、下記３点かと。
１．作成したSGにインバウンドルール（SG）を設定、NSGに受信セキュリティ規則を設定する時
２．設定したルールの評価方法について
３．NICに対して複数SGをアタッチ、複数NSGをアタッチした場合について
上記１：作成したSGにインバウンドルール（SG）を設定、NSGに受信セキュリティ規則を設定する時
インバウンドルール（SG）/受信セキュリティ規則（NSG）の作成画面を見ることで違いが分かりやすくなりますので、そちらを紹介します。
【SGのインバウンドルール作成画面】
タイプ： EC2へのインバウンド通信を許可するタイプ（SSHやHTTP、RDP等）を選択します。カスタムを選択することで任意のポートを指定できます。
プロトコル： 「カスタムプロトコル」を選択しない限り、自動で入力されます。
ポート範囲： 宛先となるポート/ポート範囲を指定します。ウェルノーウンポートであれば自動的に入力されます。（SSHなら22、RDPなら3389、等）
ソース： 送信元の情報を記載します。
どこからでもアクセスOKであれば「任意の場所（0.0.0.0/0）」を選択。
CIDR/IPアドレス/SGを明示的に指定したい場合には「カスタム」を選択
これらの項目を指定して、NIC（ENI）に関連付けます。
EC2が許可しているポート番号と、許可したい送信元を定義してます。
重要なのは「許可」する「送信元」を定義しているところです。
【NSGの受信セキュリティ規則の作成画面】
AWSのSGと似たような項目を設定できます。
しかし、クラウド環境をAWSから触った私としては、
「何故、宛先まで記載するんだ！？」ってなるんですよ。。。
宛先ポートは、SGでも指定するから理由はわかります。
NSGにアタッチするのはNICかサブネットなので、必然的に宛先はNICかサブネットとなり、AWSと同じように考えるなら「宛先情報は不要なのでは！？」って思ってました。
なので、現場の方にこの疑問をぶつけてみたところ、以下のような返答が。
＝＝ここから＝＝
AzureのNSGの場合、一つのルールでより多くの情報を使ってフィルタリングすることができるので、サブネット単位にアタッチしやすいとのことでした。
具体的には、サブネットの中に複数台の用途が違うサーバが存在する際、宛先はサーバ単位となり、明示的にサーバのIPアドレスを指定する必要があるとのことでした。
AWSのSGは、NIC単位に関連付けることが決まっている為（＝サブネットに定義するならACLを使うため）、ルールで宛先を指定する必要はない。
＝＝ここまで＝＝
なるほどって思いました。
AzureのNSGは、AWSのSGとACLを合わせた機能として実現しているため宛先情報が必要になるんだな、と。
上記２：設定したルールの評価方法について
【AWSのSG】
SGはホワイトリスト形式のため、許可したい通信情報をルールに定義します。
定義したルールはすべて走査（評価）されます。
定義が重複した際は拒否のほうが優先されます。
ルールに記載のない通信は拒否されます。
デフォルトでは何も定義されていないため、EC2は通信できません。
【AzureのNSG】
ホワイト形式ではなく、L3スイッチやルータのアクセスコントロールの考えに近いです。また、デフォルトで設定されているルール（優先度65000,65002,65500）は削除不可です。
定義したルールは優先度が若い順に走査され、マッチした時点で、それ以降の優先度のものは評価されずスキップされます。
SGとの大きな違いです。
上記３：NICに対して複数SGをアタッチ、複数NSGをアタッチした場合について
【Azureの場合】
出鼻をくじく形になりますが、NSGはNICに複数アタッチできません。
仮想マシンのNICをみてみると、一つしかアタッチできないようになっています。
つまり、Azureの場合には仮想マシンのNICに紐づくNSGは必ず一つです。
よって、一つのNSGですべてのルールを定義します。
【AWSの場合】
SGは一つのNICに対して複数アタッチできます。（上限は5つまで）
また、複数アタッチされているSGは全て走査されます。
そのため、SGを用途ごとに分けることで管理しやすくなります。
例）HTTP/HTTPS通信用のSG、SSH接続用のSG、等
長くなりましたが、以上です。
