Configuring CORS is probably the biggest pain about this approach and is necessary if you want to send data to and from an API. This guide should probably mention it or link another guide.
> Configuring CORS is probably the biggest pain about this approach and is necessary if you want to send data to and from an API.
CORS is only needed for the API, not the website, and only if you don't control the API or don't make it so the API can be served (from the client's perspective) from the same origin, perhaps because it's fronted by the same Cloudfront distribution.
I've found a fairly workable solution is to have an origin for the API in CloudFront and a behaviour to route /api/* to that origin. Saves any CORS headaches. Obviously this won't work in all cases.
Just remember, the route prefix you use to define the CloudFront behavior will also be added to the request sent to the origin server. So in this case, all routes defined by the API must be prefixed with `/api/`. This makes it hard to refactor existing APIs with many routes and dependencies, but works great in a greenfield scenario.
(Of course, you can rewrite the URL on the fly via Lambda@Edge but that's a PITA to maintain)
CORS is only needed for the API, not the website, and only if you don't control the API or don't make it so the API can be served (from the client's perspective) from the same origin, perhaps because it's fronted by the same Cloudfront distribution.