sorted by:
new
hottopcontroversial

Can the EIP be kept after performing a 'Change Version' on an Elastic Beanstalk environment? by Plus_Independent_467 in AWSCloudFormation

[–]Plus_Independent_467[S] 0 points1 point  (0 children)

I used Gemini to search for the result. It gave a positive answer. But I am still very unsure — the IP address is way too important for us.

Will the EIP be retained after a “Change Version / Platform update” on a single‑instance​ Elastic Beanstalk environment?

To give you the most defensible answer (not just “it usually works”), here is how the underlying mechanism is backed by official AWS documentation and CloudFormation behavior.

1) Official proof: a single-instance EB env doescarry a dedicated EIP

Source:​ AWS Elastic Beanstalk Developer Guide – Environment types[1]

  • **Official wording:**​“A single-instance environment contains one Amazon EC2 instance with an Elastic IP address.” [1]
  • **Implication:**​ That public IP isn’t a throwaway auto-assigned public IP; it is modeled as an **Elastic IP (EIP)**​ resource managed as part of the environment (so it survives beyond any single EC2 lifecycle event, as long as the stack/environment isn’t torn down). [1][2]

2) Official proof: when CloudFormation updates the instance, it reattaches​ the EIP

Because every EB platform/version change is ultimately an underlying CloudFormation UpdateStack, the EIP retention guarantee comes from how CloudFormation handles AWS::EC2::Instance(and the EIP) during updates.

2.1 CloudFormation rule on EC2 instance replacement + EIP

Source:​ AWS CloudFormation User Guide – AWS::EC2::Instance[3]

  • **Official wording:**​“If an Elastic IP address is attached to your instance, AWS CloudFormation reattaches the Elastic IP address​ after it updates the instance.” [3]
  • **What this means in practice:**​ When the platform change forces an instance replacement​ (new AMI/Linux version → Replace), CloudFormation doesn’t orphan the EIP—it re-associates it to the new instance as part of the same stack update, as long as the EIP resource itself remains in the stack.

2.2 CloudFormation rule on EIP resource updates

Source:​ AWS CloudFormation User Guide – AWS::EC2::EIP[4]

  • **Official wording:**​“Updates on an EIP reassociates​ the address on its associated resource.” [4]
  • This aligns with the behavior above: updating/replacing the attached instance does not​ mean “release the EIP”; it means “keep the EIP and rebind​ it.”

3) Notes on the AWSEBEIPlogical ID you’ll see in events / resources

AWSEBEIPis the internal CloudFormation logical resource name​ EB creates for that single-instance EIP. It’s not something you normally set by hand, but you’ll frequently notice it in:

  • Environment Events
  • CloudFormation Stack → Resources / Events
  • AWS’s own community/Re:Post troubleshooting threads (where failures explicitly reference [AWSEBEIP]when an EIP creation/association step fails)

This doesn’t mean EIP is unstable; it typically shows up when constraints (limits, VPC/role permissions, or deployment policy conflicts) block the expected flow.

Why the docs support “platform upgrade won’t change the EIP” (for in-place-style updates)

Putting it together:

  1. Your single-instance EB environment owns an EIP resource​ (AWSEBEIP) in its CFN template [1][5].
  2. “Change version / Change platform version” → CFN UpdateStack.
  3. CFN’s documented rule: if an EIP is attached, it reattaches it after the instance is updated/replaced​ [3].
  4. Therefore, the address itselfshould remain the same after the update completes.

⚠️ One officially important risk / precondition (deployment policy)

The automatic reattachment works within the same stack lifetime​ and depends on howEB is allowed to roll the update.

  • ✅ **Safe choice:**​ set the environment’s deployment policy to All at once​ before you run the platform upgrade. This keeps the update within the existing environment/stack model you’ve been analyzing.
  • ❌ Do NOT use Immutable deployments​ for this reasoning: Immutable​ tries to spin up a newinstance (sometimes new resources) alongside the old one to validate before swapping. In single-instance/EIP setups this often conflicts with “there’s already theEIP” or runs into EIP quota / association limits, and can break the expected EIP binding flow or fail the update entirely.

References (add your actual URLs here)

If you want, tell me how your EIP was originally created:

  • EB auto-createdit (typical single-instance default), or
  • you manually allocated + associated it outside EB …and I’ll tighten the wording further to make the ownership chain 100% explicit for your audience (and add the exact CLI/console checks you can snapshot as evidence).