Build Cloud Map service discovery configurations with DNS settings, health checks, and routing policies.
Build Cloud Map service discovery configurations with DNS settings, health checks, and routing policies.
Required Fields
NameNamespaceIdDnsConfig.DnsRecordsOutput will appear here...The builder validates that Name, NamespaceId, and DnsConfig.DnsRecords all resolve before accepting the JSON as a valid CreateService request, the fields Cloud Map needs to register a discoverable service under a namespace with a defined record shape; it can't verify the referenced NamespaceId actually exists or that the routing policy is compatible with the specified DNS record types, those checks happen against the live API.
Build an AWS Cloud Map service for DNS or API-based service discovery, where RoutingPolicy determines client behavior: WEIGHTED returns multiple DNS records proportioned by assigned weight (for gradual traffic shifting), while MULTIVALUE returns up to 8 healthy instance records per query for simple client-side load balancing, and they're mutually exclusive choices tied to the DNS record Type combination, not independently toggleable settings. A service's HealthCheckConfig (Route 53-managed, for public endpoints) and HealthCheckCustomConfig (self-reported via UpdateInstanceCustomHealthStatus, for private/ECS-integrated services) are two entirely different health-check mechanisms, not two configuration options for the same check.
HealthCheckConfig (Route 53-managed) only works for endpoints Route 53 can actually reach and probe, using it for a private, VPC-internal service silently produces a health check that can never succeed, use HealthCheckCustomConfig instead for anything not publicly reachable.
A DNS TTL that's too long (the default in some setups is much higher than 60s) means clients keep resolving to decommissioned instances for the TTL's duration after a deployment, keep TTL low for services with frequent instance churn, accepting the tradeoff of higher DNS query volume.
Type: HTTP namespace services don't produce any DNS records at all, if you're expecting to dig a hostname for a Cloud Map service and getting nothing, confirm the namespace type first, HTTP namespace discovery only works through the Cloud Map API, not DNS.
No, they're mutually exclusive per service, HealthCheckConfig is Route 53's active, Cloud-Map-managed health checking (which only works for publicly reachable endpoints and incurs Route 53 health check charges), while HealthCheckCustomConfig relies on something else (commonly ECS or App Mesh) calling UpdateInstanceCustomHealthStatus to report health. Choose based on whether your service instances are publicly reachable and want AWS to actively check them, or privately managed with health already tracked by an orchestration platform.
WEIGHTED returns DNS answers proportioned according to each instance's assigned weight, useful for a controlled percentage-based traffic shift. MULTIVALUE returns up to 8 healthy instance IPs per DNS query with no weighting, relying on the client (or its DNS resolver's round-robin behavior) to distribute load roughly evenly. If you need precise traffic-percentage control (a canary), WEIGHTED is the right choice; for simple discovery of any healthy instance, MULTIVALUE is simpler and doesn't require weight management.
No, an HTTP namespace-based Cloud Map service is discovered via the Cloud Map API (DiscoverInstances) rather than DNS resolution, no DNS records are created at all for this type. This is common for App Mesh and ECS Service Connect integrations where discovery happens at the platform/SDK level rather than through actual DNS queries, DnsConfig and DnsRecords are only relevant for DNS-based namespace types (public or private DNS namespaces), not HTTP namespaces.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.