「うちにも VMware の仮想化基盤があります。VM を切り出して使っているので、もうクラウドと同じですよね」
「AWS に移せば、セキュリティは AWS が守ってくれるので、OS のパッチは当てなくてよいですよね」
どちらも、クラウドの話になるとよく聞く言葉です。オンプレミスで DNS・TCP/IP・認証・ストレージなどを扱ってきたエンジニアなら、クラウドの設定画面に並ぶ項目の多くは、知っている仕組みが「サービス」になったものです。仕組みを知っていれば項目の意味はすぐ分かります。逆に、仕組みを知らずにサービスの名前だけを覚えると、設計の判断ができません。
この連載では、クラウドの基礎を 「オンプレミスで学んだ概念が、クラウドでは何に当たるか」 という軸で整理します。題材は AWS の主要なサービスで、制限値・料金の構造・設定例まで具体的に扱い、要所で 「Azure では何と呼ぶか」 を添えます。オンプレのテーマ（DNS・TCP/IP・認証など）は、このブログの連載「DNS入門」「TCP/IP入門」などで詳しく扱っています（これから扱うものもあります）。各回の要所でその回を案内し、最終回の第14回で一覧にします。目指すのは、設定画面の項目を「オンプレでは何だったか」で読めること、サービス名の暗記ではなく組み合わせ方を判断できること、そして Azure の担当者とも同じ語彙で会話できることです。仕組みは同じで、変わるのは名前と操作です。
連載は 全14回 です。第2回で AWS の全体像を見たあと、コンピューティング（第3・4回）、ストレージ（第5回）、ネットワーキング（第6・7回）、IAM とセキュリティ（第8・9回）、データベース（第10回）、運用・監視・コスト（第11・12回）の順に、主要なサービスを見ていきます。第13回では、AWS の設計原則 Well-Architected フレームワーク を扱い、サービスを「どう組み合わせるか」の判断の軸を持ち帰っていただきます。
数値・上限・料金は 2026年9月時点 のもので、料金は 東京リージョン（ap-northeast-1）の例 です。クラウドの料金や仕様はよく変わるので、使う前に公式のページで確かめてください。
第1回では、クラウドの歴史と定義、オンプレミスとの違い、IaaS・PaaS・SaaS、責任共有モデル、配置モデル、移行の7R、仮想化基盤との違い、クラウドが向くケース・向かないケースを扱います。
クラウドの歴史（年表）
まず、クラウドがどう広がってきたかを年表で見ます。
| 年 | 出来事 |
|---|---|
| 2004 | Amazon が SQS（メッセージキュー）を公開。AWS 最初のサービス |
| 2006 | Amazon S3（3月）と EC2（8月、ベータ）を公開。「クラウド元年」とされる |
| 2008 | Google App Engine（PaaS）公開。Microsoft が Windows Azure を発表 |
| 2010 | Windows Azure が正式提供開始（2014 年に Microsoft Azure へ改称） |
| 2011 | AWS 東京リージョン開設（3月） |
| 2014 | Azure 日本（東日本・西日本）リージョン開設。AWS Lambda 発表（サーバーレスの始まり） |
| 2016 | Google Cloud 東京リージョン開設 |
| 2021 | AWS 大阪リージョンが通常リージョンに昇格（2018 年からはローカルリージョン） |
| 2024〜 | 生成 AI（Bedrock／Azure OpenAI）を軸にした投資競争。データセンター電力が制約に |
世界のシェアは、おおよそ AWS が3割弱・Microsoft（Azure）が2割・Google が1割半 で推移しています（Synergy Research の推計で、2026年4〜6月期は AWS 28%・Microsoft 20%・Google 15%。正確な値は時点により変わります）。この連載が AWS を中心に Azure を添えるのは、この2つで市場の半分近くを占めるからです。
NIST によるクラウドの定義
「クラウド」という言葉は広く使われますが、事実上の標準の定義があります。米国 NIST（国立標準技術研究所）の SP 800-145（2011年）で、5つの特徴・3つのサービスモデル・4つの配置モデル でクラウドを整理しています。
- オンデマンド・セルフサービス：人手（申請書・電話）を介さず、利用者自身が画面や API で確保できる
- 幅広いネットワークアクセス：標準的なネットワーク（HTTPS など）経由で利用できる
- リソースの共用（プーリング）：多数の利用者で物理資源を共有し、需要に応じて割り当てる（マルチテナント）
- 迅速な弾力性：需要に応じて数分で増減できる。利用者からは無限に見える
- 計測されたサービス：利用量を計測し、それに基づいて課金・制御する（従量課金の根拠）
- 「仮想化基盤を持っている」だけでは、この5つを満たしておらず、クラウドとは呼べない（後の「仮想化基盤とクラウドは何が違うか」の節）
3つのサービスモデル（IaaS・PaaS・SaaS）は管理範囲の境界の違いで、4つの配置モデル（パブリック・プライベート・コミュニティ・ハイブリッド）は誰と基盤を共有するかの違いです。どちらも、この後の節で表にします。
オンプレミスとクラウドの比較
オンプレミスとクラウドを、費用・調達・運用の観点で比べます。
| 観点 | オンプレミス | クラウド |
|---|---|---|
| 費用の性質 | 設備投資（CAPEX）。減価償却 | 運用費（OPEX）。月次の従量課金 |
| 調達のリードタイム | 数週間〜数か月（見積・発注・搬入・設置） | 数分（API 呼び出し） |
| キャパシティ | ピークに合わせて事前に確保。余剰か不足のどちらか | 需要に合わせて増減。使った分だけ払う |
| 物理層の運用 | 自社（電源・空調・HW 保守・DC 入退室） | 事業者（利用者からは見えない） |
| 拡張の単位 | サーバー 1 台・ラック 1 本 | インスタンス 1 台・GB・リクエスト数 |
| 障害時の責任 | すべて自社 | 責任共有モデルで分担（次の次の節「責任共有モデル」） |
| 向く用途 | 常時一定負荷・法規制でデータ所在が縛られる・既存資産の償却中 | 変動負荷・新規開発・グローバル展開・検証環境 |
オンプレミスでは、ピークを見込んで機器を買い、数年かけて償却します。見込みが外れれば、余るか足りないかのどちらかです。クラウドでは 必要なときに必要な分だけ確保し、使った分だけ払います。ただし、どちらが安いかは負荷の形で変わります（最後の節「クラウドが向くケース・向かないケース」）。
サービスモデル：IaaS・PaaS・SaaS と管理範囲
サービスモデルは、どの層までを事業者が管理するか の違いです。
| レイヤー | オンプレ | IaaS（EC2） | PaaS（RDS／App Service） | SaaS（Microsoft 365） |
|---|---|---|---|---|
| アプリケーション | 利用者 | 利用者 | 利用者 | 事業者 |
| データ | 利用者 | 利用者 | 利用者 | 利用者（内容の責任） |
| ランタイム／ミドルウェア | 利用者 | 利用者 | 事業者 | 事業者 |
| OS | 利用者 | 利用者 | 事業者 | 事業者 |
| 仮想化 | 利用者 | 事業者 | 事業者 | 事業者 |
| サーバー／ストレージ／NW | 利用者 | 事業者 | 事業者 | 事業者 |
| 物理 DC | 利用者 | 事業者 | 事業者 | 事業者 |
右へ行くほど運用の負荷は減り、自由度（OS への root でのログイン、独自のミドルウェアの導入）も減ります。同じ「DB を動かす」でも、EC2 に MySQL を入れれば IaaS、RDS を使えば PaaS になります。EC2 は第3回、RDS は第10回で扱います。
責任共有モデル
AWS は「クラウドのセキュリティは AWS、クラウド内のセキュリティは利用者」という言葉で責任の分界を説明しています。物理施設の入退室、電源・空調、ハードウェアの交換、ハイパーバイザーやネットワーク機器の脆弱性への対応、リージョン間の光ファイバーといった基盤は AWS が担います。利用者は SOC 報告書などで監査の結果を確かめることはできても、直接手を入れることはできません。
一方、ゲスト OS のパッチ、ファイアウォール（セキュリティグループ）の設定、IAM の権限の設計、保存データや通信の暗号化、アプリケーションの脆弱性は利用者の責任で、「AWS を使っているから安全」にはなりません。冒頭の2つ目の相談の答えがこれで、EC2 に移したなら OS のパッチは利用者が当てます。境界線はサービスによって動き、EC2 なら OS から上が利用者、RDS なら OS とミドルウェアは AWS、Lambda ならコードとデータだけが利用者 になります（次の節）。
- クラウド“の”セキュリティ＝AWS（物理・基盤・ハイパーバイザー）
- クラウド“内”のセキュリティ＝利用者（OS・NW の設定・IAM・データ）
- 境界はサービスごとに違う。「マネージド」とは 境界が AWS 側へ動くこと
責任共有モデル：サービスごとの境界
代表的なサービスで、項目ごとに誰の責任かを比べます。
| 項目 | EC2 | RDS | Lambda／S3 |
|---|---|---|---|
| 物理・ハイパーバイザー | AWS | AWS | AWS |
| OS のパッチ | 利用者 | AWS（メンテナンスウィンドウで適用） | AWS |
| ミドルウェア（DB エンジン等） | 利用者 | AWS（マイナー版の自動適用は利用者が選択） | AWS |
| ネットワーク制御（SG／NACL） | 利用者 | 利用者 | S3 はバケットポリシー、Lambda は IAM |
| バックアップ | 利用者 | AWS が自動取得（保持期間は利用者が設定） | S3 は複製済み（削除保護は利用者） |
| データの暗号化・分類 | 利用者 | 利用者 | 利用者 |
| IAM・認証情報の管理 | 利用者 | 利用者 | 利用者 |
どのサービスでも、「データ」「IAM」「利用者側の設定」は利用者の責任として残ります。マネージドサービスを選んでも、権限の設計と設定の確認は省略できません。セキュリティグループと NACL は第6回、IAM は第8回で扱います。
配置モデル：パブリック・プライベート・ハイブリッド
配置モデルは、誰と基盤を共有するか、どこに置くか の違いです。
- パブリッククラウド：AWS・Azure・Google Cloud など。事業者の共用基盤を不特定多数が利用する。この連載の主題
- プライベートクラウド：自組織専用の基盤。自社の DC に VMware・OpenStack で構築するか、事業者の専用領域（AWS Outposts、Azure Stack）を使う
- ハイブリッドクラウド：オンプレとパブリックを VPN・専用線で接続して併用する。既存資産の償却、データの所在の制約、段階的な移行のために選ばれる。日本企業の多くはこの形
- コミュニティクラウド（NIST）：特定の業界・共同体で共有する基盤。政府共通の基盤（ガバメントクラウド）は、パブリックを認定して使う形
- マルチクラウド：複数のパブリッククラウドを併用すること。事業者へのロックインの回避が目的だが、運用スキルが分散する という代償がある
オンプレと AWS をつなぐ VPN・専用線（Site-to-Site VPN・Direct Connect）は、第7回で扱います。
クラウド移行の7つの戦略（7R）
既存のシステムをクラウドへ移すときは、システムごとに次の7つのどれに当てるかを決めます。AWS が 7R と呼んで整理しているものです。
| 戦略 | 内容 | 例 |
|---|---|---|
| Rehost（リホスト） | そのまま仮想マシンへ移す（Lift & Shift） | 物理サーバー → EC2 |
| Replatform | 一部をマネージドサービスに置き換える | 自前 MySQL → RDS |
| Repurchase | SaaS へ乗り換える | 自前 Exchange → Microsoft 365 |
| Refactor（Re-architect） | クラウド前提で作り直す | モノリス → Lambda＋DynamoDB |
| Relocate | 仮想化基盤ごと移す | VMware 環境 → クラウド上の VMware（Broadcom 買収後は提供形態が変化） |
| Retire | 廃止する | 使われていないシステム |
| Retain | オンプレに残す | 法規制・レイテンシ・償却中の資産 |
移行の計画では、まず対象のシステムを棚卸しして、7R のどれに当てるかを決めます。Rehost は速いものの、クラウドの利点（弾力性・マネージド化）を活かせず、オンプレより高くつくことがあります。
仮想化基盤とクラウドは何が違うか
「うちにも VMware があるからクラウドと同じ」という誤解は多いです。ハイパーバイザーで物理サーバーを仮想化し、VM を切り出すという点は同じです。違いは、NIST の5つの特徴、特に セルフサービス・計測・弾力性 を満たすかどうかにあります。
クラウドでは、利用者が API を呼べば数十秒で VM が起動し、秒単位で計測され、不要になれば削除して課金が止まります。社内の仮想化基盤では、申請と承認を経て運用担当が VM を作り、月次で台数を数える、という運用が普通です。基盤としては同じでも、利用形態が異なります。冒頭の1つ目の相談の答えがこれで、VM を切り出せることではなく、利用者が自分ですぐ確保・削除でき、使った分が計測されるかどうかがクラウドかどうかの分かれ目です。
また、AWS の EC2 は当初 Xen を使っていましたが、2017年以降は Nitro System と呼ぶ専用のハードウェアと軽量のハイパーバイザーの組み合わせに移っており（第3回）、ストレージ・ネットワークの処理を専用のカードへ逃がして、VM の性能を物理に近づけています。オンプレの仮想化の知識は、「クラウドの下で何が起きているか」を理解する土台として、そのまま役に立ちます。
- 仮想化は手段。クラウドは 「セルフサービス・計測・弾力性」という利用形態
- EC2 の基盤は Xen → Nitro System（専用の HW＋軽量のハイパーバイザー。KVM がベース）
- Nitro Card（EBS・ENA・セキュリティ）へ処理を逃がし、ホストの CPU はほぼ VM に。ベアメタル（
*.metal）や Nitro Enclaves もこの上に成り立つ - オンプレの仮想化の知識は、クラウドの基盤の理解にそのまま使える
オンプレの仮想化基盤のストレージ（データストア・HCI）とクラウドのストレージの対応は、このブログの連載「ストレージ入門」第11回「仮想化・クラウドのストレージ」で扱います。
クラウドが向くケース・向かないケース
最後に、クラウドが向くケースと、慎重に考えるべきケースです。
- 向く：負荷が変動する（EC サイト、キャンペーン）、短期間だけ使う（検証、PoC）、早く始めたい（新規事業）、複数の拠点・海外に展開する、運用の人員が少なくマネージドに任せたい
- 向かない・慎重に：24時間365日ほぼ一定の負荷で3年以上使う（オンデマンドの単価では割高。リザーブドで緩和、第4回）、大容量のデータを頻繁に外へ出す（データ転送料、第12回）、ミリ秒以下の遅延が必要な制御系、データの所在を国内・自社内に限定する規制、既存のライセンスが仮想化・クラウドを許さない
- 「全部クラウド」でも「全部オンプレ」でもなく、システムごとに 7R で判断する のが実務。判断の軸は第13回（Well-Architected）で扱う
考えてみよう
- 自分の職場の仮想化基盤は、NIST の5つの特徴のうちどれを満たし、どれを満たしていないでしょうか。VM を1台作るのに、申請から何日かかりますか
- EC2 に MySQL を入れた構成と、RDS を使った構成で、OS のパッチとバックアップは誰の責任になるでしょうか
- 身の回りのシステムを3つ選び、7R のどれに当てるかを考えてみてください。Retain（オンプレに残す）になるのは、どんな理由のときでしょうか
ヒント：1は「NIST によるクラウドの定義」と「仮想化基盤とクラウドは何が違うか」、2は「責任共有モデル：サービスごとの境界」、3は「クラウド移行の7つの戦略（7R）」と「クラウドが向くケース・向かないケース」の節を見直してください。
まとめ
- クラウドの事実上の標準の定義は NIST SP 800-145。5つの特徴・3つのサービスモデル・4つの配置モデル
- オンプレは 設備投資（CAPEX）、クラウドは 従量課金の運用費（OPEX）。調達は数か月から数分に
- IaaS・PaaS・SaaS は 管理範囲の境界 の違い。右へ行くほど楽になり、自由度は減る
- 責任共有モデル：クラウド“の”セキュリティは AWS、クラウド“内”は利用者。データ・IAM・設定はどのサービスでも利用者
- 配置モデルはパブリック・プライベート・ハイブリッド・コミュニティ、加えてマルチクラウド。日本企業の多くはハイブリッド
- 移行は 7R でシステムごとに判断。Rehost だけでは高くつくこともある
- 仮想化基盤とクラウドの違いは セルフサービス・計測・弾力性 という利用形態
次回は、AWS の全体像として、リージョンと AZ、エッジロケーション、アカウントとルートユーザー、操作の手段、ARN、料金の構成と無料利用枠、Azure との対応を扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）（この記事）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント