Building a workshop for AWS re:Invent - part 1

This year at re:Invent 2023, AWS delivered more than 300 hands-on workshop sessions across the 5 days of the event (this isn't including the 200+ Builders sessions and the 5 AWS GameDays).

Workshops are two-hour interactive sessions where you work to solve problems or build solutions using AWS services. Following a short (5-10 minute) introduction, attendees then get hands-on with AWS, in pre-provisioned accounts.

Workshops are scaled for between 80 and 160 people, with the room typically organised into tables of 8-10 places to encourage interaction, giving you the opportunity to learn from and teach each other. There are also several AWS staff around, with experience of both the topic and the workshop, to help if needed.

Whilst we won't cover the selection process, it's worth calling out that the process for determining re:Invent content (sessions, workshops, chalk talks, etc.) starts more than 6 months before the event itself; each track (such as networking, security, databases) will have a core team of experts that will review content ideas from across AWS and beyond. As you can imagine, there are lots of ideas submitted, and so this process will often involve consolidating similar ideas into a smaller number of sessions that fit into the allocated number. If you're lucky enough to be selected, this is when the hard work really begins!

The workshop Laura and myself have developed for re:Invent 2023 (NET301 - Approaches to layered security for Amazon VPC) is an evolution of the one we ran at last year's event (NET308 - Best practices for securing Amazon VPC) - which in turn can tract its heritage back to 2017. The concept of the workshop is to allow participants to go beyond the "basics" of VPC security controls (such as security groups, Network ACLs, VPC Flow Logs) and have a chance to get hands-on with some services they might not have used before. Services we chose to focus on include Route 53 query logging, DNS Firewall, AWS Network Firewall, Traffic Mirroring, AWS WAF, and Network Access Analyser. This year we also added support for IPv6, and the ability to create your own custom firewall capability using Gateway Load Balancer.

One of the key outcomes we want from the workshop is for people to "learn by doing"; it is important to us that participants are able to try and solve things on their own initiative, without simply following detailed step-by-step instructions of which buttons to click for the 2 hours. To this end, we came up with a design approach based loosely on the Perl slogan: "There's More than One Way to Do it".

First, the workshop is broken up into a number of separate tracks, allowing you to "choose your own adventure". These tracks focus on DNS Security, Network Analysis, AWS Network Firewall, 3rd Party Network Firewall, and AWS WAF. These tracks can be done in any order, and don't have any dependencies between them. This is important - we don't want people getting stuck on one part of the workshop and then being unable to complete any other parts.

Within each track is one or two labs; these do have to be followed in the correct order, since the outcome of one lab will typically be needed to support the next lab. For example, in the AWS Network Firewall track, the first lab focusses on the routing changes needed to integrate AWS Network Firewall into your VPC. This is needed to start the second lab, which looks at the various firewall rules you can use to filter or alert on specific traffic types.

In order to make the labs as interactive as possible, we allow participants two different approaches; the first is to state the desired outcome in the workshop guide, provide a starting point, and offer some suggestions as to what services to use. Participants are free to explore and learn by experimentation, but with the ability to look at hints if they need to. Alternatively, if attendees feel more comfortable with a step-by-step walkthrough, we provide that as well. The approaches can be mixed; you might start by experimenting, get stuck, and then dip into the walkthrough guide to help with a specific task.

At its core, an AWS workshop consists of a fresh AWS account, provisioned on behalf of the attendee, with an IAM role and pre-deployed resources, together with a set of Markdown-format documentation providing guidance on how to complete the workshop. As workshop authors, we need to create the CloudFormation template that is pre-deployed into the Workshop Studio accounts, together with the documentation & guidance needed for attendees to complete the tasks.

For the past few years, AWS workshops run at events such as re:Invent have been developed and deployed using an internal capability called AWS Workshop Studio. Inside AWS, we use this to design and develop the workshop documentation, code, account structures, permitted resources, and more. From a development perspective, it uses a Git-based source code repo for both the documentation and code, with a whole bunch of automation to deploy micro-sites, etc.

When it comes to actually running the workshop, AWS Workshop Studio handles all of this heavy lifting, allowing us to safely and securely provision 100's of pre-configured AWS accounts and associated resources based on a workshop template, allow users to register for the workshop, and then provide time-boxed access to those accounts for the workshop attendees. The workshop code is deployed prior to the workshop being delivered, and then when the participants log into their accounts, they assume a role with the appropriate permissions needed to complete the workshop.

This is a far better experience than the approach I had to use at the first re:Invent workshop I ran back in 2017, when participants had to bring their own accounts, deploy resources before starting the labs, troubleshoot resource limits, restrictive IAM policies, etc. It's also worth calling out that the AWS Workshop Studio team are amazing - more on that in part three!

Since this workshop was an evolution of our previous one, we weren't starting from scratch; however we did have to make a couple of significant modifications - the first was to integrate IPv6 into the architecture, and the second was to include the ability to get hands-on with Gateway Load Balancer (GWLB). The first was reasonably straightforward, but the second presented some problems, since we already had a lab focussed on Network Firewall. Since we were going for the ability for attendees to "choose their own adventure", we had to make sure that an attendee completing one track wouldn't interfere with the other (even if they made a mistake).

In the end, Laura came up with an elegant solution - we would demonstrate IPv6 using Network Firewall, and use IPv4 for GWLB; this way both tracks could be completed independently, and a mistake or issue in one wouldn't impact the other.

Development of the documentation, screenshots and diagrams had to run in parallel to the development of the workshop code; this is because we needed to include screenshots in the documentation, links to specific console pages, etc. For me, this was probably the hardest part of the workshop development overall - when you've been working on something so closely for a number of months, it's easy to make assumptions and skip steps that should be captured in the documentation.

For our diagrams we made use of Draw.IO, with the AWS icon pack. From a screenshot perspective, I highly recommend Skitch - it's a great tool for capturing screenshots, redacting sensitive information, and highlighting key parts of the image. For the code and content development itself, we used VS Code, together with the very useful cfn-lint and cfn_nag extensions.

That's enough for this post; part 2 will get into the details of code development...