15 min read

The Quickest Way to Create an Amazon AWS Diagram

September 21, 2021

The Quickest Way to Create an AWS Diagram

Accurate AWS cloud diagrams play a vital role in monitoring and internally communicating the operational status and design of your AWS infrastructure.

If you are building or operating solutions hosted on AWS, you probably already understand the value a good network architecture diagram provides. The problem has always been the time it takes to manually draw diagrams, especially when using drag and drop charting applications.

Manually trawling through your AWS console to find what services are running, how they are configured and how they relate to each other can be a massive undertaking especially if you have multiple AWS accounts or multiple application environments to consider.

If you have a complex network or multiple applications and dev/test environments it can take days or even weeks to research and map out your AWS Cloud diagrams.

The quickest way to create an AWS diagram by far is to automate the process using Hava. All you need to do is to create a read-only cross-account role in AWS and then connect your AWS account to Hava using the new role.

The entire process takes a minute or two, which is the only investment of your precious time you will need to make for a lifetime of accurate and perpetually up to date network topology diagrams. It really is that simple.

Allowing access to your AWS configuration data via read-only cross-account role is AWS best practice and while Hava has been assessed by Cyber-GRX as secure with encryption present for data both in-transit and at rest, sometimes internal security or corporate policies dictate that third party SaaS access cannot be granted, so to accommodate customers in this scenario, Hava is available as a self-hosted option.

With the self hosted option, you can run Hava completely within your own cloud environment with no call-home network activity from the application. You will be notified when updates are available, which you can pull updates as required.

The majority of Hava users are however happy to leverage the SaaS application which can be up and running in minutes.

All you need to do is connect a new data source in Hava, which can be either AWS, GCP or Azure. When you select AWS, there is a link that will open up your AWS console and prefill the fields to create a new cross account role:

Add_Source_Modal

This will open up the create role dialogue with pre-filled account id and external ID already pre-populated. You should also uncheck "Require MFA" at this stage, so the application can operate freely in the background without prompting for multi-factor authentication challenges each time it polls your config data for changes.

Getting_Started_CAR_Create_2The next step is to create an access policy in the permissions step by pasting in the provided JSON code into a new policy

Getting_Started_CAR_Create_3Getting_Started_CAR_Create_4

Paste in the following JSON code:

{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"acm:DescribeCertificate",
"acm:GetCertificate", 
"acm:ListCertificates",
"apigateway:GET",
"appstream:Get*",
"autoscaling:Describe*",
"cloudformation:List*",
"cloudfront:Get*",
"cloudfront:List*",
"cloudsearch:Describe*",
"cloudsearch:List*",
"cloudtrail:DescribeTrails",
"cloudtrail:GetTrailStatus",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"codecommit:BatchGetRepositories",
"codecommit:Get*",
"codecommit:GitPull",
"codecommit:List*", 
"codedeploy:Batch*",
"codedeploy:Get*",
"codedeploy:List*",
"config:Deliver*",
"config:Describe*",
"config:Get*",
"datapipeline:DescribeObjects",
"datapipeline:DescribePipelines",
"datapipeline:EvaluateExpression",
"datapipeline:GetPipelineDefinition",
"datapipeline:ListPipelines",
"datapipeline:QueryObjects",
"datapipeline:ValidatePipelineDefinition",
"directconnect:Describe*",
"ds:Check*",
"ds:Describe*",
"ds:Get*",
"ds:List*",
"ds:Verify*",
"dynamodb:DescribeGlobalTable",
"dynamodb:DescribeTable",
"dynamodb:ListGlobalTables",
"dynamodb:ListTables",
"dynamodb:ListTagsOfResource",
"ec2:Describe*",
"ec2:GetConsoleOutput",
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:DescribeRepositories",
"ecr:ListImages",
"ecr:BatchGetImage",
"ecs:Describe*",
"ecs:List*",
"eks:Describe*",
"eks:List*",
"elasticache:Describe*",
"elasticache:List*",
"elasticbeanstalk:Check*",
"elasticbeanstalk:Describe*",
"elasticbeanstalk:List*",
"elasticbeanstalk:RequestEnvironmentInfo",
"elasticbeanstalk:RetrieveEnvironmentInfo",
"elasticfilesystem:DescribeMountTargets",
"elasticfilesystem:DescribeTags",
"elasticfilesystem:DescribeFileSystems",
"elasticfilesystem:DescribeMountTargetSecurityGroups",
"elasticloadbalancing:Describe*",
"elasticmapreduce:Describe*",
"elasticmapreduce:List*",
"elastictranscoder:List*",
"elastictranscoder:Read*",
"es:DescribeElasticsearchDomain",
"es:DescribeElasticsearchDomains",
"es:DescribeElasticsearchDomainConfig",
"es:ListDomainNames",
"es:ListTags",
"es:ESHttpGet",
"es:ESHttpHead",
"events:DescribeRule",
"events:ListRuleNamesByTarget",
"events:ListRules",
"events:ListTargetsByRule",
"events:TestEventPattern",
"firehose:Describe*",
"firehose:List*",
"glacier:ListVaults", 
"glacier:DescribeVault", 
"glacier:GetDataRetrievalPolicy",
"glacier:GetVaultAccessPolicy",
"glacier:GetVaultLock",
"glacier:GetVaultNotifications",
"glacier:ListJobs", 
"glacier:ListMultipartUploads",
"glacier:ListParts",
"glacier:ListTagsForVault", 
"glacier:DescribeJob", 
"glacier:GetJobOutput", 
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*",
"inspector:Describe*",
"inspector:Get*",
"inspector:List*",
"iot:Describe*",
"iot:Get*",
"iot:List*", 
"kinesis:Describe*",
"kinesis:Get*",
"kinesis:List*",
"kms:Describe*",
"kms:Get*",
"kms:List*",
"lambda:List*",
"lambda:Get*", 
"logs:Describe*",
"logs:Get*",
"logs:TestMetricFilter",
"machinelearning:Describe*",
"machinelearning:Get*",
"mobilehub:GetProject",
"mobilehub:ListAvailableFeatures",
"mobilehub:ListAvailableRegions",
"mobilehub:ListProjects",
"mobilehub:ValidateProject",
"mobilehub:VerifyServiceRole",
"opsworks:Describe*",
"opsworks:Get*",
"organizations:ListAccounts",
"rds:Describe*",
"rds:ListTagsForResource",
"redshift:Describe*",
"redshift:ViewQueriesInConsole",
"route53:Get*",
"route53:List*",
"route53domains:CheckDomainAvailability",
"route53domains:GetDomainDetail",
"route53domains:GetOperationDetail",
"route53domains:ListDomains",
"route53domains:ListOperations",
"route53domains:ListTagsForDomain",
"s3:GetAccelerateConfiguration",
"s3:GetAnalyticsConfiguration",
"s3:GetBucket*",
"s3:GetInventoryConfiguration",
"s3:GetLifecycleConfiguration",
"s3:GetMetricsConfiguration",
"s3:GetReplicationConfiguration",
"s3:List*",
"sdb:GetAttributes",
"sdb:List*",
"sdb:Select*",
"ses:Get*",
"ses:List*",
"sns:Get*",
"sns:List*",
"sqs:GetQueueAttributes",
"sqs:ListQueues",
"sqs:ReceiveMessage",
"storagegateway:Describe*",
"storagegateway:List*",
"swf:Count*",
"swf:Describe*",
"swf:Get*",
"swf:List*",
"tag:Get*",
"trustedadvisor:Describe*",
"waf:Get*",
"waf:List*",
"waf-regional:Get*",
"waf-regional:List*",
"wafv2:ListResourcesForWebACL",
"wafv2:ListWebACLs",
"wafv2:ListTagsForResource",
"wafv2:GetWebACL",
"workspaces:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]

 

At this point you can amend the policy to restrict access to any resource types you do not wish to grant Hava access to, however obviously this will prevent them from appearing on your automatically generated diagrams.

All that is left now is to name and save the policy, then return to the new cross account role and attach the new permissions policy.

Getting_Started_CAR_Create_6

Now the new cross account role is created, you simply copy the role ARN from the role summary.

Getting_Started_CAR_Create_8

Then return to the Hava dialogue and paste in the role ARN and press the import button.

Hava_AWS_Role_ARN

So far this process has taken a minute, maybe two and now diagrams for every VPC and container cluster within your AWS account are being generated, which we would argue is the quickest way to create an AWS diagram that we know of.

Now the time it takes to complete the scan of your AWS configuration will depend on the number of resources and environments you have configured. Simple environments can take as little as a minute before diagrams appear in your Hava dashboard, whereas large complex environments will take longer.

But what do you need to do when you change your configuration by manually adding or removing resources, or when AWS autoscaling occurs and scales in or out the number of resources running. The answer is nothing. Hava continuously polls your AWS configuration and updates your diagrams when changes are detected. This happens without any manual intervention which means none of your valuable time is ever wasted keeping documentation up to date.

Once diagrams are superseded, they are placed into version history so you have an audit trail of network topology changes and you can pull up fully interactive older diagrams for side-by-side comparisons.

Why document your AWS environments?

Diagrams produced by Hava allow you to generate GCP, Azure and AWS Diagrams that are always up to date that help you to visually diagnose network issues and explain how and why a network is designed the way it is.

It allows you to identify weak points in your architecture. Having a helicopter view of the VPC's, regions or virtual networks configured in your infrastructure, you can immediately see what will happen if your cloud provider has a regional outage. You can spot redundancy weaknesses and build in resilience before it is needed.

Because your network topology is automatically generated, you also see exactly what is running, where it's running and what it's costing your organisation.

Do you have old test environments running that are no longer needed? Are there any old databases or storage buckets that were preserved "just in case" ? Are there massively over-specced resources that can't really be justified when you compare traffic expectations versus reality.

Everything will become apparent once you connect your cloud accounts to hava.io

Hava takes care of your documentation with little intervention so you can concentrate on development and not paperwork.  Your team can be fully across your infrastructure making it easier to explain the state of play to management and new team members which makes on-boarding developers and operations engineers so much easier.

The unique AWS Security diagrams produced by Hava will also give your security team an instant visual reference of the potential ingress/egress of traffic into and out of your network. All the security groups, open ports and traffic flow are visualized which provides an understanding in seconds that which would normally take hours or days of combing through console setting to establish. This is a major advantage over just having a standard AWS diagram.

On top of automated diagrams and an incredibly flexible API, all Hava diagrams are fully interactive, which means you can click on resources to see detailed attributes, hover over security groups to see what resources belong to the group, turn on connections to see how resources are connected.  This is true for both current and diagrams in the version history.

It's never been easier to create cloud documentation that is accurate and always up to date using Hava

So what do you get when you let Hava take care of your cloud documentation?

Hava Infrastructure View.

AWS_Environment_with_Attribute_Pane

The Infrastructure view lays out your AWS VPCs into separate diagram sets. Subnets within the VPC are grouped by availability zones. The AWS Diagram generated also displays both internal and external resources. 

All Hava diagrams are interactive. Selecting any of the resources on the diagram changes the attribute panel on the right of the diagram canvas which allows you to take a deep dive into the resource settings like security groups, IP ingress/egress ports, connected storage and so on. The diagrams also display the estimated costs of each resource which are totalled for the entire environment when the environment is opened up.

You can view relationships and connections between resources using  the feature that toggles on and off the ability to view connections.

Security_Group_Connections

Right from the outset, we decided to keep the diagrams clean and free from non essential resources like network interfaces that could flood the diagrams making them messy and confusing. 

Although these less important components are not visualized on the diagrams, we did need to know about these 'non-visualized' components, so we designed Hava to create a "List View". The List View is an extensive data set that lists all the resources discovered in your AWS configuration. This view lists both visualized and non-vizualized resources.

The listed resources also have an estimated cost detailed against them.

List_View_New_UI

 

One of the major benefits of the list view is the ability to sort the list by descending resource costs. This surfaces what resources make up the bulk of your estimated cloud spend which should help when you are looking to save cloud costs or explain to management which important resources make up the bulk of your AWS bill.

We also added the ability for you to export this list of resources in CSV format which CFO's and accountants seem to enjoy. 

AWS Cloud Diagram Security View

AWS Security View 800x600

The security view report shows you all of your AWS security groups and will overlay the open ports to show how users traverse your AWS network.  You can select a security group on the diagram to see all the connected resources in the attribute pane, as well as the ingress and egress port numbers and associated IP addresses related to that resource.

This high level view makes some security config issues obvious.

The AWS security view is truly unique and is a result of a team of industry practitioners knowing exactly what information is important to enable effective visualized security monitoring.

One of the benefits of having a team of actual cloud engineers behind a product like hava.io as opposed to say a drag and drop flow chart drawing package solution, is that we are always close to the market and hundreds of front line cloud engineers. If we don't pick up new technologies and methodologies first, then our customers will, and are sure to send in feature requests which we endeavour to integrate into Hava as soon as possible.

This is evidenced by the rising popularity of AWS Container Services.  As more development teams embrace containers to deploy applications and provide portability of software between environments we added the Container view

AWS ECS Container View 800x600

The container view displays your ECS Services and the contained ECS tasks inside an ECS Cluster.

AWS ARCHITECTURE DIAGRAM VERSION COMPARISON

Hava continuously scans your AWS architecture and when changes are detected a new diagram set is automatically generated. The superseded diagrams are not discarded or overwritten. Instead they are moved into version history. Still fully interactive.

What this means is you can view your cloud architecture at any point in time and also leverage Hava's revision comparison (Diff Diagrams) to quickly identify what has been added or removed between the two diagram dates.

Diff_View-1 

So you can easily identify all the changes made since your last compliance audit, or see what changed yesterday that is causing unexpected network or application errors.

AWS ARCHITECTURE MONITORING

While diff diagrams are super helpful in diagnosing changes after the fact, you may want to keep on top of changes as they happen.

Hava's architecture monitoring alerts will let you know the minute a change is detected. You simply nominate the environment you wish to monitor and add a group of recipients to receive the alerts. When a change is detected like the addition or removal of a resource, Hava will send each recipient a diff diagram showing the changes.

Alerts_Detail

Now you and your security team can be across every change as it happens so you can assess and take action if required.

ENVIRONMENT DIAGRAM NOTES

For every architecture diagram generated you have the ability to add text comments. This serves as a rolling dialogue your team can contribute to that may better explain elements of the diagram or bigger picture concepts related to the diagram.

Notes are accessed from the accordion menu within the attribute pane.

Access_Environment_Notes

New notes are added to the top of the list so they are stored in chronological order.

Multiple_Notes

Whichever diagram or view makes the most sense or delivers the information your team needs to build and manage your environments, the upside to using a hands free automatic AWS Cloud Diagram generator like hava.io is that your diagrams are sourced directly from your AWS configuration, the source of truth, so nothing is missed out and nothing can be added or removed by mistake.

When your configuration changes, so do the diagrams. All hands-free, no human interaction required. The diagrams that are automatically replaced are archived in a version history. You can open up the historical diagrams at any time you like. They are fully interactive so you can compare old configurations to new ones to find out what changed in the event of a problem or compliance audit.

The diagrams generated by Hava are also exportable. You can produce an AWS architecture PDF or a JPG for inclusion in your reporting as well as CSV and JSON.

How to generate an AWS Network Topology Diagram

There are currently two options for using Hava to automatically generate your cloud infrastructure diagrams.

Option 1: Hava SaaS

The SaaS option is by far the quickest and easiest way to start visualizing your AWS cloud infrastructure.

You simply create an AWS cross account role with read only permissions, then log into hava.io and connect your AWS account. Hava will read your AWS config data and render the diagrams and start to track any changes for audit purposes.

A 14 day fully functional trial is available (along with demo data) so you can try Hava for yourself. At the time of writing, no credit card is required to take the trial.

Option 2: Self Hosted

The self hosted option allows you to run Hava from within your own AWS infrastructure. If you have particular security or enterprise policies that prevent the connection of 3rd party applications to your cloud environments, then self-hosted may be the solution.

Both options are identical in functionality, but you will need to contact our support team to organise a self-hosted solution.

As well as using the application console to generate and view diagrams, Hava has a fully featured API that allows you to programmatically add and remove data sources, projects and diagrams.

 

testimonials

We recommend requesting a one on one demo with our sales team if you would like to see Hava in action and explore the self-hosted option.

You can contact us via sales@hava.io or jump into a free trial here:

  

 

 

Topics: aws cloud
Team Hava

Written by Team Hava

The Hava content team

Featured