Is there a difference between aws:autoscaling:updatepolicy:rollingupdate:RollingUpdateType:Immutable and aws:elasticbeanstalk:command:DeploymentPolicy:Immutable?

Yes, there is a difference between the two configuration options you mentioned, although they are related and both contribute to implementing immutable updates in Elastic Beanstalk.

The aws:autoscaling:updatepolicy:rollingupdate:RollingUpdateType:Immutable setting is specifically for configuring how Auto Scaling group updates are handled. When set to "Immutable", it ensures that changes to the Auto Scaling group configuration (like instance type changes) are performed using an immutable update strategy.

The aws:elasticbeanstalk:command:DeploymentPolicy:Immutable setting, on the other hand, is a more general configuration that applies to application deployments and other environment updates. When set to "Immutable", it ensures that all deployments and updates use the immutable update strategy.

Regarding the behavior you're observing with the extraneous third instance, this is actually expected behavior for immutable updates in Elastic Beanstalk, especially when you have multiple instance types specified and are using Spot instances.

Here's what's likely happening:

1. Elastic Beanstalk creates a new temporary Auto Scaling group for the immutable update.
2. It launches a new instance (t4g.medium) in this group, likely because it's the first available instance type that meets the criteria.
3. Once that instance is up, Elastic Beanstalk then launches the preferred instance type (m8g.medium) in the same temporary group.
4. After the m8g.medium instance passes health checks, Elastic Beanstalk terminates the t4g.medium instance.
5. Finally, it moves the new m8g.medium instance to the original Auto Scaling group and terminates the old m8g.medium instance.

This behavior is a result of the immutable update strategy combined with your configuration for multiple instance types and Spot instances. The temporary t4g.medium instance is part of Elastic Beanstalk's process to ensure a smooth, zero-downtime update while also trying to optimize for cost and availability based on your instance type preferences and Spot instance usage.

To potentially reduce the likelihood of seeing the temporary t4g.medium instance, you could try listing the m8g.medium instance type first in your InstanceTypes configuration. However, the behavior you're seeing is generally working as designed for immutable updates and isn't necessarily a problem, even though it might seem inefficient.
Sources
Immutable environment updates - AWS Elastic Beanstalk
Deployment policies and settings - AWS Elastic Beanstalk
Seamless Production Deployment with Elastic Beanstalk | .NET on AWS Blog
Configuration changes - AWS Elastic Beanstalk

Yes — there is a difference between the two settings:

aws:autoscaling:updatepolicy:rollingupdate:RollingUpdateType = Immutable This controls how the Auto Scaling Group (ASG) updates its configuration (e.g., launch config or template changes). When set to Immutable, it creates a new temporary ASG with the updated config and shifts traffic only after instances are healthy. This prevents in-place instance replacement and helps avoid deployment failures.

aws:elasticbeanstalk:command:DeploymentPolicy = Immutable This controls the Elastic Beanstalk application version deployments. When set to Immutable, EB provisions an entirely new set of instances in a temporary environment, deploys the app there, then swaps them in only if they're healthy — avoiding downtime.

Why You’re Seeing Three Instances With both policies set to Immutable and a multi-instance-type Spot config, the behavior you’re seeing is expected:

A new instance is launched in the temporary ASG (e.g., t4g.medium) — likely because it’s cheaper or more readily available.

EB realizes it prefers m8g.medium (per your InstanceTypes list) and spins one up.

Once the new m8g.medium is healthy, the temporary t4g.medium is terminated.

Finally, the original instance is replaced, completing the immutable deployment.

Tip: To guide EB toward using m8g.medium first, put it first in the InstanceTypes list — order matters for Spot prioritization.

Summary RollingUpdateType: Immutable = protects ASG updates

DeploymentPolicy: Immutable = protects app version deployments

Temporary/extra instances = part of EB’s zero-downtime and fault-tolerant deployment strategy

You’re not doing anything wrong — this is standard behavior under these combined settings, especially with Spot and multiple instance types involved.