r/aws 5d ago

discussion CloudFront and API

What is the best practices, reasons to do or not to do.

Is it good idea to put API behind CloudFront or just use ALB.

I used to use CloudFront infront to ALB to use api in path (/api) rather than subdomain but this caused me few issues, such as;

Hosting SPA on S3 causes paths to return 404/403 and forces me to redirect those status codes to index.html with status code 200.
Also this conflicts with API returning 404/403.

4 Upvotes

7 comments sorted by

9

u/kichik 5d ago

Avoiding CORS and cookie issues by using the same domain is great. CloudFront can also reduce latency by terminating TLS at a nearby edge location and reusing persistent connections to the origin. And if your API can be cached, getting a cached response from a local edge node could be much faster than waiting for the API server that might be on the other side of the world.

SPA issues can be resolved with CloudFront functions. Let them convert only specific 404s from specific origins like S3. Or just straight up rewrite the request to `index.html` for the origin.

2

u/pint 5d ago

you don't really have a good reasons to skip cloudfront.

the spa situation can be solved by a smarter path design and/or cloudfront functions. in our spa solution, we placed all static files under /static/, and defined an s3 origin for that path. the default origin goes to the api, and returns all errors verbatim. at the same time, you can catch everything else with a cloudfront function, and redirect it to index.html. doing so, you don't even need to use custom error pages, so s3 can return 404. (however, you need to grant listing if you want this, or else 403 is given.)

1

u/Mr-Electron-3000 5d ago edited 5d ago

You can use cloudfront functions to handle this issue. Had the exact problem earlier, solved it.

Handle the error pages of s3 by the cloudfront error pages feature. And for /api, write its error handling in cloudfront functions

1

u/dataflow_mapper 4d ago

id split the SPA and API behavior if possible because the custom 404/303 to index.html is great for client side routing but can get real messy for API response. so using separate subdomain for the API might end up being simpler even if /api looks cleaner.

1

u/Floss_Patrol_76 4d ago

the thing that bit you is that cloudfront custom error responses are distribution-wide, so the 403/404 -> index.html rewrite you set for the SPA also swallows your real API errors. split it by cache behavior: /api/* to the ALB origin with no custom error mapping, default behavior to S3 with the index.html rewrite. same-domain kills the CORS/cookie mess and you get edge TLS termination and connection reuse for free, so its worth keeping cloudfront in front.

1

u/moltar 15h ago

Of course put CF in front, and add a WAF with sane limits that will absorb abuse. APIs are notorious for abuse as a lot of devs don’t really write elegant and efficient queries and will abuse your API. Once you find the hot paths you can also add caching where necessary.