AWS What's New Digest

Appearance

2026年08月04日 ​

[Rds For Sql Server] Amazon RDS for SQL Server now support BYOM in additional commercial regions ​

概要 ​

Amazon RDS for SQL Serverが、BYOM（Bring Your Own Media）をさらに10の商用リージョンでサポートしました。既存のMicrosoft SQL Serverライセンス（Software Assurance付き）をRDSで再利用できます。

変更内容・新機能の詳細 ​

今回の拡張により、Asia Pacific（Taipei, Hyderabad, Jakarta, Malaysia, Melbourne, New Zealand, Thailand）、Europe（Milan, Spain）、および Mexico（Central）の計10リージョンでRDS for SQL ServerのBYOMが利用可能になりました。BYOMを使うと、MicrosoftのLicense Mobilityプログラムに基づき、Software Assurance（SA）付きの既存ライセンスをAmazon RDS上の管理対象SQL Serverインスタンスに割り当て可能です。サポートされるSQL Serverのバージョンは2019、2022、2025です。RDSのBYOMはAWS License Managerと統合されており、AWS環境全体でライセンス使用状況を追跡し、コンプライアンス管理に利用できます。導入時はRDSインスタンス作成時にBYOMオプションを選択し、License Managerでライセンスを登録・追跡します。詳細な料金や地域ごとの可用性はAmazon RDS for SQL Serverの料金ページで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 既存のMicrosoft SQL Serverライセンス（Software Assurance付き）を保有するエンタープライズ、データベース管理者、クラウド移行チーム
  • 利用シーン: オンプレミスからRDSへのリホスト（Lift-and-Shift）移行で既存ライセンスを再利用してライセンスコストを最適化する場合
  • 運用効果: ライセンス移行によるコスト削減とRDSの管理・運用メリット（パッチ管理、バックアップ、スケーリング）を組み合わせられる
  • リージョン影響: 上記10リージョンが追加でBYOMをサポートするため、これら地域での既存ライセンス利用が可能になる

技術的な注意点 ​

  • 前提条件: ライセンスをBYOMで利用するには対象ライセンスがMicrosoftのLicense Mobilityに適格であり、かつ有効なSoftware Assurance（SA）が必要です
  • 対応バージョン: SQL Server 2019, 2022, 2025 をサポート
  • AWS License Manager: BYOMはLicense Managerと統合されるため、ライセンスの登録・追跡を行ってコンプライアンス管理をしてください
  • IAM権限: RDSインスタンス作成、AWS License Manager操作に必要なIAM権限（rds:CreateDBInstance などおよび license-manager 関連権限）を付与する必要があります
  • リージョン制限: 今回追加された10リージョン以外では未対応の可能性があるため、デプロイ前に利用予定リージョンの対応状況と料金を確認してください
  • コスト: BYOMはMicrosoftライセンス費用自体をAWSが肩代わりするものではありません。RDSのインスタンス料金は別途発生します。ライセンス移行による全体コスト影響を事前に評価してください
  • 運用上の注意: RDSはマネージドサービスのため、オンプレミスのSQL Serverで可能だった一部のサーバー/OSレベルの機能や拡張は利用できない場合があります（機能差分は事前検証を推奨）
  • Microsoft側の手続き: ライセンス移行やLicense Mobilityの適用にはMicrosoft側の承認や記録保持が必要になる場合があるため、必要書類・手順を確認してください
  • コンプライアンス責任: ライセンスの適正利用は顧客の責任です。License Managerでの追跡やMicrosoftとの契約内容を遵守してください

参考情報 ​

[Rds For Sql Server] Amazon RDS for SQL Server supports Developer Edition in additional AWS regions ​

概要 ​

Amazon RDS for SQL Server の Developer Edition が 13 の追加リージョンで利用可能になりました。Developer Edition は Enterprise Edition と同等の機能を持ち、開発・テスト用途ではライセンス料が免除されます。

変更内容・新機能の詳細 ​

今回の拡張により、Asia Pacific（Hong Kong、Taipei、Hyderabad、Jakarta、Malaysia、Melbourne、New Zealand、Thailand）、Canada West（Calgary）、Europe（Milan、Spain）、Israel（Tel Aviv）、Mexico（Central）の合計13リージョンで RDS for SQL Server の Developer Edition が利用可能になりました。Developer Edition は SQL Server Enterprise の機能セット（例：高機能な管理・データベース機能）を含みますが、Microsoft のライセンス条件に従い開発・テスト用途向けにライセンス料が免除されます。リージョン拡大により、ユーザーはアプリケーション開発・検証をエンドユーザーやデータに近い場所で行えるため、ネットワーク遅延の低減や開発ワークフローの簡素化が期待できます。RDS のインスタンス料金、ストレージ、バックアップ、I/O などの通常の AWS 利用料金は引き続き適用されるため、コスト見積もり時には注意してください。詳細な対応バージョン／機能や制限事項は公式ドキュメントで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、テスト/QA チーム、RDBMS を利用する開発組織
  • 利用シーンまたは効果: 開発・テスト環境をエンドユーザーやデータに近いリージョンで構築し、ネットワーク遅延を低減して動作確認や負荷検証が可能
  • 運用効果: リージョン分散による検証精度向上とデバッグ速度の改善、リージョン移行前のローカル検証が容易になることでリリースリスクを低減
  • 対象リージョン（今回追加分）: Hong Kong、Taipei、Hyderabad、Jakarta、Malaysia、Melbourne、New Zealand、Thailand、Calgary、Milan、Spain、Tel Aviv、Mexico (Central)

技術的な注意点 ​

  • ライセンス: Developer Edition は開発・テスト用途向けでライセンス料が免除。ただし本番運用での使用は Microsoft ライセンス条件に反する可能性があるため避けること
  • コスト: SQL Server のライセンス料は免除されるが、RDS のインスタンス時間、ストレージ、スナップショット、I/O、データ転送などの通常料金は発生する
  • リージョン制限: 対象リージョンでのみ利用可能。マネジメントコンソール／CLI／API での配信状況を事前に確認すること
  • IAM権限: DB インスタンス作成や設定変更には rds:CreateDBInstance / rds:ModifyDBInstance 等の適切な権限が必要。VPC やサブネット、セキュリティグループ操作に関する権限も確認すること
  • 機能・互換性: Developer Edition は Enterprise と同等の機能を含むが、RDS 固有のサポート範囲や制約（例: 一部 OS レベルの操作不可や拡張機能の制限）があるため、利用予定の SQL Server 機能が RDS でサポートされているか公式ドキュメントで確認すること
  • 運用設計: 高可用性（Multi-AZ）やバックアップ、パラメータ/オプショングループの設定は通常の RDS インスタンスと同様に計画が必要。スナップショットや移行の手順も検討すること

参考情報 ​

[Rds For Sql Server] RDS SQL Server now supports publishing SQL Server Audit logs to CloudWatch ​

概要 ​

Amazon RDS for SQL Server が SQL Server Audit の監査ログを CloudWatch Logs に直接配信できるようになりました。これにより監査イベントのリアルタイム分析や既存のログ処理ワークフローへの統合が容易になります。

変更内容・新機能の詳細 ​

SQL Server Audit は SQL Server 本体の機能で、データベースエンジン上で発生するイベントを追跡・記録します。RDS for SQL Server 上では従来通り監査（audits）および監査仕様（audit specifications）を作成できますが、今回の更新により監査ログの出力先として Amazon S3 と CloudWatch Logs の両方を選択できるようになりました。S3 と CloudWatch の両方を有効にした場合、監査ログの“publication”は両方へアップロードが完了するまで「completed」とマークされません。CloudWatch に配信された監査ログは CloudWatch Logs Insights、メトリクス変換、サブスクリプションフィルタ（Lambda/Kinesis 連携）などでリアルタイム解析やアラート設定、SIEM 連携が可能です。さらに、RDS 側で監査ログを DB インスタンス上に一定期間保持する設定（retention）を行うこともできます。設定方法や詳細は Amazon RDS for SQL Server User Guide に記載されており、AWS マネジメントコンソール、AWS CLI、RDS API を通じて構成できます。本機能は Amazon RDS for SQL Server が利用可能なすべての AWS Commercial および AWS GovCloud (US) リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者（DBA）、セキュリティ/コンプライアンス担当者、SRE/運用チーム
  • 利用シーン: 監査イベントのリアルタイム監視と解析、アラート発砲、SIEM 連携、フォレンジック調査やコンプライアンス証跡の長期保管
  • 運用効果: 監査ログの即時分析により不正検知や問題対応の時間短縮、S3 と CloudWatch を組み合わせた二重保存で耐障害性と検索性を両立

技術的な注意点 ​

  • IAM権限: CloudWatch Logs や S3 にログを配信するための RDS のサービス側権限は AWS 側が管理しますが、ログ閲覧や CloudWatch Insights 実行には適切な IAM ポリシーが必要です
  • リージョン制限: Amazon RDS for SQL Server が提供されているすべての AWS Commercial および AWS GovCloud (US) リージョンで利用可能（リージョン未対応の場合はドキュメントを確認）
  • コスト: CloudWatch Logs の取り込み・保存、S3 のストレージとリクエストに対する料金が発生します。リアルタイム解析や長期保持を有効にするとコスト増となる可能性があります
  • 保持（retention）: RDS の設定で DB インスタンス上に監査ログを一定期間保持できます。S3 に保存する場合は別途ライフサイクル設定で長期保管を管理可能
  • 配信動作: S3 と CloudWatch の両方を有効化した場合、両方のアップロード完了後に「completed」と見なされます。片方のみの保証ではない点に注意
  • 暗号化: CloudWatch Logs、S3 ともに AWS KMS による暗号化を利用可能です。顧客管理キー（CMK）を使う場合は追加の権限・設定が必要です
  • ログ形式と解析: 出力される監査ログは SQL Server Audit の形式に準拠します。CloudWatch Logs Insights や外部ツールで解析する際はログ形式を把握しておくと便利です
  • 設定方法: AWS マネジメントコンソール、AWS CLI、または RDS API（および該当するユーザーガイド）に従って設定してください

参考情報 ​

[General] AWS Transform continuous modernization is now generally available ​

概要 ​

AWS Transform の continuous modernization 機能が一般提供（GA）になりました。ソースコードリポジトリを大規模に解析して技術的負債やセキュリティ課題を検出・優先化し、修正用ブランチやプル／マージリクエストを自動で作成してリモートリポジトリへ反映できるようになりました。

変更内容・新機能の詳細 ​

continuous modernization は、GitHub 組織、GitLab グループ、Bitbucket ワークスペースを接続してリポジトリをスケジュールまたはオンデマンドで解析し、技術的負債、セキュリティ、agentic readiness、modernization readiness、カスタム基準などのカテゴリで検出結果を優先化します。検出結果に対して修正（remediation）が定義されている場合は、自動でブランチを作成しプルリクエスト／マージリクエストを開いて検証済みのコード変更をレビュー可能な形で提示します。解析と修正処理はお客様の AWS アカウント内でお客様の資格情報を用いて実行されるため、ソースコードはお客様の管理下に留まります。開発者向けには AWS Transform の Web アプリケーションから操作できるほか、AWS Transform Kiro Power、agent プラグイン、CLI を用いて IDE や端末からローカルリポジトリを解析したり、ラベルでリポジトリを整理したり、Amazon EC2 や AWS Batch を使ってローカル／リモートで解析を実行できます。スケジュール実行、優先度付け、修正の自動ブランチ作成と PR/MR のオープンにより、定期的な技術負債の管理と自動化された修正ワークフローが実現します。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発チーム、プラットフォーム／SRE チーム、ソフトウェアアーキテクト、DevOps エンジニア
  • 利用シーン: 大規模リポジトリ群の技術的負債やセキュリティ問題の継続的な検出・優先化と、自動生成された修正ブランチ／PR を使ったレビュー主体の修正ワークフローの導入
  • 運用効果: 手作業によるコードレビュー・パッチ作成の工数削減、技術的負債の早期検出と一貫した優先付けによる保守性向上、CI/CD への統合による修正サイクル短縮

技術的な注意点 ​

  • IAM権限: Transform が実行する AWS リソース（EC2、Batch、S3、ECR など）を操作するための IAM ロール／ポリシーが必要です。実行はお客様のアカウントで行われるため、最小権限の原則でロールを設計してください。
  • ソースプロバイダ権限: GitHub/GitLab/Bitbucket と連携するためにリポジトリの読み取り／書き込み（ブランチ作成、PR/MR 作成）権限が必要です。OAuth トークンやパーソナルアクセストークン（PAT）などの設定が求められます。
  • リージョン制限: 本機能は「AWS Transform がサポートする全リージョン」で利用可能です。利用前にコンソールで対象リージョンのサポート状況を確認してください。
  • コスト: 解析や修正の実行に伴う AWS リソース（EC2、AWS Batch、S3、ECR、ログ／メトリクス）の実行・保存コストが発生します。AWS Transform 自体に料金がある場合は別途発生する可能性がありますので見積りしてください。
  • シークレット管理: ソースプロバイダ用のトークンや認証情報は安全に管理する必要があります（Secrets Manager 等の利用を検討）。
  • プルリクエストの扱い: 自動で作成される PR/MR は review のために開かれますが、マージは自動で行わない設定にするなどワークフローを検討してください。
  • ローカル解析とエージェント: Kiro Power や agent プラグインを用いる場合、ローカル環境の依存関係やネットワーク設定（プロキシ、ファイアウォール）に注意してください。
  • 既存 CI/CD との統合: 自動修正の取り込みや検証は既存の CI パイプラインに合わせた調整が必要です（テスト、セキュリティスキャンの再実行等）。

参考情報 ​

[Bedrock] OpenAI GPT-5.6 Sol, Terra, and Luna now support 1 million token context windows on Amazon Bedrock ​

概要 ​

Amazon Bedrockで提供されるOpenAI GPT-5.6（Sol、Terra、Luna）が最大100万トークンのコンテキストウィンドウをサポートしました。これによりコードベースや長文ドキュメント、長いマルチターン履歴を単一リクエストで扱えます。

変更内容・新機能の詳細 ​

GPT-5.6のSol、Terra、Lunaが1,000,000トークンのコンテキストウィンドウをサポートします。これによりリポジトリ丸ごとのコードレビューやマイグレーション、長大な法務／規制文書のエンドツーエンド処理、マルチステップのエージェントワークフローでの会話履歴保持などが一度のリクエストで可能になります。長いコンテキストをそのままモデルに渡せるため、チャンク分割に伴う情報欠落や整合性問題が減り、より広範な文脈に基づく一貫した推論結果が得られます。Bedrock上の料金はOpenAIのファーストパーティ料金に合わせられ、AWS利用コミットメントにカウントされます。プロンプトキャッシュは明示的なキャッシュブレークポイントを設定した長コンテキスト要求にも適用され、繰り返し同一コンテキストを送る場合は90%の割引が適用されます。利用はAmazon BedrockコンソールまたはResponses API（bedrock-mantleエンドポイント）から行えます。モデル提供リージョンは以下の通りです：Sol → US East (N. Virginia: us-east-1)、US East (Ohio: us-east-2)。Terra & Luna → US East (N. Virginia: us-east-1)、US East (Ohio: us-east-2)、US West (Oregon: us-west-2)。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、AIリサーチャー、SRE/運用チーム、ソフトウェア移行担当者
  • 利用シーン: リポジトリ全体の自動コードレビュー／リファクタリング、長文契約書や規制文書の一括解析、マルチターンのエージェント／チャットボットで完全な会話履歴を保持した処理
  • 運用効果: チャンク分割不要による情報欠落低減と高精度化。単一パスでの解析によりワークフローが簡素化され、運用コストと手戻りを削減可能

技術的な注意点 ​

  • IAM権限: BedrockのResponses APIやコンソール利用に必要なIAMポリシー（bedrock:InvokeModelなど）を事前に付与してください
  • リージョン制限: 一部モデルが利用可能なリージョンに制限あり（Sol: us-east-1/ us-east-2、Terra/Luna: us-east-1/ us-east-2/ us-west-2）。利用前に対象リージョンでの提供状況を確認してください
  • コスト: トークンベースの課金が適用され、長コンテキストでは入力トークン量が大きくなるためコスト増加の可能性あり。繰り返しの同一コンテキストはプロンプトキャッシュの90%割引で抑制可能
  • パフォーマンス: 1Mトークン処理はメモリ使用量とレイテンシが大幅に増加する可能性があります。応答遅延やスループット低下を考慮した設計（非同期処理、タイムアウト設定、バッチ設計等）を推奨します
  • API/エンドポイント: Responses APIをbedrock-mantleエンドポイントで利用可能。SDKやHTTPクライアントでの大容量リクエスト送信時にタイムアウトやペイロード制限を確認してください
  • トークン化の注意: トークンはトークナイザー依存のため、実際の文字数や行数とトークン数は一致しません。送信前にトークン数計測ツールで確認してください
  • 互換性: 既存のチャンク分割・ストリーミング実装は不要になる場合があるため、実装を見直して不要な分割処理の削除やキャッシュ活用を検討してください
  • プロンプトキャッシング: 明示的なキャッシュブレークポイントの設定が必要であり、適切に設計しないと期待する割引やキャッシュ効果が得られない場合があります
  • コンプライアンス／セキュリティ: 長大な機密データを送信する際はデータ保護ポリシーやリージョンの法的要件（データ所在地、暗号化、ログ保存）を確認してください

参考情報 ​

[General] Amazon GameLift Streams now supports sharing streams with stream URLs ​

概要 ​

Amazon GameLift Streamsがストリーム共有用の一時的なストリームURLをサポートしました。受信者はAWSアカウントや認証情報なしで、対応ブラウザからプレイ可能なストリームセッションにアクセスできます。

変更内容・新機能の詳細 ​

今回の追加機能では、ストリームグループとそのアプリケーションに対して「ストリームURL」を発行できるようになりました。発行時にURLの有効期間（TTL）と、そのURLから開始できるセッション数を指定できます。URLを開いた各利用者は独立したストリームセッションを開始し、GameLift Streamsはあなたが選択した配信ロケーション群の中から近いロケーションへルーティングします。受信者側にクライアント統合やバックエンドサービスは不要で、ソフトウェアのインストールやAWSアカウントも不要です。ストリームURLの作成・確認・一覧表示・取消はコンソールまたは新API（CreateStreamUrl、GetStreamUrl、ListStreamUrls、RevokeStreamUrl）で行えます。ストリームURL自体に追加料金はなく、URL経由で開始されたセッションが消費するストリーム容量に対して通常のGameLift Streamsの料金が適用されます。対応リージョンはリージョン表で確認してください。詳しい利用手順やブラウザ要件、API仕様はDeveloper GuideおよびCreateStreamUrl APIリファレンスを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ゲーム開発者、QAチーム、マーケティング担当、プロモーション担当
  • 利用シーンまたは効果: 外部ユーザーへのデモ配信、QA向けの即時テスト招待、ゲーマー向けのプロモーション配信、カスタマーサポートによるリモート再現（URL送付で即プレイ）
  • 運用効果: 認証やクライアント配布の手間を削減し、短時間で多数の独立セッションを提供可能。トライアルやデモの導線が簡略化されるためマーケティング施策の導入速度が向上する
  • スケーラビリティ影響: URLを配布すると受信者ごとに独立したセッションが生成されるため、同時接続数が増えるとストリーム容量（課金対象）と配信インフラの需要が増大する

技術的な注意点 ​

  • IAM権限: CreateStreamUrlやRevokeStreamUrlなどのAPI実行に必要なIAMポリシーを事前に用意してください（コンソール操作権限も同様）。
  • リージョン制限: すべてのリージョンで未対応の可能性があるため、対応リージョン表を確認してください。
  • コスト: ストリームURL自体は無償ですが、URL経由で開始されたセッションが消費するストリーム容量に対して通常のGameLift Streams料金が発生します。大量配布ではコストが増加します。
  • セキュリティ: ストリームURLは一時的で認証不要の「ベアラートークン」として機能します。漏洩すると誰でもアクセス可能なため、有効期限設定・セッション数制限・必要に応じてRevokeStreamUrlでの取り消しを行ってください。
  • ブラウザ要件: 対応ブラウザやネットワーク要件（WebRTC等のサポート、ポート/帯域）についてはDeveloper Guideを参照してください。
  • 運用/クォータ: 同時セッション数や発行可能URL数はサービスのクォータに依存します。大量配布前にクォータ確認・引き上げ申請を検討してください。

参考情報 ​

概要 ​

AWS Resilience Hub（次世代）が「推奨レジリエンステスト」機能を提供開始しました。サービス定義とレジリエンスポリシーに基づき、事前構成された障害注入テストを自動で実行・評価します。

変更内容・新機能の詳細 ​

Resilience Hub の推奨レジリエンステストは、サービスのアーキテクチャ、構成、レジリエンスポリシーを参照して事前構成されたテストを作成します。テスト実行時には AWS Fault Injection Service (FIS) を使って制御された障害（例：アベイラビリティゾーン障害、リージョン障害、依存サービスの故障など）を注入し、CloudWatch アラームや定義済みのリカバリ目標（Recovery Objectives）に基づいてサービスが所定の時間内に回復するかを判定します。各テストは対象サービスのリソースを自動でターゲットにし、必要なフォルトを注入、アラーム評価を行って合格/不合格の結果を出力し、詳細なテストレポートを生成します。機能は次世代 Resilience Hub 上で提供され、複数のリージョンで利用可能です（記事掲載のリージョン参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: プラットフォームエンジニア、SRE、サイト信頼性/運用チーム、クラウドアーキテクト
  • 利用シーンまたは効果: 本番に近い条件での障害注入テストにより、AZ単位・リージョン単位・依存サービス障害など既知の障害シナリオに対する復旧能力を検証できる
  • 運用効果: 自動化されたテストと判定によりレジリエンスポリシー遵守の確認が容易になり、障害対応計画の妥当性検証やSLA検証の効率化が期待できる

技術的な注意点 ​

  • IAM権限: Resilience Hub と FIS を実行するための権限（Resilience Hub のテスト実行、FIS: RunExperiment 等、CloudWatch 関連権限、関連リソースの操作権限）が必要です。事前に最小権限のポリシーを設計してください
  • リージョン制限: 次世代 Resilience Hub の推奨テストは記事記載の以下リージョンで利用可能です: us-east-1, us-east-2, us-west-2, ca-central-1, eu-west-1, eu-west-2, eu-central-1, eu-west-3, eu-north-1, ap-south-1, ap-southeast-1, ap-southeast-2, ap-northeast-1, ap-northeast-2, sa-east-1
  • コスト: FIS 自体の操作で追加課金は発生しないものの、障害注入によるリソースの状態変化（代替リソース起動、ログ/メトリクス増加、データ転送など）やテスト結果を保存するストレージ・CloudWatch ログ/メトリクスの利用に対しては通常の料金が発生します。定期実行する場合はコスト見積りを行ってください
  • 運用上の注意: テストは実際にリソースへ障害を注入するため、事前にスケジュール・影響範囲の承認を得て、バックアップ/リカバリ手順を準備してください。テストは本番影響を伴う可能性があるため、メンテナンスウィンドウ内での実行を推奨します
  • 互換性/範囲: サービス定義に基づき自動ターゲティングするものの、オンプレ/サードパーティ管理の依存サービスは自動で注入対象にならない場合があります。テスト対象外の依存に対する別途検証が必要です
  • 設定必須項目: 正確な評価のために CloudWatch アラームや Recovery Objectives（RTO/RPO 相当）を事前に定義しておく必要があります
  • 移行注意: 従来の Resilience Hub から次世代を利用する場合は移行手順や互換性を確認してください（必要に応じて設定の再確認が必要）

参考情報 ​

[General] AWS Organizations now provides maximum account quota visibility in Service Quotas ​

概要 ​

AWS Organizationsのアカウント数上限（最大アカウント数）とその利用状況が、AWS Service Quotasから直接確認できるようになりました。これによりサポートやアカウント担当に問い合わせることなく、上限の把握と増枠申請の事前準備が可能になります。

変更内容・新機能の詳細 ​

これまでAWS Organizationsのアカウント上限はサポートやAWSアカウントチームに問い合わせる必要がありましたが、今回の機能により管理アカウントからService Quotasコンソール、またはService QuotasのGetServiceQuota APIを使って「最大アカウント数（maximum number of accounts）」のクォータ値と現在の利用状況を確認できるようになりました。確認は管理アカウントで行うか、管理アカウントと同等の権限を持つIAM主体（クロスアカウントロール等）で行います。現在は米国東部（バージニア北部 / us-east-1）で利用可能です。クォータ情報はService Quotasの該当するサービス（AWS Organizations）エントリとして表示され、増枠が必要な場合はService Quotasの増枠リクエスト機能を通じて申請できます。

影響範囲・利用シーン ​

  • 対象ユーザー: AWS Organizationsを使って複数アカウントを管理する管理者、クラウドプラットフォームチーム、SRE/運用チーム
  • 利用シーン: 事前にアカウント数の上限と利用率を監視してアカウント増設計画を立てる（オンボーディング、組織拡大、環境分離の設計）
  • 運用効果: 増枠が必要になる前に申請できるため、アカウント作成遅延や急なサポート依頼を削減し、オンボーディング・環境展開をスムーズにする

技術的な注意点 ​

  • IAM権限: 管理アカウントでのService Quotas閲覧権限が必要（例: servicequotas:GetServiceQuota、servicequotas:ListServiceQuotas等）。管理アカウント以外からは適切に権限が委譲されたロールでの実行が必要です。
  • リージョン制限: 本リリース時点では米国東部（バージニア北部 / us-east-1）で利用可能。今後順次他リージョンへ展開される可能性があります。
  • コスト: クォータの表示自体や増枠リクエストに対する追加課金は通常発生しませんが、増枠申請の承認プロセスやアカウント増設に伴う運用コスト（アカウント単位のリソース利用）は別途発生します。
  • その他: Service QuotasのコンソールまたはAPI（GetServiceQuota）でAWS Organizationsの該当エントリを選択して確認します。増枠申請はService Quotasのワークフローを通じて実施可能です。

参考情報 ​

[General] AWS Lambda Provisioned Mode for Amazon SQS event source mappings now supports up to 10,000 event pollers ​

概要 ​

AWS LambdaのProvisioned ModeでのAmazon SQS用イベントソースマッピング(ESM)が、イベントポーラーの上限を従来の2,000から10,000に引き上げました。これにより、ESMあたり最大100,000の同時実行を達成でき、高スループット・低レイテンシのイベント駆動アプリケーション構築が容易になります。

変更内容・新機能の詳細 ​

今回の変更はProvisioned Modeで動作するSQSイベントソースマッピング(ESM)における「イベントポーラー(event poller)」の最大数を5倍の10,000に引き上げたものです。Provisioned ModeではESMごとに最小・最大のイベントポーラー数を設定でき、ポーラー数に応じてLambdaがSQSキューをポーリングして関数を同期的に起動します。最大10,000ポーラーは理論上ESMあたり最大100,000の同時Lambda実行(＝ポーラー×バッチあたり1イベント想定)に相当し、大規模なファンアウト処理やリアルタイム注文処理、金融取引パイプライン、IoTテレメトリ吸収などのミッションクリティカル用途で有用です。機能は全てのAWS商用リージョンで一般利用可能(GA)です。設定はLambdaコンソール、ESM API、AWS CLI、AWS SDK、CloudFormation、AWS SAMから行えます。課金はEvent Poller Unit(EPU)という単位での使用量に基づきます。既存のESM制御(バッチサイズ、最大並列実行、リトライ設定など)と組み合わせてスループットとレイテンシの最適化が可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: SQSをイベントソースにしてLambdaで大規模・低遅延処理を行うアプリケーション開発者、SRE、プラットフォームチーム
  • 利用シーン: 大量同時処理が必要な注文処理、金融/決済処理、IoTテレメトリ取り込み、大規模なメッセージファンアウトワークロード
  • 運用効果: ESMを分割せず1つで高い同時実行を達成できるため設計と運用が簡素化され、レイテンシ短縮とスループット向上が期待できる

技術的な注意点 ​

  • IAM権限: lambda:CreateEventSourceMapping / lambda:UpdateEventSourceMapping等の権限が必要です。LambdaがSQSを操作するためのロールにはsqs:ReceiveMessage, DeleteMessage, ChangeMessageVisibility, GetQueueAttributes等を付与してください。
  • アカウント制限/同時実行: ESMあたり最大100,000同時実行が可能とされますが、アカウント全体のLambda同時実行上限(default 1,000等)やリージョン毎のクォータにより制約を受けます。必要に応じてAWSサポートにクォータ引き上げを依頼してください。
  • コスト: イベントポーラーはEvent Poller Unit(EPU)で課金されます。ポーラー数を増やすとEPU課金および通常のLambda実行/実行時間に基づく課金が増加します。プロビジョニング中のアイドル状態でもEPUコストが発生する点に注意してください。
  • モニタリング: CloudWatchでLambdaのConcurrentExecutions、Throttles、及びESM関連メトリクス（IteratorAge/ApproximateAgeOfOldestMessage等）とSQSのApproximateNumberOfMessagesVisibleを監視し、バッチサイズ／ポーラー数の調整やスロットリング対策を行ってください。
  • 設定手段: コンソール、ESM API、AWS CLI(create-event-source-mapping等)、SDK、CloudFormation(AWS::Lambda::EventSourceMapping)、SAMでmin/maxポーラーを設定可能です。
  • リージョン制限: 本機能は全てのAWS商用リージョンで一般提供されています(記事時点)。
  • SQS側注意点: SQSのメッセージ可視性タイムアウトやデッドレターキュー(DLQ)の設定、バッチ処理時のメッセージ重複対策(冪等性)を確認してください。
  • 注意点がない場合: 特になし

参考情報 ​

[Ec2] Amazon EC2 I7i instances now available in Asia Pacific (Thailand) and Israel (Tel Aviv) Regions ​

概要 ​

Amazon EC2のストレージ最適化インスタンス「I7i」が、アジアパシフィック（タイ）およびイスラエル（テルアビブ）リージョンで利用可能になりました。第5世代Intel Xeonと第3世代AWS Nitro SSDにより、前世代I4iと比べて計算性能・ストレージ性能・価格性能が改善されています。

変更内容・新機能の詳細 ​

I7iインスタンスは5th Gen Intel Xeonプロセッサ（オールコアターボ3.2GHz）を搭載し、I4i比で最大23%の計算性能向上、価格性能で10%以上の改善を実現します。ストレージは第3世代AWS Nitro SSDを採用し、最大45TBのNVMeローカルストレージ提供、リアルタイムストレージ性能は最大50%向上、ストレージI/O待ち時間は最大50%短縮、待ち時間のばらつきは最大60%低減とされています。トーンライト（torn write）防止機能は最大16KBブロックサイズまでサポートし、データベース等での部分書き込みによる性能/整合性のボトルネックを軽減します。インスタンスサイズは仮想9サイズ（最大48xlarge）とベアメタル2サイズの計11種類で、ネットワーク帯域は最大100Gbps、EBS帯域は最大60Gbpsを提供します。用途としては高ランダムIOPSが求められるI/O集約型やレイテンシー敏感ワークロード（OLTPデータベース、NoSQL、検索、キャッシュ、メタデータサービス、小〜中規模データセットのリアルタイム処理等）に最適化されています。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド/インフラエンジニア、データベース管理者、SRE、アプリケーション開発者
  • 利用シーン: 高ランダムIOPS・低レイテンシを必要とするOLTPデータベース、NoSQLストア、検索インデックス、メタデータサービス、リアルタイム分析やキャッシュ層
  • 運用効果: より低いストレージレイテンシと安定したI/O性能によりトランザクション遅延やスロットリングが減少、I4i比での計算/価格性能改善により同等性能をより低コストで達成可能

技術的な注意点 ​

  • リージョン制限: 本発表は Asia Pacific (Thailand) と Israel (Tel Aviv) 向けの拡張。その他リージョンでの提供状況は別途確認してください。
  • OS/ドライバ: Nitro SSDやENA/NVMeデバイスを利用するため、最新のLinuxカーネル（NVMe/ENAサポート）や対応ドライバが必要です。古いAMIsではドライバ更新が必要な場合があります。
  • IAM権限: EC2の起動・ネットワーク設定・EBS操作に関する標準的なEC2権限が必要です。ベアメタルや専用ホスト利用時は追加の権限／設定確認を推奨します。
  • クォータ/キャパシティ: 新しいインスタンスタイプはアカウントのvCPUクォータに影響します。必要に応じてService Quotasから増枠申請してください。またAZごとの容量制限で起動できない場合があります。
  • ベアメタル注意: ベアメタルサイズはハイパーバイザ機能（例: Nitro Enclaves等）の一部機能が利用できない場合があります。仮想とベアメタルでの機能差は事前確認してください。
  • コスト: インスタンス料金はリージョンごとに異なります。I7iはI4iより価格性能比が改善されていますが、絶対コストはインスタンスタイプ／サイズごとに異なるため、稼働コストは料金ページで確認してください。
  • EBS/ローカルストレージ: 最大45TBのNVMeローカルストレージはインスタンス料金に含まれる構成が多いものの、永続性・耐障害性の要件に応じてEBSやレプリケーション設計が必要です。

参考情報 ​

[SageMaker] Amazon SageMaker AI serverless model customization now supports full fine-tuning ​

概要 ​

Amazon SageMakerのサーバーレスモデルカスタマイズで、25以上のオープンソースモデルに対する「フルファインチューニング（全パラメータ更新）」がサポートされました。サーバーレスでインフラ管理不要に全パラメータを更新して深くドメイン適応できます。

変更内容・新機能の詳細 ​

従来のLoRAのようなパラメータ効率化手法（モデルの一部だけを更新）に加え、SageMakerのサーバーレスモデルカスタマイズでモデル内の全パラメータを更新するフルファインチューニングが可能になりました。対応モデルはgpt-oss、Gemma、Llama、Nemotron、Qwenなどのファミリーを含む25+のオープンソースモデルです。フルファインチューニングにより専門用語、複雑な出力形式、推論パターンや大規模プロプライエタリデータに基づく内部知識の学習など、表層的なスタイル適応を越えた高度な能力獲得が期待できます。サーバーレスはインフラのプロビジョニングやトレーニングオーケストレーションをSageMaker側で管理するため、利用者はインフラ設定を行わずジョブを実行でき、使用分だけ課金されます。利用開始はSageMaker StudioのJumpStart→Modelsページからカスタマイズジョブを起動するか、SageMaker Python SDK経由で行います。現在の提供リージョンは米東（N. Virginia）、米西（Oregon）、アジアパシフィック（東京）、欧州（アイルランド）です。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、MLプラットフォームチーム、データサイエンティスト
  • 利用シーンまたは効果: ドメイン特化モデルの構築（専門用語や複雑な出力仕様を要するタスク）、企業内大規模データを用いたモデルの内部知識注入、カスタム推論ロジックや複雑なフォーマット生成の習得
  • 運用効果: サーバーレスでインフラ管理負荷を削減しつつ深い適応を実現。小規模なLoRAでは得られない精度向上やタスク固有の挙動獲得が可能
  • コスト影響: フルファインチューニングは計算量が多くLoRA等より費用が高くなる傾向。サーバーレスは使用量課金だがトレーニング時間・リソースに応じたコスト増を見込む必要あり

技術的な注意点 ​

  • IAM権限: SageMakerのジョブ作成/管理権限に加え、S3アクセス（データ・アーティファクト格納）、CloudWatchログ、KMS（暗号化使用時）、必要に応じてECRアクセス等の権限を実行ロールに付与してください
  • リージョン制限: 提供リージョンは US East (N. Virginia), US West (Oregon), Asia Pacific (Tokyo), Europe (Ireland) のみ（記事公開時点）。他リージョンでは未対応の可能性があります
  • モデル互換性: フルファインチューニング可能なモデルは限定リストがあるため、対象モデルを事前にドキュメントで確認してください
  • トレーニング制約: フル更新は計算・メモリ負荷が高くなるため、トレーニング時間・バッチサイズ・混合精度やチェックポイント保存戦略を設計する必要があります。サーバーレス環境には同時実行や最大リソース量の制約がある可能性があるため、分散（マルチノード）トレーニングの可否やスケール要件を事前に確認してください
  • データ保護: 機密データを用いる場合はS3バケットのアクセス制御・暗号化・監査設定を行い、必要に応じてVPCエンドポイントやプライベート通信を検討してください
  • コスト管理: 長時間のフルチューニングは高額になるため、サンプルデータや小規模で検証→段階的スケールの戦略を推奨します
  • その他: 開始方法はSageMaker StudioのJumpStart→Modelsを使うかSageMaker Python SDKでジョブを起動します。詳細なAPI/パラメータやサポートモデル一覧は公式ドキュメントで確認してください

参考情報 ​

[Aurora] AWS Transform for full-stack Windows modernization now supports offline schema transformation to Aurora PostgreSQL ​

概要 ​

AWS Transform for full-stack Windows modernization がオフラインソース変換を一般提供しました。SQL Server のライブ接続を不要に、DDL ファイルをアップロードするだけで Aurora PostgreSQL 向けのスキーマ・コード変換と検証が実行できます。

変更内容・新機能の詳細 ​

オフラインソース変換では、SQL Server の Data Definition Language (DDL) ファイルを直接アップロードして、テーブル・スキーマ・ストアドプロシージャや関数などのコードオブジェクトを Aurora PostgreSQL 互換に自動変換します。ストレージオブジェクトの変換は AWS DMS を活用し、コードオブジェクト（T-SQL のストアドプロシージャ等）はエージェント的・対話的な体験で解析・変換されます。変換プロセスは複雑さ評価、カスタマイズ可能な変換プラン生成、機能等価性の検証、および変換後のスキーマを Aurora PostgreSQL にデプロイするまでを含みます。さらに、同一ワークフローで依存する .NET アプリケーション側の修正も行い、接続文字列、ADO.NET および Entity Framework のデータアクセス呼び出しを PostgreSQL 互換に更新します。残る変換課題はウェブコンソール上で反復的に修正可能で、AWS Transform MCP サーバ経由で好みの IDE にハンドオフして詳細な手直しを行えます。合成データワークフローにより、Aurora PostgreSQL にテストデータを投入してエンドツーエンドの動作検証を行うことも可能です。現在、オフライン変換は米国東部（バージニア北部）リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: レガシーの Microsoft SQL Server と .NET アプリケーションを Aurora PostgreSQL/.NET (PostgreSQL対応) にモダナイズしたいエンタープライズ、DBA、クラウド移行チーム
  • 利用シーンまたは効果: オンプレやネットワーク分離された環境でライブ DB 接続なしにスキーマ・ストアドプロシージャを解析・変換し、移行計画の早期作成と工数見積が可能
  • 運用効果: 変換の自動化と機能等価性検証により手作業を削減、.NET 側の接続・アクセス呼び出しも自動更新されるためアプリ側の改修工数を低減
  • 移行リスク低減: 合成データによる検証フローで実運用前にアプリの振る舞い確認ができ、移行後の不具合検出を早期化

技術的な注意点 ​

  • IAM権限: DDLアップロード、S3、DMS、Aurora 作成/変更、Transform コンソール/ MCP 利用に必要な権限が必要です。事前に最小権限ポリシーを確認してください
  • リージョン制限: GA 時点では US East (N. Virginia) のみ利用可能です。他リージョン展開は今後の対応を確認してください
  • データ移行とテストデータ: オフライン変換はスキーマとコード変換が中心。実データの移行は別途 AWS DMS などを用いる必要があります。合成データワークフローはテスト目的で提供されますが本番データの完全な代替ではありません
  • T-SQL と機能制約: 複雑な T-SQL 構文、拡張機能、CLR ストアドプロシージャや特定の SQL Server 固有機能は自動変換できない場合があり、手動対応が必要です。機能等価性の検証と手直しが推奨されます
  • .NET/EF 互換性: ADO.NET／Entity Framework の呼び出し自動変換を支援しますが、使用している EF バージョンやカスタムデータアクセス実装によっては追加修正が必要です
  • ツール連携: コンソール上での対話的修正と、MCP サーバ経由で IDE へハンドオフ可能。CI/CD や既存のコードレビューワークフローに組み込むことを検討してください
  • コスト: AWS Transform の利用料（該当する場合）に加え、Aurora インスタンス、DMS、S3 ストレージ、データ転送、MCP サーバ稼働分のコストが発生します。事前にコスト見積を行ってください

参考情報 ​

[WAF] AWS WAF now supports Miggo Security managed rule groups for emerging threats and AI/ML application protection ​

概要 ​

AWS WAF が Miggo Security 提供の 2 種類のマネージドルールグループ（High Emerging Application Threats、AI/ML Application Protection）を AWS Marketplace 経由でサポート開始しました。これにより、活発に悪用されている脆弱性や生成AI関連スタック向けの攻撃から継続的に防御できます。

変更内容・新機能の詳細 ​

Miggo Security の2つのパートナーマネージドルールグループが AWS WAF（WAFv2）で利用可能になりました。各ルールグループは AWS Marketplace で購読し、AWS WAF コンソールから該当ルールグループを Web ACL に追加するだけで導入できます（追加設定不要）。 ・Miggo Rules for AWS WAF – High Emerging Application Threats: 公開済みの PoC（Proof‑of‑Concept）や実際に悪用が確認されている脆弱性、CISA の KEV（Known Exploited Vulnerabilities）カタログに含まれる項目など、現在アクティブに攻撃対象となっている脆弱性にフォーカスします。 ・Miggo Rules for AWS WAF – AI/ML Application Protection: ジェネレーティブ AI のエージェントフレームワーク、LLM ゲートウェイ、モデルサービング基盤など、AI/ML アプリケーションスタック特有の脅威（モデルインジェクション、ワークフロー連鎖攻撃、プロンプト漏洩等）に対応するルールを提供します。 両ルールグループはバージョン管理に対応し、Miggo 側でルールの継続的更新が行われます。価格は Miggo が AWS Marketplace 上で設定し、使用に伴う課金は Marketplace 経由で発生します。導入前に対象リージョンやサービス対応状況は AWS Regional Services ページで確認してください。詳細は AWS WAF Developer Guide と AWS WAF コンソール、Marketplace の該当ページで確認できます。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、セキュリティエンジニア、SRE
  • 利用シーンまたは効果: 既知の悪用中の脆弱性や PoC が公開された脆弱性からの保護を迅速に導入可能。生成AI（LLM）を利用したサービスの攻撃面に特化した防御を追加できるため、モデルサービングやエージェント基盤のリスク低減に有効です。
  • 運用効果: ルール作成・保守の負荷を低減し、セキュリティチームは検出結果のチューニングやインシデント対応に集中できる。継続的なルール更新により新たな脅威に対する応答速度が向上します。
  • コスト影響: ルールグループは Miggo が Marketplace で課金設定するため追加費用が発生します（利用前に価格を確認してください）。

技術的な注意点 ​

  • IAM権限: Marketplace での購読や Web ACL 更新に必要な権限（例: wafv2:CreateWebACL, wafv2:UpdateWebACL, aws-marketplace:Subscribe 等）を事前に確認・付与してください。
  • リージョン制限: すべてのリージョンで提供されるとは限りません。対応リージョンは AWS Regional Services ページで確認してください。
  • コスト: ルールグループの利用は Miggo による追加課金が発生します。WAF の通常料金（リクエスト数、Web ACL 数）と合わせた総コストを評価してください。
  • WCU（WAF Capacity Units）: マネージドルールの追加は WCU を消費します。アカウント・Web ACL の WCU 上限に注意し、必要に応じてクオータ申請を行ってください。
  • バージョン管理: ルールグループはバージョン対応しています。自動更新の内容が運用に影響を与える可能性があるため、ステージング環境での動作確認や変更ログの確認を推奨します。
  • 互換性/優先度: 既存のカスタムルールや他のマネージドルールとのルール優先度（Rule priority）やアクション競合を確認し、期待するブロック/カウント動作になるよう設定してください。
  • テスト運用: 初回導入時はまず Count（モニタリング）モードで挙動を観察し、誤検知がないことを確認してから Block に移行することを推奨します。
  • Marketplace購読: AWS Marketplace での購読承認や利用規約同意が必要です。購読は管理者権限が必要になる場合があります。

参考情報 ​

[Config] AWS Config now supports 15 new resource types ​

概要 ​

AWS Configが15種類の追加リソースタイプをサポートしました。これにより、Amazon Bedrock、Amazon OpenSearch Serverless、Amazon SageMakerなどのリソースを含めた環境全体の検出・評価・監査・修復のカバレッジが拡張されます。

変更内容・新機能の詳細 ​

今回追加されたのは以下の15のCloudFormation形式のリソースタイプで、既存のConfig機能（記録、Configルール、アグリゲータ）で利用可能になります。もし「全てのリソースタイプの記録」を有効にしている場合は自動的に追跡が開始されます。追加リソース: AWS::AppSync::DomainName, AWS::OpenSearchServerless::AccessPolicy, AWS::Bedrock::AutomatedReasoningPolicy, AWS::OpenSearchServerless::LifecyclePolicy, AWS::Bedrock::AutomatedReasoningPolicyVersion, AWS::SageMaker::ImageVersion, AWS::Bedrock::Blueprint, AWS::SageMaker::InferenceComponent, AWS::Bedrock::DataAutomationProject, AWS::SageMaker::PartnerApp, AWS::BedrockAgentCore::ApiKeyCredentialProvider, AWS::SageMaker::Project, AWS::Connect::UserHierarchyGroup, AWS::SageMaker::Space, AWS::Glue::Trigger. 技術的効果として、これらリソースの構成履歴（コンフィグレーションアイテム）や変更監査、Configルールによる準拠性評価、複数アカウント/リージョンのアグリゲーションでの統合監視が可能になります。Configのコンソール／API（例: PutConfigurationRecorder、DescribeConfigurationRecorder、PutAggregationAuthorization、PutConfigRule等）からスコープやルールの対象にこれらのタイプを追加して運用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/コンプライアンスチーム、クラウド運用（SRE）/ガバナンス担当者、データサイエンス・機械学習基盤チーム
  • 利用シーンまたは効果: BedrockやSageMaker、OpenSearch Serverlessなどのリソースを含めた構成監査と準拠性チェック、複数アカウントやリージョンにまたがる統合状況把握
  • 運用効果: リソースカバレッジ拡大により未検出の設定変更や非準拠リソースの早期発見・是正が可能になり、監査対応やセキュリティ運用の精度が向上します
  • 導入の容易さ: 既に「全リソース記録」を有効にしている環境では追加作業不要。個別記録設定の場合は記録対象の更新が必要です

技術的な注意点 ​

  • IAM権限: Configの設定変更（例: config:PutConfigurationRecorder、config:PutDeliveryChannel、config:PutConfigRule、config:PutAggregationAuthorization）や、アグリゲータで他アカウント/リージョンの情報にアクセスするための適切なIAM権限を確認してください。対象サービスの読み取りAPI権限が別途必要になる場合があります。
  • リージョン制限: 記載の通り "リソースが利用可能な全リージョン" でサポートされます。サービス（特に Bedrock 等）はリージョン展開が限定的なため、実際の利用可否は各サービスのリージョン一覧を確認してください。
  • 記録設定: 設定で "recording group" が "ALL"). にしている場合は自動で追跡されます。個別にリソースタイプを指定している場合は、Configレコーダーの設定（コンソール/CLI/API）で新しいリソースタイプを追加してください。
  • Configルール/アグリゲータ: 新しいタイプはConfigルールのスコープやアグリゲータ集約対象として使用可能です。既存のルールや集約定義を見直し、必要に応じてスコープを更新してください。
  • コスト: 記録されるリソース数増加により、Configの課金対象（記録されたConfiguration Item数、ルール評価回数、アグリゲータ利用等）が増える可能性があります。コスト影響を事前に見積もり、必要ならフィルタリングやルールの最適化を検討してください。

参考情報 ​

[ECR] Amazon ECR now supports image layers up to 200 GB ​

概要 ​

Amazon ECRは、Docker pushでプッシュするイメージレイヤーの最大サイズを従来の制限から拡張し、単一レイヤーで最大200GBまで格納できるようになりました。これにより、大きなモデルやデータセット、重いバイナリ依存をイメージ内に直接含めやすくなります。

変更内容・新機能の詳細 ​

今回のアップデートにより、Docker push（Dockerレジストリプロトコル経由）でプッシュされたコンテナイメージの個々のレイヤーサイズ上限が200GBになりました。これまでは単一レイヤーのサイズ制約のためにデータを複数レイヤーに分割したり、外部ストレージにオフロードする必要がありましたが、その手間が軽減されます。ただし、AWS SDKやAWS CLIの低レベルAPI（UploadLayerPart API）を用いたアップロードは従来どおり50GBの上限が継続します。リージョン展開はAmazon ECRが提供されているほとんどの領域で有効ですが、Middle East (Bahrain) と Middle East (UAE) では未対応です。大容量レイヤーは、イメージのプッシュ/プルに要する時間やストレージコスト、イメージスキャン（脆弱性スキャン）やCI/CDパイプラインの処理時間に影響するため、運用面・コスト面での検討が必要です。詳細はECRプロダクトページ、ユーザーガイド、料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: コンテナを用いて大容量アセット（大規模言語モデル、ゲノミクスデータ、大型バイナリ）を直接配布・実行したい開発者、MLエンジニア、バイオインフォマティクスチーム
  • 利用シーンまたは効果: モデルや大容量データを単一レイヤーでイメージに含めることで、外部ストレージとの組合せやレイヤー分割のための運用工数を削減し、デプロイ手順を簡素化可能
  • 運用効果: イメージ管理が簡潔になりCI/CDのアーティファクト管理が容易化。ただしプッシュ/プル時間やスキャン時間は増加するためパイプラインやデプロイ戦略の見直しが必要
  • 制限事項: Docker push経由のみ200GBをサポート。UploadLayerPart API（AWS SDK/CLI経由）は引き続き50GB上限
  • リージョン影響: ほとんどのリージョンで有効だが、Middle East (Bahrain) と Middle East (UAE) は未対応

技術的な注意点 ​

  • IAM権限: 通常のECRプッシュ/プルに必要な権限（ecr:PutImage / ecr:InitiateLayerUpload / ecr:UploadLayerPart / ecr:CompleteLayerUpload 等）をCI/CD実行主体に付与してください
  • API制限: Docker pushでの200GBサポートはレジストリプロトコルを使用した経路に限定されます。AWS SDK/CLIのUploadLayerPart APIは依然50GBが上限のため、大容量レイヤーを扱う場合はCI環境でDockerクライアントを使ってプッシュする必要があります
  • リージョン制限: 全リージョンで提供されていますが、Middle East (Bahrain) と Middle East (UAE) では未対応です。利用前に対象リージョンを確認してください
  • コスト: ストレージ量増加によりECRの保管料金が増加します。さらに大きなイメージの頻繁なプルはデータ転送やネットワークコストを押し上げる可能性があるため料金ページで見積もりしてください
  • スキャン/セキュリティ: 大容量レイヤーはイメージスキャン（脆弱性検出）やサードパーティスキャナーの処理時間・メモリ要件を増加させ、最悪スキャン不能になる可能性があります。スキャンの制限やタイムアウトを事前に確認し、必要ならスキャン対象を調整してください
  • CI/CDとネットワーク: プッシュ/プルに要する時間が大幅に増えるため、CIジョブのタイムアウトや並列性、リトライ設定を調整してください。安定した帯域幅と障害対策（レジューム/再試行）を検討することを推奨します
  • コンテナランタイム互換性: Dockerおよび主要なコンテナランタイム（containerdなど）は大きなレイヤーを扱えますが、ランタイムやホストのディスク容量・一時キャッシュ（/var/lib/docker等）を必ず確認してください
  • 互換性検証: 実運用に投入する前にプッシュ/プル、スキャン、デプロイ（起動）をステージング環境で検証し、ボトルネックとコスト影響を評価してください

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026