(ECS): VPC by default created with NAT

link to reference doc page

https://docs.aws.amazon.com/cdk/v2/guide/ecs_example.html

Describe your issue?

Folks, you are doing a great job. I really enjoy CDK and the direction it takes. I’ve been using CDK quite happily for building my app using Fargate until I noticed that my AWS bill was ~90$ instead of the expected ~8$ for this project. I started digging into it, and it was NAT Gateway created by CDK when I deployed my container. I followed mostly official documentation

This part, in particular, I believe caused this:

Vpc vpc = Vpc.Builder.create(this, "MyVpc")
    .maxAzs(3)  // Default is all AZs in region
    .build();

If I understood correctly, the default behavior is to create NAT Gateway and put service behind it. While I understand the reasoning behind it, I believe most people don’t need it. For sure, no one wants unexpected bills. Please consider changing this default behavior. At the very least, there should be some disclaimer.

Btw, I’m still trying to figure out how to get rid of NAT. Simply adding .natGateways(0) doesn’t work, causing some subnet conflicts when I try to update the existing stack. Seems like I have to learn how VPC works in AWS.

[sergekukharev]

This might be helpful. To get rid of NAT Gateway in Fargate setup, something like this should be used:

Vpc vpc = Vpc.Builder
      .create(this, "MyVpc")
      .natGateways(0)
      .enableDnsHostnames(true)
      .enableDnsSupport(true)
      .subnetConfiguration(List.of(
          SubnetConfiguration.builder().mapPublicIpOnLaunch(true).cidrMask(24).subnetType(SubnetType.PUBLIC).name("public-one").build()
      ))
      .maxAzs(3)
      .build();
      
//...

ApplicationLoadBalancedFargateService.Builder.create(this, "MyFargateService")
       .cluster(cluster) 
       .assignPublicIp(true) // Since we have no NAT, ECS service needs public IP to be able to pull image from ECR through Internet Gateway
       .publicLoadBalancer(true) 
       .taskImageOptions(
               ApplicationLoadBalancedTaskImageOptions.builder()
                       .image(ContainerImage.fromRegistry("amazon/amazon-ecs-sample"))
                       .build())
       .cpu(512) 
       .memoryLimitMiB(2048) 
       .build();

[madeline-k]

@kylerjensen thank you for sharing your detailed perspective on this one! The mission of the aws-cdk is to simplify AWS for builders. This often comes into conflict with the goal of reducing AWS costs.

Customers can always see the CloudFormation templates created by their CDK apps. But it’s not always easy to tell what is going to be charged once deployed. Some additional transparency in the docs, and an easier way in the L2 and L3 ecs service APIs to remove the NAT Gateways should also help customers to avoid unintentionally incurring these charges.

Cloudformation also has a feature for estimating the cost of Cloudformation stacks. We could also integrate this into the CDK CLI to help customers get a sense of how much they will be charged after deploying their CDK apps.

(Not saying we should not change the default behavior with a feature flag. That is a pretty big decision, and I’m interested to hear more perspectives on it still.)