May sound like a strange question, but bear with me here.
I need to build a small web project. For the sake of making it free, I was going to host the front end portion on S3 as a static site, and have it invoke server side functions by making AJAX calls to a REST API hosted in a lambda function. I've done this before in a webapp for myself, but I remember it causing complications when cross origin requests were made and I ended up resorting to using JSONP. Is there any problem with this setup? I've heard JSONP can be a security concern, and this new site is intended for public use.
My alternative setup would be to build a server on lightsail that hosts the site and backend. Obviously this is probably the more correct way to do things, but is slightly more money.
Which of these methods is likely the better option?
Additional question: Is it possible to setup CORS so I don't have to use JSONP for cross origin requests? I'm a bit unfamiliar with CORS.
Which of these methods is likely the better option?
I'm going to pretend you didn't ask that, since there isn't a "correct" answer -- it's subjective, and there are many factors, some of which are opinion-based.
But both solutions are viable.
API Gateway, which is what you'd use as a front-end to expose your Lambda functions to the Internet, has CORS support, so this should not need to be a concern for you.
Another option is using S3 and Lambda (with API Gateway) but configure both resources as origins behind a CloudFront distribution. Point the default cache behavior at the bucket, then use a path pattern like /api/* to route the API requests to API Gateway. This proxies all requests to the appropriate origin, but your site's hostname in DNS is pointed to CloudFront, where all the resources are accessed, which means none of the requests will be cross-origin -- everything is accessed at a single hostname. The CDN/caching features of CloudFront are a bonus for optimal performance when fetching the the static content and can be disabled for the API.
Sounds like costs is your concern .. so keep this in mind: IF any of the server-side code of your app needs to talk to the Internet, you MUST also provision a NAT Gateway for Lambda to use to talk to the Internet. On its own, Lambda has NO OUTBOUND INTERNET ACCESS. A NAT Gateway currently costs .045 per hour, on top of data transfer AND processing charges. With Lambda you only pay for the time the function is running, but your NAT Gateway will be running all the time. On top of this, if your traffic is getting to your Lambda function through API Gateway there is that to consider .. since its a small app, I am going to assume you will never hit the limit to incur the API Gateway charges, however, if you have CloudTrail turned on, you will be getting CloudTrail logs for (1) Lambda, (2) NAT Gateway, (3) S3, and (4) API Gateway .. which may potentially set you up for possible CloudTrail charges.
Now compare this with the cheapest Lightsail instance which costs .047 per hour and already has Internet access. Granted the RAM available is really small, but if you are running a small app .. and hopefully its not written in Java, then this should not be an issue. Also, the stack is much smaller and simpler to manage.
So at a baseline difference of .002 cents per hour (comparing the NAT Gateway cost with the Lightsails costs) .. and also taking into account the simplicity of Lightsail, .. Lightsail could be a better choice.
If you are concerned about the fact that Lambda will scale automatically, keep in mind that you can programmatically trigger additional and larger Lightsail instances and essentially accomplish the same sort of scaling paradigm. Note though, that you can't simply shut down a Lightsail instance you are not using, you must delete it before the end of the month to prevent the full monthly charge.
That being said, for an EC2 instance you dont have to delete it to avoid additional charges, you can simply shut it down .. so actually, I would recommend EC2 over Lightsail because you can make things even simpler.
FYI To fix the CORS issues, you have to create a lambda that will respond to the options preflight request (and link that up with the API gateway) and then configure the lambda to return the CORS headers you want