The Art of Focus: Navigating the AWS Security Pillar with Deep Work

Do you scroll on social media? It’s easy to skip stuff you don’t want to see. Now think about this. How do you read? No, really, how do you approach documentation like the AWS well-architected framework? Do you find yourself skipping and browsing through links looking for the right answer?

As a security and technology professional, we must review documentation on best practices. As I prepare for my AWS Solutions Architect Associate exam, I’ve taken some time to read and study the security pillar of the well-architected framework. In the remainder of this blog post, I’ll share my approach to reading and internalizing the content to make me a better cloud security professional.

The first step in studying documentation is to limit distractions. I know that’s easier said than done. If you have a demanding life, try to time-box your study to just 10 minutes at a time. This approach should help you eliminate distractions. Years ago, I read the book Deep Work by Cal Newport. In it, he talks about the need to dedicate time to doing deep work to reach the greatest heights in your profession.

Now, I haven’t read all the documentation yet. I did my time-boxing and wanted to share what I discovered so far. There is a significant emphasis on separating workloads as much as possible. I get the principle of least privilege. I’ve been a security professional for more than a decade. However, as I read, I got the sense that this has a different meaning in the cloud. Let me explain.

When you have access to a local data center, your dev, test, and production environments are likely physically different. If not, there is a logical isolation at the hypervisor level that was well thought out in the system design phase. The cloud offers a level of autonomy to developers and technology professionals not common to on-premises environments. Additionally, one of the benefits of moving to a cloud environment is the ability to rapidly innovate and deliver something to market. This go-fast mentality is often equated to a race car driving down a curvy mountain road. The documentation leverages this analogy by describing the security recommendations as guardrails.

When security is built into the design, the builders and innovators can leverage their creativity to help your organization reach its goals. Without security built in, you might still achieve the creative milestone but also expose your organization to a significant risk.

Enough theory. Here is the takeaway. In AWS you should isolate each workload in its account. You can then allow or permit actions in that account using service control policies. If two services from different accounts need to interact, the best approach is to leverage a role for the other account to assume.

That’s it for now. As I read more and experiment, I’ll continue writing on the security pillar of the AWS well-architected framework. It’s your turn. Get out there, pick a technology, read through the documentation, and share what you got from it. We can all grow together by taking this approach. As always, thanks for reading.