How to create a security group that allows only traffic coming from CloudFront?

Why the question “How can I allow only CloudFront traffic in a security group?” keeps coming up on AWS, what it reveals about the limits of the network model, and how to answer it properly in production.

How to create a security group that allows only traffic coming from CloudFront?  

Why this question keeps coming back  

In the AWS world, some questions come up again and again.
Not because they are poorly phrased, but because they point to a real friction between security, networking, and application architecture.

At first glance, the question seems simple—almost trivial.
In reality, it reveals an excellent architectural intuition… and a structural limitation of the AWS network model.

I. Where does this question come from?  

This question almost always appears in the same concrete scenarios:

• An application is exposed through AWS CloudFront
• The origin is an Application Load Balancer (ALB), an EC2 instance, an ECS service, or sometimes an internal API
• There is a strong requirement to avoid any direct access to the origin from the Internet

The underlying reasoning is perfectly sound:

“If all traffic goes through CloudFront, then my backend should only accept traffic from CloudFront.”

The instinctive answer therefore makes sense:

“I’ll just restrict my security group to CloudFront only.”

That is precisely where the problem starts.

II. The fundamental misunderstanding: CloudFront is not an IP  

An AWS Security Group works with:

• IP ranges (CIDR blocks)
• or references to other security groups

But CloudFront:

• does not have a fixed IP address
• uses hundreds of IP ranges
• distributed globally
• and changes over time

It is therefore impossible to express in a security group:

“Allow only CloudFront”

Without:

• opening a massive number of CIDR ranges
• maintaining a constantly changing and fragile allowlist
• or creating a false sense of security

III. Why opening 0.0.0.0/0 is a false solution  

In many projects, you eventually come across a rule like this:

Inbound: 443 from 0.0.0.0/0

Often justified with reasoning such as:

“Anyway, only clients go through CloudFront.”

In practice, however, this means:

• direct access to the ALB is possible
• the CDN can be completely bypassed
• cache mechanisms can be avoided
• the backend is directly exposed to attacks
• backend calls bypass CloudFront, leading to unnecessary costs

CloudFront becomes optional, which cancels out a large part of its value.

IV. What this question reveals  

This question is interesting because it highlights several realities that are often underestimated:

• network-level filtering is not always sufficient
• security cannot rely solely on IP addresses
• sometimes you must change the layer at which control is applied

In other words:

• the real problem is not “how do I write the security group rule?”
• the real problem is “how do I prove that a request actually comes from CloudFront?”

Once the problem is reframed this way, the solutions become clear.

V. Solutions that actually hold up in production  

1. Application-level validation using a secret header  

(the most common pattern)

CloudFront allows you to add a custom header to requests sent to the origin, for example:

X-Origin-Secret: s3cr3t-value

On the Application Load Balancer or application side:

• any request without this header is rejected
• the backend becomes inaccessible without CloudFront

Advantages:

• ✔ simple to implement
• ✔ very effective
• ✔ compatible with ALB, ECS, and EC2

2. AWS WAF as the “guardian” of the origin  

With AWS WAF:

• attached to CloudFront or directly to the ALB
• strict rules on headers, methods, and behaviors
• protection against bots, scans, automated attacks, and DDoS

Advantages:

• centralized security
• declarative and auditable rules
• native observability

This is often the preferred solution in enterprise or compliance-driven environments.

3. Special case: S3 with OAI / OAC  

When the origin is an Amazon S3 bucket:

• OAI / OAC allow access exclusively via CloudFront
• no IPs to manage
• no network rules to maintain
• security fully handled by AWS

This is the gold standard for static websites.

VI. Why this question is a good signal  

Honestly, this question is rarely asked by accident.

It usually indicates that the person asking it:

• thinks in terms of attack surface
• anticipates bypass scenarios
• understands security and cost implications
• is looking for a robust, not just functional, architecture

Conclusion  

The question:

“How can I create a security group that allows only traffic coming from CloudFront?”

is interesting because it:

• starts from an excellent intuition
• exposes a structural limitation of AWS
• forces a change in the level of reasoning
• leads to better architectures

The correct answer is not:

“Here is the right CIDR.”

The correct answer is:

“The control must be implemented somewhere other than the security group.”

And that is exactly what makes the difference between
an infrastructure that merely works
and one that stands the test of time.

🔗 Useful resources  

• CloudFront – Restricting access to the origin
  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RestrictingAccessToOrigins.html

• AWS WAF – Concepts and use cases
  https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html