Private subnets play a crucial role in your VPC — they protect, isolate, and maintain confidentiality. When designing your network, consider using private subnets.
- Security: Private subnets keep sensitive resources (such as databases, application servers, and backend services) away from prying eyes.
- No Direct Internet Access: Instances within private subnets lack public IP addresses. If these instances need internet access (for updates, patches, or cat videos), they route through a NAT Gateway or NAT Instance. This also allows you to predict the IP address for all external requests.
- Cost Optimization: By placing non-public resources in private subnets, you avoid unnecessary data transfer costs.
NAT Gateways are an essential part of private subnets, but they can be expensive and the pricing is confusing. Let’s explore the costs:
Note: EC2 prices below do not assume reserved instances, savings plans, or negotiated rates. These are the minimal savings you can anticipate.
AWS charges $0.045 per hour for NAT Gateways, roughly equivalent to a typical .medium EC2 instance. However, an EC2 NAT Gateway is a lightweight system. Even if you run one for each availability zone (AZ), you’ll still save money compared to AWS NAT Gateways.
| $/Hour | $/Month | Base | |
|---|---|---|---|
| AWS NG | $0.0450 | $32.40 | - |
| t3.micro | $0.0104 | $7.49 | 33% |
| t3a.micro | $0.0094 | $6.77 | 21% |
| t4g.micro | $0.0084 | $6.05 | 19% |
| t3.nano | $0.0052 | $3.74 | 12% |
| t3a.nano | $0.0047 | $3.38 | 10% |
| t4g.nano | $0.0042 | $3.02 | 9% |
AWS charges a hefty $0.045 per gigabyte (GB) for data processing, excluding standard Data Transfer rates. While S3 data transfer is exempt when using an endpoint within your VPC, other data types still incur processing fees. Whether it’s region-to-region, inter-region, internet outbound, or internet inbound, you’ll pay for data processing.
Consider your balance between data in and out. For routine tasks like a yum update, paying 4.5¢ per GB seems excessive. Similarly, exporting data to a client shouldn’t cost you 13.5¢ per GB (4.5¢ + 9¢ standard data charge).
| GB | - | AWS NAT In | AWS NAT Out | - | EC2 In | EC2 Out |
|---|---|---|---|---|---|---|
| 1 | $0.05 | $0.14 | $0.00 | $0.09 | ||
| 10 | $0.45 | $1.35 | $0.00 | $0.90 | ||
| 100 | $4.50 | $13.50 | $0.00 | $9.00 | ||
| 1,000 | $45.00 | $135.00 | $0.00 | $90.00 | ||
| 10,000 | $450.00 | $1,350.00 | $0.00 | $900.00 | ||
| 25,000 | $1,125.00 | $3,375.00 | $0.00 | $2,250.00 | ||
| 50,000 | $2,250.00 | $6,750.00 | $0.00 | $4,500.00 | ||
| 100,000 | $4,500.00 | $13,500.00 | $0.00 | $9,000.00 |
While AWS Data Processing charges are high, the tradeoffs are worth considering. For a detailed comparison, refer to AWS’s official documentation.
git clone https://github.com/MikeGarde/aws-nat-gateway.gitYou'll need - Packer - Terraform - Taskfile - dotenv-cli
# First time, initiate it all
task init
# Or do packer & terraform on their own
packer init ami/nat-gateway.pkr.hcl
terraform init terraform/scratch/Build the AMI, you'll need an existing VPC to create your initial AMI. Review packer-build in Taskfile.yaml
task packer-buildWhichever option you choose you'll need to have already created your EC2 NAT Gateway AMI. Next utilize the terraform files in ./terraform/scratch/ as inspiration or apply the setup to your account.
Check out the manual section below to see what this is doing.
# Automatically setup your .tfvars file (but still review it before proceeding)
task dotenv-setup
# Run terraform actions
task terraform:plan
task terraform:apply
task terraform:destroycd terraform/scratchcp .tfvars.example .tfvarsand make appropriate edits- You'll need to whitelist EC2 Connect for your region, see
Taskfile.yamlfor guidance. Or see Work with ip-ranges.json. terraform plan -var-file=".tfvars"terraform apply -var-file=".tfvars"
- Rule 5
- 5.1 - Ensure no Network ACLs allow ingress from 0.0.0.0/0 to remote server administration ports
- 5.2 - Ensure no security groups allow ingress from 0.0.0.0/0 to remote server administration ports
CIS v3 rules 5.1 and 5.2 are designed to work in tandem to enhance the security of remote server administration ports. Rule 5.1 acts as a safety net, ensuring that Network ACLs do not allow ingress from 0.0.0.0/0, while rule 5.2 focuses on the same for Security Groups.
In an ideal scenario, we would avoid making changes to the ACL and instead make necessary adjustments to the Security Groups. If done correctly, the need for rule 5.1 becomes redundant. However, if we were to enforce SSH & RDP using only Security Groups, we would fail an audit.
The rule is explicit in its instruction: do not allow inbound from 0.0.0.0/0. Therefore, we should adhere to the letter of the rule while maintaining safety with Security Groups.
For the Network ACL, we can be more permissive. If admin IPs are static, we should use them. However, if the work environment is remote, we should allow larger blocks that cover the ISP, such as /11 or /16.
On the other hand, the SSH Security Group should be specific, with a single entry per admin with a /32. This approach ensures that we comply with the CIS v3 rules while maintaining a secure and flexible network infrastructure.
Goto ipinfo.com and get your ISPs abuse block. Got a lot of people and you subscribe to ipinfo? Use the following.
IP_TOKEN=xxxx
IP_ADDR=$(curl -s -4 icanhazip.com)
IP_BLOCK=$(curl -s "https://ipinfo.io/$IP_ADDR/json?token=$IP_TOKEN" | jq -r '.abuse.network')
echo $IP_BLOCK