The default-vpc and all linked resources (subnets, IGW, etc.) are removed

[benoitMariaux]

Maybe an option to avoid that, what do you think?

[OwenTuz]

+1 as just got caught out by this myself - this is particularly unfortunate since the documentation suggests it won't happen:

aws-nuke/README.md

Line 153 in 928f315

eu-west-1 - EC2NetworkACL - 'acl-6482a303' - cannot delete default VPC

I'll start by raising a documentation PR to fix that, but I don't think that closes the issue as raised - I suspect it's one for the maintainers to decide whether it's worth adding/maintaining this as a new feature.

If it is accepted, I may be free to contribute some work on it.

[OwenTuz]

Scratch that, this seems to be a bug:

aws-nuke/resources/ec2-network-acls.go

Lines 41 to 47 in 592a342

	func (e *EC2NetworkACL) Filter() error {
	if *e.isDefault {
	return fmt.Errorf("cannot delete default VPC")
	}
	return nil
	}

eu-west-1 - EC2NetworkACL - acl-041a322a6f3de71d2 - cannot delete default VPC
[...]
eu-west-1 - EC2VPC - vpc-074b51ca4cd92b123 - [ID: "vpc-074b51ca4cd92b123", IsDefault: "true"] - would remove

[benoitMariaux]

Thank you for finding this.

[caj-larsson]

I assume there is no good way of avoiding removal of the default VPC then, anyone sitting on a good way to filter out the default VPC and related resources without specifying specific ID:s etc?

[svenwltr]

Hello. Sorry for the late response.

I do not yet understand the use case here. You want to preserve all linked resources of the default VPC? Even custom created ones?

Additionally the IsDefault property of the EC2NetworkACL is actually not filtering for the default VPC. The property says:

Indicates whether this is the default network ACL for the VPC.

So we have to question whether this property makes sense for aws-nuke at all.

[caj-larsson]

Actually I just would prefer to preserve the default networking structure as it was set up when the account was created, right now I'm looking at capturing it specifically every time for every account before I start provisioning.

The reason is mainly to save time on the actions on VPCs as they are relatively slow.

I have very high account turnover in my usecase :)

[OwenTuz]

Sorry, I did a bit of a drive-by on this one as I wasn't quite sure whether it qualified as a bug or was a documentation problem. This is helpful discussion above, thanks.

For background, I came across this because I had an issue with a third-party test suite which expected my default VPC to exist. There's a strong argument to be made that tests should avoid assuming things about my AWS account - but I mention it because it did highlight that people expect the default VPC, subnets and so on to be present. I wouldn't expect resources that I created to be reserved, but AWS default resources are at least more of a grey area.

So, based on the discussion above: I think it's correct behaviour that by default aws-nuke leaves no survivors. It's in the name.
However, I also think the current output is a little confusing, and that people might expect default resources to be left.

After a quick look around, it looks like there are already options to filter the default VPC and subnets (though I've not tested them):

• Ability to exclude Default VPC #188
• Add 'DefaultForAz' property for subnets #315

So I would suggest that the fix here is to:

• Change the message about ACLs to say 'not deleting default ACL' or similar instead of 'cannot delete default VPC'
• Highlight in documentation that default resources will be deleted unless aws-nuke is configured otherwise
• Add suggested config to the documentation, to demonstrate how they can be preserved

Does that make sense? Happy to add this if so.

Alternatively, if we think there's value in adding a --preserve-default-resources flag then we could bundle this up into a feature. But I'm not sure it's necessary given we already have options for doing it.

[danielrankov-mm]

Hello and thanks very much for the comments.
I would support having a "--preserve-default-resources" or alike.
That @OwenTuz said in the latest comment can be applied for EC2VPC and EC2Subnet. Yet there are more resources attached to the default VPC:
EC2InternetGatewayAttachment
EC2RouteTable
EC2DHCPOption
EC2InternetGateway

Which are going to be deleted even after we put the configuration:

    filters:
      EC2VPC:
        - property: IsDefault
          value: "true"
      EC2Subnet:
        - property: DefaultForAz
          value: "true"

If those resources (EC2InternetGatewayAttachment, EC2RouteTable, EC2DHCPOption, EC2InternetGateway) gets deleted - this is as good as deleting the whole VPC.

I would love to have an option to preserve the default VPC ( EC2VPC resource with all of the related resources: EC2Subnet, EC2InternetGatewayAttachment, EC2RouteTable, EC2DHCPOption, EC2InternetGateway)

Thank you!

[bjoernhaeuser]

Hello!

The default vpc should not really be used for anything serious, especially in infrastructure as code scenarios. It just there to make the life a bit simpler, especially when you use the web ui, but in cases where you use terraform and/or cloudformation, its recommended to setup everything, including the VPC.

That being said, we will most likely consider/accept any pull request, which adds a filter property "IsDefaultVPC" (or something similar) to all the dependent resources.

[faermanj]

@bjoernhaeuser That sounds like something i could do. Any hints where to start?

[timharsch]

last comment over a year ago, went unanswered, any updates on this? (i too ran into the unfortunate scenario where the default vpc was destroyed). I gathered from the docs that it would be safe from nuke

[XanderXAJ]

Another year and... It looks like we're close now?

I'm doing this on a personal account to stop those AWS bills -- apparently I wasn't 100% consistent when experimenting with AWS and Terraform and some resources got orphaned. Since it's a personal account I'd like to retain the default VPCs for maximum compatibility with tutorials etc.

I was looking at the nuke plan and noticed that all the default VPC resources @danielrankov-mm mentioned can now be targeted. 🎉

What about EC2DefaultSecurityGroupRule?

There's one hole: You may also want to retain resources of type EC2DefaultSecurityGroupRule which come with each VPC to determine inbound and outbound traffic access. (I've obliterated them in some regions during my testing... Whoops. 😄)

These resources only possess a SecurityGroupId:

us-west-2 - EC2DefaultSecurityGroupRule - sgr-097ea6defac5ceedc - [SecurityGroupId: "sg-01bb60ea5bf76fccf"]

So if you want to preserve them, AFAIK the resource type needs to be excluded. However, this may stop you from removing other non-default VPCs. 😞

With that said, I didn't get any EC2DefaultSecurityGroupRules when creating VPCs in Terraform for testing, so your mileage may vary. Keep an eye out. 🕵️

The (almost there) config

Even with the above caveat, this config gets us close:

# ... regions, account-blocklist, etc...

accounts:
  "<id>":
    filters:
      # BEGIN: Filter all default VPC resources
      EC2DHCPOption:
      - property: DefaultVPC
        value: "true"
      EC2InternetGateway:
      - property: DefaultVPC
        value: "true"
      EC2InternetGatewayAttachment:
      - property: DefaultVPC
        value: "true"
      EC2RouteTable:
      - property: DefaultVPC
        value: "true"
      EC2Subnet:
      - property: DefaultVPC
        value: "true"
      EC2VPC:
      - property: IsDefault
        value: "true"
      # END: Filter all default VPC resources

resource-types:
  excludes:
  - EC2DefaultSecurityGroupRule # Retain default VPC resources

If we do a test to check the filters by adding on this config:

# DEBUG: Default VPC test -- comment the previous resource-types temporarily
resource-types:
  targets:
  - EC2InternetGateway
  - EC2DHCPOption
  - EC2RouteTable
  - EC2InternetGatewayAttachment
  - EC2Subnet
  - EC2VPC

It yields the following result (across multiple regions) 🎉:

Scan complete: 51 total, 0 nukeable, 51 filtered.

I'm happy to make a PR to add this filter config to the README if you'd like. 🙂

What if I've already deleted my default VPCs?

If you've completely obliterated a default VPC, Terraform's aws_default_vpc resource creates a new default VPC and associated resources which match the above filters. 👍

Note: If you only deleted some default VPC resources, like I did EC2DefaultSecurityGroupRule, Terraform will not recreate them. Use aws-nuke to destroy the whole default VPC (Be careful as always! Also, Terraform seemed to struggle, even with aws_default_vpc's force_destroy: true), then use Terraform to recreate it. It'll recreate everything, including those EC2DefaultSecurityGroupRules. 🎉

Here's a small example of the Terraform code:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.11.0"
    }
  }

  required_version = "~> 1.5"
}

provider "aws" {
  region = "us-west-2" # Change as required
}

resource "aws_default_vpc" "default" {}

And when I tried to aws-nuke the region afterwards, using the default VPC filters:

Scan complete: 9 total, 0 nukeable, 9 filtered.

They're all filtered. 🎉 I love it when a Terraform plan comes together.

[ekristen]

I'm planning on putting together some example configurations in the new documentation on the now actively managed fork of aws-nuke

I'll make sure to include this there.

---

Please see the copy of the notice from the README about the deprecation of this project. Sven was kind enough to grant me access to help triage and close issues and pull requests that have already been addressed in the actively maintained fork. Some additional information is located in the welcome issue for more information.

Caution

This repository for aws-nuke is no longer being actively maintained. We recommend users to switch to the actively maintained fork of this project at ekristen/aws-nuke.
We appreciate all the support and contributions we've received throughout the life of this project. We believe that the fork will continue to provide the functionality and support that you have come to expect from aws-nuke.
Please note that this deprecation means we will not be addressing issues, accepting pull requests, or making future releases from this repository.
Thank you for your understanding and support.