I have some cloud resources which take a very long time to create or delete. For this reason it's best to leave these resources up between Pulumi up/down cycles. Currently I'm using the resource's tag:Name as an identifier to maintain persistence. I'm using the retain-on-delete and import_ resource options to either create a new resource or find one already created and re-use it.

try:
        vgw = aws.ec2.get_vpn_gateway(
            filters=[aws.ec2.GetVpnGatewayFilterArgs(
                name="tag:Name",
                values=[f"Vgw"],
            )], opts=pulumi.ResourceOptions(provider=provider_options)
        )
        vgw = aws.ec2.VpnGateway(f"Vgw",
                tags={"Name": f"Vgw"},
                opts=pulumi.ResourceOptions(
                    provider=provider_options,
                    retain_on_delete=True,
                    import_=vgw.id
            )
        )
    except:
        vgw = aws.ec2.VpnGateway(f"Vgw",
            tags={"Name": f"Vgw"},
            opts=pulumi.ResourceOptions(
                provider=provider_options,
                retain_on_delete=True
            )
        )

Is this is the best way to achieve this? It works but it doesn't seem particularly elegant for such a common / simple task.

RetainOnDelete will keep the resource around but the stack state loses track after a destroy

I have used protect in conjunction with programatically importing resources and it works fine. we use it to manage some repositories in github 👍

In my opinion: no, this isn't the best way to handle this. I suggest moving these resources to a different project. I find that thinking of projects as groups of related resources which share a single deployment cycle is very helpful. If your current project needs two deployment cycles, then (in my opinion) it should be two projects.

@little-cartoon-10569 I follow the same philosophy. How do you then handle these multi step deployments when you need to deploy multiple projects in a sequence? I mean programmatically? I'm thinking about using Azure Logic apps.

We use a pattern for "base infrastructure" or "shared resources" for projects that have common for base resources that "child projects/stacks" will reference via the outputs of those projects using StackReferences.

Separate Pulumi projects are very easy to deploy in a fixed sequence at initial deployment: a short script can do it, or you can use automation-api to call out to the projects. In the simplest case of just calling one project then the other, with the same stack name in both, then I recommend the simple script: automation-api brings a lot more power, but that comes at the normal cost of additional complexity.

@millions-furniture-75402 I’m tending toward this separation pattern also. But even then… reducing destroy/deploy timeframes and leaving alone “network” infrastructure / connections can be desirable