AWS What's New Digest

Appearance

2026年04月10日 ​

[General] AWS RTB Fabric supports health checks for real-time bidding workloads ​

概要 ​

AWS RTB Fabricは、EC2 Auto Scalingグループ（ASG）を使うリアルタイムビディング（RTB）ワークロード向けにヘルスチェック機能を提供開始しました。RTB responder gatewayで稼働中のインスタンスの健全性を継続監視し、健全なインスタンスへ自動的にトラフィックをルーティングします。

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

今回の機能は、RTB responder gatewayに組み込まれたヘルスチェックにより、ブートストラップ中、ドレイン中、あるいは障害状態にあるインスタンスへ入札トラフィックが送られることを防ぎます。ヘルスチェックは継続的に実行され、RTB responder gateway上で設定（間隔、しきい値などの構成が可能な点が記事で言及されています）に基づき不健全なインスタンスを検出すると自動的にトラフィックを切り離します。これにより入札トランザクションの失敗を減らし、稼働率向上とエラー率低下、収益保護が期待できます。RTB Fabric自体はプライベートな高性能ネットワークを通じて単一桁ミリ秒のレイテンシを実現し、標準的なクラウドネットワーキングコストを最大で約80%削減できるとされています。本機能はEC2 Auto ScalingグループとRTB responder gatewayを組み合わせて利用する設計で、設定の詳細やパラメータはRTB Fabricのドキュメント／コンソールで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: AdTech事業者、リアルタイムビディングを運用する開発／SREチーム、広告パートナーとの連携を行うプラットフォーム事業者
  • 利用シーンまたは効果: RTBトラフィックをASG内の不健全インスタンスへ送らないことで入札失敗率を低減し、稼働率向上・収益損失の防止に寄与します
  • 運用効果: デプロイ／スケール時のブートストラップやドレイン処理中の落札失敗を削減できるため、SLAsの改善と監視/アラート運用の負荷軽減が期待できます
  • パートナー連携: Amazon Adsや主要SSP/パブリッシャーパートナーと低レイテンシで接続する環境を維持しやすくなります

技術的な注意点 ​

  • IAM権限: RTB Fabricのレスポンダーゲートウェイ設定やASG操作には適切なIAM権限が必要です（コンソール/APIでの設定変更権限やEC2/Auto Scaling操作権限を確認してください）
  • リージョン制限: 一般提供（GA）は US East (N. Virginia), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland) の各リージョンに限定されています
  • 互換性/前提条件: 機能利用にはRTB responder gateway経由の構成とEC2 Auto Scalingグループの利用が前提です。既存のロードバランサーやヘルスチェック設定との整合性を確認してください
  • 設定項目: ヘルスチェックの具体的なパラメータ（間隔、タイムアウト、連続不良閾値など）のサポート範囲はドキュメントで確認してください。記事では「構成可能」とありますが、チェックプロトコル（TCP/HTTP等）のサポートについては公式ドキュメント参照が必要です
  • コスト: RTB Fabricは「標準クラウドネットワーキングコストを最大80%削減」との記載がありますが、ヘルスチェック機能そのものの課金体系や追加費用の有無は製品ページ／料金表を確認してください
  • 監視/運用: ヘルスチェックに伴うログ・メトリクス（不健全判定回数、フェイルオーバー頻度等）を監視し、ASGのスケーリングポリシーやデプロイフローと合わせて運用設計を行ってください

参考情報 ​

[Backup] AWS Backup extends Amazon FSx support to 5 additional AWS Regions and expands cross-Region and cross-account copy to 14 AWS Regions ​

概要 ​

AWS BackupがAmazon FSx（Windows File Server、OpenZFS、Lustre）のバックアップ/復元サポートをさらに拡張しました。5つの追加リージョンでFSxのバックアップ管理が可能になり、14リージョン間でのクロスリージョン／クロスアカウントコピーが利用可能になりました。

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

今回の拡張では2点の強化があります。1) バックアップ／復元サポートの拡大：Amazon FSx for Windows File Server、Amazon FSx for OpenZFS、Amazon FSx for Lustre を対象に、以下5リージョンでAWS Backupによるバックアップと復元が可能になりました。Asia Pacific (Malaysia)、Asia Pacific (Taipei)、Asia Pacific (Thailand)、Canada West (Calgary)、Mexico (Central)。これにより、これらリージョン上のFSxファイルシステムをAWS Backupのポリシー、スケジュール、モニタリングで一元管理できます。2) クロスリージョン／クロスアカウントコピーの拡大：FSxバックアップのクロスリージョンおよびクロスアカウントコピーが以下14リージョンでサポートされます：Africa (Cape Town)、Asia Pacific (Hong Kong, Hyderabad, Jakarta, Malaysia, Melbourne, Taipei, Thailand)、Canada West (Calgary)、Europe (Milan, Spain, Zurich)、Israel (Tel Aviv)、Mexico (Central)。オンデマンドコピーと、バックアッププランにおけるコピー規則（定期コピー）が両方利用可能です。さらに、opt-inリージョンにおいてはAWS Backupの“論理的エアギャップ”となるバックアップボルト（Vault）へ格納して、不慮または悪意のある削除からの防御やランサムウェアからの復旧強化に活用できます。クロスリージョン／クロスアカウントコピーは、事業継続性・コンプライアンス要件に合わせたバックアップの配置ポリシーを構成するための機能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用チーム、バックアップ/DR担当、SRE、データ保護/コンプライアンス担当者
  • 利用シーン: 地理的冗長化（DR）、規制・コンプライアンスに伴うバックアップ保管、アカウント分離による保護、ランサムウェア対策のためのエアギャップ保管
  • 運用効果: 中央管理によるポリシー一貫性、オンデマンドおよび自動コピーでのバックアップ配置の自動化、異なるリージョン・アカウント間での復旧時間短縮とセキュリティ強化
  • スケーラビリティ: 複数リージョンへの自動コピーにより、拡張した地理的保護を容易に実現可能

技術的な注意点 ​

  • IAM権限: クロスアカウントコピーやRestoreを実行するためのAWS Backup関連アクション（StartCopyJobなど）と、ターゲットアカウントでの適切なロール/信頼ポリシーが必要です。クロスアカウントアクセス用にIAMロールの設定を準備してください。
  • KMS/暗号化: 暗号化にカスタムKMSキーを使用する場合、コピー先アカウント・リージョンでのKMSキー許可が必要です（キーのポリシーやグラントの設定を確認してください）。
  • リージョン制限: バックアップ/復元サポートが拡張されたのは記載の5リージョン（Malaysia、Taipei、Thailand、Calgary、Mexico Central）です。クロスリージョン／クロスアカウントコピーが可能な14リージョンは記事記載の一覧を参照してください。一部リージョンはopt-in（利用に申請が必要）です。詳細はAWS Backupの機能可用性ページで確認してください。
  • コスト: クロスリージョンコピーではデータ転送料金と追加ストレージ料金が発生します。コピーの頻度や保持期間によりコストが増加するため、コスト見積もりを行ってください。
  • 運用上の注意: コピールールやライフサイクル（保持ルール）を適切に設計し、誤った削除や保持期間違反を防ぐためにBackup Vault Lock等の保護機能の利用を検討してください。
  • 互換性/サポート対象: 対象はAmazon FSx for Windows File Server、Amazon FSx for OpenZFS、Amazon FSx for Lustreです。EFSや他のストレージサービスは別扱いです。
  • その他: 既存のバックアッププランへのコピールール追加や、オンデマンドでのコピー実行が可能です。復元テストを実施して実運用時の復旧手順を検証してください。

参考情報 ​

[Rds For Sql Server] Amazon RDS now supports the latest CU and GDR updates for Microsoft SQL Server ​

概要 ​

Amazon RDS for SQL Server が Microsoft の最新 Cumulative Update (CU) と General Distribution Release (GDR) をサポートしました。これにより複数の SQL Server バージョンでセキュリティ修正と安定性向上を適用できます。

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

サポート追加された RDS エンジン/SQL Server の組み合わせは以下の通りです：

  • SQL Server 2016 SP3 + GDR KB5077474 (RDS バージョン 13.00.6480.4.v1)
  • SQL Server 2017 CU31 + GDR KB5077471 (RDS バージョン 14.00.3520.4.v1)
  • SQL Server 2019 CU32 + GDR KB5077469 (RDS バージョン 15.00.4460.4.v1)
  • SQL Server 2022 CU24 KB5080999 (RDS バージョン 16.00.4245.2.v1) GDR パッチは CVE-2026-21262 と CVE-2026-26115 に関連する脆弱性を修正します。これらの更新には Microsoft の KB ドキュメントに記載された不具合修正や改善が含まれます。Amazon RDS 上のインスタンスへ適用するには、RDS マネジメントコンソール、または AWS SDK/CLI を使ってエンジンバージョンを更新してください。更新は同一メジャーバージョン内のマイナーバージョン適用に相当し、通常はインスタンスの再起動（ダウンタイム）を伴います。詳細は各 KB と Amazon RDS SQL Server のアップグレードガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: RDS for SQL Server を利用するデータベース管理者、SRE、セキュリティチーム
  • 利用シーン: セキュリティパッチ適用、定期的なCU/GDRアップデートによる安定性・互換性維持、脆弱性対応のための迅速なデプロイ
  • 運用効果: CVE-2026-21262/CVE-2026-26115 の修正による攻撃リスク低減、バグ修正とパフォーマンス改善による運用の安定化

技術的な注意点 ​

  • IAM権限: db:ModifyDBInstance 等の RDS 更新に必要な IAM 権限を事前に付与してください
  • バックアップ: 変更前にスナップショット取得を推奨します（ローリングバック目的）
  • ダウンタイム: エンジンバージョン適用はインスタンス再起動を伴うためダウンタイムが発生します。apply-immediately を有効にすると即時再起動、無効の場合は次回メンテナンスウィンドウで適用されます
  • メンテナンスウィンドウ: 影響を最小化するため、非ピーク時間のメンテナンスウィンドウでの適用を検討してください
  • 検証: 本番適用前にステージング環境でアプリケーション互換性とパフォーマンス検証を行ってください
  • レプリカ/マルチ AZ: リードレプリカやマルチ AZ 構成がある場合、フォールバックやフェイルオーバーの挙動を確認してください。Multi-AZ は切り替えでダウンタイムを短縮できますが、一時的な接続切断は発生します
  • バージョン互換性: これはマイナーバージョン（CU/GDR）の適用であり、メジャーバージョンアップグレードではありません。アプリケーション互換性の影響は少ない想定ですが KB を確認してください
  • リージョン制限: 一部リージョンで提供開始が遅れる場合があります。対象リージョンで利用可能かコンソールで確認してください
  • コスト: パッチ適用自体の追加料金は通常発生しませんが、ダウンタイムや検証作業に伴う運用コスト、長時間のテスト実行等のコストを考慮してください
  • CLI 例: aws rds modify-db-instance --db-instance-identifier <DB_IDENTIFIER> --engine-version <RDS_ENGINE_VERSION> --apply-immediately

参考情報 ​

[Timestream] Amazon Timestream for InfluxDB Now Supports Customer-Defined Maintenance Windows ​

概要 ​

Amazon Timestream for InfluxDB が顧客指定のメンテナンスウィンドウをサポートしました。週次の曜日と時刻（IANA タイムゾーン指定）で定期メンテナンスの実行時間を指定できます。

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

対応対象は InfluxDB 2 インスタンスと InfluxDB 3 クラスターの全エディションで、すべての Timestream for InfluxDB 提供リージョンで利用可能です。ユーザーは週次のメンテナンスウィンドウを「曜日＋時刻」形式で任意の IANA タイムゾーン（例: Asia/Tokyo, Europe/London, America/New_York）により指定できます。指定したタイムゾーンのサマータイム（DST）変動は自動で処理されるため手動調整は不要です。メンテナンスの種類は通常のルーチン処理（パッチ適用や軽微なアップデート等）を想定しており、メンテナンスウィンドウを指定しない場合は従来どおりサービス側が自動で実行タイミングを決定します。設定は Amazon Timestream for InfluxDB コンソール、AWS CLI、または AWS SDK を用いてリソース作成時や更新時に行えます。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、SRE、運用チーム、InfluxDB を利用するアプリケーション開発者
  • 利用シーン: トラフィックが少ない時間帯にのみメンテナンスを実行したい運用（深夜バッチ時間帯や非稼働ウィンドウ）
  • 運用効果: メンテナンスによる予期しない中断を避け、業務影響を最小化できる。サマータイム自動対応によりスケジュール管理工数が削減される

技術的な注意点 ​

  • IAM権限: リソースの作成・更新には Timestream for InfluxDB の管理操作を実行できる IAM 権限（コンソール/CLI/SDK の Create/Update 相当の権限）が必要です。必要に応じて最小権限ポリシーを検討してください。
  • リージョン制限: 記事の通り、Timestream for InfluxDB を提供している全リージョンで利用可能です。利用前に対象リージョンでサービス提供状況を確認してください。
  • コスト: メンテナンスウィンドウ指定自体に追加料金は通常発生しませんが、メンテナンス中の短時間の性能低下や一時的な接続中断により間接的な影響（再試行、バッチ遅延等）が発生する可能性があります。料金体系の変更は AWS のドキュメントで確認してください。
  • API/CLI: コンソールに加え AWS CLI / SDK 経由でウィンドウを設定可能です。パラメータ名や API はバージョンに依存するため、実装時は最新の SDK/CLI ドキュメントを参照してください。
  • 運用注意点: メンテナンスウィンドウは週次指定のため、より細かなスケジュール（例: 祝日対応や一時的な変更）は都度更新が必要です。サマータイム処理は自動ですが、運用ポリシーに合わせて確認してください。

参考情報 ​

[Bedrock] Amazon Bedrock now supports cost allocation by IAM user and role ​

概要 ​

Amazon Bedrockのモデル推論コストをIAMユーザー／ロール単位で配分・分析できるようになりました。Cost and Usage Report 2.0（CUR 2.0）とCost Explorerで、IAMプリンシパル（caller identity）に基づくコスト集計が可能です。

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

今回の機能では、IAMユーザーやIAMロールに付与したタグ（例：team、project、cost-center）をコスト配分タグとして有効化することで、Bedrockのモデル推論にかかる課金をIAMプリンシパル単位で可視化・集計できます。実装上は、Bedrockの呼び出しに含まれるcaller identity情報をCUR 2.0のラインアイテムおよびCost Explorerの集計キーに含められるようにし、Cost Explorerでタグフィルタを使った集計や、CUR 2.0の「Include caller identity (IAM principal) allocation data」オプションを有効にしたエクスポートで行単位の確認ができます。開始手順は主に3ステップです：1) IAMユーザー/ロールにタグを付与（例: team=AI、project=chatbot） 2) Billing and Cost Managementコンソールで該当タグをコスト配分タグとして有効化 3) CUR 2.0データエクスポート作成時にcaller identityデータを含める、またはCost Explorerで有効化済みタグでフィルタ/グルーピングする。CUR 2.0はラインアイテムレベルの詳細を提供するため、個別リクエストの帰属確認やチーム／アプリ別の精緻な費用配分が可能です。なお、この機能はAmazon Bedrockが利用可能なすべてのAWS商用リージョンで利用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドコスト管理者、SRE、MLプラットフォームチーム、FinOps/予算管理担当者
  • 利用シーンまたは効果: チーム／プロジェクト／アプリケーション別にBedrockの推論コストを正確に配分・分析できる（Cost Explorerのタグ集計やCUR 2.0の行単位分析により、コスト帰属の透明性が向上）
  • 運用効果: 負担割合の明確化、予算配賦・チャージバックの自動化、無駄な推論呼び出しやコスト異常の特定が容易になる

技術的な注意点 ​

  • IAM権限: IAMユーザー／ロールへタグを付与する権限（例: iam:TagUser、iam:TagRole相当）およびBillingコンソールでコスト配分タグを有効化する権限（aws-portal系の請求管理権限または同等の権限）が必要です。CUR作成にはS3バケット作成／書き込みやレポート配信用のIAMロール作成（iam:PassRole等）の権限も必要です。
  • リージョン制限: Amazon BedrockがサポートされているすべてのAWS商用リージョンで利用可能（リージョンごとのBedrock提供状況に依存）。
  • コスト: タグの有効化自体に追加料金は通常発生しませんが、CUR 2.0をS3へ配信する際のS3ストレージ費用や、Athena/Glueでの分析・クエリ実行時の料金、Cost Explorerの詳細レポート利用に伴う潜在的な分析コストには注意してください。
  • データ遅延と反映: タグの有効化やCUR/Catalog反映には反映遅延があり（通常数時間〜最大で24時間程度、請求期間の切り替わりによる遅延もあり得る）、過去のデータへ即時に遡って適用されない場合があります。
  • タグ仕様・制限: タグキー／値の長さ・文字種制限は通常のAWSタグ仕様に従います（例: キー最大128文字、値最大256文字など）。タグ整備（命名規則の統一）が重要です。
  • 対象コスト範囲: 本機能は主にBedrockのモデル推論に関する課金に紐づきます。ストレージや他サービスのコストは別途通常のタグ付け・配分ルールに従います。

参考情報 ​

[Opensearch Service] Amazon OpenSearch Service supports Managed Prometheus and agent tracing ​

概要 ​

Amazon OpenSearch ServiceがManaged Service for Prometheusとのネイティブ統合とAIエージェントトレーシング機能を追加し、メトリクス（Prometheus）、ログ、トレース、AIエージェントトレースをOpenSearch UIの単一ワークスペースで横断的に扱える統合オブザーバビリティを提供します。

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

今回のリリースでは、Amazon Managed Service for Prometheus（AMP）とOpenSearch Serviceのネイティブ統合を実装し、PromQLでのメトリクスLive QueryをOpenSearchのオブザーバビリティワークスペースから直接実行できるようになりました。データをOpenSearchへ重複格納することなく、Prometheusメトリクスをログ・トレースと組み合わせて可視化・相関分析できます。加えて、RED（Rate, Errors, Duration）指標に基づくアプリケーション監視ワークフローと、OpenTelemetry GenAIセマンティックコンベンションに準拠したAIエージェントトレーシングを導入。これにより、遅いトレースをアプリケーションログに紐付けたり、Prometheusメトリクスをサービスダッシュボードにオーバーレイしたり、LLMエージェントの実行フローを追跡することが容易になります。アーキテクチャはLive Queryベースのため、従来のプレミアム観測プラットフォームと比較してデータ重複や長期保存によるコストを抑制できます。機能はOpenSearch UIのオブザーバビリティワークスペースで利用可能で、記事時点で20のAWSリージョン（米国東部（バージニア北部、オハイオ）、米国西部（北カリフォルニア、オレゴン）、アジア太平洋（香港、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京）、ヨーロッパ（フランクフルト、アイルランド、ロンドン、ミラノ、パリ、スペイン、ストックホルム）、カナダ（中部）、南米（サンパウロ））で提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: Site Reliability Engineers、DevOps、Platform Engineeringチーム
  • 利用シーンまたは効果: Prometheusメトリクス、ログ、トレース、AIエージェントトレースを同一UIで相関させることで、パフォーマンス劣化原因の迅速な特定、サービスダッシュボードでのリアルタイム監視、LLMエージェント実行の可観測化が可能
  • 運用効果: データ重複の削減によるストレージコスト低減、ツール間のコンテキストスイッチ削減による対応速度向上、REDベースのワークフローでSLA監視とアラート精度が向上

技術的な注意点 ​

  • IAM権限: OpenSearch ServiceとManaged Service for Prometheus（AMP）双方へのアクセス許可が必要。PrometheusワークスペースやOpenSearchのObservability機能に対する読み取り／クエリ実行権限（必要に応じてサービスロールやクロスアカウント権限）を事前に設定してください
  • リージョン制限: 記事時点で20リージョンで提供（東京リージョン含む）。利用前に対象リージョンでの提供状況を確認してください
  • コスト: Live Queryによりデータ格納コストは削減されますが、Managed Prometheusのストレージ/クエリ料金およびOpenSearchのクエリ／ダッシュボード利用に伴う料金は発生します。クエリ頻度や保存ポリシーに応じた料金影響を評価してください
  • ネットワーク/接続: AMPワークスペースとOpenSearch間の接続やVPC設定、エンドポイントアクセス要件を確認する必要があります（VPCエンドポイントやセキュリティグループ設定が関係する場合あり）
  • インストルメンテーション: AIエージェントトレーシングを利用するには、OpenTelemetry準拠のエージェントやライブラリがGenAIセマンティックコンベンションに対応していることが望ましいです
  • 互換性/制限事項: 一部の地域や既存の監視フローで追加設定が必要になる可能性があります。導入前にテスト環境でクエリ性能や表示挙動を検証してください

参考情報 ​

[S3] Amazon S3 Lifecycle pauses actions on objects that are unable to replicate ​

概要 ​

Amazon S3のライフサイクルは、レプリケーションに失敗したオブジェクトに対する有効期限（Expiration）およびストレージクラス移行（Transition）を自動的に保留するようになりました。これにより、レプリケーション設定や権限を修正するまでオブジェクトが意図せず削除・移行されることを防げます。

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

従来はライフサイクルルールにマッチするオブジェクトがあれば、レプリケーション状態に関わらず期限切れやストレージクラス移行が実行され得ました。今回の変更により、S3は「レプリケーションに失敗した（failed）オブジェクト」に対してはExpirationおよびTransitionアクションの実行を一時停止します。失敗の原因は不適切なバケットポリシーやIAMロール、レプリケーション設定の誤りなどが主です。修正後はS3 Batch Replicationを使って一度失敗したオブジェクトを再レプリケートでき、レプリケーションが成功するとS3 Lifecycleが自動的に該当オブジェクトを設定されたルールに従って処理します。今回の挙動は既存・新規のLifecycle設定に自動的に適用され、AWS中国リージョンやAWS GovCloud (US) を含む37リージョンに展開されています（展開は段階的に行われており、数日で完了予定）。運用面では、レプリケーション状態（x-amz-replication-statusやS3 Inventory/レプリケーションメトリクスで確認）を監視し、失敗を検出してから権限や設定を修正→S3 Batch Replicationで再実行→正常化後にライフサイクルが適用されるフローが推奨されます。

影響範囲・利用シーン ​

  • 対象ユーザー: S3を利用するアプリケーション開発者、SRE/運用チーム、データ保管・バックアップ設計者
  • 利用シーン: クロスリージョン/クロスアカウントレプリケーションを設定しているバケットで、誤設定や権限不足によりオブジェクトが複製されない場合の保護
  • 運用効果: レプリケーション失敗による意図しないオブジェクト削除や早期のストレージクラス移行を防ぎ、データ消失リスクを低減。修正後にS3 Batch Replicationで再レプリケートすればライフサイクルが自動で適用されるため復旧運用が容易になる

技術的な注意点 ​

  • IAM権限: S3 Batch ReplicationやレプリケーションのためのIAMロール／バケットポリシーが正しく設定されていることを確認してください（PutObject/ReplicateObject等の権限が必要）
  • 確認方法: オブジェクトのレプリケーション状態はオブジェクトメタデータ（x-amz-replication-status）、S3 Inventoryのreplication-statusフィールド、またはS3 Replicationメトリクス/CloudWatchで確認可能です
  • リージョン制限: 変更は37リージョン（AWS China、AWS GovCloud (US)を含む）へ段階的に展開中です。お使いのリージョンでの展開状況を確認してください
  • コスト: S3 Batch Replicationの再実行はリクエスト/データ転送/ストレージに対する通常の料金が発生します。ライフサイクルの保留により一時的にストレージコストが増加する可能性があります
  • 既存設定への影響: 既存のLifecycle設定にも自動適用されるため、明示的な設定変更は不要ですが、レプリケーション失敗の検出と対応フローを運用に組み込む必要があります
  • その他: レプリケーション失敗の原因はACLやKMSキーのアクセス許可、バケット所有者の設定（Object Ownership）など多岐にわたるため、トラブルシューティングドキュメントを参照しつつ修正してください

参考情報 ​

[Aurora] Amazon RDS Blue/Green Deployments now supports Amazon RDS Proxy ​

概要 ​

Amazon RDS Blue/Green DeploymentsがAmazon RDS Proxyをサポートしました。これによりスイッチオーバー時のDNS伝播遅延が解消され、アプリケーションの復旧をより高速に行えるようになります。

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

Blue/Green Deploymentsは本番のBlue環境とは別にフルマネージドのステージング（Green）環境を作成し、変更を検証してからスイッチオーバーできます。今回の拡張で、単一リージョン構成のスイッチオーバー時にRDS Proxyがデータベースインスタンスを監視し、Green環境が新しい本番になると即座に接続先を切り替えます。これにより、従来のDNS TTLに伴う名前解決の遅延を回避し、アプリケーションの接続文字列やドライバの変更なしに迅速に切り替えられます。対応データベースは Amazon Aurora (MySQL/ PostgreSQL 互換)、Amazon RDS for MySQL、Amazon RDS for PostgreSQL、Amazon RDS for MariaDB で、RDS Proxyが利用可能な商用リージョンで提供されます。操作はAmazon RDSコンソールまたはAWS CLIから数クリック／コマンドで実行できます。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース運用者、SRE、クラウドアーキテクト、アプリケーション開発チーム
  • 利用シーンまたは効果: 本番DBの安全な入れ替え（Blue→Green）でアプリケーションのダウンタイム・切替遅延を最小化し、リリースやパッチ適用時の復旧時間を短縮
  • 運用効果: DNS伝播を待つ必要がなくなるためスイッチオーバー後の接続復旧が高速化され、再接続処理を簡素化できる
  • 対象範囲: Aurora(MySQL/PostgreSQL互換)、RDS for MySQL、RDS for PostgreSQL、RDS for MariaDB（RDS Proxyが利用可能な全商用リージョン）
  • 制約: 単一リージョンのBlue/GreenスイッチオーバーでRDS Proxyがアクティブに監視・リダイレクトを行います。リージョン依存のためRDS Proxy未提供リージョンでは利用不可

技術的な注意点 ​

  • IAM権限: Blue/Green DeploymentsおよびRDS Proxyの作成・管理に必要なRDSおよびIAM権限を事前に確認してください（rds:, rds-db:, iam:PassRole等を含むロールが必要になる場合があります）
  • リージョン制限: RDS Proxyが提供されている商用リージョンのみ対応。対象リージョンでRDS Proxyの可用性を確認してください
  • コスト: RDS Proxyは別途課金対象です。Proxyの持続料金と接続数に基づく課金が発生するため、コスト影響を評価してください
  • 接続面の注意: アプリケーション側のドライバ変更は不要ですが、長時間のセッションやトランザクション中の挙動（切断や再試行）があるため、アプリは再接続や短いトランザクション/リトライ戦略を持つことが望ましいです
  • ネットワーク/セキュリティ: RDS ProxyはVPC内に配置されます。セキュリティグループ、サブネット、ENIの設定や接続先ターゲットグループの設定が正しいことを確認してください
  • 対応DBエンジン: Aurora (MySQL/ PostgreSQL 互換), RDS for MySQL, RDS for PostgreSQL, RDS for MariaDB をサポートします
  • 運用手順: コンソール／CLIからBlue/Greenを作成する際にRDS Proxyを有効化する（既存のProxyをアタッチする）かを確認し、テストスイッチオーバーで切替動作を検証してください

参考情報 ​

[Marketplace] AWS Marketplace announces the Discovery API for programmatic access to catalog data ​

概要 ​

AWS MarketplaceがDiscovery APIを発表しました。マーケットプレイスの製品・価格情報（SaaS、AIエージェント/ツール、AMI、コンテナ、機械学習モデル等）をプログラム的に取得できるAPIです。

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

Discovery APIは、AWS Marketplaceカタログの製品説明、カテゴリ、公開価格・プライベートオファーの価格情報、オファー条件などのデータにプログラム的にアクセスするためのエンドポイントを提供します。これにより、購買者は社内ポータルや調達ツールへ最新のカタログ・価格情報を組み込み、比較・評価・承認フローを自動化できます。販売者やチャネルパートナーは自社サイトやストアフロント内でMarketplaceの出品情報や公開価格、権限のあるプライベートオファー情報を表示でき、ユーザーをパートナー体験内で比較・購入へ誘導できます。APIはAWS SDK経由で呼び出せ、呼び出しにはAWSアカウント側でのIAM権限設定が必要です。利用可能リージョンは US East (N. Virginia, us-east-1)、US West (Oregon, us-west-2)、Europe (Ireland, eu-west-1) です。返却されるデータはプログラムで処理しやすい構造を想定しており、内部ポータル、調達ワークフロー、カスタム検索/フィルタリング機能などに適用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: 購買担当者（プロキュアメント）、SaaS/ソフトウェア管理者、販売者およびチャネルパートナー
  • 利用シーン: 社内のソフトウェアカタログ同期、購買ポータルへの価格表示と比較、ベンダー評価ワークフローの自動化、パートナーストアフロントでの出品表示・価格提示
  • 運用効果: 手作業の価格更新やリスト更新を削減し、最新のオファー条件と価格を自動反映できるため、調達速度の向上と見積もり整合性の確保が可能

技術的な注意点 ​

  • IAM権限: API呼び出しに必要なMarketplace関連のIAM権限を付与する必要があります（詳細は公式リファレンスでポリシーを確認してください）。
  • リージョン制限: 利用可能リージョンは us-east-1, us-west-2, eu-west-1 のみ（記事公開時点）。他リージョンでは未対応です。
  • プライベートオファー可視性: プライベートオファーや特定の価格情報は、適切な認可（アカウント間の関係や権限）がないと取得できない可能性があります。認可スコープを確認してください。
  • レート制限とスロットリング: APIにはレート制限やスロットリングが存在する可能性があるため、大量取得時はリトライ/バックオフ設計を行ってください（詳細はリファレンス確認）。
  • コスト: 記事では追加のAPI利用料金について明示されていませんが、API呼び出しに伴う標準的なデータ転送費用や関連サービスのコストが発生する可能性があります。詳細は料金ページを確認してください。
  • SDK/実装: AWS SDK経由で呼び出せます。レスポンスのスキーマや利用可能なフィールド（product、offer、pricing等）はAPIリファレンスで確認し、キャッシュ戦略や更新頻度を設計してください。

参考情報 ​

[Bedrock] AWS Agent Registry for centralized agent discovery and governance is now available in Preview ​

概要 ​

AWS Agent Registry（Amazon Bedrock AgentCore経由）はプレビューで利用可能になりました。組織内のエージェント、ツール、MCPサーバー、カスタムリソースを中央で発見・管理するためのプライベートかつガバナンス対応のカタログ／ディスカバリーレイヤーです。

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

Agent Registryは組織内のAI資産（エージェント、スキル、ツール、MCPサーバー、カスタムリソース等）を一元的に登録・公開・検索できるサービスです。アクセスはAgentCoreコンソール、API（AWS CLI / AWS SDK）、またはMCPサーバーとしての提供によりIDEから直接クエリ／呼び出しが可能です。認証はIAMとOAuth（カスタムJWT）の両方をサポートします。リソースの登録はコンソール／APIで手動登録できるほか、URLベースのディスカバリ機能によりライブなMCPサーバーやエージェントエンドポイントからツールスキーマや能力記述などのメタデータを自動取得して登録できます。登録レコードは承認ワークフローを経て可視化され、管理者は承認前に公開を止めるなど既存の承認プロセスへ組み込んでガバナンスを強化できます。AWS CloudTrailによる操作の監査ログが取得でき、アクセスや管理操作のトレーサビリティを確保します。検索機能はキーワード検索に加えセマンティック検索（自然言語でユースケースを記述して検索）を備え、開発者は既存の能力を再利用して再構築を回避できます。プレビューはAgentCoreが提供される5リージョン（米国西部（オレゴン）、アジアパシフィック（東京）、アジアパシフィック（シドニー）、欧州（アイルランド）、米国東部（バージニア北部））で利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: ML/AI開発者、ソフトウェアエンジニア、SRE/運用チーム、セキュリティ/ガバナンス担当者
  • 利用シーンまたは効果: 組織内の既存エージェントやツールを発見して再利用することで開発工数と技術的負債を削減し、重複実装を回避できます
  • 運用効果: 承認ワークフローとCloudTrail監査によりガバナンスとコンプライアンスの強化が可能になり、管理者は公開前の検証を行えます
  • 開発者体験: IDEから直接MCPサーバーをクエリ／呼び出しできるため、ローカル開発や統合が容易になります
  • 組織的影響: 標準化されたカタログによりチーム間のコラボレーションが促進され、資産の再利用性が向上します

技術的な注意点 ​

  • プレビューの注意: 現時点ではPreview版のため機能やAPIが変更される可能性があります。商用利用の前に安定性とサポート状況を確認してください
  • IAM権限: Agent Registryの閲覧・登録・承認操作には適切なIAMポリシーが必要です。IAMとOAuthの両方式をサポートしますが、権限設計を明確にしてください
  • リージョン制限: プレビュー提供は米国西部（オレゴン）、米国東部（バージニア北部）、アジアパシフィック（東京・シドニー）、欧州（アイルランド）の5リージョンに限定されています
  • コスト: プレビュー中の料金モデルや付帯コストは異なる可能性があります。使用状況やデータ保管・APIコール等による追加コストを事前に確認してください
  • 承認ワークフロー連携: 既存の組織ワークフロー（チケットシステムや承認プロセス）に接続する場合はAPIベースの統合実装が必要です
  • ディスカバリ方式: URLベースの自動ディスカバリはライブなMCP/エージェントエンドポイントからメタデータを取得するため、エンドポイントのスキーマ準拠と可用性が重要です
  • 監査とログ: AWS CloudTrailによりアクセスと管理操作の監査が可能ですが、ログ保管方針と解析基盤も合わせて設計してください
  • 互換性: AgentCoreおよびMCPプロトコルに準拠したエージェント／ツールのみがフルに利用可能です。カスタム実装はメタデータの整備が必要になる場合があります

参考情報 ​

[Opensearch Service] Amazon OpenSearch Serverless now supports Zstandard (zstd) codec for index compression ​

概要 ​

Amazon OpenSearch ServerlessがZstandard (zstd) コーデックによるインデックス圧縮をサポートしました。LZ4と比べて最大約32%のインデックス容量削減が可能で、ストレージコストの低減とパフォーマンスのトレードオフを調整できます。

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

今回の追加により、Amazon OpenSearch ServerlessでインデックスのストレージにZstandard圧縮アルゴリズム（zstd / zstd_no_dict）が利用可能になりました。ユーザーは圧縮モードと圧縮レベルを指定して、ストレージ効率とインデックス/クエリパフォーマンスのバランスを調整できます。低い圧縮レベル（例：level 1）はインデクシングスループットやクエリ遅延への影響が小さく、ある程度の容量削減を実現します。高い圧縮レベル（例：level 6）はより高い圧縮率を達成しますが、インデクシング速度が低下するためスループットやレイテンシに影響を与える可能性があります。公式発表では、デフォルトのLZ4と比較して最大約32%のインデックスサイズ削減が期待できるとしています。設定はインデックス作成時のインデックス設定で指定します。大規模なログ分析、オブザーバビリティ、時系列データなどデータ量が多いワークロードで特に有効です。機能はAmazon OpenSearch Serverlessが提供されているすべてのAWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: 大量ログ/時系列データを扱うデータエンジニア、SRE、プラットフォームチーム
  • 利用シーンまたは効果: 大規模ログ分析、オブザーバビリティパイプライン、メトリクスや時系列データのストレージ最適化。ストレージ使用量の削減による管理ストレージコスト低減。
  • 運用効果: ストレージ容量あたりのデータ保持コストを削減可能。圧縮レベルをチューニングすることで、インデクシング性能とクエリレイテンシの許容範囲内でコスト最適化が図れる。
  • パフォーマンス影響: 低レベルでは影響小、 高レベルではインデクシングスループット低下やクエリ遅延増加が発生するため、ワークロードに応じた検証が必要。

技術的な注意点 ​

  • IAM権限: インデックス作成／設定変更に必要なOpenSearch Serverlessの権限を事前に確認してください（インデックス管理操作の権限が必要）。
  • 設定方法: コーデック（zstd / zstd_no_dict）と圧縮レベルはインデックス作成時のインデックス設定で指定します。既存インデックスのコーデック変更は通常再インデックスが必要になるため注意してください。
  • 圧縮レベルと性能: 例として level 1 は容量削減と性能維持のバランス、level 6 は最大圧縮（ただしインデクシング遅延増加）を狙う設定です。実稼働前にベンチマークで最適点を見つけてください。
  • モード: 提供されるモードは zstd と zstd_no_dict の2種類です。ワークロード特性に応じて選択してください。
  • コスト: ストレージコストは低下しますが、高い圧縮設定はCPU負荷やインデクシング時間の増加を招き、Serverless側のコンピュート利用（課金）や遅延の観点でコスト増加要因になる可能性があります。総合的なコスト比較を実施してください。
  • リージョン制限: Amazon OpenSearch ServerlessがサポートされているすべてのAWSリージョンで利用可能とされていますが、導入前に対象リージョンでの提供状況を確認してください。
  • モニタリング: 圧縮導入後はインデクシングスループット、クエリレイテンシ、CPU利用率、ストレージ使用量を監視し、必要に応じて圧縮レベルを調整してください。

参考情報 ​

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

Copyright © 2026