クラウド仮想マシン比較まとめ (Amazon EC2・Azure VM・Google Compute Engine)

前へ << 3大クラウドサービス サービスマッピング表 クラウドストレージ比較まとめ (Amazon S3・Azure Storage・Google Cloud Storage) >> 次へ

仮想マシンとは

いわゆる 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 だけだったのです。

比較表

- AWS Azure GCP
管理画面操作
管理画面からのインスタンス作成
作成時のステップ数 ○ 6ステップ (少ない) × 16ステップ (多すぎ!) ◎ 2ステップ (とても少ない)
管理画面からの OS ログイン ×
料金・課金
課金単位 △ 秒 (最低1分) と時間単位が混在 ◎ 分単位 (秒切り捨て) ◯ 秒 (最低1分)
継続利用割引 × ×
リザーブによる割引
スポット VM ×
管理・メンテンナンス
停止時のインスタンスサイズ変更
起動時のインスタンスサイズ変更 × × ×
リージョン変更 × × ×
ライブマイグレーション × × ◎◎◎
起動時間 △ 3分〜4分20秒 △ 3〜4分 ○ 16〜27秒
シリアル接続 × ×
自動シャットダウン × ×
アカウント自動作成 × ×
OS
Linux Amazon Linux, Amazon Linux 2, Ubuntu, RHEL, SUSE CentOS, Debian, Ubuntu, RHEL CentOS. Debian, Ubuntu, CoreOS, RHEL, SUSE
Windows Windows Server 2003, 2008, 2012, 2016 Windows Server 2008, 2012, 2016, Windows 7,8,10 Windows Server 2008, 2012, 2016
FreeBSD × FreeBSD 10/11 ×
その他 SQL Server, コンテナ特化OS
スペック
CPU vCPU: 1〜128 vCPU: 1〜128 仮想CPU: 0.2〜96
メモリ 0.5〜3,904GB 0.75〜2,048GB 0.6〜624GB
CPU/メモリカスタマイズ × × ○ (カスタムタイプ, 拡張メモリ)
GPU あり あり あり
性能指標値 ECU ACU GCEU
ネットワーク
グローバルIPアドレス固定化
内部IPアドレス固定化
複数 NIC
ストレージ
ストレージ ○ EBS ○ Managed Disk, Azure Disk Storage ◯ 永続ディスク
HDD/SSD 選択
ストレージ冗長化 △? 年間故障率(AFR)0.1%〜0.2% ○ (3重化。可用性 99.999%)
1ストレージの最大容量 16TB 4TB 64TB
ストレージ最大数 Linux: 40、Windows: 17〜26 4〜16 (2018/1 現在ベータだが 16〜128 も可能)
ストレージ合計 64TB (共用タイプは 3TB)
ストレージ共有 × ×
ストレージ動的拡張 ○ (2017/2 より動的拡張可能) × (インスタンス停止が必要)
ストレージバックアップ ○ (EBS スナップショット) ○ (スナップショット)
ストレージストライピング △ (できるが、推奨ではない)
一時的ストレージ ○ インスタンスストア ○ 一時ディスク ◯ ローカル SSD (375GB×8本)

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

管理画面操作

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

- AWS Azure GCP
管理画面からのインスタンス作成

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

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

- AWS Azure GCP
作成時のステップ数 ○ 6ステップ (少ない) × 16ステップ (多すぎ!) ◎ 2ステップ (とても少ない)

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

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

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

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

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

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

- AWS Azure GCP
管理画面からの 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
課金単位 △ 秒 (最低1分) と時間単位が混在 ◎ 分単位 (秒切り捨て) ◯ 秒 (最低1分)

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秒だけ使えることはまずありえないので、 気にしないことにしましょう。

継続利用割引 について

- AWS Azure GCP
継続利用割引 × ×

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

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

- AWS Azure GCP
リザーブによる割引

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

スポット VM について

- AWS Azure GCP
スポット VM ×

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

  • AWS の EC2: スポットインスタンス
  • GCP の Compute Engine: プリエンプティブ VM インスタンス

詳細は こちら

Azure Virtual Machine にはこの仕組はありません (Azure Batch にはあるが、Azure Virtual Machine にはない)。

管理・メンテナンス

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

- AWS Azure GCP
停止時のインスタンスサイズ変更

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

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

- AWS Azure GCP
起動時のインスタンスサイズ変更 × × ×

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

リージョン変更

- AWS Azure GCP
リージョン変更 × × ×

一度インスタンスを作成すると、リージョンの変更はできません。

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

- AWS Azure GCP
ライブマイグレーション × × ◎◎◎

ライブマイグレーション機能を持つのは 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 のアップグレード

「起動時間」について

- AWS Azure GCP
起動時間 △ 3分〜4分20秒 △ 3〜4分 ○ 16〜27秒

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

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

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

「シリアル接続」について

- AWS Azure GCP
シリアル接続 × ×

例えば /etc/fstab の修正をミスしたときなど、通常起動が失敗してしまいます。 オンプレミスであればシングルユーザモードでの起動や、 さくらインターネットの VPS などではシリアルコンソールから復旧ができます。 ではクラウド 3社はどうかというと、なんと AWS・Azure ではシリアル接続ができません。

どうするかと言うと、AWS であれば EC2 を落とし、該当のファイルが含まれる EBS をデタッチし、 別 EC2 を作成し、そこに EBS をアタッチし、OS からマウントし、ファイルを修正し、EBS をデタッチし、 元の EC2 にアタッチし、EC2 起動、です。Azure も同様です (VHD イメージまわりで、さらにすごくめんどくさい体験をした気がするのだが、詳細を思い出せない)。 一方で、Google Compute Engine の場合は、 管理画面からシリアル接続を有効化し、管理画面からシリアルコンソール起動することができます。 ただ、ログインID・パスワードでの認証が必要であるものの、 デフォルトではパスワード認証が有効になっていないはず。 よって、事前に設定変更・パスワード設定を行っておかないとログインできないのではなかろうか。

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

- AWS Azure GCP
自動シャットダウン × ×

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


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


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



- AWS Azure GCP
アカウント自動作成 × ×

対応 OS

- AWS Azure GCP
Linux Amazon Linux, Amazon Linux 2, Ubuntu, RHEL, SUSE CentOS, Debian, Ubuntu, RHEL CentOS. Debian, Ubuntu, CoreOS, RHEL, SUSE
Windows Windows Server 2003, 2008, 2012, 2016 Windows Server 2008, 2012, 2016, Windows 7,8,10 Windows Server 2008, 2012, 2016
FreeBSD × FreeBSD 10/11 ×
その他 SQL Server, コンテナ特化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 があるのは素晴らしいことです。ZDNet の 「Microsoft Azure」、FreeBSDを公式サポート によると、

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

とのこと。マイクロソフト様ありがとう。

スペック

- AWS Azure GCP
CPU vCPU: 1〜128 vCPU: 1〜128 仮想CPU: 0.2〜96
メモリ 0.5〜3,904GB 0.75〜2,048GB 0.6〜624GB
CPU/メモリカスタマイズ × × ○ (カスタムタイプ, 拡張メモリ)
GPU あり あり あり
性能指標値 ECU ACU GCEU

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/時間

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

AWS・Azure は、あらかじめ用意されたインスタンスタイプから選択するしかありませんが、 GCP では「カスタムマシンタイプ」という仕組みがあり、柔軟に組み合わせることができます。 vCPU (コア) を 1〜64 で選択可能で、メモリは 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 調査・東京・継続利用前提)。

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

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

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

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 で不要モジュール削減すると、さらにメモリ状況は改善します。

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 を比較するようなものではありません。

しかしながら、この値もあまり信用できない状況です。 同じインスタンスタイプやマシンタイプであっても、全くハード構成が同じというわけではありませn。 例えば、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 に速度に関しては「実際にインスタンスを起動してみないとわからない!」です。

ネットワークについて

- AWS Azure GCP
グローバルIPアドレス固定化
内部IPアドレス固定化
複数 NIC

ディスク・ストレージについて

- AWS Azure GCP
ストレージ ○ EBS ○ Managed Disk, Azure Disk Storage ◯ 永続ディスク
HDD/SSD 選択
ストレージ冗長化 △? 年間故障率(AFR)0.1%〜0.2% ○ (3重化。可用性 99.999%)
1ストレージの最大容量 16TB 4TB 64TB
ストレージ最大数 Linux: 40、Windows: 17〜26 4〜16 (2018/1 現在ベータだが 16〜128 も可能)
ストレージ合計 64TB (共用タイプは 3TB)
ストレージ共有 × ×
ストレージ動的拡張 ○ (2017/2 より動的拡張可能) × (インスタンス停止が必要)
ストレージバックアップ ○ (EBS スナップショット) ○ (スナップショット)
ストレージストライピング △ (できるが、推奨ではない)
一時的ストレージ ○ インスタンスストア ○ 一時ディスク ◯ ローカル SSD (375GB×8本)

ストレージ について

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

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

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

HDD/SSD 選択 について

Amazon・Azure・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 インスタンスで共有できるか、 Azure の Managed Disk を複数の VM で共有できるか、 というと、できません。

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

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

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

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

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

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

一時ストレージ について

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

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

GCP の場合、ローカル SSD というものがあります。 これはホストに物理的に直結してあり、なおかつ NVMe で接続できるので、爆速という噂です。 制限事項はたくさんあります。

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

前へ << 3大クラウドサービス サービスマッピング表 クラウドストレージ比較まとめ (Amazon S3・Azure Storage・Google Cloud Storage) >> 次へ