aws-ecs-patterns: Ability to add a Cloudfront Distribution to the ApplicationLoadBalancedFargateService

Describe the feature

The ApplicationLoadBalancedFargateService makes for super easy deployments of modern SSR web applications (among many other things of course). The construct appears to be fundamentally designed as a "one stop shop" for these services as it handles everything from networking, scaling, domain and cert setup, etc.

Following the ethos of this design pattern, I feel it would be useful if there were a way to attach a CloudFront distribution between the domain and the load balancer out of the box with the ApplicationLoadBalancedFargateService construct.

Use Case

When deploying a NextJS site (for example) via the ApplicationLoadBalancedFargateService, large static content such as images and videos take a longer time to load than they would if they were served with Cloudfront.

Serving this content behind a Cloudfront distribution would drastically improve this performance. Incorporating it into the ApplicationLoadBalancedFargateService would further the design pattern of a "one-stop shop"/easily deployable fargate service to support a variety of tasks.

Proposed Solution

// Create a load-balanced Fargate service for a nextjs landing page/website
    const landingService =
      new ecsPatterns.ApplicationLoadBalancedFargateService(
        this,
        "landingService",
        {
          cluster: this.cluster,
          desiredCount: 1,
          ...
          cloudfrontDistribution: new cdk.aws_cloudfront.Distribution(...),  <---- addition of CloudFront dist in construct
          redirectHTTP: true,
          certificate: this.cert,
          domainName: `www.${props.domainName}`,
          domainZone: route53.HostedZone.fromLookup(
            this,
            "landingServiceDomainZone",
            {
              domainName: props.domainName,
            }
          ),
        }
      );

Other Information

Another thing that may be worth considering here is a forced full invalidation (i.e., invalidate /*) on the distribution when a change is detected in the service so that we don't have any hanging cache across deployments.

Acknowledgements

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

CDK version used

2.149.0

Environment details (OS name and version, etc.)

macOS Sonoma 14.5

aws / aws-cdk