Using the Services menu, navigate to CloudFront in the AWS Console. Select your distribution from the Distributions list on the CloudFront landing page. Click the Origins tab and Create Origin. You will once again be in the Create Origin view, from which you will select your S3 bucket as the Origin Domain Name. A drop-down appears when you begin editing the field. When you select your bucket, an Origin ID will be auto-generated. You can leave this as is.
Currently, we’re not planning to make the photos in our application private. However, we very well could want to make user content private (or at least restricted) at a later date. As a first step in supporting this functionality, we have to restrict direct access to the bucket. When we set the Restrict Bucket Access value to Yes, the S3 URLs will no longer be public, and users will only be able to access the content at CloudFront URLs.
139
Because we’re restricting bucket access, we will have to create a CloudFront Access Identity with permissions to access the S3 buckets. While this may sound like something you manage in IAM, these identities are entirely managed within CloudFront. Select Create a New Identity to generate a new
CloudFront origin access identity. In the Comment field, you can enter a string to identify the identity you’re creating, something like access-identity-photoalbums-cloudfront.
Next, you will be asked if you want to Grant Read Permissions on Bucket. This is a convenient method to update the policy on your S3 bucket, so you don’t have to do this manually. Select Yes, Update Bucket Policy. If everything looks like Figure 5-13, click Create to proceed.
Figure 5-13. Creating a CloudFront Origin for the S3 bucket
CloudFront S3 Behavior
Now that we have created a CloudFront origin for our S3 bucket, we have to create the behavior that will route requests to that origin. Select the Behaviors tab. You should recognize this view from when we were experimenting with caching behavior in Chapter 4. You’ll notice that so far, all of our behaviors have the same origin: the load balancer from our application stack. But as discussed before, it would be a waste of resources to make our application serve the image uploads to users. This time, we will create a behavior that originates in the S3 bucket, completely removing the application stack from the equation.
Click Create Behavior at the top-left corner. Once again, you have to input a path pattern for the behavior. In the Path Pattern field, enter /uploads/* to catch all requests to the uploads folder. In the Origins field, expand the drop-down and choose the origin you just created, which corresponds to the S3 bucket.
Leave the other fields alone until we reach Object Caching. Because we will not be sending custom origin headers from our application stack, we want CloudFront to control the TTL for these assets. Select Customize and in the Minimum TTL field, enter 43200 (seconds), for 12 hours. Assets retrieved from our S3 bucket will be refreshed in CloudFront after a minimum of 12 hours, which you can certainly change to any other value if you have a preference.
Going through the rest of the options, we will not forward query strings or cookies or change any other value. Review your choices to be sure they match Figure 5-14 and click Create.
You’ll notice that the new behavior appears at the bottom of the behaviors list, except for Default(*), which is always at the bottom. There’s no need to move this behavior to the top of the list, as there is no conflict with our existing behaviors. Once again, it will take a few moments for the changes in CloudFront to propagate. You can keep an eye on the Status field in the distributions list, waiting for yours to change from In Progress to Deployed.
Now it’s time for the moment of truth! Find a jpeg image file that you want to use to create a photo. We’re assuming you’ve created a user and album already in production. If you haven’t, make those requests now, and you should have a userID of 1 and albumID of 1. Now make a POST request to www.[your domain]. com/photos/upload. Include the following parameters in your form data:
albumID: 1 userID: 1
caption: 'my first real photo'
The file key should be photo, and be sure to set the Content-Type to application/x-www-form- Figure 5-14. Create CloudFront behavior for /uploads/*
141
Your response headers should look like Listing 5-14. You’ll notice that the X-Cache header shows a miss from CloudFront. The response should never be a hit from CloudFront, or you would without a doubt be seeing the wrong data.
Listing 5-14. Photo Upload Response Headers
Content-Type: application/json; charset=utf-8 Content-Length: 9
Connection: keep-alive
Date: Mon, 15 Dec 2014 21:02:57 GMT X-Powered-By: Express
X-Cache: Miss from cloudfront
Via: 1.1 eadedd3fe9e82c51cc035044b3a5f3fa.cloudfront.net (CloudFront) X-Amz-Cf-Id: yRWUsgyOTSh4xw5NcKfX-ne2-N7EU9yUIQYot9J82xcF1elqiRgBnw==
Next, let’s validate that the data we uploaded to the application was stored correctly and is now accessible. Open your browser to www.[your domain].com/photos/id/21 (replacing 21 with the ID you received). You should see JSON similar to the following:
[ {
"photoID":21,
"caption":"my first real photo",
"url":"uploads/1/141867737733318085bdee7f0a1577a57200e59c65306.jpg", "albumID":1,
"userID":1 }
]
There’s a URL for the image! Next, as long as the CloudFront behavior changes are complete, you should be able to access the image at your domain. Copy the URL, add it to your domain, and try to view it in your browser. You should see your image!