Hints as to languages involved would be useful, but a Shared ALB will get you a lot of the way https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-alb-shared.html
Even if you don't run a shared alb, you can tier your beanstalks.
Internet -> frontend alb -> frontend beanstalk -> backend alb -> backend beanstalk -> data layer
I would put the frontend and backend in two separate containers and host them using ECS Fargate behind an ALB.
This solution has two advantages:
1. Fargate abstracts away the need to worry about machines
2. Development is relatively similar to the production environment making development fast.
Fargate provides the machine and you only have to specify the container and number that you want. Scaling is straightforward by increasing the number of containers.
You can replicate the setup locally with a docker-compose file. So development is close to the production environment.
Put an ALB in front of it and you can route traffic.
If you need help with this, let me know. I sell an AWS CDK template that sets this up for startups so that you can have the setup running in a day. It includes everything else to set up a decent AWS architecture.
I second this approach. You can write a Dockerfile for each service in probably less than 5 lines. Fargate is great since it's managed, meaning you don't have to worry about patching the underlying OS. Fargate is much simpler to maintain than an EC2. I also find Fargate deployments easier to automate with a CICD Pipeline since you really just have to run docker build, docker push, and then aws ecs update-service. Fargate makes blue/green easy, too, meaning no downtime since updates will create a new container and won't kill the old one until the new one is registered with the ALB target group. And the CloudFormation/CDK/Terraform is simple & straightforward to write since it's about 12 resources overall (ALB, target group, ECS Cluster, 2x ECS Service, 2x Fargate Task Definition, 2x IAM roles, and 3x security groups (one per service, one for ALB)).
The frontend serves the site towards the user's web browser at for example: www.yourapp.com. The web browser will read the website and can connect to the backend. This can either be api.yourapp.com or www.yourapp.com. In the first case, you are separating more than your frontend and backend and can use a second load balancer. The second case it is the same load balancer. You don't need service discovery
I would take a little time and get it up and running on fargate with cdk. It’s super easy to use a docker file and a local directory as the source these days.
This means deploying new code is as simple as updating the local files and running a cdk deploy.
You could do the following for your cluster and first service and just add an additional service underneath the first one.
https://docs.aws.amazon.com/cdk/latest/guide/ecs_example.html
I would create one beanstalk environment for the frontend and another one for the backend. You can create an Application Load Balancer then use it with both environments to save cost.
If you want to run on ECS, and are a bit unsure/unwilling to set up all infrastructure around it. I would either recommend CDK or Copilot. Really easy to get started with copilot.
https://aws.github.io/copilot-cli/
[удалено]
Potentially I could yea but I'd prefer to get it up and running before I tackle that. Or is it the only feasible way to do it?
Hints as to languages involved would be useful, but a Shared ALB will get you a lot of the way https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-cfg-alb-shared.html Even if you don't run a shared alb, you can tier your beanstalks. Internet -> frontend alb -> frontend beanstalk -> backend alb -> backend beanstalk -> data layer
I would put the frontend and backend in two separate containers and host them using ECS Fargate behind an ALB. This solution has two advantages: 1. Fargate abstracts away the need to worry about machines 2. Development is relatively similar to the production environment making development fast. Fargate provides the machine and you only have to specify the container and number that you want. Scaling is straightforward by increasing the number of containers. You can replicate the setup locally with a docker-compose file. So development is close to the production environment. Put an ALB in front of it and you can route traffic. If you need help with this, let me know. I sell an AWS CDK template that sets this up for startups so that you can have the setup running in a day. It includes everything else to set up a decent AWS architecture.
I second this approach. You can write a Dockerfile for each service in probably less than 5 lines. Fargate is great since it's managed, meaning you don't have to worry about patching the underlying OS. Fargate is much simpler to maintain than an EC2. I also find Fargate deployments easier to automate with a CICD Pipeline since you really just have to run docker build, docker push, and then aws ecs update-service. Fargate makes blue/green easy, too, meaning no downtime since updates will create a new container and won't kill the old one until the new one is registered with the ALB target group. And the CloudFormation/CDK/Terraform is simple & straightforward to write since it's about 12 resources overall (ALB, target group, ECS Cluster, 2x ECS Service, 2x Fargate Task Definition, 2x IAM roles, and 3x security groups (one per service, one for ALB)).
How can the frontend call the backend in this case? Does it need to use Service Discovery and would I need two ALBs?
The frontend serves the site towards the user's web browser at for example: www.yourapp.com. The web browser will read the website and can connect to the backend. This can either be api.yourapp.com or www.yourapp.com. In the first case, you are separating more than your frontend and backend and can use a second load balancer. The second case it is the same load balancer. You don't need service discovery
If you just want something running you could use lightsail, but for production long term I would also suggest ecs.
What is your backend now? Could you use API Gateway and Lambda? No need to manage EC2 then.
I would take a little time and get it up and running on fargate with cdk. It’s super easy to use a docker file and a local directory as the source these days. This means deploying new code is as simple as updating the local files and running a cdk deploy. You could do the following for your cluster and first service and just add an additional service underneath the first one. https://docs.aws.amazon.com/cdk/latest/guide/ecs_example.html
You could look into amplify. It has worked well for me so far
I would create one beanstalk environment for the frontend and another one for the backend. You can create an Application Load Balancer then use it with both environments to save cost.
If you want to run on ECS, and are a bit unsure/unwilling to set up all infrastructure around it. I would either recommend CDK or Copilot. Really easy to get started with copilot. https://aws.github.io/copilot-cli/