【MLA-C01】インフラのコード化とオートスケール｜CloudFormation/CDK・自動スケーリング・BYOC・VPCを図解

デプロイ方式を決めたら、次はインフラをどう用意・運用するかです。手作業で構築すると再現できず、属人化します。MLA-C01では、インフラをコードで定義（IaC）して再現可能にし、トラフィックに応じて自動でスケールさせ、独自環境をBYOCで持ち込み、VPCで安全に隔離する——という運用設計が問われます。前の記事は M3-1、全体像はシラバスマップをどうぞ。

インフラをコード化し、トラフィックに応じて自動でスケールさせるイメージ図 — 図：インフラはコードで定義すれば、何度でも同じ構成を再現できます。あわせて需要に応じた自動スケールで、性能とコストを両立します。

インフラをコードで定義する：IaC
需要に応じて自動で増減：オートスケーリング
独自環境を持ち込む：BYOC
安全に隔離する：VPC内のエンドポイント
確認クイズ
よくある質問（FAQ）
まとめ

インフラをコードで定義する：IaC

同じ構成を検証環境と本番環境にそろえたり、変更履歴を管理したりするには、インフラをコードとして記述（Infrastructure as Code）します。手動構築と違い、再現性・バージョン管理・自動化が得られます。

ツール	特徴
AWS CloudFormation	JSON/YAMLのテンプレートでインフラを宣言的に定義
AWS CDK	プログラミング言語（Python/TypeScript等）でインフラを記述

どちらもIaC。テンプレートで宣言的に書くならCloudFormation、慣れた言語で柔軟に書くならCDKが目安です。

需要に応じて自動で増減：オートスケーリング

トラフィックは時間帯やイベントで変動します。SageMakerエンドポイントのオートスケーリングは、指標に基づいてインスタンス数を自動で増減させ、ピークの性能と閑散時のコストを両立します。

トラフィックに応じてインスタンス数を自動で増減させるオートスケーリングの図 — 図：負荷が上がればインスタンスを増やし、下がれば減らす。固定台数より、性能とコストのバランスが取れます。

スケールの指標：インスタンスあたりの呼び出し数（invocations per instance）、CPU使用率、モデルのレイテンシなどを基準に設定
コスト最適化：学習などではスポットインスタンスを使うと安価（中断の可能性は許容）

独自環境を持ち込む：BYOC

SageMaker提供のコンテナで要件を満たせない場合、BYOC（Bring Your Own Container）で独自のDockerイメージをAmazon ECRに登録して使います。依存ライブラリや実行環境を自分で管理する代わりに、自由度が高いのが特徴です（責任範囲も自分側に移る点に注意）。

安全に隔離する：VPC内のエンドポイント

推論エンドポイントをインターネットに公開せず、VPC内に配置すれば、通信を閉域に閉じて安全性を高められます。サブネットやセキュリティグループで、アクセスできる範囲を制御します。

確認クイズ

Q1. あなたが運用するリアルタイム推論エンドポイントは、日中はリクエストが急増し、夜間はほとんど来ません。固定台数で運用したところ、ピーク時は遅延し、閑散時はインスタンスが無駄になっています。性能とコストを両立する最も適切な対策はどれですか。

A. ピークに合わせてインスタンス数を常時最大のまま固定する。

B. 最小の1台に固定し、遅延は許容する。

C. エンドポイントのオートスケーリングを設定し、呼び出し数などの指標に応じてインスタンス数を自動で増減させる。

D. 負荷の変化に合わせて担当者が毎回手動でインスタンス数を変更する。

Q2. あなたのチームは、検証環境と本番環境でまったく同じインフラ構成を再現し、構成の変更履歴を管理して、ワンクリックに近い形で展開できるようにしたいと考えています。最も適切なアプローチはどれですか。

A. AWS CloudFormationやAWS CDKでインフラをコードとして定義し、テンプレートをバージョン管理して各環境へ展開する。

B. マネジメントコンソールで毎回手作業でリソースを作成する。

C. 構築手順を文章の手順書にまとめ、担当者がその都度なぞる。

D. 設定画面のスクリーンショットを保存し、それを見ながら再現する。

Q3. あなたは特殊なライブラリと独自の実行環境を必要とするモデルをSageMakerでホストします。SageMaker提供の標準コンテナでは要件を満たせません。独自のDockerイメージで実行環境を持ち込みたい場合、最も適切な方法はどれですか。

A. 要件をあきらめ、標準コンテナで動く別のアルゴリズムに変更する。

B. ライブラリを推論時に毎回インターネットから動的に取得する。

C. 標準コンテナのまま、不足するライブラリは無視して実行する。

D. BYOCで独自のDockerイメージを作成し、Amazon ECRに登録してSageMakerで使用する。

Q4. あなたは機微なデータを扱う推論エンドポイントを運用します。エンドポイントをインターネットに公開せず、社内ネットワークからの閉じた通信だけに限定して、セキュリティを高めたいと考えています。最も適切な構成はどれですか。

A. エンドポイントをパブリックに公開し、認証だけで保護する。

B. エンドポイントをVPC内に配置し、サブネットとセキュリティグループでアクセス範囲を制御する。

C. 特に対策はせず、URLを知っている人だけがアクセスできる前提にする。

D. データを暗号化すれば公開しても問題ないと考え、公開のまま運用する。

よくある質問（FAQ）

Q. CloudFormationとCDKはどちらを使うべき？

A. どちらもIaCです。宣言的なテンプレートで管理したいならCloudFormation、使い慣れた言語で柔軟に書きたいならCDKが目安です。

Q. オートスケーリングの指標は何を使う？

A. インスタンスあたりの呼び出し数・CPU使用率・モデルのレイテンシなどを基準に設定します。負荷の特性に合った指標を選びます。

Q. スポットインスタンスはどんな場面で使う？

A. 中断されても再開できる学習ジョブなどコスト重視の場面に向きます。常時の本番推論には安定性を優先します。

まとめ

インフラはIaC（CloudFormation/CDK）でコード化し、再現性・履歴・自動展開を得る
オートスケーリングで需要に応じてインスタンスを自動増減し、性能とコストを両立
独自環境はBYOC（ECRに登録）、コスト重視の学習はスポット
機微な推論はVPC内に配置し、サブネット・セキュリティグループで隔離

🎯 次のステップ

➡ 次の記事：M3-3 CI/CDパイプライン（CodePipeline・SageMaker Pipelines・blue/green・canary）※準備中
➡ 前の記事：M3-1 デプロイ基盤の選択／シラバスマップ

※本記事はAWS公式試験ガイド(MLA-C01)および各サービスの公開ドキュメントに基づき、エンジニアKが作成しています。サービス仕様は更新されることがあるため、最新は必ずAWS公式でご確認ください。本サイトはAmazon Web Services, Inc.の公式サイトではありません。AWSは同社の商標です。