Bonus exam another incorrect answer

[dotcloud]

A company hosts a web application service in the AWS eu-west-1 region. The application serves high-resolution weather maps to users. The maps are updated frequently which are stored in an Amazon S3 bucket along with the static web contents. The web application is behind an Amazon CloudFront distribution. The company has expanded and now provides the same service to North American users. The new users report that their viewing experience with the weather maps is inconsistent and slow at times.

Which of the following steps can be implemented to provide consistent performance to the users in a cost-effective way? (Select TWO.)

• Create a Lambda@Edge that modifies requests from North American users to use the us-east-1 Amazon S3 bucket endpoint as the new origin.

• Create a Lambda@Edge function that modifies requests from North American users to use the S3 Transfer Acceleration endpoint for the us-east-1 region.

• Create a new AWS Global Accelerator endpoint for the us-east-1 bucket and add it as an origin for the CloudFront distribution. Use Lambda@Edge to modify North American requests to use this new origin.

• Configure Amazon S3 cross-region replication from the eu-west-1 bucket to a new bucket in the us-east-1 region.

• Create a new AWS Global Accelerator endpoint for the eu-west-1 S3 bucket. Configure additional endpoint groups in the us-east-1 S3 bucket for TCP ports 80 and 443.

Correct answers were marked C and D. However, there’s no benefit to adding a Global Accelerator behind a Cloudfront distribution. The request to S3 will already be routed over AWS backbone without the Global Accelerator. Therefore the correct answers are actually A and D.

[ccatchings]

EDIT: Actually, I see what the correct answers are getting at now. Focus on the statement “the maps are updated frequently”. That means CloudFront is going to have to make a lot of calls to the S3 origin to retrieve updated map data. CloudFront can deliver help with performance by delivering cached data from its Edge locations. However, by default, it may still use a sub-optimal route to retrieve updated data from the S3 origin. This is where Global Accelerator comes into play. Global Accelerator can allow CloudFront to use the AWS backbone to retrieve updated origin data via the most optimal network route. This will help provide consistent performance end-to-end (S3 Origin -> CloudFront distribution/Edge location -> client).

Having said that, I still would not consider it “cost-effective” as Global Accelerator is an expensive service, especially for data that is frequently updated. Using Lambda@Edge to route requests from N. America to the us-east-1 Bucket should be enough to provide consistent (in terms of performance being consistent with that in Europe) access to N. American users if we are emphasizing “cost-effective”.

This question was posted here fairly recently and I agree that Global Accelerator is unnecessary (and actually an incorrect answer if we are looking for a “cost-effective” solution since Global Accelerator is expensive and an unnecessary add-on cost). The AWS blog linked below does a good job distinguishing use-cases for CloudFront vs Global Accelerator.

https://aws.amazon.com/blogs/networking-and-content-delivery/well-architecting-online-applications-with-cloudfront-and-aws-global-accelerator/

Considerations for web applications

Customers use Amazon CloudFront for most HTTP(S) based Web applications. AWS Global Accelerator should be considered by customers for HTTP(S) workloads in the following common scenarios:

• Static IPs, including BYOIP. Customers may
  want to expose their APIs through a limited number of static IPs to
  their partners or to their devices with hard coded IPs.
• Turn key Global Traffic Management.
  Customers looking for an off-the-shelf solution to implement a
  multi-Region architecture for their APIs can use Global Accelerator
  instead of building this solution using CloudFront based on AWS Route 53
  or Lambda@Edge.
• Accelerating tens of thousands of domain names. CloudFront and Certificate Manager
  have quotas on the number of domains that can be configured (excluding
  wild card setup such as *.example.com). In this scenario, as a SaaS
  providing tens of thousands of APIs using custom domain names, customers
  can use Global Accelerator with an AWS EC2 fleet behind NLB to handle
  the very large number of TLS certificates.

None of the 3 bullet points above are outlined in this question and the company is already using CloudFront so bullet point 2 is completely irrelevant.

• This reply was modified 4 months, 3 weeks ago by  ccatchings.

[fancypants]

Also, there’s no way to “Create a new Global Accelerator endpoint for the us-east-1 bucket”, you need to create a Multi-Region Access Point for the bucket and use that. As per the GA FAQ:

Q: Can I use AWS Global Accelerator for object storage with Amazon S3?

A: You can use Amazon S3 Multi-Region Access Points to get the benefits of Global Accelerator for object storage. S3 Multi-Region Access Points use Global Accelerator transparently to provide a single global endpoint to access a data set that spans multiple S3 buckets in different AWS Regions. This allows you to build multi-region applications with the same simple architecture used in a single region, and then to run those applications anywhere in the world. Application requests made to an S3 Multi-Region Access Point’s global endpoint automatically route over the AWS global network to the S3 bucket with the lowest network latency. This allows applications to automatically avoid congested network segments on the public internet, improving application performance and reliability.

So, clearly this question is wrong.

[Carlo-TutorialsDojo]

Hello fancypants and dotcloud,

Thank you for your feedback.

We apologize for the inaccurate information that is present in this particular item. First off, Global Accelerator runs on the same internal AWS network that CloudFront uses to deliver content, so it also has a presence globally. Hence, it doesn’t make much sense to put GA behind a CloudFront distribution in hopes of further ‘optimizing’ requests. Second, they’re designed to optimize different aspects of the network path. Layering them isn’t really necessary and could add unnecessary complexity and cost.

We’ll work on improving this item.

Regards,

Carlo @ Tutorials Dojo