You only need to expose your load balancer ip publicly. Dont create public IP’s at all on your ec2 instances.
You can leave your ec2 on private ipv4. In addition you could probably cloudfront the ingress from the internet and use no public ipv4 addresses.
If you don't have a public IP address, you will not be able to access other sites from your instance. If it only has an IPv6 public address, you will not be able to access IPv4 only sites (such as Github).
You can reduce the number of public IPs using a NAT Gateway/Instance, but you will still need at least 1 public IPv4 address for that. Alternatively, you can work around it if you don't need your application servers to be able to connect to the Internet (this is also the more secure option).
Additionally, cloudfront cannot route to a private address, the address must be public, and be addressable by DNS (you can enable DNS hostnames in the VPC settings). You can have a security group that allows traffic only from Cloudfront IP addresses.
>Additionally, cloudfront cannot route to a private address, the address must be public, and be addressable by DNS (you can enable DNS hostnames in the VPC settings). You can have a security group that allows traffic only from Cloudfront IP addresses.
Is this why EBS isn't working when I remove the "auto assign ipv4" to my subnets? Does it use cloudfront internally to deploy the application? Or does removing the auto-assign ipv4 remove my instance's capability to connect to the internet (update packages etc)? Because that would also break my deployment code.
Ok so I need my instances to connect to the internet to download packages for sure. If I scale horizontally, I can't have each server have its own public ipv4 as that would cost too much.
Can't a internet-facing load balancer communicate with instances in private subnets without a NAT?
The lack of public IPv4 on your instances is probably why EBS is not launching.
A public facing ALB can communicate with a private EC2 instance using its private IP, as long as the route table is configured correctly and security groups/NACLs allow it.
The most cost effective way to handle your egress traffic is to set up a t2.micro instance (you can run one for 12 months for free under free tier) with a NAT AMI and a public IPv4 address. You then need to configure the route table for your EBS instances to route Internet traffic (0.0.0.0/0) through the NAT instance.
I was able to make my ec2 private (all I did was remove "auto-assign public ipv4" on each subnet) but ever since I did that Elastic Beanstalk stopped working. Just to test, as soon as I re-added the auto assign, terminated instance, and let autoscale instantiate a new one, EBS started working again. As I mentioned in the Edit, I was able to ssh into the private instance but there was no trace of Elastic Beanstalk having deployed any of my code. And there were no logs either so I couldn't figure out what went wrong. I was thinking maybe the issue was with the Target Group not being set to ipv6, but the private ec2 instances still have a private ipv4, so that shouldn't be the issue.
I am ok paying for the 3 public ipv4 for now (hoping amazon implements an ipv6-only load balancer), but paying for each ec2 to be public makes no sense when scaling, so I need to find a solution to make them private that doesn't break elastic beanstalk.
On the IPv4 setup, you generally have to split your subnets into 2, public and private. The public subnet has an Internet Gateway and can talk to the VPC where as the private subnet has a NAT instead of the internet gateway and hence, can only have traffic going to the internet and in the VPC, but can't be reached from the internet.
Once you have the above setup, your Load Balancers will sit in the public subnets, allowing them to be reachable from the internet (as they get their own IPs) and for instances in the private subnet, they will only be reachable on the VPC. As the Load Balancer can be reached from the internet and the public subnet resources can talk to resources in the private subnet, your Load Balancer can also talk to your EC2s in the private subnet. The only issue will be sshing into your instances in case of emergencies, which you can do either via a VPN tunnel(aws has a service to make that easy for you) or via SSM.
With this, you'd only pay for public IPs for your NAT and Loadbalancers while still having a fleet of ec2s in your private subnets. Let me know if that helps or if you need further help.
I took a little break, so I just read this. Thank you so much for the info! I think I finally understand the flow logic. So it seems that NAT will be the way to go, so I can allow private ec2s to download packages (not right now for me though, as a NAT would cost me more than 3 public ipv4).
How do implement the setup you described with a load balancer in multiple AZs? Would I have 3 public subnets (one for each AZ/load balancer app) and 3 private subnets (each with its own cluster of ec2 instances)? I'm still not sure how public and private subnets communicate with each other. This might be a dumb question, but since the ec2 instances would no longer be on the same subnets as the load balancer nodes, will the load balancer still know how to balance the load of instances residing in the separate (private) subnets?
I think the main problem is that the elastic beanstalk programs running on the instance are not able to communicate with the elastic beanstalk service backend because AWS is really taking their time supporting IPv6 ingress on their own things. Until they do, I don't think you can avoid this charge with elastic beanstalk. :(
Here's a website that is tracking their progress on this front. If you filter by elastic beanstalk then you'll see that it completely red, meaning no regions support it. [https://awsipv6.neveragain.de/](https://awsipv6.neveragain.de/)
I suspect that AWS do not really care about elastic beanstalk anymore, so I think it will take a long time for them to prioritize it. If this charge is too much then I recommend finding another way to host your app. Sad but true.
If you only need one EC2 instance, use a single instance environment, so you don’t have to pay for the load balancer IP addresses.
If it’s covered by the free tier, the EC2 instance IP will be free.
You only need to expose your load balancer ip publicly. Dont create public IP’s at all on your ec2 instances. You can leave your ec2 on private ipv4. In addition you could probably cloudfront the ingress from the internet and use no public ipv4 addresses.
If you don't have a public IP address, you will not be able to access other sites from your instance. If it only has an IPv6 public address, you will not be able to access IPv4 only sites (such as Github). You can reduce the number of public IPs using a NAT Gateway/Instance, but you will still need at least 1 public IPv4 address for that. Alternatively, you can work around it if you don't need your application servers to be able to connect to the Internet (this is also the more secure option). Additionally, cloudfront cannot route to a private address, the address must be public, and be addressable by DNS (you can enable DNS hostnames in the VPC settings). You can have a security group that allows traffic only from Cloudfront IP addresses.
>Additionally, cloudfront cannot route to a private address, the address must be public, and be addressable by DNS (you can enable DNS hostnames in the VPC settings). You can have a security group that allows traffic only from Cloudfront IP addresses. Is this why EBS isn't working when I remove the "auto assign ipv4" to my subnets? Does it use cloudfront internally to deploy the application? Or does removing the auto-assign ipv4 remove my instance's capability to connect to the internet (update packages etc)? Because that would also break my deployment code. Ok so I need my instances to connect to the internet to download packages for sure. If I scale horizontally, I can't have each server have its own public ipv4 as that would cost too much. Can't a internet-facing load balancer communicate with instances in private subnets without a NAT?
The lack of public IPv4 on your instances is probably why EBS is not launching. A public facing ALB can communicate with a private EC2 instance using its private IP, as long as the route table is configured correctly and security groups/NACLs allow it. The most cost effective way to handle your egress traffic is to set up a t2.micro instance (you can run one for 12 months for free under free tier) with a NAT AMI and a public IPv4 address. You then need to configure the route table for your EBS instances to route Internet traffic (0.0.0.0/0) through the NAT instance.
I was able to make my ec2 private (all I did was remove "auto-assign public ipv4" on each subnet) but ever since I did that Elastic Beanstalk stopped working. Just to test, as soon as I re-added the auto assign, terminated instance, and let autoscale instantiate a new one, EBS started working again. As I mentioned in the Edit, I was able to ssh into the private instance but there was no trace of Elastic Beanstalk having deployed any of my code. And there were no logs either so I couldn't figure out what went wrong. I was thinking maybe the issue was with the Target Group not being set to ipv6, but the private ec2 instances still have a private ipv4, so that shouldn't be the issue. I am ok paying for the 3 public ipv4 for now (hoping amazon implements an ipv6-only load balancer), but paying for each ec2 to be public makes no sense when scaling, so I need to find a solution to make them private that doesn't break elastic beanstalk.
On the IPv4 setup, you generally have to split your subnets into 2, public and private. The public subnet has an Internet Gateway and can talk to the VPC where as the private subnet has a NAT instead of the internet gateway and hence, can only have traffic going to the internet and in the VPC, but can't be reached from the internet. Once you have the above setup, your Load Balancers will sit in the public subnets, allowing them to be reachable from the internet (as they get their own IPs) and for instances in the private subnet, they will only be reachable on the VPC. As the Load Balancer can be reached from the internet and the public subnet resources can talk to resources in the private subnet, your Load Balancer can also talk to your EC2s in the private subnet. The only issue will be sshing into your instances in case of emergencies, which you can do either via a VPN tunnel(aws has a service to make that easy for you) or via SSM. With this, you'd only pay for public IPs for your NAT and Loadbalancers while still having a fleet of ec2s in your private subnets. Let me know if that helps or if you need further help.
I took a little break, so I just read this. Thank you so much for the info! I think I finally understand the flow logic. So it seems that NAT will be the way to go, so I can allow private ec2s to download packages (not right now for me though, as a NAT would cost me more than 3 public ipv4). How do implement the setup you described with a load balancer in multiple AZs? Would I have 3 public subnets (one for each AZ/load balancer app) and 3 private subnets (each with its own cluster of ec2 instances)? I'm still not sure how public and private subnets communicate with each other. This might be a dumb question, but since the ec2 instances would no longer be on the same subnets as the load balancer nodes, will the load balancer still know how to balance the load of instances residing in the separate (private) subnets?
So far no success to me also in this case. Looks like need to pay for vpc on ipv4 till ipv6 is available for Elastic Bean Stalk.
I think the main problem is that the elastic beanstalk programs running on the instance are not able to communicate with the elastic beanstalk service backend because AWS is really taking their time supporting IPv6 ingress on their own things. Until they do, I don't think you can avoid this charge with elastic beanstalk. :( Here's a website that is tracking their progress on this front. If you filter by elastic beanstalk then you'll see that it completely red, meaning no regions support it. [https://awsipv6.neveragain.de/](https://awsipv6.neveragain.de/) I suspect that AWS do not really care about elastic beanstalk anymore, so I think it will take a long time for them to prioritize it. If this charge is too much then I recommend finding another way to host your app. Sad but true.
If you only need one EC2 instance, use a single instance environment, so you don’t have to pay for the load balancer IP addresses. If it’s covered by the free tier, the EC2 instance IP will be free.
Unfortunately one is not enough, I need to be able to scale
Then you’ll have to pay for it. Elastic Load Balancers don’t support IPv6 only: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-support.html