コスト管理（FinOps）

クラウドでは、エンジニアが設定を1つ変えるだけで毎月の費用が大きく変わります。そのため、コストを財務部門だけの話にせず、設計・運用する人が自分の判断の結果として見えるようにすることが大事です。この考え方をFinOpsと呼び、FinOps Foundationは、見える化（Inform）・最適化（Optimize）・運用（Operate）の3つの段階を繰り返すモデルを示しています。

コストの改善も「計測 → 改善 → 回帰を防ぐ」。性能チューニングと同じ形。

• 可視化：タグ付け、Cost Explorer、チーム・サービス単位の按分

• 購入オプション：Savings Plans、リザーブド、スポット（中断耐性のあるワークロード）

• 適正化：使われていないリソースの削除、インスタンスサイズの見直し、Graviton への移行

• 「信頼性とコストのトレードオフ」をどう判断したかを具体例で話せるとよい

第8章「ストレージ」：S3のストレージクラスとライフサイクルを図で詳しく

削減率は利用条件で変わるため、面接では「実際にいくら・何%削減したか」を自分の数字で話すのが一番強い。

クラウドの請求は、サーバーの台数や大きさだけでは決まりません。データがどこを通ったか（NAT ゲートウェイ・AZ の間・インターネットへの出口）や、ログの量、消し忘れたリソースにも料金がかかり、構成図を見ても気づきにくいところで膨らみます。

SRE はコストも信頼性と並ぶ運用の指標として見ます。「先月から急に増えた」と聞かれたときに、どの項目から疑うかの当たりを付けられるようにしておきます。

請求書の「EC2-その他」や「データ転送」が大きいときは、まず通信の経路を疑う。

下の「ブラウザで試す」の図では、プライベートサブネットのアプリが外部 API を呼ぶときに NAT ゲートウェイを通る経路と、S3 へのバックアップをゲートウェイ型の VPC エンドポイントに向けて NAT を通さずに届ける経路を順に見られます。表の1行目「NAT Gatewayの処理料金」に関係するのは後半の「NAT GW の料金に注意」の手順で、通ったデータ量ごとに料金がかかる経路と、それをどこで迂回できるかに注目してください。

割引契約は、過去の使用量のうち「最低でも常に使っている量」に合わせて買います。全部を契約で覆おうとすると、使用量が減ったときに無駄が出ます。購入後は、利用率（約束した額をどれだけ使えたか）とカバー率（使用量のうち割引が効いた割合）を定期的に確認します。アーキテクチャの変更（Gravitonへの移行、Fargateへの移行）を予定しているなら、その計画も考えて種類と期間を選びます。

割引契約は「土台」だけ。山の部分はオンデマンドとオートスケールで。

AWSのWell-Architected Frameworkにもコスト最適化の柱があり、信頼性やパフォーマンスの柱とあわせてトレードオフを検討する考え方が示されています。面接では「コストを下げた経験」に加えて、「信頼性を落とさないためにどこは削らなかったか」を話せると、判断の質が伝わります。