-
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.
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 1 year, 6 months ago by
ccatchings.
- Static IPs, including BYOIP. Customers may
