Hands-on with AWS re:Invent 2017 Labs

| | | 0 comments

I went to Las Vegas last month, and didn’t gamble once! Weird, right? But AWS re:Invent 2017 was so full of material that it doesn’t leave much free time for the usual Vegas experience, after the keynotes, talks, hackathons, daily after-parties, and sundry side activities. If you’re reading this and wondering whether you should go to re:invent 2018, the tl;dr is “Yes!”

I didn’t even attend any talks, and ended up watching the keynotes over livestream (see walking, later). My focus the entire time was the hands-on labs. The labs (or workshops) are all structured the same: scheduled for 2.5 hours, each starts with a presentation from an AWS trainer or expert, followed by self-paced study time, with additional AWS subject-matter experts on-hand to answer questions on the material. I focused on intermediate- or advanced-level workshops (300- or 400-level), where its assumed you’ll already have an account set up, know how to access the console, and manage your PEM files or configure the CLI.

These are not sandbox labs (like Qwiklabs or other online practice tools), so its important to have an AWS account of your own, and one where you can feel free to create and destroy resources with aplomb. Each lab does provide credits which cover the cost of running the lab (and after five such workshops, I built up a good buffer of billing credits!). Here’s the specific workshops which I attended (and one which I planned on but missed, SRV330):

CMP316 was my favorite. It gives a detailed, functioning example of using an autoscaling EC2 Spot fleet to run analysis on financial markets. The approach uses Jupyter notebooks, asynchronous SQS queueing, and Cloudwatch alarms, and then shows how AWS Batch can replace much of that with a managed-service offering.

SRV424 was good, but there’ an issue with the fourth lab, for which I opened an issue. I got to build my first Alexa skill in ABD325, and deploy a serverless application using Athena and Quicksight to analyze Twitter sentiment. Really all of the workshops were top-notch. If you already work with AWS professionally, I recommend the advanced-level workshops; the content is really solid and the AWS experts on-hand help with specific questions. The list above includes links to the lab materials on Github, which is awesome, since I could follow-up and read in more detail later. It also means you could work through them even if you didn’t attend reinvent. Get to it!

For the first time, re:invent was spread across multiple locations along the Vegas strip. Plently of discussions on Reddit and elsewhere abount long walking times. While there were shuttles between the locations, it often took 40-60 minutes to get from one venue to another. There were also issues with long lines if you hadn’t reserved a seat in a lab. And not getting in to the workshop you arrived at almost certainly meant missing out on any workshop for that time slot. If you’re planning to attend for the workshops, figure out in advance which ones you want and consider booking your hotel where those workshops will be given.

Workshops are meant as focused time for deep-dives. If you’re going to re:invent to network, they probably aren’t where you want to spend most of your time. But for getting familiar with a service like IoT Device Manager or CodeDeploy and CodePipeline, and maybe chatting with SMEs at other companies along the way, workshops are great.

The workshops leave a lot of resources lingering around in your AWS account. And as always, cost management is key. This gave me a great excuse to try AWS Nuke, a project whose very premise evokes fear in the minds of everyone I mention it to. Nuke will, as it says, blow away everything in an AWS account. There’s multiple layers of safety built in, and a way to whitelist items to not remove. But in the end, Nuke identified resources in S3 buckets, SageMaker managed services, Lambda functions, and various other items which would have persisted long afterwards, had I not obliterated them. After all, you don’t want to do account cleanup in between re:invent parties!

The Meaning behind the Foghorn Logo

The Meaning behind the Foghorn Logo

When we started Foghorn Consulting in 2008, we were laser focused on learning everything we could about how we could best help companies utilize cloud computing to meet business goals.  We spent zero time with things like logos.  Well, 8 years later, we thought it was...