本記事はネットワークウィーク 5日目の記事です。
💻 4日目 ▶▶ 本記事 ▶▶ 6日目 🌐

はじめに

こんにちは、クラウド事業推進部の関谷です！早いもので中途入社して5ヶ月が経過しました。私は前職でAzureを扱っていた経験が長いので、今回のネットワークウィークにちなみ、現在業務で使用しているAWSと過去に業務で触れたことのあるAzureのネットワーク制御サービスを比較していきたいと思います。

AWS・Azureの基礎的ネットワークサービス

AWSのネットワークサービス

今回比較の対象とするAWSのサービスは以下の2つです。

セキュリティグループ(以下、SG)

SGの特徴は許可ルールのみを定義するホワイトリスト型の使用方法とステートフルな制御を行うリソースだということです。また、インスタンス単位に適用するのが基本的な使用方法です。

ネットワークアクセスコントロールリスト(以下、NACL)

NACLの特徴としてはSGと対称的に許可・拒否両方のルールが定義可能で、ステートレスな通信制御を行うということです。また、SGとは役割が異なりサブネットに適用します。

docs.aws.amazon.com

Azureの基礎的ネットワークサービス

Azureで見ていくのは以下のサービスです。

ネットワークセキュリティグループ(以下、NSG)

NSGはAWSのSG・NACL両方の要素が取り込まれているといえるかと思います。許可・拒否ルールが定義可能な点はNACLに近い感覚かと思います。一方で、ステートフルな制御を行うという点においてはSGと近い関係です。適用対象についてはSGの主な適用先となるインスタンスやNACLの適用先となるサブネット単位と両方に対応しています。

learn.microsoft.com

基本的な特徴を比較してみて

AWSについてはそもそもSGとNACLという二つのサービスが準備されており、使い方についてもSGはインスタンスごとにきめ細かく制御を行い、NACLでネットワーク単位で粗く制御をすることで深層防御の役割を果たすというコンセプトが打ち出されています。

一方でAzureのNSGを見てみると、SGとNACLの両方の特徴がミックスされているようで、ネットワークのレンジ単位に適用してもよし、インスタンスに紐づくIPアドレス単位に適用してもよしというサービスの自由度があるように感じます。その裏返しとも言えますが、運用する側が自律的に運用のルールを明確にしていく必要があるのではないかとも思います。

ネットワークサービス比較表

サービス名	AWS-セキュリティグループ (SG)	AWS-ネットワークアクセスコントロールリスト (NACL)	Azureネットワークセキュリティグループ (NSG)
ステートフル/ステートレス	ステートフル	ステートレス	ステートフル
許可/拒否ルール	許可のみ（ホワイトリスト）	許可・拒否両方可能	許可・拒否両方可能

初期設定を比較してみる

基本的な特徴を見ましたが、両社のサービス設計思想にも少し触れてみたいと思います。特にサービスの初期設定には各クラウドベンダーがどのような意図を持ってユーザに使ってほしいのかが表れていると考えます。そこで、各サービスの初期設定内容を比較してみます。

初期設定比較表

サービス名	AWS-セキュリティグループ (SG)	AWS-ネットワークアクセスコントロールリスト (NACL)	Azure-ネットワークセキュリティグループ (NSG)
初期設定（受信）	自身のSGからの通信のみ許可	すべて許可（ルール番号100）→すべて拒否（*）	VirtualNetwork内通信・LoadBalancer通信を許可→その他拒否
初期設定（送信）	すべて許可	すべて許可（ルール番号100）→すべて拒否（*）	VirtualNetwork通信・インターネット通信を許可→その他拒否

AWSのネットワーク制御リソース初期設定

AWSには仮想的なネットワークサービスであるVPCがあります。そのVPC作成時に自動でSGとNACLを作ってくれます。(個別に作成も可能)

上記の表の内容だけだとわかりにくいですが、SGとNACLの設定内容は、受信・送信ともにネットワーク的に開放されており(NACLによる制御)、インスタンス的に送信は自由で、受信は同じSGに属するリソースからのみ受け取る(SGによる制御)と表現できます。

Azureのネットワーク制御リソース初期設定

Azureは仮想的なネットワークのサービスであるVirtual Networkとは独立してNSGを作成する必要があります。

NSGの設定内容は受信・送信ともに同じVirtual Networkに属している場合は自由に通信が可能かつLoadBalancerなど連携するサービスとの通信も可能という表現になります。また、NSGはそれ以外の通信を最終的に拒否するように明示的に設定されています。

各社の初期設定への考察

AWSについてはInbound通信がSGによって制限されていますが、Outboundについてはほぼ無制限な状態なので、作成直後から外部接続が可能で、手軽に使用が開始できる印象です。

一方、AzureのNSGについては内部ネットワーク間の通信は許可されていますが、外へ出るには明示的に管理者側で許可する必要があるので使用開始にはひと手間必要になります。

この違いからAWSについてはネットワーク内のリソース(EC2など)を使用する際の障壁が低く、アプリ運用者にとっても手軽に使用できる。一方Azureについては早期の段階からネットワーク管理者がルール管理に介入しないと使用できない印象を受けます。

その意味でAWSは、アプリ主導でリソースをセットアップし、自社サービスを開始した段階で、最低限の制御は行われているので、そこからセキュリティ面をより精緻にしていくという使い方に適しているのではないかと考えます。

Azureはネットワーク制御ルールを初期の段階で変更せざるを得ない初期設定であることから管理者が早期に入ることを前提とし、ある程度ネットワークの骨組みを検討したうえでサービスの開始をしていく使い方に適しているのではないかと考えます。

この点については筆者の考えのため、読者のみなさんにもぜひ考察いただければ幸いです！

最後に

今回はAWSとAzureのネットワーク制御サービスの初期設定や設計思想の違いについてご紹介しました。それぞれのクラウドが持つ思想やユースケースの違いを知ることで、より適切な設計ができるようになるのではないでしょうか。今後もこうした比較を通じて、クラウドへの理解を深めていければと思います。最後までお読みいただきありがとうございました！