AZ-900 — クラウドの概念：練習問題60問

Step 1: 共有責任モデルの基本を整理する クラウドでは責任範囲がプロバイダーと顧客で分割されます。プロバイダーは物理インフラ、ファシリティ、基盤ソフトウェアの保守やセキュリティを担い、顧客はデプロイしたリソース（例: VM 内の OS、アプリ、データ）の管理や設定、データ保護、アクセス制御を担当します。

Step 2: オプション1 とオプション3 が正しい理由 オプション1 は正しいです。Azure は物理データセンターのセキュリティ（施設のアクセス制御、電源・冷却設備、ハードウェアの保守など）を管理する責任があります。これにより顧客は物理面の保守を心配する必要がなくなります。オプション3 も正しいです。IaaS モデルでは仮想マシン上の OS のパッチ適用、ミドルウェアの設定、アプリケーションのセキュリティ対策などは顧客側が実施する責任になります。

Step 3: なぜ他の選択肢が誤りか オプション2（顧客が物理ハードウェアのメンテナンスを行う必要がある）: これは誤りです。物理ハードウェアのメンテナンスはクラウドプロバイダー（この場合 Azure）が担当します。顧客が物理サーバーに触れることは通常ありません。 オプション4（顧客がネットワークバックボーンやリージョン間の物理接続を設計する責任がある）: リージョン間の物理的ネットワークやバックボーンの設計・保守は Azure の責任範囲です。顧客は仮想ネットワークの設計や接続設定（どのリージョンにデプロイするか、VPN の設定など）は行いますが、物理インフラそのものの設計はプロバイダー側です。 Trap: よくある誤解 共有責任モデルを誤解して「クラウドに移せばセキュリティの全てが解決する」と考える人がいます。実際には、インフラ層はプロバイダーが管理しますが、OS、アプリケーション、データ、アクセス制御などは顧客の責任であり、これらを怠るとセキュリティリスクが残ります。 Why each wrong answer fails: - オプション2（顧客が物理ハードウェアのメンテナンスを行う）: Azure は物理ハードウェアの監視・修理・交換などを行います。顧客が物理機器に介入することは通常なく、これは誤りです。 - オプション4（顧客がバックボーンや物理的接続を設計する）: リージョン間ネットワークや物理バックボーンはクラウド事業者が設計し運用します。顧客はどのリージョンを使うかや仮想ネットワーク構成を決めますが、物理設計は Azure 側の責任です。 結論: 正解はオプション1 とオプション3。共有責任モデルを理解して、顧客側で実施すべき運用（OS パッチ、データ保護、アクセス管理など）を明確にしておくことが重要です。

Step 1: 要件を整理します。問題は「数分単位で急なアクセス増加が発生」し、「トラフィックに応じて自動でインスタンス数を増減し、コストを最小化したい」という点です。これはリソースの増減を自動化し、短期の需要変動に素早く対応したいという典型的な弾力性のユースケースです。

Step 2: 用語の定義を確認します。スケーラビリティ（Scalability）はシステムが負荷の増加に対応して性能を向上させられる能力（垂直/水平の拡張）を指し、設計やアーキテクチャの観点で重要です。一方、弾力性（Elasticity）はリソースを自動的かつ迅速に増減させて、実際の需要に合わせコスト効率を保つ能力を強調します。高可用性はダウンタイムを減らすこと、災害復旧は大規模障害からの回復を指します。

Step 3: 要件との照合で最適解を選びます。短時間・変動性の高い負荷に対して即時にリソースを上下させ、利用した分だけ支払うことを重視するなら弾力性が正解です。クラウドのオートスケール機能（スケールアウト/スケールイン、またはスケールアップ/スケールダウン）を利用し、負荷監視に基づくポリシーで自動化することで、ピーク時の性能確保と平常時のコスト削減を両立します。 Trap: スケーラビリティと弾力性を混同することが多い点が注意です。スケーラビリティは増加を想定した設計能力に焦点があり、弾力性は動的な増減の自動化・迅速性とコスト最適化に焦点があります。 Why each wrong answer fails: - 高可用性（High Availability）: 高可用性はサービスの継続性とダウンタイムの最小化を目的としており、負荷の増減に自動で合わせるという点では直接的に答えになりません。高可用性構成は弾力性と組み合わせることがあるが、要件の中心は自動的な増減とコスト最適化です。 - スケーラビリティ（Scalability）: スケーラビリティは必要に応じてシステムを拡張できる能力ですが、設問の「数分単位で自動的に増減しコストを最小化する」という動的・即時的な要素には、より具体的に適合するのは弾力性です。 - 災害復旧（Disaster Recovery）: 災害復旧は大規模障害からの復旧計画やデータ保護を扱う領域で、短期的なトラフィックの増減に対する自動スケールとは無関係です。

Step 1: 要件の把握 設問は「トラフィック増加時に自動でインスタンス数を増やす」とあります。これは需要に応じてリソース（インスタンス数）を増減し、処理能力を維持する能力を指しています。

Step 2: 概念の定義 スケーラビリティ（Scalability）はシステムが負荷に応じて性能や容量を向上させる能力で、水平スケーリング（インスタンスの数を増やす）や垂直スケーリング（より高スペックなインスタンスに切替える）があります。弾力性（Elasticity）は一歩踏み込んで、リソースの増減を自動で行い、コスト最適化と需要変動の吸収を実現する概念として使われることもありますが、一般的に「インスタンス数を増やす」行為はスケーラビリティの説明に最も合致します。

Step 3: 結論と適用 したがって、この要件はスケーラビリティに最も関連します。Azure のオートスケール機能を用いれば、CPU 使用率やリクエスト数に基づいて自動でインスタンスを増減できます。 Trap: よくある誤解 「弾力性（Elasticity）とスケーラビリティは同義」と見なし混同することが多いです。実務では類似して使われる場合もありますが、スケーラビリティは拡張性そのもの、弾力性はその拡張を自動的かつ迅速に行い、かつ需要が下がれば縮小してコストを削減する動作まで含めて説明するケースが多いです。 Why each wrong answer fails: 高可用性（選択肢 1）が不正解な理由：高可用性はサービスの稼働率や障害からの耐性を示します。インスタンスを増やすことで結果的に可用性が向上する場合もありますが、設問の焦点は「トラフィック増加時に処理能力を確保すること」であり、これは拡張性（スケーラビリティ）に直接対応します。 弾力性（選択肢 3）が不正解な理由：弾力性は負荷変動に応じた自動的な増減を含む概念で、今回の記述と近いものの、クラウド基本概念の区分では「インスタンス数を増やす＝スケーラビリティ」として扱うのが一般的です（特に基礎試験の文脈で）。 冗長性（選択肢 4）が不正解な理由：冗長性は単一障害点を避けるために同一機能を複数用意することを指します。負荷増加に対して自動でインスタンス数を増やすという点では冗長性は間接的に関係しますが、問題の主題である「スケールして処理能力を確保する」点には直接当てはまりません。

Step 1: 要求条件の把握 — 問題は“同一リージョン内で物理的に分離された障害ドメインにワークロードを配置したい”という点です。これはリージョンは変えずに、地理的または電源/ネットワーク的に独立した施設単位にリソースを分散したいというシナリオです。

Step 2: Azure の機能の整理 — Azure には複数の手段（アベイラビリティセット、アベイラビリティゾーン、複数リージョンへのデプロイなど）があります。アベイラビリティセットは同一データセンター内での故障ドメインや更新ドメインを考慮しますが、物理的に完全に分離された施設という意味ではアベイラビリティゾーンがより強力です。アベイラビリティゾーンは同一リージョン内にあるが物理的に別建屋・別電源・別ネットワーク経路を持つゾーンを示し、ゾーン間障害に耐える設計が可能です。

Step 3: 選択の根拠 — 「同一リージョン内で物理的に分離された障害ドメイン」という明確な要件に最も合致するのはアベイラビリティゾーンの活用です。複数ゾーンにまたがって VM やその他リソースを冗長化すれば、ゾーン単位の被害（電源・ネットワーク障害、建屋障害）からサービスを守れます。複数リージョンに展開するのは耐災害性をさらに高めますが、設問は“同一リージョン内”が前提です。 Trap: アベイラビリティセットとアベイラビリティゾーンを混同しがちです。アベイラビリティセットは同一データセンター内での冗長化を支援しますが、ゾーンとは物理的分離度合いが異なります。 Why each wrong answer fails: - 単一の仮想マシンを単一のアベイラビリティセットに配置する: アベイラビリティセットは複数 VM 間で故障ドメインを分けるためのものですが、”単一の仮想マシン”を置くだけでは冗長化にならず、物理的に分離された施設への配置という要件も満たしません。 - アプリケーションを複数のリージョンに同時にデプロイする: これも高可用性の戦略として有効ですが、設問は同一リージョン内での物理的分離を求めているため、過剰かつ要件から逸れています。リージョン間は遅延やデータ整合性、コストの面で追加の考慮が必要です。 - 同一のデータセンター内で複数の VM を配置する: 同一データセンター内に複数 VM を置く場合、データセンター単位の障害で全滅するリスクが残るため“物理的に分離された障害ドメイン”の要件に反します。したがってアベイラビリティゾーンの方が適切です。

Step 1: ワークロード特性の把握。問題は「短期間のバッチ処理でのみ大きなCPUリソースが必要」という点を強調している。したがって、長期にわたって同等のリソースを保持する必要はなく、必要なときだけリソースを確保して使い終わったら解放する戦略がコスト効率が良い。

Step 2: 各選択肢の評価。消費ベース（pay-as-you-go）でオンデマンドVMやサーバーレス（Azure Functions、Container Instances、Batchなど）を使用すれば、処理時間に応じた課金となり、短期処理では総コストが最低になる可能性が高い。対して常時大きな仮想マシンを予約して固定料金で運用する方法は、短期処理では遊休時間にコストが発生するため非効率である。リザーブドインスタンスは長期にわたる継続利用で割引が得られるが、短期バッチには向かない（前払いまたは長期コミットメントによるコスト負担が発生する）。オンプレミス専用サーバーを導入して常時待機させるのは初期投資と運用コストが高く、短期利用には不経済である。

Step 3: 実行戦略と注意点。実運用では、短期バッチはサーバーレス（Azure FunctionsやLogic Apps）、コンテナ（AKSまたはContainer Instances）、あるいはスポットインスタンスを使った大規模バースト処理で実行するのが一般的である。サーバーレスはコード実行回数や実行時間で課金され、スケールは自動化されるため、急な需要にも対応しやすい。スポット（スポットVM）は非常に低コストだが、事前通知で割り込まれる可能性があるため、処理が中断されても問題ないバッチに向く。課金面ではデータ転送費用やストレージの長期保持コストも考慮し、処理後に不要なリソースは確実に解放する運用プロセスを作ることが重要である。 Trap: よくある誤解は「予約やリザーブが常に安いからそれを選ぶべきだ」という考え。短期・突発的なワークロードでは予約は割高になることが多く、消費ベースの柔軟性を活かした方が安価になる。 Why each wrong answer fails: - 常時大きな仮想マシンを予約しておき、固定料金で運用する: バッチ処理が短期間である場合、常時稼働するVMに対して無駄な支払が発生する。固定料金は長期的に高い利用率が見込める場合に有利であり、短期処理には不向きである。 - 長期のリザーブドインスタンスを購入して短期バッチに利用する: リザーブドインスタンスは通常1年または3年のコミットメントで割引が適用されるため、短期利用では前払いのコストを正当化できない。短期ワークロードでは投資回収が困難である。 - オンプレミスの専用サーバーを導入して常時待機させる: 初期設備投資、運用・保守コスト、スケーラビリティの制約などから、突発的な短期需要に対しては経済的・運用的に不利である。クラウドの消費ベース課金の利点（必要なときだけ支払う）が活かせない。 実務上、短期バッチではオートスケール設定、ジョブオーケストレーション、スポットインスタンスの活用、そしてジョブの再試行設計（スポットの中断を許容する）を組み合わせることでコストを最小化しつつ信頼性を確保するのが一般的である。

Step 1: 弾力性の概念整理 — resilience（弾力性）は、障害発生時にサービスを継続または迅速に復旧する能力を指す。高可用性（availability）は稼働率を高める工夫、スケーラビリティは負荷対応、resilienceは障害からの回復性に重点がある。

Step 2: 選択肢検討 — 「リージョン間でデータを複製しディザスタリカバリを構成する」は、リージョン障害時でも別リージョンに切り替え復旧できるため弾力性向上に直結する。「Availability Zones/Availability Setsの利用」は同一リージョン内でも物理的に分離されたフォールトドメインを使って冗長化でき、ハードウェア障害の影響を局所化してサービス継続性を高める。これら二つは弾力性の基本設計であり正解。

Step 3: 結論と誤答の説明 — 正答は1と3。Trap: 「スケールアップすれば問題が解決する」と考える誤り。垂直スケール（単一VMを大きくする）は単一障害点を放置したまま能力を上げるだけで、障害時に復旧できない場合は影響範囲が大きくなる。Why each wrong answer fails: 「単一の仮想マシンにリソースを集中し垂直スケールする」は、性能は向上するが可用性や回復性は向上しない。障害が発生するとサービス全体が停止するリスクが高い。「定期的に仮想マシンを停止し再起動することで障害を回避する」は運用上の一時しのぎやメンテナンスの一環に過ぎず、停止中のサービス中断や人為ミスのリスクを増やすこともある。弾力性を高めるには、設計レベルでの冗長化と自動フェイルオーバー、バックアップ/レプリケーション、運用手順とテストされた復旧シナリオが必要であり、単純な再起動運用は代替策にならない。

Step 1: SaaSの責任分界を理解する。SaaSではソフトウェアとそのランタイム、インフラ、パッチ適用、物理的なデータセンター管理などをサービス提供者が管理します。一方で顧客はサービスをどう使うか（アカウント管理、データ入力、アクセス権設定、機密データの分類や削除方針）について責任を持つ部分が残ります。

Step 2: 選択肢を評価する。基盤ハードウェアやハイパーバイザー、データセンター物理セキュリティはプロバイダーの管理領域に該当します。アプリケーションコードのパッチ適用やランタイム管理も通常はSaaS提供者の仕事です。自社データの管理とアクセス制御は顧客が行う必要があり、特にアイデンティティや権限設定、データ分類やバックアップポリシーの決定は顧客側の責務です。

Step 3: 実務での適用を考える。SaaSを導入する際にはデータ保護やコンプライアンス、ID管理（SSO、MFA、ロールベースのアクセス制御）を適切に設定する必要があります。これを怠ると、データ流出や不適切なアクセスが発生するリスクがあります。Trap: 誤認しやすい点は「SaaSだから全てサービス提供者に任せて大丈夫」と考えることです。多くのセキュリティ問題は顧客側の設定ミス（権限設定の甘さ、漏洩対策の不備）に起因します。 Why each wrong answer fails: 「基盤となるハードウェアとハイパーバイザーの保守」はSaaSプロバイダーの責任範囲であり、顧客が通常管理するものではありません。 「アプリケーションコードのパッチ適用とランタイム管理」はSaaS提供者が行うため、利用者はアプリケーションの内部実装に対して一般的に責任を負いません（例外的にカスタムコードや拡張がある場合は別）。 「データセンターの物理セキュリティ対策」もサービス提供者側の管理項目であり、顧客が直接管理する領域ではありません。一方「自社データの管理とアクセス制御（ユーザー管理や認可設定）」は顧客の責任であり、適切な設定や運用が求められます。

Step 1: 設問は責任分界点（どこまでプロバイダーが管理し、どこから顧客が管理するか）を述べています。仮想マシンの生成やネットワーク設定は顧客が行い、ハイパーバイザーや物理ホストの管理はクラウド事業者が行う、という構図はIaaSの典型です。

Step 2: IaaS（Infrastructure as a Service）は仮想化されたコンピュート、ストレージ、ネットワークをサービスとして提供します。顧客はOSのインストール、パッチ適用、ミドルウェアやアプリケーションの構築と運用を担います。クラウドプロバイダーは物理リソース、ハイパーバイザー、基盤ネットワークの可用性とセキュリティを保証します。

Step 3: したがって、設問で示された「顧客がOSとミドルウェアを管理し、プロバイダーが下位レイヤを管理する」モデルはIaaSであり正解です。Trap: よくある誤解はPaaSとIaaSの混同です。PaaSではOSやランタイムの多くがプロバイダー管理となり、顧客はアプリケーションとデータに集中できますが、設問はOS管理を顧客が行うと明示しています。 Why each wrong answer fails: SaaS: SaaSはソフトウェアが完全に管理され、ユーザーはアプリを利用するだけでOSやミドルウェアの管理は不要です。設問の「顧客がOSとミドルウェアを管理する」という点と矛盾します。PaaS: PaaSではランタイムやOSの多くがプロバイダー側で管理され、開発者はコードと設定に集中できます。設問のように顧客がOSやミドルウェア全般を管理するケースとは異なります。ハードウェアのみのレンタル: これはIaaSよりさらに低レイヤで、一般にクラウドのサービスモデルとして標準化されているものではありません。設問の仮想マシン管理やネットワーク設定と結びつかないため不適切です。 補足（実務での注意点）: IaaSは柔軟性が高く、レガシーアプリのクラウド移行や特定の構成が必要なワークロードに適していますが、OSパッチやセキュリティ設定は顧客責任であるため運用負荷が残ります。料金面では従量課金だが、長期利用ならリザーブドインスタンス等でコスト最適化が可能です。

Step 1: 要求の明確化 — 問題文では「インフラやOSの管理を気にせずにコードの開発とデプロイに集中する」ことが目的であり、プラットフォームの管理をプロバイダーが担うモデルが求められている。

Step 2: モデルの比較 — IaaSはインフラを提供するがOSやミドルウェアはユーザーが管理する必要があるため、開発者がインフラ管理から解放されるわけではない。PaaSはOSやミドルウェア、ランタイム、データベース接続などのプラットフォーム機能をクラウドプロバイダーが管理し、アプリケーションコードとそのデプロイに集中できる。SaaSは完成したソフトウェアをそのまま利用する形で、開発者がアプリケーションを新規に作るケースには適していない。オンプレミスは自社で全て管理するため今回の要件とは逆方向である。

Step 3: 結論 — 開発者がOSやインフラを気にせずアプリのコードに集中するためにはPaaSが最も適切である。PaaSはスケーラビリティやパッチ管理、ミドルウェアの運用などをクラウドが担い、迅速な開発サイクルを実現する。 Trap: 「クラウドに任せる = すべての管理が不要」と思い込み、SaaSを選ぶ誤りがある。SaaSは既製のアプリを利用するもので、自社アプリの開発・デプロイには向かない点に注意。 Why each wrong answer fails: - IaaS（誤り）: IaaSでは仮想化されたインフラを提供するが、OSやミドルウェアのインストールや更新、セキュリティ対策は利用者の責任であり、開発者がインフラ管理から解放されるとは言えない。 - SaaS（誤り）: SaaSは提供者がアプリケーションを運用するため、利用者は機能を使うだけでカスタムアプリを一から開発する用途には適さない。デプロイやカスタムコードの実行が前提のケースでは不適合。 - オンプレミス（誤り）: オンプレミスは自社で物理インフラから管理するモデルであり、インフラやOSの管理を気にしないという要件と正反対である。 以上の理由から、コード開発とデプロイに専念したい開発者にはPaaSが最適解となる。

Step 1: 問題の目的把握 — 「単一リージョン内の単一アベイラビリティゾーンに仮想マシンを配置しているシステムのダウンタイムを最小化する」ための有効な設計を問うている。ここで注目すべきは“単一アベイラビリティゾーン”という弱点であり、ゾーン障害が発生するとサービス全体が影響を受ける可能性が高い点である。

Step 2: 高可用性設計の基本 — クラウドで高可用性を実現するには、障害の境界を分散させることが重要である。アベイラビリティゾーン（AZ）は同リージョン内の独立した物理インフラを持つため、AZ間で冗長化することで単一AZ障害によるダウンタイムを回避できる。したがって、複数AZへ冗長化してデプロイすることが最も直接的かつ効果的な対策である。

Step 3: 結論 — 複数のアベイラビリティゾーンに冗長化してデプロイする（選択肢2）が正答。これにより、あるAZで停電やネットワーク障害が発生しても、別AZに配置したインスタンスやサービスが処理を継続できるため、ダウンタイムを最小化できる。 Trap: 垂直スケーリング（高スペック化）は単一インスタンスの障害耐性を高めるものではなく、物理的障害には無力である点を見落としやすい。また、バックアップやネットワーク最適化は重要だが即時のフェイルオーバーや継続的可用性の確保には不十分である。 Why each wrong answer fails: - 同一VMに対して高スペックを割り当て（誤り）: 垂直スケーリングは処理性能や容量を上げるが、インフラやAZレベルの障害（電源断、ネットワーク断）には効果がない。単一の故障点を排除できないため高可用性対策として不十分である。 - 同一データセンター内にバックアップを置く（誤り）: バックアップはデータ保護には有効だが、同じデータセンターもしくは同じAZに置くと物理障害時に両方が影響を受ける可能性がある。迅速なサービス継続を目的とする場合は別のAZや別リージョンへの冗長化が必要である。 - リージョンをまたがないでネットワークを最適化する（誤り）: ネットワークの最適化は遅延低減やスループット向上には寄与するが、物理的な障害やゾーン停止に対する耐性向上には直接結びつかない。可用性向上のためには冗長配置が必要である。 以上より、単一AZ配置のシステムでダウンタイムを最小化するには、複数アベイラビリティゾーンへの冗長デプロイが最も有効な設計となる。

Step 1: 課金モデルの基本理解。消費ベース（pay-as-you-go）はクラウドリソースを実際に消費した分だけ課金される方式で、長時間稼働するリソースも短時間のみ起動するリソースも同一の原則でカウントされる。AzureではVMの利用時間、ストレージ容量、データ転送量、PaaSサービスの呼び出し回数などに基づいて課金されることが多い。

Step 2: 選択肢の判定。選択肢2は消費ベースの本質を正確に表している：柔軟性が高く、使用量に応じてコストが増減する。そのため、トラフィックのスパイクやバッチ処理による一時的なリソース消費で費用が高騰する可能性があり、予算管理やアラート、コスト予測が重要になる。逆に、選択肢1（固定月額）はサブスクリプションやリザーブドインスタンスのような別モデルに近い。選択肢3は長期利用で割引があるリザーブドインスタンスに関連する説明で、消費ベースの定義ではない。選択肢4は責任共有モデルに関わる誤った主張で、消費ベースだからといってセキュリティ責任が全てクラウド事業者にあるわけではない。

Step 3: 実運用の含意と対策。実際のクラウド環境では、消費ベースのメリット（柔軟で初期費用が少ない）とデメリット（コストの変動性）を考慮して設計する。例えば、ピーク時間の予測に基づきスケーリング方針を設定したり、コストアラートを設ける。長期的に安定して高利用が見込めるリソースはリザーブドインスタンスで割引を検討するなど、複数の課金オプションを組み合わせることがよくある。Azure Cost Managementを使ってコストの可視化と最適化を行うのも実務上の良い手法である。 Trap: よくある誤解は「消費ベースなら常に安い」や「運用コストを完全に予測できる」という考え。実際には、需要が急増した場合に予期せぬ高額請求が発生する可能性があるため、監視と予算管理が不可欠である。 Why each wrong answer fails: - 固定月額料金で、使用量に関係なく毎月同額を支払うモデルである: これは消費ベースの定義に反する。固定月額はサブスクリプション型やマネージドサービスの一部で見られるが、使用量に応じて課金される消費ベースとは別のモデルである。 - 長期利用を前提に割引が適用されるため、短期間の利用には向かないモデルである: これはリザーブドインスタンスやコミットメントベースの割引の説明であり、消費ベースの本質ではない。消費ベースは短期利用にも向く。 - 消費ベースモデルではセキュリティ責任の全てがクラウド事業者にある: これは責任共有モデルの誤解である。Azureの責任共有モデルでは、物理インフラやホスト層のセキュリティはクラウド事業者が担うが、OSやアプリケーションの設定やデータ保護、アクセス管理は顧客側の責任であり、課金モデルによってセキュリティ責任が変わるわけではない。 最後に、実際のクラウド運用では消費ベースの柔軟性と予想外のコスト増加リスクを両立させるために、コストアラートや妥当なリザーブ戦略、オートスケールルールの最適化を行うことが推奨される。

Step 1: ビジネス要件の整理 — 変動するバッチ処理で、ピーク時のみ追加リソースが必要ということです。つまり、常に最大容量を確保するのはコスト効率が悪く、逆にリソース不足だと処理遅延や失敗が発生します。動的にリソースを増減する仕組みが求められます。

Step 2: 各選択肢の評価 — 常時最大リソース稼働や単一大型 VM はピーク時には対応できますが、平常時にも無駄なコストを払い続けます。長期前払い契約（リザーブドや割引）は安価ですが、変動の激しいワークロードではリザーブ量の予測が難しく、逆に過剰払いになるリスクが高いです。オートスケーリングは負荷に応じ自動的にインスタンスを増減させられるため、ピーク時のみ追加し、平常時に縮小してコスト削減できる理想的な手段です。

Step 3: 実運用での実装方針 — クラウドプロバイダーのオートスケーリング機能（例：Azure VM スケール セットや Azure Functions の自動スケール）を利用して、CPU 使用率やキュー長などの指標でスケールアウト/スケールインのポリシーを定義します。短時間での負荷増減に対応するにはスケールのしきい値やクールダウン期間を適切に設定し、コスト監視アラートを導入して不必要なスケーリングを防ぐことが重要です。 Trap: 「前払い＝常に安い」という誤解です。確かに一定の使用率が見込める場合は前払いが有利ですが、使い方が不確定か変動が大きいワークロードでは柔軟な従量課金＋オートスケールの方がトータルコストを下げられます。 Why each wrong answer fails: - ピーク時に対応できるように常に最大リソースを常時稼働させる: 常時最大リソースを稼働させると、平常時でも最大料金を支払うことになりコスト効率が非常に悪くなります。 - 長期契約で全てのリソースを前払いし割引を適用する: 前払いは利用が安定している場合に有利ですが、変動が大きいバッチ処理では余剰リソース分のコスト負担が発生するリスクが高く、柔軟性に欠けます。 - 単一の大型 VM に全ての処理を集中させて管理を簡素化する: 単一障害点が増え可用性や耐障害性が低下します。さらにピーク時対応のために大型 VM を常時稼働させるとコスト効率が悪化します。