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/*"
Related
I'm fairly noob and new to AWS, but I've been stuck on a bug.
I have a React App hosted as Static Website on A S3 Bucket with a Cloudfront distributions setup for it so it is secured with SSL. I also have a NodeJS/express Backend hosted on EC2 with a SSL certificate that I made myself and the EC2 is all set up to receive HTTPS request(I added a load balancer to handle HTTPS request).
Here is the twist. So basically in React project config, I have the Backend URL like this :https://long-url-to-ec2..... , you get the vibe.
So I basically have 2 environments, the React App in the S3 bucket (the unsecured app) and the React App in Cloudfront which is secured. But the problem is that in the S3 Bucket version of my app, all of my request are sent to https://my-backend but in the Cloudfront version, the request are only sent to http://my-backend . Cloudfront seems to not care about the URL and just send all of my request through HTTP even if https is specified in the URL!
Does anybody know what do I have to setup In Cloudfront so it sends my request to the good HTTPS URL and not just HTTP?
Whether you use the S3 url or the CloudFront url, it's the same React app which is hosted in S3. The issue is when your react app calls the backend, which is just an ALB url, correct? So it must be an issue with your react code. You define in your react app how you call the backend. It's got nothing to do with CloudFront.
Although I'm a bit confused how you could have different results when using the S3 url and the CloudFront url. Ultimately it's the exact same react app that calls the backend. You should start with the question of how you call the backend from your react app. The exact piece of code you're using. That should give you a clue.
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 new with AWS WAF and get stuck with setting up it for application that hosts on some dedicated server. I didn't find any information how to set up it without migration to aws servers, but I found that WAF integrated with CloudFront. But anyway I found only few information that explain how to integrate this CDN with my web application. So, the main question is:
Is it possible to use AWS WAF with application that hosted on some dedicated server? And if it possible - can you provide some guides and/or docs for setting up?
Yes, you can use WAF with a server outside AWS.
WAF works with CloudFront, and CloudFront does not require the origin server to be in the AWS ecosystem.
When you create a distribution, you specify where CloudFront sends requests for the files. CloudFront supports using several AWS resources as origins. For example, you can specify an Amazon S3 bucket or a MediaStore container, a MediaPackage channel, or a custom origin, such as an Amazon EC2 instance or your own HTTP web server. (emphasis added)
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html
Configuring CloudFront to work with your external server is no different than configuring it to work with a server in EC2. Your DNS entry (e.g. www.example.com) changes to point to CloudFront, and CloudFront connects to your server using a new name that you create (e.g. origin.example.com). CloudFront proxies requests through to your server, unless the edge location handling the a given request happens to have access to a copy of the same resource that it cached while handling a previous request for the same page -- that's how CloudFront gets your content, by caching it as it handles requests that are passing through. (You don't pre-load any content into CloudFront.) If CloudFront has a cached copy, your server sees nothing, and CloudFront returns the object to the browser from its cache. But CloudFront isn't strictly a CDN, even though they market it that way. It is a global network of reverse proxies and high-reliability/low-latency transport.
You'll want to take steps to ensure that the web server rejected requests that didn't come through CloudFront. See Using Custom Headers to Restrict Access to Your Content on a Custom Origin as well as the list of CloudFront IP Addresses which you could use on your web server's firewall.
Once you have your site working through CloudFront, all you do is activate WAF on the distribution. CloudFront is very tightly integrated with WAF so that is a very simple change, once you have your WAF rules set up.
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.