My application architecture's allowed traffic flow is as below in AWS.
CompanyInternalSubnets(IS)=>ALB with WAF=>EC2
ALB has security groups which allows only traffic from IS. ALB has WAF which has rules to allow traffic only from IS. EC2 has security group which allows only traffic from ALB's SG.
I want to create multiple replica of same application in AWS. I will create sperate EC2 and ALB. but can i use same WAF and attach it to second ALB or do i need to use separate WAF fur each replica? what is the best practice?
Thanks
use the same WAF across since its a replica and why another one? unless you have a different set of rule
Related
I am reading up on AWS Auto Scaling Groups and trying to understand (from a network-perspective) how the following resources all fit together:
Auto Scaling Group (ASG)
Application Load Balancer (ALB)
Individual EC2 instances sitting behind the ALB
ALB Listeners
ALB Target Groups
Security Group(s) enforcing which IPs/ports are allowed access to the EC2 instances
I understand what each of these does in theory, but in practice, I'm having trouble seeing the forest through the trees with how they all snap together. For example: do I configure the EC2 instances to be members of the Security Group? Or do I do that at the balancer-level? If I attach the ALB to the Auto Scaling Group, then why would I need to do any additional configuration with an ALB Target Group? When it comes to routing, do I route port 80 traffic to the ALB or the Auto Scale Group?
I know these are lots of small questions, so the main question here is: how do all of these snap together to provide a load balanced web server hosted on EC2 instances? Ultimately I need to configure all of this inside a CloudFormation template, but a diagram or explanation to help me configure everything manually is probably the best place for me to start. Thanks for any help!
do I configure the EC2 instances to be members of the Security Group?
Or do I do that at the balancer-level?
The EC2 instances should be a member of one security group. The Load Balancer should be a member of another security group. The Load Balancer's security group should allow incoming traffic from the Internet. The EC2 instances should allow incoming traffic from the load balancer.
If I attach the ALB to the Auto Scaling Group, then why would I need
to do any additional configuration with an ALB Target Group?
If you are using an auto-scaling group to create the instances, then you don't have to do any manual updates to the target group, the auto-scaling group will handle those updates for you.
When it comes to routing, do I route port 80 traffic to the ALB or the
Auto Scale Group?
An Auto-scaling group is not a resource that exists in your network. It is a construct within AWS that just creates/removes EC2 servers for you based on metrics. The traffic goes to the load balancer, and the load balancer sends it to the EC2 instances in the target group.
I know these are lots of small questions, so the main question here is: how do all of these snap together to provide a load balanced web server hosted on EC2 instances? Ultimately I need to configure all of this inside a CloudFormation template, but a diagram or explanation to help me configure everything manually is probably the best place for me to start.
It's a bit much to ask somebody on here to spend their free time creating a diagram for you. I suggest looking at the AWS reference WordPress implementations which they tend to use for providing reference implementations of auto-scaled web server environments.
See the "WordPress scalable and durable" CloudFormation template example here.
See the AWS WordPress Reference Architecture project here, which includes a diagram.
New to fargate. Trying to understand how to separate tasks connections.
We have multiple Fargate tasks, like Frontend task, Backend task, and other tasks created by different teams.
How to restrict incoming and outgoing traffic to other services so that other team's tasks cannot communicate with frontend or backend.
In order to restrict or allow traffic, we can use Security Groups
In fact, when we create a Fargate task from the AWS console, we are greeted with the following options:
This step will explicitly create either one security group allowing inbound traffic on port 80 for HTTP or two security groups in case if we put a load balancer in front of the task. In case if we have a load balancer, the security group attached to the load balancer will allow traffic from the outside on port 80, while the security group attached to the task will allow traffic only from the load balancer.
Obviously the inbound/outbound rules of a security group can be further customized if we go into EC2 console and search for our security group.
Besides security groups, we can allow or restrict traffic on the VPC level using NACLs.
I am having a bunch of micro services running in AWS ECS fargate with ALB and Route53.Each micro service has an ALB with Route53.
Is there any kind of possibility where I can use only one ALB for all the microservices and route to their respective Route53 paths??
Here, I am not using EKS. Using AWS ECS Fargate.
To server multiple Fargate services from a single ALB, you need to create different target groups (TGs) for them. So, each service will have its own TG, and ALB will forward traffic to respective TGs based on some listener rules.
Since you have Route53, a common choice is to create sub-domains, e.g.: service1.example.com and service2.example.com. You associate them as simple Alias A records with the same ALB.
On the ALB you will have single listener (e.g. HTTP 80), with different rules. For example:
Rule one will be based on Host header equal to service1.example.com, with Action of Forward to TG1.
Rule two will be based on Host header equal to service2.example.com, with Action of Forward to TG2.
Some default rule compulsory (or use 2 as default rule).
And that's it. Any request from the internet directed to service1.example.com will go to your TG1 which is Fragete service1. Same for requests to service2.example.com.
We are having several microservices on AWS ECS. We have single ALB which has different target group for different microservices. We want to expose some endpoints externally while some endpoints just for internal communication.
The problem is that if we put our load balancer in public VPC than it means that we are exposing all register endpoints externally. If we move load balancer to private VPC, we have to use some sort of proxy in public VPC, which required additional infra/cost and custom implementation of all security concerns like D-DOS etc.
What possible approaches we can have or does AWS provide some sort of out of the box solution for this ?
I would strongly recommend running 2 albs for this. Sure, it will cost you more (not double because the traffic costs won't be doubled), but it's much more straight forward to have an internal load balancer and an external load balancer. Work hours cost money too! Running 2 albs will be the least admin and probably the cheapest overall.
Checkout WAF. It stands for web application firewall and is available as AWS service. Follow these steps as guidance:
Create a WAF ACL.
Add "String and regex matching" condition for your private endpoints.
Add "IP addresses" condition for your IP list/range that are allowed to access private endpoints.
Create a rule in your ACL to Allow access if both conditions above are met.
Assign ALB to your WAF ACL.
UPDATE:
In this case you have to use external facing ALB in a public subnet as mentioned by Dan Farrell in comment below.
I would suggest doing it like this:
one internal ALB
one target group per microservice, as limited by ECS.
one Network load balancer(NLB), with one ip based target group.
The Ip based target group will have the internal ALB ip addresses,as the private ip addresses for ALB are not static, you will need to setup cloudwatch cron rule with this lambda function(forked from aws documentation and modified to work on public endpoints as well):
https://github.com/talal-shobaita/populate-nlb-tg-withalb/
Both ALB and NLB are scalable and protected from DDOS by AWS, AWS WAF is another great tool that can be attached directly to your ALB listener for extended protection.
Alternatively, you can wait for AWS to support multiple target group registration per service, it is already in their roadmap:
https://github.com/aws/containers-roadmap/issues/104
This how we eventually solved.
Two LB one in private and one in public subnet.
Some APIs meant to be public, so directly exposed through public LB.
For some private APIs endpoints need to be exposed, added a proxy in public LB and routed those particular paths from public LB to private LB through this proxy.
These days API Gateway is the best way to do this. You can have your API serve a number of different endpoints while serving only the public ones via API Gateway and proxying back to the API.
I don't see it mentioned yet so I'll note that we use a CloudMap for internal routing and an ALB for "external" (in our case simply intra/inter-VPC) communication. I didn't read in depth, but I think this article describes it.
AWS Cloud Map is a managed solution that lets you map logical names to the components/resources for an application. It allows applications to discover the resources using one of the AWS SDKs, RESTful API calls, or DNS queries. AWS Cloud Map serves registered resources, which can be Amazon DynamoDB tables, Amazon Simple Queue Service (SQS) queues, any higher-level application services that are built using EC2 instances or ECS tasks, or using a serverless stack.
...
Amazon ECS is tightly integrated with AWS Cloud Map to enable service discovery for compute workloads running in ECS. When you enable service discovery for ECS services, it automatically keeps track of all task instances in AWS Cloud Map.
You want to look at AWS Security Groups.
A security group acts as a virtual firewall for your instance to control inbound and outbound traffic.
For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic.
Even more specific to your use-case though might be their doc on ELB Security Groups. These are, as you may expect, security groups that are applied at the ELB level rather than the Instance level.
Using security groups, you can specify who has access to which endpoints.
I'm trying to setup my ECS Hosts so the outbound rules does not allow the whole world, very similar to this issue. The ideal way would be to point directly to the NAT-gateway but according to Amazon, that is not possible:
Note that security groups cannot be directly associated with a NAT gateway. Instead, customers can use EC2 instance security groups outbound rules to control authorized network destinations or leverage a network ACL associated with the NAT gateway’s subnet to implement subnet-level controls over NAT gateway traffic.
How do I setup a proxy or ACL for the ECS hosts?
This reference architecture should be helpful to you, it contains a CloudFormation template that automatically sets this up for you, so you can learn from the configuration it containers: https://github.com/awslabs/ecs-refarch-cloudformation