What are possible causes for this problem?
(Choose two.)
CloudFront does not have the ALB configured as the origin access identity.
The DNS is still pointing to the ALB instead of the CloudFront distribution.
The ALB security group is not permitting inbound traffic from CloudFront.
The default, minimum, and maximum Time to Live (TTL) are set to 0 seconds on the CloudFront distribution.
The target groups associated with the ALB are configured for sticky sessions.
Explanations:
CloudFront does not require an origin access identity (OAI) when configured with an ALB. OAIs are primarily used for Amazon S3 origins to restrict access to the S3 bucket.
If the DNS is still pointing to the ALB instead of the CloudFront distribution, then user requests will go directly to the ALB, bypassing CloudFront entirely, which would prevent CloudFront from caching responses and reducing load on the web servers.
While it is important to configure the security group correctly, the default behavior of the ALB allows traffic from any source. Therefore, unless specific inbound rules were set to block CloudFront’s IP ranges, it would not be a likely cause of the issue.
If the TTL settings for the CloudFront distribution are set to 0 seconds, it effectively means that CloudFront would not cache any content. Thus, every request would be forwarded to the ALB without caching, resulting in no reduction of load on the web servers.
Sticky sessions (also known as session affinity) cause requests from the same client to be sent to the same target in the target group. However, this would not prevent CloudFront from caching responses unless the caching behavior is configured to do so. Sticky sessions can affect load distribution but do not inherently prevent CloudFront from functioning correctly.
I reckon the answer is:
The DNS is still pointing to the ALB instead of the CloudFront distribution.
My best guess is:
The DNS is still pointing to the ALB instead of the CloudFront distribution.