The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To publish a portfolio securely without managing a web server, store the built HTML, CSS, JavaScript, images and video in a private Amazon S3 bucket, then put an Amazon CloudFront distribution in front of it. CloudFront reads the bucket through Origin Access Control (OAC), provides HTTPS, caches files at edge locations and can serve a custom domain. Keep S3 Block Public Access enabled; do not expose the bucket or rely on the old public S3 website-endpoint pattern.
What this architecture does
A static portfolio is a collection of files delivered to a browser. Typical files include index.html, stylesheets, JavaScript bundles, fonts, photographs and videos. S3 stores those objects durably, while CloudFront is the public delivery layer. A visitor requests your CloudFront hostname, CloudFront serves a cached object when available, and it retrieves the object from S3 when it is not cached or has expired.
This design has three important consequences:
- S3 does not run PHP, Python, Ruby, server-side JavaScript or other server-side scripts. A contact form, blog admin, authentication service or database-backed feature needs a separate backend or managed service.
- The S3 website endpoint is HTTP-only. CloudFront is the component that gives the portfolio HTTPS and a certificate for a custom hostname.
- The bucket can remain private. OAC signs CloudFront’s requests to S3, so visitors do not need direct S3 permissions.
Decide whether S3 and CloudFront fit your portfolio
Use this pattern when you already have a static build, want control over the bucket and CDN configuration, or need a straightforward origin for files that change through a deployment process. It is also suitable for a portfolio generated by a static-site tool, provided the final output is ordinary web assets.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choose a different architecture, or add services, when the site must execute code on the server, store user accounts, process payments, query a database, accept uploads, or provide an API. You can still keep the front end in S3 and CloudFront while routing dynamic functions to another origin.
#1 Best Overall
Prepare the site and account
Have the production build ready before creating the distribution. Your output directory should contain the page that visitors receive first, normally index.html, with all referenced assets using paths that will work from the chosen domain. Test the files locally so broken relative paths are fixed before caching makes diagnosis harder.
- An AWS account with permission to create S3 buckets, CloudFront distributions, IAM bucket policies, ACM certificates and DNS records.
- A globally unique S3 bucket name. The name does not need to match your domain when you use an S3 origin and CloudFront.
- A registered domain only if you want a custom address. The DNS provider must let you create an alias or equivalent record for CloudFront.
- A build directory containing only the files intended for publication. Keep source files, credentials and environment secrets outside this directory.
Step 1: Create a private S3 bucket
- Open the S3 console and choose Create bucket.
- Enter a globally unique bucket name and select the AWS Region you want for storage and operational convenience.
- Leave all four Block Public Access settings enabled. Do not add a public-read bucket policy and do not turn these protections off to follow an older static-website tutorial.
- Keep the remaining defaults unless your organization requires a specific versioning, encryption, logging or retention policy, then create the bucket.
For the secure CloudFront design, use the bucket itself as the CloudFront S3 origin rather than selecting the S3 website endpoint. The website endpoint is intended for direct website hosting and is HTTP-only; it is not the private origin used by OAC.
Step 2: Upload the portfolio build
- In the bucket, choose Upload, add the contents of your build directory and start the upload. Upload the files inside the directory, not an extra parent folder, unless your site is intentionally served from that prefix.
- Confirm that
index.htmlis at the bucket root (or at the exact prefix you will configure as the origin path). - Check object names and capitalization. S3 keys are case-sensitive, so
Images/portrait.jpgandimages/portrait.jpgare different objects.
You do not need to grant the public a GetObject permission. CloudFront will receive the permission it needs through the bucket policy generated for its OAC.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Step 3: Create CloudFront with Origin Access Control
- Open CloudFront and choose Create distribution.
- For the origin, select the S3 bucket. If the console offers to create or attach an Origin Access Control, create one for the distribution and use signing requests to the origin.
- Allow CloudFront to update the S3 bucket policy, or add the equivalent policy yourself. The policy should permit the specific distribution to read objects from this bucket and should not grant anonymous public access.
- Set the distribution’s default root object to
index.html. This tells CloudFront what to request when someone visits the hostname without a filename. - Set the viewer protocol behavior to redirect HTTP to HTTPS (or require HTTPS if you do not need an HTTP redirect). This prevents visitors from remaining on an unencrypted URL.
- Choose a cache policy appropriate for static files. The default policy is a starting point; later you can tune cache durations or send explicit cache-control headers from your build process.
- Create the distribution and wait until its status changes from deploying to deployed. Copy the generated CloudFront domain name for testing.
CloudFront and S3 are separate services: the bucket stores the source objects, while the distribution controls the public hostname, TLS behavior and edge caching. A successful distribution does not make the bucket public.
Step 4: Add HTTPS and a custom domain
Request an ACM certificate
If the CloudFront hostname is sufficient, you can test immediately without a custom certificate. For a domain such as www.example.com, request a public certificate in AWS Certificate Manager (ACM). CloudFront certificates must be available in the AWS Region required by CloudFront, us-east-1, even when the S3 bucket is in another Region.
- In ACM, request a certificate for every hostname you will serve, such as the apex domain and its
wwwsubdomain. - Choose DNS validation when your DNS provider supports it. ACM supplies validation records; create them exactly as shown and wait for the certificate status to become issued.
- Return to the CloudFront distribution, edit the general settings and select the issued certificate under the custom SSL certificate option.
- Add the same hostnames under Alternate domain names, save the distribution and wait for the change to deploy.
A certificate only proves control of the hostname and enables TLS. DNS still has to send visitors to the distribution.
Create DNS alias records
In Route 53, create an alias record for the apex domain and another for the subdomain you plan to use. Select the CloudFront distribution as the alias target. Other DNS providers may call this an ALIAS, ANAME or CNAME-like record; follow that provider’s documented method for an apex domain. The target must be the CloudFront distribution hostname, not an S3 website endpoint.
Keep the CloudFront hostname available while DNS changes propagate. It is the fastest way to distinguish a DNS problem from an origin, certificate or cache problem.
Step 5: Verify before changing public DNS
- Open the CloudFront hostname over HTTPS and confirm that the expected landing page loads.
- Open a stylesheet, script and image directly to verify that asset paths and content types are correct.
- Inspect the browser’s developer tools for 403, 404, mixed-content or JavaScript errors.
- Test a URL with and without a trailing slash and test a deep path that your navigation uses.
- After the custom hostname is attached and DNS has propagated, repeat the same checks at the custom domain.
A 403 response immediately after distribution creation usually means the OAC permission or bucket policy is incomplete. A 404 often indicates a wrong key, a missing build file or a path mismatch rather than a CloudFront outage.
How updates and caching work
CloudFront serves an object from an edge location until that object’s configured expiration is reached. After expiry, CloudFront checks S3 and stores the newer object at the edge when one exists. Uploading a replacement to S3 therefore does not guarantee that every visitor sees it immediately.
Plan deployments around one of these approaches:
- Cache expiration: use suitable time-to-live values and wait for old objects to expire. This minimizes operational work but delays visible changes.
- Invalidation: request a CloudFront invalidation for changed paths after publishing. This is useful for urgent replacements, but it adds an operational step and may incur charges under your CloudFront usage and allowance.
- Versioned asset names: emit filenames such as
app.abc123.jsfor each build and update the HTML to reference the new names. Long-lived caching can then be used safely for immutable assets.
Keep the HTML entry point on a shorter cache lifetime than fingerprinted images, scripts and styles when you need frequent releases. The cited AWS guidance does not establish one universally correct TTL; choose values based on how often you publish and how quickly a correction must reach visitors.
Security and reliability checks
- Verify that all S3 Block Public Access settings remain enabled after CloudFront is working.
- Review the bucket policy and ensure it names the intended CloudFront distribution rather than a broad anonymous principal.
- Use HTTPS redirects and remove mixed-content references such as HTTP image or script URLs.
- Do not upload API keys, private source maps, passwords or environment files into the publication bucket.
- Consider S3 versioning if you need recovery from an accidental overwrite, and retain a copy of each production build outside the bucket.
- Use browser and CloudFront logs when troubleshooting repeated failures. A cached error can persist until its error-cache lifetime expires or is invalidated.
What this costs
AWS bills S3 according to stored data, requests and data transferred. CloudFront charges depend on requests, the edge locations used to serve them and data transferred. A custom domain adds a registration fee through your registrar; AWS’s getting-started documentation gives an illustrative annual range from about $9 to several hundred dollars depending on the top-level domain, not a current quote for every domain.
Your total depends on portfolio traffic, media size, request frequency, cache hit rate, region and deployment activity. Check current regional S3, CloudFront, ACM and DNS pricing before committing to a budget. ACM certificates for public CloudFront use do not remove the separate domain-registration and data-transfer considerations.
Direct S3 and CloudFront versus managed hosting
AWS also offers Amplify Hosting for S3-style website content. It uses CloudFront behind a managed workflow and supplies a public HTTPS URL with less infrastructure configuration. The choice is about control and workflow, not a guaranteed price or performance winner.
| Decision area | S3 plus CloudFront | Managed hosting option |
|---|---|---|
| Setup effort | More steps: bucket, OAC policy, distribution, certificate and DNS. | Fewer infrastructure settings and a guided deployment workflow. |
| Configuration control | Fine-grained control over origin, cache behavior, policies and release mechanics. | More defaults and abstractions, with less direct CDN configuration. |
| Deployment workflow | Upload files yourself or automate uploads and invalidations. | Use the managed service’s connected-repository or deployment process. |
| HTTPS and CDN | Configure CloudFront and ACM directly. | CloudFront-backed delivery is managed for you. |
| Price outcome | Varies with S3 storage, requests, transfer and CloudFront usage. | Not established as universally cheaper or more expensive; check current pricing. |
Troubleshooting by symptom
The CloudFront URL returns 403
Confirm that the origin is the S3 bucket, not the website endpoint; OAC is attached; the bucket policy permits the distribution to read objects; and the requested key exists. Keep Block Public Access enabled while correcting the policy.
Recommended Free Tools
The home page is 404 or shows an access error
Check that the default root object is exactly index.html and that the object is at the expected bucket prefix. If the distribution uses an origin path, include that prefix when checking the key.
Assets are missing but the HTML loads
Inspect the failing URL’s capitalization and leading slash. A site built for a subdirectory may generate paths that do not match a root-domain deployment. Upload the complete build output, including fonts and media, rather than only the HTML file.
The custom domain shows a certificate warning
Make sure the certificate covers the exact hostname, is issued in the CloudFront-required region, and is selected on the distribution. Confirm that DNS points to CloudFront and not directly to S3.
A new release is not visible
Check the object in S3 first, then account for CloudFront’s cache lifetime. Invalidate the changed path or publish versioned filenames when the update must appear immediately.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Production checklist
- Build output tested locally and contains the intended
index.html. - Private S3 bucket created with all Block Public Access settings enabled.
- CloudFront S3 origin configured with OAC and a least-privilege bucket policy.
- Default root object and HTTPS viewer behavior configured.
- ACM certificate issued for every custom hostname and attached to CloudFront.
- DNS alias records point the apex and subdomains to the distribution.
- CloudFront hostname and custom domain tested for pages, assets, deep links and HTTPS.
- Release process documents cache expiration, invalidation or asset versioning.
- Traffic, storage, request and transfer costs reviewed against current AWS pricing.
Once these checks pass, S3 remains the private file store and CloudFront becomes the single public entry point for the portfolio. That separation gives you HTTPS, edge caching and a custom domain without operating a conventional web server, while leaving room to add a separate backend when the site stops being purely static.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
