Creating Visual Notes for Amazon Web Services — My Step-by-Step Process

Readers often ask me how I create the diagrams found at awsgeek.com. What’s the process I follow when I author my visual notes? What tools do I use to create them?

In this post, I’ll answer those questions and walk you through the steps I take when I create a new diagram for a service. You’ll see that evolving a diagram from an idea to an image is simpler than you might think.

Let’s get started.

Step #1: Choose a Service

First, I choose an AWS service as a topic. Luckily, the pace of innovation at AWS usually means the pool of available topics is large. Choosing the service is usually the easiest part of the process.

When choosing a service, I try to find one that I’m interested in learning about or a service that might be useful for a customer I’m working with. For example, last year I was interested in learning more about machine learning on AWS, so I created diagrams for several services including Amazon Machine Learning, Amazon Rekognition, Amazon SageMaker, and Amazon Comprehend.

Step #2: Research the Service

Once I’ve made the selection and have decided which service I’m going to draw about, I begin researching the service and gathering details about it. This process is similar to what I might do if I was going to write a blog post or article about the service:

  1. I look for articles about the service on the AWS news blog, particularly introductory blog posts Chief AWS evangelist Jeff Barr authors when a new service is launched. These articles usually include high-level overviews for new services and practical examples and usage walk-throughs. They’re a great jumping off point to product docs.
  2. I review the product pages for additional detail about the service, to identify major features and to become familiar with common use cases for the service. I start to think about how I might want to visualize the service and use cases.
  3. I read the product FAQ page to understand how the service interacts with other services, what security features it has, how available & scalable it is, etc.
  4. I occasionally dive into the developer docs for a service, but that’s usually deeper than I need to go. Some times I find interesting info there that I don’t find anywhere else.
  5. I might also watch an AWS re:Invent video about the service to get some additional context.

One thing to keep in mind is that these diagrams are supposed to provide an overview of a service. I expect that readers who want additional detail will continue on to the services’ product pages (which I link to in every diagram).

More about this in the next step.

Step #3: Decide on Detail

Armed with a decent overview of a service, its features, and its use cases, it’s time to decide on what information and what level of detail to include in the diagram. Too much detail and the diagram can be difficult to digest quickly and a burden for me to maintain.

I think I’ve struck the right balance with some of my most recent diagrams, both in style and detail. The Amazon DocumentDB diagram is an excellent example of what I consider the right level of detail for my diagrams.

Some AWS services are too vast to cover in a single diagram, like AWS Elastic Cloud Compute (EC2). Instead, I’ve chosen to break them down into more manageable sub-topics, like EC2 Spot Instances and the Evolution of the EC2 Host.

In the process of deciding what to include, I often create a high-level outline, use a mind-map (like for the AWS Well Architected Framework), or create a rough draft (sketch). These tools help focus my thoughts and narrow down the topic, similar to what I might do when writing a blog (like this one).

Step #4: Draw the Diagram

Once I’ve decided on what information I’m going to include and have an idea for how I want to visualize this information, I get to put pencil to paper (figuratively, of course). All of the diagrams you see on my website are created with the same set of tools:

After several years of experimenting with different tablet/stylus/app combinations, I settled on the tools listed above.

Step #5: Publish to the Web

Satisfied with the details and layout of the diagram, I upload the diagram to my website. That process and how the diagram is converted to different formats and integrated into my website, as well as details on the website itself, are described in more detail here.

I publish each new diagram via Twitter, LinkledIn, Reddit, and HackerNews. Depending on the medium, I’ll post each diagram one or more times to ensure complete coverage.

Conclusion

That’s it. From start to finish, I typically spend between 2 to 8 hours researching, preparing and creating each diagram. Some services take longer, particularly those I’m not familiar with and haven’t used before.

I use the same process and tools for AWS services and features and for breakout sessions at AWS re:Invent, although for breakout sessions, I usually only use the session video as my information source.

Creating these diagrams has been a great learning tool for me. My learning style tends to be more visual than anything else, and these diagrams help reinforce key leanings and ideas for me.

If you’re a visual learner, I hope these diagrams have been helpful to you, too.

Question

How do you familiarize yourself with new AWS services and features?