料金・容量・サポートのシナリオ判断

この単元で学ぶこと

• シナリオの需要と制約から購入方法を判断する
• 約束と実績の数値を計算し費用を比較する
• サポート・情報・専門支援を目的に応じて選ぶ

本文解説

1. 短期と安定利用 イベント用の二日間の環境と一年中動く基盤では、約束できる使用量が違います。短期分はオンデマンドを基準に、継続する部分はRIやSavings Plansを比較します。需要のピークを丸ごと長期約束する前に、時間帯ごとの使用と廃止予定を確認します。Spotは安定利用の代名詞ではなく、中断後に再開できるかを別に評価します。

2. 時間単位の計算 説明用にSavings Plansの約束が毎時4ドル、対象使用を契約単価で評価した額が毎時3ドルなら、その時間の未使用は1ドル、利用率は75%です。余りを翌時間へ回せません。また、オンデマンドで合計200ドルの同一使用が契約総額150ドルなら差は50ドルです。割引率だけでなく、比較対象の使用量と対象料金を合わせて計算します。

3. 容量と専用性を確認 リージョンRIで料金を下げても、必要なAZの容量は別に用意します。短期間の容量確保は即時型Capacity Reservation等の条件を比較できます。物理ホストのコア数やソケットを把握したいライセンス要件ならDedicated Hostsを調べます。単に専用ハードウェアを使いたい条件と混同しないよう、問題文から必要な制御を取り出します。

4. 現在の支援を選ぶ 24時間の技術相談が必要なら、現行のBusiness Support+等の範囲を比較します。EnterpriseのTAMによる助言、Unified Operationsの専門家や運用支援も、要求する仕事から検討します。最初の応答目標が短くても業務復旧の時間を保証するものではありません。機密情報を伴うケースは許可された利用者が適切な経路で扱い、公開投稿へ秘密情報を載せません。

5. 旧名称の用途を読む 旧プラン比較ではDeveloperは開発段階向けの営業時間内の技術支援、Businessは本番環境向けの24時間支援という違いを読み取れます。Enterprise On-RampではTAM群からの助言等が案内されていました。これらは試験資料の旧名称を理解するための比較です。現行の新規加入可否、既存契約の移行期限や地域差とは分離し、古い表を新規契約の一覧として使いません。

6. 障害と改善を切り分ける AWS側で自分の資源に関係する予定イベントがあるならHealthを見ます。構成の費用・安全性等の改善候補ならTrusted Advisorです。一般的な手順は公式文書やre:Postを調べます。例えばアプリの遅延には自身のメトリクスやログも必要で、Healthの公開状態が正常なことだけではアプリの問題を否定できません。

7. 購入と実装の相談 第三者の製品を探して購入するならMarketplace、業界に詳しい支援企業ならPartner、設計・構築・移行プロジェクトの専門支援ならProfessional Services等を検討します。これらの経路が組み合わさる場合も、ソフトウェアの契約、実装の成果物、運用支援の範囲を区別します。支払いをまとめられるだけで実装作業の契約まで成立するわけではありません。

8. 報告と確認を完了する AWS資源からの不正利用が疑われたら、Trust and Safetyの案内に従い、観測時刻や対象等の必要な証拠を整理します。通常の技術ケースや一般質問へ置き換えません。料金契約についても、見積り、購入、適用実績の確認は別の段階です。共有設定や利用率を定期的に確認して、契約と実態のずれを見つけます。

図解

重要ポイント

• 料金計算では使用量と期間の前提をそろえる。
• 旧プランの用途差と現行提供状態を分ける。
• 影響イベント、改善、知識、専門支援で経路を選ぶ。

間違えやすい点

• 時間ごとの余りを月内で相殺できると考える。
• 有料支援に入ればアプリの復旧設計も保証されると考える。

用語解説

初回応答

ケースへ最初の応答を行うこと。解決完了とは別。

未使用コミットメント

その時間の適合使用へ適用しきれなかった約束額。

支援範囲

契約やプランにより提供される相談・作業等の範囲。

関連教材

• ストレージクラスとライフサイクルを理解する
• EC2購入方式・容量・支援の違いと使い分け
• ストレージクラスとライフサイクルのシナリオ判断
• Spotを理解する
• データ転送コストの考え方を理解する