Amazon BedrockのPriority / Standard / Flexの推論サービス階層で推論コストと性能を最適化

はじめに

こんにちは、久保(賢)です。

2025年11月18日に、Amazon BedrockにPriorityとFlexという2つの新しい推論サービス階層（Service Tier）が追加されました。
2025年11月26日には、Reservedという予約型のサービス階層も発表されています。
そのため既存のStandard（従来のオンデマンド推論）と合わせて、合計4つのTierからワークロードに応じて選べるようになっています。

docs.aws.amazon.com

Reserved Tier は1ヶ月or3ヶ月の期間であらかじめ利用するトークン数を約束する形態で、利用するには別途AWSアカウントチームへの連絡が必要な階層となっております。本記事では扱いません。

なお、2025年11月28日時点において、推論サービス階層(inference service tiers)に対応しているモデルは限られています。詳細は「対応モデルとリージョン」のセクションをご参照ください。
Anthropic Claude は、執筆時点ではサービス階層に対応していませんのでご注意ください。

本記事では、この新しいサービス階層について以下を整理します。

各Tier（Priority / Standard / Flex）の特徴とユースケース、料金
各Tierの簡易的なレイテンシ測定結果
APIからTierを指定する方法（CLI / Python / OpenAI互換API）
モデル・リージョンの対応状況
既存ワークロードをどう切り分けていくかの考え方

はじめに
Amazon Bedrockのサービス階層とは？
何がうれしいのか？
料金
- 東京リージョンの Amazon Nova Pro を例にした Tier ごとの単価差
  - オンデマンド推論（1,000 トークンあたり）
  - バッチ推論と Flex の関係
Tierごとの特徴とユースケース
簡易な選定フレームワーク
実測：各階層のレイテンシー比較
APIからサービス階層を指定する
対応モデルとリージョン
おわりに

Amazon Bedrockのサービス階層とは？

公式ドキュメントでは、Amazon Bedrockの推論サービス階層は次の3つと説明されています。

Priority
- もっとも速いレスポンスを提供するTier
- Standardより高い料金
- ミッションクリティカルなアプリケーション向け
Standard
- これまでのオンデマンド推論に相当
- 日常的なAIアプリケーション向けの安定した性能
Flex
- レイテンシ許容度の高いワークロード向けの割引料金
- モデル評価やコンテンツ要約、エージェントワークフローなどに向く

サービス階層を使うために追加のセットアップは不要で、Bedrock Runtime APIを呼ぶ際にオプションのパラメータとしてTierを指定するだけです。指定しなければ従来どおりStandard（default）が使われます。

何がうれしいのか？

速さが命の部分
→ Priority でレイテンシを削る
ふつうの業務処理
→ これまでどおり Standard
完全にバッチ処理にできる部分（夜間にまとめて流すなど）
→ Standard のバッチ推論を使う（Standard オンデマンドのちょうど半額）
オンデマンド推論のままにしたいが、レイテンシに余裕がある評価ジョブやワークフロー
→ Flex でコストを抑える

というように、ワークロードごとに「速さ」と「コスト」を切り分けられるようになりました。特に処理時間に余裕があるワークロードについては、

バッチ API に乗せられるものは Standard バッチ推論
オンデマンドで個別に呼びたいものは Flex

と使い分けることで、コスト削減が期待できるのがポイントかと思います。

フローチャート風にすると以下のようになります。

料金

最初に気になる料金を整理します。
執筆時点では Flex の料金は Standard Tier 比でおおよそ半額（約 50% オフ）(※) となるため、
レイテンシに余裕のあるオンデマンド処理や、バッチ API に載せきれないワークロードでコスト削減が期待できそうです。

東京リージョンやバージニア北部リージョンにおけるNova Premier/Proやgpt-oss-20b/120b、Qwenなどで確認した範囲ではいずれも標準より50%廉価となっていましたがすべてのモデル/リージョンで網羅的に比較したわけではないため、正確な値は公式の料金表をご確認ください。

東京リージョンの Amazon Nova Pro を例にした Tier ごとの単価差

具体的にイメージできるよう、東京リージョン（ap-northeast-1）の Amazon Nova Pro（テキスト生成） の料金を例に、Tier ごとの単価差を整理してみます。

オンデマンド推論（1,000 トークンあたり）

Tier	1,000 input tokens	1,000 output tokens	Standard 比
Priority	0.00168000	0.00672000	約 1.75 倍
Standard	0.00096000	0.00384000	1.0 倍
Flex	0.00048000	0.00192000	約 0.5 倍

※ 単位はいずれも「1,000 トークンあたり」のUSDの金額です。

例えば「1,000 input + 1,000 output トークン を 1 リクエスト」として計算すると、概算のコストは次のようになります。

Priority
- 0.00168000（入力） + 0.00672000（出力） = 0.00840000
Standard
- 0.00096000（入力） + 0.00384000（出力） = 0.00480000
Flex
- 0.00048000（入力） + 0.00192000（出力） = 0.00240000

Priority は Standard の 約 1.75 倍 の単価
Flex は Standard の 約 1/2（50% 割引） の単価

という関係になっています。

バッチ推論と Flex の関係

同じく東京リージョンのAmazon Nova Pro について、「1,000 input + 1,000 output トークン」を 1 単位として見ると次のようになります。

種別	合計コスト (USD)	Standard オンデマンド比
Priority（オンデマンド）	0.00168000 + 0.00672000 = 0.00840000	約 1.75 倍
Standard（オンデマンド）	0.00096000 + 0.00384000 = 0.00480000	1.0 倍
Flex（オンデマンド）	0.00048000 + 0.00192000 = 0.00240000	約 1/2
Standard（バッチ推論）	0.00048000 + 0.00192000 = 0.00240000	約 1/2

見ての通り、Nova Pro の場合は Flex（オンデマンド）と Standard のバッチ推論が同じ単価 になっています。

完全にバッチ処理にできるジョブ → Standard のバッチ推論で半額に
オンデマンド API のままにしておきたいが、レイテンシ許容度が高いジョブ → Flex に寄せて Standard 比半額に

という整理にすると、「バッチ推論」と「Flex」の棲み分けがイメージしやすいかと思います。

Tierごとの特徴とユースケース

まずはそれぞれのTierをざっくり整理します。

Priority Tier

特徴
- 他のTierよりも優先的にリクエストが処理される
- コンピュートリソースも優先的に割り当て
- Standardと比べて、対応モデルでは出力トークン毎秒（OTPS）が最大25%程度向上するとされています
- その分、料金はPremium
向いているユースケース
- エンドユーザー向けのチャットボット / カスタマーサポート
- リアルタイムの言語翻訳
- 取引や決済など、SLAが厳しい業務システムの一部
- 「返ってこないと困るし、遅くても困る」系の処理
混雑時の挙動
- 需要が高い時間帯には、他のTierより優先して処理されるため、レイテンシのばらつきを抑えやすくなります

Standard Tier

特徴
- これまでのBedrockオンデマンド推論と同等のTier
- 安定した性能・通常料金
- 特に指定しない限り、このTierが選択される（service_tier=default）
向いているユースケース
- 一般的なテキスト生成（ブログ下書き、メールドラフト等）
- テキスト分析、分類
- 日常業務のドキュメント処理、FAQ回答など

Flex Tier

特徴
- Standard より低料金で利用可能なコスト効率重視の Tier
- レイテンシは長めでも OK な前提
- サーバ側での優先度は Standard より低く、需要が高いタイミングでは待たされる可能性が高い
向いているユースケース
- モデル評価（プロンプトの AB テスト、大量のベンチマーク実行）
- 大量ドキュメントの要約・タグ付け・ラベリング（イベント駆動で 1 件ずつ処理するようなパターン）
- Agentic なワークフローのバックグラウンド処理（ユーザー非対話ステップ）
- 社内ポータルの Q&A チャットなど、多少遅くても致命的ではない対話系
- 「バッチ API にまとめるほどではないが、オンデマンドで順次流したい系」の処理

簡易な選定フレームワーク

AWS公式ブログでは、Tier選定のメンタルモデルとして次のような分類が紹介されています。

カテゴリ	推奨Tier	典型的なユースケース例
ミッションクリティカル	Priority	カスタマーサポートチャット、リアルタイム翻訳、インタラクティブなAIアシスタントなど
ビジネス標準	Standard	マーケティングコンテンツ生成、テキスト分析、通常の文書処理
ビジネス非クリティカル	Flex	モデル評価、大量の要約ジョブ、多段のエージェントワークフロー

現場でTierを決めるときは、次のステップで整理することができるかと思います。

ワークロードを棚卸し
- APIごと、エンドポイントごとに「だれのため」「どのくらいの速さが必要か」をざっくり分ける
SLO/期待値でラベリング
- 「混雑時でも安定した推論パフォーマンスが必要 → Priority候補」
- 「レイテンシがあっても影響が軽微で許容可能 → Flex候補」
まずは小さくテスト
- 検証環境にてTierを切り替えて実際の挙動を確認
- レイテンシと料金のトレードオフを確認

特にFlexは、「とりあえず全部Flexにしよう」とするとユーザー体験を壊しかねないので、用途を限定してから使うのが安全かと思います。

実測：各階層のレイテンシー比較

実際に Amazon Nova Pro（us-east-1）で Converse API 利用時の各サービス階層のレイテンシーを測定してみました。
ここで紹介する値は各階層10回ずつの小規模ベンチマーク結果であり、厳密な評価には実際のワークロードを利用した検証をおすすめします。

測定条件

モデル: amazon.nova-pro-v1:0
リージョン: us-east-1
測定回数: 各階層10回ずつ
レイテンシ: クライアント側で time.time() により計測したエンドツーエンドの処理時間（ネットワーク往復＋Bedrock推論を含む）
プロンプト: 「Amazon Bedrockのサービスの特徴について1000文字程度で説明してください」
max_tokens: 1500
temperature: 0（レイテンシ比較のため決定論的な出力を優先）
測定日: 2025年11月28日
実行環境: MacBook Air M4 / Python 3.13.3 / boto3 1.41.5

▼測定スクリプトを表示する

#!/usr/bin/env python3
 
import boto3
import time
import statistics
import json
from typing import List, Dict, Any
from datetime import datetime

# ベンチマーク設定
MODEL_ID = "amazon.nova-pro-v1:0"
REGION = "us-east-1"
ITERATIONS = 10  

# 測定に使用するプロンプト
# 長めの生成タスクで、実際の業務で使われそうな内容を選定
BENCHMARK_PROMPTS = [
    {
        "name": "技術説明（長文生成）",
        "content": "Amazon Bedrockのサービスの特徴について1000文字程度で説明してください",
        "max_tokens": 1500
    }
]
 
 
def measure_latency(
    bedrock_runtime: Any,
    model_id: str,
    prompt: str,
    max_tokens: int,
    service_tier: str
) -> Dict[str, Any]:
    """
    単一のリクエストのレイテンシーを測定
    
    Returns:
        dict: レスポンス時間と使用トークン数を含む辞書
    """
    start_time = time.time()
    
    try:
        # serviceTierの指定方法を分岐
        if service_tier == "standard":
            # Standardの場合はserviceTierを指定しない
            response = bedrock_runtime.converse(
                modelId=model_id,
                messages=[
                    {
                        "role": "user",
                        "content": [{"text": prompt}]
                    }
                ],
                inferenceConfig={
                    "maxTokens": max_tokens,
                    "temperature": 0,
                }
            )
        else:
            # Priority / Flexの場合は明示的に指定
            response = bedrock_runtime.converse(
                modelId=model_id,
                messages=[
                    {
                        "role": "user",
                        "content": [{"text": prompt}]
                    }
                ],
                inferenceConfig={
                    "maxTokens": max_tokens,
                    "temperature": 0,
                },
                serviceTier={
                    "type": service_tier
                }
            )
        
        end_time = time.time()
        latency = end_time - start_time
        
        return {
            "latency": latency,
            "usage": response["usage"],
            "service_tier": response.get("serviceTier", {"type": "standard"})["type"],
            "success": True
        }
        
    except Exception as e:
        end_time = time.time()
        return {
            "latency": end_time - start_time,
            "error": str(e),
            "success": False
        }
 
 
def calculate_statistics(latencies: List[float]) -> Dict[str, float]:
    """
    レイテンシーの統計情報を計算
    
    Args:
        latencies: レイテンシーのリスト（秒）
    
    Returns:
        dict: 平均値、中央値、95パーセンタイルを含む辞書
    """
    if not latencies:
        return {
            "mean": 0,
            "median": 0,
            "p95": 0,
            "min": 0,
            "max": 0
        }
    
    sorted_latencies = sorted(latencies)
    n = len(sorted_latencies)
    p95_index = int(n * 0.95)
    
    return {
        "mean": statistics.mean(latencies),
        "median": statistics.median(latencies),
        "p95": sorted_latencies[min(p95_index, n-1)],
        "min": min(latencies),
        "max": max(latencies)
    }
 
 
def run_benchmark(
    bedrock_runtime: Any,
    model_id: str,
    service_tier: str,
    prompt_config: Dict[str, Any],
    iterations: int
) -> Dict[str, Any]:
    """
    指定されたサービス階層でベンチマークを実行
    
    Args:
        bedrock_runtime: Bedrock Runtimeクライアント
        model_id: モデルID
        service_tier: サービス階層（priority/standard/flex）
        prompt_config: プロンプト設定
        iterations: 実行回数
    
    Returns:
        dict: ベンチマーク結果
    """
    print(f"\n{'='*60}")
    print(f"Testing {service_tier.upper()} tier")
    print(f"{'='*60}")
    print(f"Prompt: {prompt_config['name']}")
    print(f"Iterations: {iterations}")
    print(f"Model: {model_id}")
    
    latencies = []
    token_counts = []
    errors = []
    
    for i in range(iterations):
        print(f"\n  Run {i+1}/{iterations}...", end=" ", flush=True)
        
        result = measure_latency(
            bedrock_runtime,
            model_id,
            prompt_config["content"],
            prompt_config["max_tokens"],
            service_tier
        )
        
        if result["success"]:
            latencies.append(result["latency"])
            token_counts.append(result["usage"]["totalTokens"])
            print(f"✓ {result['latency']:.2f}s ({result['usage']['totalTokens']} tokens)")
        else:
            errors.append(result["error"])
            print(f"✗ Error: {result['error']}")
        
        # レート制限を避けるため、少し待機
        if i < iterations - 1:
            time.sleep(1.5)
    
    # 統計情報を計算
    stats = calculate_statistics(latencies)
    
    return {
        "service_tier": service_tier,
        "stats": stats,
        "latencies": latencies,
        "token_counts": token_counts,
        "errors": errors,
        "success_rate": len(latencies) / iterations * 100
    }
 
 
def print_results(results: List[Dict[str, Any]]):
    """
    ベンチマーク結果を表形式で出力
    """
    print(f"\n{'='*80}")
    print("BENCHMARK RESULTS SUMMARY")
    print(f"{'='*80}")
    print(f"Model: {MODEL_ID}")
    print(f"Region: {REGION}")
    print(f"Iterations per tier: {ITERATIONS}")
    print(f"Timestamp: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
    
    print(f"\n{'Tier':<12} {'Mean':<10} {'Median':<10} {'P95':<10} {'Min':<10} {'Max':<10} {'Success':<10}")
    print("-" * 80)
    
    for result in results:
        tier = result["service_tier"].upper()
        stats = result["stats"]
        success_rate = result["success_rate"]
        
        print(f"{tier:<12} "
              f"{stats['mean']:.3f}s    "
              f"{stats['median']:.3f}s    "
              f"{stats['p95']:.3f}s    "
              f"{stats['min']:.3f}s    "
              f"{stats['max']:.3f}s    "
              f"{success_rate:.0f}%")
    
    # 比較情報を表示
    print(f"\n{'='*80}")
    print("COMPARISON (vs Standard)")
    print(f"{'='*80}")
    
    standard_result = next((r for r in results if r["service_tier"] == "standard"), None)
    if standard_result:
        standard_median = standard_result["stats"]["median"]
        
        for result in results:
            if result["service_tier"] != "standard":
                tier = result["service_tier"].upper()
                median = result["stats"]["median"]
                diff_percent = ((median - standard_median) / standard_median) * 100
                diff_symbol = "+" if diff_percent > 0 else ""
                
                print(f"{tier:<12} Median: {median:.3f}s ({diff_symbol}{diff_percent:.1f}%)")
    
    # エラー情報
    print(f"\n{'='*80}")
    print("ERRORS")
    print(f"{'='*80}")
    has_errors = False
    for result in results:
        if result["errors"]:
            has_errors = True
            print(f"\n{result['service_tier'].upper()}:")
            for error in result["errors"]:
                print(f"  - {error}")
    
    if not has_errors:
        print("No errors occurred during the benchmark.")
 
 
def save_results_to_json(results: List[Dict[str, Any]], filename: str = "benchmark_results.json"):
    """
    結果をJSON形式で保存
    """
    output = {
        "timestamp": datetime.now().isoformat(),
        "model_id": MODEL_ID,
        "region": REGION,
        "iterations": ITERATIONS,
        "results": []
    }
    
    for result in results:
        output["results"].append({
            "service_tier": result["service_tier"],
            "statistics": result["stats"],
            "latencies": result["latencies"],
            "token_counts": result["token_counts"],
            "success_rate": result["success_rate"],
            "errors": result["errors"]
        })
    
    with open(filename, 'w', encoding='utf-8') as f:
        json.dump(output, f, indent=2, ensure_ascii=False)
    
    print(f"\n✓ Results saved to {filename}")
 
 
def main():
    """
    メイン処理
    """
    print("="*80)
    print("Amazon Bedrock Service Tier Latency Benchmark")
    print("="*80)
    
    # Bedrockクライアントを初期化
    bedrock_runtime = boto3.client(
        service_name="bedrock-runtime",
        region_name=REGION
    )
    
    # 各サービス階層でベンチマークを実行
    tiers = ["priority", "standard", "flex"]
    results = []
    
    for tier in tiers:
        result = run_benchmark(
            bedrock_runtime,
            MODEL_ID,
            tier,
            BENCHMARK_PROMPTS[0],
            ITERATIONS
        )
        results.append(result)
    
    # 結果を表示
    print_results(results)
    
    # 結果をJSONファイルに保存
    save_results_to_json(results)
    
    print(f"\n{'='*80}")
    print("Benchmark completed successfully!")
    print(f"{'='*80}\n")
 
 
if __name__ == "__main__":
    main()

測定結果

結果の考察

今回の測定では、以下の傾向が見られました：

Priority階層が最速: 中央値13.077sで、Standardより6.4%速い結果
- 最小値11.461sと最大値15.196sの差が比較的小さく、安定したレスポンスを提供
- 優先処理の効果が明確に現れています
- 25%の改善には届いていませんが、混雑時にはより効果が出るものと思われます
Standard階層: 中央値13.970sで中間的な性能
- 安定した性能を発揮し、コストと性能のバランスが良い
Flex階層が最も遅い: 中央値15.835s（Standardより+13.4%）
- コスト削減（50%オフ）の代償として、レイテンシーが長くなる傾向

注意: この測定結果は特定の時間帯・負荷状況での一例です。実際の性能は時間帯やリージョンの負荷状況によって変動すると考えられます。出力文字数が200文字程度で試した際はFlexが最速になる場合も見られました。処理時間の長さや混雑度によってはPriorityが必ずしも最速にはならない可能性もありそうです。あくまで混雑時に優先されるというのがPriorityの価値であり最大25%レイテンシが向上することを期待して利用するのは注意が必要そうです。

(参考)出力文字数200文字程度の場合の結果

測定結果(Nova Pro, us-east-1, 200 tokens output)

中央値はほぼ差がなく、Standardが最速となっています。最小値ではFlexがPriorityよりレイテンシが小さくなっています。推論時間が短く試行回数も少ないため、このケースではPriorityの効果やFlexの遅延は観測しづらいと考えられます。

繰り返しになりますが各階層で10回程度の簡易測定結果であるため、厳密には実際のワークロードを利用した検証を推奨いたします。

APIからサービス階層を指定する

サービス階層は、Bedrock Runtime API呼び出し時のオプションパラメータで指定します。モデルがTierに対応していれば、CLIやSDKから簡単に指定できます。

AWSでは会話アプリケーションの場合、Converse API の利用が推奨されています。本記事でもConverse APIを使った例を中心に紹介します。

1. AWS CLI（Converse API）で指定する例

Amazon Nova ProモデルをPriority Tierで呼び出す例です。

aws bedrock-runtime converse \
  --model-id amazon.nova-pro-v1:0 \
  --messages '[{"role": "user", "content": [{"text": "サービス階層について教えてください。"}]}]' \
  --inference-config '{"maxTokens": 200, "temperature": 0.3}' \
  --service-tier '{"type": "priority"}' \
  --region us-east-1

ポイント:

--service-tier に {"type": "priority"} / {"type": "flex"} の形式で指定
指定しなければStandard Tier（default）が使われます

2. Python（boto3）でConverse APIを使用する例

前提条件: serviceTier利用には 1.40.76 以降が必要です。

pip install --upgrade boto3

Converse APIでサービス階層を指定:

import boto3

bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1",
)

response = bedrock_runtime.converse(
    modelId="amazon.nova-pro-v1:0",
    messages=[
        {
            "role": "user",
            "content": [
                {"text": "Bedrockのサービス階層について説明してください。"}
            ]
        }
    ],
    inferenceConfig={
        "maxTokens": 300,
        "temperature": 0.3,
    },
    serviceTier={
        "type": "priority"  # "priority" / "flex"
    }
)

print(response["output"]["message"]["content"][0]["text"])
print(f"Service tier: {response['serviceTier']['type']}")

複数のTierをテストする例:

import boto3

bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1",
)

# Priority, Standard, Flexの各階層をテスト
tiers = ["priority", "flex"]  # Standardは指定しない場合のデフォルト

for tier in tiers:
    response = bedrock_runtime.converse(
        modelId="amazon.nova-pro-v1:0",
        messages=[
            {
                "role": "user",
                "content": [
                    {"text": f"{tier}階層でリクエストしています。"}
                ]
            }
        ],
        inferenceConfig={
            "maxTokens": 200,
            "temperature": 0.3,
        },
        serviceTier={
            "type": tier
        }
    )
    
    print(f"使用したTier: {response['serviceTier']['type']}")
    print(f"トークン使用量: {response['usage']}")

3. OpenAI互換APIで指定する例

OpenAI互換のChat Completionsエンドポイントを使う場合は、リクエストボディに service_tier フィールドを追加します。

from openai import OpenAI

client = OpenAI(
    base_url="https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1",
    api_key="AWS_BEARER_TOKEN_BEDROCK", 
)

completion = client.chat.completions.create(
    model="openai.gpt-oss-120b-1:0",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "サービス階層の違いを教えてください。"},
    ],
    service_tier="priority",  # "priority" / "flex" / "default"
)

print(completion.choices[0].message)

4. Python（boto3）でInvokeModel APIで指定する例

InvokeModel / InvokeModelWithResponseStream を使う実装でも、リクエストパラメータに serviceTier を含めることで同様にサービス階層を指定できます。

InvokeModel APIは主に以下の場合に使用します：

既存のInvokeModelベースのコード資産がある
埋め込みや画像生成など、Converseが対応していないモデルを使用する

import boto3
import json
bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1",
)
 
body = json.dumps({
    "messages": [
        {
            "role": "user",
            "content": [
                {"text": "Bedrockのサービス階層について簡単に説明してください。"}
            ]
        }
    ],
    "inferenceConfig": {
        "maxTokens": 512,
        "temperature": 0.7
    }
})
response = bedrock_runtime.invoke_model(
    modelId="amazon.nova-pro-v1:0",
    body=body,
    contentType="application/json",
    accept="application/json",
    serviceTier="priority"  # "priority" / "flex" / "default"
)
response_body = json.loads(response["body"].read())
print(response_body["output"]["message"]["content"][0]["text"])

対応モデルとリージョン

2025年11月執筆時点では、Priority / Flexサービス階層に対応している代表的なモデルは以下のとおりです。

OpenAI
- openai.gpt-oss-120b-1:0
- openai.gpt-oss-20b-1:0
Qwen
- qwen.qwen3-235b-a22b-2507-v1:0
- qwen.qwen3-coder-480b-a35b-v1:0
- qwen.qwen3-coder-30b-a3b-v1:0
- qwen.qwen3-32b-v1:0 など
DeepSeek
- deepseek.v3-v1:0（DeepSeek-V3.1）
Amazon Nova
- amazon.nova-premier-v1:0
- amazon.nova-pro-v1:0

リージョンは東京リージョン（ap-northeast-1）を含む複数のリージョンで利用可能です。詳細なリストは公式ドキュメントの最新情報をご確認ください。