we have a use-case where we have a configuration file present in AppConfig hosted configuration store and we want use cloudfront to serve that, is it possible?
I tried researching about it a little but couldn't find the possible way of integrating Cloudfront with AppConfig.
You can't connect Cloudfront and AppConfig directly. I think it will be possible if we design the structure below.
Appconfig - Lambda - API Gateway - Cloudfront
Related
I am trying to setup a website whereby both the static HTML pages and assets are served by AWS cloudfront (CDN).
I would also like to have friendly/pretty URLs for my pages and therefore need to create a AWS lambda function to redirect the friendly/pretty URLs to the correct webpage.
Is this the only solution to my problem or is there a more eloquent way to achieve this?
Lambda#Edge is a feature of Cloudfront that allows you to run serverless functions to tweak the HTTP requests or responses between Cloudfront and your Origin or visitor. here is an example
You need to create an alias record in Route53 or if you have some other DNS provider to point to your CloudFront distribution.
Lambda#Edge is not meant for this.
My requirement is to redirect url from Cloudfront. So for this I see there are possibilities to do using Lambda function as mentioned here.
My application is not hosted in S3, rather it is hosted in Apache webserver which is running on some EC2 instance.
Because redirect rules are many so I would like Lambda function to read configuration of redirect mapping from some other place but I do not know what could be the other place. I see it is possible to read either from S3 or SNS topic. Could you please suggest what is the best practice to store redirect mapping and handle redirect via Lambda?
As I understood it is not possible to do using Route53 to read mapping and then do redirect. Please correct me if I am wrong.
I am new to this and would request your expert guidance!
I think you are mistaking some concepts. If I got it right you need a CDN for an Apache server on EC2. In that case you want Cloudfront with EC2 as origin . https://aws.amazon.com/cloudfront/getting-started/EC2/
I have an AWS API Gateway API with CORS enabled and a custom domain set-up. Direct API access via the execute-api endpoints is working and I get no CORS issues in the browser. Access via the custom domain api.example.com which I also configured, is working in principle, but not in the browser, where I get CORS:
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
When setting up the custom domain, API Gateway configures its own CloudFront distribution which is somewhat internal and I do not see how to configure it or if this is even possible, it does not show up in my list of CloudFront distributions, which is expected. From the AWS docs:
The CloudFront distribution created by API Gateway is owned by a
region-specific account affiliated with API Gateway
I found these answers https://stackoverflow.com/a/52435619/4556546 and https://stackoverflow.com/a/51463965/4556546 that describe how to solve the problem with a normal CloudFront distribution. I am, however wondering:
Have I missed something in configuring the custom domain and its
associated CloudFront distribution?
In what circumstances would I choose the custom domain with its internal CloudFront distribution over running my own CloudFront distribution
that I can configure? (I already have a CloudFront distribution that I use for other parts of my app.) Are there pricing implications?
Your suggestion to remove the stage or "/dev" from my new custom domain worked like a charm.
api.example.com/dev/some_endpoint Incorrect
api.example.com/some_endpoint Correct
Hopefully this answer can help anyone else trying to add a custom domaim to AWS API Gateway.
simply removing /dev from the end of my custom domain in my amplify config nailed it! I want to hide under the sheets everytime I see that cors error, in this case I came out on top, thanks!
I am trying to implement a vue.js server(-less) side rendered webshop-a-like-site via nuxt.js on AWS Lambda backed with Cloudflare.
I prefer Cloudflare over Cloudfront because of http/3, image optimization features, safety against attacks, brotli and some more features that Cloudflare provides out-of-the-box.
Unfortunately i couldn't find any ressources if anyone did this before and what to take care of to work properly.
Right now my setup is like:
User -> Route53 -> AWS API Gateway -> AWS Lambda
-> S3 (for static files)
-> another AWS Lambda for dynamic data from Elasticsearch indexes
I am not sure where to properly integrate Cloudflare.
`I found a blogposts and threads about:
using Cloudflare Workers instead of AWS API Gateway
https://news.ycombinator.com/item?id=16747420
Creating a CNAME for Lambda provided by Cloudfront, but I am not sure if this triggers another Roundtrip to Cloudfront and additional cost? https://forums.aws.amazon.com/thread.jspa?threadID=261297
Connecting a Subdomain to API-Gateway
https://medium.com/#bobthomas295/combining-aws-serverless-with-cloudflare-sub-domains-338a1b7b2bd
Another solution could be that I build the nuxt.js directly in a Cloudflare Worker, but I am not sure of any downsides of this solution, since CPU time is very limited in Pro Plan?
`
Furthermore I've read an article about the need of securing the API-Gateway against attackers by only allowing Cloudflare IPs.
Did anyone of you already setup Vue + Nuxt with Cloudflare ? Am open to any other suggestions or ideas.
Thanks a lot!
Philipp
I am not sure where to properly integrate Cloudflare.
Assuming this is the crux of the question here, this is what it might look like using the notation you provided.
User -> Route53 -> Cloudflare -> AWS API Gateway -> AWS Lambda -> S3 -> Another lambda
The basic idea is that you'll want Cloudflare to be the first thing your DNS (Route53) resolves to so it can properly serve cached content before it ever reaches your application. Which, in this case, would start at API Gateway.
If I have a static site on AWS S3 (and maybe using CloudFront) that's pretty cool, because it scales easily, and has zero-downtime deployments, because you're just updating static assets, and gets distributed to edge locations, woohoo!
But, if I want to have a contact form, or process a stripe payment. I need to run some backend code. So, how do I tell AWS that for GETs to certain routes, use S3 (or CloudFront), but if there's a form submit, direct that to this little Lambda function over here?
Could I use Route53 and direct everything at example.com/forms/... over to Lambda?
Route53 is just DNS, it doesn't do any routing based on the path. Since you are using CloudFront I believe you can use the CloudFront Behaviors feature to perform the routing you are talking about, like what is described in this blog post. Alternatively, just use a different subdomain for the dynamic parts of your web application like api.example.com for your API Gateway routes.