AWS Security Profiles: Becky Weiss, Senior Principal Engineer

In the weeks leading up to re:Invent, we’ll share conversations we’ve had with people at AWS who will be presenting at the event so you can learn more about them and some of the interesting work that they’re doing.

How long have you been at AWS, and what do you do in your current role?

My title is Senior Principal Engineer, and most of my work is with the AWS Identity team. That’s the team that does AWS Identity and Access Management, AWS Organizations, AWS Directory Service, AWS Single Sign-On, and a bunch of other things. We build the infrastructure for security, compliance, and manageability across all of AWS. It’s a large swath of services, and it’s a very interesting place to be. My team is at the crossroads of everything that’s going on, so we get an up-close view of trends and patterns around the controls customers demand as they move workloads to the cloud, as well as what they do to secure those workloads and put guardrails around them once they’re here.

How do you explain your job to non-tech friends?

Most people, even outside of the tech space, have heard about the cloud. And they’ve likely heard about companies in almost every imaginable industry choosing to move their core infrastructure — computing, and networking — from their own data centers to the cloud, as well as taking advantage of data services and higher-level application and AI services, of which there are increasingly many options. So to these people, I’d say that my job is to make sure that the security controls these enterprise customers will need are present, and that we’re constantly improving them by making them more comprehensive and simpler to get right.

What’s your favorite part of your job?

My job is very rewarding because, as customers move into the cloud, one of the things that I deeply and truly believe is that they’ll be able to improve their security posture. They’re going to gain visibility into and get control over things they didn’t have visibility into or control over before, and they’ll have it in a way that scales much better than the processing power of human gatekeepers. It’s really rewarding to see those transformations happen and to be able to give customers something that I believe will serve them so well.

Another privilege of this aspect of my job, in which I get to work with customers, is seeing how much these customers value AWS’s institutional experience, not just in security but in building for resilience and scalability. They ask, “How would Amazon architect this? What would you do if you were building our stuff?” It’s an incredible honor to be asked a question like that.

What are you currently working on that you’re excited about?

In the last couple of months, my team has done a lot of deep dives and close listening with some of our customers on what “governance in the cloud” means to them and what their needs are. We have this process at Amazon called “working backwards from the customer,” where we start with the very real challenges, concerns, and problems that customers lay out for us as they describe their own workloads and approaches. We take those insights and we use them to work backward toward what we need to build. That peculiar Amazonian focus on mapping customer needs and using them to drive what we’ll provide is one of the things that keeps me looking forward to coming into work. It’s special.

What’s the most challenging part of your job?

I mentioned before that my team sits at the crossroads of AWS, and the number of new services and new features that show up every re:Invent and throughout the year is mind-boggling. The reason we’re able to maintain this pace as a company is a consequence of the Amazon DNA: Each service is managed as its own business, and its owners engages directly with its own customers. Working from those specific customer needs is what allows us to iterate quickly and address customer-needs head-on. But the flip side is that you do have certain features that need to be constant, consistent, and effective across all services, and this is sometimes at loggerheads with what makes us makes us fast. One of our biggest strengths is also one of the things that can pose challenges when you’re sitting in the middle of “downtown AWS” like my team does.

What does cloud security mean to you, personally?

When it comes to security, complexity is the enemy. So you’re looking for security controls and mechanisms that are as simple as possible while still doing the job. When you’re answering the question, “Why is this thing secure?” having a long answer can be a sign that you have the wrong answer. If you can figure out a simple expression of the controls that you want to put on your infrastructure, it means you’re doing something right.

One of your 2018 re:Invent sessions is A Practitioner’s Guide to Securing Your Cloud (Like an Expert). What’s that session about?

One of the reasons why I wanted to give this talk is because you might look at this incredible landscape of AWS services and, especially if you’re new to the cloud, you might think, “Wow, there’s so much stuff here.” If you’re a security- or governance-minded professional and it’s your job to make sure things are secure and properly controlled, you might ask yourself, “How is my job even possible over this kind of surface area?” But the truth of the matter is it’s easier than you might think if you’re new here. We’ve worked hard to make sure that’s the case. In fact, there are just a couple of patterns: You’re securing your infrastructure with IAM permission controls and with VPC network security controls. (There are also encryption controls, which I won’t have time to cover in the session, but that follows simple patterns too.) But really, these two or three patterns repeat everywhere. If you learn them once, it doesn’t matter what new AWS service your team is going to adopt—you’re already going to know how to secure it. That even includes features and services we haven’t yet launched or even dreamed up yet—you’re already going to know how to secure it. The patterns are repeatable and very learnable.

You’re also co-presenting a session with David Yanacek that talks about Failing Successfully in the Cloud. How did you choose that topic?

That one’s a chalk talk—basically an open-ended Q&A with folks in the audience. Here’s where I got the topic idea: One of the tremendous privileges of being an engineer at Amazon is that AWS has been running at such a scale, and for long enough, that we’ve built up this institutional experience that I believe you can’t find anywhere else. There’s no compression algorithm for experience, and people like David and me have been lucky enough to have a front-row seat. The various services we’ve worked on—between us, Amazon Elastic Compute Cloud (Amazon EC2), Amazon DynamoDB, IoT, AWS Lambda, and AWS IAM—have given us a first-class education in resilience. It’s the law of large numbers: Anything can happen and eventually does. So we’ve learned a number of lessons that we’ve now baked into the design of what we do.

One of the things we’re going talk about is how, when we run a service, we break it down between the data plane (the “day job” of the service, the part that runs at high volume and is critical to the business), and the control plane (the part that’s used to configure the rest of the service). At AWS, we think about these planes very separately because of the resiliency benefits. We’re also going to talk about some approaches to handling high levels of load, and how to think about dependency failures. I’m expecting some really interesting discussion.

And finally, you’ll be co-presenting a session and chalk talk with Alan Halachmi on Securing Your Virtual Data Center in the Cloud. Tell us about those.

These two are an outgrowth of a re:Invent session I used to lead called NET201: Creating Your Virtual Data Center in the Cloud (this was back when I used to work on Amazon Virtual Private Cloud). It continues to be one of our most popular sessions, and it’s now led by my colleague Gina Morris. Based on the feedback I received when I hosted these talks, I realized that our customers were hungry for simple explanations of networking in AWS. And it really is possible to explain this topic simply, which I think is why the talk remains so popular.

But I realized there’s also a security angle on this topic. So we created the breakout session NET202: Securing Your Virtual Data Center in the Cloud as a primer on how to use Amazon VPC to secure your resources and as a way to educate people about the ways in which Amazon VPC intersects with other security controls in AWS. Because the NET201 session always generated incredible Q&A after the talk, we’re also pairing the new session with a chalk talk of the same name, and we’re looking forward to an active discussion. We’re bringing a number of examples to walk through, but based on the past experiences Alan and I have had talking to our customers about networking in AWS, we’re expecting great Q&A.

What are you hoping that your audience will do differently after your session?

For the “Practitioner’s Guide” and “Securing your Virtual Data Center” sessions, I want my customers to go back and look at the workloads their teams are standing up, and the workloads they’re standing up themselves, and recognize the patterns we’ve pointed out—and then apply these patterns and feel confident that they’re securing things correctly because, again, there are only really a couple of things you need to know to get the network right, and to get the access controls right. And I think these things are eminently teachable in a fifty-minute session.

For the “Failing Successfully” chalk talk, I want the folks to go back home, take a look at the workloads they’re running and ask themselves questions that they may not have thought to ask before. For example: “Does this system have a control plane and a data plane?” Most systems do; you just have to know where to apply the analogies. “Have I separated them?” Maybe start thinking about separating those if you want to get more resilient. “Am I taking dependencies on things that are going to fail more than I want my own service to fail, and what I could do about that? If my system is under load, what do I want to have happen?”

The AWS Security team is hiring! Want to find out more? Check out our career page.