パブリッククラウドのネットワークについて比較をしてみた

ネットワーク名称

これから各クラウドでのネットワーク構成、料金、通信制御を比較していきたいと思いますが、その前に各項目においての名称を図にして分かるようにしました。

ネットワーク構成

Alibaba Cloud

VPC：リージョン内に作成が可能
CIDR: VPCとサブネットに設定が可能
サブネット：アベイラビリティゾーンの中で作成が可能

上記はVPCにvRouterとCIDR ブロック、vSwichで構成されているオーソドックスなアーキテクチャとなります。vSwitchはサブネットに該当しVPC内に複数のvSwitchを作成してネットワークを分けていくイメージです。

vRouterはVPC内のゲートウェイでVPC内に1つのみ作成されます。

または、VPC 内の VSwitch の最大数は24個となっており、上限の申請は可能ですが設計時には注意が必要です。

AWS

VPC：リージョン内に作成が可能
CIDR:　VPCとサブネットに設定が可能
サブネット：アベイラビリティゾーンの中で作成が可能

AWSでもVPCを定義し、その配下でサブネットリソースを指定しています。しかしAWSではサブネットでパブリック、プライベートという区分けがあります。基本的な違いはグローバルネットワークから通信が可能か否かですが、もっぱらパブリックサブネットにアプリケーションのサーバを設置します。対してプライベートサブネットにはDBサーバを置き、NATゲートウェイなどを介してグローバルネットワークに接続することが多いです。

ほかのクラウドと比較すると各項目が細かく分けられていますね。最小限のネットワーク設計をVPCで設計してより拡張したい場合は別のネットワークサービスをカスタマイズすることで拡張性が広がるといったところでしょうか。

Azure

VNet：リージョン内に作成が可能
CIDR:　VNetとサブネットに設定が可能
サブネット：アベイラビリティゾーンをまたいで作成が可能

Azureはサブネットがゾーンをまたぐことができるのが特長です。

ですので、ゾーンを移動する際に同じIPを利用することも可能でしょう。

Google Cloud

VPC：リージョンをまたいで作成が可能
CIDR:　サブネットにのみ設定が可能
サブネット：ゾーンをまたいで作成が可能

Google CloudのVPCは、ネットワークの設計思想がほかのクラウドと大きく異なっています。その理由としては、VPCがリージョンにまたがる形式で構成されているからです。これはGoogleのグローバル展開を意識している一番の特長といってもいいのではないでしょうか。一方でネットワーク設計時にはIPレンジが重複しないような工夫が必要かと思われます。

クラウドネットワーク構成の所感

Alibaba CloudとAWSはオーソドックスなネットワーク構成が読み取れました。

Azureにおいても基本的な設計思想は大きく異なりませんでしたが、サブネットがアベイラビリティゾーンをまたげるという特長がありました。

Googleにおいては設計思想の違いが顕著にみられ、デフォルトでリージョンとサブネットを定めれば、複数リージョンにまたがるサブネットが作成されるというのは想定しているユーザや規模がほかのクラウドと異なるのではないかと思われます。

通信制御方法

次に各クラウドのVPC・VNetにおける通信制御の方法について比較していきましょう。

こちらも違いがみられるのでしょうか？

Alibaba 

Alibabaではセキュリティグループが仮想のファイアウォールとして機能しインスタンス間でのトラフィックをコントロールします。設定としてはインバウンド及びアウトバウンドのアクセスを「許可」または、「禁止」するルールを設定するオーソドックスな形式となっています。そしてセキュリティグループには「Basic」と「Advanced」の2種類が存在します。

「Advanced」ではエンタープライズレベルのシナリオに適しており、より多くのインスタンス、エラスティックネットワークインターフェース（ENI）、およびプライベートIPアドレスを含めることができ、基本的なセキュリティグループよりも厳密なレベルのアクセス制御を実装可能です

AWS 

AWSのセキュリティ設定として、セキュリティグループとネットワークACLと、大きく分けて2種類存在します。

違いを以下に示します。

セキュリティグループ

• EC2インスタンス単位で適用
• ホワイトリスト形式
• ステートフル

※Incoundの通信が許可されれば、Outboundの通信は自動的に許可されます。

ネットワークACL

• サブネット単位で適用
• ブラックリスト形式
• ステートレス

※Inboundの通信、Outboundの通信を個別で設定をする必要があります。例えば、行きの通信が許可されていても戻りの通信で拒否されていれば通信が失敗します。

セキュリティグループでは「許可ルール」のみの設定となり、「拒否ルール」は設定ができないため注意が必要となっています。

Azure 

Azureではネットワークセキュリティグループで通信制御を行います。

対象は仮想マシン・サブネット両方に設定が可能です。設定単位としては、1つのNetwork Interfaceやサブネットに対して、ネットワークセキュリティグループも1つづつです。本筋とは脱線しますが、Azure Storageのストレージアカウントというストレージを利用する場合のリソースを用いることでフローログを作成することが可能となり、リソース間におけるトラフィックの分析を実施することができ非常に便利です。参考までにMicrosoftの公式資料を掲載しておきます。

ネットワーク セキュリティ グループのフローのログ記録の概要

Google Cloud

Google Cloudの通信制御にはファイアウォールを用います。ファイアウォールもAzureのネットワークセキュリティグループ同様に、仮想マシン、VPC単位で設定が可能です。

サービスアカウントという特定のユーザではなく仮想マシンなどに使用する専用のアカウントの存在がGoogle Cloudにはあり、ほかクラウドにも存在するタグの利用と使い分けることが可能です。

通信制御の比較・所感

各クラウドの通信制御方法を比較してみました。AWSにおいてはVMとサブネットで異なるサービスを使い分ける必要がありそうです。

しかしながら全体的には名称が異なるとはいえ、大きな仕様の差は見られませんでした。

比較表

まとめ

ここまで各クラウドのネットワーク周りについて見てきました。ここまで纏めてきた所感としては、GoogleCloudはほかクラウドと比較して特長がみられたがそれ以外は大きな差は見られなかった。しかし、ハイブリッドクラウドでのネットワーク設計を考えるうえで、今回ご紹介したような基本的な考え方を知っておくのは重要だと、あらためて認識することができました。次回は各クラウドの専用回線について比較してみようと思ってます。専用回線も名称が違いますが機能差があるのか細かい点まで見ていきたいと思っていますので、よろしければ見ていただけると幸いです。

関連サービス