AWS Application Manager: A Birds Eye View of your CloudFormation Stack
At Reinvent 2023, AWS introduced a new feature called myApplications which allowed you to group resources using App Registry and view consolidated data about that application. This operations requires that the resources be tagged with a special applicationTag which is vended by AppRegistry.
The introduction of this new feature reminded me about another feature that was already available for CloudFormation stacks which offered similar functionality, the AWS Application Manager which was part of AWS Systems Manager. This component was already pre-configured to use the resources within the CloudFormation, aggregating data for your convenience. There isn’t much mention about it online so here’s a quick primer on how to use it and what kind of information it provides.
At its core, the AWS Application Manager consolidates information about a particular CloudFormation stack and provides a single dashboard to view these information which come from a multitude of services. Its integrated with all these services which it derives it data from and allows you to easily view all these information. To access the AWS Application Manager for a particular CloudFormation stack, simply go to the CloudFormation console, select a particular stack, click on Stack actions in the top right hand corner and click View in Application Manager in the dropdown. Doing that will bring you to the homepage for the stack.
The Overview page shows you an option to monitor the health of the stack using CloudWatch with alarms that you can define yourself. The Cost widget shows you cost information about the stack. If you are going into the page for the first time, you will probably see that the Cost widget is not accessible. That is because you need to tag all the resources related to the stack first with a Cost Allocation Tag in this case, AppManagerCFNStackKey. If you’re using aws-cdk, there’s a very simple way to add this tag to all the resources which require it.
// Define a BaseStack extending Stack
export class BaseStack extends Stack {
constructor(scope: Construct, stackName: string, props?: StackProps){
super(scope, stackName, props)
Tags.of(this).add('AppManagerCFNStackKey', context.stackName);
}
}
// Define your Stack extending the BaseStack
export class MyServiceStack extends BaseStack {
constructor(scope: Construct, stackName: string, props?: StackProps){
super(scope, stackName, props)
// Your Application Here
const vpc = new Vpc(.......)
}
}Using this BaseStack class above will tag all the resources within the Stack when you synthesize it. You can also use the BaseStack class to add more tags including more cost allocation tags such as Team , Environment , Cost Centre etc… After adding in this tag, you will need to add all these tags in the AWS Billing and Cost Management console under the cost allocation tags tab.
Moving down this tab, you have the related Systems Manager widgets for Runbooks for your EC2 instances for instance as well as OpsItems if you use AWS Systems Manager to track your incidents and resolution. Here you also see AWS Config which is a great tool to help keep your cloud infrstructure in-line with the leading Cybersec guidelines and best practices. This widget will show you the compliance status of the resources within the stack.
The next tab, Resources, shows the list of all resources associated with the application and is similar to that shown in the CloudFormation console expect that it is grouped by Logical Groups in the CloudFormation console as opposed to showing a list of resources here. Provisioning, in the next tab, is also seen in the CloudFormation console under the Events tab.
The compliance tab shows the AWS Config compliance checks that have been setup for your account along with any findings that might be flagged by the system. To fully utilize this tab, you will need to have AWS Config setup and the recording turned on. This requires you to deploy a S3 bucket along with a role which allows AWS Config to utilize the bucket. The role will required the arn:aws:iam::aws:policy/service-role/AWS_ConfigRole as well as access to the S3 bucket. You will then setup a ConfigRecorder and a DeliveryChannel to define the delivery interval and the resources that should be monitored. You can choose to set this up via the Console or via IAC tools. After it is setup, it will take some time before the data from the resources start getting analyzed and the findings are generated for you to rectify. This setup as well as this widget in the dashboard provides you a great way to view non-compliant resources in your stack and rectify them as opposed to the AWS Config dashboard that will show all the findings across your entire account.
The Monitoring tab uses AWS CloudWatch Application Insights to monitor EC2 instances as well as setup the reccomended metrics and alarms. It’s a one click setup and will take some time for the results to be displayed. It helps to setup metrics and monitoring for resources such as ALB, removing the need for you to set it up one by one in your console. Otherwise, you can also do it via IAC by creating reusable components that already have these monitoring tools implemented and then export these components for use by downstream resources.
Logs shows all the log groups that are associated with this stack which is a great way to see where logs are being stored. It’s also probably a very good reminder that you should clean up your unused log groups especially since Fargate tasks spawn new ones each time.
Lastly, you will see the Cost tab. FinOps is becoming an ever-important part of managing cloud infrstructure and being able to accurately attribute cost is an essential tool for platform teams. This tab provides you a breakdown of all costs associated with this stack which is great if the stack belongs to a single business unit or application, depending on how you attribute cost. otherwise, using cost explorer with user defined cost allocations tags will be better.
Apart from the tabs covered above, there are the Runbooks and OpsItems tab which would be relevant if your team uses these to manage your infrastructure.
Even with the introduction of myApplications, AWS Application Manager still has a really good use case in helping you to gain some visibility over your resources as it is already pre-configured for the CloudFormation stack and doesn’t require any additional configurations unless you want to use more features. Give it a go to help gain some insights on the CloudFormation stacks you are deploying!