Advise on Creating a Custom AMI from an Existing Beanstalk-Managed EC2 Instance

Question

Hello,

I have an IIS application based on a Windows Server 2019 image.  It is a single EC2 instance managed by Elastic Beanstalk.  I'm looking to create a custom AMI based on this existing EC2 instance to provide the ability to auto-scale our Beanstalk environment as needed in the future.

Constraints:
- This is a production environment so I'm trying to minimize downtime - a few minutes is fine but I definitely can't have a prolonged outage
- Need to be able to retrieve passwords for the individual instances for RDP in the event that I need to view logs

I'm looking for advice on the procedures/best practices I should follow for safely doing this. For example, should I run Sysprep?  The AWS docs say not to, for a production system, but I've had issues in the past with being unable retrieve passwords for custom AMIs, and was told that it may have been due to not running Sysprep.

Thanks!

Answer

As you are currently running a single instance, beanstalk performs an in-place update when you update your application versions, and as such your application might become unavailable for a short period of time. To avoid this considered switching deployment strategies to better support future needs. For example, with a blue/green approach all you would need to do is swap the CNAMEs of the two environments to redirect to the new version instantly.

There are some caveats in that the your environment must run independently of any beanstalk provisioned database.

Refer to [Blue/Green deployments with Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)

The following [table](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html) compares deployment method properties.

| Method | Impact of failed deployment | Deploy time | Zero downtime | No DNS change | Rollback process | Code deployed to |
| --- | --- | --- | --- | --- | --- |--- |
| All at once | Downtime | * | No | Yes | Manual redeploy | Existing instances |
| Rolling | Single batch out of service; any successful batches before failure running new application version  | ** | Yes | Yes | Manual redeploy | Existing instances |
| Rolling with an additional batch | Minimal if first batch fails; otherwise, similar to Rolling | *** | Yes | Yes | Manual redeploy | New and existing instances |
| Immutable | Minimal | **** | Yes | Yes | Terminate new instances | New instances |
| Traffic splitting | Percentage of client traffic routed to new version temporarily impacted | **** | Yes | Yes | Reroute traffic and terminate new instances | New instances |
| Blue/green | Minimal | **** | Yes | No | Swap URL | New instances |

Method	Impact of failed deployment	Deploy time	Zero downtime	No DNS change	Rollback process	Code deployed to
All at once	Downtime	*	No	Yes	Manual redeploy	Existing instances
Rolling	Single batch out of service; any successful batches before failure running new application version	**	Yes	Yes	Manual redeploy	Existing instances
Rolling with an additional batch	Minimal if first batch fails; otherwise, similar to Rolling	***	Yes	Yes	Manual redeploy	New and existing instances
Immutable	Minimal	****	Yes	Yes	Terminate new instances	New instances
Traffic splitting	Percentage of client traffic routed to new version temporarily impacted	****	Yes	Yes	Reroute traffic and terminate new instances	New instances
Blue/green	Minimal	****	Yes	No	Swap URL	New instances

Advise on Creating a Custom AMI from an Existing Beanstalk-Managed EC2 Instance

Conteúdo relevante