This document discusses using URL rewriting to distribute static content across internet storage services to reduce load on virtual servers. It recommends uploading static content to Amazon S3 and using CloudFront as a content delivery network to serve the content globally with low latency. The implementation involves overwriting static content URLs in HTML to point to S3 or CloudFront, which can be done dynamically using Apache or Nginx filters without modifying the original files. This provides greater robustness, reduces costs, and handles latency through distributed caching of static assets.

1. URL REWRITING PATTERN
Problem to Be Solved
When a web service is provided by a virtual server, if the number of
accesses becomes too large, the load is handled by increasing the number
of virtual servers or upgrading the specifications of the virtual servers.
However, often the majority of the accesses are requests for static
content, so how to distribute access to static content has become an
important issue.
Explanation of the Cloud Solution/Pattern
You can use Internet storage to distribute access of static content. This makes it
possible to handle the load without increasing the number of virtual servers.
Using this method requires that the URL for the static content be changed to a
URL for the Internet storage. But this does not imply that you always have to
adjust the static content directly; you can use the the Filter function of the web
server to change the URL at the time of delivery. Instead of delivering from
Internet storage, you can also deliver the content from a content delivery server.

2. Implementation
In AWS, you can use the Amazon Simple Storage Service (S3) to deliver static content. You can deliver content globally
without delay by using content located on Amazon Simple Storage Service (S3) as the original, and using the CloudFront
content delivery service.
(Procedure)
Upload (synchronize) a portion of the static content (JavaScript/CSS/images, etc.) of the EC2 to S3.
If necessary, generate a CloudFront using, as the original, the S3 where the static content has been uploaded
(synchronized). (When CloudFront is used, it is also possible to use an EC2 instance directly as the original server, rather
than S3.)
Overwrite the static content URLs in the HTML tags with those of the S3 or of CloudFront.
You can use the Apache filter module or Nginx, prepared as a proxy, to perform the overwriting dynamically.

3. CONFIGURATION

4. BENEFITS
• You can provide greater robustness to load and can also reduce EC2
costs through distributing the access of static content to
S3/CloudFront.
• You can use CloudFront as a way to handle latency caused by
distance in worldwide delivery.
• When mod_ext_filter/mod_sed, Nginx, or the like is used, you can
use this pattern by inserting a filter, without modifying the original
HTML file. You can easily fall back to the state where CloudFront is
not used, by simply turning the filter off.
BENEFITS
When CloudFront is used, there may be some cases where deletion or updating
may be delayed due to content caching.