If you’re running workloads on Amazon EKS, there’s a good chance you already have some form of network observability in place. VPC Flow Logs have been a staple of AWS networking for years, and AWS has since introduced Container Network Observability, a newer set of capabilities built on Amazon CloudWatch Network Flow Monitor, that adds pod-level visibility and a service map directly in the EKS console.
It’s a reasonable assumption that between these tools, you have solid visibility into what’s happening on your cluster’s network. But for teams focused on Kubernetes security and policy enforcement, there’s a significant gap — and it’s not the one you might expect.
In this post, we’ll break down exactly what EKS native observability gives you, where it falls short for security-focused use cases, and what Calico’s observability tools, Goldmane and Whisker, provide that you simply cannot get from AWS alone.
What EKS Gives You Out of the Box
AWS offers two main sources of network observability for EKS clusters:
VPC Flow Logs capture IP traffic at the network interface level across your VPC. For each flow, you get source and destination IP addresses, ports, protocol, and whether traffic was accepted or rejected at the VPC level, by security groups and network ACLs. Useful for infrastructure-level visibility, but with no awareness of the Kubernetes layer.
Container Network Observability, introduced more recently and powered by Amazon CloudWatch Network Flow Monitor, goes meaningfully further. Once you’ve installed the NFM agent as a DaemonSet and configured the required IAM permissions, Scope, and Monitor resources, you get access to:
- Performance metrics — pod and node-level metrics including ingress/egress flow counts, packet counts, bytes transferred, and bandwidth limit events, exposed in OpenMetrics format and scrapable by Prometheus
- A service map — a visualization of traffic between pods and deployments in the EKS console, showing retransmissions, retransmission timeouts, and data transferred between communicating workloads
- A flow table — a breakdown of top-talking workloads across three views: within the cluster (east-west), to AWS services (S3, DynamoDB), and to external destinations
This is a genuinely capable performance observability tool. If your primary concern is understanding network throughput, identifying bandwidth hotspots, tracking cross-AZ traffic costs, or detecting retransmission anomalies, Container Network Observability gives you a solid foundation.
But if your primary concern is Kubernetes network security, specifically understanding policy behavior, debugging denied connections, and moving toward a least-privilege posture, it leaves critical gaps.
What EKS Native Observability Doesn’t Tell You
Understanding what EKS observability doesn’t show you is just as important as knowing what it does. Several gaps become significant once you’re actively managing network policies or investigating a security incident.
No policy verdict context. This is the most important gap. Neither VPC Flow Logs nor Container Network Observability have any awareness of Kubernetes network policies. If a Calico policy is denying traffic between two pods, you will not see that denial in AWS observability tooling. You’ll see a connection failing with no indication of which policy rule fired, which tier it belonged to, or whether the traffic was intentionally blocked or the result of a misconfiguration. For teams actively managing network policies, this makes AWS observability tools nearly useless for the most common debugging scenario you’ll face.
Performance metrics, not security metrics. The flow-level metrics in Container Network Observability (retransmissions, retransmission timeouts, and bytes transferred) are designed to answer performance questions. They are not designed to answer security questions like: which namespaces are communicating that shouldn’t be, which egress destinations are being reached, or which policy rules are being evaluated for a given flow. These are fundamentally different observability needs, and AWS’s tooling is built for the former.
Top 500 flows only, over a 1-hour window. The NFM agent collects the top 500 network flows by volume every 30 seconds, and the console visualizations are scoped to a 1-hour time range. For security investigations, this matters: less frequent or lower-volume connections — exactly the kind that might indicate lateral movement or exfiltration — may not appear in the top 500 and will be invisible to the service map and flow table.
No namespace-level policy context. While the service map does show pod and deployment-level topology, it shows you traffic volume and performance — not whether that traffic is authorized by your network policies, which policies evaluated it, or whether any of it should be blocked. Understanding the security posture of your namespace boundaries requires a different layer of data entirely.
Setup complexity. Enabling Container Network Observability requires installing the NFM agent add-on, configuring IAM permissions with Pod Identity or IRSA, and creating NFM Scope and Monitor resources either through the console, AWS CLI, or Terraform. For teams managing this with IaC, that means defining additional resource dependencies and managing the Terraform AWS Provider version requirements. It’s not prohibitively complex, but it’s meaningful infrastructure to own and maintain.
What Calico Adds: Goldmane and Whisker
Calico’s observability capabilities are built on two components introduced in Calico 3.30: Goldmane, a flow log API that generates enriched, Kubernetes-native flow data, and Whisker, a web-based UI for visualizing and filtering that data in real time. Together they give you a fundamentally different class of observability — one built specifically for the Kubernetes security layer.
Goldmane: Flow Logs That Speak Kubernetes Security
Where AWS Container Network Observability speaks in performance metrics, Goldmane speaks in Kubernetes policy context. Every flow log entry generated by Goldmane includes:
- Source and destination namespace, pod name, and deployment — Kubernetes identity is always present, regardless of IP churn
- Service names — traffic is attributed to the service it passed through, not just the backend pod IP
- Policy verdicts — each flow includes which Calico policy rule evaluated it, whether the action was Allow or Deny, and which tier the policy belonged to
- Port, protocol, and domain information — including DNS-based destinations for egress traffic
The policy verdict data is what changes the debugging experience most fundamentally. When a network policy misconfiguration breaks Prometheus scraping, blocks a health check probe, or silently drops traffic between namespaces — scenarios that are routine for any team actively managing network policies — Goldmane tells you exactly which rule fired and why. You’re not correlating IP addresses and timestamps across multiple tools; the answer is in the flow log.
Goldmane exposes its data via a gRPC API, making it straightforward to consume from your existing observability stack, whether that’s Elasticsearch, Grafana, or a custom pipeline. It covers all flows in your cluster, not just the top 500 by volume.
Whisker: Real-Time Policy Visibility Without Additional Infrastructure
Whisker is a lightweight web console that surfaces Goldmane’s flow data without requiring any additional tooling. You can filter flows by namespace, pod, policy verdict, or direction, and see in real time which traffic is being allowed and denied across your cluster.
For teams moving from a default-allow posture toward namespace isolation or zero trust, Whisker is particularly valuable during the transition: you can watch policy verdicts update live as you apply and adjust rules, rather than inferring policy behavior from downstream signals like application errors and health check failures.
Whisker is included in Calico Open Source as of 3.30. Access it via a local port-forward — no agent DaemonSet configuration, no IAM policies, no cloud service dependencies required.
Going Further: Calico Cloud Free Tier
Goldmane and Whisker give you a significantly richer observability foundation for security and troubleshooting than AWS native tooling. If you want to go further, Calico Cloud’s free tier adds a hosted experience that requires no additional infrastructure to operate.

The Calico Cloud Service Graph provides a live, visual map of communication between namespaces, services, and pods.
Connecting your EKS cluster to Calico Cloud gives you access to the Service Graph, which provides a live visual map of how your namespaces, services, and pods are communicating, overlaid with Calico policy evaluation data. Unlike the AWS console service map, which surfaces performance metrics for your top flows, the Calico Cloud Service Graph shows you the security posture of your traffic: which connections are authorized, which are being denied, and where your policy coverage has gaps. Teams that see it for the first time consistently describe it as the moment their cluster’s network finally became legible from a security perspective.
The free tier also includes the policy recommendation engine, which analyzes your cluster’s actual traffic patterns and automatically generates staged network policies to implement namespace isolation. Staged policies let you audit the recommended rules and see exactly which traffic they would allow and deny before you enforce them. It’s the fastest path from a default-allow EKS cluster to one where every namespace is isolated and secured.
Calico Cloud’s free tier is genuinely free, with no sales engagement required. It supports a single cluster with 24-hour data retention — enough to experience the Service Graph and understand what your cluster’s traffic actually looks like from a security perspective.
A Quick Comparison
| Feature | VPC Flow Logs | EKS Container Network Observability | Calico Open Source (Goldmane + Whisker) | Calico Cloud Free Tier |
|---|---|---|---|---|
| Pod / namespace identity | ✗ | ✓ | ||
| (deployment/pod view) | ✓ | ✓ | ||
| Service-level visibility | ✗ | ✓ | ||
| (service map) | ✓ | ✓ | ||
| Network performance metrics | Partial | ✓ | ||
| (RT, RTO, bytes) | ✗ | ✗ | ||
| Calico policy verdict (allow/deny + which rule) | ✗ | ✗ | ✓ | ✓ |
| All flows (not just top N by volume) | ✓ | ✗ | ||
| (top 500) | ✓ | ✓ | ||
| Security posture / policy gap visibility | ✗ | ✗ | ✓ | ✓ |
| Real-time policy visualization | ✗ | ✗ | ✓ | |
| (Whisker) | ✓ | |||
| (Service Graph) | ||||
| Policy recommendations | ✗ | ✗ | ✗ | ✓ |
| Setup complexity | Low | Medium | ||
| (NFM agent, IAM) | Low | |||
| (port-forward) | Low | |||
| (single manifest) |
Sign up for the free tier
Goldmane and Whisker, available today in Calico 3.30+, fill the gaps in EKS observability. They’re purpose-built for the Kubernetes security layer and give every EKS operator richer policy-level observability at no cost.
If you want to go further and have a live service graph that surfaces policy context, hosted dashboards, and automated policy recommendations, Calico Cloud’s free tier is the next step.
Sign up at Calico Cloud and connect your EKS cluster in under 20 minutes
Conclusion
AWS Container Network Observability is a meaningful improvement over VPC Flow Logs and a genuinely useful tool for understanding network performance in your EKS environment. If you’re tracking retransmissions, monitoring cross-AZ traffic, or trying to identify bandwidth hotspots, it’s worth enabling.
But it was designed for performance observability, not security observability. It has no awareness of Kubernetes network policy behavior, no policy verdict data, and no visibility into whether your namespace boundaries are being respected. For teams actively managing network policies or trying to move toward a least-privilege security posture, these are not minor gaps.
Goldmane and Whisker, available today in Calico 3.30+, fill exactly those gaps. They’re purpose-built for the Kubernetes security layer and give every EKS operator richer policy-level observability at no cost. If you want to go further and have a live service graph that surfaces policy context, hosted dashboards, and automated policy recommendations, Calico Cloud’s free tier is the next step.
The post What Your EKS Flow Logs Aren’t Telling You appeared first on Tigera - Creator of Calico.
Top comments (0)