I have a domain on ec2 instance with real-time access ( inserting new leads)to remote db. Recently AWS advised to use elb+cloud front for security.

Is possible to enable cloud front on a domain with real-time access ( inserting new leads)to remote db.

  • 2
    Yes, with the right caching headers and TTLs you can use CloudFront as just a proxy instead of a caching layer. See stackoverflow.com/questions/10621099/… – ceejayoz Apr 24 '17 at 17:25
  • @ceejayoz after making TTL value to 0, it stooped caching and working as expected. – adminz Apr 24 '17 at 20:37

Both ELB and CloudFront provide some security. They prevent against specific layer 3 and layer 7 attacks by virtue of terminating the connection, before passing it on to your server. This include DDOS and SlowLoris.

CloudFront has the advantage that it has nodes all over the world, and massive amounts of bandwidth. That can mitigate many DDOS attacks simply because of scale. ELB also scales with traffic, but not as quickly as CloudFront, as it has to start or allocate new servers.

Incoming traffic is free on AWS. This means they absorb the attacks no charge to you.

Using either of those products increases your security. You don't need to use both. I suggest you just use CloudWatch for now.

I just set up CloudFront for my EC2 server, it's fairly easy, but with a few gotachas around https. The broad steps (including HTTPS) are:

  • Use AWS certificate manager to create a certificate for your domains (including www subdomain) in the US-EAST-1 region (MUST be that region)
  • Set up a new subdomain for your origin. CloudFront needs this. For example I used origin.example.com and configured Nginx to respond to that address.
  • Set up CloudFront with that origin, with your domain and subdomains as alternate. Set up your behaviors carefully, taking into account what should and shouldn't be cached. Even if nothing is cached your website is likely to be faster than if it goes over the internet, as once the request hits CloudFront it travels over the private optimized AWS backbone, not the public internet. Dynamic content is fine, just set the TTL to 0.
  • Ideally, set up Route 53, use alias records to point to CloudFront, move your DNS over, and change it to be your name servers

If you want to improve your security ever more you can use AWS WAF. it integrates with CloudFront. It's cheaper than most WAFs, but you'll probably spend low tens of dollars per month if it's set up comprehensively. Personally I don't bother, my service isn't critical.

If you want an even easier option, use CloudFlare. This isn't part of AWS, but it's super simple to set up, and they have a free tier. I use it for most of my websites.

  • after making TTL value to 0, it stooped caching and working as expected. stackoverflow.com/questions/10621099/… – adminz Apr 24 '17 at 20:38
  • 1
    Yes, TTL 0 is good for content that shouldn't be cached - any scripts, posts, that sort of thing. Caching should be for static files or pages that change rarely. I have 8 - 10 behaviors set up in my distribution, so static content is cached for a long time, pages are cached for a short time, and things like admin and URLS that are posted to aren't cached. – Tim Apr 24 '17 at 20:53
  • Of course, your server should also be sending a reaponse header, something along the lines of Cache-Control: no-cache, private, must-revalidate for content that shouldn't be cached, which CloudFront respects automatically (without config changes), as well as browsers. – Michael - sqlbot Apr 24 '17 at 23:54
  • Good point Michael, I didn't think to include that. – Tim Apr 25 '17 at 0:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.