Skip to content

2026年04月03日

[CloudWatch] Amazon CloudWatch introduces PromQL querying with Query Studio Preview

概要

Amazon CloudWatchはQuery Studioをパブリックプレビューで公開しました。これにより、CloudWatch上でネイティブなPromQLクエリが実行でき、PromQLとCloudWatch Metric Insightsを単一のUIで使えるようになります。

変更内容・新機能の詳細

Query Studioは、PromQLとCloudWatch Metric Insightsを統合したクエリ/可視化環境です。PromQLでAWSが提供する(vended)メトリクスや、OpenTelemetry経由で取り込んだカスタムメトリクスを同一インターフェースでクエリ可能にします。UIはビジュアルなフォームビルダー(オートコンプリート付き)と、シンタックスハイライトを備えたコードエディタを提供し、初心者から経験者まで使いやすく設計されています。クエリ結果から直接アラームを作成したり、ダッシュボードにチャートを追加することが可能で、例えばEC2のvendedメトリクスとアプリケーションのOpenTelemetryメトリクスを並べて相関を見ることで、スタック横断の問題特定を迅速化できます。Query Studioはパブリックプレビューとして指定リージョンで利用可能で、標準のCloudWatchダッシュボード料金が適用されます。コンソール上のMetrics画面やダッシュボード編集モードから起動できます。

影響範囲・利用シーン

  • 対象ユーザー: クラウドエンジニア、SRE、プラットフォーム/アプリ運用チーム、Observability/Telemetry担当者
  • 利用シーン: Prometheus/PromQLを既に利用している環境で、AWS vendedメトリクスやOpenTelemetryメトリクスと合わせて可視化・分析する場面(例: EC2上のアプリ指標とホストメトリクスの相関分析)
  • 運用効果: コンソールを切り替えずにPromQLでクエリできるため、トラブルシューティング時間の短縮、アラート作成やダッシュボード反映のワークフロー短縮が期待できる
  • 適用範囲: メトリクスレベルの相関分析、カスタムメトリクスとvendedメトリクスの統合クエリ、ダッシュボード/アラームの迅速な作成

技術的な注意点

  • IAM権限: CloudWatchのGet/List系権限(例: cloudwatch:GetMetricData, cloudwatch:ListMetrics)、ダッシュボード/アラーム作成にはPut権限が必要になります。必要な最小権限を設計してください。
  • リージョン制限: パブリックプレビューは現時点で US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Singapore), Europe (Ireland) のみで利用可能です。他リージョンは未対応の可能性があります。
  • プレビュー注意: パブリックプレビュー機能は変更される可能性があり、GA時に仕様や制限が変わる場合があります。
  • コスト: 標準のCloudWatchダッシュボード料金やMetric Insights/クエリ実行に関連する料金が適用される可能性があります。クエリ頻度やダッシュボード表示数により追加料金が発生するため、利用前に料金ページで確認してください。
  • データ連携: OpenTelemetryメトリクスを利用する場合は、CloudWatchへ適切に取り込まれていること(OTel CollectorやAWS Distro for OpenTelemetry等の設定)を事前に確認してください。

参考情報


[General] Amazon ElastiCache Serverless now supports IPv6 and dual stack connectivity

概要

Amazon ElastiCache Serverless が IPv6 とデュアルスタック接続をサポートしました。IPv4 に加え、IPv6-only または IPv4/IPv6 両対応(dual stack)を選択でき、段階的な IPv6 移行や IPv6準拠要件への対応が容易になります。

変更内容・新機能の詳細

ElastiCache Serverless のキャッシュ作成時にネットワークタイプとして「IPv4」「IPv6」「dual stack(IPv4+IPv6同時受け入れ)」のいずれかを選べるようになりました。dual stack を選ぶと同一キャッシュが IPv4 と IPv6 の両方で接続を受け付けるため、既存の IPv4 クライアントはそのまま動作させつつ、並行してクライアントの IPv6 化を進められます。IPv6 を選択すると IPv6-only サブネットでの配置が可能になり、IPv4 アドレスを割り当てる必要がなくなります。DNS の応答はデュアルスタック時に A(IPv4)と AAAA(IPv6)アドレスを返す想定で、クライアントは利用可能なアドレスで接続します。本機能は追加料金なしで全リージョン(AWS GovCloud (US) / 中国リージョン含む)で利用可能です。

影響範囲・利用シーン

  • 対象ユーザー: アプリケーション開発者、ネットワークエンジニア、クラウド基盤運用者
  • 利用シーン: IPv6 への段階的移行(dual stack を使ったハイブリッド運用)、IPv6-only VPC/サブネットを前提としたインフラ構築、コンプライアンス要件で IPv6 が必須の環境
  • 運用効果: NAT や IPv4 アドレス依存を減らせるため運用コストや複雑さを低減可能。デュアルスタックによりダウンタイムなしで IPv6 へ切り替えを進められる

技術的な注意点

  • IAM権限: ElastiCache のサーバレスキャッシュ作成/変更権限(ElastiCache 系の操作権限)と VPC 関連の EC2 権限(ネットワークインターフェイス操作など)が必要です
  • リージョン制限: 本発表によると全リージョン(GovCloud/China 含む)で利用可能です
  • コスト: IPv6 / dual stack の利用自体に追加料金はありませんが、データ転送や関連するネットワーク構成(例: NAT Gateway の削除や egress 経路の変更)によるコスト影響が発生する可能性があります
  • ネットワーク設定: VPC とサブネットに IPv6 CIDR を割り当てる、サブネットのルートテーブルに IPv6 のルートを設定する、セキュリティグループ/NACL に IPv6(CIDR, ::/0 など)の許可ルールを追加する必要があります。デュアルスタックでは A/AAAA の DNS 応答が重要です
  • 互換性: クライアント・ライブラリやミドルウェアが IPv6 をサポートしていることを事前に確認してください。古い OS/ミドルウェアでは IPv6 接続に未対応の可能性があります
  • 監視/ログ: CloudWatch や既存の監視ツールで IPv6 アドレス表記が扱えるか確認してください
  • 回帰・テスト: デュアルスタック導入時は接続優先度(IPv6/IPv4)や DNS キャッシュの挙動を検証し、負荷/レイテンシの変化をベンチマークしてください

参考情報


[EKS] Amazon CloudWatch launches OTel Container Insights for Amazon EKS (Preview)

概要

Amazon CloudWatchがAmazon EKS向けにOpenTelemetry(OTel)メトリクスを使ったContainer Insightsをパブリックプレビューで提供開始しました。OTLPで収集されたメトリクスをCloudWatchへ送信し、Kubernetesメタデータやカスタムラベルで最大150個のラベルを自動付与して可視化します。

変更内容・新機能の詳細

本機能は既存のContainer Insightsを拡張し、広く使われているオープンソースおよびAWSのコレクタからより多くのメトリクスを収集してOpenTelemetry Protocol(OTLP)でCloudWatchに送信します。各メトリクスにはKubernetesのメタデータ(namespace、pod、nodeなど)やユーザー定義のラベル(team、application、business unit等)を含め最大150個まで自動的に付与されます。Container Insightsコンソールにはキュレーションされたダッシュボード(クラスタ/ノード/ポッド単位のヘルス表示)が用意され、インスタンスタイプ、AZ、ノードグループ、カスタムラベルなどで集約・フィルタリングできます。詳細分析はCloudWatch Query StudioでPrometheus Query Language(PromQL)を使ってクエリ可能です。インストールはCloudWatch Observability EKSアドオンによりEKSコンソールからワンクリック、もしくはCloudFormation、CDK、Terraformでデプロイできます。アドオンはNVIDIA GPU、Elastic Fabric Adapter、AWS Trainium/Inferentiaなどのアクセラレータを自動検出します。既存のアドオン利用者はOpenTelemetryメトリクスと従来のContainer Insightsメトリクスを同時に公開可能です。パブリックプレビューは US East (N. Virginia)、US West (Oregon)、Asia Pacific (Sydney)、Asia Pacific (Singapore)、Europe (Ireland) で利用可能で、プレビュー期間中はOpenTelemetryメトリクスの課金は発生しません。

影響範囲・利用シーン

  • 対象ユーザー: EKSを利用するSRE/プラットフォームエンジニア、アプリケーション開発チーム、観測基盤(Observability)担当者
  • 利用シーンまたは効果: クラスタ/ノード/ポッド単位の詳細なメトリクス収集とPromQLによる高度なクエリでトラブルシュートやパフォーマンス分析を向上
  • 運用効果: カスタムラベルでのフィルタリングによりチーム単位やアプリ単位の状態把握が容易になり、原因特定と対応時間を短縮
  • 対象ワークロード: GPU/トレーニングアクセラレータ(Trainium/Inferentia)を使う機械学習や高性能コンピュートワークロードの可観測性向上
  • リージョン: プレビューは指定のリージョン(N. Virginia, Oregon, Sydney, Singapore, Ireland)のみ対応
  • コスト: プレビュー期間中はOpenTelemetryメトリクスの課金なし(ただし将来的な課金や高ラベル数によるメトリクス高分解能化でコスト増の可能性あり)

技術的な注意点

  • IAM権限: EKSアドオンのインストールにはEKSクラスタの管理権限とCloudWatchへの書き込み権限が必要(ServiceAccountやClusterRoleBindingの設定が必要になる場合あり)
  • リージョン制限: パブリックプレビューは US East (N. Virginia)、US West (Oregon)、Asia Pacific (Sydney)、Asia Pacific (Singapore)、Europe (Ireland) のみ
  • コスト: プレビュー期間はOTelメトリクスに課金なし。ただしプレビュー終了後はCloudWatchのメトリクス/ストレージ/クエリの課金対象となる可能性があるため、高ラベル数(高カードinality)によるコスト増を想定して設計すること
  • デプロイ方法: CloudWatch Observability EKSアドオン(EKSコンソールのワンクリック)またはCloudFormation/CDK/Terraformでの自動デプロイに対応
  • 互換性: 既存のContainer InsightsメトリクスとOpenTelemetryメトリクスの同時公開をサポート
  • メトリクス設計上の注意: 最大150ラベルという高次元のメタデータ付与は時系列データのカードinalityを大幅に増やすため、ラベル設計(どのラベルを付けるか)を慎重に行わないとストレージ・クエリコストや検索パフォーマンスに影響する
  • 監視と収集設定: Collectorのサンプリング/バッファリング設定、OTLPエンドポイントやバッチ送信設定を適切に調整してネットワーク負荷と遅延を抑えること
  • ハードウェア検出: NVIDIA GPU、Elastic Fabric Adapter、AWS Trainium/Inferentiaなどの検出を行うが、特定のドライバやCRI設定が必要となる場合があるため事前確認を推奨
  • PromQLサポート: CloudWatch Query StudioでPromQLが利用可能。Prometheusネイティブのクエリ資産を活かせる
  • 既知の制約: プレビュー機能のため将来的なAPI/ラベル名の変更や動作変更があり得る。運用前にプレビューの制限事項を確認すること

参考情報


[Deadline Cloud] AWS Deadline Cloud now supports configurable job scheduling modes for queues

概要

AWS Deadline Cloudでキューごとにジョブのスケジューリング方式を選べるようになりました。これにより、ワーカーの割り当て方法を制御し、提出したジョブのフィードバックを早めることができます。

変更内容・新機能の詳細

今回の更新で、キュー作成または更新時に選択できる3つのスケジューリングモードが追加されました。

  • priority FIFO(既定): これまでの動作で、最も高い優先度かつ最も早く提出されたジョブへ利用可能な全ワーカーを順次割り当てます。遅いジョブの進行は優先ジョブ完了まで待たされる可能性があります。
  • priority balanced: 同一の最高優先度レベル内にあるすべてのジョブに対してワーカーを均等に分配します。複数ジョブを並行進行させ、各ジョブの初期フィードバックを早められます。
  • weighted balanced: ジョブごとに重み付けを行い(設定可能なパラメータ例: 優先度、エラー数、提出時刻、レンダリングタスク数)、その重みに応じてワーカーを分配します。重み付けルールによって短時間でのプレビュー優先や、エラーの多いジョブへの割当て抑制などが可能です。 これらのモードは、コンソール/API/SDKからキューの作成・更新時に指定できます(記事では "create or update a queue" と記述)。また、すべてのAWSリージョンのDeadline Cloud対応リージョンで利用可能です。開発者ガイドに設定方法や各パラメータの詳細が記載されています。

影響範囲・利用シーン

  • 対象ユーザー: CG/VFXアーティスト、レンダリング管理者、SRE/運用チーム
  • 利用シーン: アーティストが提出直後にプレビューを早く得たいケース(短いテストジョブやインクリメンタルな修正確認)、複数の同優先度ジョブを並列で進めたいワークフロー
  • 運用効果: 重要ジョブに全リソースを集中させる従来方式と比べ、複数ジョブの初期応答性が向上しフィードバックループを短縮できる。重み付けによりポリシーベースの割当てが可能になり、ワークフローの柔軟性が増す

技術的な注意点

  • IAM権限: キューの作成・更新を行う権限(Deadline Cloudの該当APIやコンソール操作を許可するIAMポリシー)が必要です。具体的なアクション名はドキュメントで確認してください。
  • リージョン制限: すべてのDeadline Cloud対応リージョンで利用可能と記載されていますが、利用前に対象リージョンでサービスが提供されているか確認してください。
  • コスト: 新機能自体に追加料金は明記されていません。ただし、balancedモードで複数ジョブを並列実行するとワーカーの稼働パターンが変わり、使用時間や同時稼働インスタンス数の観点でコストへ影響する可能性があります。運用方針に合わせて検証してください。
  • 既存動作との互換性: デフォルトはpriority FIFOのままです。モード変更はキュー設定の変更で適用されますが、実行中ジョブへの影響や適用タイミングはドキュメントで事前に確認し、まずは非本番キューで検証することを推奨します。
  • 監視・ロギング: スケジューリング変更後はジョブの進行状況やワーカー利用率をCloudWatchやDeadlineのメトリクスで監視し、期待通りの割当てになっているか確認してください。

参考情報


[Lightsail] Announcing compute-optimized instance bundles for Amazon Lightsail

概要

Amazon Lightsailは最大72 vCPUのコンピュート最適化(compute-optimized)インスタンスバンドルを提供開始しました。7サイズでIPv6専用およびデュアルスタックのネットワークをサポートし、Lightsailの全ブループリントで利用可能です。

変更内容・新機能の詳細

新しいコンピュート最適化バンドルは最大72 vCPUまでの高CPU性能を必要とするワークロード向けに設計されています。7つのサイズが用意され、IPv6-onlyとIPv4/IPv6デュアルスタックの両方のネットワークタイプを選択可能です。すべてのLightsailブループリント(WordPress、cPanel & WHM、Plesk、Drupal、Magento、MEAN、LAMP、Node.js、Ruby on Rails、Amazon Linux、Ubuntu、CentOS、Debian、AlmaLinux、Windows など)でこれらのインスタンスを作成できます。これらのインスタンスは一貫した専用CPU性能を提供するため、CPUバウンドなバッチ処理、分散解析、高性能ウェブサーバ、科学計算、専用ゲームサーバ、広告配信エンジン、動画エンコード、CPU集約型の機械学習推論などに適しています。Lightsailは15リージョンで利用可能で(例:米国東部(北バージニア)、米国西部(オレゴン)、欧州(フランクフルト)、欧州(ロンドン)、アジアパシフィック(東京)、アジアパシフィック(ジャカルタ)など)、コンソールやLightsail API/CLIからインスタンスを作成できます。詳細なスペックや料金はLightsailの料金ページで確認してください。

影響範囲・利用シーン

  • 対象ユーザー: 開発者、スタートアップ、中小規模のSaaS事業者、ゲームサーバ運用者、データエンジニア、機械学習推論の運用チーム
  • 利用シーンまたは効果: CPU集約型バッチ処理や高性能Webサーバ、動画エンコード、広告配信、CPUベースのML推論などで処理時間短縮と予測可能なCPUパフォーマンスを実現
  • 運用効果: 専用CPUによりスローダウンの発生が減り、レスポンスの安定化やスループット向上が期待できる。EC2に移行せずにLightsailのシンプルさを保ちながら高CPU性能を利用可能
  • 移行のヒント: 既存のライトセールインスタンスから垂直スケールする場合はスナップショット取得と停止/再作成が必要なことがあるため、ダウンタイムを考慮してください

技術的な注意点

  • IAM権限: Lightsailの操作にはlightsail:CreateInstancesやlightsail:GetInstanceなどの権限が必要です。既存のIAMポリシーを確認してください
  • リージョン制限: 現時点ではLightsailが提供されている15リージョンで利用可能。全リージョンで即時利用できるとは限らないため、利用予定リージョンの対応状況を確認してください
  • コスト: 高CPU構成は料金が上昇します。ワークロードの稼働時間やスケール要件によりコスト評価を行ってください。Windowsは追加のライセンス料がかかる場合があります
  • 互換性: 記載のとおり公式ブループリントはサポートされていますが、アプリケーション固有のチューニング(スレッド数、ワーカー数、メモリ割当て)は必要です。各バンドルのメモリ/ストレージ仕様は料金ページで確認してください
  • ネットワーキング: IPv6-onlyオプションは一部の外部サービスやクライアントで互換性の問題が発生する可能性があります。IPv4依存のサービスと連携する場合はデュアルスタックを選択してください
  • スケーリング/運用: LightsailはEC2ほど細かいインスタンスタイプやカスタムネットワーク機能を持ちません。GPUや特殊ネットワーク機能が必要な場合はEC2の利用を検討してください。インスタンスサイズ変更は停止/再作成やスナップショットを伴う場合があります
  • Windows/ライセンス: Windowsベースのインスタンスはライセンスコストが含まれるか確認が必要です。ライセンス条件はリージョンとイメージによって異なります
  • API/CLI: コンソールに加えLightsailのAPI/CLI/SDKでインスタンス作成が可能です。自動化やIaCを行う場合は対応APIを確認してください

参考情報


[CloudWatch] Amazon CloudWatch expands auto-enablement to Amazon CloudFront logs and 3 additional resource types

概要

Amazon CloudWatchの自動有効化(auto-enablement)が拡張され、Amazon CloudFrontのStandardアクセスログ、AWS Security HubのCSPM所見ログ、Amazon Bedrock AgentCoreのメモリおよびゲートウェイのログ/トレースをCloudWatch Logsへ自動で送信できるようになりました。組織単位/アカウント単位/タグ単位のルールで既存および新規リソースに一貫したテレメトリ収集を自動化します。

変更内容・新機能の詳細

・サポート対象: CloudFront Standardアクセスログ、AWS Security Hub CSPM(コンプライアンス/構成管理)所見ログ、Amazon Bedrock AgentCoreのメモリとゲートウェイに関するログおよびトレース。 ・有効化ルール(enablement rules): 組織(Organization)全体、個別アカウント、リソースタグに基づくスコープでルールを作成可能。作成したルールは既存リソースと今後作成されるリソースの両方に対して自動的にテレメトリ設定を適用するため、手動設定を減らして標準化されたログ収集を実現する。 ・スコーピングの差異: CloudFrontアクセスログとSecurity Hub CSPM所見は組織全体のルールをサポート。Bedrock AgentCoreのメモリ/ゲートウェイテレメトリはアカウント単位のルールでサポートされる。 ・リージョン対応: AWSの全商用リージョンで利用可能。 ・課金: CloudWatchへのログ取り込み(ingestion)はCloudWatchの料金体系に従って課金される(取り込み、保存、クエリ、エクスポート等の各種料金に注意)。 ・運用例: セキュリティ中央チームが1つの組織ルールを作成して、組織内のすべてのCloudFrontアクセスログとSecurity Hubの所見を自動的にCloudWatch Logsへ集約する、といった構成が可能。

影響範囲・利用シーン

  • 対象ユーザー: クラウド運用者、SRE、セキュリティチーム、プラットフォーム/ガバナンス担当者
  • 利用シーン: 組織全体でのアクセスログ・セキュリティ所見の一元収集、自動オンボーディングされたリソースの継続的な監視、Bedrock AgentCoreのランタイムメトリクス収集
  • 運用効果: 手動設定を削減してテレメトリの抜け漏れを防止し、ログ収集の標準化と迅速なインシデント対応を実現
  • コスト影響: 送信されるログ量に応じたCloudWatchの取り込み・保存・クエリ料金が発生するため、ログ量・保持期間・メトリクス変換の設計がコスト最適化に直結します

技術的な注意点

  • IAM権限: 有効化ルールの作成・適用にはCloudWatch側の操作権限に加え、対象サービス(CloudFront、Security Hub、Bedrock)およびLogsへの書き込み権限が必要です。事前に必要な権限ポリシーを確認してください。
  • リージョン制限: 本機能は全商用リージョンで利用可能とされていますが、商用以外のリージョン(GovCloud、China等)は別途確認してください。
  • スコープ差分: CloudFront/Security Hubは組織単位での全体適用が可能ですが、Bedrock AgentCoreのテレメトリはアカウント単位のルールのみサポートされます。運用設計時に考慮してください。
  • ログ管理: 自動でロググループが作成される可能性があるため、ロググループ命名規則、保持期間(retention)、KMS暗号化、サブスクリプションフィルター(Lambda/Firehose等)との連携を事前に設計してください。
  • コスト: 取り込み(ingestion)、保存、分析(ログインサイトやLogs Insights)の各コストが発生します。大量ログを送る前に試験的に料金影響を評価してください。
  • 既存の設定との競合: 既に手動で設定したログ配信設定やサードパーティのログ収集設定と競合する可能性があるため、ロールアウト前に影響範囲を確認してください。

参考情報


[Direct Connect] AWS Direct Connect announces 100G expansion in Auckland, New Zealand

概要

Auckland(Datacom Orbit DH6)にある既存の AWS Direct Connect ロケーションで、100 Gbps 専用接続の提供が拡張されました。100Gbps ポートは MACsec によるレイヤ2暗号化に対応し、中国リージョンを除く全パブリック AWS リージョン、AWS GovCloud、そして AWS Local Zones へのプライベート接続が可能です。

変更内容・新機能の詳細

今回の拡張により、ニュージーランド(オークランド)の Datacom Orbit DH6 コロケーションにて 100 Gbps の専用 Direct Connect ポートを利用できるようになりました。Direct Connect は顧客データセンターやコロケーション施設と AWS 間の物理的な専用回線を提供し、インターネット経由よりも低遅延・安定したスループットを実現します。提供される 100 Gbps 接続は MACsec によるレイヤ2暗号化をサポートするため、回線上でのフレーム単位の暗号化が可能です。接続先は中国リージョンを除くパブリックリージョン、AWS GovCloud、Local Zones で、Direct Connect Gateway を使えば複数リージョンや複数 VPC への接続統合も可能です。ポートは物理クロスコネクトを介してプロビジョニングされ、必要に応じて LAG(Link Aggregation Group)、BGP ピアリング、帯域監視や冗長構成(複数ポート/ロケーション)を組むことができます。なお、AWS は世界中に 150 を超える Direct Connect ロケーションを持っています。

影響範囲・利用シーン

  • 対象ユーザー: エンタープライズ、クラウドアーキテクト、SRE、メディア配信事業者、機械学習/大規模データ転送を行う組織
  • 利用シーンまたは効果: 大容量データの定常転送(バックアップ、データ湖の同期、データ移行)、低遅延でのハイブリッドクラウド接続、メディアストリーミングやリアルタイム分析の品質改善
  • 運用効果: インターネット経由より安定したスループットと低ジッタを実現し、100 Gbps による短時間での大量データ移動やピーク時の性能確保が可能
  • 地理的影響: オークランド近傍のユーザーはレイテンシと帯域で恩恵を受ける。ニュージーランド国内で 100Gbps を提供する Direct Connect ロケーションが増え、冗長性の向上にも寄与

技術的な注意点

  • リージョン制限: 中国リージョン(cn-north-1 等)にはこのロケーションから直接アクセスできません
  • MACsec/機器要件: MACsec を利用する場合、顧客側ルーター/スイッチが 100G および MACsec をサポートしている必要があります(対応トランシーバ等も必要)
  • ポート/在庫: 100 Gbps 専用ポートは物理リソースに依存するため、プロビジョニングに際して在庫確認と発注手続きが必要です
  • ネットワーク設定: BGP ピアリング、VLAN(VIF)、LAG、Direct Connect Gateway の構成が利用可能。複数リージョン接続は Direct Connect Gateway 経由で実現します
  • コスト: ポート料金(時間単位)、データ転送料金、コロケーションのクロスコネクト費用や機器投資が発生します。100Gbps の長時間利用はコストに影響します
  • 運用/冗長化: ミッションクリティカル用途では別ロケーション/別プロバイダでの冗長 Direct Connect を検討してください
  • IAM権限: Direct Connect の操作には専用の IAM 権限が必要(接続作成、仮想インターフェース管理など)

参考情報


[General] Amazon CloudWatch now supports OpenTelemetry metrics in public preview

概要

Amazon CloudWatchがパブリックプレビューでネイティブなOpenTelemetry(OTel)メトリクス受信をサポートしました。OTLPで直接メトリクスを送信でき、CloudWatchの既存メトリクスと統合してPromQLでクエリ可能になります。

変更内容・新機能の詳細

今回のアップデートにより、OpenTelemetry Protocol(OTLP)で送信されたメトリクスをCloudWatchがネイティブに受け取り、カスタムOTelメトリクスとAWSが提供する70以上のサービスのメトリクスを同一プラットフォームで扱えるようになりました。主な機能は以下の通りです。

  • OTLP経由での直接受信: 追加の変換ロジックや外部ツールなしでOTelメトリクスを送信可能。
  • PromQL対応とQuery Studio: PromQLでクエリを書き、CloudWatchコンソール内のQuery Studioでメトリクス探索、アラーム作成、ダッシュボード構築が行えます。
  • ハイブリッド環境対応: Amazon EKS上のマイクロサービスとオンプレミスのサービスから同一にメトリクスを集約し、アプリケーションレイヤ(例: オーダー処理レイテンシ)とインフラレイヤ(例: Pod CPU、ALBリクエスト数)を相関付けて分析できます。
  • 異常検知の統合: CloudWatchのアノマリ検出がOTelメトリクスにも適用され、静的閾値設定なしで異常パターンを検出します。
  • プレビュー特典: パブリックプレビュー中はOTelメトリクスの送信およびクエリに料金は発生しません(ただし将来の正式リリース時は通常のCloudWatch課金体系が適用される可能性があります)。 技術的には、OTel SDK/エクスポーターを使ってOTLPでCloudWatchの受信エンドポイントに送信するフローが基本で、受信されたメトリクスはCloudWatchのメトリクス体系に統合され、PromQLで横断的に扱えます。Query Studioはコンソール上でのクエリ作成・検証・アラーム化・ダッシュボード化を容易にします。対応リージョンは公開情報の通り限定されています。

影響範囲・利用シーン

  • 対象ユーザー: マイクロサービス開発者、SRE、観測基盤チーム、オンプレ混在インフラを持つ組織
  • 利用シーンまたは効果: ハイブリッド環境のメトリクス統合(EKSとオンプレのOTelメトリクスをCloudWatchで一元管理)や、アプリケーションメトリクスとAWS vendedメトリクスの相関分析(例:注文処理遅延とPod/ALBのリソース利用を同一クエリで確認)
  • 運用効果: PromQLベースの統合ダッシュボードとアラートによりトラブルシューティングが迅速化。アノマリ検出により静的閾値設定の負担を軽減できます。
  • 導入負荷: 既存のOTelエクスポーターをCloudWatchのOTLPエンドポイントに向けるだけで導入可能(追加エージェントや大規模なコード変更は不要なケースが多い)

技術的な注意点

  • IAM権限: CloudWatchへのメトリクス書き込みやアラーム操作に必要な権限(例: PutMetricData相当の書き込み権限、アラーム作成用の権限)が必要です。コンソール操作用の権限も適切に設定してください。
  • リージョン制限: パブリックプレビューは US East (N. Virginia: us-east-1)、US West (Oregon: us-west-2)、Asia Pacific (Sydney: ap-southeast-2)、Asia Pacific (Singapore: ap-southeast-1)、Europe (Ireland: eu-west-1) のみで利用可能です。その他リージョンでは未対応です。
  • コスト: プレビュー期間中はOTelメトリクスの送信およびクエリに課金はありません。正式リリース後はCloudWatchのメトリクス保管、API呼び出し、ダッシュボード、アラーム等の通常料金が適用される可能性があるため事前に費用想定を行ってください。
  • 互換性/データ型: OTelのメトリクス名やラベル(attributes)がCloudWatchのメトリクス名、ディメンションにどのようにマップされるかをドキュメントで確認してください。ヒストグラムやサマリー表現、エクザンプル等のサポート状況や集約動作は実装に依存するため注意が必要です。
  • プレビューの注意: 公開プレビュー機能は仕様やAPIが変更される可能性があり、本番導入時は制約やSLAを確認してください。

参考情報


[Appstream 2 0] Amazon WorkSpaces Applications improves multi-session fleet management

概要

Amazon WorkSpaces Applicationsにマルチセッションフリート向けの「ドレインモード」が追加され、インスタンスが新規セッションの受付を停止しつつ既存セッションは継続させることで、メンテナンスやスケール操作時のユーザー切断を防げるようになりました。

変更内容・新機能の詳細

ドレインモードは、マルチセッションフリート上の個々のインスタンスに対して新しい接続を受け付けない設定を適用し、既に接続中のユーザーセッションは中断せずに継続できる機能です。これにより、保守作業(OS/ミドルウェアのパッチ適用など)、インスタンスの縮小、またはシステムアップデート時にユーザー体験を損なわずに対象インスタンスを段階的に空にできます。新規接続は自動的に他の空きインスタンスへ振り分けられるため、サービスの安定性を保ちながらリソース調整が行えます。マルチセッションフリートは1台のインスタンスで複数ユーザーをホスティングし、リソース効率とコスト最適化を図る仕組みですが、ドレインモード導入により運用上の柔軟性と停止の回避が向上します。追加料金は発生せず、WorkSpaces Applicationsが利用可能な全リージョンで提供されます(従量課金モデル)。

影響範囲・利用シーン

  • 対象ユーザー: VDI/仮想アプリケーションを運用するクラウド/仮想デスクトップ管理者、SRE、IT運用チーム
  • 利用シーン: 保守作業(パッチ適用、ソフトウェア更新)、インスタンスのスケールダウン、リソース入れ替えや障害対応時のユーザー切断回避
  • 運用効果: ユーザーの作業中断を防止しつつ段階的にインスタンスを空にできるため、メンテナンス時のエンドユーザー体験が向上し、計画的なスケール操作や更新導入が容易になる
  • コスト影響: 機能自体に追加料金はないが、ドレインにより一時的に必要台数が増える運用を選ぶとインスタンス利用料金に影響する可能性がある

技術的な注意点

  • IAM権限: フリートおよびインスタンスの変更(ドレイン設定)を行うためのWorkSpaces Applications関連の管理権限が必要です。詳細は公式ドキュメントで必要なAPI/アクションを確認してください。
  • リージョン制限: WorkSpaces Applicationsが利用可能な全リージョンで提供されます。サービス自体が未提供のリージョンでは利用できません。
  • コスト: ドレインモード自体に追加料金はありませんが、接続が他インスタンスへシフトすることで一時的に稼働インスタンス数が増減し、従量課金の総額に影響する場合があります。
  • 運用注意: ドレイン開始前にユーザーへ通知する運用プロセスや既存セッションの想定継続時間を考慮してください。長時間セッションが残る場合は段階的な運用計画が必要です。
  • 互換性/依存: 接続振り分けはWorkSpaces Applicationsのセッション管理ロジックに依存します。ロードバランサやブローカーの動作と合わせて事前にテストしてください。
  • 検証推奨: 本番導入前にステージング環境でドレインの挙動(新規接続遮断、既存セッション継続、スケールへの影響)を検証してください。

参考情報

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