1

From my understanding, the SSL option on CloudFront is a costly option (out of reach for me). Therefore, I am considering using the https://*.cloudfront.com option.

One of the perks of CF over S3 is the ability of assigning multiple custom domains to get the benefit concurrent parallel HTTP connections, ie. cdn0.domain.com, cdn1.domain.com, etc.

Since custom domain + SSL is not an option, does CF have a wildcard option of the https://*[0,1,2,3].cloudfront.com variant to a single distribution?

Viet
  • 3,257
  • 3
  • 28
  • 36
  • What *possible* advantage do you imagine there might be in having multiple *meaningless* hostnames referencing a single set of content, as opposed to just one single meaningless hostname? – Michael - sqlbot Jan 28 '14 at 09:01
  • Many browsers have a concurrency restraints of around two when accessing from a single hostname. In other words HTTP requests are limited to two at the time from a single domain. It is a known best practice that you can speed up page load times by having your application distribute the assets across multiple domains. For example, on Rails, there is a feature that allows you to set a dynamic host where cdn[val].domain.com where val is either 0, 1, 2, or 3. So no, it is not meaningless. Here is some literature: http://www.openajax.org/runtime/wiki/The_Two_HTTP_Connection_Limit_Issue, – Viet Jan 28 '14 at 16:24
  • And additional information under the Ruby on Rails documentation. Looking under "Using asset hosts" http://edgeapi.rubyonrails.org/classes/ActionView/Helpers/AssetUrlHelper.html . I believe that one of the many reasons why Amazon CloudFront allows up to 10 CNAME for a single distribution is for this reason. – Viet Jan 28 '14 at 16:30
  • And one last resource from our peers, just to bring the point home. https://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser – Viet Jan 28 '14 at 16:39
  • Yes, this is a valid point, of course. I meant "meaningless" in the sense that the default distribution hostname contains no human-meaningful information. Since objects "behind" each of the hostnames would be, to the browser, different objects, this configuration would be somewhat counterproductive if the hostnames were randomized, since it would limit browser-side caching... unless each object were statically behind a particular imaginary hostname... in which case you could simply create multiple CloudFront distributions pointing to the same origin, for the same cost. – Michael - sqlbot Jan 29 '14 at 12:59

1 Answers1

2

The solution would be to only have multiple CF distributions in this case... one for images, another for static code (JS, CSS) etc. Typically if you are already keeping these images etc in S3 bucket, have separate bucket for each type (say one for image) and make these buckets origin servers in the CF distribution.

Having said that, the concurrent connections in a browsers have increased over time. It is not that small anyway. Typically a page needs to load only one JS (combined. minified), one CSS(combined. minified) and one Image for Icons (sprited). This is like only 1 + 3 connections - not too high. Other images (like large thumbnails etc) in the page anyway come from another CF distibution. So you dont have to "artifically" create sub-domains for performance.

This shows the state of connections now : (What's the maximum number of simultaneous connections a browser will make?)

Community
  • 1
  • 1
Sony Kadavan
  • 3,982
  • 2
  • 19
  • 26