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）、
認識しておいて損はないと思います。

＊認識誤り、追加情報あればご指摘ください！