EC2 - consider disabling associate public IP address in launch templates

Disabling associate_public_ip_address in an AWS EC2 launch template stops new instances from receiving a public IPv4 address automatically at launch. Every public IPv4 address attached to a running instance carries an hourly charge and adds a direct path from the internet to that instance, so removing the automatic assignment reduces both cost and attack surface. This applies to any launch template backing an Auto Scaling group or standalone instance that doesn't need to accept unsolicited inbound traffic from the public internet.

Why This Policy Matters

How It Helps Reduce Cloud Costs

AWS bills separately for every public IPv4 address attached to a running instance, on top of the instance's compute cost. That charge accrues every hour the address is attached, whether or not the instance receives any inbound traffic on it.

Instances that reach the internet only for outbound traffic, like pulling packages or calling an external API, don't need a public IP address to do that. A NAT gateway in the VPC route table provides outbound connectivity for instances in a private subnet, without exposing them to inbound connections from the internet.

This policy does not eliminate egress costs. A NAT gateway has its own hourly charge and a per-gigabyte data processing fee, so removing public IP addresses shifts the cost model rather than eliminating outbound cost entirely.

Potential Savings

The per-instance savings from removing one public IPv4 address are modest on their own. The effect compounds at fleet scale: an Auto Scaling group that runs hundreds of instances, or a shared launch template reused across many teams, multiplies a small per-instance charge into a recurring monthly line item.

Teams that default new launch templates to associate_public_ip_address = false avoid that charge going forward, rather than needing to clean it up after the fact. Retrofitting existing instances typically requires replacing them, since public IP assignment on a network interface generally can't be toggled without recreating the interface or the instance.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show a launch template that assigns a public IP address by default, and the corrected version that doesn't.

Non-compliant configuration: public IP address assigned automatically

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "t3.medium"

  network_interfaces {
    associate_public_ip_address = true
    security_groups             = [aws_security_group.app.id]
  }
}

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "t3.medium"

  network_interfaces {
    associate_public_ip_address = true
    security_groups             = [aws_security_group.app.id]
  }
}

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "t3.medium"

  network_interfaces {
    associate_public_ip_address = true
    security_groups             = [aws_security_group.app.id]
  }
}

Every instance launched from this template gets a public IPv4 address automatically, whether or not it needs one. This is a common source of unnecessary internet exposure on internal-only services.

Compliant configuration: public IP address disabled

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "t3.medium"

  network_interfaces {
    associate_public_ip_address = false
    security_groups             = [aws_security_group.app.id]
  }

  iam_instance_profile {
    name = aws_iam_instance_profile.ssm.name
  }
}

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "t3.medium"

  network_interfaces {
    associate_public_ip_address = false
    security_groups             = [aws_security_group.app.id]
  }

  iam_instance_profile {
    name = aws_iam_instance_profile.ssm.name
  }
}

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "t3.medium"

  network_interfaces {
    associate_public_ip_address = false
    security_groups             = [aws_security_group.app.id]
  }

  iam_instance_profile {
    name = aws_iam_instance_profile.ssm.name
  }
}

Instances launched from this template stay on private IP addresses only. The added iam_instance_profile block attaches the permissions needed for AWS Systems Manager Session Manager, covered in the next section.

Step-by-Step Fix Instructions

1. List every aws_launch_template resource in Terraform state and check the associate_public_ip_address value in each network_interfaces block.

2. Confirm a NAT gateway exists in the route table for the private subnets these instances will use, so outbound connectivity still works.

3. Set associate_public_ip_address = false and move the launch template's subnet references to private subnets if they currently point at public ones.

4. Attach an IAM instance profile with the AmazonSSMManagedInstanceCore managed policy so AWS Systems Manager Session Manager can reach the instance without inbound SSH.

5. Run terraform plan to confirm the change. Auto Scaling groups typically need an instance refresh to roll the new template version out to running instances.

6. Add Infracost to the CI/CD pipeline so any future pull request that sets associate_public_ip_address = true gets flagged before merge by Infracost's built-in check for this pattern.

Best Practices

• Default associate_public_ip_address to false in shared or reusable launch template modules, so teams have to opt in to a public IP address rather than opt out.

• Use AWS Systems Manager Session Manager instead of SSH key pairs and an open port 22 for administrative access. This removes the need for a public IP address or an open inbound rule just to reach the instance.

• This policy does not apply to instances that must remain directly reachable from the public internet, such as a self-managed VPN endpoint or a NAT instance. Those are exceptions to document, not default configurations.

Tools and Scripts

Infracost's Cloud Security Policies include a named check for this exact pattern, EC2 - consider disabling associate public IP address in launch templates, which flags the exact file and line that needs attention before code merges.

This gives platform teams a pre-deployment signal instead of discovering an internet-facing instance during a security review. Infracost enables teams to track how many policy violations get introduced over time, which supports burning down existing exposure incrementally and reporting progress.

To check existing launch templates using the AWS CLI:

aws ec2 describe-launch-template-versions \
  --launch-template-name <template-name> \
  --query "LaunchTemplateVersions[].LaunchTemplateData.NetworkInterfaces"

aws ec2 describe-launch-template-versions \
  --launch-template-name <template-name> \
  --query "LaunchTemplateVersions[].LaunchTemplateData.NetworkInterfaces"

aws ec2 describe-launch-template-versions \
  --launch-template-name <template-name> \
  --query "LaunchTemplateVersions[].LaunchTemplateData.NetworkInterfaces"

Examples of Impact

Illustrative example: an internal API picks up a public IP by accident. A team copies an existing launch template as a starting point for a new internal service and doesn't notice the copied template still has associate_public_ip_address = true. The service is only ever called by other services inside the VPC, but every instance now has a public IPv4 address and is technically reachable from the internet through its security group rules, an exposure nobody intended.

Illustrative example: fleet-wide cleanup. A platform team audits its shared launch template modules and finds associate_public_ip_address unset in several of them, defaulting to the subnet's own public-IP setting. Standardizing on falseacross the modules and moving the affected Auto Scaling groups to private subnets removes public IP addresses from several hundred instances in one change.

(These are illustrative, composite scenarios, not specific customer accounts.)

Considerations and Caveats

• Subnet defaults still apply. If associate_public_ip_address is left unset in the launch template, the subnet's map_public_ip_on_launch setting determines the outcome. Setting the attribute explicitly to false removes that ambiguity.

• NAT gateways aren't free. Moving instances to a private subnet behind a NAT gateway trades the public IPv4 charge for a NAT gateway hourly charge plus data processing costs. This is usually a net reduction at fleet scale, but it's a real cost, not zero.

• Session Manager needs a network path. Systems Manager Session Manager requires the instance to reach the SSM endpoints, either through the NAT gateway or through VPC interface endpoints for SSM.

• Provider-specific. This policy targets the aws_launch_template resource and the network_interfaces.associate_public_ip_address attribute. Other providers expose similar settings under different resource and attribute names.

• Existing instances need replacement. Changing a launch template only affects new instances launched from it; running instances usually need an instance refresh or replacement to pick up the change.

Related Policies and Concepts

• EC2 - require Instance Metadata Service Version 2 (IMDSv2): another EC2-level FinOps policy in Infracost's library that hardens the default configuration of EC2 instances against a common attack path.

• App Service - consider using latest TLS version: a similarly structured Compute-group policy that closes a configuration gap most teams don't think to check until an audit flags it.

• PostgreSQL - consider using backup retention in non-production projects: a related Compute-group policy focused on removing an unnecessary default rather than a one-time cleanup.

• "How to Enforce Cloud Cost Policies in Your CI/CD Pipeline": a planned Infracost resource article covering the broader workflow of catching configuration and cost policy violations like this one at the pull request stage.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. EC2 - consider disabling associate public IP address in launch templates is one of Infracost's built-in Cloud Security Policies. It evaluates aws_launch_template resources in pull requests and flags any associate_public_ip_address set to true. This check is available in the free trial and all paid plans.

Can this policy be customized?

Yes. Teams can scope the policy in Infracost, for example limiting the check to specific launch templates, environments, or accounts, rather than applying the default configuration everywhere.

Does Infracost automatically fix violations?

No. Infracost identifies and reports an aws_launch_template resource with associate_public_ip_address set to true in a pull request. Setting the attribute to false and confirming outbound connectivity through a NAT gateway is a change the team applies manually.

Is this policy cloud-agnostic?

No. This specific policy targets AWS EC2 launch templates and the aws_launch_template Terraform resource. Other cloud providers expose similar public-IP-on-launch settings, but the resource and attribute names differ.

How often should I review launch template public IP settings?

Teams running Infracost in CI/CD get a check on every pull request that touches an aws_launch_template resource. For templates already in place, reviewing network interface settings during a recurring security or cost audit, quarterly is a reasonable cadence for most teams, catches drift that CI alone won't.

Does disabling the public IP address affect how I access the instance for troubleshooting?

Yes, in a good way for most teams. Without a public IP address, direct SSH from the internet isn't possible. AWS Systems Manager Session Manager provides shell access through the AWS API instead, without requiring an open inbound port or a bastion host.

What is the difference between this setting and a subnet's public IP default?

associate_public_ip_address on the launch template's network_interfaces block takes precedence when explicitly set. If it's left unset, the subnet's own map_public_ip_on_launch setting determines whether new instances get a public IP address.