Amazon EKS Capabilities now supports Amazon CloudWatch Vended Logs
Until now, logs from EKS Capabilities managed controllers running on AWS-managed infrastructure were inaccessible. This article covers how to choose a log destination, configure delivery via the CLI, and apply the feature across Argo CD, ACK, and kro use cases.
Introduction
On June 4, 2026, AWS announced CloudWatch Vended Logs support for Amazon EKS Capabilities. You can now collect and monitor managed controller logs from Argo CD, AWS Controllers for Kubernetes (ACK), and kro through AWS's standard logging infrastructure.
If you've been running EKS Capabilities in production, you may have wondered how to access controller logs. Whether you're investigating a failed deployment, tracing the history of AWS resource operations, or debugging a resource group that isn't building as expected — until now, there was virtually no way to access logs from managed controllers running on AWS-managed infrastructure. This update directly addresses that visibility gap.
This article covers what changed, how to configure log delivery, real-world use cases for each capability, and how to think about costs. Whether you're already using EKS Capabilities or exploring ways to strengthen observability in your platform engineering stack, read on.
What Changed
If you've worked with EKS Capabilities, you know how difficult it has been to understand the state of managed controllers.
| Before | After | |
|---|---|---|
| Controller log access | No access | Available via CloudWatch Vended Logs |
| Troubleshooting | Manual investigation without log visibility | Direct log access for faster root cause analysis |
| Real-time monitoring and alerting | Not available | Alerts configurable via Amazon CloudWatch Logs |
| Long-term log retention | Not available | Achievable with Amazon S3 delivery |
| External SIEM / data lake integration | Not available | Streaming via Amazon Kinesis Data Firehose |
| Additional EKS charges | — | None |
The Challenge Before
EKS Capabilities — Argo CD, ACK, and kro — run their controllers on AWS-managed infrastructure, outside of your cluster. While this eliminates the need to install, maintain, or scale these components yourself, it also meant there was no way to directly access the logs those controllers generate.
Whether you were investigating why an Argo CD application sync failed or trying to confirm that ACK was provisioning AWS resources correctly, you had to work without the log visibility that troubleshooting typically requires.
What You Can Do Now
With this update, each Capability can be configured as a CloudWatch Vended Logs delivery source. Logs can be delivered to Amazon CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose, configured individually per capability via the CloudWatch APIs or the AWS Management Console.
AWS handles log collection and delivery on your behalf, providing reliable and secure log delivery. There is no additional EKS charge for this feature.
How CloudWatch Vended Logs Works and Pricing
What Are CloudWatch Vended Logs?
CloudWatch Vended Logs is a mechanism where AWS services generate and deliver logs on your behalf. Because AWS handles log collection, you don't need to deploy or manage log collection agents. Many AWS services already use this approach — including VPC Flow Logs and Amazon EKS control plane logs — and EKS Capabilities now joins that list.
EKS Capabilities controllers run on AWS-managed infrastructure and are not present within your cluster, which means agent-based log collection doesn't apply here. CloudWatch Vended Logs, where AWS owns the collection and delivery pipeline, is the right fit for this architecture.
Pricing
You are charged only the standard CloudWatch Vended Logs pricing for your chosen destination. Delivery pricing uses a volume-tiered model — the per-GB rate decreases as your monthly delivery volume increases.
| Destination | Starting price (us-east-1) | Lowest price | Additional charges |
|---|---|---|---|
| Amazon CloudWatch Logs | $0.50 / GB | $0.05 / GB | Log storage, Logs Insights query charges |
| Amazon S3 | $0.25 / GB | $0.05 / GB | S3 storage charges |
| Amazon Kinesis Data Firehose | $0.25 / GB | $0.05 / GB | Firehose ingestion charges |
Pricing varies by region and delivery volume. For current rates, see the Amazon CloudWatch pricing page . Note that volume tier thresholds apply per AWS account and are not aggregated across accounts in a multi-account organization.
Choosing a Log Destination
Each destination is optimized for a different set of use cases. Beyond cost, your requirements for real-time access, query capabilities, and external tool integrations should drive the decision.
| Amazon CloudWatch Logs | Amazon S3 | Amazon Kinesis Data Firehose | |
|---|---|---|---|
| Real-time log access | ✅ Available immediately | ❌ Not available | △ Depends on destination |
| CloudWatch Alarms integration | ✅ Directly configurable | ❌ Not available | ❌ Not available |
| Logs Insights queries | ✅ Supported | ❌ Requires Amazon Athena or similar | ❌ Not available |
| Long-term retention / cost efficiency | △ Additional storage charges apply | ✅ Low-cost long-term storage | △ Depends on destination |
| External SIEM / tool delivery | △ Requires additional configuration | △ Requires additional integration | ✅ Streams directly to OpenSearch, Splunk, and more |
| Compliance and audit support | △ Requires retention policy configuration | ✅ Lifecycle policies for long-term management | △ Depends on destination |
Amazon CloudWatch Logs
CloudWatch Logs is the most natural starting point for teams already using CloudWatch for operational monitoring. Logs are available immediately, and you can run ad hoc queries with Logs Insights or automatically generate alarms from error logs using Metric Filters — all within your existing CloudWatch environment. Keep in mind that log storage and Logs Insights query charges apply separately, so configure your log group retention period to manage costs.
Amazon S3
S3 is well-suited for audit log retention and compliance scenarios — for example, preserving a long-term history of AWS resource operations performed by ACK. The starting delivery price is lower than CloudWatch Logs, and S3 Lifecycle policies can automate tiering to S3 Glacier for cost-efficient long-term storage. Querying requires a separate tool such as Amazon Athena, but for logs that don't need frequent access, S3 is the most cost-effective option.
Amazon Kinesis Data Firehose
Choose Kinesis Data Firehose when you need to stream logs to an external observability platform such as OpenSearch Service, Splunk, Sumo Logic, or Datadog. It's also a good fit for centralizing logs from multiple services into a data lake for unified analysis.
Not Sure Where to Start?
If you're just getting started with EKS Capabilities logging, or if CloudWatch is already your primary observability platform, start with Amazon CloudWatch Logs. As your usage patterns become clearer, you can add S3 for audit retention and Kinesis Data Firehose for external integrations.
Configuration
Log delivery can be enabled through the AWS Management Console or via the CloudWatch APIs. Configuration is done individually per capability.
Three-Step Setup
When using the CloudWatch APIs, the setup follows three steps:
| Step | API | Description |
|---|---|---|
| ① | PutDeliverySource | Register the EKS Capability as a Vended Logs delivery source |
| ② | PutDeliveryDestination | Register the log destination (CloudWatch Logs, S3, or Kinesis Data Firehose) |
| ③ | CreateDelivery | Link the delivery source to the delivery destination |
Available Log Types
The
logType parameter in PutDeliverySource accepts the following values, organized by capability and component:| Capability | logType | Component |
|---|---|---|
| ACK | EKS_CAPABILITY_ACK_LOGS | ACK controller |
| Argo CD | EKS_CAPABILITY_ARGOCD_APPLICATION_LOGS | Application controller |
| Argo CD | EKS_CAPABILITY_ARGOCD_APPLICATIONSET_LOGS | ApplicationSet controller |
| Argo CD | EKS_CAPABILITY_ARGOCD_COMMITSERVER_LOGS | Commit server |
| Argo CD | EKS_CAPABILITY_ARGOCD_REPOSERVER_LOGS | Repo server |
| Argo CD | EKS_CAPABILITY_ARGOCD_SERVER_LOGS | API server |
| kro | EKS_CAPABILITY_KRO_LOGS | kro controller |
Because Argo CD log types are scoped to individual components, you can enable only what you need. Use
ARGOCD_APPLICATION_LOGS when investigating deployment failures, or ARGOCD_REPOSERVER_LOGS when troubleshooting Git repository connectivity issues.Example: Delivering Argo CD API Server Logs to Amazon CloudWatch Logs
The following example configures delivery of Argo CD API server logs to CloudWatch Logs in the ap-northeast-1 region.
① Create the delivery source
1
2
3
4
5
aws logs put-delivery-source \
--name "argocd-server-source" \
--resource-arn "<Capability ARN>" \
--log-type "EKS_CAPABILITY_ARGOCD_SERVER_LOGS" \
--region ap-northeast-1
② Create the delivery destination
1
2
3
4
5
aws logs put-delivery-destination \
--name "eks-capability-cw-destination" \
--delivery-destination-configuration \
'{"destinationResourceArn": "arn:aws:logs:ap-northeast-1:<account-id>:log-group:/aws/vendedlogs/eks/capabilities/argocd"}' \
--region ap-northeast-1
When delivering to CloudWatch Logs, log groups prefixed with
/aws/vendedlogs/ are created automatically. If you use a different log group name, create it manually before configuring delivery.③ Create the delivery
1
2
3
4
aws logs create-delivery \
--delivery-source-name "argocd-server-source" \
--delivery-destination-arn "<Delivery destination ARN from step ②>" \
--region ap-northeast-1
For S3 or Kinesis Data Firehose destinations, specify the corresponding resource ARN in the
destinationResourceArn field in step ②. The remaining steps are the same.Required IAM Permissions
The IAM role performing the configuration must have permissions for the CloudWatch Logs delivery APIs (
logs:PutDeliverySource, logs:PutDeliveryDestination, logs:CreateDelivery), permissions to allow Vended Logs delivery for the EKS Capability resource, and the appropriate access permissions for your chosen destination. For the full IAM policy required per destination type, see Enabling logging from AWS services in the Amazon CloudWatch Logs User Guide.Use Cases
The following scenarios show how each capability's logs can be applied in real-world operations.
Argo CD: Pinpoint GitOps Pipeline Failures Quickly
Applications sometimes fail to sync in Argo CD despite code being pushed to Git. Before this update, identifying which component was at fault required guessing from the outside.
With controller logs delivered to Amazon CloudWatch Logs, you gain direct visibility.
EKS_CAPABILITY_ARGOCD_APPLICATION_LOGS exposes drift detection and sync failure details from the Application controller, while EKS_CAPABILITY_ARGOCD_REPOSERVER_LOGS covers Git repository connectivity and manifest retrieval issues. Pairing these with CloudWatch Metric Filters to auto-generate alarms on error patterns reduces the time from detection to response.Because Argo CD log types are separated by component, you can scope your investigation more precisely.
ACK: Retain AWS Resource Operation History for Audit
For teams managing AWS resources through Kubernetes manifests, audit requirements often call for a record of who changed what, when, and how. Until now, there was no way to retain a long-term history of operations performed by the ACK controller.
Delivering
EKS_CAPABILITY_ACK_LOGS to Amazon S3 provides a low-cost way to preserve that history. When you need to review the logs, Amazon Athena supports ad hoc queries against the stored data.kro: Trace Root Causes in Complex Resource Group Failures
kro enables platform teams to define high-level abstractions — ResourceGroups — that compose Kubernetes and AWS resources. When resource dependencies are complex, identifying which resource failed and stalled the rest of the group can take time.
EKS_CAPABILITY_KRO_LOGS gives you access to the kro controller's processing logs as it handles ResourceGroups. During development and debugging, CloudWatch Logs Insights makes it straightforward to filter by resource name or error message. In production environments already integrated with an external SIEM or OpenSearch, routing logs through Kinesis Data Firehose keeps your logging pipeline unified.Summary
This update gives you, for the first time, direct access to managed controller logs from EKS Capabilities. Argo CD, ACK, and kro are now observable through CloudWatch Vended Logs, with no additional EKS charges.
References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article