Hi folks! New around here :wave: Here's a replica...
# aws
Hi folks! New around here 👋 Here's a replica of an EC2 Instance with which I'm working:
Copy code
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):
Copy code
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
) that don't get neatly detached:
Copy code
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.
) 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
-> re-attach the NetworkInterface.
You can use the dependsOn opt, if it's not already inferred. I thought ENIs are, though...
However if you don't need to explicitly define the ENI, then you shouldn't. AWS will create and manage one for you. You can get its ID from the instance's outputs if you need it.
yeah I've tried various `CustomResourceOptions`:
, etc. Instead of handling that flow above, they offer this preview:
Copy code
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?
or it should do so anyway
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
. If you don't need a specific IP address, don't provide one, let AWS pick one for you. This is much safer.
Assuming that the only things that will connect to your EC2 instance are set up in Pulumi, just get the IP address from the created resource. You hopefully shouldn't have to define the IP address in advance.
this has been working great for me!!! thanks @little-cartoon-10569 🙂