AWS SAA-C03 コスト最適化 完全攻略 — Domain 4（20%）を「性能を落とさず削る」判断で取る

AWS SAA-C03 高性能設計 完全攻略（2026-06-04 公開）で 3 つ目のドメインを終えました。最後に控えるのが配点 20% の Domain 4「Design Cost-Optimized Architectures」です。これで SAA-C03 の 4 ドメインがすべて揃います。

AWS SAA-C03 コスト最適化のテーマは「性能や可用性を犠牲にせずに、いかに無駄を削るか」です。安くするだけなら誰でもできます。難しいのは、必要な性能を保ちながらコストを最小化すること。本記事では、コンピュート購入オプション・ストレージ階層・データ転送という 3 つの切り口で、その判断軸を整理します。なお記載する価格は us-east-1 リージョンの 2026 年時点のもので、1 ドル＝約 159.1 円で換算しています。

コスト最適化の原則 — 適正サイジングと弾力性

コスト最適化の出発点は、2 つの原則に集約されます。

ひとつは適正サイジング（right sizing）です。実際の使用量に対して過剰なスペックのリソースを使っていないかを見直し、ちょうど良いサイズに合わせる。多くの環境では、使われていない、あるいは過剰に大きいリソースが眠っています。これを削るだけで、性能を落とさずにコストが下がります。

もうひとつは弾力性（elasticity）の活用です。需要に応じてリソースを増減させ、使った分だけ支払う。常時ピークに合わせて固定容量を確保するのは、平常時に無駄を垂れ流すことを意味します。Auto Scaling で需要に追従させ、不要なリソースは止める。クラウドの従量課金モデルを最大限に活かす発想が、コスト最適化の土台です。

従来のオンプレミス環境では、ピーク需要を見越して最大構成のサーバーを購入し、平常時はその大半を遊ばせていました。クラウドではこの前提が逆転します。必要な時に必要なだけ確保し、不要になれば即座に手放す。開発環境を夜間や週末に自動停止するだけでも、稼働時間を大幅に削減できます。マネージドサービスやサーバーレスを使えば、アイドル時間そのものへの課金をなくせる場面も多い。「リソースを所有する」のではなく「必要な時だけ借りる」という発想の転換が、コスト最適化の根底にあります。

この 2 原則を貫くのが「使っていないものに払わない」という哲学です。料金の基礎はAWS 料金体系 完全攻略 — CLF-C02 Domain 4 + 模擬問題 30 問（2026-05-29 公開）で扱いましたが、Associate ではこれを「設計でどう実現するか」という判断として問われます。

コンピュート購入オプション — 4 つの選択肢

EC2 のコストを左右する最大の要素が、購入オプションの選択です。4 つの選択肢を、コミットメントと柔軟性のトレードオフで整理します。

判断軸はシンプルです。いつ止めるか分からない・短期間なら、割高でも柔軟なオンデマンド。長期間安定して使い続けるなら、コミットして割引を得る Savings Plans か Reserved Instances。中断されても困らない処理なら、最大 90% 引きの Spot。この「コミットできるか」「中断に耐えられるか」の 2 軸で、最適な購入オプションが決まります。

ここで陥りやすい誤解を解いておきましょう。「とにかく Reserved Instances を買えば安くなる」という発想は危険です。コミットした分を使い切れなければ、割引どころか無駄な支払いが発生します。逆に、明らかに長期稼働するワークロードをオンデマンドで回し続けるのも、みすみす割引を逃しています。重要なのは、まず使用実績を分析してベースライン（常に必要な容量）を把握し、その安定部分にコミット型を、変動部分にオンデマンドや Spot を充てる、という階層的な設計です。実務では、ベースをコミット型で 60〜70%、ピークの変動分をオンデマンドや Spot で吸収する、といった組み合わせが現実的な落としどころになります。

Savings Plans の選定 — Compute か EC2 Instance か

Savings Plans には 2 タイプがあり、柔軟性と割引率がトレードオフになっています。

• Compute Savings Plans: 最大 66% 割引。EC2・Fargate・Lambda を横断して適用され、インスタンスファミリ・リージョン・OS が変わっても割引が効く。最も柔軟
• EC2 Instance Savings Plans: 最大 72% 割引。特定のインスタンスファミリとリージョンに固定する代わりに、より深い割引が得られる

判断軸は「将来の構成変更があるか」です。アーキテクチャが流動的で、使うサービスやインスタンスが変わりうるなら、柔軟な Compute Savings Plans。逆に「この M 系インスタンスをこのリージョンで使い続ける」と確信できるなら、より割引の深い EC2 Instance Savings Plans を選びます。Reserved Instances も同様の割引水準ですが、Savings Plans の方が適用範囲の柔軟性で優れるため、近年は Savings Plans が推奨される場面が増えています。

コミット期間と支払い方法も割引率に影響します。1 年より 3 年の方が、また全額前払いの方が部分前払い・前払いなしより、割引は深くなります。試験では「割引を最大化したい」という要件なら 3 年・全額前払い、「キャッシュフローの柔軟性も保ちたい」なら 1 年・前払いなし、といった文脈から適切な選択を導きます。とはいえ、3 年コミットは技術の陳腐化リスクも伴います。Graviton のような新世代へ移行する余地を残すなら、あえて柔軟な選択を取る判断もありえます。AWS SAA-C03 コスト最適化では、割引率だけでなく、こうした将来の自由度とのバランスまで含めて問われることがあります。

Spot インスタンスの活用と中断耐性設計

最大 90% という破格の割引を持つのが Spot インスタンスです。AWS の余剰キャパシティを安く使える仕組みですが、AWS 側の都合で中断（回収）される可能性があります。

この中断という性質ゆえ、Spot は「中断されても問題ない設計」とセットで使う必要があります。具体的には、ステートレスなバッチ処理、ビッグデータ分析、CI/CD のビルド、機械学習の学習ジョブなど、途中で止まっても再実行できるワークロードです。逆に、状態を持つデータベースや、止まると困る本番 Web サーバーには不向きです。

実践的には、オンデマンドや Savings Plans で確保したベース容量に、Spot で変動分を上乗せする「混在構成」が定石です。Auto Scaling グループで複数のインスタンスタイプとオンデマンド/Spot の比率を指定すれば、可用性とコストのバランスを取れます。AWS SAA-C03 コスト最適化では、「このワークロードは Spot に載せられるか」を見極める判断が頻出します。

Spot を安全に使うコツは、中断の予兆に備えることです。AWS は回収の少し前に中断通知を出すため、これを受けて処理中のデータをチェックポイントとして保存し、別のインスタンスで再開できるように設計します。また、特定のインスタンスタイプに依存せず、複数のタイプ・複数の AZ にまたがって Spot を要求すれば、一斉回収のリスクを分散できます。コンテナオーケストレーションと組み合わせれば、中断されたタスクを自動で別ノードへ振り直すことも容易です。「最大 90% 引き」という数字だけに飛びつかず、中断を前提とした運用設計まで含めて評価するのが、成熟したコスト最適化の姿勢です。

S3 ストレージクラスとコスト — 6 クラスを使い分ける

ストレージコストの最適化は、S3 のストレージクラス選択から始まります。アクセス頻度と取り出しコストのトレードオフで、最適なクラスが変わります。

S3 Standard とDeep Archive の単価差は約 23 倍に達します。アクセス頻度の低いデータを Standard に置きっぱなしにするのは、大きな無駄です。判断軸は「どれくらいの頻度でアクセスするか」「取り出しにどれくらい待てるか」。頻繁に読むなら Standard、たまにしか読まないが即時性は欲しいなら Standard-IA や Glacier Instant Retrieval、長期保管でほぼ読まないなら Deep Archive、というふうに選びます。なお Standard-IA と One Zone-IA は最小オブジェクトサイズ 128KB・最小保存期間 30 日の課金条件がある点にも注意が必要です。

見落としがちなのが、安価なクラスに潜む「取り出しコスト」です。Standard-IA や Glacier 系は保管単価が安い一方、データを読み出す際に取り出し料金が発生します。つまり、頻繁にアクセスするデータを安易に IA クラスへ移すと、保管費は減っても取り出し費がかさみ、かえって総額が増えることがあります。さらに One Zone-IA は単一 AZ にしかデータを置かないため、その AZ が失われるとデータも失われます。可用性を犠牲にしてよいか、という観点も忘れてはいけません。安いクラスには必ず代償がある——この理解が、クラス選択を誤らないための鍵です。

S3 ライフサイクルと Intelligent-Tiering による自動最適化

ストレージクラスを手動で管理するのは現実的ではありません。そこで自動化の仕組みが用意されています。

S3 ライフサイクルポリシーは、オブジェクトの経過日数に応じて自動でクラスを移行させます。たとえば「作成から 30 日経ったら Standard-IA へ、90 日経ったら Glacier へ、365 日経ったら削除」というルールを設定すれば、データの鮮度に応じてコストが自動で最適化されます。ログやバックアップのように、時間とともにアクセス頻度が下がるデータに最適です。

アクセスパターンが読めない場合は、S3 Intelligent-Tiering が有効です。これはアクセス頻度を監視し、自動的に最適なアクセス階層へ移動させます。手動でルールを組まなくても、頻繁に使われるデータは高速な層に、使われなくなったデータは安価な層に自動で振り分けられます。「アクセスパターンが予測できないが、コストは最適化したい」という要件は Intelligent-Tiering の出番です。ライフサイクルが「経過日数という決め打ちのルール」で動くのに対し、Intelligent-Tiering は「実際のアクセス実績」で動く、という違いを押さえておくと、設問での選び分けに迷いません。

データ転送コスト — 見落とされる「隠れた料金」

コスト設計で最も見落とされがちなのが、データ転送料金です。AWS では、インターネットへの送信（アウトバウンド）や、リージョン間・AZ 間のデータ転送に課金されます。逆に、インターネットからの受信（インバウンド）は通常無料です。

この非対称性が、設計に影響します。たとえば、大量のデータを頻繁にインターネットへ配信するなら、CloudFront を挟むことでデータ転送コストを下げられます。CloudFront 経由の配信は、S3 から直接インターネットへ出すよりデータ転送料金が安く設定されているからです。また、リージョンをまたぐ通信や AZ をまたぐ通信にも課金されるため、関連性の高いコンポーネントは同一 AZ・同一リージョンに寄せる、という設計判断もコストに効きます。AWS SAA-C03 コスト最適化では、この「データの移動にいくらかかるか」を意識した設計が問われます。

もうひとつの重要な手段が VPC エンドポイントです。VPC 内のリソースが S3 や DynamoDB にアクセスする際、通常はインターネットゲートウェイや NAT ゲートウェイを経由し、データ転送料金や NAT の処理料金がかかります。ゲートウェイ型 VPC エンドポイントを使えば、AWS 内部の経路で直接アクセスでき、これらのコストを回避できます。特に NAT ゲートウェイは処理データ量に応じた課金が地味に効いてくるため、S3 への大量アクセスがあるワークロードでは VPC エンドポイントの導入が定石です。「データ転送コストを下げたい」という設問では、CloudFront、同一 AZ 集約、VPC エンドポイントの 3 つを引き出しとして持っておくと強いです。

コスト可視化 — Cost Explorer・Budgets・CUR

コストを最適化するには、まず現状を可視化する必要があります。AWS には 3 つの主要ツールがあります。

使い分けは明快です。「コストの傾向を見たい・どのサービスが高いか分析したい」なら Cost Explorer。「予算オーバーを防ぎたい・しきい値で通知してほしい」なら Budgets。「明細レベルで徹底的に分析したい」なら CUR を BI ツールや分析基盤に取り込みます。可視化なくして最適化なし、というのがコスト管理の鉄則です。

組織レベルでは、コスト配分タグと AWS Organizations の連携も重要です。リソースにプロジェクトや部門のタグを付けておけば、Cost Explorer でその軸ごとにコストを分解でき、「どのチームがいくら使っているか」が明確になります。さらに、複数アカウントの請求を統合し、Savings Plans や Reserved Instances の割引を組織全体で共有する一括請求の仕組みを使えば、個々のアカウントでは届かない割引水準にまとめて到達できます。コストの可視化は、技術的な最適化だけでなく、組織のガバナンスとも地続きなのです。

AI 推論コストの最適化 — 賢く削る

AI ワークロードは GPU を使うため、コストが膨らみやすい領域です。ここでも最適化の原則は共通します。

第一に、適切なモデルとインスタンスの選択です。すべてのタスクに最大のモデルを使う必要はありません。簡単なタスクには軽量モデルを、難しいタスクにのみ大規模モデルを使う「モデルの使い分け」が、コストを大きく左右します。第二に、バッチ処理の活用です。リアルタイム性が不要な推論は、まとめてバッチで処理する方が単価を抑えられます。第三に、キャッシュです。同じ入力に対する推論結果をキャッシュすれば、無駄な再計算を避けられます。性能設計とコスト最適化が地続きであることが、ここでもよく分かります。AWS SAA-C03 コスト最適化の判断軸は、最新の AI ワークロードにもそのまま通用します。

設計シナリオ演習 — 5 つの典型問題

判断軸を試験形式で確認します。

シナリオ 1: 24 時間 365 日、安定して稼働し続ける本番サーバー。 オンデマンドのままでは割高です。正解は Savings Plans か Reserved Instances でコミットし、割引を得ることです。

シナリオ 2: 夜間に走るバッチ処理。中断されても再実行できる。 オンデマンドは過剰なコストです。正解は Spot インスタンスで最大 90% 引きを狙うことです。

シナリオ 3: ログを 1 年保管するが、30 日を過ぎるとほぼ読まない。 Standard に置き続けるのは無駄。正解は S3 ライフサイクルで Glacier 系へ自動移行することです。

シナリオ 4: アクセスパターンが予測できないデータのコストを抑えたい。 手動のクラス管理は現実的でない。正解は S3 Intelligent-Tiering です。

シナリオ 5: S3 から大量のコンテンツを世界中へ配信し、転送料金が高い。 直接配信を続けるのは不利。正解は CloudFront を挟み、データ転送コストとレイテンシを同時に下げることです。

5 問とも、判断は「コミットできるか」「中断に耐えられるか」「アクセス頻度はどうか」「データの移動を減らせるか」という問いに帰着します。

まとめ — Domain 4 のチェックリスト

AWS SAA-C03 コスト最適化は、次のチェックリストに集約できます。

• 適正サイジングと弾力性で「使っていないものに払わない」
• 安定継続なら Savings Plans / RI、短期なら オンデマンド、中断耐性なら Spot
• Savings Plans は柔軟性なら Compute、深い割引なら EC2 Instance
• S3 はアクセス頻度でクラスを選び、ライフサイクルで自動移行
• 予測不能なアクセスは Intelligent-Tiering
• データ転送はアウトバウンド課金。CloudFront や同一 AZ 集約で削減
• 可視化は Cost Explorer、予算アラートは Budgets、明細分析は CUR
• AI 推論はモデル使い分け・バッチ・キャッシュで削る

コスト最適化で忘れてはならないのは、最適化は一度きりの作業ではなく継続的な活動だという点です。ワークロードは時間とともに変化し、新しいインスタンスタイプやサービスも次々と登場します。定期的にコストを見直し、適正サイジングをやり直し、より有利な購入オプションへ乗り換える。この継続的な改善のサイクルこそが、長期的にコストを抑え続ける唯一の方法です。設計時点の最適が、半年後も最適とは限らないのです。

これで SAA-C03 の 4 ドメインがすべて揃いました。あとは、個別の知識を「解答力」に変える段階です。次は頻出アーキテクチャパターンを整理し、模擬問題 30 問で実戦感覚を磨きます。知識を得点に変換する仕上げに進みましょう。

参照

• AWS Certified Solutions Architect – Associate（SAA-C03）公式
• AWS Savings Plans 公式
• Amazon EC2 Spot インスタンス
• Amazon S3 ストレージクラス
• Amazon S3 料金
• AWS コスト管理

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.