Azure側はエンドポイントのACLでしかアクセス制御ができませんでしたが、
いよいよAzureでもセキュリティグループの考え方が登場したので、比較してみました。
簡易比較表
| 観点 | AWS | Azure |
|---|---|---|
| 名称 | Security Groups | Network Security Groups (NSG) |
| アタッチ対象 | インスタンスに対して適用 （EC2、RDSなど） |
サブネット、インスタンスに適用可能 |
| アタッチ対象への上限数 | 5個 | 1個 （サブネットとインスタンスに1個ずつアタッチ可能） |
| ルール数上限/SG | 50個 | 200個 |
| Default設定(In) | All-deny | VnetからはAll-allow、 インターネットからはAll-deny |
| Default設定(Out) | All-allow | All-allow |
| 設定方法 | Management Consoleで設定可能 （もちろんコマンドからの可能） |
Powershellコマンドレットからのみ設定可能 |
| 上限緩和 | 可能 （Management Consoleから） |
可能なはず （ソース見当たらず…） |
考察
どちらのセキュリティグループもステートフル（入力が許可されれば応答は保証される）とのこと。
Azureのセキュリティグループの設定方法はAWSのNetwork-ACLっぽいので、もしかしたらスレートレスなのかも、
と思いましたが、杞憂だったようです。
AWSでは、送信元や送信先にセキュリティグループのIDを指定できますが、AzureではCIDRのみ指定可能です。
AzureはVNet内通信は全許可なので、SourceIPとかdestinationIPにセキュリティグループを設定するケースがないのかな、と想像しました。
（AWSでは、同じVPC内であっても明示的に許可しなければ通信できないので、そういった需要がでてくるのかな）
また、注意点として、Azureのセキュリティグループは、エンドポイントACLとの共存はサポート外のようです。
セキュリティグループを使う場合は、事前にエンドポイントACLは削除しておきましょう。
まとめ
AWSのセキュリティグループとNetwork-ACLがひとつにまとまっているのが、Azureのセキュリティグループ
という印象です。
明示的な許可設定が必要なのがAWS。間違っても出て行かないように、という、
安全側に倒す設計方針は、AWSの基本理念が垣間見えます。
明示的に拒否する必要があるAzureと、明示的に許可する必要があるAWS。
どちらがよいかは、それぞれのシステム構成や要件によりけりかな、と思います。
これだけでAWSかAzureかと決定するようなことはないと思いますが、
移行などをする場合は、考え方の差によってセキュリティホールになる可能性があるので（特にAzure）、
認識しておいて損はないと思います。
＊認識誤り、追加情報あればご指摘ください！