aws / aws/aws-cdk

aws-ecs: currently it is not possible to construct fully functional ECS Service from ARN or Attributes

Open
#30,436 3 comments 0 reactions 0 assignees View on GitHub
@aws-cdk/aws-ecs effort/medium feature-request p2
Dominant language
TypeScript
Stars
12.9k
Forks
4.6k
Avg merge
2d 3h
Merged PRs (30d)
83

Description

### Describe the feature

Currently it is not possible to cleanly manage connectivity on the ECS service level for existing resources created outside of the stack (e.g. anything retrieved by ARN/Attributes in CDK).

Additionally, for example, for `ICluster` an equivalent connections property is manually exposed, without implementing `IConnectable`, is there any reason for this? Wouldn't consistent use of `IConnectable` be preferred?

### Use Case

For us the use case is simple, we need permanent infrastructure with some ECS services (Fargate for us, but should not matter here) which is created as part of one stack, but also temporary infrastructure which needs to connect to the services of the primary permanent stack created in another stack.

We would prefer avoiding routing the traffic through any load balancers (internal or otherwise), and unfortunately service connect doesn't help either since some of our ECS tasks are scheduled and thus "serviceless" (although I am unsure if Service Connect would even side step the need of security groups here for us anyway, since we ruled it out early on, in favor of classic service discovery for the above limitation it has).

### Proposed Solution

See title, `BaseService` appears ready to include this interface as is, if you wish for some reason to avoid dependency to the ec2 interface `IBaseService` should alternatively expose connections property directly, similar to `ICluster`.

### Other Information

Upon further inspection it seems that what I would actually be looking for is an equivalent of `fromLookup()` for ECS resources such that we could construct a fully functional CDK construct from just an ARN or a more limited set of attributes.

Is there a particular reason why CDK seems so stingy about providing this kind of functionality? (this is hardly the first time I come across this, e.g. accessing legacy RDS instances created by hand is a pain since we have to manually provide all the information even though surely there would be a way to do it with API calls similar to how VPC lookup is done).

There seems to be a feature to add context provider plugins, but it is for some unknown reason marked as internal use only, even though it would be useful as a general availability feature. For example when for one reason or another only partial CDK usage is possible.

### Acknowledgements

- [x] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### CDK version used

2.144.0 (Typescript)

### Environment details (OS name and version, etc.)

Windows / WSL (Ubuntu)

Contributor guide

Open the contributing guide

Research direction

Start with the BaseService, IConnectable, IBaseService, and ICluster entry points mentioned in the issue, then compare the existing fromLookup() behavior for other ECS resources. Define whether the work is an imported service connectivity interface or an ARN-based lookup construct; done should be a fully functional ECS service reference that supports connectivity without a load balancer.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
cloud, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.