コスト最適化総合

このレッスンでできるようになること。SAA の設問末尾に付く定番の言い回しを見分けて、同じシナリオでも答えが変わる理由を説明できるようになります。

要件の文から入る

ある会社が、社内向けのバッチ処理を EC2 上の自前スクリプトで動かしています。1 日 1 回、数分で終わり、残りの時間はアイドルです。この構成をどう変えますか。

ここで気づいてほしいのは、この文だけでは答えが決まらないことです。設問の最後の一文で答えが変わります。「最も低コストで」なら Lambda か、スケジュール起動する Fargate タスクです。「アプリを改修せずに」なら EC2 のまま、インスタンスのスケジュール停止か Auto Scaling のスケジュールアクションになります。SAA が測っているのは構成の知識だけではなく、この最後の一文を拾えるかです。

3 つの言い回しが指す方向

同じ「共有ファイルを置きたい」という要件でも、最も低コストならライフサイクルを効かせた S3、運用の手間を最小にするなら EFS、アプリを改修せずに (既存のコードが SMB や NFS のパスを直接読んでいる) なら FSx for Windows File Server や EFS になります。要件の本体が同じでも、末尾で行き先が変わるというのがこの章の要点です。

3 つが衝突したときの優先順位

本番では 2 つ以上が同時に書かれます。そのときの読み方は次のとおりです。

1. 機能要件と制約が最優先。 「アプリを改修せずに」「ダウンタイムなしで」「既存のライセンスを維持したまま」は、満たさなければその選択肢は成立しません。どれだけ安くても失格です
2. 次が運用のオーバーヘッド。 「最小の運用オーバーヘッドで」と「最も低コストで」が同時に書かれていたら、マネージドサービス側を選びます。自前で EC2 に構築して安く上げる案は、SAA では基本的に誤答の側に置かれます
3. 最後がコスト。 上の 2 つを満たす候補が複数残ったときに、その中で最も安いものを選びます

つまりコストは同点決勝の基準であって、単独で最上位に来ることは少ない、と覚えます。「最も低コストで要件を満たす」という言い方自体が、要件が先だと言っています。

見落としやすい費用の場所

コスト比較の問題では、インスタンスの単価以外が決め手になることがあります。

• データ転送。AWS からインターネットへ出る通信には費用がかかります。AZ をまたぐ通信や、NAT ゲートウェイを通る通信も同様です。「S3 への大量アクセスの費用を下げたい」なら、NAT ゲートウェイ経由をやめて Gateway 型の VPC エンドポイントにするのが定番の答えです
• NAT ゲートウェイの本数。可用性のため AZ ごとに置くのが基本ですが、費用の要件が強いシナリオでは本数が論点になります
• アイドル時間。使っていない時間も課金される形か、使ったときだけ課金される形かは、稼働率が低いワークロードで大きな差になります
• 総保有コスト。マネージドサービスは単価だけを見ると高く映りますが、パッチ適用やバックアップ、障害対応の人手を含めた比較では逆になる、というのが SAA の標準的な立場です

要件語から構成への対応表

よくある引っ掛け

1 つめは、「最小の運用オーバーヘッドで」と書かれているのに、EC2 上に自前でミドルウェアを構築する案を選んでしまうものです。単価は下がっても、この一文がある限り成立しません。

2 つめは、「アプリを改修せずに」と書かれているのに、コードの書き換えを伴うサーバーレス化を選んでしまうものです。低コストという語が同時にあっても、改修禁止のほうが上位の制約です。

まとめ

• 設問の最後の一文で答えが変わります。本体だけ読んで決めません
• 低コストはサーバーレスやスポット、運用の手間の最小化はマネージド、改修禁止は既存インターフェースの維持へ向かいます
• 衝突したら、制約が最優先、次に運用のオーバーヘッド、最後にコストの順です
• データ転送や NAT ゲートウェイなど、単価以外の費用が決め手になることがあります
• マネージドサービスは総保有コストで比較する、というのが SAA の立場です