A company is creating a software solution that executes a specific parallel-processing mechanism. The software can scale to tens of servers in some special scenarios. This solution uses a proprietary library that is license-based, requiring that each individual server have a single, dedicated license installed. The company has 200 licenses and is planning to run 200 server nodes concurrently at most.
The company has requested the following features:
- A mechanism to automate the use of the licenses at scale.
- Creation of a dashboard to use in the future to verify which licenses are available at any moment.
What is the MOST effective way to accomplish these requirements?
A. Upload the licenses to a private Amazon S3 bucket. Create an AWS CloudFormation template with a
Mappings section for the licenses. In the template, create an Auto Scaling group to launch the servers. In the user data script, acquire an available license from the Mappings section. Create an Auto Scaling lifecycle hook, then use it to update the mapping after the instance is terminated.
B. Upload the licenses to an Amazon DynamoDB table. Create an AWS CloudFormation template that uses an Auto Scaling group to launch the servers. In the user data script, acquire an available license from the DynamoDB table. Create an Auto Scaling lifecycle hook, then use it to update the mapping after the instance is terminated.
C. Upload the licenses to a private Amazon S3 bucket. Populate an Amazon SQS queue with the list of licenses stored in S3. Create an AWS CloudFormation template that uses an Auto Scaling group to launch the servers. In the user data script acquire an available license from SQS. Create an Auto Scaling lifecycle hook, then use it to put the license back in SQS after the instance is terminated.
D. Upload the licenses to an Amazon DynamoDB table. Create an AWS CLI script to launch the servers by using the parameter --count, with min:max instances to launch. In the user data script, acquire an available license from the DynamoDB table. Monitor each instance and, in case of failure, replace the instance, then manually update the DynamoDB table.
Answer: D
โ
Explanation
-Key Requirements:
Automate license use at scale โ assign one license per server automatically.
-Dashboard to verify license availability at any time โ visibility into which licenses are in use or free.
-Maximum 200 licenses for up to 200 concurrent servers.
-The licenses must be individually tracked and released when instances terminate.
-Analysis of options:
A. Using CloudFormation Mappings for licenses
Mappings in CloudFormation are static key-value pairs, not designed to be dynamically updated during runtime.
-You cannot update mappings dynamically to track license allocation and release.
-Hence, this does not support automation or dynamic tracking of licenses.
=> Not feasible for dynamic license allocation.
B. Upload licenses to DynamoDB and update using Auto Scaling lifecycle hooks
DynamoDB is a good fit for managing a dynamic inventory like licenses.
Licenses can be stored as items in the table with a status attribute (e.g., "available", "in-use").
Instances can query DynamoDB during launch (via user data) to atomically acquire a license by marking it "in-use."
On termination (via lifecycle hooks), the license can be released back to "available."
DynamoDB also supports querying and scanning, making it straightforward to build a dashboard for license availability.
C. Use SQS queue with license list and CloudFormation + Auto Scaling
Using an SQS queue to hold licenses is creative.
On instance startup, a license is received (dequeued) from SQS.
On termination, the license is returned (re-enqueued).
This naturally controls the concurrency since the number of licenses in the queue limits server licenses.
SQS does not natively support querying all license statuses (no direct way to see which licenses are in use or available).
Building a dashboard to view license availability would be complicated and would require external tracking.
SQS visibility timeouts and message processing can cause edge cases if instances fail unexpectedly.
D. DynamoDB + manual monitoring and manual license updates
DynamoDB again is good for license tracking.
-However, this option relies on manual updates to the license table on instance failures.
-Manual intervention is error-prone and not automated.
-This does not meet the requirement for automation.