I have a networking question that is hopefully not difficult to untangle (Cloud networking newbie here).
Task
My company uses a vendor for a UI interface and data storage, a 'managed cloud solution'. Basically, when our front line staff enter data in the vendor's proprietary UI software, the data is stored to a SQL Server RDBMS on the vendor's AWS Account. I need to go out and grab that data from their server on a schedule, basic ELT. To gain access to the RDBMS, I need to have an IP address whitelisted and will be doing so from our AWS account.
Questions
Would I want to use our private subnet NAT Gateway's private IPv4 address as the IP to have whitelisted? There is a requirement that the IP come from our domain so I do not think an IGW allowed. Or should the NAT Gateway sit on a public subnet since we're leaving the boundary of our own network and trying to connect to another AWS network? Does he NAT Gateway is on our private subnet, would that prevent a request going out to the vendors IP address or prevent us my task from extracting the data?
Additional Context
The IP Whitelisting is treated as an exception to policy, which is to only give out RDP to the server instance, so requesting a range of IPs or repeatedly requesting IPs to whitelist is a pain and raises questions so ideally I would only request one IP.
I'm planning to use Fargate Tasks to spin up Linux Debian Container (Buster) on a schedule to perform the ELT, but I notice that Fargate creates new IP addresses each run. My thought is that the target IP will see the NAT Gateway's IP address if I put my task on the NAT's private subnet.
Assume that I have
Or is there a better method to run small periodic batch jobs requiring a static IP address?
I have done research on AWS networking but am unclear of the best path forward given the particulars of my situation. The AWS literature suggests that Fargate Tasks are the best solution for batch work, but that IP addresses aren't static. Unclear if the task resides on a private subnet with a Nat-Gateway, if that that NAT will translate the task's IP Address to a standard IP address.
Related question Unable to get AWS NAT gateway working for API with IP whitelist does not seem to address my question.
Would I want to use our private subnet NAT Gateway's private IPv4 address as the IP to have whitelisted?
A NAT Gateway has to sit in a public subnet. It has to have a direct route to an Internet Gateway. Private subnets would have a route in their route table to the NAT Gateway. You would never give out a NAT Gateway's private IP address, because any private IP address would only make sense from within your VPC. It is the public IP address you would give out.
When you create your NAT Gateway, you would assign an Elastic IP address to it. This Elastic IP address is the public IP address that all traffic that goes through the NAT Gateway will have. The Elastic IP address is the address you would ask your third-party vendor to whitelist.
There is a requirement that the IP come from our domain so I do not think an IGW allowed.
This requirement doesn't make much sense, but if you need to have a DNS record on your domain that verifies you control this IP address, as part of the validation process, then after you have created the NAT Gateway with an Elastic IP address, you could create an A record in your DNS host that points to the Elastic IP address.
My thought is that the target IP will see the NAT Gateway's IP address if I put my task on the NAT's private subnet.
Yes, exactly! You have to have the "Assign Public IP" setting in your Fargate task set to false, and you have to deploy your Fargate task into a private subnet. That private subnet has to have a route in the route table to the NAT Gateway. Then any outgoing network requests in your Fargate task will be routed through the NAT Gateway, and use the NAT Gateway's public IP address.