Deploying Secure Static Sites on AWS Using S3, CloudFront, and OAC

Launching a modern static website isn’t simply about dragging and dropping files to a server anymore. With advanced cloud-native platforms like Amazon S3, you’re stepping into an environment built for resilience, scalability, and surgical-level security. Before any traffic ever hits your site, your job is to craft a digital fortress that can handle both scale and scrutiny.

Understanding the Power of Amazon S3

Amazon S3—Simple Storage Service—is a pillar of cloud-based infrastructure. It’s built to handle virtually unlimited amounts of data, with eleven 9s of durability. But its raw power isn’t what makes it shine for static sites. What truly stands out is its flexibility and the potential to align every setting, from permissions to caching, with your performance and security goals.

Creating and Configuring the S3 Bucket

Let’s begin with the setup. You’ll start by creating a new S3 bucket, or you may already have one. This bucket houses the production-ready static files for your website—HTML, JavaScript, CSS, images, fonts, and any other client-facing assets. Now, instead of enabling the traditional static website hosting feature within S3, we go a more nuanced route: keep the entire bucket private.

Disabling Static Website Hosting for Security

Why disable static website hosting? Because it automatically exposes your content to the public internet. That worked in 2012, but in 2025, that’s a huge security flaw waiting to happen. Instead, all objects in your bucket should remain private. You’ll serve them securely through CloudFront, with precise control using Origin Access Control (OAC).

Setting Access Permissions

Once the bucket is created, disable all public access settings. AWS has made this easier in recent years with a global setting that blocks all public access, including ACLs and public bucket policies. Ensure all boxes are checked. This is the first defense layer, and it’s essential.

Uploading and Organizing Website Files

Now, upload your website’s build files. Make sure your project is properly built—whether it’s a React app, a static HTML5 template, or anything in between. Upload the entire build folder, ensuring that Html file is at the root. Organize your files using a clean directory structure, separating scripts, styles, and media assets into their respective folders. A little file hygiene now pays dividends later.

Assigning Accurate Metadata

Beyond file placement, there’s the matter of metadata. Each object in your S3 bucket should have the correct content-type metadata. HTML files should be served as text/html, CSS as text/css, and JavaScript as application/javascript. Incorrect metadata can lead to all kinds of rendering and loading errors in browsers.

Configuring Cache Control for Optimization

Another critical setting involves caching. S3 allows you to define cache-control headers on a per-object basis. For example, your HTML files—likely to change frequently—should have a shorter max-age. Meanwhile, versioned JS and CSS files can be cached aggressively with long lifetimes. This caching discipline not only optimizes performance but also keeps your costs low by reducing redundant data transfers.

Enabling Object Versioning

Enable object versioning in your S3 bucket if you haven’t already. This provides a soft safety net for accidental overwrites or deletions. You can recover a previous version of an object without having to dig through backups. This is especially useful during frequent deployments where something inevitably goes sideways.

Implementing Fine-Grained IAM Policies

While the content sits in the bucket, you also need to consider who—or what—can access and manipulate it. IAM policies govern this layer of security. Create roles and permissions narrowly tailored to your use case. For instance, your CI/CD system should only have permissions to upload new content and manage object metadata, but not delete or list all bucket contents unless absolutely necessary.

Enabling Server Access Logging

Additionally, server access logging is worth enabling. By turning on logging, you get detailed records of requests made to the S3 bucket, which are stored in a separate bucket you designate. While this might feel excessive for a basic website, it’s an invaluable tool for debugging performance anomalies, analyzing access patterns, and investigating potential security incidents.

Setting Up Lifecycle Rules

You also want to implement lifecycle rules. These rules automatically transition older files to lower-cost storage classes like S3 Infrequent Access or delete them entirely after a certain period. This helps manage cost and clutter in the long run. For example, if you deploy new versions weekly, old JS/CSS bundles can be auto-deleted after 90 days.

Preparing for CloudFront Integration

Now we get into policy enforcement. Without enabling static website hosting, you’ll rely on CloudFront to deliver the content. But to prepare for that integration, you’ll need to ensure your bucket policy supports Origin Access Control. That means your S3 bucket policy must permit only specific identities or services—in this case, CloudFront via OAC—to access content.

Moving Toward Secure Architecture

That’s where this whole setup flips from “traditional” to “secure modern architecture.” You’re not just preventing people from finding your files directly. You’re building an architecture where the only permitted route to your files is through a trusted, authenticated channel.

Avoiding Common Permission Mistakes

A common misstep is leaving open IAM permissions during development and forgetting to tighten them later. Avoid this trap. Start tight, and loosen only where your workflow requires. For example, developers uploading assets can do so via the AWS CLI using IAM credentials, but those permissions should never carry over to the live web access model.

Optimizing Large File Uploads

One overlooked optimization is multipart uploads for large assets. If you’re uploading high-res videos or animations, S3’s multipart capability lets you upload in chunks and retry only the failed parts if needed. This saves time and bandwidth.

Supporting Regional Deployments

For sites that feature regional or localized content, consider using bucket prefixes or separate buckets altogether. This lets you localize performance tuning and access policies depending on geography or language, which can be a game-changer for audience-specific deployments.

A Secure and Scalable S3 Setup

This entire setup phase with Amazon S3 is more than a placeholder for your website files. It’s the scaffolding for a secure, efficient, high-availability deployment. By starting with a private bucket, disabling legacy hosting features, assigning proper metadata, defining smart caching headers, and tightening IAM permissions, you’re not only getting ready to serve users—you’re ensuring that the experience is secure, fast, and seamless.

What you’ve built so far is a future-proofed, best-practice-based foundation for serving static web content. But the story doesn’t stop here. Next, we turn to CloudFront, where this private and secure content gains global reach and performance that meets users where they are—anywhere on Earth.

Introduction to CloudFront Distribution

Once your static website content is secure within Amazon S3, the next pivotal step is leveraging CloudFront—a powerful content delivery network designed to distribute your web content with low latency and high transfer speeds. CloudFront is what puts your site on the digital autobahn. Instead of routing all traffic to a single S3 endpoint, CloudFront replicates and serves your content from edge locations worldwide.

Understanding the Mechanics of CloudFront

CloudFront works as a globally distributed system of edge servers that cache your static content closer to users. When a visitor requests your website, CloudFront responds from the edge location nearest to them geographically, minimizing latency and improving loading speed. This isn’t just a minor improvement—it can shave seconds off load times, especially for users far from your primary S3 region.

Creating a CloudFront Distribution

Begin by heading into the AWS Management Console and opening the CloudFront dashboard. Select “Create Distribution” to start configuring a new distribution. The first step is choosing your origin, which in this case will be your private S3 bucket.

In the origin settings:

• Choose the S3 bucket from the dropdown list.

• Disable legacy settings such as Origin Access Identity (OAI).

• Instead, opt for the new Origin Access Control (OAC) method to tighten security.

Setting Up Origin Access Control (OAC)

CloudFront’s Origin Access Control is a more secure and flexible evolution of the older OAI system. Rather than using a predefined CloudFront identity, OAC lets you configure specific IAM roles and permissions to securely grant CloudFront the ability to fetch private objects from your S3 bucket.

Create a new OAC setting under the “Security” section of the CloudFront console. Ensure that the “Sign requests (recommended)” option is selected. This ensures all requests made from CloudFront to your S3 bucket are signed and verified.

Linking OAC to the CloudFront Distribution

Once your OAC setting is ready, link it to the distribution you’re creating. In the Origin settings of your distribution, select the new OAC configuration. This ensures that only your CloudFront distribution will have the permissions required to access the content in your private S3 bucket.

Configuring Additional Distribution Settings

Leave most of the default settings as-is unless your project requires specific configurations. However, do take time to configure the following:

• Viewer Protocol Policy: Redirect HTTP to HTTPS for security.

• Allowed HTTP Methods: Use GET and HEAD for static sites.

• Compress Objects Automatically: Enable this to reduce bandwidth usage.

Setting the Default Root Object

Add HTML file as the Default Root Object. This tells CloudFront to automatically load an HTML file when users navigate to the root of your domain. Without this setting, users might see an error or directory listing if they access your site without a full path.

Updating the S3 Bucket Policy Manually

Unlike the legacy OAI setup, OAC requires you to manually update your S3 bucket policy. Copy the generated policy from the CloudFront distribution screen and paste it into your bucket’s permissions tab. Ensure the policy grants s3:GetObject permission to the CloudFront service principal via the OAC.

Double-check that no other principals have access, maintaining your private bucket configuration.

Deploying the Distribution

Once everything is in place, hit “Create Distribution.” CloudFront will begin provisioning the distribution across its global network of edge locations. This process typically takes a few minutes. Once completed, you’ll be given a CloudFront distribution domain.

Accessing the Website via CloudFront

Copy the domain name and paste it into your browser. If everything is configured correctly, your static website should load instantly, pulled straight from CloudFront’s edge servers. This marks a successful deployment of a lightning-fast, secure, and globally accessible static site.

Verifying Secure Access Control

Try accessing the website via the S3 bucket URL. You should encounter an Access Denied error. This confirms that your bucket is secure and that only CloudFront—via OAC—is allowed to retrieve the content. This gatekeeping mechanism is crucial for preventing direct access to your S3 objects.

Monitoring and Logging CloudFront Activity

To ensure ongoing performance and visibility, enable logging in your CloudFront distribution settings. These logs can be stored in another S3 bucket for later analysis. This lets you monitor usage patterns, identify traffic anomalies, and refine your caching strategies.

Leveraging CloudFront Functions for Custom Logic

If you need lightweight request manipulation, consider using CloudFront Functions. These allow you to write JavaScript-based logic that executes at the edge, enabling use cases like header modification, URL rewrites, or geo-based redirects—all without needing LambdaEdge or additional infrastructure.

A Global Gateway for Your Content

With CloudFront and OAC working together, your static website is not just live—it’s turbocharged. You’ve gone from isolated, private files in S3 to a globally distributed, high-performance web experience. CloudFront doesn’t just deliver your content faster—it does so with refined access control, scalability, and security that aligns with the expectations of modern web architecture.

This setup doesn’t only future-proof your website. It sets the bar for what “standard” should mean in secure, performant cloud-based deployments.

Introduction to Domain Customization

Having a secure and performant website isn’t enough—you also need it to look professional. That starts with ditching the default CloudFront domain and serving your site under a custom domain. A memorable, branded URL paired with SSL encryption dramatically boosts credibility and trust. AWS makes this relatively painless through Route 53 for DNS management and ACM (AWS Certificate Manager) for SSL.

Choosing and Registering a Domain

If you don’t already own a domain, you can register one directly via Route 53 or through any third-party registrar. Using Route 53 streamlines DNS configuration, but the integration process is flexible enough to accommodate external domains too. Choose a domain name that’s concise, clear, and brand-aligned.

Once registered, create a hosted zone in Route 53 for your domain. This hosted zone becomes the control center for routing traffic to your CloudFront distribution.

Requesting an SSL/TLS Certificate with ACM

Security is non-negotiable. Visitors expect the little padlock in their browser bar, and search engines increasingly penalize non-secure sites. AWS Certificate Manager issues free SSL/TLS certificates you can integrate directly with CloudFront.

Navigate to the ACM console and request a public certificate. Enter your domain name—use both the root domain and the wildcard subdomain to ensure full coverage. Opt for DNS validation when prompted. This is faster and more reliable than email-based verification.

Validating the SSL Certificate with DNS

Once the certificate request is created, ACM provides CNAME records you must add to your domain’s DNS configuration. Head back to Route 53, locate your domain’s hosted zone, and add the CNAME records exactly as provided.

DNS propagation can take a few minutes to an hour, depending on your TTL settings. Once ACM detects the correct records, it will issue and validate the certificate. The status will update to “Issued,” signaling that your SSL is ready to use.

Attaching the SSL Certificate to CloudFront

Go back to your CloudFront distribution settings. Under the “General” tab, click “Edit.” In the Custom SSL Certificate section, select the certificate you just issued via ACM. Make sure you also update the CNAMEs to include your custom domain.

For the price class, choose the edge locations that best match your audience. Unless you’re running a global app with wide reach, you can often get by with the default setting.

Configuring Alternate Domain Names (CNAMEs)

CloudFront supports up to 100 alternate domain names per distribution. Enter all the domains you want to point to this distribution. This typically includes the root domain and the www subdomain. After setting your alternate domain names, double-check that the SSL certificate matches all entries. Inconsistent domain coverage can result in HTTPS errors.

Updating Route 53 DNS Records

Now, create an alias record in Route 53 that points your domain to the CloudFront distribution. In your hosted zone, create two records:

• One for the root domain

• One for the www subdomain

Choose “A – IPv4 address” for the record type, then select “Alias” and point it to your CloudFront distribution. Route 53 will present a dropdown menu of available CloudFront distributions—select the correct one and save the record.

Forcing HTTPS with Redirects

To ensure all traffic is secure, configure CloudFront to redirect HTTP to HTTPS. This setting is available under the “Behaviors” tab of your distribution. Edit the default behavior and change the Viewer Protocol Policy to “Redirect HTTP to HTTPS.” This ensures that any insecure request is immediately redirected to the secure version, maintaining both security and SEO integrity.

Testing and Troubleshooting

With all components in place, test your custom domain in a browser. You should see the correct website load over HTTPS. Inspect the SSL certificate in your browser to ensure it’s valid, current, and correctly issued by ACM.

If you run into issues, verify the following:

• The ACM certificate is fully validated and covers all specified domains.

• The CloudFront distribution includes all domain names under Alternate Domain Names.

• Route 53 DNS records are correctly configured as Alias records pointing to CloudFront.

• DNS changes have fully propagated.

Adding Redirection Logic

If you want all non-www traffic redirected to www (or vice versa), this requires some extra routing logic. CloudFront doesn’t support automatic domain redirection natively, but you can configure a separate distribution with a LambdaEdge function or CloudFront Function to handle this logic.

Another simpler option is to set up a second CloudFront distribution for the redirecting domain and use the error pages feature or a static site in S3 to serve a 301 redirect response.

Supporting Multiple Subdomains or Regions

If your site supports multiple languages or markets, consider segmenting traffic by subdomain. Each subdomain can have its own behavior and cache settings. Use CloudFront behaviors and Route 53 routing policies—like geolocation or latency-based routing—to tailor the experience per audience.

This approach requires you to provision the subdomains in ACM and Route 53 just like you did with the main domain.

Monitoring and Validating SSL Health

ACM certificates are managed by AWS and will auto-renew as long as DNS validation remains intact. Set up CloudWatch alarms to alert you if there are SSL handshake failures or if the certificate status changes.

You can also use third-party tools like SSL Labs or hardened CLI tools to test the strength of your SSL implementation. Aim for an “A” grade by ensuring support for modern TLS protocols, avoiding weak ciphers, and using HSTS headers.

Enhancing Security with HSTS

HTTP Strict Transport Security (HSTS) tells browsers to always access your domain over HTTPS, preventing protocol downgrade attacks. You can implement this via CloudFront response headers.

Edit your default behavior in CloudFront, scroll to Function Associations or Response Headers Policy, and add a custom header for HSTS:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

 

This header ensures every modern browser remembers to use HTTPS only, even if a user types in HTTP.

Using Custom Error Pages

To maintain a polished user experience, configure custom error responses for scenarios like 403 (Access Denied) or 404 (Not Found). In the CloudFront console, go to the “Error Pages” tab and add entries for your chosen errors. Point them to an error file or a similar page in your S3 bucket. This avoids the generic XML error messages and keeps your user journey cohesive, even in failure cases.

Your Domain, Your Rules

With a custom domain and a fully validated SSL certificate in place, your static website now looks and behaves like a top-tier digital property. The trust signals are visible, the performance is optimized, and the underlying architecture is locked down. Users don’t care that it’s static—they care that it’s fast, secure, and memorable. This phase completes the evolution from a basic S3-hosted project to a truly branded, production-grade web experience.

Streamlining Deployment with CI/CD Pipelines

A static website might not change often, but when it does, the process of uploading build files manually to S3 becomes tedious and error-prone. To streamline and standardize deployments, integrating a CI/CD pipeline is crucial. GitHub Actions, AWS CodePipeline, or GitLab CI can automate this process.

With GitHub Actions, you can trigger a pipeline every time new code is pushed to your main branch. The action should build your static assets, then sync them to your S3 bucket using the AWS CLI. After syncing, invalidate the CloudFront cache to ensure updated files are served instantly. This simple workflow removes human error and slashes deployment time to mere minutes.

CloudFront Invalidation Strategies

By default, CloudFront caches content aggressively to enhance performance. However, when you update site files (especially HTML), you must invalidate the cache so users see the latest content. Instead of clearing the entire cache—which is slow and inefficient—you can target specific paths.

For instance, invalidate HTML files and other changed resources, while letting unchanged assets like images or fonts persist in cache. This surgical invalidation approach reduces latency and keeps bandwidth costs down.

Versioning Your Assets for Efficiency

Another smart tactic is versioning your static assets. Append a hash or version number to filenames.. This guarantees cache busting without needing invalidations. You can safely configure CloudFront to cache such resources for long periods, knowing updates will always reference a new file name.

Tools like Webpack and Vite support automatic file hashing, ensuring you never have to micromanage filenames.

Enabling GZIP and Brotli Compression

Speed is critical. CloudFront supports GZIP and Brotli compression automatically for most text-based file types—like HTML, CSS, JavaScript, and JSON. Brotli, in particular, offers superior compression ratios. Enable both in the distribution’s behavior settings.

Smaller file sizes translate directly into faster load times and better user experience, especially on mobile devices or slower networks.

Logging and Access Monitoring

Understanding who’s accessing your site, from where, and how often is vital. Enable CloudFront standard logging and send logs to a dedicated S3 bucket. These logs contain detailed request-level metadata such as IP address, URI path, user-agent, and cache result.

For deeper analysis, ingest logs into Amazon Athena or CloudWatch Logs Insights. You can set up queries to identify top referrers, analyze cache hit/miss ratios, and detect suspicious traffic spikes.

Setting Up Alarms and Dashboards

Monitoring static sites is often overlooked, but even small disruptions can lead to major issues. Use Amazon CloudWatch to set alarms on S3 errors, CloudFront 5xx responses, or unusual traffic spikes. You can also track SSL/TLS errors or latency trends. Build CloudWatch dashboards to visualize traffic volume, request patterns, and cache behavior in real-time. Pair this with AWS Budgets to keep an eye on billing anomalies.

Adding Security Headers for Best Practices

Security isn’t just about access control. HTTP response headers help prevent attacks like cross-site scripting or clickjacking. Create a Response Headers Policy in CloudFront to include:

• Content-Security-Policy

• X-Content-Type-Options

• X-Frame-Options

• Referrer-Policy

• Permissions-Policy

These headers tell browsers how to behave with your site content and add an extra layer of defense.

Leveraging CloudFront Functions and LambdaEdge

For edge-side customization, CloudFront Functions offer lightweight request/response manipulation—ideal for redirects, header rewrites, or custom authentication. They execute in milliseconds, without the overhead of full LambdaEdge functions. However, if you need to inspect or modify content, geolocation-based responses, or advanced logic, LambdaEdge gives you full access to Node.js at CloudFront’s edge locations. Use this to serve region-specific content, apply AB testing, or insert cookies.

Enabling Geo-Targeted Content

If your user base spans multiple regions or languages, geo-targeting can serve them better. CloudFront automatically attaches a CloudFront-Viewer-Country header. Your edge logic can use this to serve localized landing pages, route requests differently, or apply custom logic per region. You can also define cache behaviors based on country headers, letting CloudFront cache country-specific variants of your site.

Protecting Against DDoS and Malicious Bots

Even static sites can become targets. AWS Shield Standard protects against basic DDoS attacks automatically. For deeper control, integrate AWS WAF (Web Application Firewall).

Create WAF rules to block known malicious IPs, rate-limit excessive requests, or filter user-agents. Apply this WAF to your CloudFront distribution. You can also inspect request headers or URI paths to block specific attack vectors.

Enabling Static Site Search

Static sites often lack search functionality out-of-the-box. But integrating client-side tools like Lunr.js, Algolia, or Meilisearch can change that. You index your content during build time and serve a pre-built JSON index.

These search tools live fully on the frontend, don’t require a backend server, and work well with S3-hosted sites. They can be styled and optimized to mimic native search experiences.

Adding Analytics without Sacrificing Privacy

While Google Analytics is ubiquitous, privacy-conscious users prefer lighter alternatives. Consider tools like Plausible, Umami, or GoatCounter. These are GDPR-compliant, cookie-free, and easy to drop into your static site via a script tag. If you want AWS-native logging, configure CloudFront logs or embed Amazon Pinpoint for deeper event tracking.

Future-Proofing with Infrastructure as Code

Define your entire website stack using tools like AWS CloudFormation or Terraform. Capture S3 buckets, CloudFront distributions, OAC policies, Route 53 zones, and SSL configurations in code. This enables full reproducibility, rollback capabilities, and version tracking for infrastructure changes. Treat your site’s setup like code—because it is.

Leveraging Image Optimization

Static sites often suffer from heavy, uncompressed images. Use tools like Sharp or Squoosh during build time to resize and compress images. Then serve them in modern formats like WebP or AVIF. You can also integrate an image CDN like Cloudinary or Imgix to offload and dynamically optimize image delivery based on device type or resolution.

Conclusion

What began as a simple S3 bucket and a few HTML files has now evolved into a production-grade, high-performance, and secure digital property. By layering automation, edge logic, analytics, and monitoring, your static site is no longer “just static”—it’s resilient, adaptable, and future-ready. These enhancements ensure your site scales effortlessly, defends itself, and delivers a best-in-class experience no matter where your users are. The difference is no longer just about content—it’s about infrastructure intelligence and operational excellence.

 

• Category: other
• Tags: AWS Using S3, CloudFront, OAC, Secure, Sites, Static