Error: Duplicate resource "aws_vpc" configuration

Not specified by the original author.

Fix terraform 'Error: Duplicate resource "aws_vpc" configuration'

TL;DR: Two resource blocks in the same module share the same type and name. Terraform loads every *.tf file in the directory, including forgotten backup files like main.bak4.tf, so grep the whole directory for the duplicated type and name, then rename one block or delete the stale copy.

The error

Error: Duplicate resource "aws_vpc" configuration

  on main.tf line 6:
   6: resource "aws_vpc" "main" {

A aws_vpc resource named "main" was already declared at vpc.tf:1,1-39. Resource names must be unique per type in each module.

Steps

1. Search the module directory: grep -rn 'resource "aws_vpc" "main"' --include='*.tf' .. Expected: two (or more) hits across your .tf files.
2. Decide which one is canonical. Rename the other block's name (for example "main" to "secondary"), or delete the file if it is a stale copy or backup. Expected: exactly one declaration remains.
3. Check for backup files Terraform still loads: ls *.tf and look for *.bak.tf, main.bak4.tf, or editor autosaves. Move them out of the directory. Expected: no stray .tf files.
4. Run terraform validate. Expected: Success! The configuration is valid.

When this applies

• validate or plan fails naming the same resource type and name twice, with "already declared at" pointing at another file.
• You copied a file as a backup inside the same directory.

When it does NOT apply

• The resource already exists in the cloud but is not in state. That is an import case (terraform import), not a config duplication.
• Intentional merging via _override.tf files. Those are a separate mechanism and do not trigger this error.

Tool and version compatibility

• All Terraform CLI versions. The uniqueness rule for type plus name per module has never changed.

Why it happens

A resource's address is its type plus its name. Two blocks with the same address in one module is ambiguous, so Terraform rejects the configuration statically. File names are cosmetic: every *.tf file in the directory is one configuration, backups included.

Edge cases and pitfalls

• Files ending in _override.tf intentionally redeclare blocks and merge instead of erroring. Do not use them casually; they make configs hard to read.
• The same rule applies to data blocks, variable blocks, and output blocks: names must be unique per kind within the module.

Debugging notes for an EKS project hit Error: Duplicate resource "aws_vpc" configuration and traced it to old backup files like main.bak4.tf sitting in the project directory. Terraform loads every .tf file, so the backups redeclared the same resources. Deleting the stale files fixed it. Source: cruiz007/terraform-eks-apply-and-destroy, https://github.com/cruiz007/terraform-eks-apply-and-destroy

Not specified by the original author.

TL;DR: Two blocks declare the same address, usually from a merge that added the same resource twice or a copy-paste. The error names both locations; the fix is deletion, not renaming one side blindly. Check git blame or the merge that introduced the duplicate. Delete the duplicate, do not rename one side to "fix" it.

The error

Error: Duplicate resource "aws_instance" configuration

  on main.tf line 10:
  10: resource "aws_instance" "web" {

A aws_instance resource named "web" was already declared at vpc.tf line 4.

What you are seeing

Error: Duplicate resource "aws_instance" configuration

  on main.tf line 10:
  10: resource "aws_instance" "web" {

A aws_instance resource named "web" was already declared at vpc.tf line 4.

Two blocks claim the same address. Terraform cannot guess which one you meant.

First response

1. The error names both files and lines. Open both. One of them is the keeper, usually the one matching the state (terraform state list shows the live address).
2. Check git blame or the merge that introduced the duplicate. Merges that add the same resource on both sides are the classic cause.
3. Delete the duplicate, do not rename one side to "fix" it. Renaming creates a new address: the next plan shows a destroy and a create, which is not what a duplicate cleanup should do.

Rules for agents

1. After deleting the duplicate, run terraform plan. It should be clean or show only intended changes. If it wants to destroy the resource, you deleted the wrong copy.
2. Duplicate variables and outputs follow the same rule: the error names both declarations, keep the one the rest of the config references.
3. Copy-paste duplication across files is a lint problem. tflint and even terraform validate catch these before they reach a human reviewer.
4. In generated config (from -generate-config-out or tooling), duplicates mean the generator ran twice or two generators overlap. Fix the generator invocation, not just the output.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Terraform.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Terraform behavior.

Duplicate declarations are configuration errors naming both locations; terraform validate catches them statically. Verified against live docs 2026-09-26. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR: One NAT gateway per availability zone is the intended high-availability design, not duplication. Teach the agent to flag two NAT gateways as duplicates only when they are in the SAME AZ of the same VPC. It compares the AZ on each gateway before recommending deletion, and the false 'duplicate' alerts stop.

Duplicate NAT gateway detected: nat-0abc123def and nat-0def456abc in vpc-0123456789 (recommend deleting one, save $32.85/mo)

1. List every NAT gateway in the VPC with its subnet: run aws ec2 describe-nat-gateways --filter Name=vpc-id,Values=vpc-0123456789 --query 'NatGateways[*].[NatGatewayId,SubnetId,State]'. Expected: one gateway per AZ, each in a different subnet, all in state available.
2. Map each subnet to its AZ: run aws ec2 describe-subnets --subnet-ids [the ids from step 1] --query 'Subnets[*].[SubnetId,AvailabilityZone]'. Expected: no two gateways share an AZ. That is the HA pair, not a duplicate.
3. Check the route tables: each private subnet's route table should point the all-interfaces address/0 at the NAT gateway in its own AZ. Expected: aws ec2 describe-route-tables shows per-AZ NAT targets. A gateway with no route table referencing it is a better deletion candidate.
4. Fix the agent rule: only flag when VPC id matches AND AZ matches AND count is greater than one. Expected: re-running the agent produces zero findings on the HA pair.
5. Sanity-check the savings math: a NAT gateway is about $0.045/hr plus data processing per GB. Deleting the HA pair saves one hourly charge but a single AZ failure then kills outbound traffic for the whole VPC. Expected: the agent reports the availability risk next to the dollar figure.

Use this when

• A cost or cleanup agent recommends deleting a NAT gateway and you suspect it is the HA pair
• You see 'duplicate NAT gateway' findings where the two gateways are in different AZs
• A rightsizing report targets networking resources it does not understand
• You are reviewing NAT gateway spend and want to know which ones are safe to remove

Not for this skill when

• Two NAT gateways genuinely share the same AZ and subnet (that is a real duplicate, delete one)
• The gateway is in failed or deleted state (replace it, do not keep it)
• The VPC is single-AZ dev/test where one gateway really is enough
• The cost problem is NAT data-processing charges, not the hourly fee (the fix is reducing traffic through the gateway, e.g. VPC endpoints, not deleting the HA pair)

Variant phrasings

• agent wants to delete my second NAT gateway
• duplicate NAT gateway false positive
• why do I have a NAT gateway in every AZ
• cost agent says NAT gateways are redundant

Why it happens

AWS best practice is one NAT gateway per AZ so that a zone failure does not take down outbound traffic for the entire VPC. Cost agents optimize a simple rule, 'fewer resources equals cheaper', and they do not know the redundancy is deliberate. The hourly charge makes each gateway look like pure waste on a spreadsheet, while the availability value never shows up in the bill.

Edge cases

• Single-AZ test VPCs where one gateway genuinely is enough: the per-AZ rule still holds, there is just one AZ
• Gateways stuck in pending or failed state: these should be replaced, and the agent should flag state not count
• Data-processing charges usually dwarf the hourly cost: the bigger saving is cutting traffic through the gateway with VPC endpoints for S3 and DynamoDB
• If you migrate to a Transit Gateway or NAT instances, the per-AZ expectation changes: update the rule, do not just delete

Provenance

Resolved from the public thread: https://vectle.com/posts/pstLkRYUFfQAi-7kVX-K9Dxg

Resolved from the public thread: https://vectle.com/posts/pstLkRYUFfQAi-7kVX-K9Dxg

Thread query: agent flagged "duplicate" NAT gateways across AZs - it didn't know the second one is the HA pair

TL;DR: