AWS Solutions Architect — コスト最適化アーキテクチャの設計：練習問題60問

Step 1: 要件の把握 — 長期にわたり安定稼働する特定のインスタンスがあり、さらに特定アベイラビリティゾーン（AZ）でのキャパシティ予約が必要という点が重要。堅牢なレイテンシ要件やライセンス制約、データローカリティ等で AZ レベルの確保が必要な状況。

Step 2: 各オプションの機能比較 — - Zonal（ゾーン単位）Standard Reserved Instances（RI）は購入したゾーンに対してキャパシティの予約効果があり、インスタンスタイプが一致する限り割引と容量の両方を提供する。これは AZ 固有の継続的稼働を保証したい場合に有効。 - Compute Savings Plans は柔軟で多様なコンピュートに適用できるが、容量の予約機能は提供しない（割引はあるがキャパシティ保証は無い）。 - スポットインスタンスは中断リスクがあるため、確実に容量を確保したい用途には向かない。 - Convertible RI はインスタンス属性を変更できる柔軟性があるが、容量予約を目的とする場合は Zonal Standard RI の方が明確に AZ レベルでのキャパシティ確保が可能である。

Step 3: 推奨の理由付け — AZ レベルでの確保やライセンスの都合（ソフトウェアの特定 OS/テナンシー要件など）で物理的にインスタンスを保証したいなら、Zonal Standard RI を購入することで割引と同時にキャパシティ予約が得られるため最適である。運用、可用性、コストのバランスが取れる。 Trap: よくある誤りは「Reserved Instances は割引だけで、キャパシティ予約は別にしなければならない」と思う点。実際には Zonal RI はその AZ の容量確保に相当する効果を持つため、容量保証が必要なケースで役立つ。ただし Zonal RI と Capacity Reservation は厳密に異なる AWS 機能だが、Zonal RI はそのゾーン内での優先的なキャパシティ割当を助ける（必要なら Capacity Reservations を明示的に作ることもできる）。 Why each wrong answer fails: - Compute Savings Plans を購入する: 柔軟性は高く割引も得られるが、特定の AZ での容量予約機能は提供しないため、キャパシティ確保が必要な要件を満たせない。 - スポットインスタンス中心の運用: スポットは中断が頻繁に起こり得るため、固定的な容量保証や SLA 的要件には適さない。オンデマンドの補完も可能だが常に確実な容量を得るための最適解ではない。 - Convertible RI を購入する: Convertible RI は後からインスタンス種別を柔軟に変更できる利点があるが、容量予約が必要な場合には Zonal Standard RI の方が適合性が高い。Convertible RI は主に将来のインスタンス変更に備えるオプションであり、AZ レベルの容積確保を主目的にするなら不十分である。 総括すると、特定 AZ における長期安定稼働と容量確保が要件である場合は Zonal（ゾーン単位）の Standard Reserved Instances を選ぶのが最も妥当である。

Step 1: まず、コスト最適化のためには“検出”が先です。大規模環境では手動や単一メトリクス（例：CPUのみ）での判断は誤検出や見落としが発生します。Trusted Advisor のコスト最適化チェック、Cost Explorer のリソース最適化/rightsizing レポート、Compute Optimizer、CloudWatch メトリクス、タグベースのリソースグルーピングを組み合わせて、実際に利用されていないインスタンスや未アタッチのEBSボリューム、古いスナップショットを特定します。S3 Inventory やリソースタグの整備も有効です。

Step 2: 検出したら、停止スケジュールや自動削除のライフサイクルポリシーを導入します。例：Development環境のEC2は業務時間のみ起動するスケジュール、未アタッチEBSは30日経過で自動削除するData Lifecycle Manager ポリシー、またはAWS Backupのライフサイクルルール。ステージングを経て自動化を適用し、監査用に変更履歴と承認ワークフローを残します。

Step 3: 最後に、不要化の決定を運用ルールとして組織に適用します。タグ付けポリシーを徹底し、Cost Allocation Tags を有効にしてアカウントやチーム別に費用を見える化します。さらに、節約余地が確認できたリソースに対してはReserved InstancesやSavings Plansのコスト最適化を検討しますが、これは“定常的に利用される”ことが確認できてから行います。 Trap: 試験や現場でよくある誤解は「すぐにインスタンスを削除すればコスト削減できる」という考えです。削除はビジネスインパクトを招きやすく、メトリクスのみに依存すると誤って重要なバッチや低CPUだがI/O重視のインスタンスを削除してしまうことがあります。 Why each wrong answer fails: - すべてのEC2を30日で即終了するスクリプト: 短絡的で危険。ビジネス可用性やデータ整合性を壊す可能性が高く、削除前にバックアップや所有者確認が必要。単純な稼働日数は利用実態を反映しない。 - 正解（Trusted Advisor + Cost Explorer + 自動化）: 大規模環境での検出→承認→自動化のワークフローを含み、リスクを最小化しながら持続的に不要リソースを削減できる。 - すべてをRI/Savings Plansで事前購入: 事前購入は定常負荷に有効だが、未使用インスタンスが多い状況で購入すると逆に費用を固定化してしまい無駄が増える。まずは無駄を削ぎ落とすべき。 - CloudWatch の単一CPUアラームだけ: CPUだけで判断するとI/O専用やメモリバウンド、短時間にスパイクするワークロードなどを誤分類する。複合メトリクスと履歴・ビジネス文脈が必要。 総括: 大規模環境では検出と承認のプロセスを整えることが最初の一歩。自動化やポリシー導入で継続的に不要リソースを削減するのが最も効果的かつ安全なアプローチです。

Step 1: トラフィック特性を把握する。今回のケースは『ほぼゼロの時期があり、短時間に高いスパイク』があるため、常時容量を持つモデル（常時稼働のFargateやEC2）はアイドルコストが発生します。サーバーレスはリクエストベースで課金されるため、アイドル時のコストが最小になります。

Step 2: パフォーマンス要件を確認する。大量の短時間リクエストに対してはLambdaは自動スケーリング可能ですが、コールドスタートやコネクション確立（DB接続）によるレイテンシー対策が必要です。Provisioned Concurrency やコネクションプールの工夫（RDS Proxyなど）を組み合わせることで安定した低レイテンシを保てます。これらは必要なときだけ課金されるため、全体コストは下がることが多いです。

Step 3: 移行と運用を計画する。Lambdaへ移行できないワークロード（長時間処理、大量バイナリ処理）はFargateやバッチ専用インスタンスに残すハイブリッド戦略を採る。モニタリングで実際のコスト/レイテンシを評価し、プロビジョンドコンカレンシーやAPI Gatewayのスロットリングを適切に設定する。 Trap: 試験でよくある誤解は「サーバーレスは常に安い」または「スポットは常に最安」という単純化です。Lambdaは短時間高頻度の呼び出しが極端に多い場合や長時間処理に不向きな場合があります。一方スポットは中断耐性のあるワークロードに限定されます。 Why each wrong answer fails: - 現在のFargateを常時十分に割り当てる: 常時容量確保はアイドル時間に無駄な料金を生むため、変動が大きい環境ではコスト非効率。 - スポットに全移行して再設計: スポットは確かに安価だが中断リスクがあり、ステートフルやリアルタイム応答を要求するマイクロサービス全体に適用するのは現実的ではない。中断対策のための再設計コストと運用負荷が高い。 - EC2オンデマンドに置き換え: オンデマンドはスケール可能だが、管理オーバーヘッドと常時稼働コストが高く、FargateやLambdaに比べて運用/コスト面で劣る。 総括: 変動が激しく深夜にほぼゼロ稼働となる設計では、サーバーレスへ移行してリクエスト単位で料金を支払うモデルが最もコスト効率が高い。必要に応じてProvisioned ConcurrencyやRDS Proxyなどを組み合わせ、パフォーマンスを確保するハイブリッド戦略が現実的です。

Step 1: 理解すべき課金ルール - AWSではElastic IPアドレスがアカウントで割り当てられている状態でも、EC2インスタンスにアタッチされていない（未使用の）EIPに対して課金が発生します。複数の未使用EIPがあると継続的なコスト要因になります。

Step 2: 対応策の評価 - 最も直接的で確実な方法は未使用のEIPをリリースすることです。リリースすることでそのEIPに対する継続課金が即停止します。もし特定の固定IPが必要なら、利用中のインスタンスにのみEIPをアタッチし、不要になったら即リリースするポリシーを導入します。また、インフラコードやTerraformでEIPの管理を厳格化し、不要な割当てを防ぐ運用も重要です。

Step 3: 運用改善と代替案 - NATゲートウェイはアウトバウンド用にEIPを使用するが、NATゲートウェイ自体が高コストなサービスであるため、単にEIPコストを下げるために移行するのは得策でない場合がある。適切な対策は未使用EIPの解放、必要なEIPのタグ管理、そして自動化で未使用EIP検出→通知/削除を行うこと。 Trap: 試験での誤りは「Elastic IPは無料で保持できる」あるいは「EIPは常に必要」だと考えることです。実際は未使用状態のEIPは課金対象であり、必要でなければすぐに解放すべきです。EIPとNATゲートウェイのコスト比較をせずに移行するのも誤りです。 Why each wrong answer fails: 2) Elastic IPをすべてNATゲートウェイに切り替える（選択肢2） - NATゲートウェイはアウトバウンドアクセスを提供するには便利だが、時間単位の高いコスト（データ処理料金や時間料金）が発生するため、未使用EIPの単純な代替としてはコストが増える可能性が高い。 3) Elastic IPを維持する（選択肢3） - 将来のために確保しておくと課金が継続する。特にテスト/開発環境では不要なEIPを確保し続けることがコストの無駄遣いとなる。 4) Elastic IPを常にアタッチしたままにする（選択肢4） - アタッチしたままにすれば課金は発生しない（ただし、EIPはアタッチされたインスタンスに対して無料の条件があるが、使い方によっては不要な費用が残る）。常にアタッチを維持するという運用は非現実的であり、必要ないEIPは解放すべきである。 総括: 未使用のElastic IPを特定してリリースすることが、直接的かつ即効性のあるコスト削減策であり、タグ管理や自動検出で再発を防ぐ運用改善が重要です。

Step 1: 問題の本質把握 — スナップショットは便利だが放置されるとストレージコストを増やす。手動管理はヒューマンエラーや見落としを生み、規模が大きくなると現実的ではない。したがって自動化とポリシー化が必要です。

Step 2: AWSの機能選択 — Data Lifecycle Manager（DLM）はEBSスナップショットの自動作成と保持期間管理に特化したサービスで、タグに基づくポリシーでスナップショットを作り、古いものを自動削除できます。AWS Backup はより広範なサービスで、EBSのほかRDS、EFS、DynamoDB等も統合的にバックアップ・保持管理が可能です。どちらも組織ポリシーとして展開し、監査ログやレポートを残せます。

Step 3: 導入と運用 — まず既存スナップショットをスキャンしてオーナー情報と用途を特定し、必要なものはタグ付けする（例：retain=true）。次にDLM/AWS Backupでライフサイクルルールを定義（例：日次スナップショット、30日以上経過したスナップショットを削除）して段階的に運用に移す。変更はステージング→本番へ段階的に適用し、削除前に一定の保護期間と承認ワークフローを設ける。 Trap: よくある誤解は「古いスナップショットは圧縮すればコストが下がる」「手動管理で十分だろう」というもの。EBSスナップショットは増分で保存されるため、無秩序に保持すると関連ブロックでコストが残る。圧縮という操作はAWS上ではユーザが直接できないし、手作業はスケールしない。 Why each wrong answer fails: - 月次手動チェックで削除: 規模が大きい環境では人的コストとミスが増え、運用効率が低い。リアルタイムで不要スナップショットが蓄積されるリスクが残る。 - 正解（DLM/AWS Backup の自動化）: 自動でポリシー適用でき、スケールしやすく監査ログも残せるため運用負荷を増やさずコスト削減が可能。 - スナップショットを圧縮: AWSではユーザが直接スナップショットを圧縮する機能はなく、概念的に誤り。EBSスナップショットは増分保持であり、不要なブロックを除去するためにはポリシーで削除するのが現実的。 - 毎週AMI化して古いAMIを残す: AMIはEBSスナップショットを参照するため、古いAMIを残すと同様にスナップショットが保持されコストが下がらない。さらにAMIs管理による運用負荷が増える。 総括: スナップショットの継続的なコスト削減には、DLMやAWS Backup などのネイティブなライフサイクル自動化を導入してポリシー化するのが最も現実的で安全な方法です。

Step 1: 利用実績の把握と分類 まず過去の利用パターンを Cost Explorer と Compute Optimizer で解析し、ベースライン（常時稼働分）とバースト（スパイク）を切り分けます。ベースラインは安定した割引（例: Savings Plans / RI）で低コスト化し、スパイクは柔軟なオンデマンド性で対応するのが基本戦略です。

Step 2: 割引適用とスパイク対応の設計 ベースラインについては Compute Savings Plans を検討してください。Compute Savings Plans はインスタンスサイズやファミリをまたいでディスカウントを適用できるため、将来のインスタンス変更に強い利点があります。スパイクには Auto Scaling を用いてオンデマンドやスポットインスタンスを用いることで、必要時だけリソースを追加しつつコストを低く抑えます。スポットは低コストだが停止のリスクがあるため、スパイク用でもコア処理には注意が必要です。

Step 3: 実行と継続的最適化 Compute Optimizer と定期的な Cost Explorer レポートを使って、RI/Savings Plans の利用率、コミットメントのマッチ度を評価し、必要なら契約を見直します。オンデマンド・スポットの割合やスケーリングポリシーを調整して SLA を保ちながらコスト最適化を続けます。 Trap: よくある誤解 「すべてを Zonal RI にすれば容量確保と安価な運用が両立する」と安易に考えるのは危険です。Zonal RI は確かに容量予約が可能なため一部ワークロードに有効ですが、スパイク対応と柔軟性を犠牲にし、長期のコミットメントによるミスマッチリスクを生みます。 Why each wrong answer fails: 1. ベースラインに Compute Savings Plans を適用しスパイクは Auto Scaling/スポット（正解）: ベースラインで安定的に割引を受けつつ、スパイクでは自動スケールとスポットの低価格性を利用することでコストと柔軟性を両立する理にかなった方法。 2. すべてを Standard Zonal RI にする（誤り）: 全インスタンスを Zonal RI に固定するとスパイク対応の柔軟性が低下し、将来のリファクタリングやインスタンス変更で割引が無駄になるリスクがある。さらにスパイクに対する追加キャパシティをオンデマンドで確保することは可能だが、全体戦略としては効率が悪い。 3. オンプレミスへワークロードを移行する（誤り）: 一部ケースで有効かもしれないが、クラウドのスケーラビリティや運用効率を犠牲にする可能性が高く、移行コスト・運用コスト・柔軟性の面でメリットが必ずしも出るとは限らない。しかも即時のコスト削減にはつながりにくい。 4. Compute Optimizer / Cost Explorer で分析し最適ミックスを決定する（正解）: データに基づく意思決定は最も重要。まず現状分析を行わずに割引を購入するのはリスクが高く、分析に基づくミックス設計が長期的な最適化の鍵となる。 結論: ベースラインは Savings Plans（Compute）で割引、スパイクは Auto Scaling とスポットで対応し、Compute Optimizer と Cost Explorer で継続的に利用状況を分析して最適な構成にチューニングしていくのが最善です。

Step 1: 要件整理 — 1年間保持、アクセス頻度は非常に低い（数か月に一度）、取り出しは規制対応時に必要。この特性は長期アーカイブ向けのストレージを示します。S3 Glacier Deep Archive は最安の長期アーカイブオプションで、取り出しが数時間〜12時間程度許容されることが前提です。

Step 2: 設計手順 — S3に書き込みを行い、オブジェクトメタデータとS3 Inventoryを有効にしてオブジェクト一覧を定期的に取得します。Lifecycleルールで例えば90日後に Glacier Deep Archive に移行し、保持期間に達したら自動で削除するルールを設定します。検索用のインデックス（例：Athena + S3 Inventory / Glue Catalog）を用意しておくと、復元前でもメタデータ検索が可能です。

Step 3: 運用とコスト評価 — Deep Archive への移行によりストレージコストは最小化されます。取り出しはコスト（リクエスト/データ取り出し料金）と時間がかかるため、復元は必要最小限に留め、復元後は一時的にS3 Standardに保管して処理するワークフローを導入します。アクセス頻度が増えた場合は階層を見直します。 Trap: 試験でよくある誤解は「Intelligent-Tiering が常に最安で自動最適化してくれる」という点です。Intelligent-Tiering は短期的にアクセスパターンが不明なデータに適しているが、数か月〜年単位でほとんどアクセスしない大量のオブジェクトは Glacier Deep Archive の方が総合コストは低い。 Why each wrong answer fails: - S3 Standard に保持し続ける: アクセスが稀であるにもかかわらず高コストの Standard に置き続けるのは非効率。コストが高く長期保持要件には不向き。 - 正解（Lifecycle -> Glacier Deep Archive + Inventory）: 長期アーカイブに最適で、取り出しの方法とインデックス管理も含めて運用面とコスト面のバランスが取れている。 - S3 Intelligent-Tiering の単独利用: Intelligent-Tiering はフレキシブルだが、頻度が極端に低い（数か月〜年単位）大量データに対してはストレージコストが高くなる可能性がある（特にDeep Archiveよりは高い）。また一部のアーカイブ層へ自動的に移るとはいえ、最も低コストのDeep Archiveほど安くならない。 - オンプレに移す: ハイブリッドは運用とセキュリティ、可用性の観点で複雑性とコストが増える。S3+Glacierは耐久性・コンプライアンス機能が強く、オンプレ移行の運用コスト・リスクが大きい。 総括: 監査ログのような「長期保管かつ低頻度アクセス」データは S3 Lifecycle を使って Glacier Deep Archive に移行し、S3 Inventory やメタデータカタログで検索性を確保するのが最も現実的でコスト効率の良い設計です。

Step 1: ワークロード特性の把握 RDS（マネージド DB）では、本番の常時稼働かつ一定の使用パターンがあるインスタンスは Reserved Instances（RI）によってコスト削減が可能です。ただし、どのクラスをどの程度購入するかは実際の CPU/メモリ/IO 要件を基に決める必要があります。まず Performance Insights、Enhanced Monitoring、CloudWatch を使い、CPU 使用率、メモリ圧迫、IOPS、スロークエリ等を観測します。

Step 2: 右サイズと割引の選定 実測に基づき過剰スペックのために無駄が出ている DB はダウンサイジング（右サイズ）を行い、そのうえで長期的に必須なインスタンスには Regional Reserved Instances（または Zonal RI の検討）を購入します。RI は DB インスタンスクラスに対する割引を与え、安定稼働する DB に対してはコスト効果が高いです。

Step 3: 開発環境の扱いと運用ポリシー 開発／検証環境はオンデマンドやスポット、スケジュールで停止する方式にしてコストを削減します。運用ではタグ付け、所有者責任、定期的なレビューを行い、RI の適用率と有効期間を管理します。 Trap: よくある誤解 「Compute Savings Plans はすべてのマネージド DB に適用される」と誤解する人がいますが、Compute Savings Plans は EC2/Fargate/Lambda を主対象としており、RDS のインスタンス課金に対しては適用範囲が限定されます。RDS の割引は通常 RDS 用の RI または DB インスタンスに紐づく Reserved Instances で管理します。 Why each wrong answer fails: 1. 本番に Regional RI を購入し開発はオンデマンド（正解）: 常時稼働で予測可能な負荷がある本番 DB には RI が有効。開発は柔軟に停止／再作成できるようオンデマンドを維持するのが現実的。 2. RDS に Savings Plans が適用される（誤り）: Savings Plans は主に EC2/Fargate/Lambda に焦点を当てた割引であり、RDS の課金には直接適用されないため誤り。ただし、RDS を EC2 上で自運用している場合は別の話になるが、マネージド RDS には適用されない。 3. Performance Insights 等で計測し右サイズ→RI（正解）: 実測に基づく右サイズは不要なコストを削る最も効果的な施策で、その後 RI を適用すると最大の費用対効果が得られる。 4. 自動バックアップとスナップショットを無効化（誤り）: バックアップを無効化するのは運用上及びコンプライアンス上極めて危険。短期的にストレージ費用は下がるかもしれないが、データ復旧不能や監査違反のリスクが非常に高く、許容されないことが多い。 まとめ: 本番の安定稼働 DB は実測に基づく右サイズを先に行い、その上で RI を導入する。開発環境は停止ポリシーやオンデマンド運用でコストを抑えるのが賢明です。

Step 1: 要件と制約の把握 — 長時間実行されるバッチ、リトライやジョブ管理が必要、運用負荷最小化、コスト削減が目的。長時間処理では Lambda の 15 分制限が障害になり、セルフマネージド EC2 ではジョブ管理やスケジューリングを自前で構築する必要がある。

Step 2: サービスの適合性検討 — AWS Batch はバッチワークロードに特化したマネージドサービスで、ジョブ依存関係、優先度、リトライポリシー、並列実行などの機能を提供する。コンピューティングはマネージドなコンピュート環境（EC2 又は Fargate）で実行され、Spot インスタンスを利用することで大きなコスト削減（場合によって 70-90%）が可能。さらに、AWS Batch は中断や再スケジュールを考慮した設計がしやすく、運用負荷が低減する。

Step 3: トレードオフ評価 — Spot を利用するとコストは低減するが中断リスクがある。長時間バッチではチェックポイント設計や再実行ロジックを組み込む必要があるが、AWS Batch と組み合わせることで中断管理が容易になる。可用性は AWS の管理に依存するが、ジョブ再スケジュールや失敗時の自動再試行などで業務継続性を確保できる。セキュリティは IAM ロールや VPC 内での実行、ロギングで担保する。 Trap: 試験でよくある誤解は「Spot は不安定だから使わないほうが良い」という考え。確かに中断リスクはあるが、耐障害性を設計（チェックポイント、再試行、非同期処理）すればコストメリットは非常に大きい。AWS Batch はそのようなパターンを前提にしているため適している。 Why each wrong answer fails: - EC2 上にジョブスケジューラ（オンデマンド）: 完全に自分で管理するため運用コスト（パッチ、スケール、監視、再試行ロジック）が高く、オンデマンド料金は Spot より高価で長時間処理ではコスト効率が悪い。 - Amazon SQS + EC2 常時稼働ワーカー: SQS は良いが「常時稼働ワーカー」はアイドルコストが発生する。スケールの自動化や複雑なジョブ管理（依存関係、優先度、リソース制限）を自前で実装する必要があり運用負荷が高い。 - AWS Lambda で分割して処理: Lambda は最大実行時間が 15 分（現時点）であり、長時間バッチには向かない。分割して再試行ロジックを自前で作ると運用が複雑になり、コールドスタートやスループットの管理も課題になる。 総括すると、長時間バッチでコスト最適化と運用簡素化を両立するには AWS Batch を用い、可能であれば Spot を活用してコストを下げる設計が最も妥当である。

Step 1: 要件確認 — 問題は“アクセスは稀だが、取り出し時に低レイテンシが必要で、高い耐久性を維持”という点です。これはアーカイブ用途だが、即時リトリーブや短時間での復元を求められるユースケースです。

Step 2: ストレージクラスの特性比較 — S3 Standardは高頻度アクセス向けでコストは高めだが低レイテンシを常に提供します。S3 Standard-IAは低頻度アクセス向けで、S3 Standardに近い耐久性と低レイテンシを維持しつつ保存コストを下げる設計です。S3 One Zone-IAは単一AZにデータを保存するためコストはさらに低いが、AZ障害時の耐久性が低下します。S3 Glacier Deep Archiveは最も安価だが、取り出しに数時間以上かかることがあり、低レイテンシの取り出し要件を満たしません。

Step 3: 選択と理由付け — 要件に“低レイテンシの取り出し”と“高耐久性”が含まれるため、S3 Standard-IAが最適です。Standard-IAはS3 Standardと同等の11 9の耐久性（実運用上の高耐久性）を維持しつつ、アクセス頻度が低いデータに対するストレージコストを有意に削減します。一方、One Zone-IAはコストは低いもののAZ障害でデータ損失のリスクがあり、Glacier Deep Archiveは復元時間が長いため低レイテンシ要件を満たしません。 Trap: 受験者は“Infrequent Access = Glacier”と混同しがちですが、Glacier系は通常の低レイテンシアクセス用途向けではなくアーカイブ（低頻度かつ復元は時間がかかる）向けです。 Why each wrong answer fails: - S3 Standard（選択肢2）: 要件は低頻度アクセスのデータであるため、S3 Standardは過剰なコストとなります。確かに低レイテンシと高耐久性は満たしますが、コスト効率が劣ります。 - S3 One Zone-IA（選択肢3）: コストはさらに低くできますが、データは単一AZにのみ保存されるため耐久性・可用性が低く、AZ障害時にデータが失われるリスクがあります。高い耐久性が要件なので不適切です。 - S3 Glacier Deep Archive（選択肢4）: 最も安価ですが、復元に数時間〜十数時間かかることがあり“取り出し時に低レイテンシ”という要件を満たしません。また復元コストやリストア運用の負荷が発生します。 追加の考慮点: 実運用ではS3ライフサイクルポリシーを使って、データが作成されてから一定期間はS3 Standardに置き、その後Standard-IAやGlacierに移行することでコストを最適化できます。アクセスパターンがさらに変動する場合はS3 Intelligent-Tieringも検討に値しますが、確実に低頻度で即時アクセスが必要であればStandard-IAが分かりやすい選択肢です。

Step 1: 要件の精査 - 質問文は「長時間稼働」「使用率が一定」「容量変更の頻度が低い」など、ステディステート（定常）なワークロードを示しています。こうしたワークロードは長期的なコミットメントを用いて割引率を最大化するのに適しています。

Step 2: 各購入オプションの比較 - Standard RIは最も高い割引を提供する傾向にあり、特定インスタンス/リージョンに対して適用されます。Compute Savings Plansは柔軟性に優れ、リージョンやインスタンスファミリーを跨げるが通常Standard RIより割引率がやや低い。オンデマンドは柔軟だがコストが高い。スポットは最安だが中断許容性がないため常時稼働の本番には不向き。

Step 3: 推奨とリスク管理 - 定常的に稼働する本番サーバに対してはStandard RI（1年/3年、支払いオプションは全額前払い/一部/なし）を検討する。RIを選ぶ際はインスタンスのサイズ、リージョン、OS、テナンシーに注意し、タグベースでどのインスタンスがRIの恩恵を受けるかを分析して購入量を決定する。 Trap: よくある誤解は「Savings Plansが常にRIより良い」や「スポットを本番で使えば一番安い」という思い込みです。Savings Plansは柔軟性で勝るが、特定の安定した容量に対してはStandard RIの方が割引が深い場合があります。スポットは割安だが中断の影響が許容できない本番には適しません。 Why each wrong answer fails: 1) Compute Savings Plans（選択肢1） - 優れた柔軟性を持ち幅広いサービスに適用できるが、長期で固定された本番ワークロードに対してはStandard RIの方が割引率が高いケースが多い。もしインスタンスが全く変わらないならStandard RIのコスト効果が勝る可能性が高い。 3) オンデマンドのまま（選択肢3） - 柔軟性はあるがコスト効率が最悪。定常的に稼働するワークロードには割引コミットメントを利用しないのは非効率。 4) スポットインスタンス（選択肢4） - 価格は最も低いが、EC2スポットは中断される可能性があるため、常時稼働が必要な本番系サービスでは適合しない。障害対策やビジネス影響のリスクが高い。 総括: 安定稼働の長期本番には、割引率の高さとコスト予測性が優れるStandard Reserved Instancesが最適解となる。ただし、今後の変動見込みがある場合はConvertible RIやSavings Plansを併せて検討すること。

Step 1: 要件分析 — トラフィックがバースト的で長時間低利用であるなら、CPUやメモリを常時プロビジョンしておく固定コストは不利です。コスト最適化の観点では、消費ベースで課金されるサーバーレスが有利です。また運用負荷（OSパッチ、スケーリング調整、監視）を下げることも求められています。

Step 2: サービス選定と設計（AWS観点）— AWS Lambdaはイベント駆動で実行時間と呼び出し回数に応じて課金されるため、低稼働時間帯にほとんどコストが発生しません。API Gatewayと組み合わせることで認証、スロットリング、キャッシュを統合的に管理できます。企業向けにはコールドスタート対策（軽量ランタイム、プロビジョンド・コンカレンシーを必要箇所でのみ利用）やモニタリング（CloudWatch、X-Ray）を組み込む設計が想定されます。

Step 3: トレードオフと運用対策 — Lambdaは短時間処理やI/O待ちが多い処理に向きます。長時間処理や高同時実行が恒常化する場合はコストが上振れし、ECS/FargateやEC2が有利になることがあります。そのため、まずは最もコスト効率の良いサーバーレスで実装し、実稼働メトリクスを収集して定期的にレビューすることが推奨されます。 Trap: よくある誤解は「サーバーレスは常に安い」という単純化です。高スループットかつ長時間実行タスクでは従量課金が逆に高くなることがあります。またコールドスタートによるレイテンシ要件を無視するのも誤りです。 Why each wrong answer fails: - オンデマンドEC2をAuto Scalingで運用: オートスケールはスパイクに対応できるが、低稼働時間にインスタンスをゼロにできない場合や、スケールアウトの遅延、OS管理コストが残るためサーバーレスよりも運用/コスト面で劣る。スパイクが短時間で頻繁なら起動遅延が問題になる。 - ECS on EC2 クラスタで常時稼働: コンテナ化で効率は上がるがEC2のプロビジョンドリソースを常時持つと低利用時間のコスト削減効果が少ない。管理するノード群やパッチング、スケジューリングの運用負荷も増える。 - Reserved Instancesを購入したEC2: RIは長期一貫稼働を前提とした割引で、バースト性かつ低利用時間が長いケースでは初期投資が無駄になりやすい。柔軟性も低く、短期的なスパイク対応には過剰。 結論: バースト性が強く低利用時間が長いAPIワークロードでは、Lambda＋API Gatewayが基本的に最もコスト効率が良く、運用負荷も低い選択肢です。ただし実運用でのパフォーマンスとコストの継続評価を行い、高恒常負荷に転換した場合は設計を見直すべきです。