From a Week to an Hour: Automating Quarterly Reporting with AWS Bedrock Agents

ECS Service Discovery vs. Service Connect: Which One Does Your Architecture Actually Need?

Every microservices architecture eventually runs into the same question: how do services find each other? It sounds simple until you're running dozens of containers across private subnets, and "simple" DNS lookups start colliding with real requirements — encryption in transit, retries, observability, canary deployments.

On Amazon ECS, AWS gives you two distinct paths to solve this: Service Discovery, built on AWS Cloud Map, and Service Connect, built on AWS App Mesh. They solve the same fundamental problem — service-to-service communication — but they're designed for very different levels of complexity. Picking the wrong one early on can mean either over-engineering a simple prototype or hitting a wall with a growing mesh of services that needs more than DNS can offer.

In this post, we'll break down how each mechanism works, walk through CDK (TypeScript) examples for both, and help you decide which one fits your architecture.

Note: This post assumes you already have a basic ECS setup in place using the AWS CDK (TypeScript), including a VPC, ECS Cluster, and task definitions. The examples below focus specifically on integrating Service Discovery and Service Connect with ECS, not the full stack setup.

‍

What Is ECS Service Discovery?

Service Discovery lets ECS tasks and services register themselves in a DNS namespace via AWS Cloud Map, so other services can find them using standard DNS queries. Your ECS service might register as my-api.internal.local, and any other service in the VPC can resolve that name straight to the correct task IP.

How It Works

• ECS tasks automatically register with Cloud Map when configured.
• Names like orders.internal.local resolve to the task's ENI IP.
• DNS-based resolution happens within the VPC.
• Works well with ECS services running in private subnets.

Benefits

• Simple setup, especially with CDK.
• DNS-based communication is widely supported and easy to reason about.
• Compatible with both Fargate and EC2 launch types.
• Scales naturally with multiple service instances.

Limitations

• No built-in mTLS encryption.
• Limited observability — CloudWatch metrics have to be configured manually.
• Lacks advanced traffic control features like retries or circuit breakers.

‍CDK Code Examples (TypeScript)

HTTP Namespace Example

Creates a Cloud Map namespace that supports API calls, a service within it, and registers instances to that service:

typescript

‍

import * as cdk from '../../core';
import * as servicediscovery from '../lib';

const app = new cdk.App();
const stack = new cdk.Stack(app, 'aws-servicediscovery-integ');

const namespace = new servicediscovery.HttpNamespace(stack, 'MyNamespace', {
name: 'MyHTTPNamespace',
});

const service1 = namespace.createService('NonIpService', {
description: 'service registering non-ip instances',
});

service1.registerNonIpInstance('NonIpInstance', {
customAttributes: { arn: 'arn:aws:s3:::amzn-s3-demo-bucket' },
});

const service2 = namespace.createService('IpService', {
description: 'service registering ip instances',
healthCheck: {
  type: servicediscovery.HealthCheckType.HTTP,
  resourcePath: '/check',
},
});

service2.registerIpInstance('IpInstance', {
ipv4: '54.239.25.192',
});

app.synth();

‍

Private DNS Namespace Example

Creates a Cloud Map namespace that supports both API calls and DNS queries within a VPC, registers a load balancer as an instance, and configures a secondary API-only discovery service:

typescript

‍

import * as ec2 from '../../aws-ec2';
import * as elbv2 from '../../aws-elasticloadbalancingv2';
import * as cdk from '../../core';
import * as servicediscovery from '../lib';

const app = new cdk.App();
const stack = new cdk.Stack(app, 'aws-servicediscovery-integ');

const vpc = new ec2.Vpc(stack, 'Vpc', { maxAzs: 2 });

const namespace = new servicediscovery.PrivateDnsNamespace(stack, 'Namespace', {
name: 'boobar.com',
vpc,
});

const service = namespace.createService('Service', {
dnsRecordType: servicediscovery.DnsRecordType.A_AAAA,
dnsTtl: cdk.Duration.seconds(30),
loadBalancer: true,
});

const loadbalancer = new elbv2.ApplicationLoadBalancer(stack, 'LB', {
vpc,
internetFacing: true,
});

service.registerLoadBalancer('Loadbalancer', loadbalancer);

const arnService = namespace.createService('ArnService', {
discoveryType: servicediscovery.DiscoveryType.API,
});

arnService.registerNonIpInstance('NonIpInstance', {
customAttributes: { arn: 'arn://' },
});

app.synth();

‍

Public DNS Namespace Example

Creates a Cloud Map namespace that supports both API calls and public DNS queries, and registers an IP instance:

typescript

‍

import * as cdk from '../../core';
import * as servicediscovery from '../lib';

const app = new cdk.App();
const stack = new cdk.Stack(app, 'aws-servicediscovery-integ');

const namespace = new servicediscovery.PublicDnsNamespace(stack, 'Namespace', {
name: 'foobar.com',
});

const service = namespace.createService('Service', {
name: 'foo',
dnsRecordType: servicediscovery.DnsRecordType.A,
dnsTtl: cdk.Duration.seconds(30),
healthCheck: {
  type: servicediscovery.HealthCheckType.HTTPS,
  resourcePath: '/healthcheck',
  failureThreshold: 2,
},
});

service.registerIpInstance('IpInstance', {
ipv4: '54.239.25.192',
port: 443,
});

app.synth();

‍

For DNS namespaces, you can also register instances using CNAME records:

typescript

‍

import * as cdk from '../../core';
import * as servicediscovery from '../lib';

const app = new cdk.App();
const stack = new cdk.Stack(app, 'aws-servicediscovery-integ');

const namespace = new servicediscovery.PublicDnsNamespace(stack, 'Namespace', {
name: 'foobar.com',
});

const service = namespace.createService('Service', {
name: 'foo',
dnsRecordType: servicediscovery.DnsRecordType.CNAME,
dnsTtl: cdk.Duration.seconds(30),
});

service.registerCnameInstance('CnameInstance', {
instanceCname: 'service.pizza',
});

app.synth();

‍

What Is ECS Service Connect?

Service Connect is built on AWS App Mesh and designed for more advanced, secure microservice communication. Instead of relying on plain DNS resolution, it uses Envoy sidecars to proxy and manage traffic between services — which unlocks logical service names, advanced routing, mTLS, and deep observability out of the box.

Key Features

• Built-in mTLS for encryption in transit.
• Service discovery and communication via logical names (e.g., my-backend.mesh.local).
• Support for traffic routing, retries, health-based failover, and circuit breakers.
• Deep CloudWatch and X-Ray integration via App Mesh.

CDK Example (App Mesh with ECS)

typescript

‍

import { aws_ecs as ecs } from 'aws-cdk-lib';

declare const appProtocol: ecs.AppProtocol;

const serviceConnect = new ecs.ServiceConnect(ecs.NetworkMode.NONE, {
containerPort: 123,
// the properties below are optional
appProtocol: appProtocol,
containerPortRange: 'containerPortRange',
hostPort: 123,
name: 'name',
protocol: ecs.Protocol.TCP,
});

‍

Service Discovery vs. Service Connect: Side by Side

FeatureECS Service DiscoveryECS Service ConnectMechanismDNS via Cloud MapApp Mesh via EnvoySecurityNo built-in mTLSmTLS supportedTraffic ControlBasicAdvanced (traffic shifting, retries)ObservabilityMinimalBuilt-in with Envoy, CloudWatchSetup ComplexityLowMedium/HighBest ForSimple internal servicesLarge microservice mesh

When Should You Use Each?

Use Service Discovery if:

• Your services just need basic DNS-based communication.
• You want a lightweight setup with minimal moving parts.
• You're not concerned with encryption or retries at the network layer.
• You're building simple internal apps or prototypes.

Use Service Connect if:

• You need mTLS encryption for secure service-to-service traffic.
• You want traffic shaping, canary deployments, or blue/green strategies.
• You require advanced observability and metrics out of the box.
• You're working with many microservices and need fine-grained control over how they talk to each other.

Conclusion

Both Service Discovery and Service Connect are solid tools in the ECS ecosystem — the right choice depends entirely on where your architecture actually is, not where you think it might end up.

If you're starting small or building a simple architecture, Cloud Map-based Service Discovery gets you there quickly with almost no overhead. For complex, secure, and dynamic applications — especially where compliance or observability requirements come into play — Service Connect with App Mesh gives you the robust tooling to scale with confidence.

‍

Start simple. Scale with confidence.

‍