bug: CloudFormation EC2 NetworkInterfaces ignores AssociatePublicIpAddress=false #84
Replies: 1 comment
|
Retested the unchanged minimal reproduction on the unmodified
Direct EC2 The equivalent CloudFormation This used the normal licensed entrypoint with no added extensions, adapters, or init scripts. The stack and both instances were deleted after the comparison. Successful execution and cleanup do not mean the CloudFormation checks passed. |
Uh oh!
There was an error while loading. Please reload this page.
An
AWS::EC2::Instancecreated with an inline primaryNetworkInterfacesentry andAssociatePublicIpAddress: falsestill receives a public IPv4 address. A directRunInstancescontrol using the same subnet and interface flag receives no public address.Tested with an unmodified
localstack/localstack-pro:devimage on Linux amd64, resolved on 2026-10-21 to:localstack/localstack-pro@sha256:722b9ef554f91eedf9416b4efb4d0581177073b7c890679594b6d52b3ee186e4Image creation time:
2026-10-21T12:09:05.228977792Z. The reproduction usesEC2_VM_MANAGER=mock, no extensions, no initialization hooks, and no source patches. All AWS calls use the local endpoint and dummy credentials.Start a disposable container with your own LocalStack Pro auth token:
Then run the following script in that container. It selects an available x86_64 AMI and a default subnet with
MapPublicIpOnLaunch=true, creates one direct EC2 instance and one CloudFormation-owned instance, compares the exact instance IDs, and removes both through the normal APIs.Expected
The explicit
AssociatePublicIpAddress=falseon the primary interface should suppress public-IP assignment even when the selected subnet hasMapPublicIpOnLaunch=true, matching the direct EC2 control.Observed
The direct instance has no public IPv4 address. The CloudFormation-owned instance has a public IPv4 address. Both instances are running. In this generic reproduction, the CloudFormation instance also uses a different subnet from the requested primary interface, as shown below. The CloudFormation template uses the schema-appropriate string
DeviceIndex: "0"; the EC2 SDK request uses integerDeviceIndex: 0.Focused result from the stock-image comparison:
{ "direct": { "state": "running", "subnet_matches": true, "has_public_ipv4": false }, "cloudformation": { "state": "running", "subnet_matches": false, "has_public_ipv4": true } }The reproduced instances and stacks were deleted through the ordinary EC2/CloudFormation APIs, and the disposable container was removed. To remove your reproduction container:
Discussion #69 reports an Auto Scaling launch-template path. This report isolates the separate
AWS::EC2::InstanceCloudFormation path.All reactions