如何确保部署AWS CDK VPC栈后Elastic IP保持不变？

你的核心问题是避免重新部署VPC栈时Elastic IP（EIP）被销毁重建，导致用户需要更新API白名单。以下是两种经过验证的最佳实践，以及对当前代码问题的说明：

一、当前代码的核心问题 #

你当前通过NatInstanceProvider创建的NAT实例，其自动关联的EIP由CDK VPC构造自动管理——当销毁并重建整个栈时，这些自动创建的EIP会被删除，重新部署时生成新的IP。额外创建的CfnEIP默认销毁策略是DESTROY，栈重建时也会被删除重建，无法保留原有IP。

二、最佳实践方案 #

1. 用独立CDK栈管理EIP（推荐） #

将EIP资源和VPC栈分离，单独部署一个EIP管理栈，VPC栈通过引用该栈的EIP资源进行关联。这样更新或重建VPC栈时，EIP栈不会被触动，IP保持稳定。

步骤1：创建独立的EIP栈

// eip-stack.js
const { Stack, CfnEIP, RemovalPolicy } = require('aws-cdk-lib');

class NatEipStack extends Stack {
  constructor(scope, id, props) {
    super(scope, id, props);

    // 创建需要的EIP实例，设置销毁策略为RETAIN防止意外删除
    this.eipResources = [];
    const eipCount = 4; // 对应1个默认NAT EIP + 3个额外EIP的需求
    for (let i = 0; i < eipCount; i++) {
      const eip = new CfnEIP(this, `NatEip-${i}`, {
        tags: [{ key: 'Name', value: `NatInstanceEIP-${i}` }]
      });
      eip.applyRemovalPolicy(RemovalPolicy.RETAIN);
      this.eipResources.push(eip);
    }
  }
}

module.exports = { NatEipStack };

步骤2：在VPC栈中引用并关联EIP

// vpc-stack.js
const { Stack, Vpc, NatInstanceProvider, InstanceType, CfnEIPAssociation, SubnetType } = require('aws-cdk-lib');
const { NatEipStack } = require('./eip-stack');

class VpcFargateStack extends Stack {
  constructor(scope, id, props) {
    super(scope, id, props);

    // 引用已部署的EIP栈
    const eipStack = NatEipStack.fromStackName(this, 'ExistingNatEipStack', 'NatEipStack');

    const natGatewayProvider = NatInstanceProvider.instance({
      instanceType: new InstanceType('t3.micro')
    });

    const vpcFargate = new Vpc(this, 'WhiteVpcFargate', {
      vpcName: 'white-vpc-fargate',
      natGateways: 1,
      natGatewayProvider: natGatewayProvider,
      maxAzs: 2,
      // 禁用VPC自动创建NAT EIP，避免冲突
      natGatewaySubnets: { subnetType: SubnetType.PUBLIC }
    });

    // 将独立栈的EIP关联到NAT实例
    natGatewayProvider.configuredGateways.forEach((nat, natIndex) => {
      eipStack.eipResources.forEach((eip, eipIndex) => {
        new CfnEIPAssociation(this, `EipAssociation-${natIndex}-${eipIndex}`, {
          instanceId: nat.gatewayId,
          eip: eip.ref
        });
      });
    });
  }
}

module.exports = { VpcFargateStack };

优势：

• 保留CDK自动化管理能力，无需手动维护EIP信息
• EIP资源独立于VPC栈，更新或重建VPC栈不会影响IP稳定性
• 如需调整EIP数量，单独更新EIP栈即可

2. 手动创建EIP后在CDK中导入关联 #

如果已经有现成的EIP（通过控制台/CLI创建），可以直接在CDK中导入这些EIP的ID，再关联到NAT实例。

const { Stack, Vpc, NatInstanceProvider, InstanceType, CfnEIPAssociation } = require('aws-cdk-lib');

class VpcFargateStack extends Stack {
  constructor(scope, id, props) {
    super(scope, id, props);

    // 手动创建的EIP分配ID列表
    const manualEipIds = [
      'eipalloc-xxxxxx',
      'eipalloc-yyyyyy',
      'eipalloc-zzzzzz',
      'eipalloc-aaaaaa'
    ];

    const natGatewayProvider = NatInstanceProvider.instance({
      instanceType: new InstanceType('t3.micro')
    });

    const vpcFargate = new Vpc(this, 'WhiteVpcFargate', {
      vpcName: 'white-vpc-fargate',
      natGateways: 1,
      natGatewayProvider: natGatewayProvider,
      maxAzs: 2
    });

    // 关联手动EIP到NAT实例
    natGatewayProvider.configuredGateways.forEach((nat, natIndex) => {
      manualEipIds.forEach((eipId, eipIndex) => {
        new CfnEIPAssociation(this, `ManualEipAssoc-${natIndex}-${eipIndex}`, {
          instanceId: nat.gatewayId,
          eip: eipId
        });
      });
    });
  }
}

优势：完全脱离CDK生命周期管理，不会被意外销毁；劣势：需要手动维护EIP ID，扩展性较差。

内容的提问来源于stack exchange，提问作者Florian Sabani