AWS Expands Container Services: CloudWatch Container Insights, Fluent Bit, and the Road to Managed Kubernetes

Original reporting source: containerjournal.com. Original announcement context: AWS Summit New York, July 2019.

AWS Doubles Down on Containers at Summit New York

At its AWS Summit event in New York, Amazon Web Services made two significant container-related announcements in quick succession: the general availability of AWS Fluent Bit and the preview launch of Amazon CloudWatch Container Insights. Together, these releases signal AWS’s sustained effort to reduce the operational complexity of running containers at scale on its platform.

AWS Fluent Bit: Centralised Container Log Routing

AWS Fluent Bit reached general availability alongside the Summit announcements. Fluent Bit is a lightweight, open-source log processor and forwarder that AWS integrated tightly into its ecosystem. In this AWS-managed form, it enables container logs to be routed to two primary destinations:

• Amazon CloudWatch Logs — for centralised monitoring, search, and alerting.
• Amazon Kinesis Data Firehose — for streaming log data onward to long-term or analytical storage, including Amazon S3, Amazon OpenSearch Service (formerly Amazon Elasticsearch Service), or Amazon Redshift.

For teams already running containers on Amazon ECS, EKS, or AWS Fargate, Fluent Bit provides a low-overhead, AWS-native alternative to running a heavier log aggregation sidecar or daemon set.

Amazon CloudWatch Container Insights (Preview)

CloudWatch Container Insights was announced in preview at the same event. It is designed to give operations and development teams a single observability surface for containerised applications and microservices running across AWS container services.

Key Capabilities

• Automatic discovery — Container Insights automatically discovers container environments without manual configuration of each cluster or service.
• Operational dashboards — Pre-built dashboards surface aggregated operational data, reducing the time needed to get initial visibility.
• Granular performance metrics — CPU utilisation, memory usage, disk I/O, and network metrics are collected at the container, pod, task, and service level, enabling precise resource analysis.
• Troubleshooting tools — Integrated diagnostic tooling helps engineers identify and isolate issues within containerised workloads and microservices.

Container Insights works across Amazon ECS, Amazon EKS, and AWS Fargate, positioning it as a cross-service observability layer rather than a tool tied to any single container orchestrator.

Werner Vogels on Containers and the Microservices Shift

AWS CTO Werner Vogels used his keynote address to frame the strategic importance of containers. His core argument: containers are essential to cloud-native development because they provide an elastic environment that makes scaling applications up or down straightforward. Equally important is that containers enable teams to decompose large monolithic applications into independently deployable microservices, each with its own build and deployment pipeline.

Vogels cited McDonald’s as a real-world example of container workloads at scale, noting the fast-food chain uses Amazon Elastic Container Service (ECS) to power a home-delivery application capable of handling more than 20,000 orders per second. He attributed part of that scalability to ECS’s deep integration with the broader AWS service portfolio.

Acknowledging the Kubernetes Management Problem

Notably, Vogels did not shy away from criticising the status quo. He described managing containers and Kubernetes as genuinely painful, identifying two distinct friction points:

• Developer friction — Building and deploying containers still requires working with low-level tooling that slows down development cycles.
• Operations friction — Kubernetes clusters are complex to provision, upgrade, and manage dynamically, placing a heavy burden on platform and infrastructure teams.

Vogels framed AWS’s container roadmap as an effort to abstract away this complexity so that development teams can focus on application logic rather than cluster operations — a positioning consistent with AWS’s broader managed-services strategy and the trajectory of Amazon EKS.

Containers as the Foundation for Serverless

AWS also highlighted the connection between containers and serverless computing. Internally, AWS uses containers extensively to power its serverless services. From a developer’s perspective, this means on-demand invocation of services — such as Amazon EventBridge for event-driven data routing between applications — without the need to manage the underlying container infrastructure. This model allows teams to benefit from container-based isolation and packaging without carrying the operational overhead of managing containers directly.

The Vendor Lock-In Trade-Off

The announcements also highlight a well-understood trade-off in cloud-native architecture. As organisations adopt more AWS-native services — using CloudWatch for observability, Kinesis for log streaming, ECS or EKS for orchestration — they gain tighter integration and reduced operational overhead. However, they also accumulate dependencies on proprietary AWS APIs and service hooks that make workload portability progressively harder.

For organisations with a genuine multi-cloud strategy, this creates a dilemma: AWS’s integrated toolchain is operationally compelling, but extending a consistent DevOps workflow across AWS, Azure, or Google Cloud becomes significantly more complex when each platform’s native services are deeply embedded into the application stack. Teams should evaluate container observability and logging tools — including open-source alternatives such as Prometheus, Grafana, and Fluent Bit running independently — against the operational convenience of the AWS-managed equivalents.

Summary

AWS’s July 2019 container announcements reflect a clear product strategy: lower the observability and logging burden for container operators while deepening the integration of containers into the broader AWS platform. Teams evaluating these services should weigh the operational benefits against the long-term implications of increased platform dependency.