This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.
# Appendix B: Static content configuration
By default, WordPress stores everything locally on the web server, which is block storage (Amazon EBS) for [single server deployment](simple-deployment.md), and file storage (Amazon EFS) for [elastic deployment](elastic-deployment.md). In addition to reducing storage and data transfer costs, moving static asset to Amazon S3 offers scalability, data availability, security and performance.
In this example, the W3 Total Cache (W3TC) plugin is used to store static assets on Amazon S3. However, there are other plugins available with similar capabilities. If you want to use an alternative you can adjust the following steps accordingly. The steps only refer to features or settings relevant to this example. A detailed description of all settings is beyond the scope of this document. Refer to the [W3 Total Cache plugin page](https://wordpress.org/plugins/w3-total-cache/) at [wordpress.org](https://wordpress.org/) for more information.
# User creation
You need to create a user for the WordPress plugin to store static assets in Amazon S3. For steps, refer to [Creating a user in your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html).
**Note:** Roles provide a better way of managing access to AWS resources, but at the time of writing, the W3 Total Cache plugin does not support [ roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html).
Take a note of the user security credentials and store them in a secure manner – you need these credentials later.
# Amazon S3 bucket creation
1. First, create an Amazon S3 bucket in the AWS Region of your choice. For steps, refer to [Creating a bucket](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html). Enable static website hosting for the bucket by following the [Tutorial: Configuring a static website on Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsiteConfiguration.html).
1. Create a policy to provide the user created previously access to the specified S3 bucket, and attach the policy to the user. For steps to create the following policy, refer to [Managing Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Stmt1389783689000",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:DeleteObject",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:ListBucket",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::wp-demo",
"arn:aws:s3:::wp-demo/*"
]
}
]
}
```
------
1. Install and activate the W3TC plugin from the WordPress admin panel.
1. Browse to the **General Settings** section of the plugin’s configuration, and ensure that both **Browser Cache** and **CDN** are enabled.
1. From the drop-down list in the CDN configuration, choose **Origin Push: Amazon CloudFront** (this option has Amazon S3 as its origin).
1. Browse to the Browser Cache section of the plugin’s configuration and enable the **expires**, **cache control**, and **entity tag (ETag)** headers.
1. Also activate the **Prevent caching of objects after settings change** option so that a new query string is generated and appended to objects whenever any settings are changed.
1. Browse to the CDN section of the plugin’s configuration and enter the security credentials of the user you created earlier, as well as the name of the S3 bucket.
1. If you are serving your website via the CloudFront URL, enter the distribution domain name in the relevant box. Otherwise, enter one or more CNAMEs for your custom domain name(s).
1. Finally, export the media library and upload the wp-includes, theme files, and custom files to Amazon S3 using the W3TC plugin. These upload functions are available in the **General** section of the **CDN** configuration page.
# Static origin creation
Now that the static files are stored on Amazon S3, go back to the CloudFront configuration in the CloudFront console, and configure Amazon S3 as the origin for static content. To do that, add a second origin pointing to the S3 bucket you created for that purpose. Then create two more cache behaviors, one for each of the two folders (`wp-content` and `wp-includes`) that should use the S3 origin rather than the default origin for dynamic content. Configure both in the same manner:
+ Serve HTTP GET requests only.
+ Amazon S3 does not vary its output based on cookies or HTTP headers, so you can improve caching efficiency by not forwarding them to the origin via CloudFront.
+ Despite the fact that these behaviors serve only static content (which accepts no parameters), you will forward query strings to the origin. This is so that you can use query strings as version identifiers to instantly invalidate, for example, older CSS files when deploying new versions. For more information, refer to the [Amazon CloudFront Developer Guide](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ReplacingObjects.html).
**Note**
After adding the static origin behaviors to your CloudFront distribution, check the order to ensure the behaviors for `wp-admin/*` and `wp-login.php` have higher precedence than the behaviors for static content. Otherwise, you may see strange behavior when accessing your admin panel.