(ecs): CloudMapNamespaceOptions should allow bringing your own namespace resource

[vaietc]

Describe the feature

The ECS CDK simplifies setting up default namespaces for Service Connect and Service Discovery via the use of CloudMapNamespaceOptions which automatically creates the Cloud Map namespaces. We'd like to extend this to support existing namespaces that may have been created outside of ECS Cluster configuration.

Use Case

We have found customer use cases where they already have an existing namespace modeled outside of CloudMapNamespaceOptions that they'd now like to use as the default for Service Connect but the current constructs don't allow this.

Proposed Solution

A previous bug fixed for Service Connect also recommend a potential path forward by modeling a cloudMapNamespace resource in the CloudMapNamespaceOptions which would be a workable solution

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.84.0

Environment details (OS name and version, etc.)

Mac OS 13.4

[peterwoodworth]

Thanks for opening a feature request for this 👍🏻

[chrishiestand]

Something like this would be nice:

const namespace = new PrivateDnsNamespace(
    this,
    'my-cloudmap-namespace',
    {
        name: 'my.tld',
        vpc: myVpc,
    }
);

const ecsCluster = new Cluster(this, 'my-ecs-cluster', {
    clusterName: 'myCluster',
    vpc: myVpc,
    enableFargateCapacityProviders: true,
    defaultCloudMapNamespace: namespace,
});

[MatthewAitken]

One really problematic case this would solve is when following the AWS Organizations best-practice of having a Network account provision the vpcs. In that case, the private zone has to be associated with the vpc in question before it can be used by the ECS cluster.