はじめに
2026 年 6 月 4 日、AWS は Amazon EKS Capabilities に対して、CloudWatch Vended Logs によるログ配信サポートを発表しました。Argo CD・ACK・kro のマネージドコントローラーログを、AWS の標準ログ基盤を通じて収集・監視できるようになります。
EKS Capabilities を本番運用しているエンジニアの方は、コントローラーのログをどうやって確認していたでしょうか。デプロイが失敗したとき、AWS リソースの操作履歴を追いたいとき、リソースグループが思い通りに構築されないとき。マネージドコントローラーは AWS 管理インフラ上で動いているため、これまでログへのアクセス手段がほとんどありませんでした。今回のアップデートはこの「見えない」問題に直接応えるものです。
本記事では「何が変わったのか」「どのように設定するのか」「どのユースケースで活用できるのか」「コストをどう考えるのか」を中心に解説します。EKS Capabilities をすでに利用しているエンジニアはもちろん、これから導入を検討している方やプラットフォームエンジニアリングの可観測性強化に興味がある方にも、ぜひ読んでいただきたい内容です。
何が変わったのか
EKS Capabilities を利用したことがある方なら、マネージドコントローラーの状態把握がいかに難しかったかをご存じかと思います。
| 項目 | Before | After |
|---|---|---|
| コントローラーログへのアクセス | 手段なし | CloudWatch Vended Logs で収集可能 |
| トラブルシューティング | ログが参照できず手探りの調査 | ログを直接参照して迅速に原因特定 |
| リアルタイム監視・アラート設定 | 不可 | CloudWatch Logs でアラート設定可能 |
| ログの長期保存 | 不可 | Amazon S3 への配信で実現 |
| 外部 SIEM / データレイク連携 | 不可 | Kinesis Data Firehose 経由で実現 |
| EKS 側の追加料金 | ― | なし |
従来の課題
EKS Capabilities の Argo CD・ACK・kro は、AWS が管理するインフラ上でコントローラーが動作しています。この構成はユーザーがインフラの運用負荷を持たなくて済むというメリットがある一方、コントローラーが生成するログにユーザーが直接アクセスする手段がありませんでした。
Argo CD のアプリケーション同期が失敗した原因を調べたい場面でも、ACK が AWS リソースを期待通りに作成しているかを確認したい場面でも、手がかりになるログを参照できないまま対処せざるを得ない状況が続いていました。
CloudWatch Vended Logs によるログ配信で何ができるようになったか
今回の対応で、各 Capability を CloudWatch Vended Logs の配信ソースとして設定できるようになりました。ログの配信先は CloudWatch Logs・Amazon S3・Amazon Kinesis Data Firehose の 3 種類から選択でき、CloudWatch API または AWS コンソールから Capability ごとに個別に有効化できます。
AWS 側がログ収集と配信を担うため、信頼性が高くセキュアなログ配信が保証されます。EKS 側の追加料金は発生しません。
CloudWatch Vended Logs の仕組みとコスト
CloudWatch Vended Logs とは
CloudWatch Vended Logs は、AWS サービスがユーザーに代わってログを生成・配信する仕組みです。ログの収集は AWS 側が担うため、ユーザーがログ収集エージェントを自前で配置・管理する必要はありません。VPC フローログや EKS コントロールプレーンログなど、多くの AWS サービスがすでにこの仕組みを採用しており、今回の EKS Capabilities もその対象に加わりました。
EKS Capabilities のコントローラーはユーザーのクラスター内には存在せず AWS 管理インフラ上で動作しているため、通常のエージェントベースのログ収集は機能しません。AWS 側がログの収集から転送まで担う Vended Logs の仕組みが、この構成に適しています。
コストの考え方
発生するのは、選択した配信先に応じた CloudWatch Vended Logs の標準料金のみです。配信料金にはボリューム段階制が採用されており、月間の配信量が増えるほど 1 GB あたりの単価が下がります。
| 配信先 | 開始単価（us-east-1） | 最低単価 | 追加で発生する料金 |
|---|---|---|---|
| CloudWatch Logs | $0.50 / GB | $0.05 / GB | ログ保存料金・Logs Insights クエリ料金 |
| Amazon S3 | $0.25 / GB | $0.05 / GB | S3 ストレージ料金 |
| Kinesis Data Firehose | $0.25 / GB | $0.05 / GB | Firehose 取り込み料金 |
料金はリージョンや配信量によって異なります。最新の単価は Amazon CloudWatch 料金ページ をご確認ください。マルチアカウント構成では段階制の適用がアカウント単位になるため、組織全体での合算にはならない点にも注意してください。
配信先の選び方
3 つの配信先はそれぞれ得意とする用途が異なります。コスト以外にも、リアルタイム性・分析方法・外部連携の要件が選択に影響します。
| CloudWatch Logs | Amazon S3 | Kinesis Data Firehose | |
|---|---|---|---|
| ログのリアルタイム参照 | ✅ 即時参照可能 | ❌ 不可 | △ 配信先による |
| CloudWatch Alarms との連携 | ✅ 直接設定可能 | ❌ 不可 | ❌ 不可 |
| Logs Insights によるクエリ | ✅ 対応 | ❌ 別途 Athena 等が必要 | ❌ 不可 |
| 長期保存・コスト効率 | △ 別途保存料金が発生 | ✅ 低コストで長期保存可能 | △ 配信先による |
| 外部 SIEM / ツールへの配信 | △ 別途設定が必要 | △ 別途連携が必要 | ✅ OpenSearch・Splunk 等に直接配信 |
| コンプライアンス・監査対応 | △ 保存期間の設定が必要 | ✅ ライフサイクルポリシーで管理 | △ 配信先による |
CloudWatch Logs を選ぶ場合
すでに CloudWatch を運用監視に利用しているチームには CloudWatch Logs が最も馴染みやすい選択肢です。ログを即時に参照できるうえ、Logs Insights によるアドホッククエリや、Metric Filters を使ったエラーログからのアラーム自動生成など、既存の CloudWatch エコシステムとそのまま組み合わせて使えます。ただし、ログ保存料金や Logs Insights のクエリ料金が別途発生するため、ロググループの保存期間は適切に設定してコストを抑えることを推奨します。
Amazon S3 を選ぶ場合
ACK による AWS リソース操作の監査ログを長期間保存したい、コンプライアンス要件への対応が必要といった場合は S3 が適しています。CloudWatch Logs と比べて開始単価が低く、ライフサイクルポリシーを組み合わせることで S3 Glacier への自動移行も可能です。ログを参照・分析する際は Amazon Athena などのツールが別途必要になりますが、頻繁にアクセスしないログの長期保管用途であれば最もコストを抑えられる選択肢です。
Kinesis Data Firehose を選ぶ場合
OpenSearch Service・Splunk・Sumo Logic・Datadog といった外部のオブザーバビリティプラットフォームにログをストリーミングしたい場合は Kinesis Data Firehose が適しています。kro によるリソースオーケストレーションのデバッグを既存の SIEM 基盤で行いたい場合や、複数サービスのログを一元的に分析するデータレイクへの取り込みにも向いています。
まず迷ったら
EKS Capabilities の導入初期段階や、すでに CloudWatch を中心にオブザーバビリティを構築しているチームであれば、まず CloudWatch Logs から始めるのが最もシンプルです。運用が進んでコストや用途が明確になってきた段階で、監査ログは S3、外部分析基盤との連携は Kinesis Data Firehose というように配信先を使い分けていくアプローチが現実的です。
設定方法
本機能の設定は、AWS コンソールから行う方法と CloudWatch API を使う方法の 2 種類があります。どちらも Capability ごとに個別に設定します。
設定の流れ（3 ステップ）
CloudWatch API を使う場合、以下の 3 ステップで完結します。
| ステップ | API | 内容 |
|---|---|---|
| ① | PutDeliverySource |
EKS Capability を Vended Logs の配信ソースとして登録 |
| ② | PutDeliveryDestination |
ログの送信先（CloudWatch Logs・S3・Kinesis Firehose）を登録 |
| ③ | CreateDelivery |
配信ソースと配信先を紐付け |
ログタイプ一覧
PutDeliverySource の logType パラメータには、Capability・コンポーネント別に以下の値を指定します。
| Capability | logType | 対象コンポーネント |
|---|---|---|
| ACK | EKS_CAPABILITY_ACK_LOGS |
ACK コントローラー |
| Argo CD | EKS_CAPABILITY_ARGOCD_APPLICATION_LOGS |
Application コントローラー |
| Argo CD | EKS_CAPABILITY_ARGOCD_APPLICATIONSET_LOGS |
ApplicationSet コントローラー |
| Argo CD | EKS_CAPABILITY_ARGOCD_COMMITSERVER_LOGS |
Commit サーバー |
| Argo CD | EKS_CAPABILITY_ARGOCD_REPOSERVER_LOGS |
Repo サーバー |
| Argo CD | EKS_CAPABILITY_ARGOCD_SERVER_LOGS |
API サーバー |
| kro | EKS_CAPABILITY_KRO_LOGS |
kro コントローラー |
Argo CD はコンポーネント単位でログタイプが分かれています。デプロイ失敗の調査であれば ARGOCD_APPLICATION_LOGS、Git リポジトリとの接続問題であれば ARGOCD_REPOSERVER_LOGS というように、目的に応じて必要なログタイプのみ有効化できます。
AWS CLI での設定例（CloudWatch Logs への配信）
CloudWatch Logs を配信先とする Argo CD API サーバーログの設定例です。
① 配信ソースの作成
aws logs put-delivery-source \
--name "argocd-server-source" \
--resource-arn "<Capability の ARN>" \
--log-type "EKS_CAPABILITY_ARGOCD_SERVER_LOGS" \
--region ap-northeast-1
② 配信先の作成
aws logs put-delivery-destination \
--name "eks-capability-cw-destination" \
--delivery-destination-configuration \
'{"destinationResourceArn": "arn:aws:logs:ap-northeast-1:<アカウント ID>:log-group:/aws/vendedlogs/eks/capabilities/argocd"}' \
--region ap-northeast-1
CloudWatch Logs を配信先とする場合、/aws/vendedlogs/ プレフィックス付きのロググループは自動的に作成されます。それ以外のロググループ名を使用する場合は、事前にロググループを手動で作成しておく必要があります。
③ 配信の作成
aws logs create-delivery \
--delivery-source-name "argocd-server-source" \
--delivery-destination-arn "<② で取得した配信先の ARN>" \
--region ap-northeast-1
S3 や Kinesis Data Firehose を配信先とする場合は、② の destinationResourceArn に各リソースの ARN を指定します。手順自体は同じです。
必要な IAM 権限
設定を行う IAM ロールには、CloudWatch Logs の配信 API（logs:PutDeliverySource・logs:PutDeliveryDestination・logs:CreateDelivery）に加え、EKS Capability リソースに対する Vended Logs 配信の許可、および選択した配信先へのアクセス権限が必要です。配信先ごとに必要な権限の詳細は Amazon CloudWatch Logs ユーザーガイド（英語） をご参照ください。
ユースケース別 活用シーン
各 Capability のログを実際の運用でどう活用できるか、具体的なシナリオを紹介します。
Argo CD：GitOps パイプラインの障害を素早く特定する
Git にコードをプッシュしたにもかかわらず、Argo CD 上でアプリケーションが期待通りに同期されないケースがあります。これまではどのコンポーネントに問題があるかを外側から推測するしかありませんでした。
Argo CD のコントローラーログを CloudWatch Logs へ配信することで、状況が変わります。EKS_CAPABILITY_ARGOCD_APPLICATION_LOGS では Application コントローラーが検知したドリフトや同期失敗の詳細を、EKS_CAPABILITY_ARGOCD_REPOSERVER_LOGS では Git リポジトリとの接続・マニフェスト取得の問題をそれぞれ確認できます。CloudWatch Metric Filters を組み合わせてエラーログから自動的にアラームを生成しておけば、デプロイ失敗を検知してからの対応時間を短縮できます。
Argo CD はコンポーネント単位でログタイプが分かれているため、問題の切り分けも精度よく行えます。
ACK：AWS リソース操作の履歴を監査ログとして保存する
Kubernetes マニフェストから RDS インスタンスや S3 バケットを作成・変更しているチームにとって、「いつ・誰が・どのリソースを・どのような内容で変更したか」という操作履歴の保存はコンプライアンス上の要件になることがあります。しかしこれまで、ACK コントローラーが行った操作の記録を長期保存する手段がありませんでした。
EKS_CAPABILITY_ACK_LOGS を Amazon S3 へ配信することで、ACK による AWS リソース操作のログを低コストで長期保存できます。ログの分析が必要になった際は Amazon Athena を使ったアドホッククエリで迅速に内容を参照できます。
kro：複雑なリソースグループの作成失敗を根本原因から追う
kro では、複数の Kubernetes リソースや AWS リソースを組み合わせた高レベルな抽象化（ResourceGroup）を定義できます。リソース間の依存関係が複雑なほど、どのリソースの生成が失敗してグループ全体が止まっているのかを追うことが難しく、デバッグに時間がかかりがちでした。
EKS_CAPABILITY_KRO_LOGS を配信することで、kro コントローラーがリソースグループを処理する過程のログにアクセスできるようになります。開発・デバッグのフェーズでは CloudWatch Logs Insights を使ってリソース名やエラーメッセージで素早くログを絞り込めます。本番環境で既存の SIEM 基盤や OpenSearch と連携している場合は Kinesis Data Firehose 経由で配信先を統一することで、他サービスのログと横断的な分析が可能になります。
まとめ
今回の発表により、EKS Capabilities のマネージドコントローラーログに初めてアクセスできるようになりました。「ブラックボックス」だった Argo CD・ACK・kro の動作が可視化され、本番運用での可観測性が改善されます。EKS Capabilities をすでに利用しているチームであれば、追加の EKS コストなしに今すぐ設定できます。