Secure a Portfolio with CloudFront

Secure an S3 portfolio with CloudFront HTTPS, private origins, and edge caching.

Introduction

30 Second Summary

Visitors expect a portfolio to load quickly from a secure link. A public storage address exposes more of the site than they need to reach.

In this project, you will place Amazon CloudFront in front of your existing Amazon S3 portfolio to serve it over HTTPS. The S3 bucket becomes a private origin while a test asset makes edge caching visible.

What You'll Build

You'll open one secure CloudFront link to your portfolio while its former public S3 address stays locked.

By the end of this project, you'll have:

  • A shareable CloudFront portfolio URL that loads over HTTPS.
  • A private S3 origin that rejects direct public requests while CloudFront continues serving the portfolio.
  • Visible cache evidence showing a miss, a hit, stale content, and a completed invalidation in Microsoft Edge.
  • Secret Mission: A versioned test asset that appears through a new cache key without an invalidation.

Are there any prerequisites?

You need an existing public static portfolio in Amazon S3 with permission to manage its access settings plus CloudFront resources. A Windows device provides the browser tools used for cache checks.

Before We Start

Before any hands-on work begins, a clear migration target keeps later access changes tied to the right site. This checkpoint captures why Amazon CloudFront belongs in front of your Amazon S3 portfolio.

Audit Your S3 Portfolio

Your existing Amazon S3 portfolio is about to gain an Amazon CloudFront front door. A reliable baseline shows exactly what still works before its access model changes.

Changing origin permissions without that baseline can cause avoidable downtime. This audit captures the site's current delivery details before you secure the bucket.

In this step, get ready to:
  • Sign in to the AWS Management Console and open your existing portfolio bucket.
  • Document the bucket's website delivery details.
  • Verify public access and review the current permissions model.
Open and document the bucket

The AWS Management Console holds the bucket's authoritative configuration. Its website settings give you the migration details that later checks depend on.

Your credentials stay inside the AWS sign-in flow throughout this project.

  • Press the Windows key to open Windows search.
  • Type Microsoft Edge.
  • Press Enter to open Microsoft Edge.
  • Visit the official Amazon S3 console.
  • Complete the AWS sign-in prompts for your account.
  • Choose General purpose buckets in the left navigation pane.
  • Find the bucket name from your migration notes.
  • Choose the recorded bucket name to open it.

You'll see your bucket name at the top of the page. The bucket's objects and configuration tabs are now available for this audit.

  • Confirm that the displayed bucket name matches your earlier migration note.
  • Record the displayed AWS Region here: your bucket Region.
  • Choose the Properties tab.
  • Find the Static website hosting section.
  • Record the Endpoint value here: your S3 website endpoint.

Why Record the Website Endpoint?

An S3 website endpoint is a browser-facing address for public objects. It supports HTTP delivery without HTTPS.

Recording this endpoint gives you a clean before-and-after test for the migration.

  • Record the configured Index document value here: your homepage object name.
  • Choose the Objects tab.
  • Identify one small existing asset in the object list.
  • Record its exact object key here: your small asset path.

Pick a Dependable Asset

A small stylesheet or image makes a dependable test asset. Its object key must preserve every folder name and capital letter shown in Amazon S3.

Verify the public baseline

A baseline confirms that anonymous visitors can still reach the portfolio before its permissions change. Microsoft Edge lets you test the same public route that a visitor uses.

Before you test the two URLs, do you expect the homepage and selected asset to load without an AWS sign-in prompt?

  • Open a new tab in Microsoft Edge.
  • Enter your S3 website endpoint in the address bar.
  • Press Enter to request the homepage.

You'll see the existing portfolio homepage. This confirms that the recorded website endpoint currently serves the configured homepage object.

  • Open another tab in Microsoft Edge.
  • Enter your S3 website endpoint/your small asset path in the address bar.
  • Press Enter to request the asset.

You'll see the selected asset load directly from its public S3 path. The homepage and asset now form your working baseline.

What Did the Baseline Prove?

Both objects are anonymously readable through the S3 website endpoint. Your later CloudFront checks can now distinguish a migration problem from an existing site problem.

Review Object Ownership and ACLs

The Object Ownership setting determines whether policies or access control lists manage object ownership. Bucket owner enforced disables ACLs and gives the bucket owner full control of every object.

This permission check is fiddly because an external access control list grant can belong to another AWS account. Required external grants must be migrated before ACLs are disabled.

  • Return to the Amazon S3 bucket tab from earlier.
  • Choose the Permissions tab.
  • Find the Object Ownership section.
  • Review the displayed ownership setting.
  • Find the Access control list (ACL) section.
  • Review every listed grant for access outside the bucket owner's account.

✔️ Bucket owner enforced is selected

Good work. The bucket already uses policies as its access-control mechanism.

  • Leave the Object Ownership setting unchanged.

ⓧ ACLs are enabled with no external grants

The bucket and its objects belong to your account. No required external ACL grants block the safer ownership model.

  • Choose Edit in the Object Ownership section.
  • Select Bucket owner enforced.
  • Choose Save.

Amazon S3 now uses policies for access control. ACLs no longer control the bucket's objects.

ⓧ External ACL grants are required

An external grant needs a deliberate migration plan before ACLs can be disabled. Continuing now could remove access that another account or public visitor still requires.

  • Leave the current Object Ownership setting unchanged.
  • Pause the project before changing the ownership model.
  • Migrate each required external permission to a policy before returning to this review.

Before the final check, do you expect the same homepage and asset to remain publicly accessible?

  • Return to the Microsoft Edge tab showing the portfolio homepage.
  • Refresh the homepage.
  • Return to the Microsoft Edge tab showing the selected asset.
  • Refresh the asset.

You'll see the portfolio homepage and selected asset load through the original S3 website endpoint. Your baseline remains intact after the ownership review.

Portfolio or Asset No Longer Loads?

  • Compare the website endpoint with the exact Endpoint value in Static website hosting.
  • Compare the homepage name with your homepage object name.
  • Check every capital letter in your small asset path.
  • Ask for targeted help with diagnosing the S3 baseline failure.

Your bucket details and public baseline are documented. Next, you will close direct public access and create the CloudFront distribution that replaces it.

Create a Private CloudFront Origin

Your baseline confirms that the portfolio works through its public Amazon S3 website endpoint. That endpoint cannot use Origin Access Control, so it cannot support the private origin this design needs.

You will move the bucket to a private access model. You will then create an Amazon CloudFront distribution that can request the portfolio objects securely.

In this step, get ready to:
  • Protect the existing portfolio bucket from anonymous public access.
  • Create a CloudFront distribution named portfolio-cloudfront with the regular S3 bucket as its origin.
  • Document the distribution details for the next stage of the migration.
Block anonymous S3 access

S3 Block Public Access overrides public policies that expose a bucket. Enabling every setting closes the anonymous delivery path while preserving the portfolio objects.

  • In the existing portfolio bucket from earlier, select the Permissions tab.
  • Find Block public access (bucket settings).
  • Choose Edit.
  • Select Block all public access.
  • Choose Save changes.
  • Complete the confirmation prompt if AWS displays one.

Before you reload the portfolio, do you think the recorded S3 website endpoint can still accept an anonymous request?

  • Switch back to the recorded website endpoint in Microsoft Edge.
  • Reload the page.

You will see an access error. The portfolio no longer loads from its public S3 website endpoint.

Why Is This Failure Useful?

The access error proves that anonymous requests can no longer reach the bucket. Your portfolio files remain stored in S3 for an authenticated CloudFront origin request.

Does the Portfolio Still Load?

  • Confirm that the bucket summary shows Block all public access as enabled.
  • Compare the Edge address bar with the S3 website endpoint recorded earlier.
  • Load the recorded endpoint in a new Edge tab to avoid displaying the previously loaded page.

Ask for targeted help with diagnosing public S3 access after enabling Block Public Access.

Create the CloudFront distribution

Origin Access Control lets CloudFront sign requests to a regular S3 bucket origin. An S3 website endpoint cannot use this access model.

The recommended origin settings create Origin Access Control for the regular bucket origin. The wizard adds a distribution-specific bucket permission after creation.

  • Use the AWS Management Console search bar to search for Amazon CloudFront.
  • Select Amazon CloudFront from the search results.
  • Choose Create distribution.
  • Enter portfolio-cloudfront in Distribution name.
  • Choose Single website or app.
  • Choose Next.
  • Select Amazon S3 for Origin type.
  • Choose Browse S3.

The origin picker lists your regular S3 bucket. Selecting that bucket keeps the origin compatible with Origin Access Control.

  • Select the existing portfolio bucket that matches the bucket name recorded earlier.
  • Choose Use recommended origin settings.

Optional AWS WAF protections sit outside this cache-focused project. The distribution stays focused on private origin access.

  • Continue without adding optional AWS WAF protections on the Enable security protections page.

Choose the Pricing Path Available to You

Billing choices can feel high-stakes. The Free plan costs $0/month per distribution when it is available to your account.

Pay-as-you-go charges each service according to actual usage.

Free plan available

Your account can use the eligible flat-rate path for this distribution.

  • Select the Free plan.
  • Record the selected pricing plan as your selected CloudFront pricing plan.

Free plan unavailable

Your account continues through the usage-based pricing path.

  • Select the pay-as-you-go option.
  • Record the selected pricing plan as your selected CloudFront pricing plan.

What Does Distribution Creation Change?

CloudFront creates an Origin Access Control associated with the selected S3 origin. It updates the bucket policy so the distribution can request portfolio objects.

The generated permission uses the service principal cloudfront.amazonaws.com. It grants s3:GetObject for this distribution.

  • Review the distribution summary to confirm that the recorded portfolio bucket appears as the origin.
  • Choose Create distribution.

CloudFront opens the distribution details. The Last modified field should show Deploying.

Distribution Creation Failed?

  • Confirm that the selected origin is the existing S3 bucket.
  • Confirm that Use recommended origin settings remains selected.
  • Check that your AWS identity can create CloudFront distributions.
  • Check that your AWS identity can update the existing S3 bucket policy.

Ask for help with troubleshooting the CloudFront distribution creation.

Confirm the private origin

Deployment is the slow part, so Deploying is a healthy status here. The Last modified field changes to a date and time after the distribution finishes deploying.

  • Record the distribution ID as your CloudFront distribution ID.
  • Record the assigned domain name as d111111abcdef8.cloudfront.net.
  • Confirm that Last modified shows Deploying.
  • Return to the existing portfolio bucket in Amazon S3.
  • Select the Permissions tab.
  • Find the CloudFront statement under Bucket policy.
  • Confirm that the statement names cloudfront.amazonaws.com as the service principal.
  • Confirm that the statement grants s3:GetObject for the new distribution.

The bucket policy now permits authenticated reads from this CloudFront distribution. Block Public Access continues to prevent anonymous public reads.

CloudFront Permission Missing?

  • Check that the distribution origin names the recorded S3 bucket.
  • Check that the origin has an associated Origin Access Control.
  • Confirm that your AWS identity can update the bucket policy.

Ask for targeted help with finding the CloudFront bucket-policy statement.

Before you check both surfaces, which delivery path do you expect to deny an anonymous request?

  • Switch back to the recorded S3 website endpoint in Edge.
  • Reload the page.
  • Return to the CloudFront distribution's Details page in the AWS Management Console.
  • Read the Last modified field.

The S3 website endpoint remains inaccessible to anonymous requests. The CloudFront distribution shows Deploying with the private bucket configured as its origin.

You have closed the public S3 path and started a CloudFront distribution with private origin access. Next, you will restore the portfolio through HTTPS.

Deliver the Portfolio Over HTTPS

You closed the old public Amazon S3 route in the previous step. The portfolio now needs a viewer-facing path again.

Amazon CloudFront can read the private bucket through Origin Access Control. Its viewer endpoint gives visitors an encrypted HTTPS connection.

In this step, get ready to:
  • Wait for the CloudFront distribution to finish deploying.
  • Set the default root object to index.html.
  • Verify that CloudFront delivers the private portfolio over HTTPS.
Wait for the distribution to deploy

CloudFront must distribute its configuration before it can serve the portfolio. The deployment can take a while, so a quiet console does not mean the process has stalled.

The Last modified field is the reliable deployment signal. A date and time means the distribution is ready for a viewer request.

  • Return to Amazon CloudFront in the AWS Management Console.
  • Select the distribution named portfolio-cloudfront.
  • Find the Last modified field in the distribution details.
  • Wait until Last modified shows a date and time.

Before you test the new route, do you expect CloudFront to reach the private portfolio through its origin permission?

  • Switch back to Microsoft Edge from earlier.
  • Enter your recorded CloudFront domain in the address bar.
  • Add /index.html to the end of the domain.
  • Press Enter.

You should see the portfolio load from the CloudFront domain over HTTPS. That restores the delivery path while the S3 bucket remains private.

How Does CloudFront Reach the Bucket?

Origin Access Control signs CloudFront requests to the regular S3 bucket origin. The bucket policy allows those authenticated requests through the distribution-specific permission.

Visitors use the CloudFront domain. CloudFront becomes the only public delivery path for the portfolio.

Portfolio Does Not Load?

Confirm that Last modified shows a date and time. A distribution that still shows Deploying is not ready for this check.

Check that the path ends with the recorded homepage capitalization. The expected path in this project is /index.html.

Ask for targeted help with diagnosing the CloudFront portfolio request.

Configure the root and HTTPS behavior

A default root object maps a request for the CloudFront root domain to index.html. The viewer protocol policy redirects HTTP requests to HTTPS.

  • Switch back to the portfolio-cloudfront distribution details.
  • Select the General tab.
  • Choose Edit.
  • Enter index.html in Default root object.
  • Choose Save changes.
  • Wait until Last modified returns to a date and time.

The root object must have no leading slash. The exact value is index.html.

  • Select the Behaviors tab.
  • Select the default cache behavior.
  • Choose Edit.
  • Set Viewer protocol policy to Redirect HTTP to HTTPS.
  • Set Cache policy to CachingOptimized.

The behavior editor should now show the HTTPS redirect and the managed CachingOptimized policy.

  • Choose Save changes.
  • Wait until Last modified shows a date and time again.

Why Keep CachingOptimized?

The managed CachingOptimized policy gives CloudFront a standard cache key for static content. Valid copies can be served from edge caches without another S3 request.

This keeps the behavior focused on static portfolio delivery. The next step makes that caching visible inside Edge.

Distribution Update Is Not Ready?

Keep the distribution page open until Last modified changes from Deploying to a date and time. Testing during deployment can show the previous configuration.

Ask for help with checking the root object and default behavior.

Protect the origin and compare both paths

The bucket policy is the bridge between the private origin and CloudFront. It must retain the CloudFront read permission without leaving an old anonymous public-read statement behind.

  • Return to Amazon S3 in the AWS Management Console.
  • Select your recorded portfolio bucket.
  • Select the Permissions tab.
  • Find the bucket policy.
  • Confirm that the CloudFront statement names cloudfront.amazonaws.com as its service principal.
  • Confirm that the statement grants s3:GetObject for this distribution.

Which Policy Statement Must Stay?

The CloudFront service-principal statement allows the distribution to read portfolio objects. Its source condition ties that permission to your recorded distribution.

Preserving this statement keeps the private origin reachable through CloudFront. Anonymous viewers still cannot request objects directly from S3.

The policy can now be in one of two states. Choose the tab that matches what you see.

✔️ Only CloudFront access remains

The policy retains the CloudFront service-principal permission. No old anonymous public-read statement remains, so no policy edit is needed.

ⓧ An anonymous statement remains

Block Public Access currently overrides the old statement. Removing it makes the policy match the private-origin design.

  • Remove only the statement that grants anonymous public read.
  • Preserve the statement for cloudfront.amazonaws.com.
  • Choose Save changes.

Before you compare the two routes, which one should now act as the public front door for the portfolio?

  • Switch back to Microsoft Edge.
  • Enter the HTTP form of your recorded CloudFront root URL in the address bar.
  • Press Enter.

The address bar should change to an HTTPS URL. You should see the portfolio at the CloudFront root domain.

  • Enter your recorded HTTPS CloudFront domain with /index.html in the address bar.
  • Press Enter.

You should see the same portfolio through the explicit homepage path. Both CloudFront routes now reach the private origin.

  • Enter your recorded S3 website endpoint in the address bar.
  • Press Enter.

You should still see an access error from the direct S3 website endpoint. That is the intended result because CloudFront is now the public delivery layer.

Checkpoint

  • The CloudFront root URL displays the portfolio over HTTPS.
  • The /index.html path displays the same portfolio.
  • An HTTP CloudFront request redirects to HTTPS.
  • The direct S3 website endpoint denies anonymous access.
  • The bucket policy retains the CloudFront s3:GetObject permission without an old anonymous public-read statement.

Do the Delivery Paths Behave Differently?

Confirm that the latest distribution update has finished deploying. A behavior change can remain unavailable while Last modified still shows Deploying.

Check that Default root object contains index.html without a leading slash. Check that the bucket policy still contains the CloudFront read statement.

Ask for targeted help with comparing the CloudFront and S3 results.

Your portfolio now has a secure CloudFront front door backed by a private S3 origin. Next, you will watch an edge cache answer real asset requests.

Observe CloudFront Cache Behavior

Your portfolio now reaches visitors through Amazon CloudFront. A successful page load does not reveal whether Amazon S3 or an edge cache supplied the response.

A response headers policy exposes Server-Timing diagnostics on each request. A dedicated text object gives you a stable cache key for observing a miss followed by a hit.

In this step, get ready to:
  • Expose Server-Timing diagnostics on the default CloudFront behavior.
  • Publish a dedicated test object at the root of the private S3 bucket.
  • Compare the first CloudFront response with a repeated response.
Create and attach the diagnostic policy

CloudFront can add diagnostic response headers without changing the portfolio files. A sampling rate of 100 adds the Server-Timing header to every response that matches the attached behavior.

Why Use Response Headers?

Response headers describe how CloudFront handled a request. They let you inspect cache behavior directly in the browser.

This keeps the test focused on one request at a time. You can see whether CloudFront contacted Amazon S3 or answered from an edge cache.

  • Return to Amazon CloudFront in the AWS Management Console tab from earlier.
  • Select Policies in the left navigation pane.
  • Select Response headers.
  • Select Create response headers policy.
  • Enter portfolio-server-timing in the Name field.
  • Enable Server-Timing header.
  • Enter 100 as the sampling rate.
  • Select Create.

The policy list now includes portfolio-server-timing. Its Server-Timing sampling rate is 100.

  • Return to the portfolio-cloudfront distribution.
  • Select the Behaviors tab.
  • Select the default cache behavior.
  • Select Edit.
  • Select portfolio-server-timing under Response headers policy.
  • Select Save changes.

CloudFront needs time to deploy the behavior update across its network. A Deploying value means the update is still moving through that process.

  • Select the General tab.
  • Wait until Last modified changes from Deploying to a date and time.

The completed deployment confirms that portfolio-server-timing is active on the default behavior.

Policy Missing From the Behavior?

Confirm that the policy name is exactly portfolio-server-timing. Return to Policies to verify that its Server-Timing sampling rate is 100.

Check that you edited the default cache behavior for portfolio-cloudfront.

Ask for help with attaching the response headers policy.

Create a dedicated cache test object

A small file gives the cache test one predictable response. You will create it with Windows Notepad before uploading it to the bucket root.

  • Press the Windows key to open Windows search.
  • Type Notepad.
  • Select Notepad from the results.
  • Add the version 1 payload to the blank Notepad file by entering this exact line:
Portfolio cache test: version 1

What Does This File Do?

This file creates a dedicated object for the cache experiment. Its short payload makes stale or refreshed content easy to identify.

The filename becomes the object path that CloudFront uses when constructing the cache key.

  • Select File in Notepad.
  • Select Save As.
  • Choose your Desktop as the save location.
  • Enter cloudfront-cache-lab.txt in the File name field.
  • Select Save.

✔️ Awesome, I've got everything!

The complete local file contains the version 1 test payload.

ⓧ I'd like to double check the full code

Portfolio cache test: version 1

What Should Match?

The file contains one line with the exact version 1 payload. The filename is exactly cloudfront-cache-lab.txt.

The top level of the bucket's Objects tab represents the bucket root. Uploading from that level creates the path /cloudfront-cache-lab.txt.

  • Return to the existing S3 bucket in the AWS Management Console.
  • Select the Objects tab.
  • Select Upload.
  • Select Add files under Files and folders.
  • Choose cloudfront-cache-lab.txt from your Desktop.
  • Select Open.
  • Select Upload.

Good progress. The upload status now shows success for cloudfront-cache-lab.txt. The private bucket contains the test object at its root.

Upload Did Not Succeed?

Confirm that the filename ends with .txt. Check the Desktop location if the file is absent from the file picker.

Verify that you started the upload from the top-level Objects tab. A selected folder adds a prefix to the object path.

Ask for help with uploading the test object to the bucket root.

Observe a miss and a hit

The browser cache in Microsoft Edge can hide CloudFront behavior by reusing a local response. Disable cache keeps the browser cache out of this test while CloudFront caching stays active.

How Does the Cache Key Matter?

CloudFront compares each request with the cache keys already stored at an edge location. The same path can reuse a valid cached object.

The managed CachingOptimized policy excludes query strings and cookies from this cache key. Repeating the same path keeps the comparison stable.

  • Return to the Microsoft Edge tab containing the CloudFront portfolio.
  • Press Ctrl+Shift+I to open DevTools.
  • Select Network.
  • Enable Disable cache.

Before you request the new path, do you expect CloudFront to find a valid cached copy?

  • Replace the path in the current CloudFront URL with /cloudfront-cache-lab.txt.
  • Press Enter to request the asset.

You will see Portfolio cache test: version 1 in the browser. The request also appears in the Network panel.

  • Select the cloudfront-cache-lab.txt request in the Network panel.
  • Select Headers.
  • Find Server-Timing under Response Headers.

The first response includes cdn-cache-miss. You have captured the first half of the cache story because CloudFront fetched the full object from Amazon S3.

What Does the Miss Prove?

A cdn-cache-miss marker means the edge cache did not provide the response. CloudFront requested the full object from the S3 origin.

CloudFront can now store that response at the edge for another request with the same cache key.

Before you repeat the request, what should change now that the edge cache has a valid copy?

  • Refresh the asset URL in Microsoft Edge.
  • Select the newest cloudfront-cache-lab.txt request in the Network panel.
  • Inspect Server-Timing under Response Headers.

The repeated response includes cdn-cache-hit. You now have direct evidence that an edge cache answered without requesting the object from Amazon S3.

  • Add cdn-cache-miss followed by cdn-cache-hit for /cloudfront-cache-lab.txt to your migration notes.
  • Leave DevTools open on the Network panel.
  • Keep Disable cache enabled.

Still Seeing a Cache Miss?

Keep the CloudFront URL unchanged between requests. A different path creates a different cache key.

Confirm that Disable cache is enabled in Microsoft Edge DevTools. Leave CloudFront caching enabled through CachingOptimized.

Ask for help with diagnosing repeated CloudFront cache misses.

Cache Behavior Checkpoint

  • The portfolio-server-timing policy is attached to the default behavior with a sampling rate of 100.
  • The private S3 bucket contains cloudfront-cache-lab.txt at its root with the exact version 1 payload.
  • The CloudFront root URL, /index.html, and /cloudfront-cache-lab.txt remain available over HTTPS.
  • The direct S3 website endpoint remains denied while CloudFront retains authorized object access.
  • The migration notes record cdn-cache-miss followed by cdn-cache-hit for the same asset path.

You have proved that CloudFront fetches an uncached object from Amazon S3 before serving a valid edge copy. Next, you will use this evidence to control stale content.

Invalidate Stale Content

Your earlier requests proved that Amazon CloudFront can answer from an edge cache. The same speed can preserve an older response after Amazon S3 changes.

That gap can leave a live portfolio behind its source file. You will expose the stale copy before restoring the viewer-facing asset.

In this step, get ready to:
  • Overwrite the test object with Portfolio cache test: version 2.
  • Expose the stale version through Microsoft Edge using the same cache key.
  • Refresh the exact cached path before verifying a miss followed by a hit.
Expose the stale cached copy

The unchanged asset URL produces the same cache key at CloudFront. A valid edge copy can outlive a newer S3 object.

  • Return to the local cloudfront-cache-lab.txt file from the earlier cache test in Windows Notepad.
  • Replace Portfolio cache test: version 1 with Portfolio cache test: version 2.

Windows Notepad should now show only Portfolio cache test: version 2.

  • Save cloudfront-cache-lab.txt.
  • Upload the saved cloudfront-cache-lab.txt to the root of the same S3 bucket.

Amazon S3 should report a successful upload for the root object. The origin now contains Portfolio cache test: version 2.

Before you refresh, do you expect the unchanged CloudFront URL to show version 1 or version 2?

  • Refresh the existing CloudFront HTTPS URL for /cloudfront-cache-lab.txt in Microsoft Edge.

You should still see Portfolio cache test: version 1. That stale result is intentional.

  • Select the newest cloudfront-cache-lab.txt request in Edge DevTools.
  • Open Headers.
  • Inspect Response Headers.

The Server-Timing response should include cdn-cache-hit. This confirms that the stale response came from the edge cache.

Why Is Version 1 Still Visible?

The unchanged path produced the same cache key. CloudFront found a valid edge object.

The cdn-cache-hit marker confirms that CloudFront answered without contacting S3. Uploading a replacement object does not purge that cached response.

Version 2 Appeared Immediately?

  • Confirm that the request uses the exact /cloudfront-cache-lab.txt path.
  • Confirm that Disable cache remains enabled in Edge DevTools.

Your earlier edge copy may have expired. Ask for help with checking why the stale response did not appear.

Invalidate the stale path

A cache invalidation removes a specific cached path from CloudFront. It refreshes that path before the object's TTL expires.

Check the Path Before Submitting

A submitted invalidation cannot be canceled. This request contains one exact path.

The first 1,000 invalidation paths submitted across an AWS account each month are free. This invalidation uses one path.

  • Return to Amazon CloudFront in the AWS Management Console.
  • Select portfolio-cloudfront from the distribution list.
  • Choose Invalidations.
  • Choose Create invalidation.
  • Enter /cloudfront-cache-lab.txt as the only invalidation path.
  • Choose Create invalidation to submit the path.

CloudFront distributes the request across its edge locations. The wait varies without indicating a problem.

  • Wait for the invalidation status to become complete.

The completed status confirms that CloudFront has removed the stale cached path. The next request can fetch the updated object from S3.

Invalidation Still Processing?

  • Keep the distribution page available until the status becomes complete.
  • Avoid submitting a duplicate invalidation for the same path.

Ask for help with checking a CloudFront invalidation that has not completed.

Verify the fresh cache cycle

The completed invalidation leaves no valid cached copy for this path. Two requests now reveal how CloudFront repopulates its cache.

Before you refresh, which asset version and cache result do you expect on the first response?

  • Switch back to the Microsoft Edge tab for the same /cloudfront-cache-lab.txt URL.
  • Confirm that Disable cache remains enabled in the Network tool.
  • Refresh the page.
  • Select the newest cloudfront-cache-lab.txt request.
  • Open Headers.
  • Inspect Response Headers.

You should see Portfolio cache test: version 2 on the page. The Server-Timing response should include cdn-cache-miss.

Before you refresh again, do you expect CloudFront to contact S3 for the same cache key?

  • Refresh the same asset URL again.
  • Select the newest cloudfront-cache-lab.txt request.
  • Inspect Server-Timing under Response Headers.

The second response should include cdn-cache-hit. CloudFront is now serving version 2 from its edge cache.

  • Record that version 2 appeared after invalidating /cloudfront-cache-lab.txt in your Migration Notes.
  • Add the post-invalidation cdn-cache-miss followed by cdn-cache-hit to the same note.

Still Seeing Version 1?

  • Confirm that the invalidation for /cloudfront-cache-lab.txt is complete.
  • Confirm that the S3 object contains Portfolio cache test: version 2.
  • Confirm that the requested path uses the same capitalization as the invalidation path.

Ask for help with diagnosing version 1 after a completed invalidation.

You closed the cache loop. Viewers now receive version 2 from the CloudFront edge cache.

Secret mission

Bust the Cache with a Versioned Asset Name

Publish the next test asset under a new filename. Watch its fresh path move from an origin fetch to a cached response without submitting an invalidation.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep your Amazon CloudFront delivery running, pause it for later, or remove the lab resources. The eligible CloudFront Free flat-rate plan costs $0/month per distribution.

Pay-as-you-go pricing and existing Amazon S3 usage charges apply otherwise.

Cost warning

The Free plan includes 1M requests, 100GB data transfer, and 5GB included S3 storage each month with no overage charges. Free Tier accounts cannot use CloudFront Flat-Rate Plans.

Pay-as-you-go pricing charges each service according to actual usage. Pausing or deleting the distribution prevents new CloudFront viewer traffic.

The first 1,000 invalidation paths submitted each month across all distributions in one AWS account are free.

Resources you used:

  • The CloudFront distribution portfolio-cloudfront with its assigned cloudfront.net domain.
  • The CloudFront-created Origin Access Control with its S3 bucket-policy statement granting cloudfront.amazonaws.com the s3:GetObject action.
  • The CloudFront response headers policy portfolio-server-timing.
  • The S3 test object cloudfront-cache-lab.txt containing version 2.
  • The S3 test object cloudfront-cache-lab-v3.txt containing version 3.

The completed invalidation for /cloudfront-cache-lab.txt cannot be canceled after submission. It needs no cleanup action.

Keep everything running

No action needed. Choose this if the portfolio should stay available through its CloudFront HTTPS URL.

  • Keep portfolio-cloudfront enabled.
  • Keep the existing S3 bucket private with Block Public Access enabled.
  • Keep portfolio-server-timing attached for cache diagnostics.
  • Keep both test objects for future cache experiments.
  • Share the assigned cloudfront.net URL as the portfolio's viewer-facing address.

Your portfolio remains available over HTTPS. The direct S3 website endpoint remains denied.

Pause - I'll come back to this later

Disable the CloudFront distribution to stop viewer delivery while preserving its configuration. The private S3 website endpoint stays unavailable because Block Public Access remains enabled.

  • Return to Amazon CloudFront in the AWS Management Console from earlier.
  • Select portfolio-cloudfront.
  • Open General.
  • Choose Disable for the distribution.
  • Confirm the disable request in the console.
  • Wait until Last modified changes from Deploying to a date and time.

The distribution is disabled, so its CloudFront URL no longer delivers portfolio requests. The private S3 bucket and all configuration remain ready to restore.

Delete - I don't want to use this again

Deleting the delivery layer looks final, but these instructions preserve your original portfolio objects in the private S3 bucket. Use this option when you no longer need the CloudFront lab.

  • Return to Amazon S3 in the AWS Management Console.
  • Select the existing private portfolio bucket.
  • Select cloudfront-cache-lab.txt.
  • Select cloudfront-cache-lab-v3.txt.
  • Choose Delete to remove the selected test objects.
  • Complete the deletion confirmation shown by Amazon S3.

The two test objects no longer appear in the bucket. Your portfolio files remain in place.

  • Return to Amazon CloudFront.
  • Select portfolio-cloudfront.
  • Disable portfolio-cloudfront if it is currently enabled.
  • Confirm the disable request in the console.
  • Wait until Last modified shows a date and time after the change.
  • Use the distribution's Delete action to remove portfolio-cloudfront.
  • Confirm the distribution deletion in the console.

The distribution no longer appears in CloudFront. Its assigned domain no longer delivers your portfolio.

  • Open the CloudFront page for Origin Access Control.
  • Select the Origin Access Control associated with the former portfolio-cloudfront S3 origin.
  • Use Delete to remove the selected Origin Access Control.
  • Open Policies in CloudFront.
  • Open Response headers.
  • Select portfolio-server-timing.
  • Use Delete to remove the selected response headers policy.

The project-specific Origin Access Control and response headers policy no longer appear in CloudFront.

  • Return to the existing private portfolio bucket in Amazon S3.
  • Open the bucket's Permissions tab.
  • Open the bucket policy editor.
  • Remove the statement that grants cloudfront.amazonaws.com the s3:GetObject action for portfolio-cloudfront.
  • Save the updated bucket policy.

That cleanup removes the CloudFront delivery layer while preserving your original portfolio objects. Block Public Access remains enabled on the S3 bucket.

Nice Work!

Nice Work!

You did it! Your portfolio now loads through Amazon CloudFront over HTTPS. Its Amazon S3 origin stays private behind Origin Access Control.

You've learned how to:

  • Provide secure edge delivery through the CloudFront HTTPS URL. Make root requests load index.html. Redirect HTTP viewers to HTTPS.
  • Protect the private S3 origin with Block Public Access. Let CloudFront read portfolio objects through Origin Access Control.
  • Observe cache behavior through Server-Timing. Identify cdn-cache-miss. Identify cdn-cache-hit. Refresh stale content by invalidating /cloudfront-cache-lab.txt.
  • Secret Mission: Publish version 3 as cloudfront-cache-lab-v3.txt. Prove that the versioned filename creates a fresh cache key without an invalidation. Confirm a cache miss on the first request. Confirm a cache hit on the next request.

Ready to quiz yourself?