SageMaker推論本番運用【Serverless/Async/MME/HyperPod】

1. この記事について — SageMaker 推論・デプロイ層を本番で固める

1-1. 本記事のゴール

本記事を読み終えると、SageMaker が提供するリアルタイム・Serverless・Asynchronous・Multi-Model Endpoint・Inference Components・HyperPod 推論という複数の推論方式を、トラフィック特性やコスト制約に応じて本番ワークロードへ選定・実装・運用できる状態に到達します。

具体的には、①各方式の選定基準を実装判断に落とし込む、②boto3 / Terraform でエンドポイントを構築する、③Auto Scaling とプロダクションバリアントで可用性を確保する、④CloudWatch でモデル推論を監視する、⑤方式別のコスト最適化を実施する、という一連の実務フローを主軸に解説します。概念理解ではなく「本番でどう動かすか」に焦点を当てているため、実装コードと運用チェックリストを中心に構成しています。

本記事を通じて次のスキルを習得できます。

• リアルタイム・Serverless・Asynchronous・Multi-Model Endpoint・Inference Components・HyperPod 推論の選定基準を実装判断に落とし込む力
• boto3 / Terraform を用いたエンドポイント構築、Auto Scaling ポリシー設計、プロダクションバリアントによる Blue-Green・Canary デプロイの実装力
• SageMaker 実行ロールの IAM 設計(iam:PassRole を含む)、VPC/KMS を用いたセキュリティ構成の実装力
• CloudWatch メトリクスを用いた推論監視と、推論方式別のコスト最適化を判断する力

1-2. 読者像

本記事は、Vol3 で SageMaker Pipelines・Feature Store を用いた学習パイプラインを本番運用しており、次の工程としてモデルをデプロイ・推論提供する段階に進んだ MLエンジニア・MLOps エンジニア・SRE を主な読者として想定しています。

すでに学習済みモデルを保有しており、「どのエンドポイント方式を選ぶべきか」「Auto Scaling をどう設計するか」「IAM/VPC をどう構成するか」といった本番実装の壁に直面しているチームに向けた内容です。認定資格の学習を目的とする読者(AWS Certified Machine Learning Engineer – Associate や AWS Certified AI Practitioner の受験者)は、試験対策シリーズ(後述)の方が概念理解の入口として適しています。本記事とは読者像・目的が異なる点にご留意ください。

1-3. 本シリーズの位置づけと既存記事との棲み分け

AWS ML/AI 本番運用シリーズは Vol3 までで「学習」を扱いました。Vol3 は SageMaker Studio・Autopilot・Model Monitor・SageMaker Pipelines・Feature Store という学習パイプラインの構築・運用を主題としています。本 Vol4 はその次工程にあたる「推論・デプロイ層」を扱い、学習済みモデルを本番トラフィックへ提供するフェーズに焦点を当てます。

一方、本記事の主題と概念レベルで重複しうる既存記事として、試験対策シリーズの MLA-C01 Vol3(D3「モデルのデプロイ・推論」)と AIF-C01 Vol1(§6「推論の種別」)があります。これらは Real-time / Serverless / Asynchronous / Batch Transform の使い分けや Multi-Model Endpoint と Multi-container Endpoint の違いを、認定資格の出題範囲に沿って概念レベルで解説する記事です。実装コード・IAM 設計・監視・コスト最適化までは踏み込んでいません。

本 Vol4 はこの2記事とは実務深度で明確に棲み分けます。推論方式の選定基準・概念的な違いは再解説せず、試験対策シリーズを「概念理解の入口」としてクロスリンクを用いて委譲したうえで、本記事は boto3 実装コード・IAM(iam:PassRole を含む)/VPC/KMS のセキュリティ設計・CloudWatch 監視・方式別コスト最適化という本番実装の実務に集中します。試験対策として推論方式の基礎を先に押さえたい場合は、以下の記事を参照してください。

関連：AWS MLA-C01 試験対策 Vol3 (D3 モデルのデプロイ・推論) を読む
関連：AWS AIF-C01 試験対策 Vol1 (§6 推論の種別) を読む

関連：ML/AI Vol3 (SageMaker MLOps・Pipelines・Feature Store) を読む

2. 前提 — SageMaker 推論方式の全体像と選定・実行環境

2-1. 推論方式の全体像と選定基準

SageMaker が提供する推論方式は、大きく分けて7種類あります。各方式の概念的な違いは試験対策シリーズ(MLA-C01 Vol3・AIF-C01 Vol1)で解説済みのため、本節では概念の再解説を避け、「本番でどう選ぶか」という実装判断に焦点を当てます。

Vol3 までで扱った学習パイプラインの出力(学習済みモデルアーティファクト)を受け取り、どの推論方式で本番トラフィックへ提供するかを決める、いわば学習と運用の橋渡しに当たる工程が本節の対象です。

選定は次の4軸で判断します。①トラフィックが常時発生するか断続的か(常時なら Real-time、断続的なら Serverless)。②ペイロードサイズと処理時間(1GB を超える、または処理に数分を要するなら Asynchronous か Batch Transform)。③同時にホストするモデル数とリソース効率(多数の小規模モデルを効率的にホストしたいなら MME、モデルごとに GPU 割当を細かく制御したいなら Inference Components)。④大規模 LLM 基盤かどうか(数十億パラメータ級のモデルを GPU クラスターで運用するなら HyperPod 推論を検討)。

これらの判断軸は単独では決まらず、複数の方式を組み合わせる構成も一般的です。たとえば、常時トラフィックのある主力モデルは Real-time エンドポイントで、利用頻度の低い実験的モデルは Serverless でホストし、大容量の画像・動画処理は Asynchronous Inference に振り分ける、といった使い分けが本番運用では現実的です。

選定を誤りやすいのはコスト構造の見落としです。Real-time エンドポイントはトラフィックの有無にかかわらずインスタンスが起動し続けるため、深夜帯にリクエストがほぼ発生しないワークロードでは、Serverless や Asynchronous への切り替えでコストを大幅に圧縮できるケースがあります。逆に、コールドスタートが許容できないレイテンシ要件(SLA でミリ秒単位を保証する場合など)には、Serverless の Provisioned Concurrency(事前ウォームアップ)設定でも解消しきれないことがあり、Real-time エンドポイントを Auto Scaling の最小容量を確保した状態で常時起動しておく設計が現実的です。§3〜§7 では、この選定基準を前提とした実装コードを方式ごとに提示します。

2-2. 実行環境・IAM・ネットワーク前提

推論エンドポイントを本番構築する前に、次の実行環境を整備する必要があります。

• SageMaker 実行ロール: sagemaker:CreateModel / sagemaker:CreateEndpointConfig / sagemaker:CreateEndpoint などの API を呼び出すロール、および SageMaker サービス自体がモデルコンテナ起動時に引き受ける実行ロールの双方を設計します
• モデルアーティファクト: S3 に格納した model.tar.gz (フレームワーク別のモデルファイル一式)
• 推論コンテナイメージ: ECR に配置した推論用コンテナ(SageMaker 提供の Deep Learning Container、または自前ビルドのカスタムコンテナ)
• VPC 構成: エンドポイントをプライベートサブネットに配置し、S3 / ECR へのアクセスは VPC エンドポイント経由に限定する構成
• KMS 暗号化: モデルアーティファクトの保存時暗号化、および推論インスタンスのボリューム暗号化に使用するカスタマー管理キー

呼び出し元(デプロイパイプライン)と SageMaker 実行ロール(モデルコンテナ自体)では必要な権限が異なるため、混同しないよう分けて設計します。

SageMaker 実行ロールの信頼ポリシー(trust policy)は、Principal を sagemaker.amazonaws.com に限定します。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": { "Service": "sagemaker.amazonaws.com" },
"Action": "sts:AssumeRole"
 }
  ]
}

ネットワーク面では、VpcConfig をエンドポイント設定(EndpointConfig)に指定することで、推論インスタンスをプライベートサブネットに配置できます。インターネットゲートウェイ経由の通信を遮断し、S3 / ECR / CloudWatch Logs へのアクセスはそれぞれの VPC エンドポイント(Gateway 型または Interface 型)経由に限定するのが、金融・医療など規制業界を含む本番構成の標準パターンです。

この中で本番設計上とくに注意すべきなのが iam:PassRole の設計です。SageMaker がエンドポイント作成時にモデルコンテナを起動する際、呼び出し元(ユーザーまたは CI/CD パイプラインの IAM ロール)は「この実行ロールを SageMaker サービスに渡してよい」という許可を明示的に持つ必要があります。これが iam:PassRole です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "AllowPassSageMakerExecutionRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/SageMakerInferenceExecutionRole",
"Condition": {
  "StringEquals": {
 "iam:PassedToService": "sagemaker.amazonaws.com"
  }
}
 }
  ]
}

このポリシーのポイントは2つです。①Resource を実行ロールの ARN に限定し、任意のロールを渡せる状態にしない。②iam:PassedToService 条件キーで渡し先を sagemaker.amazonaws.com に限定し、他サービスへの転用を防止する。この2点を欠くと、エンドポイント作成権限を持つ IAM プリンシパルが本来意図しない高権限ロールを SageMaker 経由で悪用できてしまうため、最小権限設計の要としてレビュー対象に含めてください。

2-3. ライフサイクルと鮮度の注意

本記事が扱う Real-time / Serverless / Asynchronous / Batch Transform / Multi-Model Endpoint / Inference Components は、いずれも成熟した機能であり(Inference Components は 2023年11月に一般提供開始)、東京リージョン(ap-northeast-1)を含む主要リージョンで広く利用できます。

一方、§6 で扱う SageMaker HyperPod 推論は比較的新しい発展的トピックです。公式ドキュメント(docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod.html)の「AWS Regions supported by SageMaker HyperPod」には ap-northeast-1(東京)が明記されており、HyperPod クラスター自体は東京リージョンで利用可能です。

ただし、HyperPod 上で推論を担う Inference Operator(Amazon EKS Add-on 化されたコンポーネント)は、2026年2月23日リリースの v3.0 で EKS Add-on 統合が導入されて以降、2026年5月・6月と短いスパンでマイナーバージョンが更新され続けている、比較的若い機能です。公式リリースノート(docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-inference-release-notes.html)にはバージョンごとの機能追加(Disaggregated Prefill and Decode・HuggingFace Hub 連携・Route 53 DNS 管理など)は詳細に記載されている一方、バージョン単位でのリージョン別提供状況は明記されていません。

本記事は「HyperPod クラスター自体が東京リージョンで提供されている」ことまでは公式ドキュメントの Region 一覧で確認していますが、Inference Operator の各マイナーバージョンが東京リージョンの EKS Add-on カタログにいつ反映されるかは変動しうるため、本記事では断定しません。§6 で HyperPod 推論の導入を検討する際は、実装前に必ず次のコマンドで対象リージョンでの提供状況を確認してください。

# EKS Add-on として利用可能な Inference Operator のバージョンをリージョン単位で確認
aws eks describe-addon-versions \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --region ap-northeast-1

コマンドの出力に目的のバージョンが含まれない場合、または公式ドキュメントの記載と実際の提供状況に差異がある場合は、断定的な判断を避け、AWS サポートまたは公式ドキュメントの最新版を確認したうえで採用可否を判断してください。この「まず公式一次情報と CLI で確認する」姿勢は、HyperPod に限らず頻繁にアップデートされる SageMaker 新機能全般に適用すべき原則です。

以上の選定基準・実行環境を前提に、§3 以降では方式ごとの実装に入ります。

なお §8 では、ここまでの実装を踏まえた詰まりポイント・アンチパターンと、本シリーズの次巻予告をまとめます。

§3 以降を読み進める際は、随時本節の選定基準表(§2-1)と IAM 設計(§2-2)に立ち返りながら、自身のワークロードに当てはめて読むことを推奨します。

3. リアルタイム推論エンドポイントの本番運用

3-1. boto3 による Model / EndpointConfig / Endpoint 作成

リアルタイムエンドポイントは、CreateModel → CreateEndpointConfig → CreateEndpoint という3段階の API 呼び出しで構築します。プロダクションバリアント(ProductionVariants)という単位でモデル・インスタンスタイプ・初期インスタンス数を紐付け、1つのエンドポイントに複数のバリアントを共存させられる構造が、後述する A/B テストや Blue/Green デプロイの土台になります。

なお、プロダクションバリアントの概念そのものは試験対策シリーズで解説済みのため、ここでは再解説せず実装に絞ります。

関連:AWS MLA-C01 試験対策 Vol3 (D3 モデルのデプロイ・推論) でプロダクションバリアントの基礎を確認する

import boto3

sagemaker_client = boto3.client("sagemaker", region_name="ap-northeast-1")

model_name = "fraud-detection-xgb-2026-07"
endpoint_config_name = "fraud-detection-xgb-realtime-config-v3"
endpoint_name = "fraud-detection-xgb-realtime"

# 1. Model — 推論コンテナ(ECR)とモデルアーティファクト(S3)を紐付ける
sagemaker_client.create_model(
 ModelName=model_name,
 ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerInferenceExecutionRole",
 PrimaryContainer={
  "Image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/fraud-detection-xgb:latest",
  "ModelDataUrl": "s3://ml-artifacts/fraud-detection/model.tar.gz",
 },
)

# 2. EndpointConfig — インスタンスタイプ・初期インスタンス数・バリアント重みを定義
sagemaker_client.create_endpoint_config(
 EndpointConfigName=endpoint_config_name,
 ProductionVariants=[
  {
"VariantName": "AllTraffic",
"ModelName": model_name,
"InstanceType": "ml.m5.xlarge",
"InitialInstanceCount": 2,
"InitialVariantWeight": 1.0,
  }
 ],
)

# 3. Endpoint — EndpointConfig を元にホスティングリソースを起動
sagemaker_client.create_endpoint(
 EndpointName=endpoint_name,
 EndpointConfigName=endpoint_config_name,
)

3-2. Auto Scaling — ターゲット追跡とスケジュールスケーリング

リアルタイムエンドポイントのインスタンス数は、Application Auto Scaling(sagemaker:variant:DesiredInstanceCount)を通じて制御します。まずプロダクションバリアントをスケーラブルターゲットとして登録し、その上にターゲット追跡ポリシーとスケジュールアクションを重ねる、という2段構成が基本パターンです。

aas_client = boto3.client("application-autoscaling", region_name="ap-northeast-1")

resource_id = f"endpoint/{endpoint_name}/variant/AllTraffic"

# スケーラブルターゲットとして登録(最小1〜最大8インスタンス)
aas_client.register_scalable_target(
 ServiceNamespace="sagemaker",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:variant:DesiredInstanceCount",
 MinCapacity=1,
 MaxCapacity=8,
)

# ターゲット追跡ポリシー — インスタンス1台あたりの呼び出し数を基準にスケール
aas_client.put_scaling_policy(
 PolicyName="fraud-detection-invocations-target-tracking",
 ServiceNamespace="sagemaker",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:variant:DesiredInstanceCount",
 PolicyType="TargetTrackingScaling",
 TargetTrackingScalingPolicyConfiguration={
  "TargetValue": 70.0,
  "PredefinedMetricSpecification": {
"PredefinedMetricType": "SageMakerVariantInvocationsPerInstance",
  },
  "ScaleInCooldown": 300,
  "ScaleOutCooldown": 60,
 },
)

# スケジュールスケーリング — 平日朝(JST 9時)に最小容量を引き上げてコールドスタート的な遅延を回避
aas_client.put_scheduled_action(
 ServiceNamespace="sagemaker",
 ScheduledActionName="scale-up-weekday-morning-jst",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:variant:DesiredInstanceCount",
 Schedule="cron(0 0 ? * MON-FRI *)",  # UTC 00:00 = JST 09:00
 ScalableTargetAction={"MinCapacity": 4, "MaxCapacity": 8},
)

通常のプロダクションバリアントは MinCapacity を1未満にできず、トラフィックが完全に止まってもインスタンスは起動し続けます。ゼロスケールを実現するには §5 で扱う Inference Components 化(sagemaker:inference-component:DesiredCopyCount)が必要です。

3-3. プロダクションバリアントによる A/B テストとトラフィックシフト

複数のプロダクションバリアントを1つのエンドポイントに共存させ、InitialVariantWeight の比率でトラフィックを振り分けることで A/B テストを実施できます。評価が進んだ後は、エンドポイントを再デプロイせずに UpdateEndpointWeightsAndCapacities で重みだけを変更し、トラフィック配分を段階的にシフトできます。

# 挑戦者モデルを10%のトラフィックで追加
sagemaker_client.create_endpoint_config(
 EndpointConfigName="fraud-detection-xgb-realtime-config-v4-ab",
 ProductionVariants=[
  {
"VariantName": "AllTraffic",
"ModelName": model_name,
"InstanceType": "ml.m5.xlarge",
"InitialInstanceCount": 2,
"InitialVariantWeight": 0.9,
  },
  {
"VariantName": "Challenger",
"ModelName": "fraud-detection-xgb-2026-07-challenger",
"InstanceType": "ml.m5.xlarge",
"InitialInstanceCount": 1,
"InitialVariantWeight": 0.1,
  },
 ],
)
sagemaker_client.update_endpoint(
 EndpointName=endpoint_name,
 EndpointConfigName="fraud-detection-xgb-realtime-config-v4-ab",
)

# 評価後、重みだけを変更してトラフィック配分をシフト(再デプロイ不要)
sagemaker_client.update_endpoint_weights_and_capacities(
 EndpointName=endpoint_name,
 DesiredWeightsAndCapacities=[
  {"VariantName": "AllTraffic", "DesiredWeight": 0.5},
  {"VariantName": "Challenger", "DesiredWeight": 0.5},
 ],
)

3-4. Blue-Green・Canary・Shadow デプロイの実装

モデル更新時の安全性を高めるには、UpdateEndpoint の DeploymentConfig で デプロイガードレール を使います。旧フリート(Blue)から新フリート(Green)へのトラフィックシフト方式には、全量を一度に切り替える ALL_AT_ONCE、少量のカナリアで検証してから全量切替する CANARY、n段階で線形に切り替える LINEAR の3種類があり、AutoRollbackConfiguration に CloudWatch アラームを紐付けることで、異常検知時に自動ロールバックできます。

# Canary トラフィックシフト — 5%のトラフィックを15分間 Green フリートへ流し、
# 異常がなければ残りを一括切替。5xxアラームが発火すれば自動ロールバック
sagemaker_client.update_endpoint(
 EndpointName=endpoint_name,
 EndpointConfigName="fraud-detection-xgb-realtime-config-v5",
 DeploymentConfig={
  "BlueGreenUpdatePolicy": {
"TrafficRoutingConfiguration": {
 "Type": "CANARY",
 "CanarySize": {"Type": "CAPACITY_PERCENT", "Value": 5},
 "WaitIntervalInSeconds": 900,
},
"TerminationWaitInSeconds": 300,
"MaximumExecutionTimeoutInSeconds": 3600,
  },
  "AutoRollbackConfiguration": {
"Alarms": [{"AlarmName": "fraud-detection-endpoint-5xx-high"}],
  },
 },
)

本番トラフィックを一切晒さずに新モデルを検証したい場合は、CreateInferenceExperiment API による Shadow テスト(Type="ShadowMode")を使います。本番トラフィックを担う SourceModelVariantName はそのままに、ShadowModelVariants へ指定した割合(SamplingPercentage)だけリクエストを複製し、ユーザーに応答を返さないシャドウバリアントで推論結果とレイテンシを比較できます。

sagemaker_client.create_inference_experiment(
 Name="fraud-detection-challenger-shadow-test",
 Type="ShadowMode",
 RoleArn="arn:aws:iam::123456789012:role/SageMakerInferenceExperimentRole",
 EndpointName=endpoint_name,
 ModelVariants=[
  {
"ModelName": model_name,
"VariantName": "AllTraffic",
"InfrastructureConfig": {
 "InfrastructureType": "RealTimeInference",
 "RealTimeInferenceConfig": {"InstanceType": "ml.m5.xlarge", "InstanceCount": 2},
},
  },
  {
"ModelName": "fraud-detection-xgb-2026-07-challenger",
"VariantName": "Challenger",
"InfrastructureConfig": {
 "InfrastructureType": "RealTimeInference",
 "RealTimeInferenceConfig": {"InstanceType": "ml.m5.xlarge", "InstanceCount": 1},
},
  },
 ],
 ShadowModeConfig={
  "SourceModelVariantName": "AllTraffic",
  "ShadowModelVariants": [
{"ShadowModelVariantName": "Challenger", "SamplingPercentage": 10}
  ],
 },
)

Schedule を省略した場合、実験は作成直後に開始し7日間で自動終了します。継続検証したい場合は Schedule に StartTime / EndTime を明示してください。

3-5. CloudWatch メトリクスによる本番監視

AWS/SageMaker 名前空間には、リアルタイムエンドポイントの呼び出しごとに次のメトリクスが記録されます。

ディメンションは EndpointName と VariantName の組み合わせで、バリアント単位に切り分けて監視できます。5xx エラー率の急増を検知するアラームは、そのまま §3-4 の AutoRollbackConfiguration に紐付けて自動ロールバックのトリガーとして使えます。

cloudwatch = boto3.client("cloudwatch", region_name="ap-northeast-1")

cloudwatch.put_metric_alarm(
 AlarmName="fraud-detection-endpoint-5xx-high",
 Namespace="AWS/SageMaker",
 MetricName="Invocation5XXErrors",
 Dimensions=[
  {"Name": "EndpointName", "Value": endpoint_name},
  {"Name": "VariantName", "Value": "AllTraffic"},
 ],
 Statistic="Sum",
 Period=60,
 EvaluationPeriods=3,
 Threshold=5,
 ComparisonOperator="GreaterThanOrEqualToThreshold",
 TreatMissingData="notBreaching",
)

4. Serverless Inference / Asynchronous Inference

4-1. Serverless Inference の本番実装

Serverless Inference はインスタンス管理そのものを不要にし、リクエストがない間は課金が発生しません。一方でコンピュートリソースをオンデマンドに起動するため、トラフィックが再開した瞬間に コールドスタート が発生し得ます。メモリサイズは 1024 MB(1 GB)から 6144 MB(6 GB)まで 1024 MB 刻みの6段階から選択し、SageMaker AI がメモリサイズに比例した vCPU を自動割当します。

GPU、VPC 設定、Multi-Model Endpoint、データキャプチャ、複数プロダクションバリアント、Model Monitor、推論パイプラインはサポート対象外のため、これらが必要な場合はリアルタイムエンドポイントを選択します。

sagemaker_client.create_model(
 ModelName="recommendation-experimental-model",
 ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerInferenceExecutionRole",
 PrimaryContainer={
  "Image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/recommendation:latest",
  "ModelDataUrl": "s3://ml-artifacts/recommendation/model.tar.gz",
 },
)

sagemaker_client.create_endpoint_config(
 EndpointConfigName="recommendation-serverless-config",
 ProductionVariants=[
  {
"VariantName": "AllTraffic",
"ModelName": "recommendation-experimental-model",
"ServerlessConfig": {
 "MemorySizeInMB": 3072,
 "MaxConcurrency": 20,
 "ProvisionedConcurrency": 5,  # 予測可能なバーストに備えてウォーム状態を確保
},
  }
 ],
)

sagemaker_client.create_endpoint(
 EndpointName="recommendation-serverless",
 EndpointConfigName="recommendation-serverless-config",
)

コールドスタートの監視には ModelSetupTime(コンピュートリソースの起動に要した時間)を使います。Provisioned Concurrency を設定した場合は、指定した並行数分だけ常時ウォームな状態が保たれ、ミリ秒単位で応答できます。Provisioned Concurrency 自体も Auto Scaling の対象にでき、SageMakerVariantProvisionedConcurrencyUtilization を使ったターゲット追跡で予測可能なトラフィック増減に追従させられます。

resource_id = "endpoint/recommendation-serverless/variant/AllTraffic"

aas_client.register_scalable_target(
 ServiceNamespace="sagemaker",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:variant:DesiredProvisionedConcurrency",
 MinCapacity=2,
 MaxCapacity=20,
)

aas_client.put_scaling_policy(
 PolicyName="recommendation-provisioned-concurrency-target-tracking",
 ServiceNamespace="sagemaker",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:variant:DesiredProvisionedConcurrency",
 PolicyType="TargetTrackingScaling",
 TargetTrackingScalingPolicyConfiguration={
  "TargetValue": 0.7,
  "PredefinedMetricSpecification": {
"PredefinedMetricType": "SageMakerVariantProvisionedConcurrencyUtilization",
  },
 },
)

ProvisionedConcurrency は MaxConcurrency 以下である必要があり、MinCapacity は1以上を指定します。

4-2. Asynchronous Inference の本番実装

Asynchronous Inference は、最大1GBのペイロード・最大1時間の処理時間を許容する内部キューベースの推論方式です。エンドポイント設定に AsyncInferenceConfig を追加するだけでよく、モデル・インスタンスタイプの指定方法はリアルタイムエンドポイントと同じです。

sagemaker_client.create_endpoint_config(
 EndpointConfigName="image-analysis-async-config",
 ProductionVariants=[
  {
"VariantName": "AllTraffic",
"ModelName": "image-analysis-model",
"InstanceType": "ml.g5.xlarge",
"InitialInstanceCount": 1,
  }
 ],
 AsyncInferenceConfig={
  "OutputConfig": {
"S3OutputPath": "s3://ml-artifacts/image-analysis/async-output/",
"NotificationConfig": {
 "SuccessTopic": "arn:aws:sns:ap-northeast-1:123456789012:image-analysis-success",
 "ErrorTopic": "arn:aws:sns:ap-northeast-1:123456789012:image-analysis-error",
},
  },
  "ClientConfig": {
# インスタンス1台あたりの同時処理数上限。未指定時は SageMaker AI が最適値を選択
"MaxConcurrentInvocationsPerInstance": 4
  },
 },
)

呼び出しには InvokeEndpointAsync を使用します。リクエストペイロードは、S3 に配置した URI(InputLocation)か128,000バイトまでのインライン Body のいずれか一方を指定します。両方の同時指定はできません。InvocationTimeoutSeconds の最大値は3600秒です(未指定時のデフォルト値: 15分)。

sagemaker_runtime = boto3.client("sagemaker-runtime", region_name="ap-northeast-1")

response = sagemaker_runtime.invoke_endpoint_async(
 EndpointName="image-analysis-async",
 InputLocation="s3://ml-artifacts/image-analysis/requests/batch-2026-07-13-001.json",
 InvocationTimeoutSeconds=3600,
)
# response には OutputLocation(結果の格納先S3 URI)を含むリクエストIDが返る

Asynchronous Inference の大きな特徴は、他の推論方式と異なり 通常のプロダクションバリアントのままインスタンス数をゼロまでスケールインできる 点です。スケールインには通常のターゲット追跡(カスタムメトリクス ApproximateBacklogSizePerInstance)を、ゼロからのスケールアウトには HasBacklogWithoutCapacity アラームをトリガーとするステップスケーリングポリシーを併用します。

resource_id = "endpoint/image-analysis-async/variant/AllTraffic"

# MinCapacity=0 を指定できるのは Asynchronous Inference のプロダクションバリアントのみ
aas_client.register_scalable_target(
 ServiceNamespace="sagemaker",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:variant:DesiredInstanceCount",
 MinCapacity=0,
 MaxCapacity=5,
)

aas_client.put_scaling_policy(
 PolicyName="image-analysis-backlog-target-tracking",
 ServiceNamespace="sagemaker",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:variant:DesiredInstanceCount",
 PolicyType="TargetTrackingScaling",
 TargetTrackingScalingPolicyConfiguration={
  "TargetValue": 5.0,
  "CustomizedMetricSpecification": {
"MetricName": "ApproximateBacklogSizePerInstance",
"Namespace": "AWS/SageMaker",
"Dimensions": [{"Name": "EndpointName", "Value": "image-analysis-async"}],
"Statistic": "Average",
  },
 },
)

ゼロインスタンスの状態でリクエストが到着すると、キューに滞留したまま HasBacklogWithoutCapacity メトリクスが上昇します。このメトリクスを CloudWatch アラームで監視し、ステップスケーリングポリシーでインスタンスを起動させることで、キュー詰まりを長時間放置せずに済みます。

4-3. コスト比較・監視設計と選定の実務判断

選定の実務判断としては、常時一定量のトラフィックが見込め、かつミリ秒単位のレイテンシ SLA がある場合はリアルタイムエンドポイントが適します。トラフィックが断続的・予測不能で、数百ミリ秒〜秒単位のコールドスタートを許容できるなら Serverless Inference がコストを大幅に圧縮できます。大容量ペイロードや処理に時間のかかる推論(画像・動画解析、バッチに近い非同期処理)で、結果を即座に受け取る必要がない場合は Asynchronous Inference が適しています。いずれの方式も、モデルやトラフィック特性の変化に応じて途中で乗り換えることが可能なため、まずは最も制約の緩い方式で運用を開始し、CloudWatch メトリクスの実測値を根拠に見直す運用が現実的です。

5. Multi-Model Endpoint / Inference Components

§2-1 の選定基準に沿って、本節では「多数のモデルをどう効率よく1つのインフラで束ねるか」という観点の3方式(Multi-Model Endpoint・Multi-container Endpoint・Inference Components)を扱います。いずれも Real-time エンドポイントを土台としつつ、モデルとインフラの結び付け方を変えることでリソース効率を高める仕組みです。

5-1. Multi-Model Endpoint — 同一フレームワーク多数モデルの動的ロード

Multi-Model Endpoint(MME)は、同一の推論コンテナを共有しながら多数のモデルを1つのエンドポイントでホストする方式です。エンドポイント作成時にすべてのモデルをコンテナへ読み込むのではなく、SageMaker AI が呼び出しのたびにモデルを S3 からインスタンスのストレージボリュームへダウンロードし、コンテナのメモリ(CPU または GPU)へ動的にロードします。すでにロード済みのモデルへの呼び出しはキャッシュヒットにより高速に応答し、メモリ逼迫時には未使用モデルがコンテナメモリから自動的にアンロードされます。

マルチテナント SaaS で「テナントごとに小さなモデルを大量に持つ」ようなケースに向いており、モデル数が多くアクセス頻度に偏りがある構成ほどコスト効率が高まります。逆に、個々のモデルのスループット・レイテンシ要件が厳しい場合は、専用エンドポイント(§3)の方が適します。

MME を作成するには、create_model の Containers に渡すコンテナ定義で Mode を MultiModel に設定し、ModelDataUrl に単一モデルのパスではなく S3 のプレフィックスを指定します。

container = {
 "Image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/xgboost-inference:latest",
 "ModelDataUrl": "s3://ml-artifacts/tenant-scoring/models/",  # プレフィックス配下の全モデルが対象
 "Mode": "MultiModel",
}

sagemaker_client.create_model(
 ModelName="tenant-scoring-mme",
 ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerInferenceExecutionRole",
 Containers=[container],
)

sagemaker_client.create_endpoint_config(
 EndpointConfigName="tenant-scoring-mme-config",
 ProductionVariants=[
  {
"VariantName": "AllTraffic",
"ModelName": "tenant-scoring-mme",
"InstanceType": "ml.m5.xlarge",
"InitialInstanceCount": 2,  # 可用性のため2台以上を推奨
  }
 ],
)

sagemaker_client.create_endpoint(
 EndpointName="tenant-scoring-mme",
 EndpointConfigName="tenant-scoring-mme-config",
)

呼び出し側は、invoke_endpoint の TargetModel にモデルアーティファクトのキー(S3 プレフィックス以下のパス)を指定します。

response = sagemaker_runtime.invoke_endpoint(
 EndpointName="tenant-scoring-mme",
 TargetModel="tenant-042.tar.gz",
 Body=payload,
 ContentType="application/json",
)

モデルの追加・削除はエンドポイントの更新を伴わず、S3 プレフィックス配下へのオブジェクトの配置・削除だけで完結します。キャッシュ挙動が業務上不要な場合(毎回最新のモデルを使い切りで呼び出すなど)は、コンテナ定義に MultiModelConfig={"ModelCacheSetting": "Disabled"} を追加してキャッシュを無効化できます。また GPU バックエンドの MME では、NVIDIA Triton Inference Server ベースのコンテナイメージが必要です。

5-2. Multi-container Endpoint — 異種コンテナと Serial Inference Pipeline

Multi-container Endpoint は、異なるフレームワーク・異なる役割を持つコンテナ(最大15個)を1つのエンドポイントに同居させる方式です。呼び出しパターンは2種類あります。①InferenceExecutionConfig の Mode を Serial にする推論パイプライン(前処理→推論→後処理のように、各コンテナの出力を次のコンテナへ順に渡す)。②Mode を Direct にする直接呼び出し(各コンテナを個別にエンドポイント利用率向上・コスト最適化の目的で呼び分ける)。デフォルトは Serial です。

Direct モードでは、create_model の各コンテナに ContainerHostname を指定する必要があります。

preprocess_container = {
 "Image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/image-preprocess:latest",
 "ContainerHostname": "preprocessContainer",
}
resnet_container = {
 "Image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/resnet-inference:latest",
 "ContainerHostname": "resnetContainer",
}

sagemaker_client.create_model(
 ModelName="image-pipeline-direct",
 ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerInferenceExecutionRole",
 InferenceExecutionConfig={"Mode": "Direct"},
 Containers=[preprocess_container, resnet_container],
)

呼び出し側は invoke_endpoint の TargetContainerHostname で呼び分けます。

response = sagemaker_runtime.invoke_endpoint(
 EndpointName="image-pipeline-direct",
 TargetContainerHostname="resnetContainer",
 Body=payload,
 ContentType="application/x-image",
)

Serial モード(推論パイプライン)にする場合は InferenceExecutionConfig={"Mode": "Serial"} に変更するだけで、Containers に渡した順番でコンテナ間をチェーンします。ただし、パイプライン中に含められる MME 対応コンテナは1つまでという制約があるため、MME と組み合わせる場合は構成に注意してください。

5-3. Inference Components — モデル単位のリソース割当とスケーリング

プロダクションバリアント単位(§3)や MME(§5-1)では、リソースの割当単位が「インスタンス」または「エンドポイント全体」に限られ、モデルごとに GPU・CPU・メモリを個別に割り当てることはできません。Inference Components(IC)は、この制約を解いてモデル単位でリソース要求量とレプリカ数(コピー数)を指定できるようにする仕組みです。1つのエンドポイントに複数の IC を配置し、各 IC が個別にスケールすることで、共有 GPU インスタンス上でのリソース利用率を最大化します。

IC は CreateInferenceComponent API で作成します。Specification.ComputeResourceRequirements にモデル単位で必要な CPU コア数・メモリ・アクセラレータ数を指定し、RuntimeConfig.CopyCount でレプリカ数を指定します。

sagemaker_client.create_inference_component(
 InferenceComponentName="llm-7b-ic",
 EndpointName=endpoint_name,
 VariantName="AllTraffic",
 Specification={
  "ModelName": "llm-7b-model",
  "ComputeResourceRequirements": {
"NumberOfAcceleratorDevicesRequired": 1,
"MinMemoryRequiredInMb": 8192,
  },
 },
 RuntimeConfig={"CopyCount": 2},
)

IC のスケーリングは、Application Auto Scaling のスケーラブルディメンション sagemaker:inference-component:DesiredCopyCount を使い、リソースID は inference-component/{InferenceComponentName} の形式で指定します。

resource_id = "inference-component/llm-7b-ic"

# MinCapacity=0 を指定すると、呼び出しがない間はコピー数ゼロまでスケールインできる
aas_client.register_scalable_target(
 ServiceNamespace="sagemaker",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:inference-component:DesiredCopyCount",
 MinCapacity=0,
 MaxCapacity=4,
)

aas_client.put_scaling_policy(
 PolicyName="llm-7b-ic-invocations-target-tracking",
 ServiceNamespace="sagemaker",
 ResourceId=resource_id,
 ScalableDimension="sagemaker:inference-component:DesiredCopyCount",
 PolicyType="TargetTrackingScaling",
 TargetTrackingScalingPolicyConfiguration={
  "TargetValue": 5.0,
  "PredefinedMetricSpecification": {
"PredefinedMetricType": "SageMakerInferenceComponentInvocationsPerCopy",
  },
 },
)

MinCapacity=0 を指定した IC は、呼び出しが完全に止まっている間コピー数ゼロまでスケールインでき、リクエスト到着時に自動でコピーが再起動します。複数の小〜中規模モデルを1つの GPU インスタンスプールに混載し、需要に応じてモデルごとに個別スケールさせたい構成(たとえば LLM のマルチテナント推論基盤)に向いています。

5-4. コスト最適化 — Inferentia/Graviton 併用とリソース設計

方式ごとのコスト最適化は、インスタンスタイプの選定と組み合わせで大きく変わります。Transformer 系の推論で計算量が大きいモデルは、AWS Inferentia2 を搭載した inf2 インスタンスに、AWS Neuron SDK でコンパイルしたモデルをデプロイすることで、GPU インスタンスに対してコスト効率を改善できるケースがあります。一方、前処理・後処理コンテナや軽量な古典的 ML モデル(勾配ブースティング木など)は、AWS Graviton(Arm64)ベースの c7g / m7g 系インスタンスにオフロードすることで、同等のコンピュート性能をより低コストで確保できます。

CreateInferenceComponent は Specification を配列で指定できる Specifications(最大5件)にも対応しており、1つの IC 定義に対してインスタンスタイプごとに異なるモデル・リソース構成を割り当てられます。これを、複数インスタンスタイプを1つのエンドポイントで運用する「ヘテロジニアスエンドポイント(instance pools)」機能と組み合わせることで、Inferentia2・Graviton・GPU インスタンスを同一エンドポイント内で使い分け、ワークロード特性に応じてコストと性能のバランスを取る設計が可能です。Inferentia2 や Graviton 系インスタンスの対応リージョン・対応フレームワークは更新が続くため、採用前に公式ドキュメントの最新のサポート状況を確認してください。

6. SageMaker HyperPod 推論 — 大規模 GPU 基盤

ここまでの §3〜§5 は、いずれも SageMaker AI が管理する「エンドポイント」という単位を土台にした推論方式でした。本節で扱う SageMaker HyperPod 推論は前提が異なり、大規模 LLM の学習・ファインチューニング用に構築された GPU/Trainium クラスター基盤を、そのまま推論ワークロードにも転用する仕組みです。数十億パラメータ級のモデルをマルチノードで分散サービングしたい場合や、学習に使っていた GPU フリートを推論にも再利用してリソース効率を高めたい場合に検討する、発展的なトピックとして位置づけてください。§3〜§5 の汎用エンドポイントを主に使う読者層とは想定シナリオが異なる点に留意が必要です。

6-1. HyperPod がトレーニングから推論へ拡張した背景

SageMaker HyperPod は、もともと大規模分散学習をノード障害に強い形で継続させるための基盤として提供されてきました。Amazon EKS でオーケストレーションされた HyperPod クラスターに Inference Operator(Kubernetes カスタムコントローラ)を EKS Add-on として導入することで、同じクラスター上でモデルのデプロイ・ライフサイクル管理・オートスケーリングを担えるようになり、学習と推論を同一の GPU 基盤上で運用できるようになりました。

6-2. Inference Operator(EKS Add-on)とデプロイ方法

Inference Operator の導入方法は2通りあります。①SageMaker コンソールからの one-click インストール(IAM ロール・S3 バケット・依存 Add-on を自動作成する Quick Install と、既存リソースを指定できる Custom Install)。②AWS CLI からの手動インストール(IAM ロール・S3 バケット・VPC エンドポイントなど前提リソースを個別に作成)。導入後は次のコマンドで状態を確認できます。

# EKS Add-on としてのインストール状態を確認
aws eks describe-addon \
  --cluster-name my-hyperpod-cluster \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --region ap-northeast-1

# Inference Operator が管理する Pod の稼働確認
kubectl get pods -n hyperpod-inference-system

モデルのデプロイ自体は、①kubectl による CRD 適用、②Python SDK、③SageMaker Studio UI、④HyperPod CLI、の4通りのインターフェースから選べます。JumpStart 提供モデルは JumpStartModel CRD、S3 / Amazon FSx に置いた自前モデル・ファインチューニング済みモデルは InferenceEndpointConfig CRD を使います。

# kubectl: JumpStart モデルのデプロイ例
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
  name: mistral-model
  namespace: ns-team-a
spec:
  model:
 modelId: "huggingface-llm-mistral-7b-instruct"
 modelVersion: "3.19.0"
  replicas: 2
  sageMakerEndpoint:
 name: "mistral-model-sm-endpoint"
  server:
 instanceType: "ml.g5.12xlarge"
 executionRole: "arn:aws:iam::123456789012:role/SagemakerRole"

HyperPod CLI(hyp コマンド)を使う場合、JumpStart モデルと自前モデルでサブコマンドが分かれています。

# JumpStart モデルのデプロイ
hyp create hyp-jumpstart-endpoint \
  --model-id deepseek-llm-r1-distill-qwen-1-5b \
  --instance-type ml.g5.8xlarge \
  --endpoint-name deepseek-distill-qwen-endpoint-cli \
  --tls-certificate-output-s3-uri s3://hyperpod-certs/ \
  --namespace default

# デプロイ状況の確認・削除
hyp describe hyp-jumpstart-endpoint --name deepseek-distill-qwen-endpoint-cli
hyp delete hyp-jumpstart-endpoint --name deepseek-distill-qwen-endpoint-cli

6-3. 動的オートスケーリングと可観測性

Inference Operator によるオートスケーリングは Kubernetes ベースの仕組み(KEDA 等)で実装されており、同時リクエスト数などのカスタムメトリクスに応じて Pod 数を増減させます。トラフィック急増時のスケールアウト遅延はレイテンシ悪化に直結するため、ポーリング間隔やスケーリング閾値のチューニングが運用上のポイントになります。

可観測性については、HyperPod Observability により Prometheus・Grafana ベースのダッシュボードがデフォルトで有効化され、次のような推論メトリクスが自動収集されます(Prometheus エンドポイントは既定でポート 9113・パス /metrics)。

これに加えて、TGI / LMI などのモデルサービングコンテナ側が公開するキュー深度・トークン処理数といったコンテナ内部メトリクス、および GPU 利用率を含むノード/インフラレベルのメトリクスを、HyperPod クラスター全体の Observability ダッシュボード(Grafana)で横断的に確認できます。カスタムの監視基盤と統合したい場合は、Prometheus 互換エンドポイントから自前でスクレイピングする構成も選べます。

6-4. 適用判断と鮮度の注意

HyperPod 推論は、§3〜§5 の汎用エンドポイントでは賄いきれない大規模モデル・マルチノード推論という限られたシナリオ向けの選択肢です。まずは §3〜§5 の方式で要件を満たせないかを検討し、GPU クラスターの規模や運用体制(Kubernetes の運用知見を含む)が見合う場合にのみ採用を検討してください。

また、Inference Operator は §2-3 で述べたとおりバージョン更新が頻繁な発展途上の機能であり、マイナーバージョン単位でのリージョン別提供状況は公式ドキュメントに明記されていません。本節の内容も§2-3 と同じ方針に従い、採用前に必ず aws eks describe-addon-versions や公式ドキュメントの最新版で対象リージョンでの提供状況を確認してください。

7. 監視・コスト最適化・セキュリティの本番運用

ここまで §3〜§6 で方式ごとに解説してきた監視・スケーリング・セキュリティの要素を、本節では本番運用の観点で横断的に整理します。試験対策シリーズが扱う「監視指標の分類」「コストモデルの基礎」といった概念レベルの解説は再度行わず、複数方式を併用する本番環境で実際に何を設定し、何を見張るかという実装・運用の視点に絞ります。

7-1. 方式横断の CloudWatch 監視設計

各推論方式の主要メトリクスを1つの表に整理すると、監視すべき対象がどこにあるかが明確になります。

本番運用では、これらを個別のアラームとして設定するだけでなく、put_dashboard で1画面に集約し、複数エンドポイントを横断して異常の全体像を把握できるようにします。

import json

cloudwatch.put_dashboard(
 DashboardName="sagemaker-inference-production-overview",
 DashboardBody=json.dumps({
  "widgets": [
{
 "type": "metric",
 "properties": {
  "metrics": [
["AWS/SageMaker", "ModelLatency", "EndpointName", endpoint_name, "VariantName", "AllTraffic"],
["AWS/SageMaker", "Invocation5XXErrors", "EndpointName", endpoint_name, "VariantName", "AllTraffic"],
["AWS/SageMaker", "ApproximateBacklogSizePerInstance", "EndpointName", "image-analysis-async"],
  ],
  "period": 60,
  "stat": "Average",
  "region": "ap-northeast-1",
  "title": "推論方式横断ダッシュボード",
 },
}
  ]
 }),
)

7-2. Auto Scaling チューニングの実務ポイント

方式ごとにスケーリングの挙動と落とし穴が異なるため、§3〜§5 で登場したスケーラブルディメンションを一覧化し、チューニング時に見るべき項目を整理します。

スケールアウトを速く・スケールインを遅くする非対称なクールダウン設計は、コスト最適化(過剰なインスタンス保持)と可用性(スケールインし過ぎて次のバーストで遅延が出る)のトレードオフを調整する基本パターンです。まずは保守的な設定で運用を開始し、CloudWatch の実測値を基に段階的に閾値を追い込むのが実務上の定石です。

7-3. 推論コスト最適化 — SageMaker AI Savings Plans と右サイジング

SageMaker のコスト最適化は、①コミットメント型の割引プログラムを使う、②インスタンスサイズを実測値に基づき適正化する、という2つのアプローチを組み合わせます。

SageMaker AI Savings Plans は、1年または3年のコミットメントに対して時間単価($/時間)を約束することで、オンデマンド料金に対して最大64%の割引を受けられるプログラムです。インスタンスファミリー・インスタンスサイズ・リージョン・コンポーネント(Studio ノートブック・トレーニング・推論エンドポイントなど)を問わず、コミットした金額の範囲内で自動的に割引が適用されます。ここで注意すべきは、EC2 Instance Savings Plans や Compute Savings Plans は SageMaker の利用には適用されないという点です。SageMaker のコンピュートコストを削減したい場合は、SageMaker AI Savings Plans を個別に購入する必要があります。

トラフィックが安定した Real-time エンドポイントのように、常時起動が前提でインスタンス数の下限が読める構成は Savings Plans によるコミットメント割引の効果が大きく出ます。逆に Serverless / Asynchronous のようにアイドル時課金が発生しない方式では、コミットメントの対象自体が小さくなるため、Savings Plans の優先度は相対的に下がります。

右サイジングには SageMaker Inference Recommender を使います。負荷テストを自動化し、レイテンシ・スループット要件を満たす最小コストのインスタンスタイプ・インスタンス数を提案します。既存の稼働中エンドポイントに対しても、過剰プロビジョニングを検出する用途で実行できます。

sagemaker_client.create_inference_recommendations_job(
 JobName="fraud-detection-rightsizing-2026-07",
 JobType="Default",
 RoleArn="arn:aws:iam::123456789012:role/SageMakerInferenceExecutionRole",
 InputConfig={
  "ModelPackageVersionArn": "arn:aws:sagemaker:ap-northeast-1:123456789012:model-package/fraud-detection/3",
  "Endpoints": [{"EndpointName": endpoint_name}],
 },
)

方式別の単価特性(常時起動課金 / 従量課金 / 起動時間課金)は §4-3 の比較表に整理済みのため、ここでは再掲しません。コスト最適化の実務は、まず Savings Plans でベースラインのコミット割引を確保し、その上で Inference Recommender の提案値をもとに定期的に右サイジングを実施する、という2段構えで進めるのが現実的です。

7-4. IAM 最小権限設計 — PassRole を含む実装設計の再確認

§2-2 で解説した iam:PassRole の設計原則(Resource を実行ロール ARN に限定し、iam:PassedToService で渡し先を sagemaker.amazonaws.com に限定する)は、本番運用フェーズでも継続して適用すべき最重要ポイントです。本節ではこれを、エンドポイントの作成・更新・削除を担うデプロイ元ロールの実装設計として、命名規則による制限を加えた形で再確認します。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "AllowManageInferenceEndpointsByNamingConvention",
"Effect": "Allow",
"Action": [
  "sagemaker:CreateModel",
  "sagemaker:CreateEndpointConfig",
  "sagemaker:CreateEndpoint",
  "sagemaker:UpdateEndpoint",
  "sagemaker:UpdateEndpointWeightsAndCapacities",
  "sagemaker:DeleteEndpoint"
],
"Resource": "arn:aws:sagemaker:ap-northeast-1:123456789012:endpoint/prod-*"
 },
 {
"Sid": "AllowPassSageMakerExecutionRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/SageMakerInferenceExecutionRole",
"Condition": {
  "StringEquals": { "iam:PassedToService": "sagemaker.amazonaws.com" }
}
 }
  ]
}

Resource をエンドポイント名の命名規則(prod-* など)で絞ることで、デプロイ元ロールが検証環境・実験用エンドポイントにまで操作範囲を広げてしまう事故を防ぎます。iam:PassRole の条件キーを外した状態でこのポリシーを配布すると、エンドポイント作成権限を持つ任意の CI/CD パイプラインが、本来意図しない高権限ロールを SageMaker 経由で引き受けさせられる余地を残すため、本番配布前のレビュー観点として必ず確認してください。

7-5. VPC エンドポイント・KMS 暗号化の本番構成

§2-2 で述べたプライベートサブネット構成を、Terraform で恒常的に維持する構成例です。S3 は Gateway 型、ECR / CloudWatch Logs は Interface 型のエンドポイントとして構築します。

terraform {
  required_version = "~> 1.9.0"
  required_providers {
 aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

resource "aws_vpc_endpoint" "s3_gateway" {
  vpc_id= aws_vpc.ml_inference.id
  service_name= "com.amazonaws.ap-northeast-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids= [aws_route_table.private.id]
}

resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id  = aws_vpc.ml_inference.id
  service_name= "com.amazonaws.ap-northeast-1.ecr.api"
  vpc_endpoint_type = "Interface"
  subnet_ids  = aws_subnet.private[*].id
  security_group_ids= [aws_security_group.sagemaker_endpoint.id]
  private_dns_enabled  = true
}

resource "aws_vpc_endpoint" "cloudwatch_logs" {
  vpc_id  = aws_vpc.ml_inference.id
  service_name= "com.amazonaws.ap-northeast-1.logs"
  vpc_endpoint_type = "Interface"
  subnet_ids  = aws_subnet.private[*].id
  security_group_ids= [aws_security_group.sagemaker_endpoint.id]
  private_dns_enabled  = true
}

KMS 側は、モデルアーティファクトの保存時暗号化と推論インスタンスのボリューム暗号化それぞれにカスタマー管理キーを使い、キーポリシーで SageMaker サービスプリンシパルからの kms:Decrypt のみを許可します。

{
  "Sid": "AllowSageMakerDecryptForInference",
  "Effect": "Allow",
  "Principal": { "Service": "sagemaker.amazonaws.com" },
  "Action": ["kms:Decrypt", "kms:CreateGrant"],
  "Resource": "*",
  "Condition": {
 "StringEquals": { "kms:ViaService": "sagemaker.ap-northeast-1.amazonaws.com" }
  }
}

create_endpoint_config の ProductionVariants で KmsKeyId を指定すると、推論インスタンスにアタッチされるボリュームがこのキーで暗号化されます。モデルアーティファクト側の暗号化キーと推論ボリューム側の暗号化キーは、運用上分離してもよく、統一してもかまいません。分離する場合は、両方のキーポリシーへ同じ条件(kms:ViaService で SageMaker サービスに限定)を適用してください。

7-6. モデルのデータキャプチャ・モニタリング

§3-4 で扱った Shadow テストは「今この瞬間」の2モデル比較を目的とした同期的な仕組みですが、本節で扱う Data Capture と Model Monitor は、本番トラフィックの入出力を継続的に記録し、時間経過に伴うデータドリフト・品質劣化を定期実行のジョブで検知する仕組みです。両者は目的が異なるため、本番運用では併用が基本になります。

sagemaker_client.create_endpoint_config(
 EndpointConfigName="fraud-detection-xgb-realtime-config-v6",
 ProductionVariants=[
  {
"VariantName": "AllTraffic",
"ModelName": model_name,
"InstanceType": "ml.m5.xlarge",
"InitialInstanceCount": 2,
  }
 ],
 DataCaptureConfig={
  "EnableCapture": True,
  "InitialSamplingPercentage": 100,
  "DestinationS3Uri": "s3://ml-artifacts/fraud-detection/data-capture/",
  "CaptureOptions": [
{"CaptureMode": "Input"},
{"CaptureMode": "Output"},
  ],
 },
)

キャプチャしたデータは、Model Monitor のモニタリングスケジュールが定期的に分析し、学習時のベースライン統計との乖離(データドリフト)を検出します。検出結果は CloudWatch メトリクスとして出力できるため、§7-1 のダッシュボードにドリフト検知結果を組み込むことで、推論品質の劣化を運用監視の一部として扱えます。

7-7. 各方式横断の運用チェックリスト

本番投入前に、方式によらず共通して確認すべき項目を整理します。

• [ ] 5xx エラー率・レイテンシのアラームが設定され、§3-4 の AutoRollbackConfiguration または運用手順に紐付いている
• [ ] Auto Scaling の MinCapacity がコスト影響を許容できる値になっている(Real-time は特に注意)
• [ ] iam:PassRole の Resource と iam:PassedToService 条件が本番用ロールに限定されている
• [ ] S3 / ECR / CloudWatch Logs へのアクセスが VPC エンドポイント経由に限定されている
• [ ] モデルアーティファクト・推論ボリュームの双方が KMS で暗号化されている
• [ ] Data Capture が有効化され、Model Monitor のベースライン・スケジュールが設定されている
• [ ] Savings Plans のコミット状況と Inference Recommender の右サイジング提案を四半期ごとに見直す運用が決まっている

8. 詰まりポイント・アンチパターン・まとめ

8-1. 詰まりポイント — 実践的な失敗例

• リアルタイムエンドポイント常時起動でのコスト膨張: トラフィックの少ない深夜帯や検証用エンドポイントを Real-time のまま放置すると、インスタンスは起動し続け、コストが積み上がります。§4 で解説した Serverless・Asynchronous への切り替え、または Auto Scaling の MinCapacity 見直しで対処します。
• Asynchronous Inference と Batch Transform の取り違え: 「非同期だから大量データの一括処理に向いている」と誤解し、本来 Batch Transform で処理すべき大規模なオフラインジョブを Asynchronous Inference のキューに投入してしまうケースがあります。Asynchronous Inference は個別リクエスト単位の非同期処理(最大1時間・1GB)であり、大量データの一括変換には向きません。§2-1 の選定基準表に立ち返り、処理単位の性質で使い分けてください。
• Serverless のコールドスタート未考慮: メモリサイズ選定時にレイテンシ SLA を確認せず、本番導入後に間欠的な遅延で問い合わせを受けるケースがあります。§4-1 の Provisioned Concurrency を事前に検討するか、レイテンシ要件が厳しい場合は Real-time エンドポイントを選択します。
• MME のモデルロード遅延: モデル数が多く、かつアクセス頻度の偏りが大きい構成で、キャッシュミス時のモデルロード待ち(ModelLoadingWaitTime)がユーザー体感レイテンシに直結する事故があります。アクセス頻度の高いモデルは専用エンドポイント(§3)に切り出し、MME は本当にロングテールなモデル群に限定するのが実務上の対処です。
• Inference Components のリソース見積もり不足: ComputeResourceRequirements の見積もりを甘くしたまま複数 IC を1インスタンスに詰め込みすぎると、リソース競合が発生します。IC 導入時は Inference Recommender や負荷テストで実測したリソース使用量をもとに見積もることが重要です。

8-2. アンチパターン → 正解変換

8-3. 本番運用 Go-Live チェックリスト

Vol4 全体を通じて解説した内容を、本番投入直前の最終確認として整理します。

• [ ] 推論方式の選定根拠(§2-1)がトラフィック特性・レイテンシ要件・コスト制約に照らして文書化されている
• [ ] Auto Scaling ポリシーとスケジュールスケーリング(§3-2)が設定され、負荷テストで動作確認済みです
• [ ] モデル更新時のデプロイ手順(Blue-Green・Canary・Shadow テスト、§3-4)が定義され、自動ロールバック条件が設定されている
• [ ] CloudWatch ダッシュボード(§7-1)とアラームが本番エンドポイント全体をカバーしている
• [ ] IAM(§2-2・§7-4)・VPC エンドポイント・KMS(§7-5)の設計がセキュリティレビューを通過している
• [ ] Data Capture・Model Monitor(§7-6)が有効化され、ドリフト検知のアラート先が設定されている
• [ ] コスト最適化の見直しサイクル(§7-3)が運用カレンダーに組み込まれている

8-4. まとめと次巻予告

本 Vol4 では、Vol3 までで構築した学習パイプラインの出力を受け取り、Real-time・Serverless・Asynchronous・Multi-Model Endpoint・Inference Components・HyperPod 推論という複数の推論方式を、選定基準から実装(boto3・Terraform)、Auto Scaling、デプロイ戦略、監視、コスト最適化、セキュリティ設計まで一気通貫で解説しました。推論方式の概念的な違いは試験対策シリーズ(MLA-C01 Vol3・AIF-C01 Vol1)に委譲し、本記事は一貫して「本番でどう動かすか」という実装・運用の実務深度に焦点を当てています。

AWS ML/AI 本番運用シリーズは、Vol2 の Bedrock・RAG・Knowledge Bases・Agents、Vol3 の SageMaker MLOps・Pipelines・Feature Store、そして本 Vol4 の推論・デプロイ層まで到達し、学習から本番提供までの主要な工程を一通りカバーしました。次巻では、これらの推論エンドポイントを含む ML/AI ワークロード全体の運用監視・インシデント対応・ガバナンスといった、シリーズ全体を横断する運用トピックを扱う予定です。

関連：ML/AI Vol2 (Bedrock・RAG・Knowledge Bases・Agents) を読む
関連：ML/AI Vol3 (学習・パイプライン) を読む