Hi folks! New around here 👋 Here's a replica of an EC2 Instance with which I'm working:

const amznAmi = aws.getAmiOutput({
        filters: [{
            name: "name",
            values: ["amzn2-ami-kernel-*"],
        }],
        owners: ["137112412989"],  // NOTE: this is Amazon's Owner ID for Official Amazon-managed AMIs
        mostRecent: true,
    });

/* snip */

const instance = new aws.ec2.Instance(customName, {
        ami: pulumi.interpolate`${amznAmi.id}`,
        instanceType: "t2.medium", 
        networkInterfaces: [{
            networkInterfaceId: networkInterface.id,
            deviceIndex: 0,
        }],
        userData: userData,
        keyName: "some-key",    
        tags: {
            Name: customName
        },
        rootBlockDevice: {
            volumeSize: 400
        }
    },

This builds fine on initial stack buildouts, but whenever Amzn publishes a new Amzn Linux 2 AMI, I run into an issue where pulumi can't create the right update strategy. The AMI triggers a replacement of the EC2 Instance (see the entire preview below (with --show-replacement-steps on):

Type                 Name        Plan        Info
     pulumi:pulumi:Stack  infra-dev               1 warning
 +-  └─ aws:ec2:Instance  instance    replace     [diff: ~ami]

But there are resources that helped build that instance (like

networkInterface

) that don't get neatly detached:

aws:ec2:Instance (instance):
      error: 1 error occurred:
      	* creating EC2 Instance: InvalidNetworkInterface.InUse: Interface: [eni-<snip>] in use.
      	status code: 400, request id: <snip>

My question is: how can I best tell Pulumi what my ideal update strategy is when a field that triggers replacement (e.g.

ami

) on a resource inevitably is different? In particular with EC2, I would want Pulumi to stop the EC2 instance -> detach the NetworkInterface -> terminate the old instance -> create a new EC2 with the new AMI and current

userData

-> re-attach the NetworkInterface.

You can use the dependsOn opt, if it's not already inferred. I thought ENIs are, though...

yeah I've tried various `CustomResourceOptions`:

dependsOn

,

parent

, etc. Instead of handling that flow above, they offer this preview:

Type                         Name                    Plan       Info
     pulumi:pulumi:Stack          infra-dev                          1 warning
     ├─ aws:ec2:NetworkInterface  networkInterface
 +   │  └─ aws:ec2:Instance       instance                create
 -   └─ aws:ec2:Instance          instance.               delete

After re-reading: you can't get Pulumi to detach ENIs. There is no support for this sort of thing. You would need to do this yourself. Pulumi can delete it for you, and create a new one...

ahhhh I see! But if I hand over the mgmt of making the ENI to Amazon, Amazon will take care of it on replacement?

Yes. I've never had an issue with ENIs. They're essentially atomic within the instances.

so instead of trying something like this to give the instance an EIP: pulumi.com/registry/packages/aws/api-docs/ec2/instance/#network-and-credit-specification-example , I could instead just set something like https://www.pulumi.com/registry/packages/aws/api-docs/ec2/instance/#associatepublicipaddress_nodejs and Amazon should understand iirc

I don't see a need for an explicit ENI in that first example. And I don't see a need for a public IP address, either. If you need a specific private IP address, use

privateIp

. If you don't need a specific IP address, don't provide one, let AWS pick one for you. This is much safer.

this has been working great for me!!! thanks @little-cartoon-10569 🙂