Amazon CloudFront now allows you to set two new values, a Default TTL (Time To Live) and a Max time-to-live, so that you can control how long CloudFront caches your objects in each CDN node. This dramatically increases your control over the cache duration which previously only allowed you to set the Minimum TTL. Learn more about setting cascading cache rules for CloudFront here.
You can now set a TTL without setting cache control headers on each object at the origin, If you can’t set cache-control headers at your origin that was the case for many people who were using a third-party CMS.
Override cache-control headers set by your origin so that they don’t rely on the cache-control headers set by your origin specially when you don’t control the origin server, you can now easily override the cache-control headers by setting the same value for Max TTL, Min TTL and Default TTL.
Ensure that TTLs are always within a range you specify when setting both a Min TTL and a Max TTL, you can override origin configurations that might cause objects to be cached for longer or shorter periods than you intended.
There are no additional charges for configuring Min TTL, Max TTL, or Default TTL. You can learn more about these new features by reading the Specifying How Long Objects Stay in a CloudFront Edge Cache section on the Amazon CloudFront Developer Guide.
Misuse of CloudFront by hackers can get your CDN blocked by your server, this can be a problem. Unfortunately for security reasons you do not want to allow CloudFront to by pass mod security, as this can be exploited by Mod Security:
22.214.171.124 # lfd: (mod_security) mod_security (id:210410) triggered by 126.96.36.199 (US/United States/server-216-137-42-131.dfw3.r.cloudfront.net): 5 in the last 3600 secs – Thu Mar 12 22:13:57 2015
188.8.131.52 # lfd: (mod_security) mod_security (id:950103) triggered by 184.108.40.206 (US/United States/server-205-251-218-78.arn1.r.cloudfront.net): 5 in the last 3600 secs – Sun Mar 15 23:38:33 2015
220.127.116.11 # lfd: (mod_security) mod_security (id:220030) triggered by 18.104.22.168 (US/United States/server-54-240-145-159.fra6.r.cloudfront.net): 5 in the last 3600 secs – Mon Mar 16 07:07:34 2015
We are considering to make an effort to build something to allow Mod Security to block X-IP-ADDRESS header instead of the actual IP which belongs to the CDN, meanwhile the best thing you can do is to make sure while mod security blocks risky requests, it doesn’t become black listed.
Here is the full list of IP address ranges used by Amazon Cloud Front up to this date, add them to your “Firewall Allow IPs” list: