I'm building a single page app with an api backend. All of the static assets including html are hosted on s3 with static hosting turned on. Let's say the domain for the SPA is mydomain.com. Is there a way for me to forward all requests from mydomain.com/api/v1 to the ip address of my api backend, without setting up a dedicated proxy server?
i think it's no possible. You have to set up web server that does follow:
hosts the start page of SPA
reverse proxy requests from API to ip address you need
and put all static content under separate domain (e.g. static.mydomain.com) and associate with S3
Related
I have an AWS api that I created which is accessible through a URL. I wanted to make this API accessible only to my front end which is hosted on a static S3 bucket. Is there any way I could add the front ends IP (S3 buckets IP) to the API IP whitelist?
So far I have tried using the "Access-Control-Allow-Origin" CORS policy and set it to my website's url but this didn't seem to work and I was still able to call the API with postman.
S3 buckets don't have static IP addresses. Besides, the S3 bucket doesn't make the requests to your API. S3 just serves files up to your user's web browsers. Those web browsers render the web page and run the JavaScript code in those files. The JavaScript code making API requests to your API is running in each of your user's web browsers. The IP address that the API request is coming from is the IP of each of your users' laptop or desktop PC.
So no, your idea of white-listing the S3 bucket's IP address will not work.
I am trying to deploy my angular app and nodejs server on aws. To deploy the angular app, I am using s3 bucket and enable static website hosting.
To deploy nodejs, I am using ec2. I have chosen to keep both the server and angular frontend separate.
I wanted to know how this will be available to the outside world. I have purchased a domain name say www.example.com. I am attaching with an s3 bucket, so upon launching www.example.com, I get to see my angular app. But I also want to use the same domain for my nodejs server as my angular app is making API calls to the nodejs server. Do I need to purchase a different domain for my backend server?
In my local development, I was simply running my frontend on localhost:4200 and nodje on localhost:3000. But I am not sure how it would work on the cloud.
There are multiple solutions to this problem.
You could have www.example.com point to your S3 bucket and api.example.com point to your backend.
Another solution would be to use CloudFront and configure it with multiple origins: one for your frontend (S3) and one for your backend (custom origin, API gateway or Application Load Balancer). You would then have a specific behavior like /api/* serve your backend. This solution has the advantage of having a CDN in front of both your frontend and backend and avoiding CORS request in the frontend (+ many more features offered by CloudFront).
I've made the following diagram showing the pieces which this request will flow through:
As #jogold has said, the key is CloudFront, which will behave redirecting to FrontEnd or BackEnd (Same distribution, multiple origins, multiple behaviors)
Remember to create a new origin ("Origins and Origin Groups" tab), but also a new behavior ("Behaviors" tab): Use the expected "Path Param" (Your app also should have this as a BasePath) and pay attention to "Precedence" (Default must always be the last).
In my case, "PathParam" value for BackEnd was "/api/*"
We have all of our domains and setup on Amazon AWS. We have created a not so complex kinda static website which is hosted on a Linux machine at a hosting company. Now we have to redirect the domain e.g. example.com and www.example.com to that url which is like temp.example.hostingcompany.com.
How can I redirect example.com and www.example.com to that url so that the user sees our url and the contents on that url are displayed.
Note: I want to make it work for both http and https. We are using Amazon https certificates.
I know we can host static websites using S3 Buckets on Amazon but its already been hosted somewhere else and I can't change that decision now.
Thanks.
If you want to migrate the website to the new domain, than its simply setup the codebase on new server and make appropriate domain changes it will work.
Secondly, If you want to just show the website on the new domain, but internally its still being available on old domain, than you can use any reverse proxy server like nginx, and use the old domain as the backend and your new domain as its front end.
I have s3 serving my React App. Whats the best way to redirect any requests that have /api in the url to my webserver. Currently my CORS config in S3 redirects GET only and I know this is not the correct way to handle api endpoints.
somedomain.com -> serve static s3 react app
somedomain.com/api -> send requests to webapp (hosted at api.somedomain.com)
My other option is to just let nginx handle serving the app and api.
Use Cloud Front and Change the incoming patterns to different origin.
A static website hosted on Bitbucket will only allow (and redirect) GET requests.
I'd recommend you set the api.somedomain.com as your api endpoint in your JS. This would avoid the need for the /api route.
My mobile app consists of a dynamic portion on heroku (foo.herokuapp.com) which serves up our API and web views for some content we expose to users who don't have the app installed. There is also of course a static landing page (http://foo.co) which is hosted on S3.
Currently, I have DNS setup to resolve foo.co to our S3 instance. And S3 has routing rules to redirect our dynamic content (http://foo.co/some_dynamic_data/1234/) to our heroku servers.
Given it's a 3XX redirect, this results in a pretty ugly experience for the user since their browser bar is now going to reflect our heroku backend.
Question:
Is there an easy proxy service I can deploy that has special routing rules to route dynamic content to heroku and static content to S3 so that I can point foo.co DNS to the proxy and not have to expose the backend to users via redirects?
CloudFront.
And don't say, "but I thought that was a CDN." That's how it's marketed, but it's also a reverse proxying HTTP request router that can choose the backend based on the request path. The caching capability can be used, or it can be disabled if you don't need/want/understand it.
Create a distribution with two origins (that's what CloudFront calls your backend servers) -- one for the bucket and one for the API endpoint.
Configure your example.com hostname as an alternative hostname in the distribution settings.
Create path behaviors to choose which path patterns route to which origin. If there's an obvious choice for one of them to be the default, catching every path that's otherwise unconfigured, point the default behavior to that particular origin.
Point the DNS hostname to the CloudFront distribution.
Optional: have some SSL on your site with a free certificate from Amazon Certificate Manager, which is integrated with CloudFront.