Architecture Overview - Ops Automator

Architecture Overview

Deploying this solution with the default parameters builds the following environment in the AWS Cloud.


        Ops Automator solution architectural overview

Figure 1: Ops Automator architecture

This solution includes an AWS CloudFormation template that must be deployed in the primary account. For guidance on choosing a primary account, refer to the Security section. This template launches all solution components, including a set of microservices (AWS Lambda functions) that manage triggering events, resource selection, task execution, concurrency control, and completion; Amazon DynamoDB tables that store task-related data; Amazon CloudWatch for logging and metrics collection; Amazon Simple Notification Service (Amazon SNS) for event forwarding and notifications; Amazon Simple Queue Service (Amazon SQS) for logging; and Amazon Simple Storage Service (Amazon S3) for task output.

The primary template automatically generates additional AWS CloudFormation templates in an Amazon S3 bucket. These templates allow you to create cross-account AWS Identity and Access Management (IAM) roles to perform actions in secondary accounts, and to forward events. You can modify and build upon these templates to create custom actions that extend the solution’s functionality. The solution also includes additional templates that you can use as references to configure and combine multiple task stacks to create end-to-end scenarios that handle complex tasks, such as vertical scaling for Amazon Elastic Compute Cloud (Amazon EC2) instances.

During initial configuration of the primary AWS CloudFormation template, you define a tag key which you use to identify resources that will receive automated actions. When you deploy a task template, the stack name you specify is used as one or more tag values that identify the tasks you want the solution to perform on the tagged resource. For example, a user might assign the custom tag name (tag key) OpsAutomatorTaskList and create a task stack called Delete7 that deletes a resource after seven days. To identify the resource for deletion, the user adds the OpsAutomatorTaskList tag key with a value of Delete7.

Or, you can use a tag filter expression to specify the tasks you want to perform on resources. The expression overwrites the selection of resources based on the values in the OpsAutomatorTaskList tag key. A tag filter expression enables a more granular selection of resources. Tag filter expressions allow the use of wildcards, regular expressions, and Boolean operators for tag names and values. For more information, refer to Appendix D.

You can also configure tasks to send all started and ended actions to an Amazon SNS topic, and to send detailed metrics to Amazon CloudWatch Metrics.

Task Execution Process

The automated process begins when either a time-based, interval-based, or event-based trigger invokes the solution’s scheduler Lambda function. The scheduler checks the task configuration to determine which tasks must be run. Based on the metadata from the action that is configured for the task, the scheduler runs one or more Lambda functions that use tags to identify and select resources across accounts and regions. Then, the scheduler creates task execution items, and starts one or more Lambda functions that implements the logic of the action on the resource or resources. Most actions contain completion logic. If the action contains completions logic, the framework periodically calls this logic to check whether the execution step has completed. The framework continues to continue to do this until the logic of the action decides that the action is complete or the action has timed out.


          Task execution process

Figure 2: Task execution process