AIAI Agent Dev Labaiagentdev-lab.com
3分適性診断 →
無料で学習を始める／ログイン無料で始める
メニュー

SAA-C03 · LESSON 4

コストを最適化したアーキテクチャの設計20% · 4項目

コストを最適化したストレージ、コンピューティング、データベース、ネットワークの設計を学びます。

4.1コストを最適化したストレージを設計する

4.1 Design cost-optimized storage solutions.

概念

S3 では、アクセス頻度に合わせたストレージクラスとライフサイクルルールの組み合わせがコスト削減の中心です。アクセスのパターンが不明・変化するなら S3 Intelligent-Tiering、再作成できるデータは One Zone-IA、長期の保管は Glacier Flexible Retrieval や Deep Archive。EBS は gp2 から gp3 への変更、未使用のボリュームとスナップショットの削除で削減します。

仕組み・手順

  1. S3 Storage Lens やストレージクラス分析でアクセスの傾向を確認する
  2. ライフサイクルルールで古いデータを安いクラスに移し、不要なものは期限で削除する
  3. 取り出しの頻度と時間の要件に合う Glacier のクラスを選ぶ
  4. EBS を gp3 に変更し、使っていないボリュームを削除する
  5. 不完全なマルチパートアップロードを自動で削除する

業務での例

監査ログを 90 日は Standard、その後 Glacier Flexible Retrieval、7 年後に削除するルールを設定し、取り出しは年に 1 回の監査のときだけにする。

紛らわしい点・試験の注意

ミニクイズ

Q1. 作成から30日間はよく参照し、その後1年間はたまに参照し、それ以降はほとんど参照しない帳票データがある。7年後には削除してよい。最も適切な設定はどれか。

  1. EBS のスナップショットとして保存し、毎年作り直す
  2. 最初から Glacier Deep Archive に保存しておき、参照が必要になるたびに復元して取り出す
  3. すべてを S3 Standard に保存し、7年後に手作業で削除する
  4. ライフサイクルで30日後に Standard-IA、1年後に Deep Archive へ移し、7年後に削除する
答えと解説を見る

正解：D　ライフサイクルで30日後に Standard-IA、1年後に Deep Archive へ移し、7年後に削除する

アクセス頻度の変化が分かっているなら、ライフサイクルルールで段階的に安いクラスへ移し、保存期間の終わりに削除する。

Q2. バージョニングを有効にした S3 バケットの保存費用が増え続けている。最も適切な対策はどれか。

  1. ライフサイクルルールで、非現行バージョンを移行または削除する
  2. オブジェクトの名前を短くして、保存容量を減らす
  3. バケットを別のリージョンにコピーして、元のバケットを削除する
  4. バージョニングを停止すれば、過去のバージョンも自動で削除される
答えと解説を見る

正解：A　ライフサイクルルールで、非現行バージョンを移行または削除する

バージョニングでは非現行バージョンも保存料金の対象になる。ライフサイクルルールで非現行バージョンの移行・削除を設定する。停止しても既存のバージョンは残る。

参考リンク

4.2コストを最適化したコンピューティングを設計する

4.2 Design cost-optimized compute solutions.

概念

購入オプションの組み合わせ（安定した基盤は Savings Plans、変動はオンデマンド、中断可能はスポット）と、ライトサイジング（AWS Compute Optimizer の推奨）、Graviton への移行、使わない時間の停止、サーバーレスの活用でコストを下げます。Auto Scaling グループでは、オンデマンドとスポットを混在させられます。

仕組み・手順

  1. Compute Optimizer で過剰なサイズのインスタンスを特定する
  2. 常時の利用は Compute Savings Plans で割引する
  3. 中断に強いバッチやステートレスな処理にスポットを使う
  4. 開発環境は夜間・週末に自動で停止する
  5. 断続的な処理は Lambda や Fargate にして待機時間の費用をなくす

業務での例

CI のビルドサーバーをスポットのみの Auto Scaling グループにし、本番の Web は最低台数分を Savings Plans、ピークはオンデマンドで賄う。

紛らわしい点・試験の注意

ミニクイズ

Q1. 過大なサイズの EC2 インスタンスを見つけて、適切なサイズを提案してほしい。最も適したサービスはどれか。

  1. AWS Artifact
  2. AWS Compute Optimizer
  3. Amazon Inspector
  4. AWS Pricing Calculator
答えと解説を見る

正解：B　AWS Compute Optimizer

Compute Optimizer は使用状況のメトリクスを分析し、EC2・EBS・Lambda などの適正なサイズや設定を推奨する。

Q2. Auto Scaling グループで、常に必要な最低限の台数と、負荷の増加分を分けて費用を下げたい。最も適切な構成はどれか。

  1. ピーク時の台数分のリザーブドインスタンスを 1 年で購入する
  2. すべての台数を Savings Plans の対象にし、スポットは使わない
  3. 基本の台数をスポット、増加分をオンデマンドにする
  4. 基本の台数は割引付きのオンデマンド、増加分はスポットも含めて自動で増減する
答えと解説を見る

正解：D　基本の台数は割引付きのオンデマンド、増加分はスポットも含めて自動で増減する

常時必要な分は長期割引、変動分はスポットやオンデマンドで Auto Scaling する組み合わせが、費用と可用性のバランスがよい。 【他の選択肢】すべてを割引の対象にすると、使わない時間の分も約束することになる。基本の台数をスポットにすると中断で最低限の台数を保てない。ピーク分の予約は無駄が出る。

参考リンク

4.3コストを最適化したデータベースを設計する

4.3 Design cost-optimized database solutions.

概念

DynamoDB のキャパシティモードは、予測できない負荷にはオンデマンド、安定した負荷にはプロビジョンド（自動スケーリングとリザーブドキャパシティで割引）。RDS は適正なインスタンスのサイズ、リザーブドインスタンス、開発環境の停止、Aurora Serverless v2 で負荷に合わせた課金を使います。アクセスの少ない項目は DynamoDB の標準 IA テーブルクラスにすると保存の費用が下がります。

仕組み・手順

  1. 負荷のパターン（安定・変動・断続的）を確認する
  2. DynamoDB はパターンに合うキャパシティモードとテーブルクラスを選ぶ
  3. RDS の常時稼働の本番はリザーブドインスタンスで割引する
  4. 断続的に使う DB は Aurora Serverless v2 にする
  5. TTL で不要な項目を自動で削除し、保存の費用を下げる

業務での例

新しいサービスの負荷が読めない間は DynamoDB のオンデマンドで運用し、半年後に負荷が安定したらプロビジョンドと自動スケーリングに切り替える。

紛らわしい点・試験の注意

ミニクイズ

Q1. リレーショナル DB を使う社内の申請システムは、平日の日中に数時間だけ使われる。費用を下げる方法として最も適切なものはどれか。

  1. 申請システムを EC2 のインスタンスストアで動かす
  2. 最大サイズの RDS インスタンスを常時稼働させる
  3. Aurora Serverless v2 で、負荷に応じて容量を自動で小さく保つ
  4. リードレプリカを5つ追加する
答えと解説を見る

正解：C　Aurora Serverless v2 で、負荷に応じて容量を自動で小さく保つ

使われる時間が限られる DB は、容量を自動で調整する Aurora Serverless v2 や、使わない時間の停止で費用を抑えられる。

Q2. コンテナの実行環境を選んでいる。常に一定の負荷がかかり、大きな台数を長期間使う。費用を最も重視する場合の考え方として最も適切なものはどれか。

  1. EC2 起動タイプに割引を適用し、インスタンスの利用率を高く保つ
  2. 負荷にかかわらず、常に Fargate のオンデマンドだけを使う
  3. 台数を必要の2倍にして、余裕を持たせる
  4. コンテナをやめて、Lambda で常時処理する
答えと解説を見る

正解：A　EC2 起動タイプに割引を適用し、インスタンスの利用率を高く保つ

常時大きな負荷がある場合は、EC2 の容量を割引で確保して高い利用率で使うと割安になりやすい。運用の手間を減らしたいなら Fargate（Savings Plans も適用可）を選ぶ。

参考リンク

4.4コストを最適化したネットワークを設計する

4.4 Design cost-optimized network architectures.

概念

データ転送の料金を意識した設計が重要です。インターネットへの送信、AZ 間・リージョン間の転送は有料です。NAT ゲートウェイは時間と処理したデータ量で課金されるため、S3・DynamoDB へはゲートウェイ VPC エンドポイント（無料）を使います。CloudFront からの配信は、オリジンから直接配信するより送信の料金が安くなることが多いです。

仕組み・手順

  1. Cost Explorer でデータ転送の費用の内訳を確認する
  2. S3・DynamoDB への通信をゲートウェイエンドポイントに切り替え、NAT の処理料金を減らす
  3. 利用者への配信は CloudFront のキャッシュを使う
  4. AZ 間で大量に通信する構成を見直す（ただし可用性とのバランスを取る）
  5. 多数の VPC の接続は Transit Gateway とピアリングの費用を比べる

業務での例

プライベートサブネットのバッチが NAT ゲートウェイ経由で S3 に毎日 5 TB を送っていたため、ゲートウェイエンドポイントに変えて NAT の処理料金をなくす。

紛らわしい点・試験の注意

ミニクイズ

Q1. 部門ごとの AWS の費用を把握し、予算を超えそうなときに通知したい。最も適切な組み合わせはどれか。

  1. コスト配分タグを付け、Cost Explorer で分析し、Budgets で通知する
  2. CloudWatch の請求アラームを、部門ごとのメトリクスで設定する
  3. 部門ごとに Savings Plans を購入し、割引の利用率を確認する
  4. 部門ごとに Cost and Usage Report を出力し、月末に Athena で集計する
答えと解説を見る

正解：A　コスト配分タグを付け、Cost Explorer で分析し、Budgets で通知する

タグで費用を部門に配分し、Cost Explorer で可視化し、Budgets で予算の実績・予測に対する通知を設定する。 【他の選択肢】CUR と Athena は月末の集計で、予算の超過の前に通知できない。請求アラームはアカウント全体の推定請求額で、部門別の配分にならない。Savings Plans は割引の手段で、配分や通知ではない。

Q2. Cost Explorer で、データ転送の費用が先月から3倍に増えていることが分かった。次に行うべきこととして最も適切なものはどれか。

  1. すべての VPC に S3 のゲートウェイエンドポイントを追加する
  2. すぐに CloudFront を全サービスの前に置く
  3. 使用タイプ別に内訳を見て、どの経路の転送が増えたかを特定する
  4. Savings Plans を購入し、転送の費用を割り引く
答えと解説を見る

正解：C　使用タイプ別に内訳を見て、どの経路の転送が増えたかを特定する

まず転送の種類と発生元を特定する。NAT 経由の S3 通信ならゲートウェイエンドポイント、配信なら CloudFront など、原因に応じた対策を選ぶ。 【他の選択肢】原因を特定する前の対策は効果が分からない。ゲートウェイエンドポイントは NAT 経由の S3 通信だけに効く。Savings Plans はデータ転送を割り引かない。

参考リンク

レッスンは当サイトがAWS 認定の公式ページと公式試験ガイドをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。

ご利用上の注意（非公式・独自問題・合格保証なし）