Optimize AWS with the Instance Scheduler – Part II

Disclaimer: This is a personal weblog. The opinions expressed here represent my own and not those of my employer.

AWS Instance Scheduler Architecture

Part I of this multi-part blog series focused on the AWS Instance Scheduler solution walked through the initial setup and configuration. This blog will illustrate the steps to take when deploying the solution within a child account which is part of an AWS Organization.

Launching the Remote Stack within a Child Account

There are a few different ways to launch the remote CloudFormation stack within the child AWS account. There’s the not so fun manual way which will launch the CloudFormation section of the AWS Management Console. In order for the deployment to occur in the child account, the Console will need to be logged into this account with necessary privileges in place. Within the stack a parameter input for the Master Account is required.

Launch the Remote Stack within the child AWS account
Create Stack Wizard (Manual = NO FUN!)

Alternatively scripting languages may be utilized. My personal preference is PowerShell (…sorry, strong Windows background here). Included below is a short snip-it of code that can be utilized. Regardless of the scripting language of choice (use what the most comfort is with) this is the recommended method as it does not require logging into the AWS Console and is able to be driven from the CCoE for instance when the AWS account is provisioned.


Completed Instance Scheduler Template Deployment

Grab the Created IAM Role

Within the IAM section of the AWS Console grab the ARN of the newly created InstanceScheduler Role and then within the Master Account CloudFormation Template, update the stack with this new ARN.

Alternatively you may use scripting languages to perform these actions. I have below a snip-it of PowerShell which can be used to perform these exact steps. The piece still being worked out is passing all the gathered data to Update-CFNStack. The current issue I am having is related to the CrossAccountRoles Parameter and will update the script below to include once worked out.

Now when viewing the DynamoDB StateTable within the Master Account we can see below that it is now updated with 3 accounts and not 2 like before.

Updated DynamoDB Table with new Account States

Wrap-Up

This post focused on showing how to deploy the AWS Instance Scheduler within a child AWS account. This allows centralization of cost and resource optimization exercises. The account level admins and users ultimately hold the responsibility of making sure that resources are tagged correctly. There are however, reports and controls (ie – Trusted Advisor & Cost Explorer) should be leveraged on a regular basis. In conclusion, users are able to tag their resources and have them automatically contro

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: