I appreciate that this was attempted, and feel that there are some good learnings in this article, however feel that it should be reframed. The concepts address

I appreciate that this was attempted, and feel that there are some good learnings in this article, however feel that it should be reframed. The concepts addressed in this piece area useful if you want to distribute a stateless application geographically, and route a user to the closed access point. While this a necessary attribute of a CDN, it is not sufficient in itself. I think this project ignored a main purpose of a CDN; serving static content (or acting as a reverse-proxy/cache to your upstream services) in _massive_ quantity. Bandwidth and latency are the main concerns or a CDN, and this approach addresses latency, but completely ignores bandwidth. Honestly, a CDN is probably one of the worst possible applications that could be built on AWS (or any other cloud hosting provider) simply due to the extreme bandwidth costs. EC2 egress costs are already an order of magnitude greater than Cloudfront costs, and not even fairly comparable to non-"cloud" options. Basically, if you want a build a CDN, the cloud providers are horrible options, whether you use Kubernetes or not. > edited for formatting