- Newest
- Most votes
- Most comments
Hello keiichi_m,
I'm not so sure about how your current architecture look like. I will start from scratch and assume you are using LINUX. I'll have the steps clearly written out for your convenience.
- Create a Internet gateway sitting at the edge of your VPC.
- Create a public subnet(Assign a route to Internet Gateway) and within this public subnet create a NAT gateway. NAT gateway will allow a single direction communication from your resources in private subnet to the public internet.
- Create a private subnet(Ensure the subnet do not have a direct route to the internet ) and have your web server hosted within this private subnet. This ensures that your web server is not exposed to the internet. To establish communication to the public internet your web server will have to relay the request to the NAT gateway and then to the Internet gateway.
- Since you want to specifically allow connections from *.us-west-2.compute.amazonaws.com I personally think that the simplest way to achieve this is by leveraging security group.
-
Step 1: Go to AWS IP Address ranges JSON file, https://ip-ranges.amazonaws.com/ip-ranges.json
-
Step 2: Look for 'us-west-2' EC2 prefixes. Search for entries with the following ["region": "us-west-2", "service": "EC2",]. Go to the ip_prefix I've attached and select the same characters that I have highlight and do a search(spacing matters). Your search will bring you to 209 entries, these are the full list of IP ranges used by EC2 instances in us-west-2.
-
Step 3: Update Inbound Rules in your Web Server's Security Groups: Add inbound rule for HTTPS (port 443) with the source set to the identified IP range(s) you found in step 2.
You can also consider to deploy a NGINX reverse proxy on a new EC2 instance in the public subnet, but note that NGINX does not directly support DNS-based filtering in its configuration. You will still have to translate the domain pattern into its corresponding IP ranges. To achieve this there is many more steps you'll need to execute compared to what I have suggested above.
If you think that my response answers your question please select it as accepted answer cheers!
You can't filter traffic based on DNS name because the packets don't contain the DNS name they only contain the IP address. And while you can filter based HTTP headers they can't be trusted because the client can put anything they like into a header.
While you can do a reverse IP lookup to obtain a DNS name based on the source IP address that takes time and may not return a name in the DNS domain that you expect so it's not performant and not really "accurate".
So you should filter based on source IP address. You can find the various AWS IP ranges in ip-ranges.json and then you can apply filters using NACLs or WAF on ALB or CloudFront.
I did implement a reverse IP lookup in my code, thatk-you. It succeeds for us-west-2.compute.amazonaws.com addresses and if the lookup either fails or returns something else, I've set the web server code to return an error. So this is helpful, but not as good as filtering. I'm not currently using CloudFront.
Relevant content
- Accepted Answerasked 2 years ago
- Accepted Answerasked a year ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 5 months ago
I'm using Linux, with nginx as a reverse proxy followed by gunicorn and flask. I was hoping not to have to create another gateway with the complexity of NAT. At present the instance is unprotected except for the rules I've set up for ssh and https access. For ssh I can be really specific about the allowed IP addresses; the issue is for https where I need to accept all the many ranges in us-west-2.