Help
Most simple web applications are built as three-tier architectures. You might not even be aware of this, as it is (most of the time) unintentional. The three tiers of these applications are:
- Data (usually kept in a relational database)
- Logic (dynamic content generated in a web or application server)
- Presentation (static content provided by a web server)
Over time, web development frameworks slowly lost the distinction between the logic and presentation levels. Frameworks like PHP, Ruby on Rails, and Django rely on Apache modules, effectively merging the logic and presentation levels. Only when performance is an issue will these two layers be untangled, mainly because the overhead of Apache is not necessary to serve semistatic content.
But there is another alternative: CloudFront. Amazon CloudFront is a content distribution network, designed to bring static content as close to the end user as possible. It has edge locations all over the world, storing your files and delivering them upon request. Perhaps we don’t need the edge locations yet, but we can use CloudFront for its scalability and to offload our application server. We’ll use CloudFront as the presentation tier in our three-tiered architecture.
Setting Up S3 and CloudFront
Amazon S3 is a regional service, just like EC2 and RDS, while CloudFront is a global service. S3 works with buckets, and CloudFront works with distributions. One CloudFront distribution exposes the content of one S3 bucket (one bucket can be exposed by multiple distributions). CloudFront can serve content for download and streaming, provided the content allows for streaming.
At this moment, we want to store and serve the static content from S3/CloudFront. Because our application server is in the US East region (the default), we create our S3 bucket in the same region, which in the Console is called US Standard (Figure 2-12).
Figure 2-12. Create an S3 bucket
Note: S3 was only recently added to the Amazon AWS Console. We have worked with quite a few S3 applications, but are slowly switching to using the Console for our S3-related work. It is sufficient because we don’t need it very often and it is close to CloudFront, so we can quickly switch between the two.
With our S3 bucket, we can create the CloudFront distribution (Figure 2-13). One of the interesting things about CloudFront is that you can easily expose one distribution through multiple domains. We plan to have all static content accessible through
static[0..3].kulitzer.com. We will configure Rails to use these four domains to speed up page load times, since the browser will then be able to download several assets in parallel. This technique is one of the core features in Rails. For other frameworks, you might have to do some extra work to use several different domains.Figure 2-13. Create a CloudFront distribution
It might take a little while before your distribution is enabled. AWS has already determined the domain for the distribution:
d2l9lx40wmdm9x.cloudfront.net. Using this domain, we can add the CNAME records to our DNS.Static Content to S3/CloudFront
The distribution we just created serves content from the S3 bucket. We also created four domains pointing to this bucket. If we add content to the S3 bucket, it will be available from our CloudFront distribution through these domains. We want to serve our Javascript, CSS, and other static content like images from CloudFront. In Rails, this is fairly simple if you use the URL-generating helpers in AssetHelper. Basically, the only two things you need to do are to configure
config.action_controller.asset_host to point to the proper asset hosts, and upload the files to S3. We set the configuration in config/environments/production.rb like this:# Enable serving of images, stylesheets, and javascripts from an asset server config.action_controller.asset_host = "http://static%d.kulitzer.com"
Rails will replace the
%d with 0, 1, 2, or 3.After uploading the static content to the S3 bucket (make sure you make these objects public), the Kulitzer logo is served from http://static2.kulit...images/logo.jpg or one of the other domains. The result is that the assets a page needs are evenly requested from the different domains, allowing your browser to download them in parallel. Figure 2-14 shows our Kulitzer site set up using EC2, RDS, S3, and CloudFront.
Tip: Apart from increasing the scalability of your infrastructure, you also implemented one of the patterns for optimizing the performance of your web app. For Kulitzer, we use AssetPackager to optimize and simplify working with CloudFront even more. AssetPackager merges the Javascript and CSS files into one, speeding up load times.
One important aspect of CloudFront is how it distributes the assets from S3 to the edge locations. The edge locations get new copies within 24 hours at the most, and usually much quicker than that. You can override this behavior by specifying
Cache-Control, Pragma, or Expires headers on the object in S3. If you specify an expiration time of less than one hour, CloudFront uses one hour. If you want to force a particular object to be changed immediately, you can invalidate it by calling the Invalidation API. Invalidating a file removes it from all the CloudFront edge locations. The documentation says it is supposed to be used under exceptional circumstances, such as when you find an encoding error in a video and you need to replace it.Figure 2-14. Kulitzer.com
Case study: Publitas—CloudFront to the rescue
Publitas has developed a web application called ePublisher that enables its customers to publish rich content online, starting from a PDF. Right after the summer of 2010, Publitas found its dream customer. This customer was experiencing heavy web traffic and needed help to keep up.
With a large database of interested customers, Publitas figured it would be good to start relatively slowly, and it sent out email messages to 350,000 people. The message pointed people to the online brochure consisting of descriptions of products with rich media content like audio and video.
The response was overwhelming, and the servers couldn’t handle this. Luckily, ePublisher has an export feature, and the entire brochure was quickly exported to S3 and exposed through CloudFront. Everything was on a subdomain, so the system was only waiting for DNS to propagate the changes while rewriting incoming requests. And everything worked flawlessly. Publitas was happy and the customer was happy.
This particular brochure saw nearly 440,000 unique IPs and 30 terabytes of traffic in the first month.
Learn more about this topic from Programming Amazon EC2.
If you plan to build applications to run on Amazon's Web Services, the end-to-end approach in this book will save you needless trial and error. You'll find practical guidelines for designing and building applications with Amazon Elastic Compute Cloud (EC2) and a host of supporting AWS tools, with a focus on critical issues such as load balancing, monitoring, and automation.
