if you add a rule for the EC2s public IP, it will also work
I assume the whitelisted IPs are developers?
“if you add a rule for the EC2s public IP, it will also work”
I see and that experience would not be good becuase ec2 instances can change
thats correct they are devs
Is what im attempting not possible then without whitelisting the ec2’s ip addresses?
Our ec2 are created via auto scaling group and can change quite frequently
I was hoping to just be able to blanket allow anything within the vpc to connect to it using the cidr block ibnound rule ( kind of how aws rds does it )
it suggests in the documentation that its possible https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-security-groups.html
The following inbound rules in the security group associated with your Network Load Balancer allow only traffic that comes from the specified address range. If this is an internal load balancer, you can specify a VPC CIDR range as the source to allow only traffic from a specific VPC. I
one workaround you could is to put them behind a NAT GW. The NAT GW IP does not change. But if you do not have one already in place that would be quite pricy.
The cleaner setup would be to make the NLB internal again and pprovide access via other means to the devs.
This could wither be a VPN or an EC2 as a jump host
yes but that is for internal load balancers
Yes i jsut read what the documentation said
I should make the NLB internal again and find some way to whtielist devs
With an internal lb . whitelisting devs cannot be done via security group? (correct?)
not if they are not on the internal network. (i.e. VPN)
okay~ ye if thats the reccomended approach then its what we have to go with
I guess we were jsut hoping to recreate what we have with aws rds
Im not sure if you have experience with aws rds?
We configure that sg to allow vpc access + whitelist ip dev
Yes. the RDS instance you set up probably has both public and private interfaces (publicly accessible set to true). That is why that works.
Okay will just have to change our dev exp for connecting to these other services. Using an internal NLB so that our lambda functions etc can access the service via the nlb domian name