I wonder how to manage the routes of my architecture. To summarize, my architecture is composed of :
S3 static website exposed under CloudFront CDN
Elastic Beanstalk API (based on Docker container with Django Rest and Python)
I usually insert a new record to my hosted zone in my route 53 but my goal here is to have the equivalent of Nginx locations with proxy_pass. For example, I would have :
<my_dns_record>/api that target my Beanstalk API
<my_dns_record> that target my static website on my CloudFront
I thought about an API Gateway but I wonder if it's really the best way to structure the routing.
Does anyone have an idea how to achieve the desired behavior ?
Thank you in advance for your help.
If I understand correctly, you want to have multiple apps (your S3 static site, and your Elastic Beanstalk app) served under a single domain. Route53 doesn't have any special features to handle this, since it is just a DNS service, and what you are talking about is an HTTP path routing thing.
You also shouldn't use API Gateway for this, as you would be placing your entire website behind an API Gateway when it is really only appropriate to have your API behind an API Gateway.
I would just add the Elastic Beanstalk API under CloudFront as well, as a second origin, and configure CloudFront to send requests at the /api path to the Elastic Beanstalk origin.
Alternatively, forget about having everything under the same domain, and use a subdomain api.yourdomain.com for your API. Using subdomains for your different services instead of path routing is a lot more flexible.
Related
Can possible Path-Based routing with Route53.
I have two service 1. react application on s3 CloudFront and 2. Nodejs service API on lambda.
I want it as xyz.abc.com/ which serve react application and xyz.abc.com/share which can serve nodejs API
Its not possible with Route53 as it is a DNS web service, which means it does not take into account any url paths. You must do this through your application, for example using CloudFront where you can define origin path.
My current website (single page app with CORS + API) is deployed on AWS EC2 instance and is served via ALB (mostly for easier setup of HTTPS as I only have one region covered now). The web server is configured to serve the single page application but that's all it is doing regarding frontend. I want to move the single page application to S3 instead and so completely separate the backend from the frontend. The question is, what would be the most efficient way to do it with regards to AWS setup? I can come up with the following:
point the domain at the S3 instance to serve frontend files, point API calls to ALB public DNS address
keep the domain pointed at the ELB as it is, route port 80 & 443 to S3, change API port and route that port to EC2
...
Any help appreciated.
If you're trying to completely separate the infrastructure for frontend and backend but keep the same domain you could make use of CloudFront.
In CloudFront you would create 2 origins within your distribution:
The default origin would be the S3 static website.
Then an additional origin which would point to the original ALB.
You would configure the behaviours of this CloudFront distribution so that when a path matches a specific pattern i.e. api/* it would forward traffic to the ELB. If it does not match this it would default to your S3 bucket.
Take a look at the Can I use a single CloudFront web distribution to serve content from multiple origins using multiple behaviors? article which covers a similar behaviour to what I have outlined.
I'm not very familiar with deployment and networking as I'm primarily a frontend developer. I want to create a project with Laravel and React (separated, not integrated with blade), and deploy them to AWS. I want to use Laravel only as an API server, and I'm planning to deploy it on EC2. If I host my React app on S3, how will it be possible for me to share the same domain with the API sever running on the EC2 instance?
I know that I can have separate subdomains,like www.example.com for my React app and api.example.com for my API server. However, if I want to have www.example.com for my React app and www.example.com/api for my API server, what options do I have? And what resources can you recommend for me to get more up to speed on this topic? Thanks!
As you want to use S3 and EC2 you would need to use a service that can distribute to both endpoints based on a condition.
The best service for this would be CloudFront, which supports distribution to S3 and EC2 (as a custom origin).
To do this you would create your distribution with an origin for the S3 bucket, and an origin for the API. As your API is hosted on the /api/* path you would add this as the path pattern when adding the secondary origin via a behaviour.
CloudFront will then route any requests to /api/* paths to your EC2 origin.
I have found an article named How to route to multiple origins with CloudFront which I hope will explain the steps to accomplish this in greater detail.
I have a website which I serve using express running in an EC2 instance. But this EC2 serves only the static content (html, js, css) and the dynamic part comes from API Gateway. Right now, these two have different IPs (and domains) which means that I have to deal with CORS problems accessing API Gateway from the web pages. If I could somehow serve the static content and dynamic one through the same address, that would be much better.
The way I see it, this can be done in two ways. I can serve both of them on the same host but different ports which I'm not sure if it's going to solve the same CORS problem or not. But another way which I'm sure it will not face the CORS problem is serving API Gateway under some specific sub-folder. Like http://example.com/api while the static content is served from any url except that.
Does anyone know how can I do this? Is CloudFront what I need? Or Elastic Load Balancer?
Yes, CloudFront is what you need for this scenario.
Application Load Balancer can also do path-based routing, but it doesn't support API Gateway as a target.
By default, CloudFront can route requests under a single domain to the correct choice from up to 25 destinations, using up to 25 path (matching) patterns (both of these limits can be increased by request, but it sounds like for now, you only need 2 of each, /api/* to the API, and the default * route to EC2). You can also leverage this setup to put some static content in an S3 bucket and take some load off of the servers in EC2.
For this configuration, you will want to configure your API Gateway deployment with a regional endpoint, not an edge optimized endpoint. This is because edge optimized endpoints already use part of the CloudFront infrastructure (a part to which you have no ability to configure), so using an edge-optimized endpoint behind your own CloudFront distribution sends each request and response through the CloudFront network twice, increasing latency.
I have a WordPress blog that serves niche content on domain.com
On a different endpoint, domain.com/api/ I have a completely different Node.JS API that doesn't regard the WordPress but I want to serve it from the same domain.
It is worth mentioning that we proiritize performance and speed above all.
My thought was the following :
Set up 2 EC2 Instances, one for the WordPress and one for the API (Maybe make the API a Lambda instance ?).
Set up an Application Load Balancer that will know how to route requests with a rule depending on the URL.
Is it the right way to go ? Should I just use nginx as a reverse proxy and serve the Node.JS API on a local port ?
I also want to use Elastic Beanstalk to save myself the headache of configuring the Load Balancer and the Auto Scaling group.
P.S If anyone has any advice or good habits on how to build those (With S3 Bucket perhaps, over CloudFront, etc etc) it will be more than welcome.
Thanks !