クラウド仮想マシン比較解説まとめ

最終更新 2021-03-02

• 2021/03/02：スポットVM に Azure Spot Virtual Machines を追加 (2020/05 より)。これにて AWS・Azure・GCP すべてスポット VM が利用可能となりました。
• 2020/09/26：ベアメタルについて情報を最新化。
• 2020/04/08：インスタンスのゾーン変更・移動 について追記。

クラウドの仮想マシンサービス Amazon EC2・Azure Virtual Machine・Google Compute Engine を機能・料金・管理など様々な観点から比較します。

仮想マシンとは

いわゆる IaaS を、ここでは仮想マシンと呼ぶことにします。クラウドサービス各社より、下記の名称で仮想マシンが提供されています。

• Amazon では EC2 (Amazon Elastic Compute Cloud)
• Azure では仮想マシン (Virtual Machine、VM)
• GCP では Google Compute Engine (GCE)

管理画面からのボタン操作により、Linux や Windows のマシンを立ち上げることができ、 そこの Apache + PHP で Web システムを作ってもいいし、 バッチサーバとしてもいいし、 MySQL 等をインストールして DB サーバとしてもよい。

レンタルサーバや AWS に慣れた人には「仮想マシン的なものはどのクラウドサービスにもあるはず」と 思うでしょうが、そういうわけでもありません。Azure にも GCP にも、当初 IaaS はなく、PaaS だけだったのです。

仮想マシン・IaaS 比較表

各社の IaaS・仮想マシンについて、様々な観点から比較します。

以下、詳細を説明していきます。

料金・課金・コスト・費用 詳細説明

課金単位 について

Amazon EC2 の課金は 2パターンあります。

• Amazon が提供する無料系 OS、具体的には Amazon Linux・Amazon Linux 2・Ubuntu については秒単位課金。しかしながら最低でも 1分の課金が行われる。30秒使ったら 1分の課金、1分20秒使ったら 1分20秒の課金。
• 上記以外の OS、具体的には RedHat Enterprise Linux (RHEL)・SUSE・Windows Server と、 AWS Marketplace で入手できるものは 1時間単位。

なんだか複雑ですが、ずっと 1時間単位課金だったものが 2017/10 より上記のように部分的に秒単位課金となったので、一歩前進ではあります。

Google Compute Engine は、OS を問わず秒単位・最低 1分ですので、 コスト面では AWS よりお得ですね。

Azure Virturl Machine は、さらにお得な分単位切り捨てです。Azure のサイトに「6分45秒なら課金対象は 6分」とはっきり書いてあります。30秒だけ使ったら 0秒扱いになるのかは判断できませんが、 起動におおむね 3〜4分かかるため、30秒だけ使えることはまずありえないので、 気にしないことにしましょう。

継続利用割引 について

Google Compute Engine には「継続利用割引」という仕組みがあり、 申込み不要で、1ヶ月間使い続けると 30% 割引となります。詳細は こちら。AWS・Azure にはこのような仕組みはありません。

リザーブによる割引 について

AWS・Azure・GCP いずれも、 「しばらくこのインスタンスを使うことを約束するから、その分安くして」 という値引きがあります。詳細は こちら。

スポット VM について

AWS ・Azure・GCP いずれも、 「常に使えるとは限らない、突然落ちるかもしれないけど、安い」 というインスタンスがあります。

• AWS の EC2: スポットインスタンス
• Azure の Azure Spot Virtual Machines (2020年5月より開始)
• GCP の Compute Engine: プリエンプティブ VM インスタンス

詳細は こちら。

管理画面操作 詳細説明

管理画面からの起動について

これは言うまでもなくですが、管理画面から仮想マシンを起動することができます。

作成時のステップ数について

仮想マシン作成時のステップ数を数えたところ、下記のとおりでした。

• AWS: 6ステップ
• Azure: 16ステップ
• GCP: 2ステップ

AWS と GCP の差は、OS やインスタンスタイプを選択しなければならない AWS と、 デフォルトで決まっていて変更する場合は画面操作をする GCP との違いです。GCP が不親切という考え方もあると思いますので、一長一短です。

しかしながら Azure の場合、16ステップ。名前・ユーザ名・パスワード・リソースグループ名などを入力しなければならなかったり、 初期表示される「おすすめインスタンス」が、なぜか全て月額10,000円超え！ 「すべて表示」を選んで、1画面で3個しか表示されない画面をスクロールさせつつ、 60個以上あるインスタンスから安いものを選ばなければならない (最小 CPU で絞り込みはできるので高いインスタンスサイズは簡単に絞りこめるが、 最大 CPU では絞り込みできないので、安いインスタンスを探す人は地道にスクロールしないといけない)。→ このひどい UI は、今はなおっているとどこかで読んだので要調査 (2018/6)

もう少し簡単に作業できるようにしてほしいものです。

管理画面からの OS ログイン について

AWS の場合、Mindterm という Java な SSH クライアントでログインが可能です。IE・Firefox・Safari では使用可能です。Chrome では NPAPI が廃止されたので使えません。Java 環境の事前インストールが必要です。ログイン ID は、Amazon Linux であれば “ec2-user”、Ubuntu であれば “ubuntu” と初期アカウント名が固定されているので、それを使います。

Azure の場合、Linux は ssh でログインしてねと表示されるだけです。インスタンス作成時に自分で作成したログインIDと、自分で指定したパスワード (または自分で指定した秘密鍵) でログインする必要があります。Windows の場合も、RDP ファイルがダウンロードできますが、ID・パスワードは自分で入力します。

GCP では、Linux の場合、ブラウザから ssh ログイン (Linux の場合) が可能です。ログイン ID もパスワードも入力することなくログインできますので、すごくラクです。ログイン ID もパスワードもなしで、どうやってログインするかというと、 OS アカウントについては、自身の Google アカウント名と同じログイン ID が自動生成されます (hoge@gmail.com であれば、Linux アカウントとして hoge アカウントが作成されるということ)。パスワードは使用せず、自動生成された ssh 鍵でログインが行われます。繰り返しますが、ID・パスワードについて何も覚える必要がないので、本当にラクです。

GCP での Windows インスタンスの場合は、管理画面からアカウント発行が行えます。指定した ログイン ID でアカウント作成が行われ、パスワードが自動生成されるのでメモしておきます。ログインには Windows 付属のリモートデスクトップを使ってもいいですし、 Chrome であれば「Chrome RDP for Google Cloud Platform」という Chorme 拡張があるので、 それを使うとブラウザ上で完結させることができます。

管理・メンテナンス 詳細説明

停止時のインスタンスタイプ変更

インスタンスを停止してのインスタンスタイプを変更することは AWS・Azure・GCP とも可能です。例えば Amazon EC2 であれば、 t2.micro から m3.large に変更することで、CPU やメモリ量を変更することができます。

起動中のインスタンスタイプ変更

一方で、起動中のインスタンスタイプの動的な変更は、AWS・Azure・GCP ともできません。VMware などは動的なメモリ・CPU コア数変更に対応していたはずですので、 できないことはないと思います。頑張ってほしいものです。

リージョン変更・移動

一度インスタンスを作成すると、リージョンの変更はできません。例えば米国から東京に移動することはできません。東京を大阪に変更することもできません。

リージョンを変更したい場合は、別リージョンに新規で作り直しとなります。基本的には、まずインスタンスのイメージを作成し、別リージョンにイメージをコピーし、別リージョンでイメージを元に新規インスタンスを起動する、という手順になります。

ゾーン変更・移動

GCP のみ、インスタンスのゾーンを変更することができます。例えば us-central1 には a・b・c・f のゾーンがありますが、us-central1-a を us-central1-b・c・f などに変更することができます。

ただし、インスタンスにローカル SSD がつながっていると NG とか、コマンドラインまたは API からしかできない (コンソールからは不可) など多少の制約があるため (2020/4現在)、△ としました。

詳細は こちら。

ライブマイグレーションについて

ライブマイグレーションは Google の Compute Engine が持つ、「仮想マシンを再起動することなく (動作させたまま)、現在のホストから新しいホストに移動する」という機能です。ライブマイグレーション後もプロセスは生きたままですし、ネットワークコネクションも切れないし、 メモリもディスクもマイグレーション前と同じです。正確に言うと、「一瞬」止まるらしいですが、ネットワークデータの取りこぼしは発生しません。

AWS・Azure の場合、たまに「再起動を伴う仮想マシンメンテナンス」といったお知らせが来ます。例えば「信頼性向上のメンテナンスのため 10/1〜10/10 の間、順次強制再起動します。それに先立ち、9/20〜9/30 の間にお客様にて手動で再起動いただくことで、 その後の強制再起動を避けることが可能です」的な通知です。

Google の場合、このようなお知らせがありません。Google にてライブマイグレーションを使い、裏側で実施してくれています。2015年の HeartBleed のときもそうですし、2018年年初早々の CPU 脆弱性のときもそうでした。CPU 脆弱性の際、Azure は強制再起動の前倒しでバタバタしていましたが、 Google は「もう終わってますよ」という感じでした。

セキュリティ関連のアップデート以外でも、下記のような故障時にもライブマイグレーションが使われているそうです。

• Google によるインフラのメンテナンス・故障対応
• メモリ不良・ディスク不良・電源不良・ネットワークカード不良
• OS・BIOS のアップグレード

new! 2018/04/12 2018/4 より、下記コマンドでライブマイグレーションを意図的に起こせるようになりましたので、 ぜひ試してみてください。

gcloud beta compute instances simulate-maintenance-event

なお、正確に言うとこれはメンテナンスイベントを発生させるだけで、 VM の設定でライブマイグレーションを有効にしていればライブマイグレーションしますし、 無効にしていればインスタンスは終了します。ライブマイグレーションの際は、数円〜数百円程度の費用がかかります (メモリ量や SSD サイズ量次第)。

「起動時間」について

インスタンス作成から利用可能になるまでの時間を計測しました (2017/12 調べ)。

• AWS: 3分〜4分20秒
• Azure: 3〜4分
• GCP: 16〜27秒

管理画面で Linux 系 OS を最安または次に安いインスタンスタイプ上で作成し、 完了となるまでの時間を目で調べる、 というのをそれぞれ5回程度試したものなので正確性はありませんが、 それにしても GCP の Google Compute Engine (GCE) が圧倒的に速い、 というのは確実かと思います。

「シリアルコンソール」について

例えば /etc/fstab の修正をミスしたり iptables の設定をしくじって接続できなくなった場合、 OS の起動が失敗してしまいます。オンプレミスであればシングルユーザモードで起動したり、 さくらインターネットの VPS などではシリアルコンソールでレスキューモードにするなどの方法で復旧ができます。

ではクラウド 3サービスはどうかというと、Azure・GCP ではブラウザ上でシリアル接続が可能です (Azure VM のシリアル接続は 2018/6 現在、パブリックプレビュー)。一方 AWS ではシリアル接続はできないようです。

注意点ですが、Azure VM + Linux の場合、普通にインスタンスを作成すると root パスワードが未設定となります。通常利用時は一般ユーザでログインして sudo で root 権限を得るので root パスワードがなくても問題ないのですが、 シリアル接続でログインする場合、root パスワードが必要ですので、 トラブルが発生する前にあらかじめパスワードを設定しておかないと、シリアル接続しても打つ手なしとなってしまいます。

GCP の Compute Engine ではデフォルトはシリアル接続無効となっていますので、 gcloud コマンドを使ってシリアルポートを有効化します。その後、ブラウザ・gcloud コマンド・一般的な ssh クライアントなど、いろいろな方法でシリアル接続が可能です。ブラウザであれば鍵は不要ですが、ssh クライアントの場合は ssh 鍵を使います (よって事前の root パスワード設定は不要です)。ただしこのシリアル接続を有効にすると外部 IP アドレスからログインが可能になってしまいます (正しい SSH 認証鍵・ユーザ名・プロジェクト ID・ゾーン・インスタンス名を把握していれば接続できてしまう)。GCP の場合は必要なときのみシリアルポートを有効化し、使い終わったら無効化するのがよいでしょう。

ちなみにシリアル接続ができない AWS の EC2 場合、/etc/fstab の修復はどうするかと言うと、 EC2 を落とし、該当のファイルが含まれる EBS を EC2 から デタッチし、 別 EC2 を作成し、そこに EBS をアタッチし、OS からマウントし、ファイルを修正し、EBS をデタッチし、 元の EC2 にアタッチし、EC2 起動、です。めんどくさいですねぇ。なお、Azure VM もシリアル接続がなかった時代には似たような流れを踏む必要がありました (EC2 の 3倍くらいめんどくさかった)。

「自動シャットダウン」について

お試しで仮想マシンを起動したいときがあります。そしてもう不要なのに削除し忘れて余分な請求が来てしまうことはもっとあります。Azure の場合、新規インスタンス作成時に下記のような設定項目があり、 毎日何時に自動シャットダウンするかを設定することができます。

また、シャットダウン前の通知としてメールを送信することができます。届いたメール (下記画像参照) には、シャットダウン予定である旨の通知と、 「1時間延長」「2時間延長」「今回のシャットダウンをスキップ」のリンクがあり、 クリックすることで延長やスキップさせることもできます (無視すればそのままシャットダウン)。

なぜか新規作成時には表示されないようですが、インスタンス作成後に自動シャットダウンの項目からたどると、 Webhook URL を指定することもできるので、Slack や Azure Logic Apps に連携することもできます。下記画像は Slack への通知例です。

★GCE に schedule-based-scheduling が追加。

専有・ベアメタル 詳細説明

専有 について

ベアメタル について

ベアメタル (Bare Metal) とは、もともと「ハードウェアはあるがソフトウェアは入っていない」という意味でハードディスクや筐体に対して使われる言葉でした。クラウド界隈においては「仮想化を実現するためのソフトウェアが入っていない、素の OS だけが入っているサーバ」という意味で使われます。

Hyper-V・Xen・VMware 等が入っていないサーバなので、下記の利点があります。

• 仮想化ソフトウェアが入っていないので、高速
• サーバ1台を専有できるので、高速
• 仮想サーバ上でのライセンスの制約から開放される (Oracle DB とか Oracle DB とか…)
• 仮想化ソフトウェアが入っていないので、自前の仮想環境を構築できる
• クラウドサービスのデータセンタ内に構築されるので、ネットワーク的に近い

さて、ベアメタルサーバで何をするかという観点で下記に分類してみましょう。

• クラウドサービス上でベアメタルサーバを構築し、自分で好き勝手やりたい。
• クラウドサービス上に VMware 環境を構築したい。
• クラウドサービス上に Oracle DB 環境を構築したい。
• クラウドサービス上に SAP HANA 環境を構築したい。

上記それぞれについて、AWS・Azure・GCP の対応状況は下記です (2020/10 時点)。

まず、AWS においては EC2 ベアメタルインスタンスが豊富にラインナップされています。ベアメタルインスタンスを立てたい、と思ったらすぐに立てるこおｔができます。

VMware はベアメタルインスタンス + VMware 自前構築でもいいですし、VMware on Cloud AWS という、EC2 + vSphere な専用サービスを使う選択肢もあります。

Azure の場合、ベアメタルの技術は持っているものの、ベアメタルインスタンスとして利用可能な形態でのサービスは打ち出していません。「Azure VMware Solution でベアメタルで VMware を使う」「SAP on Azure でベアメタルで SAP を使う」というやり方のみです。

GCP は、AWS と同様にベアメタルインスタンスを立てることができる「Bare Metal Solution」を開始したのですが、価格などは Web 上には記載がない、まずは問い合わせを、というレベルなのでまだこれからと言えるでしょう。

なお、上記表ではあくまで「ベアメタルで～を使う」という観点で書きましたが、例えば単に Oracle DB を使いたいということであれば Amazon RDS for Oracle を使うなり、AWS Marketplace で Oracle 入りの EC2 を使うなど、他にも手があることに注意してください。

対応 OS 詳細説明

Amazon EC2、Azure Virtual Machine、Google Compute Engine いずれも、主要な Linux・Windows 系 OS を選択可能です。

Amazon EC2 の場合、上記に加え、Amazon Linux という OS を選択可能です。これは Amazon 自身が開発する RedHat 系の Linux ディストリビューションで、 CentOS や RedHat Linux の仲間と思ってよいでしょう。最大の特徴は、CentOS “6” や “7” などのメジャーバージョンが存在しないことです。RHEL 系のパッケージシステム yum は、メジャーバージョンをまたがる更新はできません (6.0 から 6.1 へは更新可能だが、6.1 から 7.0 は不可ということ)。Amazon Linux では yum update で常に最新状態に追随ができます。その他の特徴は下記です。

• 不要なパッケージを標準からは除外し、root ログインを不可にするなど、セキュリティを向上させている。
• Amazon Linux には AWS CLI など、AWS を操作するコマンドラインツールが標準で入っている。
• Amazon セキュリティセンターにて、インシデント対応状況を管理している。

Azure の場合、Amazon Linux はありませんが、 RedHat Enterprise Linux、 Ubuntu、 CentOS、 Windows Server などを選択可能です。

Azure ではマイクロソフトによる公式な FreeBSD サポートがあるのは素晴らしいことです。狙いは下記とのこと。マイクロソフト様ありがとう。

Microsoftによると、多くの大手仮想アプライアンスベンダーがFreeBSDをベースにした製品を開発しているため、Azure上で同OSを稼働できるようにすることが重要だったという。(略) Microsoftが自社でFreeBSD 10.3のイメージをビルドした決定的な理由には、Azure上のFreeBSDのVMでエンタープライズグレードのサービス品質保証（SLA）を実現するというものがある。

ZDNet ： 「Microsoft Azure」、FreeBSDを公式サポート 

なお、AWS・GCP では、Amazon・Google による公式な FreeBSD イメージの提供はないものの、FreeBSD Foundation あるいは FreeBSD 関係者により提供されていますので FreeBSD を利用すること自体は簡単に実現できます。

スペック 詳細説明

CPU について

各サービスとも、インスタンスタイプ・マシンタイプを選択することで、 CPU・メモリが選択可能です。Amazon EC2 のインスタンスタイプのうち、低価格なものを紹介します (東京 + Linux)。

• t2.nano … vCPU: 1 ECU:可変 メモリ: 0.5GB $0.008/時間
• t2.micro … vCPU: 1 ECU:可変 メモリ: 1GB $0.016/時間
• t2.small … vCPU: 1 ECU:可変 メモリ: 2GB $0.032/時間
• t2.medium … vCPU: 2 ECU:可変 メモリ: 4GB $0.064/時間

Azure VM のインスタンスタイプのうち、低価格なものを紹介します (東日本 + Linux)。

• A0 … 1コア メモリ:0.75GB 一時ストレージ:20GB $0.022/時間
• A1 … 1コア メモリ:1.75GB 一時ストレージ:40GB $0.032/時間
• A2 … 2コア メモリ:3.50GB 一時ストレージ:60GB $0.109/時間
• A3 … 4コア メモリ:7.00GB 一時ストレージ:120GB $0.276/時間

GCP Compute Engine のマシンタイプのうち、低価格なものを紹介します (東京 + Linux)。

• f1-micro … 仮想CPU数:1 メモリ: 0.60GB $0.0092/時間
• g1-small … 仮想CPU数:1 メモリ: 1.70GB $0.0322/時間
• n1-standard-1 … 仮想CPU数:1 メモリ: 3.75GB $0.0610/時間
• n1-standard-2 … 仮想CPU数:2 メモリ: 7.5GB $0.1220/時間
• n1-standard-4 … 仮想CPU数:4 メモリ:15.0GB $0.2440/時間

vCPU・CPU数・コア数 について

EC2 の vCPU とは、仮想コア数のことです。ハイパースレッディングという並列実行することにより、実際のコア数よりも多くのコアを搭載しているように振る舞う機能があるのですが、 vCPU においては「ハイパースレッディング有効であれば、コア数 2倍」と計算しているようです。しかしながら、世の中的には「ハイパースレッディング有効なら、実際の速度は 1.2倍くらい」 という認識ですので、まぁ、あてになりません。なお、「ハイメモリインスタンス」だけ vCPU ではなく「論理プロセッサ」と表記しているのは謎です。

Azure の「コア数」は、その数だけ実際のコアを専有できるそうです。2コアと書いてあるなら 2コア専有とのこと。Azure 仮想マシンは、基本的にはハイパースレッディングが無効なので、 記載されている「コア数」に比例した CPU 計算量は期待して良さそうです。

GCP の「仮想CPU数」は、AWS と同様に、「ハイパースレッディング有効なら、コア数 2倍」 としたもののようです。残念ながらあまり参考にならないかもしれません。

メモリについて

CPU 速度の比較が難しいのに比べると、メモリは明快です。「何GB メモリが載っているか」だけです。ただ、注意点として、

• Amazon EC2: t2.nano … vCPU: 1、メモリ: 0.5GB、$0.008/時間
• Azure VM: A0 … 1コア、メモリ:0.75GB、$0.022/時間
• GCP Compute Engine: f1-micro … 仮想CPU数:1、メモリ:0.60GB、$0.0092/時間

などのメモリが少ないインスタンスタイプを選択し、Linux を入れた場合、 スワップファイル設定がされていないため、例えば Apache + WordPress で 1日数百〜数千PV 程度の 小規模サイトを立ち上げても、アクセスが殺到しているわけでもないのにメモリ不足となり、 OOM-Killer でプロセスが殺されてしまうことが多いです。

ディスク上で 2GB 程度のファイルを作成し、それをスワップファイルとして登録するだけで、 全然違ってきますので、低スペックだからとあきらめず、ぜひ試してみてください。なお、Apache の MaxClients 等を下げたり、Apache で不要モジュール削減すると、さらにメモリ状況は改善します。

CPU/メモリカスタマイズ について

AWS・Azure は、あらかじめ用意されたインスタンスタイプから選択するしかありませんが、 GCP では「カスタムマシンタイプ」という仕組みがあり、柔軟に組み合わせることができます。vCPU (コア) を 1〜96 で選択可能で、メモリは vCPU あたり 0.9GB〜6.5GB の範囲にする必要があります。

例えば n1-standard-4 は vCPU 4・メモリ 15GB ですが、 「4コアはほしいけどメモリは 15GB もいらない」という場合、 カスタムマシンタイプにて「vCPU 4・メモリ 3.6GB」と設定することができます。逆に「4コアでいいけどメモリ 15GB では足りない」という場合、 カスタムマシンタイプにて「vCPU 4・メモリ 26GB」と設定することができます。それぞれ金額は下記のようになります (2018/1 調査・東京・継続利用前提)。

• 1. n1-standard-4: vCPU 4・メモリ 15GB: $124.68/月
• 2. カスタムマシンタイプ: vCPU 4・メモリ 3.6GB: $93.51/月
• 3. カスタムマシンタイプ: vCPU 4・メモリ 26GB: $155.01/月

なお、実は 2 の金額は「ハイ CPU マシンタイプ」の一つである “n1-highcpu-4” とスペックが同じで、金額が少しだけ高めです。3 の金額は「ハイメモリマシンタイプ」の一つである “n1-highmem-4” とスペックが同じで、金額が少しだけ高めです。管理がめんどくさいので、なるべく「事前定義されたマシンタイプ」から選択し、 それでもカスタマイズしたい場合は「カスタムマシンタイプ」を検討してください。

さらに GCP には「拡張メモリ」という仕組みがあり、 「メモリは vCPU あたり 0.9GB〜6.5GB の範囲」を超えて追加が可能です。「ご使用の CPU プラットフォームが何であれ、追加できる拡張メモリの容量は VM ごとに計 455 GB までです」 とあるのですが、試した限りでは n1-standard-4 では 52GB までしか増やせないようです (無料トライアル中だから?)。

最大の注意点は、「拡張メモリは値段が2倍」ということです。下記のように、n1-standard-4 で拡張メモリ 26GB とするくらいなら、 n1-highmem-8 にした方がメモリと料金はほぼ同じで、なおかつ 4コア増えるので、 考えものです (2018/1 調査・東京・継続利用前提)。

• n1-standard-4: vCPU 4・メモリ 52GB (うち拡張メモリ 26GB): $310.01/月
• n1-highmem-8: vCPU 8・メモリ 52GB: $310.07/月

ECU・ACU・GCEU について

ベンダ各社にて、ECU・ACU・GCEU という指標値が定められています。

• ECU (EC2 Compute Unit): Amazon が定めた EC2 の CPU 速度の指標値。以前は、「1 ECU は 1.0〜1.2GHz 2007 Opteron または 2007 Xeon プロセッサに相当」と記載があったのですが、 現在は見つからず。
• ACU (Azure Compute Unit): マイクロソフトが定めた Azure VM の CPU 速度の指標値。「Standard_A1 を 100」とし、相対的な速度比を表すもの
• GCEU (Google Compute Engine Unit): Google が定めた GCP Compute Engine の CPU 速度の指標値。1 が何を表すのかは記載なし。

いずれも、ECU は EC2 間の比較、ACU は Azure VM 間の比較、GCEU は GCP Compute Engine 間の比較しか できないことに注意してください。EC2 と Azure を比較するようなものではありません。

しかしながら、この値もあまり信用できない状況です。同じインスタンスタイプやマシンタイプであっても、全くハード構成が同じというわけではありません。例えば、GCP では、あるマシンタイプにおいて、

• 2.6 GHz の Intel Xeon E5（Sandy Bridge）
• 2.5 GHz の Intel Xeon E5 v2（Ivy Bridge）
• 2.3 GHz の Intel Xeon E5 v3（Haswell）
• 2.2 GHz の Intel Xeon E5 v4（Broadwell）

のいずれかの CPU 上で動作する旨明記されているのですが、それぞれ、2011年、2012年、2014年、2016年 に発表されたアーキテクチャです。5年も時期が違う CPU が同じ速度であるわけがなく、新しい方が高速です。そしてどの CPU が実際に割り当てられるかはそのときになってみないとわかりません。

よって、CPU の速度に関しては「実際にインスタンスを起動してみないとわからない！」です。

GPU について

GPU とは画像処理・3D 演算に特化したプロセッサです。いわゆる「グラフィックアクセラレータ」です。実体としては多数のコアを持ち (CPU は数十コアに対し、GPU は数千コア)、高速なベクトル演算や浮動小数点演算が特徴です。2000年台後半より、画像・3D に関係ない領域でも GPU が活用されるようになってきました。これを GPGPU (General-purpose computing on graphics processing units、GPU による汎用計算) と言います。具体的な活用方法は、機械学習・音声認識・暗号解読・仮想通貨マイニング・流体力学・金融工学・耐震解析等、多岐にわたります。

AWS・Azure・GCP とも、GPU に対応しています。対応方法は 2パターンあります。「GPU 搭載のインスタンスタイプを準備するパターン」と 「既存インスタンスに GPU を追加可能とするパターン」です。

• GPU 搭載のインスタンスタイプを準備するパターン。AWS・Azure が対応。
  • AWS P3: NVIDIA Tesla V100 GPU (1個, 4個, 8個)、東京: ○、$5.243〜/h
  • AWS P2: NVIDIA Tesla K80 GPU (1個, 8個, 16個)、東京: ○、$1.542〜/h
  • AWS G3: NVIDIA Tesla M60 GPU (1個, 2個, 4個)、東京: ○、$1.58〜/h
  • Azure NCv3: NVIDIA Tesla V100 (1個, 2個, 4個)、東日本: ×、西日本: ×
  • Azure NCv2: NVIDIA Tesla P100 (1個, 2個, 4個)、東日本: ×、西日本: ×
  • Azure ND: NVIDIA Tesla P40 (1個, 2個, 4個)、東日本: ×、西日本: ×
  • Azure NC: NVIDIA Tesla K80 (0.5個, 1個, 2個)、東日本: ×、西日本: ×
  • Azure NV: NVIDIA Tesla M60 (0.5個, 1個, 2個)、東日本: ○、西日本: ×、176.96円〜/h
  • GCP: GCP には GPU 搭載インスタンスタイプはない。
• 既存インスタンスに GPU を追加可能とするパターン: AWS・GCP が対応。
  • AWS … Elastic GPU。GPU のついていない EC2 インスタンス (t2 とか m4 とか m5 とか) に GPU を追加できる。Windows Server のみ。GPU メモリ 1GB, 2GB, 4GB, 8GB の4パターン。GPU カードの種類は公表されていない。1インスタンスにつき Elastic GPU は 1つのみ (複数の Elastic GPU を追加することはできない)、東京: ○
  • Azure … Azure には、既存インスタンスに GPU を追加可能な仕組みはない。
  • GCP … 既存マシンタイプに GPU を追加できる。ただし共有コアタイプでは使用不可。以下の GPU が用意されている。
    • NVIDIA Tesla T4 (1個, 2個, 4個)、東京: ○
    • NVIDIA Tesla V100 (1個, 2個, 4個, 8個)、東京: ×
    • NVIDIA Tesla P100 (1個, 2個, 4個)、東京: ×
    • NVIDIA Tesla P4 (1個, 2個, 4個)、東京: ×
    • NVIDIA Tesla K80 (0.5個, 1個, 2個, 4個)、東京: ×

日本で GPU を利用する際、対応 GPU の幅が少ないことに注意してください。

※GCP では、 2019/01/16 から東京 (asia-northeast1) で GPU が利用可能となった模様です。

なお、仮想マシンからは少し外れますが、GCP では Google Cloud Dataproc・GKE でも GPU が利用可能です。

FPGA について

FPGA とは Field Programmable Gate Array の略で、 プログラミング可能なハードウェア回路です。GPU と同じく、簡単な計算を複数並列で行うような用途に向いています。事例としては下記です。

• Microsoft が検索エンジン Bing の処理の一部を FPGA 化し、CPU と比べて 150倍に高速化
• 金融取引において、FPGA を用いて処理を高速化。アルゴリズム取引が5ミリ秒遅れると、ライバルよりも 1% 利益が少なくなり、10ミリ秒遅延で利益10%減、らしい。
• 動画エンコードを FPGA を用いて高速化

2020/9 時点で対応しているのは Amazon EC2 の f1 インスタンスのみですが、発表から3年近く経ったにも関わらず東京リージョンでは使えません。Azure・GCP では現時点では利用できないようです。ちなみに、Azure 一般利用者が FPGA を使うことはできないものの、Azure 内部では パケットフィルタリング・データ暗号化・圧縮・展開などのインフラ部分に FPGA を利用しているそうです。

ネットワーク 詳細説明

ディスク・ストレージ 詳細説明

ストレージ について

Amazon EC2 の場合、EBS (Elastic Block Store) というストレージを追加する必要があります。EC2 では、最低でも「ルートディスク」というものが必要ですので、EBS が最低 1つ必要です。

Azure の VM の場合もストレージが最低 1つ必要ですが、 Azure Disk Storage と Managed Disk (管理ディスク) という選択肢があります。Azure Disk Storage は昔からあるやり方ですが、ストレージアカウントの下にぶらさがっている形になり、 IOPS の上限があったり、イメージ・スナップショットの作成ができなかったり、いろいろ問題がありました。Managed Disk はそれを解消するものですので、特に理由がない限りは Managed Disk を選びましょう。

GCP の場合、Compute Engine に接続するディスクは「永続ディスク」(Persistent Disk) と呼びます。こちらも最低 1つ必須です。

HDD/SSD 選択 について

Amazon EBS・Azure Managed Disk・GCP 永続ディスク いずれも、HDD/SSD が選択可能です。

ストレージ冗長化

EBS・Managed Disk・永続ディスクが冗長化されているかですが、すべて冗長化されています。具体的な各社の記述は下記です。

• Amazon: Amazon EBS ボリュームのデータは、追加料金なしで、同じアベイラビリティーゾーン内の複数のサーバーにレプリケートされます。(略)Amazon EBS ボリュームは、年間故障率（AFR）が 0.1%〜0.2% になるように設計されています。この場合の「故障」とは、ボリュームのサイズやパフォーマンスに応じて、ボリュームが完全に、または部分的に失われることを指します。
• Azure: 優れた耐久性と可用性 – データを 3 つのレプリカに同時にレプリケートできます。1 つのレプリカで問題が発生しても残り 2 つが引き継ぎ、データの永続性と高いフォールト トレランスを確保できます。
• GCP: 耐久性 – 永続ディスクは長くお使いいただけるように設計されています。データの整合性を確保するため、データを冗長的に保存します。

当ページ管理人としては上記の記述から Amazon EBS の信頼性が低いのではないかと感じたため、EBS のみ “△?” とさせていただきましたが、真実はいかに。

ストレージ共有 について

Amazon EBS 複数の EC2 インスタンスで共有することはできなかったのですが、2020年2月に EBS Multi-Attatch というものが使えるようになったようです。しかし並行して書けない読めない等の制限があり、フェイルオーバー時に待機 EC2 がディスクを読むためにしか使えない…? (よくわからない)

Azure の Managed Disk を複数の VM で共有することはできません。

EBS は EC2 インスタンスにアタッチして使用しなければならないのですが、 その際、複数の EC2 インスタンスにアタッチすることはできないためです。Azure も同様です。

一方 GCP の場合、永続ディスクを読み取り専用で利用すれば、 同時に複数の Google Compute Engine から利用可能です。ただし、全ての GCE より読み取り専用とする必要があるため、 データの更新が一切できません。せめて、1つの GCE からのみ更新が可能で、その他の GCE からは読み取り専用、 であればかなり使い所があるのですが…。あと一歩ということで「△」とさせていただきました。

★2021/03/02：GCE のマルチライターなるもので最大2台で読み書きができる?

ストレージ動的拡張 について

AWS・GCP は、インスタンス起動中であってもストレージ (EBS・永続ディスク) を動的に拡張することが可能となっています。管理画面からストレージサイズを拡張し、OS 側で resize2fs コマンドなり xfs_growfs コマンドなりを叩けばそれで OK です。なお、AWS ではルートディスク拡張は再起動しないやり方が通常のようですが、 GCP では「Linux では SLES 11 以外は再起動すれば新しいサイズで認識するから再起動せよ」 と書いてあります。

Azure の場合、インスタンスを停止しないといけませんが、 それ以外はおおむね上記と同じ手順です。

ちなみに 2017/2 より前は EC2 のストレージである EBS の拡張は非常にめんどくさくて、 インスタンス停止 → EBS からスナップショット作成 → ボリューム作成 (ここでサイズを拡張する) → 作業用インスタンス作成 → 作業用インスタンス停止 → ボリュームをアタッチ → 作業用インスタンス起動 → parted → resize2fs → 作業用インスタンス停止 → 作業用インスタンスからデタッチ → 元のインスタンスにアタッチ → 元のインスタンス起動 だったそうです。恐ろしや。

一時ストレージ について

AWS・Azure・GCP とも、永続化しないストレージを準備しています (何かのタイミングでデータが消えるかもしれないストレージ)。

AWS の場合、一部インスタンスタイプ限定ですが、「インスタンスストア」(旧インスタンスストレージ) というストレージが使えます。インスタンスを停止するとデータが消えてしまう、 スナップショットが取れないなどのデメリットがあります。メリットは「無料」です。

GCP の場合、ローカル SSD というものがあります。これはサーバに物理的に直結した SSD で、なおかつ NVMe で接続できるので、爆速という噂です。要は ioDrive と思ってください。制限事項は下記です。

• インスタンス作成時にローカル SSD を作成しないといけないこと。後から追加はできない。
• ローカル SSD が繋がった GCE インスタンスは停止ができないこと (立ち上げっぱなしか、削除かのいずれか)。なお、OS の再起動は可能です。

★メモ：GCE のスクリーンショットキャプチャ機能。
EC2・GCE サスペンド機能。