Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 12 discussion

Answer is A Explanation - AWS Global Accelerator vs CloudFront • They both use the AWS global network and its edge locations around the world • Both services integrate with AWS Shield for DDoS protection. • CloudFront • Improves performance for both cacheable content (such as images and videos) • Dynamic content (such as API acceleration and dynamic site delivery) • Content is served at the edge • Global Accelerator • Improves performance for a wide range of applications over TCP or UDP • Proxying packets at the edge to applications running in one or more AWS Regions. • Good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP • Good for HTTP use cases that require static IP addresses • Good for HTTP use cases that required deterministic, fast regional failover

Q: How is AWS Global Accelerator different from Amazon CloudFront? A: AWS Global Accelerator and Amazon CloudFront are separate services that use the AWS global network and its edge locations around the world. CloudFront improves performance for both cacheable content (such as images and videos) and dynamic content (such as API acceleration and dynamic site delivery). Global Accelerator improves performance for a wide range of applications over TCP or UDP by proxying packets at the edge to applications running in one or more AWS Regions. Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses or deterministic, fast regional failover. Both services integrate with AWS Shield for DDoS protection.

Option C is wrong , because: This option introduces additional complexity and cost by using AWS Global Accelerator. CloudFront alone can handle the distribution of both static and dynamic content effectively.

AWS Global Accelerator:Dynamic content CloudFront:static content

Keywords: - The web application has static data and dynamic data. Static data in an Amazon S3 bucket. - Improve performance and reduce latency for the static data and dynamic data. - The company is using its own domain name registered with Amazon Route 53. A: Correct - CloudFront has the Edge location and the cache for dynamic and static B: Incorrect - AWS Global Accelerator don't have cache function, so static file need to be load directly from S3 every time. - Beside that we configure CloudFront -> ALB, Accelerator -> S3, Route 53 -> CloudFront. It means that all the traffic go to CloudFront only, Acclerator don't have any traffic. C: Incorrect - Global Accelerator can configure CloudFront as the endpoint. D: Incorrect - We already have domain name. Why will we use new domain name? Will we change to new domain name? How everyone know you new domain name?

A. Create an Amazon CloudFront distribution that has the S3 bucket and the ALB as origins. Configure Route 53 to route traffic to the CloudFront distribution. Here's the reasoning: CloudFront with Multiple Origins: CloudFront allows you to set up multiple origins for your distribution, so you can use both the ALB (for dynamic content) and the S3 bucket (for static content) as origins. This means that both your dynamic and static content can be served through CloudFront, which will cache content at edge locations to reduce latency. Route 53 Integration with CloudFront: Amazon Route 53 can be easily configured to route traffic for your domain to a CloudFront distribution. Users will access your domain, and Route 53 will direct them to the nearest CloudFront edge location.

A is correct, other answers have wrong origin or endpoint types. Cloudfront supports multiple origins on the same distribution (ALB and S3) in our case. B incorrect - Global Accelerator Standard accelerator doesn;t support s3 endpoints c incorrect - Global Accelerator Standard accelerator doesn't support CloudFront distribution as endpoint D incorrect - Global Accelerator Standard accelerator doesn't support s3 endpoints

I'm wavering between A and C. With dynamic content, CloudFront is cacheable and that's not good. But with answer C, AWS Global doesn't support Cloudfront endpoint "Endpoints for standard accelerators in AWS Global Accelerator can be Network Load Balancers, Application Load Balancers, Amazon EC2 instances, or Elastic IP addresses. " So I choose A

Ans C - for the good reasons given by Diddy99. Altho' Ans A could do it, it is not the best optimised answer; Ans C is, but at cost of a custom domain name (which I don't like)

Cloudfront caches content at edge locations, reduces latency, and can serve static content from S3 buckets. It can also accelerate dynamic content from EC2. CloudFront maintains a persistent pool of connections to the origin, which minimises the overhead of establishing new connections. Any of these questions with "latency" and "improve performance" smell like CloudFront.

A - CloudFront for caching static content. No need for Global Accelerator since no static IP is required

A

A, adding to the excellent explanation by Kartikey140, the solution under C uses a custom DNS name, the question specifies: "The company is using its own domain name registered with Amazon Route 53"

Answer is C Explanation: A: Using Cloudfront to cache static content is perfect for low latency and performance. However, caching dynamic content from ALB through cloudfront might not be efficient as dynamic contents is often personalized and are not good for caching. B: Using cloudfront to cache dynamic contents from ALB is not the most efficient approach C: Using amazon cloudfront to cache the static data from S3 ensures efficient distribution of static contents globally. AWS Global accelerator routes traffic to the nearest AWS EDGE location. Hence, routing is optimized to both the ALB (Dynamic contents) and Cloud front distribution.

A for sure

By using CloudFront with separate origins for static and dynamic content, the company can achieve improved performance and reduced latency for both types of data. Route 53 then intelligently routes traffic based on the requested object, ensuring a smooth user experience.

It would have made sense to use S3 bucket as the origin for cloud front and ALB as the end point for global accelerator. However the option C messes it up when it mentions also the cloud front distribution as the end point for global accelerator standard (which is not supported). As this is not possible the only option left is A to use Cloud front for both S3 & ALB.