[！] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
クラウドコンピューティングサービスでは、同じ用語で同様の機能が提供されていても、仕様の異なる部分が少なくありません。この投稿では、Amazon Web Services (AWS) ⧉、Microsoft Azure (Azure) ⧉、Google Cloud Platform (GCP) ⧉ のネットワーク構成と通信制御の方法について比較していきます。
用語説明
クラウドで定番の用語が頻出するので、はじめに用語の説明を記載します。既に理解されている方は、次項のネットワーク構成にお進みください。
VPC / VNet
用途ごとの単位で作成する仮想ネットワークです。AWS、GCP では VPC(Virtual Private Cloud)、AzureではVNet(Virtual Network)と呼ばれます。1つのVPC/VNetは複数の「サブネット」というネットワークで構成されます。
一般的な使い方としては、VPC/VNetは大まかな用途単位（顧客向けサービス用、イントラネット用など）で作成して、細かいネットワーク要件（インターネットと直接通信を許可するか、しないか）の違いをサブネット単位で制御する、といったケースが考えられます。
リージョン
サービスを提供している地域です。各クラウドとも、世界中にリージョンを展開しています。各クラウドのリージョン詳細については、以下をご覧ください
AZ / ゾーン
リージョンの中にある論理的な区分で、データセンターを抽象化した概念です。AWS と Azure では AZ (Availability Zone)、GCP ではゾーンといいます。クラウド事業者やリージョンによっても異なりますが、1つのリージョンに2～4つの AZ / ゾーンが存在します。1つの AZ / ゾーンは、1つもしくは複数のデータセンターから構成されています。
複数の AZ / ゾーンにサーバー等をあらかじめ冗長化しておくことで、耐障害性や可用性を確保できます。停電や災害の影響で１つの AZ / ゾーンが停止しても、別の AZ / ゾーンで自分たちのサービスを提供できます。このような冗長構成は、Multi-AZ と呼ばれることもあります。
ネットワーク構成
ここから本題です。各クラウドのネットワーク構成の違いや特徴について見ていきます。
AWS
AWS では、リージョンの中に VPC が存在して、AZ の中にサブネットが存在します。VPC とサブネットの両方に、IP アドレス範囲（CIDR ブロック）を割り当てる必要があり、サブネットの IP アドレス範囲は、VPC の IP アドレス範囲の中から切り出して割り当てます。
Azure
Azure では、リージョンの中に VNet とサブネットがあります。AWS と異なり、サブネットは AZ をまたいで作成できます。VNet とサブネットの両方に IP アドレス範囲を割り当てる必要がある点は、AWS と同様です。
GCP
GCP では、VPC がグローバルな存在で、リージョンの中にサブネットがあります。サブネットは、Azure と同様にゾーンをまたいで作成できます。VPC に IP アドレス範囲を割り当てる必要はなく、サブネットにのみ割り当てます。
ネットワーク構成の比較
各クラウドのネットワーク構成を比較してみると、以下の3点がポイントと考えます。
- AWS のサブネットが AZ の中に存在する
- GCP の VPC がグローバルである
- IP アドレス範囲の追加を VPC / VNet で行うか、サブネットで行うか
AWS のサブネットがアベイラビリティゾーンの中に存在する
複数の AZ でサーバーやサービスを冗長化するには、AZ 毎にサブネットを用意する必要があります。作成に手間がかかるようなら、定番の構成をテンプレート化しておくと楽です。
また、（滅多にないことですが）新設された AZ を使う場合にもサブネットの新規作成が必要です。新しいサーバータイプやサービスが特定の AZ から提供開始されることもあるので、長期利用が計画されている VPC では IP アドレス範囲に余裕を持たせておくといいかもしれません。
GCP の VPC がグローバルな存在
複数の国や地域でのサービス提供を視野に入れている場合でも、1つの VPC で対応できるのがメリットです。例えば、ロードバランサーの下に異なるリージョンのサーバーを配置して、リクエストをグローバルに分散させられます。AWS や Azure で実現するには、他のネットワーク系サービスを組み合わせる必要があります。
IP アドレス範囲の追加を VPC / VNet で行うかサブネットで行うか
AWS と Azure では、VPC / VNet に IP アドレス範囲を追加してネットワークを拡張します。GCP では、サブネットの新規作成で簡単に IP アドレス範囲を追加できます。GCP の VPC は、複数のサブネットをまとめて管理する存在として、ネットワークの拡張や設計変更に柔軟性があると言えます。
なお、他のネットワークと VPN 接続等をしている場合、IP アドレス範囲の追加によって相手先のルートテーブルを見直す必要がある点は、どのクラウドサービスでも共通です。
比較
AWS、Azure、GCP それぞれのネットワーク構成をまとめたものが次の図になります。
通信の制御
続いて、各クラウドの VPC / VNet における通信制御方法の違いについて、見ていきます。
AWS
AWS の通信制御には、セキュリティグループ ⧉とネットワーク ACL ⧉ という2つの方法が用意されています。セキュリティグループは仮想マシンに割り当てるルールで、ネットワーク ACL は、サブネットに割り当てるルールです。セキュリティグループは、送信元や宛先に IP アドレスや CIDR ブロックのみならず別のセキュリティグループやプレフィックスリスト ID も設定できます1。
セキュリティグループとネットワーク ACL について、注意点が2つあります。
- セキュリティグループは許可ルールのみ設定できる
- ネットワーク ACL はステートレス ⧉、セキュリティグループはステートフル ⧉
セキュリティグループは許可ルールのみ設定できる
拒否ルールは設定できません。特定の IP アドレスからの通信をサーバー単位で拒否したい場合は、許可ルールを組み合わせることで拒否を実現するか、ネットワーク ACL でサブネット単位ルールを設定します。
ネットワーク ACL はステートレス、セキュリティグループはステートフル
ネットワーク ACL では、戻りの通信も ACL のルールに従うので、明示的に許可を設定する必要があります。セキュリティグループでは、戻りの通信が設定に関係なく許可されます。
厳格なトラフィック制御のためにネットワークACLを採用するか、ルールの複雑化を防ぐためネットワーク ACLを使わずセキュリティグループのみで制御するか、通信要件と運用管理の双方を考慮して方針を決めておくと良いでしょう。
Azure
Azure の通信制御には、ネットワークセキュリティグループ ⧉（NSG) があります。NSG は、仮想マシンとサブネットの両方に割り当て可能で、ステートフルなルールです。許可と拒否のルールを設定できるため、AWS に比べて分かりやすいです。送信元や宛先には、IP アドレス、CIDR ブロック、サービスタグ、アプリケーションセキュリティグループを設定できます2。
GCP
GCP の通信制御には、ファイアウォール ⧉があります。ファイアウォールは、VPC、仮想マシン単位で設定できます。送信元や宛先には、IP アドレス範囲、ネットワークタグ、サービスアカウント ⧉のうち、IP アドレス範囲と他2つを組み合わせてルールを書きます。ステートフルなルールで、許可と拒否の両方のルールを設定できます3。
通信制御の比較
各クラウドの通信制御を比較してみると、以下のような違いがあります。
- AWS には、許可のみ設定できるセキュリティグループと、ステートレスなネットワーク ACL という2種類のルールがある。
- Azure と GCP には、タグが付与されているリソースに対して制御できるルールがある。
- GCP は、VPC 単位で制御できる。
以下の図で、各クラウドサービスの通信制御機能を設定する単位ごとにまとめてみます。
まとめ
AWS、Azure、GCPのネットワークについて比較してみました。ネットワーク構成と通信制御の比較を表にまとめると以下のようになります。
| AWS | Azure | GCP | |
|---|---|---|---|
| VPC に IPアドレス範囲の設定 | 必要 | 必要 | 不要 |
| VPC の単位 | リージョン | リージョン | グローバル |
| サブネットの単位 | AZ | リージョン | リージョン |
| サブネットの通信制御 | ネットワークACL | NSG | ファイアウォール |
| インスタンスの通信制御 | セキュリティグループ | NSG | ファイアウォール |
クラウドでインスタンス、コンテナ、関数のいずれを使う場合でも VPC / VNet 上で動かすので、ネットワークは重要な存在です。デフォルトの VPC / VNet 上なら簡単に使えるサービスでも、インターネットとの通信を制限したプライベートサブネット上ではサービス側のネットワーク要件を満たすために追加的な対応が必要なこともあります。クラウドサービスによって細かい仕様は異なるので、ネットワーク設計の段階から意識しておきたいところです。
参考
Footnotes
