I have a large piece of server software (3 GB of files pre-install) that is running on an EC2. The software installs a full app server or interface server that communicates with the front-end desktop GUIs and database. The software was originally designed years ago to be installed through a visual step-by-step installer off a USB drive on premises. This installer ensures that the software is set up with proper configuration, networking, connection to the database, etc. Every client gets 1 or more EC2 instances dedicated to handle their workload. Moving into a cloud-minded paradigm, what is a better way to handle creating many servers, for many clients, all with different configurations of this software? When a server goes down, or another is needed for load, what's a "cloud" practice to spin up a new server and install the same configuration of software on this server?

I have multiple ideas including:

1. Store software files in S3 bucket and pull them to the EC2 instances as necessary. A config file for each customer will also be updated and stored on S3. The EC2 will then start the software from a PowerShell script to create proper configurations.
2. Store the software in the AMI of EC2 exactly as configured. This means any time a server is created with a new client configuration, we create a new AMI after installation.
3. Create a Lambda function that can handle all the different configuration parameters. When invoked, it will take care of spinning up a server, moving the software to the server, and installing the software with proper configuration.

Any guidance or references to white papers would be appreciated.

Thank you!

CodePudding user response：

I would:

• prepare one single AMI which has the software installed along with the required configuration

• store the custom config files for the customers in a bucket

• create a launch template for each customer. this template would reference the AMI and would fetch the customer specific config file from the bucket

• create an EC2 autoscaling group for each customer. Each autoscaling group would use the specific launch template

A single AMI with the config file fetched automatically allows you to scale easily if your customer base grows. The alternative, one AMI per customer, would quickly become unmanageable.

The autoscaling group allows you to scale seemlessly if the customer required more servers, and it would take care of replacing unhealthy instances automatically.