Automate creating and onboarding applications with AWS CloudFormation tags and myApplications

Customers operate hundreds of applications and often those applications consist of hundreds to thousands of resources. This can get complex and overwhelming having to monitor and manage individual resources and identifying what resources are tied to an application while making sure their applications are available, secure, cost-optimized, and performing optimally.

The underlying concept of applications allows you to group resources and metadata. You can access all applications in your account, key metrics across all applications, and an overview of cost, security, and operations metrics and insights from multiple service consoles in a single view.

Application operations is a set of capabilities across AWS that provides a consistent approach to monitor metrics like cost, health, security posture, and performance of your applications with less effort and at scale. These capabilities weave an application-centric view across multiple AWS consoles and the myApplications dashboard, a feature of the AWS Management console, through tagging so you can easily create, onboard, or migrate new and existing applications. By having manual operations, it can be complex to scale when you have a lot of environments, applications, and teams and specifically you operate an Infrastructure as Code (IaC) model. Automating manual tasks can help with efficiency in the cloud.

In this blog post you will learn about creating and onboarding an application to myApplications using AWS CloudFormation tags. You will also learn about the Cost & usage, Monitoring & operations, DevOps widgets.

Figure 1 – Solution workflow.

Prerequisites

For this walkthrough, you should have the following prerequisites for the specific services you want to have operational data shown in the myApplications dashboard:

• Permissions to use services such as Amazon CloudWatch, AWS Cost Explorer, AWS Security Hub, AWS Systems Manager, AWS Config,  Amazon CloudWatch Application Signals, and AWS CloudFormation.
• CloudWatch Application Signals supported systems

Creating an application

A guiding principle to defining an application is the collection of resources operate as a unit and help drive a business objective. For example, if you are an ecommerce company, you might have an online website, a processing system, or subscription service that make up a business object, but those different components operate individually with their own resources. This could mean that there are multiple components that make up a bigger application.

Once you have an understanding of resources make up your application then you can start operating in an application-centric view by using myApplications and supported services.

Currently, myApplications uses a unique tag key value (awsApplication) to add the resources to an application when you create an application. If you are using IaC tools to deploy an application workload, you can add the awsApplication tag to the CloudFormation stack.

Getting started with IaC is a two-step process, the first step is to create the application, the second step is to add resources. Through the create application workflow in the Management Console, you add the awsApplication tag to an existing CloudFormation template or you can take advantage of using the provided code snippets and add it directly into your CloudFormation or Terraform applications. This would require you to create an empty application. This can get complex to scale since you would need to create an application with no resources to retrieve the code snippet ahead of time with the awsApplication tag.

In the scenario where you want to automatically create an application and add the resources without having to go through the create application workflow in the Management console, you can leverage using tags through CloudFormation.

Automatically creating an application via CFN using tags

In this example, you can create the application and its resources from a CloudFormation stack. Following will create an application named CFNTagApp and adds an EC2 instance as the application’s resource. After the creation, you can visualize the application in myApplications. No manual on-boarding is required. With this approach, you can scale creating applications with myApplications.

Resources:
  #AppRegistry application
  CFNTagApp:
    Type: AWS::ServiceCatalogAppRegistry::Application
    Properties:
      Name: CFNTagApp
      Description: "CFNTagApp application"

  #EC2 Workload for more detailed use case
  CFNTagAppEC2:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId:
        Ref: LatestEC2AmiId
      Tags:
        - Key: Name
          Value: CFNTagApp
        - Key: awsApplication
          Value: !GetAtt CFNTagApp.ApplicationTagValue

Figure 2 – Onboarded application using CFNTagApp.

Let’s dive into some of the widgets and considerations for using services that provide an application-centric view experience.

Cost and usage widget

The Cost and usage widget displays monthly spend from Cost Explorer, when it is enabled, it shows spend of your applications in myApplications. The widget provides a summary of cost information including current month costs, forecasted month end costs, and savings opportunities. It is important to remember only resources that have the AWS application tag will be tracked. Something to keep in mind is you’ll only see the spend of the resources when the application has been onboarded and not previous spends.

Customers who leverage AWS Organizations and enable AWS Cost Explorer at the organization level do not have to explicitly enable it in member accounts. Cost Explorer may already be enabled for customers based on their FinOps strategies; for new customers or those who operate multiple standalone accounts, enabling Cost Explorer is a general best practice and can be enabled through Cost Explorer console. This helps maximize the myApplications experience by providing a way to understand what an application is costing you verse looking at individual resources spend. For more information on, visit Enabling Cost Explorer.

Figure 3 – Cost associated to the application.

Leverage Amazon CloudWatch monitoring capabilities

The myApplications dashboard integrates with Amazon CloudWatch, providing you with comprehensive monitoring and operational insights. By leveraging CloudWatch alarms, application service level indicator (SLIs) and metrics through CloudWatch Application Signals, you can gain a deep understanding of your application’s health, performance, and overall operational state via the Compute widget and Monitoring and operations widget.

The Compute widget displays resource performance metric trend charts from CloudWatch for EC2 instance CPU utilization and Lambda invocations (this would only be relevant for applications that use EC2 instances or Lambda functions), total alarms, and total compute resource types for your application.

Figure 4 – Compute widget shows metrics for EC2 instances and Lambda functions.

An alarm refers to the state of a probe, monitor, or change in a value over or under a given threshold. When creating alarms there are few things to consider: 1/ Always work backwards from your objectives (alert on things that are actionable), 2/ If an alarm does not need alert you, or trigger an automated process, then there is no need to have it alert you.

Amazon CloudWatch Application Signals instruments your applications on AWS so that you can monitor the health of your application and track performance against your business objectives while providing a view of your applications, services, and dependencies, and helps you monitor and triage application health.

CloudWatch Synthetics monitoring (canaries) integrates with Application Signals. Canaries are a powerful feature that allow you to monitor endpoints and APIs using scheduled synthetic behavior that follow the same routes and perform the same actions as end users of your applications. They enable you to continually assess customer experience and discover issues before end users do.

If you are new to observability or need guidance to figuring out how to set up metrics, alarms, or develop an observability strategy, the AWS Observability Best Practices outlines how you can get started understanding the different components to observability and what metrics, alarms, etc. are beneficial to monitoring.

Figure 5 – Monitoring and operations widget showing the count of Alarms, Canary alarms, Service Level Objectives (SLO) status.

DevOps widget

The DevOps widget provides information from AWS Systems Manager and AWS Config. The information that is provided from Systems Manager provides node management and the Config evaluates the compliance status from a resource level to the rules that are deployed.

The node management information identifies if the instances are managed by Systems Manager, the patch compliance state from patch policies, and any OpsItems that are associated with the resources along with the severity level.

For an instance to be managed with Systems Manager there are three prerequisites that must be met. First, the SSM agent must be installed. Second, the SSM agent needs the necessary permissions to perform actions on the node on your behalf. You can do this by either using Quick Setup through host management or use Default Host Management (DHMC) or add the necessary IAM role and permissions through IaC when you deploy your resources. And lastly, the SSM agent must have network connectivity to service endpoints over the internet or by using VPC endpoints.

Systems Manager, Patch Manager uses patch baselines that allow you to define certain criteria for patching your instances. You can also use Patch Policies to scale patching across your AWS Organization and Regions. You will also see operation data from Systems Manager OpsCenter. OpsCenters creates OpsItems that are associated to operational issue or interruption that needs investigation and remediation. You can create OpsItems that integrate with other AWS services like Amazon CloudWatch where an EC2 instance might be reaching its CPU Utilization or create an OpsItem for Security Hub findings.

The other component is the Config data that is being collected around the compliance status of your resources against the rules that are deployed within your account. First, the widget presents an aggregated percentage of rule compliance status based on how many rules in the account are compliant and do not have resources that are non-compliant. Second, the widget provides a p compliance status percentage for your application resources, that indicates whether your application resources are compliant with selected rules.

Figure 6 – DevOps widget showing managed EC2 instance count, patch compliance, AWS Config compliance, and a bar chart of the count of OpsCenter OpsItems by severity.

Cleaning up

To avoid incurring future charges, delete the resources.

• myApplications dashboard is free and you only pay for the underlying services.

Conclusion

myApplications provides application-centric console experience. It integrates necessary tools in the backend to provide centralized insight into application performance, security, and costs through a shared application definition. Being able to scale onboarding applications onto myApplications reduced the complexity. If you run Terraform-manage applications, visit Getting started with myApplications for Terraform-managed applications.