I'm sure they have a team hard at work on it but it would be nice if they at least confirmed it was getting closer. Maybe an estimate of "more than a month but less than a year" etc.
Their costs have to be crazy to keep purchasing IPv4 addresses so I'm sure they'd like it too.
IIRC, they purchased a huge block of 16 million IPv4 addresses quite some time ago and are still pulling from that, so they aren't investing any new money into IPv4.
Also, I don't see them being that stressed about it, they now have the t2.nano now which are ~$5/m and still come with a free IPv4 address.
Does it support ssl for custom domains? AWS has a "certificate manager" service that integrates nicely(i.e provides free certificates, automatic renewall etc) with their CDN.
The blog post tells you, after showing you how to enable it on an existing distribution - "The change will be effective within minutes and your users should start to see the benefits shortly thereafter."
Does anyone know why Amazon doesn't enable gzip compression on Elastic Beanstalk servers by default or give you an easy option instead of having to use the .elasticbeanstalk configuration files to do it?
Now if Amazon could support SSL at a price point somewhere between SNI (free) and dedicated IP ($600/mo), there could be some serious competition between CloudFlare and CloudFront. Say what you will about CloudFlare MITM'ing everybody, but their SAN SSL on the Pro plan ($20/mo) is a brilliant hack. I would gladly pay double that for an equivalent Amazon service, but unfortunately Amazon seems a bit slow when it comes to SSL/TLS. They didn't even support SNI until recently.
Is that a difficult migration? Admittedly our stack is tens of servers, not tens of thousands, but at first glance it looked like I could achieve migration via a simple update to a cloudformation script.
I just spent the last week migrating our dozen micro-services over. It wasn't too bad, and resulted in less complication as you can now have one internal and one external lb rather than one per service (and less security groups, DNS records, etc.).
The only real difference is that you now have to configure routing and target groups.
Yes, obviously you don't serve static content over websockets.
The point is that CloudFront can be used as the front end to your web site, with, depending on path, requests going to origins that are S3 buckets, ELB or EC2. Until recently, ELB didn't support websockets either. It does appears though that a new ELB was launched last month that does support it, so that allows for a solution.
