-
Notifications
You must be signed in to change notification settings - Fork 3
2._Use_Cases
Because awsm was designed from the start for small teams, that meant making it easy for anyone to launch AWS services in a repeatable and predictable way into any AWS Region. All of the options commonly needed to configure an EC2 instance or many other AWS services are grouped into Classes and saved in the awsm SimpleDB. This makes launching a new dev server as simple as: $ awsm launchInstance dev 10 us-west-2a
By introducing the familiar concepts of propagation, rotation, and retention - awsm can automate the work involved with moving and managing things like EBS Volumes, AMI's, and Launch Configurations. If enabled, when you create a snapshot, image, or launch configuration - awsm will automatically copy it to the region(s) of your choice and/or look for older versions of that data to rotate. Snapshots and images that are used in Launch Configurations are never touched, of course.
Since launch configurations can be easily set up to propagate to multiple regions, making changing to redundant auto-scaling groups across multiple regions is a snap.
By grouping configuration settings into Classes, you can reference different types of Classes in interesting ways to match your workflow and create a custom assembly line to move your data around.
For example:
-
AMI classes can be linked to a specific EC2 Instance ID, to create sequential AMI's. Instance classes, and launch configuration classes reference can be linked to specific AMI classes, and use the latest available AMI of that class to create the new Instance.
-
EBS snapshot classes can be linked to a specific Volume ID, to create sequential snapshots. Volume classes can be linked to specific EBS snapshot classes, and use the latest available snapshot of that class to create the new Volume.
We're about ready to get our hands dirty, head over to the Getting Started guide to install and configure awsm.