AWS What's New Digest

Appearance

2026年07月07日 ​

[S3] Amazon S3 Express One Zone is now available in the AWS Europe (Frankfurt) Region ​

概要 ​

Amazon S3 Express One Zone ストレージクラスが AWS Europe (Frankfurt) (eu-central-1) リージョンで利用可能になりました。単一アベイラビリティゾーンでの一貫した単一桁ミリ秒アクセスを低コストで提供する、高性能向けのストレージクラスです。

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

S3 Express One Zone は単一のアベイラビリティゾーン（AZ）にデータを保存するストレージクラスで、頻繁にアクセスされるレイテンシーに敏感なワークロード向けに設計されています。AWS の発表によれば、S3 Standard と比べてデータアクセス速度は最大10倍、リクエストコストは最大80%低減されるとされており、単一桁ミリ秒の一貫した読み取りレイテンシーを目標にしています。用途としては、機械学習のトレーニングでの高速データ読み出し、インタラクティブ解析、AI検索エンジンのキー・バリューキャッシュなどが想定されています。今回の拡張により利用可能リージョンは合計8リージョンとなり、eu-central-1（Frankfurt）に追加されました。基本的に既存のS3 API、ライフサイクル、レプリケーション（SRR/CRR）やバージョニング等と互換性がありますが、単一AZ保存のためマルチAZ冗長性を必要とするデータ保護要件がある場合は、レプリケーションや別クラスへのライフサイクル移行を検討してください。料金や詳細な機能サポートは S3 の料金ページおよび公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、データサイエンティスト、機械学習エンジニア、SRE/運用担当者
  • 利用シーンまたは効果: 機械学習トレーニングデータの高速読み出し、インタラクティブ解析、レイテンシー重視のキャッシュ用途（AI検索のキー・バリュー層等）においてアクセス遅延を大幅に削減しコスト効率を改善
  • 運用効果: リクエストコスト削減（最大80%）および読み取りレイテンシー短縮（最大10x）が期待でき、推論や反復学習ワークロードのスループット向上に寄与
  • 可用性/耐久性への影響: データは単一AZに配置されるため、AZ障害に対する耐障害性はマルチAZ構成（S3 Standard）より低くなる。重要データはレプリケーションやバックアップの設計を要する
  • コスト: リクエストコストと読み取りレイテンシーのトレードオフでコスト最適化が可能。ストレージ単価やデータ転送・リクエストパターンによる影響を事前に試算・ベンチマーク推奨
  • リージョン: 新たに AWS Europe (Frankfurt) (eu-central-1) で利用可能。利用可能リージョンは合計8リージョン（詳細はドキュメント参照）

技術的な注意点 ​

  • IAM権限: 特別な権限は不要（通常のS3アクセス権限、バケットポリシー、IAMポリシーで制御）。
  • リージョン制限: 本発表で eu-central-1（Frankfurt）に追加。全リージョンで未対応の場合あり。利用前に対象リージョンでの提供可否を確認してください。
  • 耐久性/可用性: 単一AZ保存のためAZ障害時のデータ可用性が低下する可能性あり。高可用性が必要なデータはS3 Standardやクロスリージョン/同一リージョンレプリケーションを検討してください。
  • 互換性/機能制限: 基本的にはS3 APIやライフサイクル、バージョニング、レプリケーションと互換性があるが、特定の機能サポート可否（例: 一部の転送最適化やアーカイブとの自動階層化の挙動）はドキュメントで確認してください。
  • 検証: 実運用導入前にワークロードでのレイテンシ/スループット・コスト効果をベンチマークすることを推奨します。
  • コスト: リクエスト単価が低くなる一方で、ストレージ単価やデータ転送費、必要な冗長化対策による追加コストも勘案してください。

参考情報 ​

[EKS] Amazon EKS Auto Mode reduces GPU management fees by up to 60% ​

概要 ​

Amazon EKS Auto ModeのGPU/アクセラレータ向け管理料金が引き下げられました（2026年7月1日適用）。Gシリーズは管理料金が35%削減、PシリーズおよびAWS Trainiumは60%削減され、既存のAuto Modeクラスタにも自動適用されます。

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

Amazon EKS Auto Modeは、機械学習推論、ファインチューニング、レンダリング、バッチ処理などのアクセラレータ使用ワークロード向けにインフラを自動プロビジョニング・管理するフルマネージド機能です。今回の更新で、Gシリーズ（GPU）インスタンスのAuto Mode管理料金が35%引き下げられ、Pシリーズ（高性能GPU）およびAWS Trainium（推論/トレーニング向けアクセラレータ）は60%引き下げられます。これらの割引は2026年7月1日以降にEKS Auto Modeを利用しているすべてのクラスタへ自動的に適用され、ユーザー側の操作は不要です。EKS Auto Modeのアクセラレータ向け機能には、ローカルNVMeストレージを使ったGPUインスタンス上での並列イメージプルとアンパック（大きなコンテナ/モデルイメージの起動時間短縮）や、GPUハードウェア故障を検出して自動で不健全ノードを置換するアクセラレータ対応ノード修復が含まれます。管理料金の削減により、マネージドインフラでGPUワークロードを実行する総コスト効率が改善します。なお、インスタンスの使用料（EC2のコンピュート料金）自体は別途発生し、今回の変更はEKS Auto Modeの管理フィー（マネジメント料金）に対するものである点に注意してください。ECSのManaged Instancesでも同等の管理料金削減が実施されています。詳細な料金テーブルや最新情報はEKSの料金ページで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、レンダリング/メディア処理チーム、DevOps/SRE
  • 利用シーン: ML推論およびファインチューニング、バッチ推論ジョブ、レンダリングやメディア変換、アクセラレータを使う大規模コンテナ/モデル配布
  • 運用効果: 管理料金の削減によりマネージド環境でのGPUワークロード運用コストが低下し、インフラ運用負荷を減らしたままコスト効率を向上可能
  • コスト影響: Gシリーズ管理料金 -35%、Pシリーズ/AWS Trainium管理料金 -60%（インスタンス利用料は別途発生）
  • リージョン: EKS Auto Modeが利用可能なすべてのリージョンで適用（リージョンによる未対応状況がある場合はEKSのリージョンサポートを確認）

技術的な注意点 ​

  • 適用開始日: 料金改定は2026年7月1日適用で、既存のAuto Modeクラスタにも自動的に反映されます
  • IAM権限: Auto Modeの利用にはEKSクラスタおよび関連する自動プロビジョニング用のIAM権限が必要（既存のAuto Mode利用時と同様）
  • リージョン制限: 変更はEKS Auto Modeが提供されているリージョンで有効。Auto Mode自体が未提供のリージョンでは適用されません
  • コスト: 管理料金は削減されますが、EC2インスタンス（GPU/Trainium）の時間料金やストレージ、データ転送コストは別途発生します。総コストはワークロードの稼働時間やインスタンスタイプ構成で変動します
  • 互換性/機能: 並列イメージプルとNVMe利用、アクセラレータ対応ノード修復などはアクセラレータを搭載したインスタンスタイプで有効。詳細はEKSのAI/MLドキュメントを参照してください
  • 既存クラスタへの影響: ユーザー操作は不要で、管理料金の割引は自動適用されますが、請求書やコスト分析で新料金が反映されているか確認してください
  • 確認推奨: 最新の料金テーブル（リージョン別/インスタンスタイプ別）はEKS料金ページで必ず確認すること

参考情報 ​

[General] Amazon SageMaker HyperPod now supports disaggregated prefill and decode ​

概要 ​

Amazon SageMaker HyperPodがDisaggregated Prefill and Decode（DPD）をサポートしました。LLM推論のprefill（長コンテキスト処理）とdecode（トークン生成）を別々のGPUプールで実行し、KVキャッシュをEFAのGPU‑Direct RDMA経由で転送してレイテンシの安定化とスループット改善を実現します。

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

DPDはLLM推論を「prefill（入力コンテキストの埋め込み・KVキャッシュ生成）」と「decode（トークン生成）」の2フェーズに分離し、それぞれを独立したGPUリソース（プール）上で実行します。prefillは計算（compute）バウンド、decodeはメモリ／帯域（memory‑bandwidth）バウンドになりがちなため、同じGPUで両方を処理すると長コンテキスト要求が他の同時要求のトークン生成をブロックする問題が発生します。DPDではKVキャッシュをElastic Fabric Adapter（EFA）を経由したGPU‑Direct RDMAでフェーズ間転送することで、このリソース競合を解消します。

主な機能と挙動:

  • フェーズ分離: prefill用GPUプールとdecode用GPUプールを個別に構成して実行
  • KVキャッシュ転送: GPU‑Direct RDMA経由でEFA上にKVキャッシュを効率的に移動
  • インテリジェントルーティング: 長コンテキスト（長いプロンプト）をディスアグリゲート経路へ送る一方、短いプロンプトは直接デコーダへ送り、不要な転送オーバーヘッドを回避
  • 設定方法: 既存のHyperPod Inference Operatorで使うカスタムリソース（InferenceEndpointConfig）にpdSpecセクションを追加して有効化
  • 互換性: 既存のKVキャッシュオフロード機能やインテリジェントルーティングと併用可能
  • 対応環境: EKSオーケストレータ上のHyperPodクラスターで、EFA対応インスタンスタイプ上（HyperPodが利用可能な全リージョン）で利用可能

期待される効果: 継続的な同時実行下でのトークン毎レイテンシの安定化、厳しいレイテンシSLO下での良好なスループット（goodput）向上、prefill/decodeの個別スケーリングによるリソース最適化。

影響範囲・利用シーン ​

  • 対象ユーザー: LLMを本番運用しているSRE/MLエンジニア、推論プラットフォーム運用者、チャットアシスタントやエージェントパイプラインを動かす開発チーム
  • 利用シーンまたは効果: 長文コンテキストを扱うチャット、RAG（retrieval‑augmented generation）、長文解析などで一貫したトークン当たりレイテンシと予測可能なスループットを実現
  • 運用効果: prefillとdecodeの過剰プロビジョニング削減、SLOに応じた良好なgoodput確保、短プロンプトと長プロンプトを適切に振り分けることで無駄なデータ転送を回避
  • スケーリング影響: prefill容量とdecode容量を独立して拡張可能になり、入力（長さ）と出力（生成速度）の比率に合わせた最適化が可能
  • コスト影響: GPUプールを分離するためインスタンス数構成が変わる可能性があり、KV転送でネットワーク使用量が増える場面では追加のコスト要因になり得る（短プロンプトはルーティングで転送を回避）

技術的な注意点 ​

  • IAM権限: InferenceEndpointConfig等のカスタムリソースを更新するためのEKS/HyperPod関連の権限（Kubernetes RBACおよびSageMaker/EC2関連のIAMロール）を確認してください
  • リージョン制限: HyperPodが利用可能な全リージョンでEFA対応インスタンスタイプ利用時に提供されていますが、まず自リージョンのサポート状況を確認してください
  • インスタンス要件: EFA対応のGPUインスタンスタイプが必要です（EFAをサポートするインスタンスファミリ／世代を確認）
  • ドライバ／OS要件: EFAドライバ、ENA、NVIDIAドライバ／CUDAなどGPU‑Direct RDMAをサポートするソフトウェアスタックの適切なバージョンが必要です
  • ネットワーク・セキュリティ: EFAを用いるためENI設定、セキュリティグループ、サブネット設計を確認し、RDMA通信経路が許可されていることを確認してください
  • 設定手順: 既存のInferenceEndpointConfigにpdSpecセクションを追加して有効化します。変更はKubernetes上のカスタムリソース更新になるため、ロールアウト計画（カナリア／段階的適用）を推奨します
  • 互換性: 既存のKVキャッシュオフロード機能やインテリジェントルーティングと併用可能ですが、運用時にルーティングポリシーやキャッシュオフロード設定との相互作用を検証してください
  • コスト: フェーズ分離に伴いGPU台数やネットワーク転送量が変化します。SLOとコストのトレードオフを事前に評価してください
  • テスト推奨: 長・短プロンプト混在の負荷試験を実施し、トークン毎レイテンシ、スループット、KV転送レイテンシを計測してSLO達成状況を確認してください

参考情報 ​

[Cognito] Amazon Cognito now supports self-service provisioned API rate limits ​

概要 ​

Amazon Cognitoで、プロビジョンド（購入可能な）APIレート上限をセルフサービスで増減できるようになりました。コンソールまたは新しいプロビジョニングAPIで即時反映の調整が可能です。

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

従来、CognitoのAPIレート上限を引き上げるにはService Quotas経由で手動レビューを伴う申請が必要で、事前の容量計画が求められていました。今回の変更により、リージョンごとのデフォルト上限とは別に購入できる“プロビジョンド（adjustable）APIカテゴリ”について、コンソールまたは新しいLimit Provisioning API操作を使って、アカウントレベルの最大値までセルフサービスで上限を増減できます。変更は即時に適用され、アプリケーションのトラフィックパターンに応じて迅速に調整可能です。対象は「調整可能なAPIカテゴリ」のみで、全てのAmazon Cognito提供リージョンで利用可能です。プロビジョンド上限は追加料金の対象となるため、料金詳細はCognitoの料金ページを参照してください。なお、アカウントレベルを超える上限引き上げは従来どおりService Quotas経由の申請が必要になる可能性があります。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、SRE/運用チーム、プロダクト担当者（ユーザープールを多用するウェブ/モバイルアプリ運用者）
  • 利用シーン: 予測不能なトラフィック急増時の一時的なスロットル回避、負荷テスト時の高スループット確保、季節イベントやプロモーション前後の短期的な容量最適化
  • 運用効果: レート上限を即時に上下できるため、事前の過剰なキャパシティ計画や手動の増枠申請を減らし、スロットリングによるユーザー影響を低減できる

技術的な注意点 ​

  • IAM権限: コンソール操作やプロビジョニングAPI呼び出しには該当するCognitoおよびService Quotas関連のIAM権限が必要です。ドキュメントで必要なアクションを確認してください。
  • リージョン制限: 全てのAmazon Cognito提供リージョンで利用可能と記載されていますが、各リージョンごとのアカウント上限や対応APIカテゴリは確認してください。
  • コスト: プロビジョンド上限は追加料金が発生するアドオンです。料金体系はCognitoの料金ページを参照のこと。
  • 適用の即時性: 変更は即時反映されます。即時反映に基づく負荷変動への対応設計（バースト、キャパシティ不足の監視）を行ってください。
  • アカウント上限: セルフサービスで設定できるのはアカウントレベルの最大値までです。最大値を超える増枠は従来どおりService Quotasなどで別途申請が必要になる場合があります。
  • 対象APIカテゴリ: すべてのCognito APIが対象ではなく「adjustable API categories」に限定されています。どのAPIカテゴリが調整可能かは開発者ガイドで確認してください。
  • 監視: CloudWatchメトリクスやログでレートやスロットリング（Throttles）を監視し、自動化やアラートと組み合わせて運用すると効果的です。
  • 既存フローとの互換性: これまでのService Quotas経由の手動申請は引き続き利用可能です。自動化したい場合は新しいプロビジョニングAPIを組み込みください。

参考情報 ​

[SageMaker] Amazon SageMaker Studio now integrates with Hugging Face for one-click model deployment and customization ​

概要 ​

Amazon SageMaker StudioがHugging Faceと直接連携し、Hugging Face上で見つけたモデルをワンクリックで事前設定済みのStudio環境に取り込んでカスタマイズやデプロイができるようになりました。新規ユーザーは秒でStudio環境が作成され、検証済みユーザーはGPUクォータの追加申請なしで主要インスタンスが利用可能になります。

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

・ワンクリック連携: Hugging Faceのサポート対象モデル画面で「Customize on SageMaker AI」または「Deploy on SageMaker AI」を選ぶと、該当モデルがプリロードされた状態でSageMaker Studioの対応ワークフロー（カスタマイズ／デプロイ）に直接遷移します。 ・事前設定されたStudio環境: 新規アカウントは標準のAWSサインアップを完了すると、サーバーレスによるモデルカスタマイズ（ファインチューニング、強化学習のカスタム報酬関数を含む）、モデル評価、SageMakerまたはAmazon Bedrockへのデプロイが行える権限や設定が事前構成されたStudio環境を数秒で受け取ります。 ・検証済み顧客向けGPUアクセス: 検証済みユーザーはエンドポイント・トレーニングジョブ・ノートブックでG5、G6、G4dnインスタンスタイプへのデフォルトアクセスが提供され、個別にService QuotasでGPUクォータ増加を申請する必要がありません。 ・クォータ表示と管理: 各インスタンスタイプごとのクォータ上限と使用状況がStudio内で確認可能になり、リソース管理が容易になります。 ・リージョン対応: Amazon SageMaker StudioがサポートするすべてのAWS商用リージョンで利用可能です。 ・ユースケース: モデル探索からすぐに実行環境へ移行できるため、実験の立ち上げ時間が短縮され、モデルのカスタマイズ（ファインチューニング／強化学習）、評価、エンドポイントデプロイまでのワークフローが簡素化されます。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、MLプラットフォーム/DevOpsチーム
  • 利用シーンまたは効果: Hugging Faceで見つけた事前学習モデルを短時間でStudioに取り込み、サーバーレスでのカスタマイズ（ファインチューニング、強化学習のカスタム報酬関数含む）や評価、SageMaker/Bedrockへのデプロイを迅速に実行可能
  • 導入コスト削減: 初期設定・IAM構成・クォータ申請の手間が削減され、PoCや実験の立ち上げコストが低減
  • 運用効果: Studio内でインスタンスごとのクォータ可視化が可能なため、リソース管理と容量計画が容易になり、GPUクォータ申請による待ち時間を短縮

技術的な注意点 ​

  • IAM権限: 新規環境はサーバーレスカスタマイズ用の権限が事前構成されるが、組織のセキュリティ要件に応じて追加のIAMポリシーや限定化が必要になる場合があります。事前構成の権限内容は確認してください。
  • リージョン制限: 本機能はAmazon SageMaker Studioがサポートする全てのAWS商用リージョンで利用可能ですが、各リージョンでのモデル・インスタンスタイプの可用性は異なるため事前確認が必要です。
  • コスト: GPUインスタンス、トレーニング・推論実行、ストレージ、データ転送などの通常の使用料が発生します。検証済みユーザーにクォータが付与されても利用に伴う課金は発生しますので、コスト見積もりとモニタリングを行ってください。
  • Service Quotas: 検証済みユーザー向けに主要GPUインスタンスのデフォルトアクセスが提供されますが、追加リソースが必要な場合は個別にクォータ管理が必要です。Studio内でクォータと利用状況を確認してください。
  • モデルライセンスとガバナンス: Hugging Face上のモデルは各モデルのライセンスに従う必要があります。商用利用や派生物の扱いについてはモデルページのライセンス／制約を確認し、データプライバシーとセキュリティ要件を満たす運用フローを設計してください。
  • データ保護/コンプライアンス: モデルの学習・評価に用いるデータが機密データの場合、転送先（SageMaker/Bedrock）や保存ポリシー、ログの取り扱いについてコンプライアンス要件を確認してください。
  • 特権ユーザーの管理: ワンクリックで環境が作成されるため、誰が起動できるかの管理・監査を組織内で整備してください。

参考情報 ​

[General] Amazon EVS VCF 9.0 and 9.1 support ​

概要 ​

Amazon Elastic VMware Service (EVS)がVMware Cloud Foundation (VCF) 9.0および9.1をサポートしました。VCFをEC2ベアメタル上のAmazon VPC内で稼働させ、インストールや運用・管理をユーザー側でフルコントロールできます。

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

今回のリリースにより、Amazon EVS上でVCF 9.0および新たにリリースされたVCF 9.1を直接実行可能になりました。EVSはEC2のベアメタルインスタンス上でVMwareのソフトウェアスタックを稼働させるため、オンプレミスで用いているインストール手順、運用ツール、既存のスキルやプロセスをそのまま活かしてクラウド上のVCF環境を構築・管理できます。運用はお客様自身で行うか、経験あるAWSパートナーと協業して実施できます。加えて、導入支援を目的とした「Solutions for EVS」GitHubリポジトリ（サンプル、テンプレート、Infrastructure as Codeアーティファクトを提供）が公開され、初期構築や自動化の出発点が用意されています。本機能はAmazon EVSが提供されているすべてのリージョンで利用可能です（リージョンごとの在庫・クォータは別途確認が必要）。

影響範囲・利用シーン ​

  • 対象ユーザー: オンプレミスでVMwareを運用しているIT運用者、クラウド移行担当、プラットフォーム/インフラアーキテクト、SRE/運用チーム
  • 利用シーン: データセンターからのワークロード移行、ハイブリッドクラウド構成、DR/試験環境のクラウド化、既存VMware運用プロセスを維持したままのクラウド移行
  • 運用効果: 既存の運用ツール・スキルを活かして短期間でVCF環境を構築可能。パートナーと組むことで導入負荷や運用の外部委託が容易になる一方、ベアメタルリソース利用に伴うコストと容量管理が必要

技術的な注意点 ​

  • 必要な基盤: Amazon EVSはEC2のベアメタルインスタンス上で動作するため、ベアメタルインスタンスの利用可否・クォータ・確保を事前確認してください
  • IAM権限: EVS／EC2／VPC等のリソース作成・管理に必要なIAM権限を用意する必要があります（運用自動化を行う場合は追加の権限設計が必要）
  • ライセンス: VCF/VMwareのライセンス取り扱い（BYOLやサポートモデル）を事前に確認してください。VMware側のライセンス・サポート要件は継続して適用されます
  • ネットワーク／接続: VPC、サブネット設計、ルーティング、Direct ConnectやVPN経由でのオンプレ連携などネットワーク要件を設計してください。NSX/SDN連携などVMware固有設定も考慮が必要です
  • リージョン制限: 記事では"Amazon EVSが提供されているすべてのリージョン"で利用可能とされていますが、実際の提供可否・キャパシティはリージョンごとに異なるため、AWSコンソールでの確認と事前調達（capacity reservation等）を推奨します
  • コスト: ベアメタルインスタンスの利用料金、ストレージ・ネットワーク転送費用、VMwareライセンス費用、パートナー支援費用などが発生します。費用見積りを事前に行ってください
  • 運用責任: 記事のとおりインストール／運用／管理はユーザー側で行う前提です。ライフサイクル管理（パッチ適用、アップグレード、バックアップ/リカバリ）の責任範囲を明確にしてください
  • IaC／自動化: Solutions for EVS GitHubリポジトリにテンプレートやコード例が提供されています。導入の自動化・再現性確保に活用できます（詳細はリポジトリ参照）

参考情報 ​

[Certificate Manager] AWS Certificate Manager now supports the ACME protocol for public certificates ​

概要 ​

AWS Certificate Manager (ACM) が ACMEv2 プロトコルに対応し、ACM が管理する ACME サーバー経由で Certbot、cert-manager、acme.sh などの ACME クライアントから公開 TLS 証明書（有効期限45日、Amazon Trust Services発行）を自動発行・更新できるようになりました。

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

ACM によりフルマネージドの ACME エンドポイントを作成でき、ACMEv2 互換クライアントを使って公開証明書を発行・更新できます。発行される公開証明書は Amazon Trust Services によるもので有効期間は45日です（CA/Browser Forum の短期化規制に対応）。PKI 管理者はエンドポイント単位でドメインスコープを定義して、どのクライアントがどのドメインで証明書を発行できるかを制限したり、ワイルドカード使用の可否をポリシーで強制したりできます。ドメイン検証はエンドポイント作成時に一度行われ、以後アプリケーションチームは自身の ACME クライアントから証明書をリクエストできるため、DNS 資格情報を共有する必要がありません。すべての操作は ACM コンソールで確認でき、AWS CloudTrail による操作ログや Amazon CloudWatch メトリクスで監査・モニタリングが可能です。ACM の ACME サポートはすべての商用 AWS リージョンで利用可能です。料金は ACM の料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドアプリケーション開発者、SRE/運用チーム、PKI 管理者
  • 利用シーン: 大量の短命公開証明書を自動発行・自動更新する必要があるウェブ/マイクロサービス、Kubernetes クラスタ上の cert-manager 統合、CI/CD パイプラインでの自動化
  • 運用効果: DNS 資格情報を共有せずにアプリチームへ発行権限を委譲でき、証明書の手動更新作業や失効リスクを大幅に低減できる

技術的な注意点 ​

  • IAM権限: ACME エンドポイントの作成・管理や証明書発行には適切な ACM/IAM 権限が必要です（IAM ポリシーで最小権限を検討してください）
  • リージョン制限: 記事では「全ての商用リージョンで利用可能」とされていますが、GovCloud/中国リージョンなど一部リージョンは対象外の可能性があるため利用前に確認してください
  • コスト: ACM の料金体系が適用されます。エンドポイントや証明書発行に追加料金が発生する場合があるため ACM 料金ページを確認してください
  • クライアント互換性: ACMEv2 に準拠したクライアント（Certbot、cert-manager、acme.sh など）で利用可能。ただしクライアント側の設定（エンドポイント URL、アカウント登録など）が必要です
  • ドメイン検証: ドメイン検証はエンドポイント側で一度実施される設計のため、以後の証明書取得で DNS/HTTP 資格情報をアプリ側に渡す必要がない点が運用上の利点です
  • ワイルドカード/ポリシー: 管理者はワイルドカード発行の可否や発行範囲を制御できます。ポリシー制御を適切に設定しないと想定外の発行が行われる可能性があります
  • 監査/モニタリング: すべての ACME 呼び出しや証明書操作は CloudTrail ログと CloudWatch メトリクスで確認可能です。監査要件がある場合はログ保存とアラート設定を検討してください

参考情報 ​

[General] CloudWatch Application Signals now automatically captures errors, performance anomalies, and deployment events ​

概要 ​

CloudWatch Application SignalsにService Events機能が追加され、アプリケーションをInstrument（ADOT SDKまたはCloudWatch Observability EKSアドオン）していれば、追加のコード変更なしで例外スナップショット、レイテンシーイベント、関数レベルのパフォーマンスデータ、デプロイイベントを自動で収集できるようになりました。

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

Service Eventsは、CloudWatch Application Signalsが有効化されたアプリケーションから自動的にイベントデータを収集します。収集対象は例外スナップショット（エラー発生時の情報）、レイテンシーイベント（高遅延のスナップショット）、デプロイメントイベント、およびオプションで有効化する関数呼び出しレベルのメトリクスです。データは例外やレイテンシーのスナップショットとしてログに保存され、関数呼び出しメトリクスはOpenTelemetry形式のメトリクスとしてキャプチャされます。アプリの計装はAmazon Distro for OpenTelemetry（ADOT）SDKまたはAmazon CloudWatch Observability EKSアドオンを利用します。Application Signalsがアクティブになると自動でデータ収集が開始され、より詳細な関数レベルの可視化が必要な場合は関数呼び出しメトリクスをオンにすることで深掘りできます。対応言語はJava、Python、JavaScriptで、全ての商用AWSリージョンで利用可能です。料金は標準のCloudWatch課金が適用されます。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、SRE、アプリケーションの運用チーム
  • 利用シーンまたは効果: デプロイ後に新しい例外やパフォーマンス劣化が発生したかを迅速に判定（CloudWatchコンソール → Application Signals → [Service] → Errorsから確認可能）
  • 運用効果: デプロイが原因の障害切り分けが高速化され、監視・トラブルシュート工数が削減される
  • 導入負荷: ADOT SDKまたはEKS用オブザーバビリティアドオンによる計装が前提で、既にApplication Signalsを有効にしていれば追加のコード変更は不要
  • 可観測性の向上: 関数レベルのメトリクス（OpenTelemetry）を有効化することでホットスポットや高コスト処理箇所を特定しやすくなる

技術的な注意点 ​

  • IAM権限: CloudWatch LogsおよびCloudWatch Application Signals関連のWrite権限が必要（ADOTやEKSアドオンのインストール時に適切なIAMロールを付与）
  • リージョン制限: 全ての商用AWSリージョンで利用可能（パブリック/政府リージョンの対応状況は要確認）
  • コスト: データはCloudWatchのログとメトリクスとして扱われ、標準のCloudWatch課金が適用される。ログ取り込み・保持やメトリクスの数に応じて追加コストが発生する可能性あり
  • 対応言語: Java、Python、JavaScriptをサポート。これ以外の言語は現時点で未サポートのため別途計装や対応が必要
  • データ収集・保存形式: 例外/レイテンシーイベントはログとして保存。関数呼び出しメトリクスはOpenTelemetryメトリクスとして収集される
  • 導入手順・注意点: ADOT SDKまたはCloudWatch Observability EKSアドオンでアプリを計装し、Application Signalsを有効にするだけで自動収集が開始。関数呼び出しメトリクスはオプションで明示的に有効化する必要がある
  • プライバシー/セキュリティ: 収集されるスナップショットに機密情報が含まれる可能性があるため、ログのマスキングやフィルタリング、保持ポリシーを設定することを推奨

参考情報 ​

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

Copyright © 2026