今日はAWSとAzureのどちらかばかり触ってると「あれっ！？」ってなる文化の違いについて
VMインスタンスを作ると、インスタンス毎にどんなアクセスを許可／拒否するかっていうファイヤーウォール設定をリソース毎に設定してく感じになるんですが、その設定プロパティをAWSではVPCの「セキュリティ グループ」とか、Azureでは「ネットワーク セキュリティ グループ」とかって呼びます。
考え方や制御する内容は、大体一緒なんだけどもリソースを作成した際に自動設定されるデフォルト設定とそのデフォルト設定の捉え方が若干違うよって話です。
デフォルトのセキュリティグループポリシー
?AWSは拒否、Azureは許可
別にAWSのことが嫌いって話じゃないです?(笑)
デフォルト生成されるセキュリティグループでは、AWSリソースのインバウンド設定は全て拒否になっているということです。
逆に、Azureのインバウンド設定は全て許可になってます。
また、リソース作成時に自動作成されるデフォルト設定に関する考え方もそれぞれ違います。
?AWSは削除可、Azureは削除付加
- AWSのデフォルト セキュリティ グループは削除することができます。
⇒ セキュリティ グループの定義がすべて削除されると、すべて拒否されて何も通信ができない状態になります。
前提が全て拒否なので、許可ルールしか設定できません。必要な通信のみを定義します。
- Azureのデフォルト ネットワーク セキュリティ グループは削除することができません。
⇒ デフォルト設定を削除できないので、それより強い優先度の定義を作って上書きして設定していくことになります。
優先度を使って、許可／拒否のルールの上書きして適切な権限を設定します。
どちらがいいという話ではないんだけども、AWSはよりFW的な権限付与の発想で、AzureはActive Directory的な権限付与の発想なのかなー？って感じがしますよね。
勉強しながらリソースコネコネしてる時には、リソース立てる毎に確認しながらやってくので滅多にハマりませんが、いざ構築をフロー化して流れ作業でやろうとした時にはここら辺の脳みその切り替えができてないで、うっかりAzure脳でAWSの構築指示したらAWSリソースが何もトラフィック受け付けてくれない！！?ってなったりする訳です。
まー普段から両方の構築をゴリゴリやるってケースはそんなにないかもしれないけども、どちらも使ってるって企業は増えてると思うので心の片隅に留めておきましょう?