Aws-cdk: [ecs-patterns]: Please make it possible to specify the vpc subnet selection when using ApplicationLoadBalancedFargateService

[frjtrifork]

When creating a Fargate ecs service from scratch you have an option to specify the Vpc SubnetSelection the service can use in FargateServiceProps in the vpcSubnets field.

But there is no such vpcSubnets option when creating the ApplicationLoadBalancedFargateService in the ApplicationLoadBalancedFargateServiceProps - in that you can only specify the VPC - not the subnetselection.

Use Case

We are trying to follow best practices regarding network splitting for our services and have our vpc split into multiple private subnets in each availability zone - each of these subnets are protected by Network ACL rules limiting the traffic into and between them.
Being able to specify which subnets the fargate service can be launched in is needed in such a scenario.

ApplicationLoadBalancedFargateService is a great abstraction and writing the CDK code for each of the constructs it helps create by hand is quite verbose and easy to get wrong.

We noticed this issue since we started out using the ApplicationLoadBalancedFargateService and configured a health check for our application but saw very different deployment times. When we started monitoring the ECS event log to troubleshoot we noticed that ECS was redeploying in a random private subnet in our VPC. When a private subnet that the database subnet ACL rules prevented from connecting to the DBs was chosen the healthcheck failed and ECS redeployed.
This could happen many times - but eventually ECS picked one of the private subnets that was allowed to connect to the database subnet and the application got into healthy state.

We then refactored to using FargateService and specified the vpcSubnets property and limited it to the subnets that was allowed to connect to our database subnet and it is working fine for us now with predictive deployment times. But it meant we had to write a lot more CDK code compared to the few lines we had when using ApplicationLoadBalancedFargateService.

Proposed Solution

We suggest adding an optional vpcSubnets property to the ApplicationLoadBalancedFargateServiceProps and make it have the same default behavior as the vpcSubnets property in FargateServiceProps.

If you can do that I assume this should not be a breaking change for existing uses of the ApplicationLoadBalancedFargateService.

• [ ] :wave: I may be able to implement this feature request
• [ ] :warning: This feature might incur a breaking change

---

This is a :rocket: Feature Request

[kyler-hyuna]

Thanks so much for this. Been banging my head over a day with this and couldn't figure out why.

[davxiao]

this is so much needed

[Tanuel]

Edit: i misunderstood the question, but will leave the original answer here if anyone stumbles across this

---

Hi, while this should be implemented, there is an easy fix for now, where you don't have to migrate your full stack: Create your own loadbalancer and inject it:

const myAlb = new elbv2.ApplicationLoadBalancer(this, "ALB", {
    vpc,
    internetFacing: false,
    vpcSubnets: {
        onePerAz: true,
    },
})

// Create a load-balanced Fargate service and make it public
const service = new ecs_patterns.ApplicationLoadBalancedFargateService(this, "App", {
    loadBalancer: myAlb,
    // add other properties
}

[kyler-hyuna]

@Tanuel the load balancer subnets aren't directly related to the subnets that ECS will deploy tasks into. Your suggestion just covers which subnets the lb will accept tasks from.

[suankan]

I'm voting with both hands for implementing this!

@frjtrifork
There is a possible "hackery" solution that allows you still choose the right set of private subnets for placing ECS Fargate Service and still to use ApplicationLoadBalancedFargateService pattern.

You can instantiate a VPC using static method ec2.Vpc.fromVpcAttributes(...) and specify only the needed Private Subnets in attribute privateSubnetIds. In this case those privateSubnetIds will be the only subnets which ApplicationLoadBalancedFargateService discovers and will place of your ECS Fargate Service always into them.

    const albFargateService = new ecs_patterns.ApplicationLoadBalancedFargateService(this, "FargateService", {
      vpc: ec2.Vpc.fromVpcAttributes(this, 'VPC_PRIVATE_SUBNETS', {
        availabilityZones: cdk.Fn.getAzs(cdk.Aws.REGION),
        vpcId: cdk.Fn.importValue('NAME_OF_CF_EXPORT_WITH_VPCID'),
        privateSubnetIds: [
          cdk.Fn.importValue('NAME_OF_CF_EXPORT_WITH_PRIVATE_SUBNET_1'),
          cdk.Fn.importValue('NAME_OF_CF_EXPORT_WITH_PRIVATE_SUBNET_2'),
          cdk.Fn.importValue('NAME_OF_CF_EXPORT_WITH_PRIVATE_SUBNET_3'),
        ],
      }),
    })

Hope that can help you.

And If you need your ALB to sit in different set of Private Subnets from ECS Fargate Service, then you can use @Tanuel approach by instantiating ALB first and injecting into ApplicationLoadBalancedFargateService.

[frjtrifork]

@suankan

I'm voting with both hands for implementing this!

@frjtrifork
There is a possible "hackery" solution that allows you still choose the right set of private subnets for placing ECS Fargate Service and still to use ApplicationLoadBalancedFargateService pattern.

You can instantiate a VPC using static method ec2.Vpc.fromVpcAttributes(...) and specify only the needed Private Subnets in attribute privateSubnetIds. In this case those privateSubnetIds will be the only subnets which ApplicationLoadBalancedFargateService discovers and will place of your ECS Fargate Service always into them.

SNIP

Hope that can help you.

That is actually quite a clever workaround!
We do have everything working now with our cdk code, so I think we will stick to what we have currently - but will remember this for my next project if the feature is not implemented in the CDK before I get to that.
Thanks 👍

[hoegertn]

@iamhopaul123 What is the current state on this and is there a special reason to have two PRs for this feature?

[iamhopaul123]

Hello @hoegertn, the external contributor seems to have trouble finishing the PR so I opened up a new one, which is under review right now. I'll ping reviewers next week to see if I can speed it up.

[github-actions[bot]]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.