How can I easily manage constantly changing public IP addresses in my many security groups

Our development environment is hosted on AWS, and is accessed by dozens of people. As people join and leave the project, or work from alternate (often temporary) locations, I find myself constantly updating many of our security groups.

Example: Caroline is a developer who primarily works from home.

• When she joins the project, I add her public IP address to the security groups "dev-a", "dev-b", "dev-c", and "dev-d"; her entries are noted as "Caroline Lastname home"‡
• On Monday, severe weather knocks out Caroline's power; when it comes back on, her public IP address has changed, so I have to update her "Caroline Lastname home" entries in security groups "dev-a", "dev-b", "dev-c", and "dev-d".
• A week later, Caroline visits her parents in another state. She determines her new public IP and conveys it to me and I add entries in security groups "dev-a", "dev-b", "dev-c", and "dev-d" noted as "Caroline Lastname temp [YYYYMMDD]".
• I subsequently remove these "temp" IP entries on a sort of garbage-collect basis.
• When Caroline pops into the office to work, there is nothing additional for me to do because the office's IP range is already configured where it needs to be.

Now multiply these activities by the number of personnel on the project...you can see why I have the link to the security group listing bookmarked!

How can I easily manage constantly changing public IP addresses in my many security groups? What steps can I take to simplify my administrative overhead of the security group entries?

‡: All names (including security group names) have been altered to protect the innocent.

It's a bit difficult to say what's best because you've not said what people are doing in the environment. Are they running an IDE on a Windows EC2 instance? Accessing logs on a Linux box? If you edit the question to give more background you might get better answers.

A few thoughts though:

• Use a different approach: instead of whitelisting home IPs let people into a bastion instance / AWS Workspace ideally using MFA. The bastion / Workspaces security group is whitelisted in the rest of your environment. Best practice would be to have private resources in a private subnet with a bastion anyway.

• Give everyone a script / batch file that uses the AWS CLI (or CLI calls lambda) to remove any existing security group rules with their name / unique ID in it and replace it with their current IP

• Consider the general idea of identity based authentication instead of IP based restrictions, similar to zero trust networking.

If you expand on your scenario in your question then reply to let me know I can refine my answer.

Create an AWS Client VPN to give them access. They can each have their own credentials and access the environment using the private IP addresses. Also you can put VPN clients in their own security group and restrict access that way.

The other answers here are excellent in terms of alternatives and best practices if you're able to make the switch to a VPN etc.

If you want to have a mechanism to automatically manage entries per the OP's workflow, consider a solution that uses lambda to create and clean up the rules.

This GitHub repo has a robust solution: https://github.com/fvinas/tf_aws_lambda_ip_whitelist

It uses terraform to set everything up and you can choose who is able to create these rules for people, whether it's yourself or the users themselves (if you trust them that much :)).