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.
Related
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.
I registered a domain on Route53 and I would like to use the same domain for both my front-end and the back-end (example xyz.com).
The whole infrastructure is hosted on AWS.
The font-end is an app hosted on S3 and fronted by cloudfront.
The back-end is served via API Gateway.
I created a record of type A to point the API Gateway endpoints and I now try to create a new record of type A to serve the front-end (point cloudfront) which doesn't allow me, returning the error:
A record with the specified name already exists.
What is the correct way to achieve having both the front-end and the back-end behind the same domain?
First of all, you can not create multiple A records like that.
As luk2302 said, the normal approach is use two domains. But if you want to keep the same domain for both FE and BE, you can use multiple path patterns of CloudFront to do the routing for you.
It will look like this: You have 1 CloudFront distribution, it will have 2 behaviors with 2 origins: S3 and API Gateway. The first behavior will have path pattern /api/* and it will point to API Gateway's Origin. And the default path pattern will go to S3's Origin
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'm curious whether is possible to load a web page via AWS lambda functions.
I mean, I would like to open a webpage like www.something.com/home which makes a request to the AWS lambda function which will open/get resources from www.i-would-like-to-hide-this-url.com/home, but the URL should remain www.something.com/home.
So can I use AWS as a proxy for the case above?
Yes you can do it with CloudFront using custom Origin. It will work as a reverse proxy for your customers.
A custom origin is an HTTP server, for example, a web server. The HTTP server can be an Amazon Elastic Compute Cloud (Amazon EC2) instance or an HTTP server that you manage privately. An Amazon S3 origin configured as a website endpoint is also considered a custom origin.
When you use a custom origin that is your own HTTP server, you specify the DNS name of the server, along with the HTTP and HTTPS ports and the protocol that you want CloudFront to use when fetching objects from your origin.
Using Amazon EC2 or Other Custom Origins
Or you can do it with ELB and a reverse proxy on EC2. But in this case you will be responsible for this reverse proxy.
Maybe it is even possible to do it with lambda if you code the "reverse proxy" solution, but I guess it is not exaclty recommended.
Typically you host the static assets (html/js/css/img) in S3, you front Lambda with API Gateway, and your web page makes HTTP/Rest requests to API Gateway which forwards them to your Lambda. Lambda itself does not typically serve the static assets. If you need SSL then you add CloudFront. Example here.