Use AWS Control Tower lifecycle events to automate configuration of AWS accounts for ServiceNow IT operations management

Several organizations that I work with use ServiceNow’s IT Operations management capabilities for their on-premises infrastructure and want to leverage the same capabilities for their AWS environment as well. Some of the core capabilities of ServiceNow’s IT Operations management are ServiceNow Discovery, Event Management and Cloud Management.

Currently, customers who want to enable ServiceNow’s Cloud Discovery and Cloud Management capabilities for their AWS environment have to go through several manual steps to configure and set up their AWS accounts in ServiceNow. This manual process becomes increasingly challenging for customers that use multiple AWS accounts. Automating this process improves operational efficiency while driving consistency and compliance.

AWS Control Tower is an AWS managed service that automates the creation of a well-architected multi-account AWS environment. Control Tower simplifies new account provisioning for your AWS Organization and provides life cycle events to trigger automated workflows.

In this blog post, I describe how you can use Control Tower life cycle events to fully automate the configuration of AWS accounts in ServiceNow. This solution allows customers to enable ServiceNow ITOM capabilities such as Discovery and Cloud Management for their AWS accounts created and managed by Control Tower. With this solution, customers can automatically capture configuration items (CIs) for their AWS accounts managed by Control Tower in the ServiceNow CMDB and seamlessly extend ServiceNow IT operations management capabilities for their AWS environment.

This solution can be used by customers who already have Cloud Management and Discovery subscriptions enabled in their ServiceNow environment. For customers who do not have a Cloud Management subscription, AWS offers a Service Management Connector for ServiceNow which leverages data collected by AWS Config to update ServiceNow CMDB with AWS resource information.

Solution overview

Setting up ServiceNow Cloud Discovery or Cloud Management for an AWS account in ServiceNow requires the below configuration in ServiceNow:

• Configure AWS account credentials as cloud credentials in ServiceNow.
• AWS account information added to the ServiceNow account table.
• Configure ServiceNow to discover data centers for the AWS account.
• Enable Cloud Discovery for your AWS Regions.
• Configure AWS Config to send configuration change events to ServiceNow to update the CMDB in real time.

This solution fully automates the above steps for configuring an AWS account in ServiceNow. The solution uses AWS Control Tower lifecycle events to trigger an AWS Lambda function that provisions the account in ServiceNow.

Figure 1 shows the solution architecture.

Figure 1: Solution architecture

The solution works as follows:

• The solution’s main AWS CloudFormation template performs the initial setup in ServiceNow. It creates a ServiceNowConfig CloudFormation StackSet to enable ServiceNow provisioning for member accounts in the AWS Control Tower environment.
• When a new AWS account is created through the AWS Control Tower Account Factory, a lifecycle event triggers the ServiceNowStackSetHandler Lambda function.
• The ServiceNowStackSetHandler Lambda function updates the ServiceNowConfig StackSet to start the configuration of the new account in ServiceNow.
• The ServiceNowConfig stack instance runs in the new account and triggers the ServiceNowConfigFunction Lambda function to start the configuration of the AWS account in ServiceNow.
• AWS Config events for the new account are aggregated in the audit account and sent to ServiceNow. ServiceNow uses the event information to update the CMDB for resource configuration changes.
• If Amazon CloudWatch integration is enabled, then the ServiceNowConfig stack creates an Amazon SNS topic with a subscription to ServiceNow Event Management to enable processing of CloudWatch alarms in ServiceNow for alert and incident management.
• At a set schedule, ServiceNow performs discovery for AWS resources in the new account and populates its CMDB.

Prerequisites

In this post, I assume that you have access to the AWS Control Tower management account. You deploy the solution to the AWS Control Tower management account and use the AWSControlTowerExecution role. I also assume that you have ServiceNow Discovery, Cloud Management, and Event Management subscriptions and have enabled those plugins on your ServiceNow instance. If you do not have these subscriptions, you can use the AWS Service Management Connector for ServiceNow to track AWS resources in the CMDB.

Before you deploy the solution, gather the following information.

• The endpoint URL for your ServiceNow cloud instance. If you do not have a ServiceNow instance, you can request a developer instance through the ServiceNow Developer page. If you are using ServiceNow developer instance, please ensure you have the Discovery, Cloud Management and Event Management plugins enabled and have also installed the Discovery and Service Mapping patterns.
• A ServiceNow MID Server to perform discovery in the AWS environment. You can use an existing MID Server as long as it has network connectivity to AWS API endpoints (*.amazonaws.com). If you do not have a MID Server, see Set up MID Servers to connect Cloud Management to an AWS account in the ServiceNow documentation. MID Server should have Cloud Managment and AWS capabilities enabled.
• The credentials of a ServiceNow user who has permissions to make REST API calls to ServiceNow, specifically to the Table API, Discovery API, and Cloud Management APIs and, if you’re enabling alerts in CloudWatch, cloud event integration API. If you don’t have a user provisioned, you can create one by following the steps in Getting started with the REST API in the ServiceNow documentation.
• An Amazon Simple Storage Service (Amazon S3) bucket to host the Lambda package and to upload the CloudFormation template for ServiceNow configuration in new accounts. You can use an existing bucket or you can create one. Make a note of the bucket’s name because you will use it later in this blog post to upload resources. The S3 bucket must be in the same AWS Region in which you plan launch AWS CloudFormation and it must be in a Region where AWS Control Tower is available.
• Clone this GitHub repo or download the ZIP file and unzip the contents on your local machine. The repo contains a CloudFormation template that creates all the solution components.

Solution steps

The solution includes three CloudFormation templates and sample code for a Lambda function that configures the AWS account in ServiceNow.

The templates are located in the cloudformation/templates folder in the solution repo.

• master-account-setup.yaml: This is the main CloudFormation template for this solution. It deploys the solution components in the AWS Control Tower management account.
• servicenow-setup.yaml: This template deploys the required components to enable ServiceNow discovery and event management in accounts managed by AWS Control Tower. This template is deployed to AWS Control Tower accounts using a StackSet created in the AWS Control Tower management account.
• aws-config-servicenow-integration.yaml: This template configures the streaming of AWS Config events to ServiceNow, so that ServiceNow can update its CMDB with resource information in real time.

Package the Lambda code

In this solution, we provide you with sample code for Lambda function that configures AWS account in ServiceNow. You can clone the GitHub repo to tailor the code to your needs. The Lambda function is written in Python, but is too large to be included inline in the CloudFormation template. To deploy it, you must package it.

Download the code or clone the GitHub repo. If you downloaded the zip rename the file to aws-control-tower-servicenow-itom-integration.zip and then decompress it. Open a command prompt. Navigate to the folder into which you extracted the ZIP file or cloned the repo and run cd src to change to the subfolder. There is a package script in the folder that creates a zipped package for the two Lambda functions provided in this solution. Choose the script appropriate for your operating system.

`./package.sh`

`./package.ps1`

The package script creates a ZIP file for the two Lambda functions and copies them under the lambda-zip folder. After you run the script, confirm that the ZIP files appear in this folder.

Deploy the solution

Upload the aws-control-tower-servicenow-itom-integration folder to the S3 bucket that you identified in the Prerequisites section. This folder contains the master-account-setup.yaml template, which deploys two Lambda functions. The source for the Lambda function is located in the repo under the src folder. You packaged these functions in ZIP files that can be found under the lambda-zip folder. When you upload the aws-control-tower-servicenow-itom-integration folder to the S3 bucket, the Lambda ZIP files are uploaded there, too.

Use the master-account-setup.yaml to create an AWS CloudFormation stack.

1. Open the AWS CloudFormation consle.
2. Confirm that your console session is in the same AWS Region as the S3 bucket in which you stored the code.
3. Choose Create Stack, and then choose With new resources (standard).
4. On the Create Stack page, under Specify template, choose Upload a template file.
5. Select Choose file, and then choose the master-account-setup.yaml template file in your local folder (cloudformation/templates).
6. Choose Next.
7. On the Specify Stack Details page, enter a name for your stack (for example, ServiceNowSetupMainStack).
8. Under Parameters, enter these values for the following parameters:
   • pServiceNowUrl: The URL for your ServiceNow instance.
   • pServiceNowAPIUserName: The user name for the ServiceNow user who has access to the ServiceNow REST API.
   • pServiceNowAPIUserPassword: The password for the ServiceNow user who has access to the ServiceNow REST API.
   • pConfigureExistingAccounts: The existing AWS accounts in ServiceNow.
   • pSolutionS3Bucket: The name of the S3 bucket used for hosting the solution content.
   • pOrganizationUnitsToConfigure: The AWS Organizations unit IDs to configure in ServiceNow. If you leave this blank, all accounts in AWS Organizations will be provisioned in ServiceNow.
   • pServiceNowCloudWatchAlertIntegration: Set to enable CloudWatch alert integration with ServiceNow.
9. On the Configure stack options page, you can add tags or choose other options, if you like and then choose Next.
10. On the Review page, validate your parameters, select the check box to acknowledge that IAM resources will be created, and then choose Create stack.

Now launch the AWS CloudFormation stack that integrates AWS Config data with ServiceNow.

AWS Config captures configuration changes to resources in your AWS environment. This data can be sent to ServiceNow to have ServiceNow update the CMDB in real time. In this step, you deploy a CloudFormation stack that enables AWS Config events to be sent to ServiceNow. Since AWS Control Tower aggregates AWS Config data in the audit account, you must deploy this CloudFormation stack in the audit account.

1. Sign in to the Audit account and open the AWS CloudFormation console.
2. Confirm that your console session is in the same AWS Region as the S3 bucket in which you stored the code.
3. Choose Create Stack, and then choose With new resources (standard).
4. On the Create Stack page, under Specify template, choose Upload a template.
5. Select Choose file, and then choose aws-config-servicenow-integration.yaml.
6. Choose Next.
7. On the Specify Stack Details page, enter a name for your stack (for example, AWSConfigServiceNowIntegration).
8. Under Parameters, enter values for the pServiceNowEndpoint, pServiceNowUserName, pServiceNowUserPassword parameters based on the information you gathered earlier.
9. On the Configure stack options page, you can add tags or choose other options, if you like and then Choose Next.
10. On the Review page, validate your parameters, select the check box to acknowledge that IAM resources will be created, and then choose Create stack.

Watch it in action

The master-account-setup.yaml creates the following required components:

•  An AWS Secrets Manager secret to store ServiceNow API user credentials.
• An IAM user in the management account with ViewOnly access and permissions to assume the servicenow-discovery role in the member account. This credential is configured in ServiceNow to enable ServiceNow to perform discovery in the management and member accounts.
• An AWS Secrets Manager secret to store the security credentials for the IAM user in the management account.
• A Lambda function (ServiceNowAcctSetupHandler) to enable the provisioning of the management account and member accounts in ServiceNow for ServiceNow Discovery.
• A Lambda function (ServiceNowStackSetHandler) to process AWS Control Tower lifecycle events and provision the new account in ServiceNow using StackSets. This Lambda function provisions existing accounts in ServiceNow, too.
• A CloudFormation custom resource to perform the initial setup in ServiceNow. This involves setting up ServiceNow with the management account credentials, creating a discovery schedule, configuring the discovery role, and configuring the management account in ServiceNow.
• A CloudFormation custom resource to create a StackSet in the AWS Control Tower management account to configure existing and new member accounts in ServiceNow.

After the stack has been deployed in the AWS Control Tower management account, sign in to your ServiceNow instance and open the Service Accounts page.

1. In Service Accounts, you will see the AWS Control Tower management and the member accounts configured for ServiceNow Discovery.

Figure 2: Service Accounts

2. Go to Discovery Schedules and confirm that AWSDiscoverySchedule appears. Select the schedule and then choose Discover Now.

Figure 3: Discovery Schedules

3. Under Discovery, go to Home, and then choose View Schedules to see the summary of AWS resources from the member account that the discovery process populated in the CMDB. You might have to wait for few mins for the discovery schedule to finish its execution before you see the resources.

Figure 4: Discovery summary

To look up resources in a specific account, go to Service Accounts, and then choose the account you’re interested in. Scroll down on the account page and choose Datacenter (the AWS Region where you deployed the solution). On the page that opens, you can see AWS resources in the account that the ServiceNow discovery process has populated in the CMDB.

Figure 5: Service Accounts page showing resource summary

4. If you enabled the AWS Config integration with ServiceNow, the aggregated AWS Config data from your AWS Control Tower accounts will be sent to ServiceNow. This makes it possible for ServiceNow to update the CMDB in real time.

To test this integration, create a test EC2 instance in one of the AWS accounts configured in ServiceNow. Sign in to your ServiceNow instance and navigate to Service Accounts. Choose the AWS account where you created the EC2 instance and select the appropriate data center for that account.

Figure 6 shows the page where you can see the newly created EC2 instance on the Virtual Machines tab.

Figure 6: Service Account showing two VMs

5. If you deployed the solution’s main stack with the option to enable CloudWatch alert integration with ServiceNow, then an SNS topic is created in each member account with a subscription to send CloudWatch alarms to ServiceNow for incident management. The name of this SNS topic is cloudwatch-alert-servicenow-intg. You can configure CloudWatch alarms to send the alarm action to this SNS topic, which will trigger ServiceNow to create an incident.

Figure 7 shows an example of an EC2-based WebServer CPUUtilization alarm that is sent to the SNS topic.

Figure 7: CloudWatch alarm details

After ServiceNow receives the CloudWatch alarm event, it processes the event and creates an incident in ServiceNow, as shown in Figure 8. You can see that the incident is associated with the WebService CI in the ServiceNow CMDB.

Figure 8: ServiceNow event details

Figure 9 shows the newly created incident is associated with the Webserver1 configuration item in the CMDB.

Figure 9: ServiceNow incident details

Clean up

To clean up ServiceNow configuration and components deployed by the main AWS CloudFormation stack deployment, use the AWS CloudFormation console or AWS CLI to delete the CloudFormation stack. When you delete the CloudFormation stack, the AWS accounts, including the management account, are removed from ServiceNow. After you delete the main CloudFormation stack from the AWS Control Tower management account, sign in to the audit account and delete the AWS Config ServiceNow integration stack. This will stop AWS Config data from being sent to ServiceNow.

Conclusion

In this post, I demonstrated how to use AWS Control Tower lifecycle events to enable and configure ServiceNow Cloud Discovery in AWS accounts managed by AWS Control Tower. I also showed you how to enable AWS Config in an AWS Control Tower environment to auto populate the ServiceNow CMDB. Lastly, I showed you how to enable CloudWatch to send alerts and generate incidents in ServiceNow.

By using this solution, you can eliminate the manual tasks needed for enabling ServiceNow’s IT Operations Management capabilities for AWS accounts created and managed by AWS Control Tower and completely automate that process. This helps you to quickly enable ServiceNow’s ITOM capabilities for existing AWS accounts while ensuring that any new accounts created within the control tower environment will automatically be enabled for those capabilities thus helping drive consistency and improving compliance for enterprise ITSM standards.

About the Author