You open Kibana, stare at a blank dashboard, and wonder where your ECS logs vanished. They are running in containers somewhere, but Kibana insists they do not exist. That gap between “it’s deployed” and “it’s observable” is exactly why people wrestle with ECS Kibana setups in the first place.
Amazon ECS (Elastic Container Service) handles container orchestration, deployment, and scaling. Kibana, on the other hand, is the front door to Elasticsearch. It turns cryptic JSON logs into visual data you can actually reason with. Together, ECS Kibana means unified observability: real-time container data in one searchable, filterable view. When tuned well, it gives your ops team perfect situational awareness across tasks, services, and clusters.
At its core, integration works by shipping logs from ECS tasks into an Elasticsearch index, which Kibana reads. Each task writes logs via a sidecar, FireLens, or a log driver configured with an output plugin such as Fluent Bit. Those logs pick up ECS metadata—cluster, task ID, service—before landing in Elasticsearch. Once indexed, Kibana builds visualizations using that metadata to map container health across the entire fleet. That’s the simple picture most teams start from.
In practice, access control becomes the bottleneck. AWS IAM, Elasticsearch RBAC, and your company’s SSO can disagree about who gets to see what. The best pattern is identity mapping: treat ECS tasks and human users differently, then use OIDC claims or service roles to assign access levels. Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. They let engineers reach dashboards through identity-aware proxies instead of brittle static credentials.