Configuring CloudFront for Security: OAC and HTTPS Enforcement

Previously in this course, we learned about hosting static frontend on S3. While S3 static website hosting is convenient, it requires making your files public. In a production environment, we want the security and performance benefits of a Content Delivery Network (CDN) without exposing our raw storage buckets to the public internet.

This lesson adds a crucial layer of production security: we will transition from direct S3 hosting to serving our site through Amazon CloudFront, using Origin Access Control (OAC) to ensure that your S3 bucket remains private while remaining perfectly accessible to your users.

Understanding CloudFront Security and OAC

When you host a static site directly on S3, you must configure the bucket for public read access. This is a common point of failure where misconfigured policies can lead to accidental data exposure. By placing a CloudFront distribution in front of S3, we can change the architecture:

1. S3 Bucket: Remains strictly private (no public access).
2. CloudFront: Acts as the entry point, authenticated to read from the bucket.
3. OAC (Origin Access Control): A security feature that allows CloudFront to sign requests sent to S3, ensuring only your specific distribution can fetch your objects.

Why HTTPS Matters

While the internet is moving toward "HTTPS everywhere," CloudFront allows you to enforce this at the edge. By requiring HTTPS, you ensure that all traffic between the user's browser and your site is encrypted, preventing man-in-the-middle attacks and ensuring data integrity.

Configuring CloudFront with OAC

To secure your infrastructure, you need to update your CloudFront distribution and your S3 bucket policy. The following diagram illustrates the secure flow:

Flow diagram: User -- HTTPS → CloudFront; CF -- Signed Request → S3 Bucket

Step 1: Create an Origin Access Control (OAC)

In the CloudFront console (or via CDK), you define an OAC configuration. This generates a unique identifier for your distribution.

Step 2: Update the S3 Bucket Policy

Once the OAC is created, you must explicitly permit the CloudFront service to access your bucket. The policy looks like this:

JSON
{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AllowCloudFrontServicePrincipalReadOnly",
    "Effect": "Allow",
    "Principal": {
      "Service": "cloudfront.amazonaws.com"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::your-bucket-name/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/DISTRIBUTION_ID"
      }
    }
  }
}

By adding the Condition block referencing your DistributionId, you ensure that even if someone discovers your bucket's URL, they cannot access it directly—they must go through your CloudFront distribution.

Step 3: Enforcing HTTPS

Within your CloudFront distribution settings, navigate to the Behaviors tab. Under "Viewer Protocol Policy," select Redirect HTTP to HTTPS. This ensures that any user trying to reach your site via insecure HTTP is automatically upgraded to an encrypted connection.

Hands-on Exercise: Locking Down the Bucket

1. Navigate to your S3 bucket in the AWS Console.
2. Under Permissions, ensure "Block all public access" is enabled (we are removing public access).
3. Create a new CloudFront distribution using your S3 bucket as the origin.
4. Select "Origin access control settings" and create a new control setting.
5. After creating the distribution, copy the generated bucket policy provided by the CloudFront console.
6. Paste this policy into your S3 bucket’s permission tab.
7. Verify by attempting to access your S3 object URL directly—it should return a 403 Forbidden error. Then, access your CloudFront domain URL—it should load your site successfully.

Common Pitfalls

• Forgetting to Update the Policy: If you set up OAC but fail to apply the bucket policy, your site will return a 403 Forbidden error when accessed through CloudFront.
• Leaving Public Access Enabled: Many developers keep the S3 public access settings enabled "just in case." Always disable them once CloudFront is operational to adhere to the principle of least privilege.
• Caching Issues: If you update your S3 files, CloudFront may still serve the old version from its edge cache. You may need to perform an "Invalidation" in the CloudFront console to clear the cache.

Frequently Asked Questions

Q: Is OAC the same as the old OAI? A: No. OAC is the newer, recommended standard. It supports advanced features like SSE-KMS (Server-Side Encryption with AWS KMS) and works with all S3 regions, whereas OAI is considered legacy.

Q: Does enforcing HTTPS cost extra? A: No, enforcing HTTPS through CloudFront’s default certificate is included in the service.

Q: Can I still use the S3 website endpoint? A: You should avoid it for production apps. Use the CloudFront distribution domain instead; it provides better performance and security.

Recap

We’ve successfully shifted from a public-facing S3 bucket to a hardened architecture using CloudFront OAC. By restricting access to the S3 bucket and forcing HTTPS at the edge, you have significantly reduced the attack surface of your web application.

Up next: Custom Domains and SSL Certificates — we'll move from a generic CloudFront URL to your own branded domain.