基礎知識

AWS・Azure・Google Cloudの違い。3社の比較と選び方

クラウドを選ぶとき、3社の違いが分かりにくいという声をよく聞きます。この記事では、それぞれの位置づけと、実務でどう選ぶべきかを整理します。

3社の位置づけ

クラウド事業者は複数ありますが、主要な選択肢は3つです。

AWS。最も早く始まり、サービスの種類が最多です。導入事例と情報が豊富で、扱える技術者も多くなります。

Microsoft Azure。Windows環境やOffice製品との連携に強みがあります。既にMicrosoft製品を全社導入している企業では、選定の第一候補になります。

Google Cloud。データ分析と機械学習の領域に強みがあります。BigQueryを目的に選ばれる例も多くあります。

基本的な機能は3社とも揃っています。サーバー、保管、データベース、ネットワーク。差が出るのは、周辺のサービスと既存環境との相性です。

名前が違うだけのもの

比較を難しくしている要因のひとつが、名称の違いです。同じ役割でも、事業者ごとに呼び方が異なります。

• 仮想サーバー／AWS: EC2、Azure: Virtual Machines、Google: Compute Engine
• ファイル保管／AWS: S3、Azure: Blob Storage、Google: Cloud Storage
• コード実行／AWS: Lambda、Azure: Functions、Google: Cloud Functions
• コンテナ基盤／AWS: EKS、Azure: AKS、Google: GKE

役割の対応が分かれば、比較はかなり容易になります。「AWSのS3」と言われたとき、ファイルを置く場所だと分かれば会話は成立します。

1社を深く理解すれば、他社への移行は難しくありません。概念は共通しているためです。

選定の判断基準

実務で何を基準に選ぶかを整理します。

既存環境との相性。Microsoft製品中心ならAzure、データ分析が主目的ならGoogle Cloud。この要素が最も大きく効きます。

社内の技術者。扱える人がいるかどうか。学習の時間も費用のうちです。

必要なサービスの有無。特定の機能が目的なら、それを持つ事業者を選びます。

費用。単純な比較は困難です。構成と使用量で変わるため、実際の想定に基づいた試算が必要になります。

規制や社内方針。データを国内に置く必要がある場合、対応地域を確認します。

技術的な優劣で選ぶ場面は、実は多くありません。

費用の構造

クラウドの費用は、従来と考え方が異なります。

初期費用が小さく、使った分だけ支払うのが基本です。機器を買う必要がなく、規模の変更も容易になります。

一方、想定より高くなる例も多くあります。原因は3つです。

使っていない資源を止め忘れる。検証用に立てたものが動き続けている。最も多い無駄です。

通信量。クラウドから外部へデータを出す際に課金される場合があります。見落とされやすい項目です。

過剰な構成。必要以上に大きな構成を選んでいる。まず小さく始め、必要に応じて増やすのが原則です。

複数を併用する場合

1社に絞らず、複数を使う構成もあります。

目的は、依存の回避と、各社の強みの活用です。分析はGoogle Cloud、業務システムはAzure、といった使い分けです。

ただし、運用の負担は明確に増えます。それぞれの知識が必要になり、監視も権限管理も二重になります。

小規模な組織では推奨されません。1社に集約するほうが、費用も運用も抑えられます。

現実的なのは、主軸を1社に置き、特定用途だけ別社を使う形です。全面的な併用は、相応の体制がある場合に限られます。

導入の進め方

これから使い始める場合の順序を示します。

• ①小さく試す／検証用の環境で、実際に動かしてみる
• ②影響の小さい業務から／止まっても致命的でないものを先に移す
• ③費用の監視を先に設定／上限の警告を必ず入れる
• ④権限を整理する／誰が何をできるか。初期に決めておく
• ⑤構成をコードで管理する／手作業の設定は、再現できず引き継げない

③と④は後回しにされがちですが、先に決めておくべきです。費用が膨らんでから、あるいは事故が起きてから対処するのでは遅くなります。

この領域で働くには

クラウドを扱う人材について整理します。

必要なのは、ネットワークとサーバーの基礎知識です。クラウド上でも、IPアドレスの設計や通信の制御という概念は同じです。

資格が実務と結びつきやすい領域でもあります。3社とも認定資格を用意しており、案件の要件になることがあります。

1社を深く学ぶことを勧めます。3社を浅く知るより、1社を実務水準で扱えるほうが評価されます。移行も難しくありません。

単価は月額70〜110万円の範囲が中心で、設計まで担える場合は上限に近づきます。この数字は民間各社の集計で、公的統計ではありません。

特定事業者への依存

選定時に検討すべき論点として、依存の問題があります。

各社の独自機能を使うほど、移行が難しくなります。仮想サーバーだけなら移せますが、その事業者にしかないサービスを組み込むと、乗り換えの費用が跳ね上がります。

ただし、依存を避けること自体が目的化すると、利点を活かせません。共通機能だけを使う構成は、運用の手間が増えます。

現実的な判断は、重要度で分けることです。中核となるデータと処理は移しやすい構成にし、周辺は各社の便利な機能を使う。

また、価格交渉の観点でも、完全な依存は不利になります。長期の契約では、この点も考慮されます。

地域と法規制

データをどこに置くかは、技術以外の要因で決まる場合があります。

各社とも、世界各地に拠点を持ちます。日本国内の拠点を選べば、データは国内に保管されます。

規制で国内保管が求められる場合があります。公共分野や金融、医療の一部がこれにあたります。

社内規程で定められている場合もあります。海外拠点の利用を禁じている企業は珍しくありません。

技術的には、近い拠点のほうが応答が速くなります。利用者の所在地に合わせた選択も、性能に影響します。

選定の初期段階で、この制約を確認しておく必要があります。後から判明すると、構成の見直しになります。