AWS What's New Digest

Appearance

2026年02月27日 ​

[Opensearch Service] Amazon OpenSearch Service adds new insights for improved cluster stability ​

概要 ​

Amazon OpenSearch ServiceのCluster Insightsに「Cluster Overload」と「Suboptimal Sharding Strategy」の2つの新しいインサイトが追加され、シャード不均衡やクラスタ資源の過負荷を自動検出して影響対象と対処案を提示できるようになりました。OpenSearch 2.17以降で追加料金なしに利用可能です。

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

追加されたインサイトは次のとおりです。

  • Suboptimal Sharding Strategy: ノード数に対してシャード数が少なすぎるインデックスや、あるシャードが他と比べて不均衡に大きなデータ量を保持しているケースを検出します。これにより、クエリ負荷やデータ分散の偏りに起因するノード間の一部に過剰な負荷が集中する問題を可視化します。検出時は、影響を受けるインデックス／シャード、シャードサイズやノードあたりのシャード割当状況などのメトリクスを提示し、シャード数の再設計（リインデックス／ロールオーバーによる新規作成）、ILM（Index Lifecycle Management）やインデックス分割・統合の検討などの対策案を提示します。

  • Cluster Overload: CPU、メモリ、ディスクI/O、ディスクスループット、ディスク使用率などのリソース利用率が上昇し、リクエストのスロットリングや拒否に至る可能性がある状態を検出します。該当ノード／インデックスや該当リソース指標を示し、ノードのスケールアップやインスタンスタイプ変更、リソース割当の調整など、具体的な対処案（スケールアップの推奨を含む）を表示します。

両インサイトとも、従来のように複数のメトリクスやログを手作業で相関させる必要を減らし、OpenSearchのUI内で影響範囲と推奨アクションを一目で確認できるようにします。これらはOpenSearchバージョン2.17以降で利用可能で、OpenSearch UIが利用可能なリージョンで追加費用なく有効化できます。

影響範囲・利用シーン ​

  • 対象ユーザー: OpenSearchを運用するSRE/DevOps、プラットフォーム/検索エンジニア、データエンジニア
  • 利用シーン: クラスタ安定化のための定常監視、パフォーマンス劣化の早期検出、容量計画（キャパシティプランニング）
  • 運用効果: シャード不均衡や高負荷を早期に検出して対処できるため、クエリ遅延やスロットリング発生の低減、リードタイムの短縮、計画的なスケーリングによる可用性向上
  • コスト影響: インサイト自体は追加費用なし。ただし、推奨されるスケールアップやノード追加、リインデックス作業には追加コストが発生する可能性がある

技術的な注意点 ​

  • バージョン要件: OpenSearch 2.17以上が必要です
  • リージョン制限: OpenSearch UIが利用可能なリージョンで提供。利用可能リージョンは公式のサポートリージョン一覧を確認してください
  • IAM権限: Cluster InsightsやOpenSearchドメインのメトリクス表示に必要なIAMポリシー（ドメインの監視/読み取り権限）が必要です
  • 運用上の注意: プライマリシャード数の変更は直接変更できないため、シャード数調整は新規インデックス作成＋リインデックス（またはILM/ロールオーバー）で行う必要があります。これらの操作は一時的な負荷増やデータ移動を伴うため、メンテナンス計画が必要です
  • 推奨対応の特記事項: 一時的な不均衡はシャード再配置（allocation/cluster reroute）で対応可能ですが、根本的なシャード数の最適化はインデックス設計の見直しが必要です。スケールアップ推奨は迅速な保護手段ですが、コストとノード間バランスを考慮して実施してください
  • メトリクス連携: Cluster OverloadはCPU/メモリ/ディスクI/O/スループット/ディスク利用率など既存メトリクスを基に判断します。異常閾値やアラートの連携はCloudWatchや既存の監視フローと組み合わせることを推奨します
  • 追加コスト: インサイト自体は無料でも、推奨アクション（ノード追加やインスタンスタイプ変更、データ移行等）に係るAWS料金は発生します
  • その他: 提示される修復案は診断に基づく推奨であり、実行前にステージングでの検証を推奨します

参考情報 ​

[General] Oracle Database@AWS is now available in the Dublin AWS Region ​

概要 ​

Oracle Database@AWSがEU-West-1（ダブリン）リージョンで利用可能になりました（当面は1つのAZで提供）。OCIの管理下にあるOracle ExadataシステムをAWSデータセンター内で利用でき、既存のExadata/RAC環境をほぼそのまま移行できます。

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

Oracle Database@AWSは、Oracle Cloud Infrastructure（OCI）が管理するOracle ExadataをAWSのデータセンター内でホストし、AWS上でOracleの高性能データベース環境（Exadata、RAC相当）を提供するサービスです。今回の拡張によりEU-West-1（Dublin）リージョンで利用可能になり、当面は1つのAvailability Zoneから開始します。主な特徴は次の通りです：

  • ライク・フォー・ライク移行：オンプレミスのOracle ExadataやRAC環境を互換性の高い形でAWS上に移行可能。
  • OCI管理のExadata：データベース基盤はOCI側で管理されるExadataで提供されるため、Exadata固有の最適化・機能を維持。
  • AWSとの統合：AWS Key Management Service（KMS）を用いたデータ暗号化、AWS CloudWatchによる監視などAWSサービスと連携して運用可能。
  • 利用手順：OracleからAWS Marketplace経由でプライベートオファーを申請し、AWS Management Consoleでデータベースをセットアップ・利用します。
  • リージョン展開状況：本拡張により、Oracle Database@AWSは以下8リージョンで利用可能になりました：us-east-1（N. Virginia）、us-west-2（Oregon）、us-east-2（Ohio）、ca-central-1（Canada Central）、eu-central-1（Frankfurt）、eu-west-1（Dublin）、ap-northeast-1（Tokyo）、ap-southeast-2（Sydney）。

影響範囲・利用シーン ​

  • 対象ユーザー: オンプレミスでOracle Exadata／RACを運用している企業、データベース管理者、クラウド移行チーム
  • 利用シーン: データ主権要件のあるEU（アイルランド）内への移行、オンプレミスExadataからのリフト＆シフトや段階的クラウド移行
  • 運用効果: Exadata固有の性能を維持しつつAWSの運用エコシステム（KMS/CloudWatch等）と統合でき、移行工数の削減と運用一元化が期待できる
  • ガバナンス/コンプライアンス: ダブリンリージョンでの提供によりEU域内のデータ居住要件や規制対応が進めやすくなる

技術的な注意点 ​

  • IAM権限: AWS Marketplaceでのオファー申請やリソース作成に必要なIAM権限（Marketplaceの購買、EC2/VPC/KMS/CloudWatch関連の操作権限等）を事前に確認・付与してください
  • リージョン制限: EU-West-1（ダブリン）は当面1つのAZで提供されます。他のリージョンと機能・AZ冗長性が異なる可能性があります
  • コスト: Oracle側のプライベートオファー料金に加え、AWS側の利用料（データ転送、関連AWSサービスの利用料など）が発生します。見積はOracleのオファーで確認してください
  • ネットワーク/接続: レイテンシ要件やオンプレミス接続（Direct Connect/VPN）の設計は移行前に検証してください。データ転送コストにも注意が必要です
  • ライセンス/サポート: Oracleライセンス条項やサポートモデル（OracleとAWSの責任分界）を事前に確認してください
  • プロビジョニング: サービス利用にはOracleからのプライベートオファー申請が必要です。プロビジョニングや初期設定はAWS Management Console経由で行います
  • モニタリング/暗号化: CloudWatchでの監視やAWS KMSとの統合を利用する場合、適切なキー管理ポリシーとCloudWatch権限を設定してください

参考情報 ​

[RDS] Amazon RDS for PostgreSQL supports minor versions 18.3, 17.9, 16.13, 15.17, and 14.22 ​

概要 ​

Amazon RDS for PostgreSQL がマイナーバージョン 18.3、17.9、16.13、15.17、14.22 をサポート開始しました。これらは2026年2月12日の PostgreSQL コミュニティリリースに由来する回帰を修正し、既知のセキュリティ脆弱性やバグ修正を含みます。

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

サポート対象のマイナーバージョンは PostgreSQL 14.22、15.17、16.13、17.9、18.3 です。これらのリリースはコミュニティ側で報告された不具合とセキュリティ問題への修正を含み、RDS 上で利用可能になりました。アップグレードは自動マイナーアップグレード設定を有効にして、スケジュールされたメンテナンスウィンドウ中に実行できます。大規模運用においては、AWS Organizations の Upgrade Rollout Policy を用いて段階的にアカウント群へロールアウト（まず開発環境、その後本番環境）する運用が推奨されています。ダウンタイムを最小化したい場合は、物理レプリケーションを利用する Amazon RDS Blue/Green デプロイメントを使ってマイナーアップグレードを実施できます。また、AWS Management Console と AWS CLI の双方から作成・更新・バージョン指定ができます。価格とリージョン可用性は RDS for PostgreSQL の料金ページで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: PostgreSQL を RDS 上で運用するデベロッパー、DBA、SRE/運用チーム
  • 利用シーン: セキュリティ修正とバグフィックスの適用、マイナーバージョン管理（自動アップグレード／段階的ロールアウト／Blue/Green による無停止移行）
  • 運用効果: 既知の脆弱性やコミュニティで修正された不具合が解消され、安定性とセキュリティが向上。Upgrade Rollout Policy と自動化を組み合わせることで多数のデータベースの一括・段階的アップグレードが容易になり、検証済み環境へ先行適用してリスクを低減できる

技術的な注意点 ​

  • IAM権限: DB インスタンスの変更や Blue/Green 操作、Organizations ポリシー適用には適切な IAM 権限（rds:ModifyDBInstance、rds:CreateBlueGreenDeployment 等）が必要です
  • リージョン制限: 新しいマイナーバージョンの利用可否はリージョン毎に異なる可能性があります。利用前に対象リージョンでの提供状況を確認してください
  • コスト: Blue/Green デプロイメントや並行するレプリカの一時的作成は追加コストが発生します。自動アップグレード自体に直接料金は発生しませんが、運用方法により課金対象となるリソースが増加します
  • 自動アップグレード: 自動マイナーアップグレードを有効にするとメンテナンスウィンドウ中に自動で適用されます。事前検証が不十分だと想定外の動作変更が本番に適用されるリスクがあるため、段階的ロールアウトやテスト環境での検証を推奨します
  • Blue/Green とレプリケーション: Blue/Green を利用する場合、物理レプリケーションを使った切替が可能ですが、切替時の接続再確立や外部依存サービスとの互換性を確認してください
  • バックアップとテスト: アップグレード前にスナップショット取得とアプリケーション互換性テストを必ず行ってください。マイナーバージョンアップグレードは通常ロールバック（ダウングレード）がサポートされないため、復旧手順の確認が必要です
  • ダウングレード不可: RDS のマイナーバージョンアップグレードは一般にダウングレード（元のバージョンへ戻すこと）がサポートされないため、事前検証を行ってください

参考情報 ​

[ECS] Amazon ECS Managed Instances now integrates with Amazon EC2 Capacity Reservations ​

概要 ​

Amazon ECS Managed InstancesがAmazon EC2 Capacity Reservationsと統合され、ECSがインフラ管理を継続する一方で、予約済みキャパシティを利用した予測可能な可用性を確保できるようになりました。capacityOptionTypeに"reserved"を指定することで、予約キャパシティ優先の起動ポリシーを選べます。

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

技術的には、ECS Managed Instancesのcapacity providerに新しいcapacityOptionType=reservedオプションが追加され、これによりEC2 Capacity Reservations（CR）を利用してインスタンスを起動できます。reservation preferencesとして以下のいずれかを選択可能です。

  • reservations-only: 予約済みキャパシティのみにインスタンスを起動（最も予測可能）
  • reservations-first: まず予約を使い、足りない場合はオンデマンドにフォールバック（可用性とコストのバランス）
  • reservations-excluded: 予約を使用しない（既存の spot/on-demand オプションと併用） 設定はAWS マネジメントコンソール、AWS CLI、CloudFormation、SDKで行え、capacity reservation groupとreservation strategy（どの予約グループを優先するか等）を指定します。ECS側はインスタンスのスケーリング、タスク配置最適化、インフラの継続管理を行い、予約キャパシティの利用によりミッションクリティカルなワークロードの高可用性を高めます。本機能は全リージョンで利用可能とされています。

影響範囲・利用シーン ​

  • 対象ユーザー: コンテナ基盤を運用するプラットフォーム/SREチーム、ミッションクリティカルなECSワークロードのオーナー
  • 利用シーン: 高可用性が求められるバッチ処理・トランザクション系サービスや、需要ピーク時に確実にインスタンスを確保したい場面（例: セール、金融取引、ヘルスケア）
  • 運用効果: 予約キャパシティを用いることで起動失敗やキャパシティ不足のリスクが低減され、サービスの安定稼働が向上する
  • コスト／スケーラビリティ効果: reservations-onlyで最大の予測可能性を得られる一方、reservations-firstによりコスト効率（オンデマンドへのフォールバック）と可用性のバランスが取れる
  • 導入上の影響: 既存のECS Managed Instances設定へcapacityOptionType=reservedを追加することで段階的に移行可能。運用ポリシー（予約グループの管理、使用優先度）設計が必要

技術的な注意点 ​

  • IAM権限: ECSのCapacity ProviderやEC2 Capacity Reservationsを操作するための適切なIAM権限（ec2:CreateCapacityReservation, ec2:DescribeCapacityReservations, ecs:PutCapacityProvider等）が必要です
  • リージョン制限: 記事によれば "全リージョンで利用可能" とされていますが、実際の予約リソースや特定インスタンスタイプの可用性はリージョン/AZ依存です
  • コスト: Capacity Reservation自体は確保した時間分の課金対象となる可能性があるため（オンデマンド課金ベースで固定費が発生する場合あり）、コスト影響を事前に評価してください。reservations-onlyは柔軟性が下がることでスケール効率に影響する場合があります
  • キャパシティ予約の性質: EC2 Capacity ReservationsはAZ/インスタンスタイプ/プラットフォーム（例: Amazon Linux/Windows）に紐づくため、予約と一致しない要求では利用できません。予約のスコープが合致していることを確認してください
  • フォールバック/スケーリング挙動: reservations-firstでは予約が不足した場合にオンデマンドへ自動フォールバックしますが、reservations-onlyを選ぶと予約が枯渇した際にインスタンス起動が失敗してスケールアウトしない可能性があります
  • 設定方法: Console/CLI/CloudFormation/SDKからcapacityOptionType=reservedとcapacity reservation group、reservation strategyを指定してCapacity Providerを作成/更新します。既存のCapacity Providerとの互換性を確認してから変更してください
  • 運用注意: Capacity Reservationのライフサイクル管理（不要になった予約の削除、期間指定の確認）、および予約グループの命名/タグ付けポリシーを導入して管理運用を容易にしてください
  • 互換性: Spot/On-Demandの既存オプションと併用可能ですが、選択したreservation preferenceにより動作が変わります。Spotは依然として価格と可用性の変動リスクがあります

参考情報 ​

[General] AWS Marketplace now supports multiple purchases of SaaS and Professional Services products ​

概要 ​

AWS Marketplaceは、同一AWSアカウント内で同一のSaaSおよびProfessional Services製品を複数契約（Concurrent Agreements）できる機能を導入しました。これにより、従来の「製品ごとに1契約」という制約が撤廃され、複数の事業部門や拡張案件の即時取引が可能になります。

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

Concurrent Agreementsにより、同じAWSアカウントで同一SaaSまたはProfessional Services製品の複数の有効な契約（サブスクリプションや合意）が共存できるようになりました。これまではアカウントあたり製品ごとに1つのアクティブ契約しか持てなかったため、拡張（mid-term expansion）や複数事業部での個別調達に対してはセラー側での運用ワークアラウンドが必要でした。Professional Servicesリスティングについては本日よりデフォルトでConcurrent Agreementsが有効化され、セラーによる対応は不要です。SaaSリスティングについては、セラーがMarketplaceの統合を更新して「1アカウントに複数アクティブサブスクリプション」を扱えるようにする必要があります。具体的には：

  • サブスクリプション通知: 従来の通知方式からEventBridgeを利用した通知へ更新し、複数サブスクリプションのイベント処理を行えるようにする
  • エントitlement（権利）API: 各サブスクリプションごとのエントitlementを正しく発行・判別できる実装に対応する
  • Metering（課金）API: サブスクリプション単位での利用計測や課金報告を行えるように更新する 統合作業を完了したSaaSセラーは即時にオプトインしてConcurrent Agreementsを有効化できます。新規SaaS製品については2026年6月1日以降、Concurrent Agreementsサポートが必須となります。Concurrent AgreementsはAWS Marketplaceがサポートされる全リージョンで利用可能ですが、実際の購入はセラーが統合を完了しているSaaS製品のみ有効です。

影響範囲・利用シーン ​

  • 対象ユーザー: SaaS/Professional Servicesのセラー（販売事業者）および買い手（エンタープライズ、複数事業部を持つ組織、IT購買チーム）
  • 利用シーン: 中央管理された単一AWSアカウントで複数チームが独立した契約・価格で同一製品を導入する場合、既存契約の途中での機能/ライセンス拡張（mid-term expansion）、繰り返し購入や部門別請求のシナリオ
  • 運用効果: セラーは複数事業部をまたぐ案件のクローズが容易になり拡張を即時取引可能に。買い手は既存契約を壊さずに追加購入でき、従来のワークアラウンド（別アカウント発行や手動的な契約管理）を削減できる

技術的な注意点 ​

  • IAM権限: Marketplace関連API/EventBridgeへのアクセスやサブスクリプション管理に必要なIAM権限を確認・付与してください（セラー・買い手双方）
  • リージョン制限: 機能自体はMarketpaceサポート済みリージョンで利用可能ですが、SaaS製品の購入可否はセラー側の統合状況に依存します
  • コスト: 買い手側に直接の追加料金発生要因はありませんが、複数契約の許容により実際のライセンス費用や運用コストが増加する可能性があります。セラーは統合対応の開発コストが発生します
  • SaaS統合要件: サブスクリプション通知をEventBridgeへ変更、エントitlement APIとMetering APIの実装・テストを行い、複数サブスクリプションごとの識別・管理に対応する必要があります
  • 後方互換性: 既存サブスクリプションは維持されますが、サーバー側のロジックが複数契約を想定しているかを確認してください（例えば、アカウント→顧客IDのマッピングをサブスクリプション単位に変更する等）
  • リリーススケジュール: Professional Servicesは即時デフォルト有効、SaaSは統合完了セラーのオプトインで即時有効。2026-06-01以降は新規SaaS製品でのサポートが必須となります
  • テスト/検証: 本番公開前に複数サブスクリプションを想定したConformanceテストやEventBridgeイベントの処理確認、課金データの分離検証を実施してください

参考情報 ​

[Connect] Amazon Connect now supports dynamic dialing mode switching for outbound campaigns ​

概要 ​

Amazon Connectのアウトバウンドキャンペーンで、実行中にプレビュー（preview）と非プレビュー（progressive/predictive等の非プレビュー）ダイヤリングモードを切り替できる機能が一般提供されました。キャンペーンを停止せずにモード変更できるため、リアルタイムの業務要件やエージェント状況に応じた柔軟な運用が可能になります。

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

今回のGAリリースは「動的ダイヤリングモード切替（dynamic dialing mode switching）」のサポートを提供します。従来はキャンペーン開始後に設定したダイヤリングモードがロックされ、変更するにはキャンペーンの停止と再起動が必要でした。本機能により、実行中のキャンペーンに対してプレビュー（エージェントが発信前に顧客情報を確認できるモード）と非プレビュー（自動発信でスループットを優先するモード）を切り替えられます。切替によって新しい発信挙動（発信ペース、エージェント割当、顧客データ表示等）が即時反映され、インフライトの通話を中断することなく以降の発信が新モードに従って行われます。これにより、高優先度の顧客に対してはプレビューでコンテキストを付与し、通常時は非プレビューでスループットを最大化するといったハイブリッド運用が可能です。機能は追加料金なしで、Amazon Connect Outbound Campaignsをサポートする全リージョンで利用可能です（US East (N. Virginia), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (London), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Africa (Cape Town)）。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンター管理者、キャンペーン運用者、SRE/運用チーム
  • 利用シーンまたは効果: 高優先度顧客の取り扱い時にプレビューへ切替えてエージェントにコンテキストを与え、トラフィック正常化後に非プレビューへ戻して発信効率を回復するようなリアルタイムな運用最適化
  • 運用効果: キャンペーン停止による中断や再スケジュール不要でダイヤリング戦略を即時変更でき、エージェント生産性とキャンペーンのコンバージョン効率を向上可能

技術的な注意点 ​

  • IAM権限: キャンペーン設定の変更を行うためのAmazon Connect管理権限（コンソール/APIを操作するユーザーに対して該当するConnectの権限付与）を確認してください
  • リージョン制限: 本機能は記事に記載のサポートリージョンで利用可能（US East(N. Virginia), US West(Oregon), Canada (Central), EU(Frankfurt), EU(London), AP(Seoul), AP(Singapore), AP(Sydney), AP(Tokyo), Africa(Cape Town)）。未記載リージョンでは未対応の可能性があります
  • コスト: 機能そのものに追加料金は発生しませんが、発信に伴う通話料金やConnectの通常コストは発生します。発信量や通話時間の増減がコストに影響します
  • 運用影響: 切替は以降の発信動作に反映されますが、既に接続済みの通話は通常通り継続します。切替タイミングで一時的に発信ペースやエージェント割り当てが変動する可能性があるため、モニタリングが必要です
  • CRM/スクリーンポップ連携: プレビュー時は顧客データや画面ポップが必須となるため、外部CRM連携や画面ポップ設定が正しく動作することを事前に確認してください
  • テスト推奨: 本番運用へ適用する前に小規模キャンペーンやステージング環境で切替動作、レポート/メトリクス（応答率、放棄率、エージェント稼働率）への影響を検証してください

参考情報 ​

[RDS] Amazon CloudWatch now provides lock contention diagnostics for Amazon RDS for PostgreSQL ​

概要 ​

Amazon CloudWatch Database Insightsが、Amazon RDS for PostgreSQL向けにロック競合（lock contention）の診断機能を追加しました。Advancedモードでブロッキング／待機セッションの関係を可視化し、過去15ヶ月分のロックデータを保持して原因分析を短時間で行えます。

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

CloudWatch Database InsightsのAdvancedモードにおいて、RDS for PostgreSQLインスタンスのロック競合診断を提供します。コンソール上でブロッキング（blocking）セッションと待機（waiting）セッションの関係を視覚化し、どのセッション／クエリ／オブジェクトが競合を引き起こしているかを特定できます。リアルタイムだけでなく、最大15ヶ月間のヒストリカルなロック情報を保持するため、過去の発生状況を遡って解析可能です。本機能により、従来必要だったカスタムSQLやアプリケーションログの手動調査を減らし、調査時間を短縮します。導入はRDSコンソール、AWS API、またはAWS SDKからCloudWatch Database InsightsのAdvancedモードを有効化するだけで開始できます。Database Insightsはフリートレベルの集約ヘルス監視と、インスタンスレベルの詳細ダッシュボード（SQLクエリ分析等）を提供します。本機能はすべてのパブリックAWSリージョンで利用可能で、課金はvCPUベースの料金体系に準じます（詳細は料金ページを参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: DB管理者（DBA）、SRE、運用チーム、アプリケーション開発者
  • 利用シーン: RDS for PostgreSQLで発生するロック競合の原因特定、リアルタイム及び過去（最大15ヶ月）のロックイベント解析、パフォーマンス障害のトラブルシューティング
  • 運用効果: カスタムクエリやログ収集による手動調査を削減し、根本原因の特定と復旧時間（MTTR）の短縮、運用負荷の軽減

技術的な注意点 ​

  • 有効化方法: RDSコンソール／AWS API／AWS SDKからCloudWatch Database InsightsのAdvancedモードを有効にしてください
  • モード制限: ロック診断機能はAdvancedモードのみで利用可能です（Standardモードでは利用不可）
  • データ保持: ロック関連のヒストリカルデータは最大15ヶ月間保持されます（保持期間に伴うストレージ／料金の影響に注意）
  • IAM権限: Database Insightsの有効化・表示には適切なRDS/CloudWatchのIAM権限が必要です。運用ユーザーに該当権限を付与してください
  • リージョン制限: 公開されている情報では「全てのパブリックAWSリージョン」で利用可能とされていますが、利用前に対象リージョンで有効化可能か確認してください
  • コスト: AdvancedモードはvCPUベースの課金が適用されます。常時有効化すると追加料金が発生するため、コスト影響を評価してください
  • PostgreSQLバージョン: 記事では特定バージョンの記載がないため、サポートされるPostgreSQLのバージョンやRDSエンジンの制約は公式ドキュメントで事前に確認してください

参考情報 ​

[Security Hub] AWS Security Hub launches Extended plan for pay-as-you-go partner solutions ​

概要 ​

AWS Security Hub Extendedは、AWSの検出機能とキュレーションされたパートナー製品を単一の購入体験で組み合わせ、請求・調達・運用の複雑さを軽減する新しい有償プラン（一般提供開始）です。従量課金または定額で必要なセキュリティカテゴリだけを選んで利用できます。

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

Security Hub Extendedは、AWSが販売主体（seller of record）となり、パートナ―提供のセキュリティソリューションをSecurity Hubのコンソールから選択して追加できるプランです。主な機能は次のとおりです。1) 請求の統合：パートナー利用分を含めた単一のAWS請求に集約し、調達・請求の複雑性を低減します。2) 統合的な検出：AWSの検出サービスとパートナーのエンドポイント、アイデンティティ、メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティ運用等のカテゴリを組み合わせ、より包括的な保護を実現します。3) 運用効率化：パートナー検出結果をAWS Security Hubの標準フォーマット（AWS Security Finding Format: ASFF）で集約し、中央可視化・自動ワークフローやSIEM/SOAR連携を容易にします。価格は従量課金（pay-as-you-go）またはフラットレートを選べ、前払いや長期契約は不要です。AWS Enterprise Support契約がある場合、Level1窓口をAWSで一本化できます。さらに、条件によってはAWS Private Pricingの対象となる可能性があり、導入後にカテゴリの追加・削除を柔軟に行えます。利用可能リージョンはSecurity Hubが提供されているAWS商用リージョンに準じます。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ運用チーム、CISO、SRE、クラウド/セキュリティアーキテクト
  • 利用シーンまたは効果: 複数ベンダーの管理を簡素化して、検出結果を一元化し、SIEM/SOARやインシデント対応の効率を向上させたい企業
  • 運用効果: 請求や契約交渉の負担が軽減され、パートナー統合に伴う手作業（インテグレーション）の削減、運用上の可視化の向上が期待できる
  • コスト影響: パートナーソリューション利用分がAWS請求に統合されるため、従来の個別契約と比較して支払先・請求処理は簡素化されるが、総コストは選択したパートナーと利用量に依存して増減する
  • サポート影響: AWS Enterprise Support利用者はLevel1サポートをAWSで一本化できるが、深い製品知見や高度なトラブルはパートナー側サポートが必要になる場合がある

技術的な注意点 ​

  • IAM権限: Security Hubの有効化、パートナー連携の追加には適切なIAM権限（securityhub:EnableSecurityHub / Integrations関連権限等）が必要です
  • リージョン制限: ExtendedはSecurity Hubが提供されるAWS商用リージョンで利用可能です。地域によって未対応のリージョンがあるため導入前にリージョン対応を確認してください
  • コスト: 従量課金または定額の料金体系が選べますが、パートナー毎の使用量に応じた追加課金が発生します。Private Pricingが適用可能な場合もあるため、費用見積りは事前に確認してください
  • サポート: AWSはEnterprise Support契約者に対してLevel1の窓口統合を提供しますが、パートナー固有の問題や製品内部の調査・修正はパートナーサポートが担当する場合があります
  • フォーマット互換性: Security HubはAWS Security Finding Format（ASFF）で検出結果を標準化します。SIEM/SOARや自動化ワークフローへ連携する際はASFFベースのマッピングを想定してください
  • 導入運用: パートナー統合は各ソリューションごとに追加設定（エージェント導入、APIキー、クロスアカウントロールなど）が必要になることが多いです。接続方法・権限・ネットワーク要件は各パートナーの案内を参照してください

参考情報 ​

[Cognito] Amazon Cognito enhances client secret management with secret rotation and custom secrets ​

概要 ​

Amazon Cognitoのアプリクライアント向けに、クライアントシークレットのカスタム持ち込み（BYO）とオンデマンド回転（ローテーション）、および最大2つのアクティブシークレットを保持するライフサイクル管理機能が追加されました。これにより定期的な資格情報ローテーションや他認証基盤からの移行が容易になります。

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

主な変更点は以下の通りです。

  • カスタムクライアントシークレット: これまでCognitoが自動生成していたアプリクライアントシークレットに対し、新規および既存のアプリクライアントで独自（Bring Your Own）のシークレットを設定できるようになりました。これにより、組織で既に管理しているシークレットポリシーや外部シークレットストアとの整合が取りやすくなります。
  • シークレットのオンデマンド回転: 管理者は必要に応じてクライアントシークレットを手動で回転（ローテーション）できるようになりました。回転時には最大で2つのアクティブシークレットを同時に保持でき、古いシークレットから新しいシークレットへの段階的な移行が可能です。
  • 操作方法: AWS マネジメントコンソール、AWS CLI、各種 AWS SDK、および AWS CloudFormation から利用可能。CloudTrailで操作の監査が可能な設計です。
  • 適用範囲: Amazon Cognito ユーザープールが提供されている全リージョンで利用可能（リージョン依存の追加制限はなし、ただしCognitoユーザープール自体の提供状況に依存）。
  • セキュリティ・運用上の利点: 定期ローテーション要件への対応、移行時の短時間での切り替え（ダウンタイム削減）、既存シークレット管理ポリシーとの統合が容易になる点。

影響範囲・利用シーン ​

  • 対象ユーザー: 認証基盤を運用するクラウドエンジニア、セキュリティチーム、SRE、アプリケーション開発チーム
  • 利用シーン: 定期的な資格情報ローテーションが求められる環境、既存認証システムからCognitoへ移行する際のシークレット持ち込み、機械間（マイクロサービス／AIエージェント）での機密クライアント認証
  • 運用効果: 最大2つのアクティブシークレットにより新旧シークレットの段階的切替が可能になり、アプリケーションのダウンタイムを発生させずにシークレットを更新できる
  • セキュリティ効果: シークレット管理ポリシー（外部シークレットストア、KMS連携など）と連携することでセキュリティ体制を強化できる

技術的な注意点 ​

  • IAM権限: シークレットの作成/更新/回転にはCognito Identity Providerの権限が必要（例: cognito-idp:CreateUserPoolClient、cognito-idp:UpdateUserPoolClient、cognito-idp:DescribeUserPoolClient など）。CloudFormationから変更する場合はスタック更新権限も必要です。
  • リージョン制限: Cognitoユーザープールが提供されているすべてのリージョンで利用可能。リージョン未提供の場合は利用不可です。
  • コスト: 新機能自体の追加料金は発表されていませんが、外部シークレット管理にAWS Secrets Manager等を利用する場合は別途料金が発生します。
  • 互換性: クライアントシークレットは「confidential」なクライアント（サーバーサイド等）で使用する想定です。パブリッククライアント（例: ネイティブモバイルやブラウザの公開クライアント）にはシークレットを持たせない設計が引き続き推奨されます。
  • 運用上の注意: シークレット回転後はクライアントアプリ側の設定更新が必要です。最大2つのアクティブシークレットを利用して段階的に切替える運用を設計してください。
  • 監査/ロギング: シークレット作成・更新・回転操作はCloudTrailで記録できます。変更イベントの監視を実装してください。
  • CloudFormation/SDK/CLI: 各種ツールからサポートされていますが、テンプレートやAPIフィールドの更新（新しいプロパティ）が必要になる場合があるため既存IaCの確認を推奨します。

参考情報 ​

[Ec2] Amazon EC2 M8i and M8i-flex instances are available in additional regions ​

概要 ​

Amazon EC2のM8iおよびM8i-flexインスタンスが、米国西部（北カリフォルニア）、欧州（パリ）、アジアパシフィック（ハイデラバード）、南米（サンパウロ）で利用可能になりました。カスタムIntel Xeon 6プロセッサ搭載で、前世代のIntelベースインスタンス比でメモリ帯域や価格性能比が向上しています。

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

M8iおよびM8i-flexはAWS専有のカスタムIntel Xeon 6プロセッサを搭載した汎用インスタンスファミリーです。特徴として、従来のIntelベースインスタンスに対して最大で15%良好な価格性能比、メモリ帯域は最大2.5倍を提供します。M7i/M7i-flexと比較すると総合性能で最大20%の向上が見込まれ、ワークロードによっては更に高い性能改善が発生します。具体的なベンチマーク例としては、PostgreSQLで最大約30%高速化、NGINXなどウェブアプリで最大約60%高速化、AIの深層学習レコメンデーションモデルで最大約40%高速化が報告されています。

M8i-flexは一般的な汎用ワークロード（ウェブ/アプリケーションサーバ、マイクロサービス、中小規模のデータストア、仮想デスクトップ、エンタープライズアプリケーション等）に対して、最も一般的なサイズ（large〜16xlarge）を提供し、計算資源をフル活用していないアプリケーションでの価格性能改善を得やすいのが利点です。一方でM8iは連続的な高CPU使用率や最大サイズが必要なケースに適しており、SAP認定を含む13サイズ（うちベアメタル2サイズ）を提供、最大の96xlargeサイズが追加されています。

利用開始はAWS Management Consoleから可能で、導入前に対象リージョンでの提供状況、価格（オンデマンド、RI、Savings Plans等）や既存AMI／ドライバの互換性を確認することが推奨されます。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、SRE、データベース管理者、AI/MLエンジニア、エンタープライズアプリ運用者
  • 利用シーン: ウェブ/アプリケーションサーバ、マイクロサービス、小中規模データストア、仮想デスクトップ、PostgreSQLなどのDB、NGINX等の高スループットWeb、レコメンデーション等のディープラーニング推論・トレーニング
  • 運用効果: 同等世代比でコストあたり性能が向上し、レスポンスタイム改善やスループット増加、インスタンス数削減による運用コスト低減が期待できる

技術的な注意点 ​

  • リージョン制限: 新たに利用可能になったのは US West (N. California)、Europe (Paris)、Asia Pacific (Hyderabad)、South America (Sao Paulo) です。その他リージョンでは未提供の可能性があるため事前確認を推奨します
  • IAM権限: ec2:RunInstances などの標準的なEC2起動権限が必要です。既存自動化・IaCでのロール／ポリシー確認を行ってください
  • AMI/ドライバ互換性: 新しいカスタムIntelプラットフォームに対してOSカーネルやENA/ドライバの互換性を検証してください。特に専用ドライバやカーネル要件がある場合は事前テストが必須です
  • ネットワーク／ストレージ: ネットワーク帯域やEBSパフォーマンスはインスタンスサイズに依存します。IOPS/スループット要件がある場合はサイズ選定とベンチマークで確認してください
  • ベアメタルとSAP: M8iはベアメタルサイズを2つ提供しており、SAP認定済みのサイズがあるためSAPワークロード向けに選択肢があります
  • コスト: 表示された「価格性能比の改善」はワークロード依存です。オンデマンド価格、RI/Savings Plans、スポット価格を比較し、実ワークロードでベンチマークして総所有コストを評価してください
  • 移行/検証: 既存のM7i等からの移行では性能差異がワークロードごとに異なるため、ステージング環境でのベンチマーク（CPUプロファイル、メモリ帯域、I/O、ネットワーク）を事前に実施してください
  • 特になし: なし

参考情報 ​

[Ec2] Introducing Amazon EC2 I8g.metal-48xl instances ​

概要 ​

Amazon EC2のストレージ最適化インスタンス I8g.metal-48xl が一般提供開始されました。Graviton4（Arm）プロセッサと第3世代Nitro SSD（ローカルNVMe）を組み合わせ、ストレージI/Oとレイテンシに最適化された高性能インスタンスです。

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

I8gインスタンスはAWS Graviton4プロセッサを採用し、従来のI4gに対して最大で約60%のコンピュート性能向上を実現します。ストレージには第3世代AWS Nitro SSD（ローカルNVMe）を搭載し、TBあたり最大約65%向上したリアルタイムストレージ性能、ストレージI/Oレイテンシを最大約50%低減、レイテンシのばらつきを最大約60%低減します。Nitroシステムを基盤とし、CPU仮想化、ストレージ、ネットワーキングを専用ハードウェア／ソフトウェアでオフロードするため、性能とセキュリティが向上します。インスタンスはI/O集約型ワークロード向けに設計され、トランザクション／リアルタイムデータベース（MySQL、PostgreSQL、ClickHouse、Apache Druid、MongoDB等）、およびリアルタイム分析（Apache Spark等）に適します。ラインナップは11サイズ（うちmetalを含む2サイズ）で、最大で48xlarge相当（metal-48xl相当）、最大1536 GiBメモリ、ローカルインスタンスストレージ最大45 TBを提供。ネットワーク帯域は最大100 Gbps、Amazon EBS向け専用帯域は最大60 Gbpsです。ArmベースのGraviton4を採用しているため、OS/アプリケーション/ライブラリはArm互換（またはマルチアーキ対応）である必要があります。インスタンスストアはローカルNVMeのためエフェメラル（永続性なし）である点にも注意してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、SRE、ビッグデータ／リアルタイム分析エンジニア、ストレージ集約型アプリケーション開発者
  • 利用シーンまたは効果: トランザクショナルDBやNoSQL（ClickHouse, Druid, MongoDB等）、リアルタイム分析基盤（Spark等）、低レイテンシIOが要求されるワークロードでのレスポンス改善とスループット向上
  • 運用効果: ストレージI/O待ちによるボトルネック低減、レイテンシ変動の縮小による予測可能なパフォーマンス、ネットワーク／EBS専用帯域による安定したデータ転送

技術的な注意点 ​

  • IAM権限: インスタンス起動・ENI作成・EBS操作などの標準的なEC2/VPC権限が必要です（RunInstances, CreateNetworkInterface, AttachVolume 等）。
  • リージョン制限: 一部リージョンでは未提供の可能性があるため、利用前に対象リージョンでの提供状況をコンソールまたはドキュメントで確認してください。
  • コスト: 高性能・大容量のローカルNVMeとmetalオプションにより、同等世代の汎用インスタンスより高コストになる可能性があります。インスタンス時間課金のほか、EBS使用分／データ転送等のコスト影響を評価してください。
  • アーキテクチャ互換性: Graviton4はArmアーキテクチャのため、既存のx86バイナリは再ビルドまたはArm対応のコンテナイメージが必要です。マルチアーキテクチャ対応のコンテナやクロスコンパイルを検討してください。
  • データ永続性: ローカルNVMe（インスタンスストア）はエフェメラルで、停止・終了でデータが消失します。永続化が必要なデータはEBS/S3等に保存する設計にしてください。
  • ドライバ／AMI: ENA（Enhanced Networking）およびNVMeドライバ対応のAMIが必要です。Amazon Linux、Ubuntu等のArm対応イメージを利用するか、カスタムAMIを用意してください。
  • metal制約: metalインスタンスはベアメタルアクセスを提供しますが、一部マネージド機能やホストテナンシーの制約、ホストレベル操作（カーネルモジュール等）の責任範囲が変わるため事前設計が必要です。

参考情報 ​

[SNS] Amazon SNS now supports push notifications in the Europe (Spain) Region ​

概要 ​

Amazon SNSはAWS Europe (Spain)リージョンでプッシュ通知の送信をサポートしました。これにより同リージョンからADM、APNs、Baidu、FCM、MPNS、WNSへプッシュ配信が可能になりました。

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

Amazon Simple Notification Service (SNS)はフルマネージドのpub/subサービスで、Lambda、SQS、Kinesis Data Firehose、HTTP、SMS、メールに加えプッシュ通知もサポートします。本リリースにより、Europe (Spain)リージョンでプッシュ通知向けのPlatform ApplicationおよびPlatform Endpointを作成でき、以下のプッシュサービスへ送信できます：Amazon Device Messaging (ADM)、Apple Push Notification Service (APNs)、Baidu Cloud Push、Firebase Cloud Messaging (FCM)、Microsoft Push Notification Service for Windows Phone (MPNS)、Windows Push Notification Services (WNS)。今回の拡張で、プッシュ送信を行えるリージョンは合計25リージョンになりました。実装上は対象リージョンでPlatform Applicationを作成し、各プロバイダ（APNsの証明書またはトークン、FCMのサーバーキー等）の認証情報を設定してPlatform Endpointを作成・管理します。リージョンを近接させることで待ち時間やデータ主権・コンプライアンスの要件を満たしやすくなります。詳細とリージョン一覧はAmazon SNSの開発者ガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: モバイル/デスクトップアプリ開発者、通知基盤を運用するSREやプラットフォームチーム
  • 利用シーンまたは効果: Europe (Spain)に配置したワークロードから直接プッシュ通知を送信可能になり、遅延低減やデータ所在要件（データ主権）の遵守が容易になる
  • 運用効果: リージョン内での管理によりネットワーク経路が短縮され、配信遅延の改善・運用監査での証跡管理やコンプライアンス対応がしやすくなる

技術的な注意点 ​

  • IAM権限: sns:CreatePlatformApplication、sns:CreatePlatformEndpoint、sns:Publish、sns:SetPlatformApplicationAttributes などの権限が必要です
  • 認証情報: APNsの証明書/トークン、FCMのサーバーキー/JSON、各プッシュプロバイダの資格情報を事前に用意してください（資格情報はリージョンのPlatform Applicationに設定します）
  • リージョン制限: プッシュ送信はリージョン単位で設定・管理します。Europe (Spain)リージョンで作成したPlatform Application/Endpointから送信できます。全てのリージョンで同一のプロバイダ機能が使えるわけではないため、対応リージョン一覧を確認してください
  • コスト: SNSの通常料金（リクエスト数、データ送信量）および関連するデータ転送コストが発生します。プッシュ配信量やリトライの影響でコストが増加する可能性があります
  • 運用注意: エンドポイントの作成・無効化（トークンの失効処理）やフィードバック（配信失敗・バウンス）を監視し、定期的なクリーンアップを行ってください

参考情報 ​

AI要約はOpenAI GPT-5-miniによって生成されています。

Copyright © 2026