クラウドサービスのメリット・デメリット

最終更新 2020-01-23

クラウドサービスのメリット・デメリットを解説します。特にオンプレミスと比較することで、クラウドサービスの利点・欠点や、得意分野・不得意分野を浮き彫りにします。

クラウドサービスのメリット・デメリット一覧表

クラウドサービスのメリット・デメリットを一覧にまとめました。

開発

導入スピードについて

導入のスピードが早い。これはクラウドサービスの一番のメリットと言っていいでしょう。ブラウザで管理画面にアクセスし、ぽちぽちと操作すれば基本的なインフラは準備ができます。

一方、オンプレミスのシステム構築において、ハードウェアの導入は以下のような流れになります。

• 提案依頼書 (RFP) を書く
• 提案依頼書をハードベンダにばらまく
• 説明会を実施する
• ハードベンダからの提案書を受けとる
• 提案書を比較検討し、さらに詳細条件を確認する
• 最終的な見積提示をしてもらう
• 契約を締結する
• ハードウェア搬入を行う
• ラックにマウントし、ネットワークを結線する
• 試験を行う

そして「海外からの出荷なので 1ヶ月待ちです」なんて言われたり、初期不良で返品となり代替品の到着を待つのに数週間も必要だったり。

大規模システムでは、クラウドサービス化により数ヶ月や1年間の期間短縮が可能です。これは全く大げさな話ではありません。事実です。

検証容易性について

上記の導入スピードとも関係しますが、画面操作だけで設定が可能なので、「まずは試してみよう」ができてしまいます。

オンプレミスのシステムからクラウドへの移行の際、固い組織だと「まずはクラウドサービスの選定プロセス検討から始めないと！」となったりします。そういうやり方も否定はしませんが、ちょっと優秀な技術者に 10日くらい与えてみると、「それなりに動くようになりました」となることも多いでしょう。

特に自社サービスであれば、検討・計画をすっとばして、まずは試してみるというのは十分ありえる選択肢です。

PaaS 利用による開発ボリューム削減

オンプレミスでは自前で構築・開発しなければならないところを、クラウドサービスの PaaS を利用することで、構築・開発を省略することができます。結果的に開発スピード向上につながります。

以下は、当ページ管理人が考える、クラウドサービスの PaaS を使った方が楽で早いと思われる箇所です。

• RDBMS 構築 (冗長化・バックアップ含む) → Amazon RDS などを利用
• DNS サーバ構築 → Route 53 などを利用
• データウェアハウス構築 → Amazon Redshift などを利用
• ストレージの構築 (冗長化・バックアップ含む) → Amazon S3 などを利用
• キャッシュサーバの構築 (Memcached・Redis など) → ElastiCache などを利用
• ロードバランサ構築 → ELB を利用
• バックアップサーバ構築 → Amazon RDS・S3 等の標準バックアップを利用
• 監視・モニタリングサーバ構築 → CloudWatch などを利用
• CI/CD サーバ構築 → AWS CodeBuild などを利用
• Web サーバ構築 → PaaS を利用

料金・コスト

価格について

価格については「場合による」です。オンプレミスから EC2 などの仮想マシンへの単純な移行であれば、クラウドの方が高額になることも多々あります。ただしインフラ構築ベンダの作業量が減る、あるいはアプリ開発ベンダがインフラ構築も担当できることもあるので、その分は浮きます。さらにオンプレミスのような数年おきの EOL/EOSL 対応が不要なので、結果的にクラウドの方が安くなるというパターンは何度か見ました。

当ページ管理人の私見としては、オンプレミスより安くなるということはあまり期待せず、似たような金額で開発期間の短縮・スモールスタートによるリスク軽減・スケールアップでの柔軟性・災害対策の容易性といった点を重視した方がよいのではと思います。

価格透明性について

クラウドサービスの Web ページにおいて料金はしっかりと記載されていますが、最終的な金額は読みづらいものです。AWS移行で予算超過のリスク判明、ダイソーの回避策 では、AWS Lambda・DynamoDB などを組み合わせたシステムを設計・開発したものの、いざ作ってみると年間数千万円のコスト超過が発生するという事例が紹介されています。

内部的な PaaS サービスの処理性能・リクエスト数・データ量などは大変読みづらいものですので、あまりに理想的な見積もりを出すのは気をつけた方がよいのでしょう。また、予測しづらいというリスクをあらかじめ経営層に伝え、最終試算や設計見直しフェーズを設けておくなど、マネジメント面でも対策をとっておいた方がよいと思います。

また、クラウド破産 もご一読ください。

初期費用 について

ほとんどのクラウドサービスでは、初期費用は不要です。「ほとんど」というのは、初期費用が必要なクラウドサービスも存在していたからです。

当ページ管理人が把握している限りでは、初期費用が必要だったのは以前の AWS CloudHSM の $5,000 のみで、2018年現在では初期費用は不要となっています。よって、AWS・Azure・GCP においては、2019年現在初期費用のあるサービスは存在しないという認識です。

最低利用期間 について

一般的な最低利用期間はありませんが、AWS のリザーブドインスタントなど前払い系であれば、リザーブドインスタンスを契約した期間中は請求が継続されます。

経費計上

オンプレミスで自社で購入する場合、サーバ機材などは資産化して 6年間減価償却をしていく必要があります。また、最初に大きなお金が出ていくのでキャッシュフローに影響を与えます。

一方、クラウドサービスの場合 (ホスティングも同様ですが)、経費で落とせますので、利益が出ているならば利益圧縮 (≒ 法人税の節税) が可能です。毎月使った分だけ支払いなので、キャッシュフローも安定します。

ただこの点は、「赤字なので利益圧縮できない」とか「BS (バランスシート) をよく見せるためにあえて資産化したい」という状況であれば、デメリットになりますね。

性能

マシン性能

CPU・メモリなどのマシン性能は、ハイエンドであれば、オンプレミスが優勢です。2019/3 現在、AWS EC2 のベアメタルサーバ m5.metal などの Xeon Platinum 8175 の 48コア (96論理コア) が 最速ではなかろうかと思うのですが、オンプレミスであればマルチソケットでより多くのコア数に対応可能です。

ストレージ性能

クラウドサービス当初は HDD しかなかったストレージですが、2020年1月現在、AWS・Azure・GCP とも、ほぼ SSD が選択可能となっており、ストレージ速度は以前と比べると上がったと考えます。それでも例えば、Amazon EC2 から利用可能なストレージ Amazon EBS では、予約可能な IOPS は最大 64,000 どまりです。

一方、オンプレミスには NVMe 接続というマザーボード直刺し形態のフラッシュメモリがありますが、2020年1月現在、SanDisk 社の NVMe SSD は、ランダム Read で 480,000 IOPS、ランダム Write で 550,000 IOPS です (IOPS は、1秒あたりの最大 I/O アクセス回数)。

さらに、フラッシュメモリを山ほど積んだフラッシュストレージというものがあります。1000万を超える IOPS のものまであります。

よって、IOPS ではオンプレミスの圧勝と言えますが、これはある意味仕方がないことです。Amazon EBS などはネットワーク経由で HDD や SSD に読み書きしているので、ハードウェア直結のものより遅いのは当然です。遅い代わりに、冗長性と可用性 (インスタンスが落ちても、他インスタンスから EBS を読み書きできる) が確保されています。さらに、NVMe 接続フラッシュメモリで 100万円以上、フラッシュストレージは数百万〜数千万円しますので、価格も全然違います。

なお、AWS・Azure・GCP とも、NVMe 接続のインスタンスはあるにはあるのですが、インスタンスの停止で内容が消えてしまうとか、立ち上げた後は停止ができないなどの制限があり、クラウドならではのデータ可搬性は実現できていません。

ネットワーク性能について

これは推測ですが、クラウドサービスのデータセンタ内の接続は 10Gbps だろうと思います。これは一般的なデータセンタでも同じでしょうから、ここには差がありません。

しかしオンプレミスの場合、Oracle RAC やフラッシュストレージ間のインターコネクトなど、より高速な通信が必要な場合は Infiniband を使ってさらに高速化するという選択肢があります。一方 AWS・Azure・GCP いずれも 2019/3 現在Infiniband の利用はできませんので、オンプレミスの方が有利です (ただし Azure では GPU 間を Infiniband でつないでいるそうです。ちなみに IBM Cloud では Infiniband 接続が可能な模様)。

また、オンプレミスからクラウドに移行するにあたり、Web サーバ・AP サーバなどはクラウドに移行するが、個人情報を含む DB などをどうしてもオンプレミスに残しておきたい場合があります。AP サーバ・オンプレミス間は通常はインターネットを経由するため、それなりの遅延は発生します。遅延を小さくするために AWS Direct Connect などで専用線接続をすることは可能ですが、その分費用はかさみます。

運用

インフラ障害対応 について

インフラ障害は、すべてクラウドサービス側で対応してくれます。個々のマシンの CPU・メモリ・電源・HDD・SSD・ネットワークカード・スイッチ・ルータすべて面倒を見てくれます。ただし「このインスタンスで HDD がクラッシュしたため交換しました」のような細かな障害情報は提供されません。我々が知ることができるのは、「この時間にインスタンス再起動が起こったようだ」程度です。

ハードウェア EOL/EOSL にあわせた開発

EOL (End Of Life)・EOSL (End Of Service Life) は、製品のサポート終了を意味する用語です。オンプレミス、特にハウジングなどでハードウェアを購入する場合最大の問題点は、すべてのハードウェアに 5〜6年程度の EOL/EOSL が設定されていることだと当ページ管理人は考えます。ベンダによっては 8年や 10年に延長可能な場合がありますが、保守料金がアップしたりします。仮に 6年だと仮定すると、中規模〜大規模システムでは

• 2年前から検討開始
• 1年半前に発注
• 1年3ヶ月前に納品
• 1年前に設置・ネットワーク設定完了
• 1年前〜3ヶ月前で試験実施

といったスケジュールになると、1年3ヶ月前に納品し、そこから保守期間がスタートしているわけですから、実質的な残りサポート期間は 4年9ヶ月です。

世の中のシステムは、このタイミングにあわせてシステム更改を計画・実施する必要があります。

一方、クラウドサービスにおいては、このようなハードウェアに関する EOL/EOSL はありません。よって、利用者はハードウェアの EOL/EOSL を意識する必要もありません。これは大きなメリットです。

Amazon・マイクソフト・Google などの大規模クラウドサービスはそもそも自作ハードウェアを 使っているため外部ハードウェアベンダ起因の保守期限といったものはありませんし、おそらくはパーツごとに寿命管理をして交換時期を計画しているでしょうし、交換パーツも山のように準備しているはずです。また、古い世代のサーバ、新しい世代のサーバは存在しますが、仮に古い世代のサーバを削減したい場合は、新しいサーバに振り直せばよいだけですので、古いハードウェアを維持管理する必然性もないのです。

セキュリティ

インフラセキュリティ・脆弱性対応

インフラに関するセキュリティ・脆弱性対応は、クラウドベンダに任せるのが一番よいと考えます。例えば 2017年末〜2018年の Spectre (スペクター) ・Meltdown (メルトダウン) 対応において、Google・AWS・マイクロソフトより早く対応できたインフラベンダはあったかと言うと、ほぼなかったのではないかと思います。

また、Web サーバなどの脆弱性についても、Azure App Service や GAE などの PaaS サービスを使う分には、クラウドベンダにおまかせできますのですごく楽です (IaaS を立てて Apache や IIS を使っている場合は自前で対応する必要があります)。

WAF・アンチウィルスソフト について

これまでオンプレミスで様々なアンチウィルスソフトを使っていた場合、それがクラウド上でそのまま実現できるかという点では、「難しい」と考えます。

また、WAF についても、クラウドサービス各社が AWS WAF、Cloud Armor などの WAF 機能をリリースしてきていますが、まだ機能不足という状況です。

なお、AWS・Azure・GCP いずれも、Marketplace から WAF やアンチウィルス等のソリューションを起動することができますが、これを使う場合接続先が EC2 や Azure Virtual Machine・GCE などの IaaS ソリューション限定になりがちであるという欠点があります。

うっかりミスによる被害

うっかりミスによる被害としてありがちなのは、Amazon S3 などオブジェクトストレージにおいて、公開状態にしてしまうことでしょう。相次ぐAmazon S3の設定ミスによる情報漏えい事故 より引用すると、

• 米Verizon、1400万人の顧客情報が誰でもアクセス出来る状態で公開
• ダウジョーンズ、400万人の個人情報がアクセス可能な状態で公開
• WWE、300万件の個人情報がアクセス可能な状態で公開

といった事故が S3 の公開設定ミスで発生しています。

オンプレミスでこのようなことが絶対に起きないとは言いませんが、管理画面操作で簡単に操作できてしまうクラウドサービスでは事故が起きやすいと考えます。

拡張性

スケールアップ

スケールアップは、CPU を高速化したり、メモリを増やしたりして処理能力を増強することを指します。これはクラウドサービスの得意なところで、管理画面からの操作で簡単にスケールアップができます。ただし 2018/07 現在、CPU のコア数増加 (128 程度)、メモリ 2〜3TB 程度が上限で、それ以上が必要な場合はオンプレミスのハイエンドマシンに軍配が上がります。

スケールアウト

スケールアウトは、サーバ台数を増やすことで処理能力を増強することを指します。こちらもクラウドサービスが得意とする領域で、数百〜数千台程度であればさくっとインスタンス作成ができます。

ただし ELB では暖気運転が必要などという話もありますので、テレビ番組での紹介や CM による急激なアクセス増などは注意が必要です。

安定性

料金・コスト安定性

クラウドサービスは、料金・コストに関する安定性はありません。各社ともクラウドシェアを必死に争っている状況ですので、基本的には値下げがトレンドです。値上げはごくまれなケースと言ってよいでしょう。

数は多くはないですが、当ページ管理人が把握している値上げは下記のとおりです。

• AWS・Azure: 2017年、Oracle が承認済クラウド環境 (AWS・Azure) での「コア係数 ×0.5」という計算方法を突然撤廃し、Oracle の必要ライセンス数が 2倍となった。結果としてコストも 2倍に (AWS や Azure 側が値上げしたわけではなく、Oracle 側が値上げした形)。
• Azure: 2015年頃、為替レート差異解消のため 日本で 10% 程度値上げ
• Azure: 2018年1月、為替レート差異解消のため 日本で 10% 値上げ
• GCP: 2011年、Google AppEngine のコストを CPU 使用時間からインスタンス時間に変更し、サービスによって数倍〜10倍の実質値上げに。

当ページ管理人の予言ですが、将来的に 1社が独占した、あるいは数社にて寡占状態となりシェアの大きな変動はなさそう、となった段階で、大幅値上げがあったり、無料期間の撤廃があると考えます。クラウドサービスではありませが、Amazon プライム米国価格は当初 79ドルでしたが、2018年の値上げで現在は 119ドル。33% 値上げされています。クラウドサービスも間違いなくそうなるでしょう。

不意のシステムトラブル

オンプレミスと比較すると、クラウドでは、不意のシステムトラブルは起こりがちであると当ページ管理人は考えます。理由は下記。

• リリースしてから、それほど時間が経過していない
• クラウド内部システムがどんどん更新されている
• クラウド内部構成が複雑化している
• 共用環境であるため、システムリソース逼迫による問題が起こりがち

DevOps が進み、テスト自動化と頻繁なデプロイが普通になりつつある現在であっても、先人たちの「必要がなければ変えるな！」というのは、安定性最優先という観点では正しいと考えます。

しかしながらクラウドサービスは、より便利に、より早く、より使いやすくするために、日々機能が追加され、内部のリファクタリングも日々行われています。その結果、昨日動いていたものが今日は動かない (エラーになる、遅い) ということが、結構頻繁にあります。

ちなみに当ページ管理人が体験した実例としては、

uri = new URI("http://example.com/foo?a=b");
req = new HttpRequest(uri);
res = req.getResponse(); 

といったコードがあったのですが 、ある日突然エラーが発生し、サービスに影響が出ました。理由はこのコードが不適切で、本来は下記のように書くべきものであったためです。

uri = new URI("http://example.com/foo");
req = new HttpRequest(uri);
req.setRequestParameter("a", "b");
res = req.getResponse(); 

これまではたまたま動いていたものが、クラウドサービスの内部実装が変更になったため、ある日突然エラーとなったということです。誰が悪いかといえば、不適切なコードを書いた人が悪いのですが、内部のライブラリが自動的に修正され、いきなり動かなくなるというのは、オンプレミスでは起こりえないものです。

突然のスローダウン

データベースやストレージなどの PaaS サービスで起こりがちなのですが、これまでは 0.1 秒で処理できていたものが、いきなり数倍の時間がかかって遅くなることがあります。原因としては、クラウド事業者側でのバージョンアップによるエンバグ、クラウド事業者側でのリソース制限の追加、などが上げられます。

しばらくしたら直ることもありますし (クラウド事業者側で気づいたか、他の利用者からサポートへのクレームがあったものと推測されます)、サポートへ連絡すると「バグであることが判明したのでただいまからロールバック (切り戻し) を行います」ということもあります。

「 クラウド事業者側でのバージョンアップによるエンバグ 」の実例は、BigQuery でスローダウンしたことがあります。ロールバック完了まで 2～3日かかりました。

「 クラウド事業者側でのリソース制限の追加」の実例としては、Azure Table Storage で「あるアクセス方法を1分あたりN回行うと、ペナルティとして一定期間スローダウンする」というのがありました。なお、ドキュメントには「このようなアクセス方法は推奨されません」とありましたので確かによくないアクセス方法ではあるのですが、ペナルティがあるとは一言も書いてありませんでした。現時点でもその記載はないように見えますが、そのペナルティが継続しているのかは不明です。

狭い範囲での可用性

クラウドサービス、特に PaaS においては、狭い範囲での可用性は低くなると当ページ管理人は考えます。具体的には、API を叩いたり、サービスに接続したりする場合、エラー発生率がオンプレミスと比較すると明確に高いと感じます。

推測ですが、PaaS は共用環境であるため、他ユーザからアクセスが殺到している場合、一時的な利用制限がかかっていたり、ハードウェア故障が発生して別マシンに自動移行中、といったことに遭遇しやすいのではないかと考えます。

例えば Azure の SQL Server の PaaS サービスである SQL Database を利用する際、下記のように実装するよう推奨されています。

SQL Database の接続に関する問題と一時的なエラーに対応する より:

• リトライ ロジックを実装し、接続切断や接続タイムアウトなどを検知時にリトライ処理を実施する
• 接続タイムアウト値 (既定 15秒) を 30秒以上に設定する
• リトライ処理の間隔は、10秒以上 (最低 5 秒以上) に設定する

また、1分間にN回以内といったレート制限が設けられてその制限に引っかかることもよくあります。PaaS の場合、エラーは起こり得ると考え、メッセージング/キュー などを用いて再実行可能なように設計することをおすすめします。

SDK バージョンアップ・仕様変更

クラウドサービスの各機能は、おおむね API が用意されています。例えば Amazon S3 には S3 を操作するための API があります (API ドキュメントは こちら)。このような API は http や https 経由でアクセスすることが多いのですが、普通は開発効率アップのために、より便利な SDK (開発キット) が用意されています。

このような SDK には残念ながらサポート期限または使用期限があり、未来永劫使えるものではありません。SDK の期限は下記のように公開されています。

• Azure SDK の場合：Support and Retirement Information for the Azure SDK for .NET and APIs
  • 例えば 2016/03/30 にリリースされた Azure SDK 2.9 は、2019/07/01 にてサポート期限切れとなることがわかります。なお、この例ではサポート期限切れになるだけで、即使えなくなるわけではありませんが、期限切れになるといつエラーになってもおかしくない状況になります。
• GCP の Dataflow の場合：SDKバージョンのサポート状況
  • 例えば 2018/01/30 リリースの SDK 2.3.0 は、2019/01/30 に非推奨 (＝サポート期限切れ) となり、2019/03/25 に動かなくなることがわかります (と言っても、書き方がわかりづらいのでぱっと見ではわからないと思います)。

なお、期限切れとなる場合、エンジニアが泣きながら SDK バージョンアップ作業を行うのですが，その作業がどれくらい大変かはその時の状況次第です。「バージョン表記だけ変えればするっと動く」ケースもありますし、「大改修でテストもほぼやり直し」ということもあります。また、「バージョンアップするとビルドが通らず数千行エラーになったけれど修正パターンは数パターンしかなく、地道になおしていけば1日作業」ということもあります。

オンプレミスの場合、サポート期限切れというのはあり得る話ですが、ある日をもって動かなくなるということは起こりえませんので、これはクラウドサービスの PaaS 系のデメリットと言えるでしょう。ただし、「サポート範囲を狭くすることでテスト範囲を限定して開発スピードを上げる」ことが目的でしょうから、一概にクラウドがダメとは言いません。

その他

ライセンス管理

Windows Server・SQL Server・RedHat Enterprise Linux・Oracle など、オンプレミスにおける商用ソフトウェアのライセンス管理は大変面倒なものです。そもそもライセンス体系がわかりづらい。プロセッサ数だのコア数だの係数だの CAL だの仮想マシンの場合はどうこうだの開発用や待機系はどうこうだの、うんざりします。そして数年おきにライセンス内容が変わったり、いきなり値上げになったり。

AWS・Azure・GCP においては、Windows Server・SQL Server・RedHat Enterprise Linux・Oracle などのライセンスがインスタンス料金に「込み」になっていますので、以下のように大変すっきりとした形になっています。

• 使えば使うほどライセンス料金を支払う
• 事前購入という考え方はない
• ライセンス期限もない
• CAL (クライアントアクセスライセンス) は (基本的には) 不要

ただし、 各クラウドベンダの料金ポリシーが異なるため、試算するとなると結構大変です。

例えば Amazon EC2 で、無償の Linux (CentOS や Amazon Linux 等) を使うか、有償の RHEL・Windows を使うかで下記のように価格が違います。Windows は「Linux の約 2倍」というルールに見えますが、RHEL は異なる料金ポリシーのようです。

Azure の場合、2020年1月時点では、Windows と Linux の仮想マシン料金が全く同一に見えます。

• Linux価格 https://azure.microsoft.com/ja-jp/pricing/details/virtual-machines/linux/#fsv2-series
• Windows価格 https://azure.microsoft.com/ja-jp/pricing/details/virtual-machines/windows/#fsv2-series

Azure は最初は Windows のみで、その後 Linux が追加されました。いくら自社開発とはいえ Windows の開発コストがゼロとは思いませんので、Windows をなるべく使ってもらうために、戦略的に Linux のコストを高くしたとのでは、と当ページ管理人は想像します。

GCP の Compute Engine の場合、インスタンスの料金と、ライセンスの料金が「プレミアムイメージ」としてきっちり分けられています。2020年1月時点でのライセンス料金は下記のとおりになります。

• 無償の Linux (CentOS・Ubuntu 等)
  • 無償
• Red Hat Enterprise Linux
  • インスタンスあたり 0.06 USD/時間。vCPU 4 個以下
  • インスタンスあたり 0.13 USD/時間。vCPU 5 個以上
• Windows Server
  • f1-micro・g1-small の場合、0.02 USD/時間
  • 上記以外の場合、1コアあたり 0.04 USD/時間

以下、クラウド化でライセンスがシンプルになったんだけど、シンプルでないところも残っているよという話です。

シンプルでない話その1:ライセンス持ち込み (BYOL)

オンプレミス用のライセンスをお持ちの場合、「持ち込み (BYOL)」という仕組みを使って、クラウド上でのライセンスコストを削減できる可能性があります。複雑怪奇な世界になっているので頑張って調査してみてください。

• AWS での Microsoft ライセンシング
  • https://aws.amazon.com/jp/windows/resources/licensing/
• Amazon RDS と Oracle ライセンス
  • https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html#Oracle.Concepts.Licensing
• Azure Hybrid Benefit について
  • https://azure.microsoft.com/ja-jp/pricing/hybrid-benefit/faq/
• GCP での Windows Server 関連ライセンス
  • https://cloud.google.com/compute/docs/instances/windows/bring-your-own-license/?hl=ja
  • https://cloud.google.com/compute/docs/instances/windows/ms-licensing?hl=ja

シンプルでない話その2: CAL (クライアントアクセスライセンス)

Windows Server における CAL (クライアントアクセスライセンス) とは、Windows Server にアクセスする利用者に対するライセンスです。

Windows マシンを一人だけが使う場合はシンプルなのですが、Windows マシンが Web サーバとなって数千人・数万人から利用される場合のライセンスとして、ユーザ CAL というものが必要になります。

実際はもっと複雑で、インターネット経由で、認証なしで使う場合は CAL は不要だったりするのですが、一般的には以下のようにすることが多かったのではないかと推測します。

• イントラ内での数十人～数百人程度の利用であれば CAL を購入
• それ以上またはインターネット経由での利用であれば DataCenter Edition を購入

めでたいことに、AWS・Azure・GCP の Windows Server・SQL Server においては、CAL が必要ないライセンス体系になっているので、CAL の購入は不要です。

しかしながら、管理用 CAL についてはまた別の話であり、AWS において Windows Server へのリモートデスクトップサービス (RDS) のセッション数は2のようです。これを増やす場合、CAL 購入が別途必要なようです。

• 参考： https://forums.aws.amazon.com/thread.jspa?messageID=530873

シンプルでない話その3：専有サーバの場合

AWS の Dedicated Hosts・Azure の Dedicated Host・GCP の単一テナントノード (Solo-tenant node) などの、いわゆる専有サーバにおいては、ライセンスの考え方はオンプレミスと全く同じになります。必要なライセンスは自分で購入することになります。

下記も参考にしてください。

• クラスメソッドブログ：2019年10月1日以降のDedicated HostsにおけるMicrosoft製品ライセンスについて
  • https://dev.classmethod.jp/cloud/aws/microsoft-updated-licensing-rights-for-dedicated-cloud/