Geolocation for EC2 Instance Security Groups Inbound Rules

Hi, this is Abhi from AWS.

Instead of focussing on a way to Geo identify source IP addresses and then allowing/denying connections from them, I would recommend using Session Manager to SSH into Linux instances and RDP into Windows instances.

1. For Linux: Session Manager can be configured to connect to remote instance using Secure Shell(SSH) without opening inbound port or maintaining bastion host. You can also copy files between local and remote machine using Secure Copy Protocol(SCP). This feature uses public SSM document AWS-StartSSHSession.
2. For Windows: You can tunnel Remote Desktop Protocol (RDP) using Port Forwarding feature of Session Manager to get access to remote Windows instance. This can be achieved without opening inbound port 3389 (default RDP port) on remote instance.

There's an interesting approach here - https://aws.amazon.com/blogs/security/how-to-restrict-iam-roles-to-access-aws-resources-from-specific-geolocations-using-aws-client-vpn/. It leverages a WAF with geo rules, making requests on it from a Lambda not to get access to the API GW behind it, but to test whether the request will be allowed or not. The Lambda is called as part of connection to AWS Client VPN which, as a managed service, doesn't require an EC2 instance.

You could roll your own by scripting something to dynamically update the IP addresses in the security group rule.

On Linux (no idea about Windows, sorry) get the IP that your ISP has given you with dig +short myip.opendns.com @resolver1.opendns.com

And then use AWSCLI to add that to a security group rule allowing ingress from your IP on ports 22 & 3389 https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/authorize-security-group-ingress.html

Right away I can see a couple of problems with this: (i) you are going to need AWS Access Keys on your local machine at home, even if these just have barely enough privileges to only update the security group it may still breach your organisation's security policies; and (ii) a security group can have a maximum of 60 inbound rules (though you can get this increased) so depending on how often your (and your colleagues') IP addresses change you may find this quickly gets filled up.

Leveraging some other tools might help (I'm going to think in terms of Terraform here but there's probably a way of doing it in CloudFormation), plug your IP from the dig command into a variable in a file (overwriting yesterday's value), commit & push that up to a git repo and then apply the change to the AWS config (automate this using a runner) getting keys from Hashicorp Secrets Manager so no secrets ever leak onto your device at home.