Cant migrate vpc from awsx.classic.ec2.Vpc to awsx.ec2.Vpc without recreating vpc

[swwu]

What happened?

Trying to migrate from awsx.classic.ec2.Vpc to awsx.ec2.Vpc causes the VPC (and consequently, many of its child resources, such as RDS) to be destroyed and recreated.

Currently can't find a way to do this upgrade via tagging or similar that doesn't involve destroying and recreating the VPC.

Example

1. Create any awsx.classic.ec2.Vpc.
2. Change it to awsx.ec2.Vpc.
3. Observe that it deletes the VPC and creates a new one.

Output of pulumi about

CLI
Version 3.63.0
Go Version go1.20.3
Go Compiler gc

Plugins
NAME VERSION
aws 6.22.1
aws 6.22.1
aws 5.43.0
aws 5.43.0
awsx 1.0.6
awsx 1.0.6
command 0.5.2
command 0.5.2
docker 3.6.1
docker 3.6.1
nodejs unknown
random 4.15.1
random 4.15.1

Host
OS darwin
Version 12.5
Arch arm64

This project is written in nodejs: executable='/Users/swwu/.nvm/versions/node/v20.4.0/bin/node' version='v20.4.0'

Current Stack: scanner-inc/log-storage/prod-use2-1

...

Found no pending operations associated with prod-use2-1

Backend
Name pulumi.com
URL https://app.pulumi.com/swwu
User swwu
Organizations swwu, scanner-inc

Dependencies:
NAME VERSION
@aws-sdk/client-ecs 3.514.0
@pulumi/aws 6.22.1
@pulumi/awsx 1.0.6
@pulumi/command 0.5.2
@pulumi/pulumi 3.105.0
@pulumi/random 4.15.1
@scnr/pulumi_shared 0.0.1
@slack/webhook 6.1.0
@types/node 14.18.63

Additional context

We are attempting to migrate to pulumi/awsx 2.7, where it appears awsx classic is now deprecated.

Our primary database is an Aurora RDS instance inside a awsx.classic.ec2.Vpc, so we would obviously prefer that it not be destroyed and recreated when we upgrade, since it contains a bunch of important customer data. (We also have a large number of individual deployments so we'd prefer not to manually remove/replace the RDS cluster in the deployment by hand on all of them.)

This issue #1020 appears to be about the same problem; however, its solution ("use classic") doesn't seem to apply any more because classic is deprecated.

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[t0yv0]

Thanks for reporting this @swwu definitely sounds very disappointing; our team will be taking a look when we have time available. If anyone is affected by this please upvote to help us prioritize.

[mikhailshilkov]

I believe this is, unfortunately, expected. The 1.0 launch blog mentions:

Refactor to replace the classic components with the new top-level components. This may require additional code changes and resource re-creation.

Another instance where pulumi/pulumi#15633 would be very helpful.

[bohlander]

We're also running into this issue. Recreating our entire VPC is a tough pill to swallow, since we also have significant stateful resources within this VPC that we do not want to destroy. Is there any manual way to accomplish this, even if it isn't as simple as updating the code as above?

Also, it is surprising to me that this problem is not classified as a bug, but as an enhancement. If there is no path forward for existing users, that seems like a pretty clear bug to me

[ctjhoa]

I'm facing kind of similar issue for my project.
After some digging, one workaround approach you can have is to remove your vpc only from your state and re-import it as awsx resource.
Unfortunately, there is no straight path to import an awsx resource, you need preview a awsx.ec2.vpc creation to generate an import-file then use the pulumi import -f import-file.json
#1300 (comment)
I cannot entirely confirm this workaround procedure because I have a more complex subnet configuration than awsx.ec2.vpc provide by default and it will require me some time to adjust but in theory this could help other people.