Are you struggling to keep an overview of all your deployed AWS services and workloads? Do you struggle to keep all your architecture diagrams up-to-date? Workload Discovery on AWS (formerly known as AWS Perspective) offers a quick way to visualize AWS Cloud workloads. This post looks at how to set up Workload Discovery, debugging options, and limitations.
Table of Contents
📐 Setup of Workload Discovery on AWS
💭 Limitations and thoughts about AWS Workload Discovery
📐 Setup of Workload Discovery on AWS
AWS offers an easy-to-deploy CloudFormation template. You can find the template here: https://s3.amazonaws.com/solutions-reference/aws-perspective/latest/aws-perspective.template
To deploy the template and configure Workload Discovery on AWS follow the below steps:
1. Login into your master/ AWS account and open the CloudFormation console. You can paste the S3 URL above or upload your local copy.
2. Review the template parameters For implementing an initial proof concept, I recommend the following minimal setup:
Make sure to acknowledge all access capabilities at the bottom of the page and create the stack
3. Check the URL of the service in CloudFront or the CloudFormation stack output after the deployment and all checks are done, you can retrieve the live CloudFront URL from the output ribbon of your CloudFormation deployment. Now you can log in with the user and password sent to the email address you specified beforehand.
4. Import the AWS accounts and regions you would like to make discoverable. Make sure to follow the prerequisites for using AWS CloudFormation StackSets and follow the instructions to import the CloudFormation templates for the different IAM roles:
After adding the accounts and regions it can take up to 15 minutes until a discovery is run. Eventually, you will see all resources on the left-hand side (Not all AWS services are supported yet so you may not find everything). Clicking on the individual resources makes them appear in the architecture diagram. You can re-arrange them manually or group them automatically via left-click in the blank areas of the canvas.
Accordingly, we can debug all methods and calls within the web browser directly. We just open the developer tools (F12) go to Network, activate preserve logs, and start recording network logs. (The option to preserve logs does not clear the logs on a page reload) When making requests to the API Gateway, we will see the exact information in the Payload ribbon of the request. You can also directly check the logs in the different CloudWatch log groups.
💭 Limitations and thoughts about Workload Discovery on AWS
Workload Discovery on AWS gives you a quick and efficent overview of all your cloud services and drill down on costs. Especially when you work with new AWS accounts or organizations.
If you onboard a whole AWS Organization it could get overwhelming quite quickly, especially if you have several hundred accounts. I recommend filtering the resources based on the accounts you want to investigate and adding accounts in smaller bulks.
Additionally, the solution could become quite costly when it is running 24/7. You can shut down services that are not getting used like the database and only spin it up once it needs to be actively used.
I usually use Workload Discovery on AWS when encountering new AWS Organizations and accounts to get a quick overview of deployed resources and have a discussion basis with the application/cloud architects. As the application landscapes grow faster the architecture team can update their diagrams dynamically and use the export function to draw.io.
Furthermore, you can quickly identify services that you have accidentally activated in your account like internet gateways or services in other regions. After all the discussions are done and I got a good overview of the environment I usually delete the CloudFormation stack again and deploy it on a need-to-use basis.
The solution is actively developed by AWS and the whole source code is published on GitHub (You can find the links down below)
All in all, it's a lightweight and easy-to-deploy solution, which can be used to get a first look at a new or existing AWS environment but should not be used instead of creating meaningful architecture diagrams of your solutions.