I want to utilize AWS ECS fargate but I have a requirement from the security team to restrict the Private IP range of my fargate instances within a subnet.
From the AWS networking docs, It seems like it is possible to use a seperate non-managed ENI to specify the private IP address. Is there a method to use a static IP range for the fargate instances?
For tasks that use the Fargate launch type, the task ENI that is
created is fully managed by AWS Fargate. Depending on which Fargate
platform version your task uses, the network traffic for your task may
also use a separate Fargate-owned ENI.
The fixed private IP range is decided based on the subnet(s) that you will deploy your Fargate tasks into.
If you create seperate subnet(s) for your Fargate tasks, and then ensure that only Fargate tasks are launched in these subnets you could then provide this range to your security team.
Fargate creates the ENI when it launches the task, with a random private IP address form the pool of available IPs in your subnet(s) range.
Related
We have an EKS cluster running in a VPC and we are thinking of extending this VPC or creating another VPC with a different subnet IP range. EKS nodes (EC2 instances) are running with multiple ENIs, that is, with multiple private IPs.
We wonder if it is possible to make these EC2 instances which serve as EKS nodes automatically get an IP from this new subnet within current VPC or on the other VPC when they are getting instantiated. If the subnet is on another VPC, should we have a VPC peering connection between two VPCs? Can it be doable by Cloud Formation templates on EKS? What is the best practice here? Thanks.
The option to extend VPC in EKS is via adding secondary CIDR block and configure CNI plugin to use the subnets created in the secondary CIDR block. CNI is ultimately responsible to assign the ip addresses available through the subnet cidr to the pods.
To use the correct CIDR range for VPC extension and to configure the CNI please use the below article :
https://aws.amazon.com/premiumsupport/knowledge-center/eks-multiple-cidr-ranges/
I have 3 AWS Elastic Beanstalk instances which are running Spring microservices. All microservices are making POST requests to each other and using RDS service for database.
Should I isolate database traffic and microservices traffic into separate subnets?
In case it's a good practice is it possible to assign 2 private network IP's for each subnet for every AWS Elastic Beanstalk instance?
I think you cannot do it using EBS as the instances will auto create and terminate. So you should try to create instances separately and add autoscaling policy on it.
What I usually do is create my EC2 instances in Public subnet and RDS in private subnet and use RDS Security Group and add EC2 instance's Elastic IP, so that all the traffic is going through the EC2 instance and all the traffic coming to EC2 instance is HTTPS coming from ELB.
Adding the below steps as requested:
Ok, So I am assuming you already know a bit about how to create the servers and RDS etc.
Create an EC2 instance for each of your microservices.
Attach an EIP to each of these instances.
Add an Auto-Scaling policy to increase or decrease the instances based on the traffic/CPU Utilization. Make sure you terminate the newest created instance.
Add an ELB for this instance and add HTTPS/SSL certificate to secure your traffic.
Create RDS in a Private subnet and add instance EIP in RDS SG for 3306 port.
I think you should be able to do this then.
It's not a good practice to directly communicate between instances in EB. The reason is that that EB instances run in autoscalling group. So they can be terminated and replaced at any time by AWS leading to change in their private Ip addresses.
The change in IP will break your application sooner or later. Instances in EB should be accessed using Load Balancer or private IP.
So if you have some instances that are meant for private access only you could separate them to internal EB environment.
I am facing an issue while using AWS - ECS service.
I am launching my ECS cluster with 2 instances. I use EC2 service. Not Fargate. I am trying to use the awsvpc networking for the ECS containers. Morte info is here.
For the container load balancing , target type is IP. It is not editable.
Now the problem is - Auto Scaling Group can not be created for this target group to scale the cluster.
How do you guys handle the situation?
Simply leave out the load balancing configuration for the Auto Scaling group.
awsvpc creates a separate network interface whose IP address is registered to the Target Group. This target group has to be of the ip-address type.
Auto Scaling Groups use the instance target group type, that uses the default network interface of the EC2 instances.
Since the Task will get its own IP address, which is separate from the IP address of the EC2 instance, there is no need to configure load balancing for the EC2 instances themselves.
This is because of awsvpc mode,awsvpc network mode is associated with an elastic
network interface, not an Amazon EC2 instance so you must choose IP. Here is what AWS said about AWVPC network mode .
AWS_Fargate
Services with tasks that use the awsvpc network mode (for example,
those with the Fargate launch type) only support Application Load
Balancers and Network Load Balancers. Classic Load Balancers are not
supported. Also, when you create any target groups for these services,
you must choose ip as the target type, not instance. This is because
tasks that use the awsvpc network mode are associated with an elastic
network interface, not an Amazon EC2 instance.
Fargate do not to manage EC2 instances, the purpose of Fargate is not to manage server then why you need to attach auto-scaling? you can scale services.
AWS Fargate is a technology that you can use with Amazon ECS to run
containers without having to manage servers or clusters of Amazon EC2
instances. With AWS Fargate, you no longer have to provision,
configure, or scale clusters of virtual machines to run containers.
This removes the need to choose server types, decide when to scale
your clusters, or optimize cluster packing.
https://aws.amazon.com/blogs/compute/aws-fargate-a-product-overview/
I have limited IP's in my public facing VPC which basically means I cannot run the K8S worker nodes in that VPC since I would not have sufficient IP's to support all the pods. My requirement is to run the control plane in my public facing VPC and the worker nodes in a different VPC with a private IP range (192.168.X.X).
We use traefik for ingress and have deployed traefik as a DaemonSet. These pods are exposed using a Kubernetes service of type NLB. And we created a VPC endpoint on top of this NLB which allows us to access this traefik endpoint through our public facing VPC.
However, based on docs it looks like NLB support is still in alpha stage. I am curious what are my other options given the above constraints.
Usually, in Kubernetes cluster Pods are running in separate overlay subnet that should not overlap with existing IP subnets in VPC.
This functionality is provided by Kubernetes cluster networking solutions like Calico, Flannel, Weave, etc.
So, you only need to have enough IP address space to support all cluster nodes.
The main benefit of using NLB is to expose client IP address to pods, so if there are no such requirements, regular ELB would be good for most cases.
You can add secondary CIDR to your vpc and use one of the two options mentioned here to have pods use the secondary vpc CIDR.
https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/
My website is running behind an AWS Classic Load Balancer. It has some scaling policies and it launches some new EC2 instances when it has to.
Is it possible to have the range of public IP addresses that will be used for the EC2 instances when they will be launched by the load balancer ?
Is it possible to have the range of public IP addresses that will be used for the EC2 instances when they will be launched by the load balancer
Not to my knowledge. Public IP addresses are assigned automatically by AWS from a pool of addresses and I do not believe it is possible to know in advance what address will be assigned to your EC2.
See here for more details
Why do you need the ip address of the new instances, out of interest? Are you trying to dynamically provision access to resources on them as part of your ec2 startup process?
This is technically possible if you use Elastic IPs. While you can't create a pool for your scaling policies to pull from, you can create several EIPs and configure Lambda scripts that trigger during scaling events, and assign available EIPs to the new instances using the associateAddress API.
Alternatively, this seems like a similar problem, and maybe a useful solution for you.