September 28, 2019

AWS Diagrams

Link to AWS Architecture Icons:

The whole point of learning about any technology is so that you can in some way use that knowledge. You may not necessarily put "hands on the keyboard" but in some way you are seeking this information for a purpose. One of the most dreaded (and ignored) parts of IT is documentation. People love to put stuff together, but nobody wants to document what they did or how they did it. It works - so shut up, right? Wrong.

Documentation has many purposes and people are largely familiar with the ones that are most daunting and painful. But it doesn't have to be that difficult and the effort can provide quite a few benefits.

Often people hear "We need to pull together a diagram of the environment for audit." Ugh. Those words should never be spoken. The diagram should exist well before the audit team requests it. The diagram should be built during your design of the system, used to build the system, and updated as changes are made. When audit requests a diagram, it should be a matter of going to your diagram repository and grabbing the latest version. If you're creating the diagram after the request is made, you are under pressure to complete it quickly. In the back of your mind, you may be concerned that this information will be used "against you" in some way. Or you may end up "in trouble" or at least embarrassed if something is incorrect or missing. Creating the diagram early in the process removes quite a few of those negative factors.

The AWS page lists some drawing and diagramming tools. You may want to use a tool that seems easy and familiar to you, but you may find that the people you will encounter will want a diagram in either a PowerPoint or Visio format. Those are two programs that you really should know - to put you a step ahead of the pack. You'll find that diagrams in PowerPoint normally flow up the food chain (especially professional-looking ones) and Visio diagrams are normally used by engineers. Most people basically stumble their way around these programs with relative degrees of difficulty and effort. Don't be "most people." Today - when there is no pressure from audit to produce something yesterday - take some spare time and take your skills up a notch.

Both Visio and PowerPoint are Microsoft products. It's likely that you have access to these programs on your work computer but not your home computer (they cost $$$). You're likely to not have any "free time" to play around with these programs during work hours and many places that promote skill development rarely give you the time to do so or fund classes unless they're directly job-related. Fortunately, Microsoft has FREE online training for these programs.

Visio Training

PowerPoint Training

You do not need to have the program installed to watch the videos. Each video is usually just a few minutes long and covers a specific topic or task. You do not have to watch all the videos and you don't have to watch them in any particular order. Select the ones that interest you. Even just a few minutes of these videos every now and then will be noticeable next time you click your way around to create or update a diagram. You're not studying this to pass an exam, but to become familiar with the terminology and available features.

Knowing the right terms can speed up your search when using the Help menu. An example is when you're looking to "line things up" properly. The Help menu is not Google search. If you search for "line" - you will get all kinds of information on the formatting of lines. If you search for "align" you will get the help pages you need. Knowing this one thing can save you time and frustration. Imagine all the other things you could learn in just minutes a day - which could save you hours of struggle later.

The link at the top of the page will lead you to both PowerPoint icons and Visio stencils. Do not be overwhelmed by all the icons. Depending on your job function, you will likely use a small subset of them. The stencils and slides are organized in the same categories that AWS uses for their offerings. Take some time to poke through them and make your own stencil or icon deck with just the icons you may frequently use. This is another time-saving measure.


  • Do not try to put everything on one page. Visio will let you create a diagram that spans multiple pages. When you send it to someone and they try to print it, they will be annoyed at the results. The diagram itself will be very busy and overwhelming to view. Start with an "overview" page of the entire system (a diagram's "executive view") and use visually interesting images to represent the separate areas of concern or further detail. You don't need to document the world each time you diagram the makeup of a specific application implementation, but it would be a good idea to give the "big picture" view of where this fits in your enterprise environment. You can use hyperlinks to "drill down" - linking to pages that specifically display that area of concern. [Don't forget to put a little "home" icon to bring you back to the overview page.]

  • You do not have to document every detail in the diagram. Often diagrams are included in other documentation, so the details may be redundant. Include enough detail so that the purpose of the diagram is obvious. Is this a data flow diagram or a connectivity diagram? Those two diagrams would display different components. A title at the top of the page would be helpful (Application XY Data Flow Diagram). You may want to include a "Title Bar" at the bottom of your diagram (on each page) - but that's for your recording purposes. Someone viewing the diagram is not going to see it right away.

  • The Title Bar on the bottom adds a touch of professionalism to the diagram. You will want to include the Title of the Diagram and perhaps the location where the documentation is stored. You could also include the person or department that created the diagram and "Last Updated" section with the person and date. You could add a sheet at the end to document the updates if you want to be thorough. Expect that your diagram may be copied and pasted into Word or PowerPoint (or even an email). Make sure that what you're showing stands on its own (without the Title Bar).

  • Since this is a diagram, realize that it is a visual display of information and should be visually pleasing to look at and show something significant. The items in the picture should line up and be uniform. When you use an icon from a stencil, it will drop onto the page and may be larger or smaller than another icon you're using. Plan out your picture and don't try to play around with adjusting individual icons. Are you trying to show 2, 8 or 10 S3 buckets? Drop the first one onto the diagram and get that sized properly. Then copy that as many times as needed so that they are all the same size. Then use the guides to make sure they are aligned properly.

  • Use the grouping feature in a hierarchical way. If you have an icon with a text box label, group them together. Then take the labeled items and group those. Be mindful of what is highlighted and grouped/ungrouped. This way you can move items as a group to adjust the "look" of the diagram.

  • Be aware of Sensitive and Proprietary data in the diagram. You will want two versions of the same diagram - one with and one without IPs, ports, server names, etc. The detailed one with proprietary information should be clearly labeled with a hyperlink to the page with the identical diagram stripped of this information and appropriate for wider use or discussion. Remember to update both diagrams when there are changes - and you will always have the "latest" diagram when it's requested.


  • Sometimes it's easier to create a diagram in Visio and copy/paste it into PowerPoint. Your PowerPoint slide is normally presented in meetings or reports, so you will want the diagram to speak for itself without a lot of added text or detailed "additional data" boxes. Think of the Visio diagram as a blueprint used by engineers (who need the additional data) and the PowerPoint slide to be a picture of the system used as a talking point in a conversation.

  • Realize that the presentation could well be used in Slide Show mode. If you will be showing two views of the same thing (such as a "before" and "after" diagram), you will want to make sure that the diagram doesn't "jump" distractingly from one slide to the next. A good way to do this is to create the first slide and then copy it to use as the basis for the next altered slide. This way the same components that remain are shown in exactly the same position and the "new" information is where the shift in display is seen. This will draw the eye to the important part of the diagram in a natural way.

  • Use a Slide Master for your deck so there is uniformity in the look and feel of the presentation. Title bars and footers shouldn't jump up and down from slide to slide. Put them in the Slide Master and you don't have to remember to include them on each slide.

Although documentation is often associated with audit requirements, there are many other uses for these diagrams. If you have a clear design diagram, your build is more likely to proceed smoothly. If the person building the environment has any questions or doesn't understand how something should be connected, they can bring that up before actually building it to clear up any questions. If you are in a position where you are responsible for troubleshooting anything within the environment, you will be glad to have a diagram available to reference and can quickly orient yourself to the situation and troubleshoot more effectively. Any proposed changes to the environment should start with a discussion referencing the current diagram. This way you can see any potential issues you may encounter with respect to the intended change. [Is this environment connected to something you didn't expect?]

Also keep on hand a Visio or PowerPoint drawing of the relevant AWS architectural diagrams. AWS provides some examples of example architectures. Normally these are static pictures in their documentation. Using the icons, recreate those same pictures in Visio or PowerPoint for the technology you're currently working with or discussing in your upcoming meeting. This way when you want to reference the diagram, you have the ability to put your customized notes and additional information directly into the diagram (which you can't do on the picture). You may find that building your documentation becomes easier this way. If you build the diagram as you discuss it, the diagram is complete and up-to-date at the end of the meeting.

One last caveat about diagrams. Take the extra time to create a diagram that you are proud to display. If you do this before you need it, you will have the time to make it look professional. If you quickly put together something that is "good enough" for a rough draft or quick chat, you may regret that shortcut. It may be passed from person to person and years later may be presented back to you in a meeting as something they consider the official drawing. [Without the last updated info - nobody knows if this is the current picture or not.]


Cloud Certifications

Keeping track of my cloud certs

Vendor Cert
AWS Certified Cloud Practitioner

Powered by
Lots of COFFEE!!