What risks should I expect when applying WAF to Classic Load Balancer with CloudFront?



I'm creating a question to ask what risks should I expect when applying WAF to Classic Load Balancer with CloudFront. I'm considering how to protect my services consisting of the Classic Load Balancer service. The best way is to convert CLB to ALB, so that WAF can be associated without any additional layer like CloudFront.

However, some of my services have a restriction that the legacy devices have troubles in connecting via Application Load Balancer. Converting to Application Load Balancer itself needs service verification, which takes a long time to complete. Therefore, I think adding CloudFront and WAF can be a quicker way than converting to ALB.

In this regard, let me ask some questions.

  1. What risks should I expect when applying WAF to Classic Load Balancer with CloudFront? It comes to me that if the service domain names are mapped to the Clooud Front endpoint, there is no big issue to consider. However, there might be some risks I am not aware of. For example, any other protocols that HTTP, HTTPS are no longer supported after CloudFront and WAF are applied.

  2. What side-effect can CloudFront and WAF on CLB incur? For example, as I mentioned earlier, are some protocols no longer supported?

If there are some folks having experience in adopting WAF for CLB, please give me suggestions.

Best Regards, Keonwoong.

3 Answers
Accepted Answer

Hi Keonwoong!

To address your main concern regarding protocols other than HTTP and HTTPS, you are correct. Implementing CloudFront with a Classic Load Balancer as the origin will limit communication between clients and your Distribution, and between your Distribution and Classic Load Balancer to only HTTP and HTTPS. You do have the option of specifying a custom HTTP/HTTPS port for communication between your Distribution and CLB origin [1] [2].

Adding WAF to the mix, you may find that some application verification is still needed to ensure that any rules you put in place do not inadvertently block valid requests. The rules you implement, whether they are custom rule groups or the AWS Managed Rules rule groups, will depend on your applications needs, but in either case, we advise following our Web ACL testing guidelines [4] to ensure your implemented WebACL meets your needs. We advise that the rules in a Web ACL be set to count and the default action of the Web ACL to allow requests. As well, enabling logging [5] for the Web ACL gives further detailed information about traffic analyzed by the Web ACL, which can help you in making decisions about how your rules may need to be modified for your specific application.

[1] Values That You Specify When You Create or Update a Distribution - Origin Protocol Policy - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html?icmpid=docs_cf_help_panel#DownloadDistValuesOriginProtocolPolicy

[2] Values That You Specify When You Create or Update a Distribution - Viewer Protocol Policy - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html?icmpid=docs_cf_help_panel#DownloadDistValuesViewerProtocolPolicy

[3] How AWS WAF works with Amazon CloudFront features - Using AWS WAF with CloudFront for applications running on your own HTTP server - https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html#cloudfront-features-your-own-http-server

[4] Testing web ACLs - https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html

[5] Logging and monitoring web ACL traffic - https://docs.aws.amazon.com/waf/latest/developerguide/logging.html

answered 2 years ago
profile picture
reviewed a year ago
  • Thank you Justin.

    Let me ask another one that relates to the original question. Have you ever heard a report from other clients that when the request with too many parameters is sent by HTTP/HTTPs, ALB can't handle it properly?

    I'm reluctant to convert CLB to ALB since we had the issue that some requests were not processed correctly and that they had common in having many parameters. I can't tell you how many parameters they had exactly, nor am I sure whether some parts of the parameters were passed or the parameters were entirely dropped as the issue had happened before I joined my organization.

    Therefore, we are now running our services on CLB that can support TCP. However, it feels weird since I've never heard about some limitations in the parameter number of the HTTP request.

  • Well, there are some limitations that could potentially have been reached while using an ALB and the HTTP requests sent to it for your application, leading to certain HTTP errors. It's possible that they could have hit header limitations, resulting an HTTP400 error. Or possibly an HTTP414 error was received from the URI and/or query string parameters sent to the ALB were too large.

    If you haven't already, you may consider looking in to utilizing a Network Load Balancer. NLBs also operate at Layer 4, and offer a number of benefits for migrating from a Classic Load Balancer, with pricing similar to that of an Application Load Balancer.

    A downside here would be if you wish to utilize CloudFront/WAF with the NLB as an origin, you may still find yourself limited by request size and URL length quotas.


Justin's answer is excellent - I'd only add this:

If I was in your position I would create an automated test suite - it would allow you to evaluate not only moving from CLB to ALB but also any future changes you might make to your entire application. Yes, it's a lot of work. But it's far better to be able to test changes before applying them to production. And automating those tests saves your future self time and effort. It also allows you to test more than just ALB/WAF.

profile pictureAWS
answered 2 years ago

Thank you Justin, Brettski. Your explanation and experience are helpful to consider how to transition from CLB to ALB. However, there are still so many traps and burdens that I should think about other alternatives that focus on the primary purpose of security.

It was a good discussion. Thank both of you.

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions