Ec2Service.ensureDefaultResources(region) stores per region correctly — key(region, vpcId) — but assigns the same id strings everywhere:
String vpcId = "vpc-default";
String[] subnetIds = {"subnet-default-a", "subnet-default-b", "subnet-default-c"};So a three-region account exposes:
us-east-1 vpc=vpc-default subnets=subnet-default-a, -b, -c
us-west-1 vpc=vpc-default subnets=subnet-default-a, -b, -c
us-west-2 vpc=vpc-default subnets=subnet-default-a, -b, -c
sg-default behaves the same way.
Real AWS never does this. VPC, subnet and security-group ids are globally unique; two regions' default VPCs have different ids. Any consumer that keys a resource by its id — the normal thing to do, since the id is the identifier — collapses three distinct resources into one.
Why it matters beyond cosmetics
It silently changes answers to questions that count resources across regions. Found while measuring a tool that snapshots an account: nine default subnets across three regions replayed as three, and a question asking how many subnets are empty came back 2 instead of 8. Nothing errored. The tool behaved correctly for ids that, on real AWS, could not have collided.
Anything aggregating account-wide is exposed: resource counts, drift detection, cost attribution, "what exists where".
Suggested fix
Derive the ids per region so they stay recognisable but unique — vpc-default-us-east-1, subnet-default-us-east-1-a — or hash the region into an AWS-shaped id. A helper (defaultVpcId(region)) would keep the four call sites in Ec2Service and the one in RdsService consistent.
Worth checking other services that seed defaults for the same pattern before fixing only EC2.
Originally filed upstream by mistake (floci-io#2097) and closed there — nothing goes upstream without a fix delivered alongside it.
Ec2Service.ensureDefaultResources(region)stores per region correctly —key(region, vpcId)— but assigns the same id strings everywhere:So a three-region account exposes:
sg-defaultbehaves the same way.Real AWS never does this. VPC, subnet and security-group ids are globally unique; two regions' default VPCs have different ids. Any consumer that keys a resource by its id — the normal thing to do, since the id is the identifier — collapses three distinct resources into one.
Why it matters beyond cosmetics
It silently changes answers to questions that count resources across regions. Found while measuring a tool that snapshots an account: nine default subnets across three regions replayed as three, and a question asking how many subnets are empty came back 2 instead of 8. Nothing errored. The tool behaved correctly for ids that, on real AWS, could not have collided.
Anything aggregating account-wide is exposed: resource counts, drift detection, cost attribution, "what exists where".
Suggested fix
Derive the ids per region so they stay recognisable but unique —
vpc-default-us-east-1,subnet-default-us-east-1-a— or hash the region into an AWS-shaped id. A helper (defaultVpcId(region)) would keep the four call sites inEc2Serviceand the one inRdsServiceconsistent.Worth checking other services that seed defaults for the same pattern before fixing only EC2.
Originally filed upstream by mistake (floci-io#2097) and closed there — nothing goes upstream without a fix delivered alongside it.