When I first deployed my portfolio as a static website, my focus was simple: getting it online. Like many beginners, I assumed security was something to think about later, perhaps at the server level or once traffic started to grow. As I learned more about how web traffic actually flows, I realized something important: the safest, cheapest, and smartest place to stop bad traffic is at the edge, before it ever reaches the origin.
In this project, I secured my static portfolio entirely at the edge using Amazon CloudFront, long before any request touched my Amazon S3 bucket.
At the time, I already had a working static website hosted in an S3 bucket. The site consisted only of static assets: HTML, CSS, JavaScript, and images. To improve performance and global availability, I placed the site behind a CloudFront distribution and configured the S3 bucket as the origin. While this setup distributed my content globally, it did not yet provide any protection at the edge. My objective was to ensure that traffic was encrypted, unnecessary or malicious requests were blocked early, security headers were applied automatically, and the S3 origin remained protected from direct or excessive access.
In CloudFront, edge security happens before caching and before requests are forwarded to the origin. This is achieved using CloudFront Functions, which run lightweight JavaScript code at CloudFront edge locations. I chose to run my function at the Viewer Request event, which is the earliest point in the request lifecycle. At this stage, CloudFront can inspect incoming requests immediately and decide whether they should be allowed or blocked.
Blocking requests at this point is especially important because it prevents unnecessary traffic from reaching the S3 bucket, improves overall performance, lowers cost by reducing origin requests, and reduces the attack surface. For beginners, CloudFront Functions are easy to explore because the AWS Console includes a built-in editor with sample code, and AWS documentation clearly explains how to create and test functions safely.
The first protection I added was enforcing HTTPS. Within the CloudFront distribution settings, I edited the default cache behavior and set the viewer protocol policy to redirect HTTP requests to HTTPS. With this configuration in place, any user attempting to access the site over an unencrypted connection is automatically redirected to HTTPS. This enforcement happens entirely at the edge and requires no changes to the website code itself.
After that, I created a CloudFront Function to block suspicious requests. Using the AWS Console, I navigated to CloudFront Functions and created a new function. The purpose of the function was straightforward: block requests targeting common WordPress administrative paths such as /wp-login.php and /wp-admin. Since my site is not a WordPress site, any request for these paths is unnecessary and potentially malicious.
The function inspects the request URI and immediately returns a 403 Forbidden response when a match is found. If the request does not match a blocked path, it is allowed to continue normally. Once the function code was saved, I published it, which is required for the function to run at CloudFront edge locations. I then associated the function with the Viewer Request event by editing the default behavior of the CloudFront distribution. After saving the changes, I waited a few minutes for the distribution to deploy globally.
To confirm that the protection worked as expected, I tested both normal and suspicious requests. The website loaded normally during regular access. However, when I manually navigated to a blocked path such as /wp-login.php, CloudFront immediately returned a 403 response, confirming that the request was stopped at the edge.
To further strengthen the security of the site, I attached a Response Headers Policy to the CloudFront behavior. This allowed CloudFront to automatically add important security headers to every response sent to the browser. These headers enforce HTTPS usage, help prevent clickjacking, and stop browsers from interpreting content as a different MIME type than intended. Because the headers are injected at the edge, no changes to the site files were required.
With this setup in place, security decisions are made as early as possible in the request lifecycle. By enforcing HTTPS, blocking suspicious paths, and adding security headers at the edge, the S3 origin remains protected while the website benefits from improved performance and reduced risk. Most importantly, this approach does not rely on servers, backend code, or complex infrastructure. Everything is handled by CloudFront at the edge.
If you already have a static website hosted on S3 and distributed through CloudFront, adding edge protection is a practical and achievable next step. CloudFront Functions provide a lightweight and effective way to inspect and block traffic early, without introducing operational complexity. By securing your website at the edge, you protect your origin, improve performance, and build a more resilient web presence.
Top comments (1)
Clean example.
What you’re really doing here is moving the decision boundary as early as possible in the request lifecycle.
Edge security isn’t about blocking more — it’s about deciding sooner, with minimal context, when nothing else should happen.
That same principle is what most AI systems still miss: knowing when the correct output is to stop, not to process further.