Skip to content

SYSTEM Cited by 1 source

Amazon ECS Service Connect

Amazon ECS Service Connect is AWS's current-generation, fully managed service-mesh layer for ECS workloads. Introduced at re:Invent 2022, it replaces the four-tier AWS App Mesh abstraction (Mesh / Virtual Service / Virtual Router / Virtual Node) with a flat Client / Server / Client-Server role model on an ECS Service, backed by a single AWS Cloud Map namespace for both service discovery and logical-boundary grouping. The sidecar itself — called the Service Connect Proxy, and running systems/envoy under the hood — is managed by AWS: customers don't build, ship, or operate the Envoy image.

Abstraction model

  • Namespace — an AWS Cloud Map namespace; acts as both the service-discovery boundary and the logical mesh boundary.
  • Client service — an ECS Service that consumes endpoints but does not expose them (e.g. a Frontend calling downstream APIs).
  • Server service — an ECS Service that exposes endpoints for Clients to connect to.
  • Client-Server service — exposes endpoints AND consumes others; intermediate tier in a multi-level application.

That's the entire model — no Virtual Nodes, no Virtual Routers, no separate Mesh resource.

Data plane: managed Envoy

Each ECS Task in a Service Connect Namespace runs a Service Connect Proxy sidecar (systems/envoy) deployed and operated by AWS. The customer does not maintain the proxy container image, version policy, or crash-recovery lifecycle. This is the canonical managed-data-plane / managed-sidecar shape.

Built-in reliability features

All inherited from Envoy but with opinionated defaults and reduced configurability:

  • Outlier detection — unhealthy backends ejected from the LB pool.
  • Active health checking — periodic health probes to backends.
  • Retries — automatic retry on transient errors.
  • Timeouts — the only reliability knob customers can tune directly; the rest ship with AWS-chosen defaults.

Observability (free)

Service Connect publishes application-level networking metrics to Amazon CloudWatch at no additional cost, visible in both the CloudWatch and ECS consoles. No customer setup required — this is one of the headline wins the migration guide emphasizes vs. App Mesh (where Envoy-metrics scraping + shipping was the customer's problem).

Security

  • TLS encryption between services supported.
  • AWS Private CA short-lived certificates — cheaper than App Mesh's general-purpose certs.
  • No mTLS at 2025-01-18 disclosure — "two-way peer authentication using mutual TLS" is explicitly listed as not yet available in Service Connect (App Mesh has it). This is the most notable Service Connect feature gap for regulated / zero-trust workloads.

Constraints vs. App Mesh

The 2025-01-18 migration guide enumerates five explicit gaps:

Feature App Mesh Service Connect
Retry / outlier / health-check tuning Full Envoy knobs Opinionated defaults; only timeouts tunable
Advanced traffic routing (version-weighted) Yes (Virtual Router + Virtual Nodes) No
Observability DIY Envoy metrics shipping Free CloudWatch app-level metrics
concepts/mutual-tls Yes No (not yet)
Cross-account mesh sharing Yes (via AWS RAM) No — single-account only

Key constraint for migration

An ECS Service cannot simultaneously be part of both an App Mesh Mesh and a Service Connect Namespace. Migration requires recreating ECS Services; the forced pattern is patterns/blue-green-service-mesh-migration with edge traffic shifting (Route 53 weighted records, CloudFront continuous deployment, or ALB multi-target-group routing).

Seen in

Last updated · 200 distilled / 1,178 read