第1回では、クラウドの定義と責任共有モデルを見ました。AWS を実際に使い始めると、最初に出会うのが リージョン・AZ・アカウント・料金 です。どれも画面の上では1行の選択肢ですが、どこに置くかで可用性が、どのアカウントで作るかで権限と請求の境界が、何を動かしたままにするかで料金が決まります。ここを知らないと、冒頭のような勘違いや「無料のはず」の請求が起きます。

第2回では、AWS のグローバルなインフラ（リージョン・AZ・エッジロケーション・Local Zones・Wavelength）、AZ 名と AZ ID、AWS アカウントとルートユーザー、操作の手段、ARN とサービスエンドポイント、料金の構成要素、無料利用枠、Azure との対応を扱います。数値と料金は2026年9月時点で、料金は東京リージョンの例です。

グローバルインフラストラクチャの規模

AWS の基盤は、大きい順に リージョン ⊃ AZ ⊃ データセンター（DC） の階層になっています。エッジロケーションや Local Zones は、リージョンの外側に置かれた延長です。

• リージョン：39の地理的なエリア（2026年9月時点。サウジアラビア・チリの2つも発表済み。最新の数は公式の「グローバルインフラストラクチャ」のページ aws.amazon.com/about-aws/global-infrastructure/ で確かめる）。日本は 東京（ap-northeast-1、2011年）と大阪（ap-northeast-3、2021年）
• アベイラビリティーゾーン（AZ）：全体で120を超える。1つの AZ は1つ以上の DC でできていて、AZ どうしは数 km〜100 km 程度離れ、独立した電源・空調・ネットワーク を持つ。AZ 間は専用の低遅延の回線で結ばれ、遅延は1桁ミリ秒（同期レプリケーションができる程度）。1つのリージョンに3つ以上
• エッジロケーション：CloudFront・Route 53 などが使う数百の拠点（後の「エッジロケーション・Local Zones・Wavelength」の節）
• Local Zones：特定の都市に置かれた AZ の小型版。低遅延が必要な用途向け
• Outposts：AWS のラックを利用者の DC に置き、同じ API で使う（プライベートクラウド的な使い方。第1回の「配置モデル」）
• 東京リージョンで使える AZ は3つ（AZ ID：apne1-az1・az2・az4。次の次の節「AZ 名と AZ ID」）

リージョンと AZ

リージョンは地理的に独立したエリアで、リージョン間はデータもコントロールプレーンも原則として分離 されています。東京リージョンに作った EC2 は大阪リージョンの画面には出てきませんし、リージョン間の通信は、インターネット経由か AWS のバックボーン経由で明示的に設計する必要があります。

AZ はリージョンの中の独立した DC 群で、1つの AZ 全体が停止しても、ほかの AZ は動き続けるように設計されています。AWS の上での可用性の設計の基本は 「複数の AZ にまたがって配置する」 ことで、ELB・Auto Scaling（第4回）、RDS のマルチ AZ（第10回）は、いずれもこの前提で動きます。逆に、単一の AZ だけに置いたシステムは、AZ の障害（東京でも2019年8月に冷却の障害で発生）でそのまま止まります。

リージョンは、利用者との距離（遅延）、データの所在の規制、必要なサービスの提供の有無（新しいサービスは米国から順に展開）、料金（東京は米国東部より1〜2割高い） の4点で選びます。

• リージョン＝独立したエリア。リージョン間は 明示的に設計しないとつながらない
• AZ＝リージョンの中の独立した DC 群。マルチ AZ が可用性の設計の基本の単位
• 選ぶ基準：遅延・規制・サービスの提供の有無・料金

AZ の中・複数の AZ・リージョンをまたぐという冗長の範囲の考え方は、このブログの連載「ストレージ入門」第11回の「冗長の範囲：AZの中・複数のAZ・リージョン」でも扱います。

AZ 名と AZ ID

コンソールに出る ap-northeast-1a のような名前と、実際の物理的な AZ の関係には注意が要ります。

• 東京のように2012年11月より前に開設されたリージョンでは、コンソールに出る ap-northeast-1a のような AZ 名と物理的な AZ の対応が、アカウントごとに異なる（2025年10月までに作ったアカウントの場合。負荷を分散するため）。A 社の 1a と B 社の 1a は、別の DC の可能性がある。大阪など新しいリージョンと、2025年11月以降に作ったアカウントでは対応は共通
• 物理的な AZ を一意に指す識別子が AZ ID（apne1-az1 など）。複数のアカウントの間で「同じ AZ に置いて遅延を下げたい」「AZ の障害の影響範囲を突き合わせたい」ときは、AZ ID で比べる
• 確かめ方：aws ec2 describe-availability-zones --region ap-northeast-1 の ZoneId の列
• 東京の apne1-az3 は新しいアカウントには開放されておらず、使えるのは az1・az2・az4 の3つ
• ネットワークの「同じセグメント」の感覚に近いのは AZ の中。AZ をまたぐ通信には、データ転送料（1 GB あたり 0.01 USD を双方向で。第12回）と遅延（AWS の説明では1桁ミリ秒）が乗る

冒頭の1つ目の相談がこれです。自分の ap-northeast-1a と取引先の ap-northeast-1a が同じとは限りません。AZ ID を突き合わせて 確かめます。「同じセグメントなら直接届き、違えばゲートウェイを経由する」という判定は、このブログの連載「TCP/IP入門」第7回の「デフォルトゲートウェイと宛先の判定」で扱います。

AZ 名と AZ ID の対応は、次のように表にして見ると分かりやすくなります（出力はアカウント A の場合の例）。

$ aws ec2 describe-availability-zones --region ap-northeast-1 \
    --query "AvailabilityZones[].[ZoneName,ZoneId]" --output table
-------------------------------------
|     DescribeAvailabilityZones     |
+------------------+----------------+
|  ap-northeast-1a |  apne1-az4     |
|  ap-northeast-1c |  apne1-az1     |
|  ap-northeast-1d |  apne1-az2     |
+------------------+----------------+

エッジロケーション・Local Zones・Wavelength

リージョンの外にも、利用者の近くで動く拠点があります。

• エッジロケーション：CloudFront（CDN）・Route 53（DNS）・AWS WAF・Global Accelerator が動く拠点。リージョンより多く、利用者の近くに置かれている。東京・大阪にも複数ある
• リージョナルエッジキャッシュ：エッジロケーションとオリジンの間にある中間のキャッシュの層
• Local Zones：都市部に置く EC2・EBS・VPC のサブセット。親リージョンの VPC を延長して使う。東京リージョン（ap-northeast-1）を親とする Local Zone は、台北（ap-northeast-1-tpe-1）に提供されている（2026年9月時点）
• Wavelength：通信事業者の 5G 網の中に置く拠点（日本では KDDI）。モバイル端末からの超低遅延の用途に使う
• 用途の違い：エッジは 「配信・名前解決を近くで」 行い、Local Zones は 「計算資源を近くに」 置く

Route 53 と CloudFront は第7回で扱います。Route 53 の DNS の機能は、このブログの連載「DNS入門」第10回「クラウド・社内環境のDNS」でも詳しく扱っています。

AWS アカウントとルートユーザー

AWS を使う単位は 「AWS アカウント」 で、契約・請求・リソースの境界 になります。アカウントを作ったときのメールアドレスとパスワードでログインするのが 「ルートユーザー」 で、請求の情報の変更、アカウントの閉鎖、サポートプランの変更、一部の S3 の設定など、IAM ユーザーではできない操作を含む 全権限 を持ちます。

そのため、ルートユーザーは日常の作業に使わず、MFA を設定し、アクセスキーは作らず、パスワードは金庫のように管理する のが原則です。AWS も、2024年5月に Organizations の管理アカウント、2024年6月に単独のアカウント、2025年6月にはメンバーアカウントを含むすべてのアカウントで、ルートユーザーの MFA を必須にしました。

実際の作業は IAM ユーザーか IAM ロール（第8回）で行い、複数のアカウントを部門・環境ごとに分けて Organizations（第8回）で束ねる構成が標準的になっています。1つのアカウントで全部を賄うと、権限の分離も請求の切り分けもできなくなります。

• アカウント＝契約・請求・リソースの境界
• ルートユーザー＝全権限。MFA 必須・アクセスキー禁止・日常には使わない
• 作業は IAM、複数のアカウントは Organizations で管理

アクセスの手段：コンソール・CLI・SDK・IaC

AWS を操作する手段はいくつかありますが、どの手段も最終的には同じ REST API を呼びます。

• マネジメントコンソール：ブラウザの GUI。学習・確認・単発の作業向け。裏では API を呼んでいる
• AWS CLI（v2）：aws <サービス> <操作> の形式（例は下のコマンド）
• SDK：Python（boto3）・Java・JavaScript など。アプリケーションから AWS を操作する
• IaC：CloudFormation・CDK・Terraform で構成をコードにする（第12回）。本番は手作業ではなく IaC が原則
• CloudShell：コンソールの中で使えるブラウザ上のシェル。CLI が設定済みで、手元に環境が無くても試せる
• どの手段も最終的には同じ REST API を呼ぶ。API の呼び出しは CloudTrail（第11回）にすべて記録される

$ aws sts get-caller-identity          # 今どの認証情報で操作しているか
$ aws ec2 describe-instances --query "Reservations[].Instances[].[InstanceId,State.Name]" --output table
$ aws s3 cp ./log.txt s3://my-bucket/logs/

最初の aws sts get-caller-identity は、作業の前に「どのアカウントの、どのユーザー・ロールで操作しているか」を確かめるコマンドです。次のような JSON が返ります（値は例）。

{
    "UserId": "AIDAEXAMPLEUSERID1234",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/tanaka"
}

リソースの識別：ARN とサービスエンドポイント

AWS のリソースは、ARN（Amazon Resource Name） で一意に識別します。

• すべてのリソースは ARN で一意に識別される。書式は arn:partition:service:region:account-id:resource
• 例：arn:aws:s3:::my-bucket/logs/*（S3 のバケットはバケット名だけで全体で一意に決まるので、リージョンとアカウントが空）、arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abc123def456、arn:aws:iam::123456789012:role/AppRole（IAM はグローバルなのでリージョンが空）、arn:aws:lambda:ap-northeast-1:123456789012:function:hello
• IAM ポリシー（第8回）の Resource で対象を指定するのに使う。ワイルドカード * が使える
• サービスエンドポイント：API の接続先は https://ec2.ap-northeast-1.amazonaws.com のように、サービスとリージョンで決まる。DNS の名前解決のとおり、名前は AWS 側の IP アドレスに解決される。VPC エンドポイント（第7回）を使うと、この名前が VPC の中のプライベート IP に解決されるようになる
• グローバルサービス（IAM・Route 53・CloudFront・Organizations）と リージョナルサービス（EC2・VPC・RDS・Lambda など。S3 のバケットもリージョンに作られる）の区別を意識する

名前解決の流れ（スタブリゾルバーからキャッシュ DNS サーバーへの問い合わせ）は、このブログの連載「DNS入門」第3回「名前解決の流れ」で詳しく扱っています。

料金の構成要素

AWS の料金は、おおむね 「コンピューティング（時間）＋ストレージ（GB・月）＋リクエスト数＋データ転送（GB）」の合計 です。サービスごとに単価表があり、リージョンで異なります。

• 時間課金：EC2・RDS・NAT ゲートウェイなど。EC2 は秒単位（最低60秒、Linux の場合）。停止中は EC2 本体の課金は止まるが、EBS は続く（第4回）
• 容量課金：S3・EBS・EFS。GB・月で数える。EBS は確保した容量、S3 は実際に置いた容量。スナップショットも容量で課金される
• リクエスト数：Lambda・API Gateway・S3 の PUT・GET・DynamoDB など
• データ転送：インバウンドは無料、インターネットへのアウトバウンドが有料（東京：最初の 100 GB/月は無料（全リージョン合計）、以降は約 0.114 USD/GB）。AZ 間・リージョン間も有料（第12回）。「入れるのはタダ、出すと高い」
• パブリック IPv4：2024年2月から、1アドレスあたり 0.005 USD/時（約 3.6 USD/月）。EIP も、使用中でも課金される
• 見積は AWS Pricing Calculator（公式）で行う。東京は米国東部より1〜2割高い

見落としがちな費用は次のとおりです（東京リージョンの例、2026年9月時点）。

冒頭の2つ目の相談は、多くがこれです。検証で作った NAT ゲートウェイや EIP、パブリック IPv4 を持つ EC2 を 止めたり消したりせずに置いたまま にすると、触っていなくても時間で課金されます。

無料利用枠（2025年7月の改定）

AWS の無料利用枠は、2025年7月に仕組みが大きく変わりました（2026年9月時点の内容）。

• 2025年7月15日以降に作ったアカウントは、「無料プラン」か「有料プラン」を選ぶ 方式に変わった
• 無料プラン：最大6か月、最大 200 USD のクレジット（登録時に 100 USD＋所定の作業を終えると最大 100 USD）の範囲で使える。クレジットか期間が尽きるとアカウントが閉じられ（90日以内に有料プランへ切り替えないと削除）、課金は発生しない。Savings Plans・リザーブドインスタンス・一部の Marketplace の製品など、クレジットを一度に使い切るおそれのあるものは使えない
• 有料プラン：従来どおりの従量課金。クレジットは同じように付与される。本番・長期の利用向け
• 常時無料枠 は続く：Lambda 月100万リクエスト、DynamoDB 25 GB、CloudWatch の基本メトリクス、CloudFront 月 1 TB の転送、SNS 100万パブリッシュなど
• 改定前（2025年7月15日より前）のアカウントには、従来の 「12か月無料枠」（EC2 の t2・t3.micro 750時間/月など）が適用される
• 検証で無料枠を使う場合でも、Budgets（第12回）で上限のアラートを必ず設定する。「無料のはず」の請求は、初めての人の定番の事故

冒頭の2つ目の相談の続きです。有料プランを選んだアカウントや、改定前のアカウントでは、無料の範囲を超えた分はそのまま請求されます。アカウントを作ったら最初に Budgets を設定する、と覚えてください。

Azure との対応表①：全体像

ここまでの AWS の用語を、Azure の用語と対応させます。

いちばん違うのは、Azure ではすべてのリソースが必ずリソースグループに属する ことと、ID の基盤が Entra ID に統合されている ことです。AWS のアカウントに当たるのはサブスクリプションですが、ユーザーの管理はその上のテナント（Entra ID）で行います。

考えてみよう

1. 自分のアカウントで aws ec2 describe-availability-zones --region ap-northeast-1 を実行し、ap-northeast-1a がどの AZ ID に当たるかを確かめてみましょう。同僚のアカウントと比べるとどうなるでしょうか
2. 検証用のアカウントで、ルートユーザーに MFA が設定されているか、ルートユーザーのアクセスキーが残っていないかを確かめてみましょう
3. EC2（パブリック IPv4 付き）と NAT ゲートウェイを1か月動かしたままにすると、何に料金がかかるでしょうか。AWS Pricing Calculator で見積もってみてください

ヒント：1は「AZ 名と AZ ID」、2は「AWS アカウントとルートユーザー」、3は「料金の構成要素」と「無料利用枠（2025年7月の改定）」の節を見直してください。

まとめ

• AWS の基盤は リージョン ⊃ AZ ⊃ DC。日本は東京（ap-northeast-1）と大阪（ap-northeast-3）
• 可用性の設計の基本は マルチ AZ。リージョン間は明示的に設計しないとつながらない
• 東京など古いリージョンでは AZ 名と物理的な AZ の対応がアカウントごとに異なることがある。物理的な AZ を比べるときは AZ ID
• エッジは「配信・名前解決を近くで」、Local Zones は「計算資源を近くに」
• アカウントは契約・請求・リソースの境界。ルートユーザーは MFA・アクセスキー禁止・日常に使わない
• 操作はどの手段も同じ API。本番は IaC、記録は CloudTrail。リソースは ARN で識別
• 料金は時間・容量・リクエスト・転送の合計。「入れるのはタダ、出すと高い」、検証でも Budgets を最初に

次回は、コンピューティングの前編として、EC2 と Nitro System・Graviton、インスタンスタイプ、AMI と起動テンプレート、EBS とインスタンスストア、ログインの手段、IMDS を扱います。

連載「クラウド入門」全14回

1. クラウドとは（定義・歴史・責任分界）
2. AWSの全体像（この記事）
3. コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
4. コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
5. ストレージ
6. ネットワーキング 前編（VPC・サブネット・SG・NACL）
7. ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
8. IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
9. IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
10. データベース
11. 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
12. 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
13. Well-Architectedフレームワーク
14. これまでのテーマとAWSの対応・まとめ

どちらも、クラウドの話になるとよく聞く言葉です。オンプレミスで 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、仮想化基盤との違い、クラウドが向くケース・向かないケースを扱います。

クラウドの歴史（年表）

まず、クラウドがどう広がってきたかを年表で見ます。

世界のシェアは、おおよそ 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つの配置モデル（パブリック・プライベート・コミュニティ・ハイブリッド）は誰と基盤を共有するかの違いです。どちらも、この後の節で表にします。

オンプレミスとクラウドの比較

オンプレミスとクラウドを、費用・調達・運用の観点で比べます。

オンプレミスでは、ピークを見込んで機器を買い、数年かけて償却します。見込みが外れれば、余るか足りないかのどちらかです。クラウドでは 必要なときに必要な分だけ確保し、使った分だけ払います。ただし、どちらが安いかは負荷の形で変わります（最後の節「クラウドが向くケース・向かないケース」）。

サービスモデル：IaaS・PaaS・SaaS と管理範囲

サービスモデルは、どの層までを事業者が管理するか の違いです。

右へ行くほど運用の負荷は減り、自由度（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 側へ動くこと

責任共有モデル：サービスごとの境界

代表的なサービスで、項目ごとに誰の責任かを比べます。

どのサービスでも、「データ」「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 と呼んで整理しているものです。

移行の計画では、まず対象のシステムを棚卸しして、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）で扱う

考えてみよう

1. 自分の職場の仮想化基盤は、NIST の5つの特徴のうちどれを満たし、どれを満たしていないでしょうか。VM を1台作るのに、申請から何日かかりますか
2. EC2 に MySQL を入れた構成と、RDS を使った構成で、OS のパッチとバックアップは誰の責任になるでしょうか
3. 身の回りのシステムを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回

1. クラウドとは（定義・歴史・責任分界）（この記事）
2. AWSの全体像
3. コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
4. コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
5. ストレージ
6. ネットワーキング 前編（VPC・サブネット・SG・NACL）
7. ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
8. IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
9. IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
10. データベース
11. 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
12. 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
13. Well-Architectedフレームワーク
14. これまでのテーマとAWSの対応・まとめ