- Newest
- Most votes
- Most comments
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
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.
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.
Relevant content
- asked 5 years ago
- Accepted Answerasked a year ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years 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.