3

I know this is an apples and oranges question but I'd like to understand the pros and cons of using https and signed urls with AWS Cloudfront. Might people please comment on and add to this list?

HTTPS

PROS

  1. Security: https is more secure than http. Though, I'm not sure what this mean b/c if you can't trust that the URL is actually from Amazon, who can you trust?
  2. Preserve your application's status quo: Your site is already fully https for another reason, like you handle credit cards. Using https for cloudfront prevents alerting the user that you are serving insecure content, i.e., the dreaded "yellow" indicator symbol. Could this also be a con if you're site is fully http (honest question)?
  3. Degree of difficulty: 0/10. Just change http to https in your url, it works either way out of the box. On the other hand, if you want to use your own CNAME with https, this seems significantly more confusing, 7/10, though I haven't tried it due to con #1 below...

CONS

  1. Cost: $600/month !! to use https with own CNAME, e.g., images.mysite.com instead of blah123.cloudfront.com. On the other hand, my understanding is that using CNAMEs with http is free?

SIGNED URLS

PROS

  1. REAL security: signed urls would seem the most commonly needed method to control who has access to your site's content. You can control things like the user IP address and the time duration of who has access.

  2. Cost: none

CONS

  1. Degree of difficulty: 9/10. Creating signed urls is relatively confusing. There's lots of terminology to learn and possibly some libraries not part of the AWS SDK you'll need to track down.
tim peterson
  • 22,033
  • 50
  • 162
  • 279

1 Answers1

2

HTTPS helps secure data in transit, which is helpful if you are already using SSL for access to your application. With the CNAME issue, most people are likely not going to realize that your images and other static content are being delivered from cloudfront.net instead of yourdomain.com

Signing URLs only helps control who can access a given file and how long they can access it for. You may use this for delivery digital purchases, or other private files to logged in users. You also loose some of the caching benefit of cloudfront.

datasage
  • 18,353
  • 2
  • 43
  • 50
  • thanks for your answer, can you explain what you mean by the "caching benefit of Cloudfront"? Is this because of the query string that changes when you set the signed url to expire? If so, does this means the file is sent by cloudfront with a cache header that lasts as long as the signed url stays the same? – tim peterson Sep 19 '13 at 21:22
  • The signed url is sort of a temporary key that gives you access to a private file. In most cases, each user would get a unique signed URL. Cloudfront would access s3 for each request instead of just the first one. – datasage Sep 19 '13 at 21:24
  • it would access S3 for each request even if the "key" didnt change? – tim peterson Sep 19 '13 at 21:32