Skip to content

2026年07月02日

[Bedrock] Amazon Bedrock AgentCore increases default runtime quota limits

概要

Amazon Bedrock の AgentCore がデフォルトの実行時クォータを引き上げ、リージョンごとの同時セッション数やスループットが増加しました。これにより追加設定なしでより多くのエージェントを同時稼働させ、高スループットのワークロードに対応できます。

変更内容・新機能の詳細

今回の変更でデフォルトのランタイム・クォータが引き上げられました。米国東部(バージニア北部)および米国西部(オレゴン)では同時アクティブセッション数のデフォルト上限が最大5,000に増加し、その他の対応リージョンでは2,500に設定されます。全対応リージョンでエージェント間のやり取り(agent interactions)は秒間200、セッション作成は秒間25(新規セッション/秒)のデフォルトが適用されます。これらは各リージョン単位のデフォルトクォータであり、AgentCore を使ったエージェントベースのアプリケーションが追加設定なしで高い同時実行性・スループットを扱えるようになります。詳細な個別クォータや例外は AgentCore のクォータドキュメントおよび Developer Guide を参照してください。なお、デフォルトクォータは引き上げ可能(Service Quotas やサポート経由)で、実運用ではモデル呼び出し回数、CPU/メモリ、ネットワークなどの下流リソースとコスト増を考慮する必要があります。

影響範囲・利用シーン

  • 対象ユーザー: AIエージェントを大規模に運用・開発する開発者、SRE、プロダクトチーム
  • 利用シーン: 大量の同時会話セッションを必要とするチャットボット群、カスタマーサポートの自動応答、複数エージェントが並列に動作する自動化フロー
  • 運用効果: デフォルト設定でより多くのエージェントを同時稼働できるため、初期設定や個別クォータ申請なしでスケールできる範囲が拡大し、導入コスト・運用のハードルが低下する
  • 制約・留意点: セッション数・スループット増加に合わせてモデル呼び出し数、ネットワーク、課金が増えるためトラフィック設計とコスト管理が重要

技術的な注意点

  • IAM権限: AgentCore の管理やクォータ確認・申請には該当する IAM 権限(AgentCore/Bedrock 関連の操作、Service Quotas へのアクセス権)が必要です
  • リージョン制限: 米国東部(N. Virginia)/米国西部(Oregon)は同時アクティブセッション最大5,000、その他リージョンは2,500がデフォルトです。全リージョンで agent interactions=200/sec、new sessions=25/sec がデフォルトとなります
  • コスト: 同時セッションやリクエスト増加はモデル呼び出し回数とそれに伴う課金増を招きます。想定トラフィックでのコスト見積もりとモニタリングを行ってください
  • クォータ変更: デフォルト以上が必要な場合は Service Quotas コンソールまたはサポート経由で増加申請が可能です。各クォータはリージョン・アカウント単位で管理されます
  • モニタリング: CloudWatch などでセッション数、リクエストレート、エラー率を監視し、セッションライフサイクル(タイムアウト・切断処理)を適切に設計してください
  • 依存サービス: AgentCore のスケールは内部でのモデル呼び出し(Bedrock モデルや外部モデル)、ネットワーク、ストレージ等に依存します。下流サービスのボトルネックを確認してください

参考情報


[General] Amazon CloudWatch supports creating alarms from log queries

概要

Amazon CloudWatchで、CloudWatch Logsのクエリ結果に直接アラームを作成できるようになりました。これにより、メトリックフィルタやカスタムメトリクスを事前に作成することなく、ログ解析ワークフロー内でしきい値監視と通知が行えます。

変更内容・新機能の詳細

新機能では、CloudWatch Logs Insights等のログクエリに対して直接アラームを作成し、クエリ結果に基づくしきい値を指定できます。従来のようにログからメトリックフィルタやカスタムメトリクスを中間で作成する必要がなく、クエリで例えばサービス別のエラーレートを集計してしきい値超過時に通知を受ける、といった一連の流れを単一のワークフローで実現します。作成したログクエリベースのアラームは、Amazon SNS通知やAmazon EventBridgeへの連携を含む標準的なCloudWatchアラームのアクションをサポートします。アラームはCloudWatchコンソール、AWS CLI、AWS CloudFormation、各種AWS SDKから作成可能です。利用可能リージョンは全ての商用AWSリージョン(Middle East (UAE)、Middle East (Bahrain) を除く)です。詳細な課金やドキュメントはCloudWatchの料金ページおよび公式ドキュメントを参照してください。

影響範囲・利用シーン

  • 対象ユーザー: SRE、開発者、セキュリティ運用チーム、ログ分析担当者
  • 利用シーン: エラーレートや例外発生の急増検知、セキュリティイベントのパターン検出、サービス別のログ集計に基づくSLA監視
  • 運用効果: メトリックフィルタ/カスタムメトリクス作成の手間を排除し、ログ解析から監視・通知までのワークフローを短縮。設定工数と運用の複雑性が低減し、場合によってはカスタムメトリクスに関わるコスト削減が期待できる

技術的な注意点

  • IAM権限: CloudWatchおよびCloudWatch Logs関連権限が必要(例: logs:StartQuery、logs:GetQueryResults、cloudwatch:PutMetricAlarm 等)。
  • リージョン制限: 商用AWSリージョンで利用可能(Middle East (UAE)、Middle East (Bahrain) は未対応)。
  • コスト: CloudWatch Logs Insightsクエリ実行料やCloudWatchアラームに関する標準料金が適用される可能性があります。クエリ頻度やアラーム数による追加コストを確認してください。
  • インターフェース: コンソール、AWS CLI、CloudFormation、各種AWS SDKから作成可能。既存のメトリックフィルタやカスタムメトリクスを置き換えるか併用する設計が可能です。
  • 動作特性: ログの取り込み遅延やクエリ評価スケジュールにより通知の遅延が発生する場合があります。評価間隔やウィンドウ設定、ノイズ抑制(例: 再試行やアラームのステート遷移ポリシー)を設計時に考慮してください。
  • 通知内容: 記事によればアラーム通知にログコンテキストを含めることが可能とされますが、通知の具体的なペイロードやサンプルはドキュメントで確認してください。

参考情報


[ECS] ECS Service Connect now supports Zone-Aware routing

概要

Amazon ECS の Service Connect がゾーンアウェア(AZ優先)ルーティングに対応しました。これにより同一アベイラビリティゾーン内のエンドポイントへ優先的に通信を送ることで、クロスAZデータ転送コストとレイテンシーを低減します。

変更内容・新機能の詳細

ECS Service Connect は、同一 AZ 内のエンドポイントを優先してルーティングするゾーンアウェアルーティングを導入しました。リクエストは発信元タスクと同じ AZ にあるエンドポイントへ優先的に送られ、エンドポイントのスケールに合わせてトラフィックウェイトを動的に調整してターゲットサービス間の負荷を均衡します。ローカルのエンドポイントがヘルス不良または容量閾値を下回った場合は、自動的に他の健全な AZ にトラフィックを再配分して可用性を維持し、単一 AZ の過負荷を回避します。既存のサービス/新規サービスともにデフォルトで有効化されますが、既存サービスはこの動作を有効にするために一度の再デプロイ(サービス更新)が必要です。追加のインフラやアプリケーションコードの変更は不要です。クロスAZトラフィックパターンのモニタリングや導入効果の検証には、AZ メタデータを付与した Amazon VPC Flow Logs の活用が推奨されます。本機能は、ECS Service Connect がサポートされる全ての商用リージョンおよび AWS GovCloud (US) リージョンで利用可能で、サービス自体に対する追加料金は発生しません。

影響範囲・利用シーン

  • 対象ユーザー: コンテナアプリケーションを複数 AZ に分散して稼働している AWS ECS 利用者(マイクロサービスアーキテクチャ、SRE/運用チーム、コスト管理担当者)
  • 利用シーン: 同一リージョン内で AZ をまたぐサービス間通信が発生するマイクロサービス群において、通信レイテンシーとクロスAZデータ転送コストを低減したい場面
  • 運用効果: クロスAZ トラフィックの削減によるネットワークコスト低減とレイテンシー改善、ローカル AZ の障害時には自動フェイルオーバーして可用性を維持しつつ負荷分散が可能

技術的な注意点

  • IAM権限: サービスの再デプロイや更新を行うために ecs:UpdateService 等の ECS 操作権限、必要に応じて iam:PassRole 等の権限を確認してください
  • リージョン制限: ECS Service Connect をサポートする商用リージョンおよび AWS GovCloud (US) リージョンで利用可能です。リージョンごとの Service Connect サポート状況はドキュメントで確認してください
  • コスト: この機能自体に追加料金はかかりませんが、クロスAZ データ転送量の減少によりネットワークコストの削減が見込めます。VPC Flow Logs の長期保存や分析にかかるコストは別途発生します
  • 既存サービス対応: 既存のサービスはゾーンアウェアルーティングを有効にするために一度の再デプロイ(サービス更新)が必要です。再デプロイ作業の運用フローを事前に計画してください
  • 監視/検証: AZ メタデータ付きの Amazon VPC Flow Logs や CloudWatch 指標でクロスAZトラフィックや負荷分散の挙動を確認してください
  • ネットワーク構成: 追加のインフラ変更は不要ですが、セキュリティグループやサブネット、ルーティング(NACL 等)が AZ 間通信に影響しないか事前に確認してください

参考情報


[ECS] Amazon ECS now provides real-time deployment observability in the AWS Management Console

概要

Amazon ECSコンソールでデプロイのリアルタイム可視化が可能になりました。デプロイ進行状況や健全性、失敗時の診断をコンソール上で即時に確認できます。

変更内容・新機能の詳細

ECSコンソールにライブなデプロイメントタイムラインを追加しました。タイムラインは各フェーズ(開始、タスク起動、ヘルスチェック、終了など)やサービスイベント、タスクの起動/終了進捗を自動更新で表示します。デプロイ健全性は、デプロイメントサーキットブレーカーの状態(失敗閾値や失敗の近接状況のトラッキング)、デプロイ関連のアラーム状態、コンテナレベル/ロードバランサレベルのヘルスチェックをリアルタイムで確認できます。失敗したタスクはタイムライン上で直接参照でき、診断コンテキスト(エラーメッセージ等)と、関連するサービス(例:AWS CloudTrail)へのディープリンクを表示するため、複数ツールを行き来せずに原因特定が行えます。本機能は追加料金なしで利用可能で、全てのAWS商用リージョンおよびAWS GovCloud(US)で、ロールリングアップデート(rolling update)方式を用いる全てのAmazon ECSサービスに対して有効です。利用はECSコンソールの任意のサービス画面でDeploymentsタブを選択するだけです。

影響範囲・利用シーン

  • 対象ユーザー: コンテナ運用者、SRE、デベロッパー、運用チーム
  • 利用シーン: デプロイ中の進捗確認、失敗タスクの迅速な原因特定、デプロイ健全性(サーキットブレーカー/ヘルスチェック/アラーム)監視
  • 運用効果: 複数ツールを往復する必要が減り、障害対応時間(MTTR)が短縮される。デプロイ失敗の初動対応が迅速化され、ロールバックや修正を早く行える
  • 制約/範囲: ローリングアップデート(rolling update)デプロイに対して有効。CodeDeploy等を用いたBlue/Green型デプロイでは対象外の可能性がある

技術的な注意点

  • IAM権限: ECSサービス・タスク情報の閲覧権限(例: ecs:DescribeServices, ecs:ListTasks, ecs:DescribeTasks 等)や、コンソール内のディープリンク先(CloudTrail等)を参照する権限が必要です
  • リージョン制限: 全AWS商用リージョンおよびAWS GovCloud(US)で利用可能と発表されています(ただしリージョン単位でのロールアウト状況はコンソールで確認してください)
  • デプロイ方式: 本機能は rolling update デプロイタイプを使用するAmazon ECSサービスに対して提供されます。Blue/Green(CodeDeployベース)等の方式は対象外になる場合があります
  • コスト: 本機能自体に追加料金は発生しません。ただし詳細な診断やログ取得に伴うCloudWatch LogsやCloudTrailの利用料金が発生する可能性があります
  • API/CLI: 本発表はコンソールでの可視化に関するもので、同等の機能が即座にCLI/APIで提供されるとは限りません。自動化や外部監視には別途API確認が必要です

参考情報


[Artifact] AWS Artifact now includes Assurance Assistant for compliance inquiries

概要

AWS ArtifactにAI機能「Assurance Assistant」が追加され、AWSのコンプライアンス資料を根拠にした引用付きの回答を自動生成して、セキュリティ/コンプライアンスに関する問い合わせやベンダー評価(DDQ)を高速化できます。

変更内容・新機能の詳細

Assurance Assistantは、AWS Artifactコンソール内で利用できるAIベースの応答生成機能です。単一質問モードでは画面上で即時に引用付き回答を取得でき、アンケートアップロードモードではXLSX形式(業界標準のCAIQ、SIGやカスタムDDQを含む)を一括処理して回答を返します。すべての回答にはAWSの公式コンプライアンス文書(SOCレポート、ISO認証、C5アテステーションパッケージなど)への引用が付与され、ユーザーはソース文書と照合して独立した検証が可能です。出力は元ファイル形式で部分または全件エクスポートでき、引用の有無を選択できます。アクセス制御は二つのIAMマネージドポリシー(AWSArtifactComplianceInquiriesReadOnlyAccess、AWSArtifactComplianceInquiriesFullAccess)で管理します。追加料金は発生せず、商用AWSリージョンで利用可能です。AWS Artifactはグローバルにアクセス可能なサービスで、特定リージョンを選択する必要はありません。

影響範囲・利用シーン

  • 対象ユーザー: サードパーティリスク管理者、コンプライアンス担当者、セキュリティエンジニア、監査担当者
  • 利用シーン: ベンダー評価(VSA)やDDQの高速化、監査準備時の証拠収集、サービス別のコンプライアンス質問への迅速な回答取得
  • 運用効果: 手作業でのドキュメント検索や証拠突合せを削減し、評価・レビューの工数を短縮
  • 導入の容易さ: Artifactコンソールから利用可能で、IAMマネージドポリシーを割り当てるだけでアクセス制御が可能
  • 信頼性・検証: すべての回答に出典(SOC/ISO/C5等)が付くため、第三者検証が容易になる

技術的な注意点

  • IAM権限: AWSArtifactComplianceInquiriesReadOnlyAccess/AWSArtifactComplianceInquiriesFullAccessのいずれかを付与してアクセス制御します。必要に応じて最小権限のポリシー運用を検討してください。
  • リージョン制限: 商用の全リージョンで利用可能とされています。AWS Chinaや隔離されたパーティション(例: GovCloud)が対象外となる可能性があるため、該当アカウントでの可用性を確認してください。
  • コスト: Assurance Assistant自体は追加料金不要と明記されていますが、関連する運用(人員コスト、出力の保存や共有に伴うストレージ等)は別途発生する可能性があります。
  • データ取扱い: アップロードするアンケート(XLSX)には機密情報を含めない運用を推奨します。社内のデータ保護ポリシーに従い取り扱ってください。
  • ファイル形式: 入力はXLSX形式のアンケートをサポート。CAIQ、SIG、カスタムDDQ等のフォーマットに対応しています。
  • 出力と証拠: 回答は引用付きで出力可能。引用元のドキュメント(SOC報告書や認証文書)を必ず原本で検証してください。
  • 監査・ログ: アクセスや操作履歴はIAM管理下で制御してください。必要に応じてCloudTrail等の監査ログ設定を確認して記録ポリシーを整備してください。

参考情報


[Marketplace] AWS Partner Central now supports AWS Marketplace listings for co-selling

概要

AWS Partner Centralで、既存のAWS Marketplace出品(Solutions/Products)をコーセル(co-sell)機会に直接紐付けできるようになりました。これにより、マーケットプレースカタログとコーセル用ソリューションの分離管理が不要になります。

変更内容・新機能の詳細

パートナーはAWS Partner Centralの案件(Opportunity)作成・編集時に、既存のAWS Marketplace出品を直接紐付けできるようになりました。選択肢は(1)AWS Marketplace solutions and products、(2)AWS Marketplace solutions only、(3)AWS Marketplace products only、(4)Otherの4種類です。1件の案件につき最大でAWS Marketplace Solutionsを10件、AWS Marketplace Productsを10件まで紐付け可能です。紐付けはサブシディアリ(subsidiary)アカウント接続が確立されたAWSアカウント内の出品も含めて対応します。プログラムからはAWS Partner Central Selling APIを使って同等の操作が可能です。案件をCommittedまたはLaunchedに進めるには、AWS Marketplace Solution、AWS Marketplace Product、またはPartner Solutionのいずれかが関連付けられている必要があります。本機能はAWS Partner Central(コンソール)で一般提供(GA)されています。

影響範囲・利用シーン

  • 対象ユーザー: AWSパートナー(Marketplace出品者)、セールス/ビジネス開発チーム、パートナー運用担当
  • 利用シーン: 既存のMarketplace出品をコーセル案件に紐付けして商談進捗と実行状況(Fulfillment)を一元管理する場面
  • 運用効果: ソリューションの二重管理を廃止し、案件トラッキングとレポート精度が向上。API連携で自動化がしやすく、営業プロセスの効率化と追跡コスト削減が期待できる

技術的な注意点

  • IAM権限: Partner CentralおよびSelling APIを操作するための適切なIAMロール/権限(Partnerアカウントへのアクセス権)が必要です
  • リージョン制限: 機能はPartner CentralのコンソールでGAだが、Partner Centralの利用可否やリージョン別の制約を事前に確認してください
  • コスト: 機能自体に追加料金は明示されていませんが、Marketplaceの取引手数料やマーケットプレースに関する既存の課金ルールは適用されます
  • 上限: 1件の案件につき最大10件のMarketplace Solutionsと最大10件のMarketplace Productsを紐付け可能です
  • サブシディアリ対応: サブシディアリアカウント接続が確立されているアカウント内の出品も紐付け可能です
  • API: 同機能はAWS Partner Central Selling APIでプログラム的に利用可能。自動化や外部システム連携が可能です
  • 案件進行要件: OpportunityをCommittedまたはLaunchedに進めるには、Marketplace Solution/ProductまたはPartner Solutionのいずれかが必須です
  • 互換性/移行: 以前はコーセル用に別途作成したソリューションとMarketplace出品を個別管理していたため、既存ワークフローを見直して紐付け運用に移行する必要があります
  • その他: 詳細な操作手順やAPI仕様は公式ガイドを参照してください

参考情報


[RDS] Amazon RDS announces Cross-Region Automated Backups in four additional AWS Regions

概要

Amazon RDS の Cross-Region Automated Backups(自動バックアップのリージョン間複製)がさらに4つのAWSリージョンで利用可能になりました。これにより指定したリージョン間で自動バックアップ(スナップショットとトランザクションログ)をレプリケートし、別リージョンでのポイントインタイム復元が可能になります。

変更内容・新機能の詳細

今回の拡張で、次のリージョン間の自動バックアップ複製が可能になりました:Mexico (Central) ↔ Europe (Ireland) または US West (N. California)、Asia Pacific (Taipei) ↔ Asia Pacific (Singapore) または Asia Pacific (Tokyo)、Asia Pacific (New Zealand) ↔ Asia Pacific (Singapore) / Asia Pacific (Sydney) / Asia Pacific (Melbourne)、Asia Pacific (Thailand) ↔ Asia Pacific (Singapore) または Asia Pacific (Jakarta)。

技術的には、RDS は自動スナップショットとトランザクションログ(WAL 等)を選択したターゲットリージョンへ定期的にアップロード・レプリケートします。これにより、プライマリリージョンが利用不可になった場合には、ターゲットリージョン上でバックアップ保持期間内の任意のポイントに対して復元(Point-In-Time Restore: PITR)が可能です。トランザクションログは頻繁にアップロードされるため、数分以内のRPO(Recovery Point Objective)が達成可能とされています。

設定は Amazon RDS コンソールから数クリックで行えるほか、AWS CLI や各種 SDK からも操作可能です。本機能は Amazon RDS for PostgreSQL、MariaDB、MySQL、Db2、Oracle、Microsoft SQL Server の各エンジンで利用できます。復元・運用フローは通常の自動バックアップの復元と同様ですが、復元先がターゲット(セカンダリ)リージョンになる点が異なります。

影響範囲・利用シーン

  • 対象ユーザー: ミッションクリティカルなデータベースを運用するデータベース管理者、SRE、クラウドアーキテクト
  • 利用シーン: リージョン障害対策(DR)、リージョン間の復旧演習、リージョン移行準備、法的/運用上の地理的分散バックアップ
  • 運用効果: プライマリリージョン障害時に別リージョンで迅速なポイントインタイム復元が可能になり、RPO を数分単位に短縮できる
  • コスト影響: ターゲットリージョンでの追加ストレージ(複製バックアップ保存)とリージョン間データ転送料金が発生する可能性があるためコスト設計が必要

技術的な注意点

  • IAM権限: Cross-Region Automated Backups の設定には RDS のバックアップ/複製関連操作(rds:Enable* / rds:Modify* / rds:Create* 等)やターゲットリージョンへの操作権限が必要。具体的な最小権限は公式ドキュメントで確認してください。
  • リージョン制限: 本リリースで新たに対応したリージョン間のみ利用可能。全リージョン間で自動的に有効になるわけではないため、利用前に対象リージョンの対応状況を確認してください。
  • コスト: リージョン間データ転送費用と、ターゲットリージョンで保持されるバックアップのストレージ料金が発生します。トランザクションログ転送に伴う課金・ストレージ増加を見積もってください。
  • エンジン対応: PostgreSQL、MariaDB、MySQL、Db2、Oracle、SQL Server に対応。エンジンの特定バージョンや設定により挙動や制限がある可能性があるため、事前にドキュメントでサポート表を確認してください。
  • 運用上の注意: レプリケーションの初回はデータ量により時間がかかることがあるため、初期同期ウィンドウを見込んだ運用設計を行ってください。また復元手順・復旧時間(RTO)は検証しておくことを推奨します。
  • その他: Cross-Region Automated Backups は自動バックアップの複製を対象とし、手動スナップショットのコピーとは運用や課金が異なります。手動スナップショットは別途コピー機能を利用してください。

参考情報


[Bedrock] Amazon Bedrock AgentCore now available in four additional AWS Regions

概要

Amazon Bedrock AgentCoreがアジア太平洋(バンコク、マレーシア)およびヨーロッパ(ミラノ、スペイン)の4リージョンで利用可能になりました。これにより、これらのリージョンの顧客はエージェントをエンドユーザーに近い場所で低遅延に実行できます。

変更内容・新機能の詳細

AgentCoreはエージェントの構築・接続・最適化プラットフォームで、任意のフレームワークやモデルで素早くエージェントを提供するためのランタイム、ID/アクセス制御、ポリシー管理、セッション永続化(session persistence)、ツール接続、観測性(observability)などの機能を提供します。今回のリージョン拡張では、上記の主要機能がローンチ時点で利用可能となり、インフラ層でのセキュリティ強制によりエージェントがポリシーを迂回できない構成になっています。結果として、レイテンシの低減、データレジデンシや規制対応の容易化、エンタープライズシステム(内部API、データストア、SaaSツール等)との接続性向上が期待できます。料金や詳細なリージョン可用性はAgentCoreの価格ページおよびリージョンサポート一覧を参照してください。

影響範囲・利用シーン

  • 対象ユーザー: AI/MLエンジニア、アプリケーション開発者、SRE・運用チーム、エンタープライズIT担当者
  • 利用シーン: エンドユーザーに近い場所でのエージェント実行(チャットボット、業務自動化エージェント、コネクタ経由で社内システムと連携するワークフロー)
  • 運用効果: レイテンシ低下による応答性向上、データ所在要件への対応が容易化、監視・ポリシー適用による運用管理の一元化

技術的な注意点

  • IAM権限: AgentCoreおよびBedrockのAPIを呼び出すための適切なIAMポリシー(サービス固有の権限やサービスリンクドロール)が必要です。事前に最小権限での設定を確認してください。
  • リージョン制限: 本アップデートは Asia Pacific (Bangkok), Asia Pacific (Malaysia), Europe (Milan), Europe (Spain) に追加されたものです。その他リージョンでの可用性はAWSのリージョン製品一覧で確認してください。
  • コスト: AgentCoreの利用は料金が発生します。エージェント実行時間、接続数、データ転送等に基づく課金が想定されるため、既存の価格ページで見積もりを行ってください。
  • 互換性: 任意のモデル・フレームワークと連携可能とされていますが、具体的なモデルプロバイダやサードパーティツールとの統合要件はドキュメントで確認してください。
  • データ保護・コンプライアンス: データレジデンシやログの保管場所に関する要件がある場合は、リージョン選択とログ/メトリクスの保持設定を確認してください。

参考情報


[ECS] Amazon ECS now supports configurable deployment circuit breaker settings

概要

Amazon ECSのデプロイ時の「サーキットブレーカー(自動ロールバック)」の挙動を細かく設定できるようになりました。タスク失敗の閾値を固定数または割合で指定し、失敗のカウント方法を連続/累積のいずれかで選べます。

変更内容・新機能の詳細

ECSサービスのデプロイが失敗したと判定される条件をカスタマイズ可能になりました。具体的には以下を設定できます:

  • 閾値の指定方法:固定のタスク失敗数(例:3回)またはサービスのdesired task数に対する割合(例:10%)で閾値を設定。
  • 失敗カウントモデル:
    • 連続(consecutive)モデル:正常なタスクが起動するとカウンターをリセット。短時間に続けて起こる失敗のみを検知したい場合に有効。
    • 累積(cumulative)モデル:デプロイ全体を通して失敗を累積。途中で正常タスクが起動しても過去の失敗は残る。 閾値に到達するとECSは自動的に現在のデプロイをロールバックし、直前の成功したタスクセット(またはデプロイ)に戻します。新規サービスだけでなく既存のサービスにも適用でき、AWS Management Console、AWS CLI、SDK、CloudFormation、AWS CDK、Terraformから設定可能です。全リージョンのECS利用可能リージョンで利用できます。

影響範囲・利用シーン

  • 対象ユーザー: コンテナ化アプリケーションをECS上で運用・デプロイする開発者、SRE、プラットフォームエンジニア
  • 利用シーン: 開発/テスト環境で素早くロールバックしたい場合や、本番で起動時に一時的な失敗を許容して安定化を待ちたい場合など、環境ごとにロールバック閾値を変えたいケース
  • 運用効果: 不必要なダウンタイムの短縮(閾値を低くして即時ロールバック)や、誤検知による不必要なロールバックの削減(閾値を高くして一時的失敗を許容)を実現し、デプロイ安定性と開発スピードの両立が可能

技術的な注意点

  • IAM権限: デプロイ設定を変更するには ecs:UpdateService / ecs:CreateService 等の権限が必要。CloudFormationやCDK経由ではスタック更新権限も必要。
  • リージョン制限: 全てのAmazon ECS提供リージョンで利用可能と公開されています(リージョンごとのサービス提供状況は公式リージョン表で確認してください)。
  • コスト: この機能自体に追加料金はありませんが、頻繁なロールバックや再起動により実行時間・リトライが増え、間接的にリソース利用コストが上昇する可能性があります。
  • 互換性: EC2 と Fargate のいずれの起動タイプでも適用されます。既存のサービスに対して設定を適用するとデプロイ挙動が変わるため、事前にステージングで検証してください。
  • インフラ管理ツール: CloudFormation / CDK / Terraform での設定は各ツールのプロバイダ/ライブラリのバージョンで対応状況が異なるため、最新のリリースノートを確認のこと。
  • 運用注意: ロールバックは「直前の成功デプロイ」を復元するため、サービスに成功デプロイが存在しない状態では期待どおりの復元が行われない点に注意。累積モデルは長時間のデプロイで過去の小さな失敗が蓄積しやすいので閾値設定に注意。

参考情報


[Ec2] Amazon GuardDuty adds sensitive file modification threat detections

概要

Amazon GuardDuty の Runtime Monitoring に、EC2 インスタンスおよび EKS/ECS 上のコンテナで機密ファイルの改ざんを検出する3つの新しい脅威検出が追加されました。侵害後の持続化、権限昇格、検知回避の試みを早期に検出することを目的としています。

変更内容・新機能の詳細

今回追加された検出は Persistence:Runtime/SensitiveFileModified、PrivilegeEscalation:Runtime/SensitiveFileModified、DefenseEvasion:Runtime/SensitiveFileModified の3種類で、重要なシステムファイル(設定ファイル、認証関連設定、システムログなど)の変更を監視します。GuardDuty Runtime Monitoring は直接ファイル操作(open-for-write、rename、symlink、link、unlink の5種類)を観測し、コマンドラインやプロセスベースのモニタリングを回避する手法を使う攻撃でも検出できる点が特徴です。検出は相関分析に基づき、正当な管理操作と悪意ある操作を切り分けることで誤検知を低減します。各検出には対応する MITRE ATT&CK タクティクス(Persistence、Privilege Escalation、Defense Evasion)がマッピングされ、対応手順や修復案も含まれた実行可能なインテリジェンスが提供されます。これらの検出は、GuardDuty Runtime Monitoring を有効化している全ての顧客(Amazon EC2、Amazon EKS、Amazon ECS のワークロード対象)で利用可能で、新規ユーザー向けに30日間の無料トライアルが提供されます。プログラム的な更新を受け取るには Amazon GuardDuty の SNS トピックを購読できます。

影響範囲・利用シーン

  • 対象ユーザー: セキュリティチーム、DevSecOps、クラウドセキュリティアーキテクト
  • 利用シーンまたは効果: 侵害後の横展開や持続化、権限昇格、検知回避の試みを早期に検出し、迅速なインシデント対応を可能にする
  • 運用効果: 重要ファイルの直接的な操作を監視することでコマンドライン回避攻撃も検出でき、誤検知を低減した上で具体的な修復手順を提示し対応時間を短縮できる

技術的な注意点

  • 前提条件/導入: GuardDuty 本体および GuardDuty Runtime Monitoring を対象アカウントと対象ワークロード(EC2/EKS/ECS)で有効化する必要があります
  • IAM権限: GuardDuty 設定や SNS サブスクリプションを行うには適切な IAM 権限(AmazonGuardDutyFullAccess 等)および SNS の操作権限が必要です
  • リージョン制限: 利用可能なリージョンは GuardDuty Runtime Monitoring のサポート範囲に依存します。利用前に対象リージョンでサポートされているか確認してください
  • コスト: GuardDuty Runtime Monitoring の利用は追加料金の対象となる場合があります。新規ユーザー向けに30日間の無料トライアルがありますが、トライアル終了後の料金体系は事前確認してください
  • 検出方法の注意: 本機能はファイル操作(open-for-write、rename、symlink、link、unlink)を直接観測しているため、ファイルシステムレベルでの検出が中心です。運用上の正当な管理操作が検出対象となる場合があるため、検出ルールや相関分析によるチューニングが有効です
  • 通知と自動化: 検出は GuardDuty の Findings として出力されるため、EventBridge/SNS/Lambda 等と連携して自動応答や通知ワークフローを構築できます
  • 特記事項: 場合によりコンテナのランタイム設定や イメージ設計(不要な権限や writable な機密ファイル配置)との組合せで検出が発生しやすくなるため、セキュアなイメージ設計と最小権限を併用してください

参考情報


[General] AWS AppConfig launches managed experimentation tools for A/B testing

概要

AWS AppConfigに実験機能(A/Bテスト・多変量実験)がGAで追加されました。Amazonの実験ベストプラクティスを元にしたAI支援と、トラフィック割当・露出制御・ロックされた処理配分を備えたマネージドな実験基盤を提供します。

変更内容・新機能の詳細

AWS AppConfigの新しい実験ツールは、A/Bテストや多変量実験を専用インフラを構築せずに実行できる機能です。特徴としては:

  • A/Bおよびマルチバリアント実験の定義(フィーチャーバリエーション、処理割当)
  • ルールビルダーによる細かいオーディエンスターゲティング
  • コンソール/CLI/API/AWS CDKからの実行と管理
  • AIによる実験設計支援(Amazonの25年以上の実験知見に基づく推奨・統計的検証や検出力の確認)
  • 露出制御とロックされたトリートメント割当で信頼できる比較を実現
  • 実験結果の解析はAmazon CloudWatchや既存の解析ツールを利用可能
  • 実験終了後、勝者のバリエーションを標準のAppConfig安全ロールアウトで本番に昇格可能
  • 対応ワークロード:Amazon EC2、AWS Lambda、Amazon ECS、Amazon EKS、オンプレミス(AppConfig Agent経由) 実験自体はAppConfig内でセットアップ/実行され、観測指標の収集は既存のモニタリングパイプライン(CloudWatchや社内分析基盤)に依存します。統計的検出力やサンプリング設計に対するAI支援が提供されますが、最終的な指標定義と解析パイプラインはユーザー側の設定が必要です。

影響範囲・利用シーン

  • 対象ユーザー: プロダクトマネージャー、データサイエンティスト、SRE/運用チーム、開発チーム
  • 利用シーン: UI変更の評価、レコメンデーション/レコメンダモデル比較、AIモデルやプロンプトのAB比較、機能フラグを使った段階的リリースの効果検証
  • 運用効果: 実験基盤を自前で構築するコストと運用負担を削減し、トラフィック割当や露出制御でより信頼性の高い結果を短期間で得られる
  • 適用範囲: サーバーレスからコンテナ、VM、オンプレ環境まで横断的に実験を実行可能で、既存のデプロイ/ロールアウトワークフローと統合できる

技術的な注意点

  • IAM権限: AppConfigのExperiment関連API/アクション、CloudWatchメトリクス読み書き、実験対象リソース(Lambda、ECS等)を操作するための適切なIAM権限を付与してください。最小権限の原則を適用すること。
  • 観測指標: 実験で評価するKPIは事前に定義・計測可能にしておく必要があります(CloudWatchメトリクスやログ、外部解析ツールへのイベント送出の準備)。
  • リージョン制限: GA発表済みですが、リージョンごとの提供状況は異なる可能性があります。利用前に管理コンソールまたは公式ドキュメントで対象リージョンを確認してください。
  • オンプレ利用: オンプレミスで利用する場合はAppConfig Agentの導入とAWSへの接続(ネットワーク/認証)を整備してください。
  • 統計的注意点: AI支援で検出力推定は行われますが、サンプルサイズ、多重比較、セグメンテーションによるバイアスなどの設計上の注意はユーザー側で評価・対策が必要です。
  • コスト: AppConfigの利用料金に加え、CloudWatchのメトリクス・ログ料金、実験中に発生する追加リクエストやデータ転送、対象サービス(Lambda実行時間、EC2/ECS利用等)の増分コストが発生する可能性があります。料金見積りを事前に行ってください。
  • 既存ツールとの統合: 結果解析はCloudWatchか既存の分析基盤で行う前提のため、既存のダッシュボードやETLパイプラインとの連携実装が必要になる場合があります。

参考情報


[ECS] Amazon ECS Express Mode now supports custom task definitions

概要

Amazon ECS の Express Mode がカスタムタスク定義をサポートしました。既存のタスク定義をそのまま使って Express Mode の簡易デプロイ体験と組み合わせられます。

変更内容・新機能の詳細

今回の更新により、ECS Express Mode サービスに既存のカスタムタスク定義を紐付けできるようになりました。これにより observability/security 用のサイドカーコンテナ、カスタムコンテナヘルスチェック、ulimits や Linux のランタイム設定、FireLens を使ったカスタムログルーティングなど、タスクレベルでの高度な設定を保持したまま Express Mode の自動的なロードバランシング、ネットワーク設定、オートスケーリング、監視、デプロイ処理を活用できます。タスク定義は既存の CI/CD パイプラインや IaC(インフラストラクチャー・アズ・コード)ワークフローで作成・管理しているものを流用可能で、コンソール、AWS CLI、AWS SDK、およびサポートされる IaC ツール経由で Express Mode サービス作成時に指定できます。タスク定義を紐付け後は、タスク定義の更新による管理と Express Mode 側での管理を選んで運用できます。本機能は全リージョンで利用可能です。

影響範囲・利用シーン

  • 対象ユーザー: コンテナ開発者、プラットフォーム/DevOps エンジニア、SRE、CI/CD チーム
  • 利用シーン: 既存のタスク定義(サイドカー/ログルーター/カスタムヘルスチェック等)をそのまま使いつつ、Express Mode による自動化されたデプロイ/運用フローに乗せたい場合
  • 運用効果: 既存の運用・セキュリティ設定を維持しつつデプロイの簡素化が可能。CI/CD・IaC 資産の再利用により導入コストが低く、監視・ログ集約・セキュリティポリシーを崩さず高速にサービスを公開できる

技術的な注意点

  • IAM権限: タスク定義の登録・参照や Express Mode サービス作成に必要な ecs:RegisterTaskDefinition、ecs:CreateService/UpdateService 等の権限に加え、タスク実行に必要な iam:PassRole 等を事前に確認してください
  • リージョン制限: 公開情報では "全リージョンで利用可能" とされています(記事参照)。ただし各リージョンでの完全展開状況はコンソールで確認してください
  • コスト: サイドカーや追加コンテナによる vCPU/メモリ消費、FireLens 経由のログ転送先でのデータ取り込み課金、オートスケーリング増加によるリソースコスト増加に注意してください
  • 互換性: 基本的には標準のタスク定義パラメータを指定できますが、Express Mode が自動管理するネットワーキングやロードバランサー設定との整合性(ポートマッピングや networkMode など)を事前に検証してください
  • 管理モデル: タスク定義を更新してデプロイする方法と、Express Mode 側で直接操作する方法の両方が可能です。どちらを主に使うか運用ルールを定めてください
  • IaC/CI/CD: 既存の CI/CD(例: CodePipeline/GitHub Actions)や IaC(CloudFormation/CDK/Terraform)がタスク定義管理を行っている場合、Express Mode にタスク定義を渡すフローを組み込むことで既存資産を再利用できます。事前に小規模環境での動作確認を推奨します

参考情報


[EKS] Amazon EKS now supports Kubernetes version rollback

概要

Amazon EKSはKubernetesのアップグレード後に問題が発生した場合、アップグレードから7日以内であれば直前のマイナー版へロールバックできる機能を提供開始しました。コンソール、AWS CLI、SDKで実行でき、事前に互換性などの自動チェック(rollback readiness insights)を行います。

変更内容・新機能の詳細

今回の機能により、EKSクラスタを新しいKubernetesマイナー版へアップグレードした後に問題が見つかった場合、直前のマイナー版へ最大7日以内で戻すことが可能になります。ロールバックはAmazon EKSコンソール、AWS CLI、AWS SDKから開始できます。ロールバック実行前にEKSは「rollback readiness insights」として自動チェックを行い、API互換性、バージョンスキュー(コントロールプレーンとノード間のバージョン差)、EKSアドオン(coredns、kube-proxy等)の互換性、クラスタの健全性などを評価して問題を検出します。EKS Auto Modeを利用しているクラスタでは、EKSがワーカーノードのロールバック(必要な場合)をコントロールプレーンを戻す前に自動で行い、事前に設定したディスラプションコントロール(計画的な停止や同時置換数など)を尊重します。ロールバックは直前のマイナー版への戻しに限定され、それより前のバージョンへの遡及的なロールバックはサポートされません。料金は追加発生せず、Amazon EKSが利用可能なすべてのリージョンで提供されています。運用上は事前のバックアップ(etcd/ワークロードの状態、CRDやカスタムコントローラのバックアップ)やアドオン/Operatorの互換性確認を推奨します。

影響範囲・利用シーン

  • 対象ユーザー: クラスタ運用者、SRE、プラットフォームチーム、DevOpsエンジニア
  • 利用シーン: 本番でのマイナー版アップグレード検証後に不具合が発見された際の復旧(差し戻し)
  • 運用効果: アップグレードのリスク低減と、安全に実運用で新バージョンを検証して問題があれば即時に戻せる安全網の提供

技術的な注意点

  • IAM権限: クラスタの更新/管理に必要なIAM権限(例: eks:UpdateClusterVersion相当の操作権限やノードグループ管理権限)が必要です。ロールバックAPIを呼ぶ権限を付与してください。
  • リージョン制限: Amazon EKSが提供されているすべてのリージョンで利用可能と発表されていますが、利用開始前に対象リージョンでロールバックUI/APIが有効か確認してください。
  • コスト: ロールバック自体に追加料金は発生しません。ただし、ロールバック中の一時的なノード置換や容量増加による通常のEC2/EKSリソース料金は発生します。
  • ロールバックウィンドウ: アップグレードから最大7日以内に限定して直前のマイナー版へ戻せます(それ以前のバージョンへは戻せません)。
  • ノード管理: EKS Auto ModeではEKSがワーカーノードのロールバックを自動で処理しますが、セルフマネージドノードや一部の外部マネージドノードグループではワーカーノードの調整を自分で行う必要があります。
  • 互換性チェック: 自動チェックでAPI互換性、バージョンスキュー、アドオン互換性、クラスタヘルス等を確認します。チェックで問題が検出された場合、ロールバックが中断・注意喚起される可能性があります。
  • 事前準備: etcd相当の状態やCRD、カスタムコントローラ、外部アドオンのバックアップ、そしてPodDisruptionBudgetやDisruption制御の設定を見直しておくことを推奨します。
  • 運用フロー: ロールバックはコントロールプレーンとノードの順序やディスラプション設定に依存します。影響範囲を想定した上でメンテナンスウィンドウを設定してください。

参考情報


[General] Amazon Managed Service for Prometheus achieves FedRAMP High and DoD IL-4/5 authorization in AWS GovCloud (US)

概要

Amazon Managed Service for Prometheus (AMP) が AWS GovCloud (US) リージョンで FedRAMP High および DoD CC SRG IL-4/IL-5 の認可を取得しました。連邦機関や防衛関連の高いコンプライアンス要件を持つ workloads の監視に利用できます。

変更内容・新機能の詳細

Amazon Managed Service for Prometheus は Prometheus 互換のフルマネージド監視サービスで、インジェストとストレージを自動的にスケールして高カードinality(高次元ラベル組合せ)のメトリクスを扱えます。今回のアップデートにより、AWS GovCloud (US) リージョン内で AMP を利用する際に FedRAMP High および DoD CC SRG Impact Level 4/5 の承認を満たすことが確認されました。これにより、連邦政府機関や DoD 関連組織が機密性の高い環境で AMP を用いてメトリクス収集、アラート、クエリを行うことが可能になります。AMP は IAM、AWS KMS(暗号化)、PrivateLink/VPC エンドポイントなどの AWS セキュリティサービスと統合し、データへの安全なアクセスや保存をサポートします。利用開始や詳細については GovCloud 向けドキュメントおよび AWS アカウントチームへ問い合わせが案内されています。

影響範囲・利用シーン

  • 対象ユーザー: 連邦政府機関、公共部門、DoD 関連組織や FedRAMP High / DoD IL-4/5 準拠が必要なエンタープライズ担当者
  • 利用シーン: 機密度の高いクラウドワークロード(政府系サービス、機密データ処理環境、国防関連アプリ)のメトリクス収集・監視・アラートの実装
  • 運用効果: 認可取得により GovCloud (US) 内で公式に AMP を利用可能になり、コンプライアンス要件を満たした形でスケーラブルな Prometheus 互換監視を導入できる
  • リージョン影響: AWS GovCloud (US) のリージョンに制限されるため、商用リージョン(パブリックリージョン)からの移行・設計検討が必要

技術的な注意点

  • IAM権限: AMP へのアクセスには適切な IAM ポリシーを付与してください(読み取り/書き込みやクエリ実行の権限)。最小権限の原則を適用すること
  • リージョン制限: FedRAMP High / DoD IL-4/5 の認可は AWS GovCloud (US) リージョンに限定されています。GovCloud アカウントが必要です
  • データ保護と設定: KMS による暗号化、VPC エンドポイント(PrivateLink)を用いたプライベート接続、CloudTrail / Config による監査ログの有効化など、ベストプラクティスに従って構成してください。認可はサービス提供側の適合を示すもので、最終的なコンプライアンスは利用者の設定にも依存します(共有責任モデル)
  • コスト: メトリクスのインジェスト量、保存期間、クエリ実行量に応じた課金が発生します。高カードinality ワークロードはコストが増大する可能性があるため見積もりとモニタリングを行ってください。また、VPC エンドポイントやデータ転送にも追加コストが発生します
  • 運用上の注意: GovCloud 環境は商用 AWS アカウントとは分離された専用のアカウント/組織が必要です。導入前に AWS アカウント担当者と連携し、必要な承認手続きやアクセス方法を確認してください

参考情報


[General] AWS Security Agent now available in Asia Pacific (Mumbai), Asia Pacific (Singapore), and South America (São Paulo)

概要

AWS Security Agent(現在は AWS Continuum の一部)が、アジア太平洋(ムンバイ)、アジア太平洋(シンガポール)、南米(サンパウロ)の3リージョンで利用可能になりました。開発ライフサイクル前倒しでの脅威検出やコードレビュー、オンデマンドの侵入テストなどのコア機能にアクセスできます。

変更内容・新機能の詳細

今回のリージョン拡張により、対象リージョンの顧客は AWS Security Agent の主要機能を利用できます。主な機能は次のとおりです:

  • STRIDEベースの脅威モデリング(プレビュー): 設計ドキュメントやソースコードを解析して、設計段階での脅威・リスクを表出します。
  • フルリポジトリおよびプルリクエスト単位のコードレビュー(プレビュー): GitHub、GitLab、GitHub Enterprise Server、Bitbucket、Confluence に対してリポジトリ全体またはPRごとのレビューを実行し、管理されたコンプライアンスパックやカスタムセキュリティ要件を適用できます。
  • 開発者向け統合: 新しい IDE プラグイン(Kiro、Claude Code)および MCP 統合から脅威モデリング/コードレビュー/修復をトリガーできます。
  • オンデマンド侵入テスト: 再現可能な攻撃パスを含む検証済みの所見と、実装可能な修正案を提供し、修正後の再テストで効果を確認します。
  • シミュレーションによる検証機能は、現時点で US East (N. Virginia) のみ提供されています。 これらにより、開発スピードに合わせてセキュリティ専門知識をスケールさせ、設計→実装→検証の各フェーズで包括的なカバレッジを確保できます。プレビュー機能は機能制限や利用申請が必要な場合があるため、利用前にドキュメントと利用条件を確認してください。

影響範囲・利用シーン

  • 対象ユーザー: 開発チーム、セキュリティ/SREチーム、DevSecOpsエンジニア
  • 利用シーンまたは効果: 開発初期設計での脅威発見(STRIDE)、CI/CD プロセス内での自動コードレビュー、オンデマンドの侵入テストによる実運用前の検証
  • 運用効果: セキュリティ問題の早期検出と修復により手戻り削減、CI/CD に組み込むことでリリース速度を落とさずにセキュリティを担保可能

技術的な注意点

  • IAM権限: SCM(GitHub 等)、Confluence、CI/CD、AWS リソースへのアクセスに必要な権限(トークンやクロスアカウントロール設定含む)を事前に用意してください
  • リージョン制限: 機能はムンバイ、シンガポール、サンパウロで利用可能。ただし「シミュレーション検証」は現時点で US East (N. Virginia) のみ提供
  • コスト: Continuum/Security Agent の利用に伴う料金が発生する可能性があります。プレビュー機能の利用条件や侵入テストの費用も確認してください
  • プレビュー機能: STRIDE ベース脅威モデリングおよびフルリポジトリ/PR レベルのコードレビューはプレビュー扱いで、機能制限や利用申込が必要な場合があります
  • インテグレーション要件: GitHub/GitLab/Bitbucket 等のリポジトリ連携にてアクセストークンやWebhooks、エンタープライズサーバーの接続設定が必要です
  • データ保護/ログ: 解析対象のソースコードや設計文書がサービスに送信されるため、機密データの取り扱いポリシーを確認してください
  • ペネトレーションテスト: オンデマンド侵入テストは検証済みの所見と再テストを提供しますが、実施にあたっては対象範囲と同意が必要です

参考情報

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