aws-ecs-patterns: service connect support

[fdhex]

Describe the feature

At this time the different *Service (eg ApplicationLoadBalancerFargateService) that can be created with the ECS Patterns lib do not support ECS Service Connect as available in the ECS module.

Use Case

Support ECS Service Connect

Proposed Solution

No response

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.93.0

Environment details (OS name and version, etc.)

all

[pahud]

Yes that would be awesome! Please help us prioritize this feature request with upvotes 👍. Thanks!

[msambol]

@pahud Can I take this?

[plurch]

Is it currently possible to connect ApplicationLoadBalancedFargateService to service connect by using its underlying created FargateService? It seems doable, but I am trying this without success so far. My frontend service (ApplicationLoadBalancedFargateService) is able to connect to the backend service (FargateService) port but is getting 504 timeout errors, and the request is not showing up in the backend service logs.

I am running the frontend and backend in different ECS clusters, not sure if that is a problem.

These errors are showing up in the service connect logs: CONSECUTIVE_LOCAL_ORIGIN_FAILURE, CONSECUTIVE_5XX.

The frontend service /etc/hosts file does have entries for backend-api.

This is my approach:

SharedCloudMapStack

this.nameSpace = new servicediscovery.HttpNamespace(this, 'MyNamespace', {
  name: 'local',
});

BackendStack

new ecs.FargateService(
  ...
  serviceConnectConfiguration: {
    namespace: props.nameSpace.namespaceArn,
    logDriver: serviceConnectLogger,
    services: [
      {
        portMappingName: 'backend',
        dnsName: 'backend-api'
      },
    ],
  },
)

FrontendStack

const albFargateService = new ecs_patterns.ApplicationLoadBalancedFargateService(...)

albFargateService.service.enableServiceConnect({
  logDriver: serviceConnectLogger,
  namespace: props.nameSpace.namespaceArn
});

[plurch]

After setting up a similar app architecture in ECS copilot CLI and observing what it does, I determined that Security Groups which allow ingress are also required to get this working.

I added this CDK code to my stack:

    // This security group setup is based on what ecs copilot does
    // A shared security group is added to all services to allow inter communication
    const sgALB = new ec2.SecurityGroup(this, 'ALBSecurityGroup', {
      vpc,
      description: 'Allow all HTTP access',
      allowAllOutbound: true
    });
    sgALB.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(80), 'allow http access at 80');

    const sgServicesShared = new ec2.SecurityGroup(this, 'ServicesSecurityGroup', {
      vpc,
      description: 'Shared security group for all services',
      allowAllOutbound: true
    });
    sgServicesShared.addIngressRule(sgServicesShared, ec2.Port.allTcp(), 'Ingress from other containers in the same security group');
    sgServicesShared.addIngressRule(sgALB, ec2.Port.allTcp(), 'HTTP ingress from the public ALB');

then add the security groups for the services:

...
      securityGroups: [
        sgServicesShared
      ]
...

And for the ALB:

albFargateService.loadBalancer.addSecurityGroup(sgALB);

Maybe the docs should be updated to note the security groups requirement for developers as this was not clear to me.