Well it’s time for update number two in my journey to AWS Solutions Architect Associate. I made a personal decision to purchase a bundle from https://learn.Cantrill.io. To be clear, I’m not endorsing anything. Rather, I want to be open about what I am using to learn. I also have access to several other training programs, some self-paced, some text-based, and even live training of which I have taken the Architecting on AWS course.
So Where Am I At?
I took my time moving through the high-level explanation of many of the AWS services. I have noticed a great deal of training programs start with this, and its a good way to get acquainted with the many services AWS offers. Since I already passed the AWS Cloud Practitioner Exam I have seen many of these, but I wanted to be sure I didn’t miss anything. My take so far is that there is a lot of services to be familiar with and a half-dozen or so that I will need to know at a deeper level. In fact, I can’t help but compare this program to the Cisco CCNA program. Years back when I got my CCNA (around 2000) the program was very focused on just a few things like routing, switching, VLANs, basic configuration and so on. When I hung up my Cisco instructor hat back in 2018 the CCNA was two weeks of training if you didn’t take a bootcamp, and encompassed a whole lot more. My point is that AWS has been around for a while now and it’s apparent that they are beyond the ‘introductory’ days. If you dive into this be prepared to cover a lot of ground.
What about the Technology/Protocols/Nerdy Stuff?
I spent a lot of time last week learning about IAM. Having written two books on identity management this topic is near and dear to my heart. So, I got a bit of experience with IAM policies. There are a lot of things that I like. Some things that are counter to what I have done in the past, not that it’s wrong, it’s just different. For example, here is an IAM policy:
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"statement1",
"Effect":"Allow",
"Action":[
"s3:*"
],
"Resource":[
"arn:aws:s3:::*"
]
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::johnsfiles", "arn:aws:s3:::johnsfiles/*"
]
}
]
}Ok, so the above policy is written in JSON. If you need to learn about JSON you might start here.
That being said, my Cisco brain looks at this and thinks things are out of order. Why?
The first statement is an allow action on the resource “arn:aws:s3:::*”. The * is a wildcard that means everything. So allow access to everything in S3. The second statement then says to deny access to “arn:aws:s3:::johnsfiles”, “arn:aws:s3:::johnsfiles/*”. In effect this is denying access to seeing anything in what appears to be the ‘johnsfiles’ folder (I say “appears to be” because there are no real folders in S3, but the UI displays it that way because we understand that structure) and everything in that folder. So coming from a firewall background I would think the deny should come first. Top down processing is what I taught for years, especially when you are talking about an ACL or a policy in ISE (that may be different now).
In reality, the way IAM policy works is simple.
Wrapping my head around that made things much easier.
Another thing I got into this week was AWS organizations. I think that topic merits it’s own post so I”ll leave you with this. Have a look at the link. It’s a way of centrally managing and governing your environment as it scales. I urge you to start out with this! Even if you think you’re not going to scale much. Why? because starting this way gives you the flexibility to scale without having a ton of production stuff in your ‘management’ or ‘root’ account. It just makes sense, trust me.
Wrap-up
Well it was a fun-filled week of learning and labbing but now I am off to Seattle for the week. While I will still continue to hit the books It wont be as heavy as last week. In the mean time, if you have any questions please throw them my way. If you have specific services you’d like to learn about throw them my way. I’ll be back soon.
Until then.. Happy Labbing!
