Getting Started Right

0:00In 1972, Nolan Bushnell and his lead engineer, Al Alcorn, took a black and white TV, rigged it with some custom circuitry, and bolted it into a wooden cabinet. They left their prototype at a bar called Andy Capp's Tavern in Sunnyvale, California. The prototype was a game called Pong. A few days later, things stopped working, so Al made a service call. Well, the game itself was working just fine, but the plastic milk carton they had rigged up as a coin box was completely overflowing with coins.

0:32The success of Pong helped launch an entire industry, one which would eventually pull in more revenue than Hollywood and the music industry combined. And I can tell you, much of my adolescent lawn mowing money ended up at the arcade machines at Pasquale's, my local hometown pizza parlor. Most of those early arcade machines, Pac-Man, Galaga, Donkey Kong, all had one thing in common. Dual inline package switches, better known as dip switches. And that is how the operators could control the elements of the game. Difficulty, number of lives, coins per credit, crack open the cabinet, flip the switches you need, and close it back up.

1:13Sounds simple, but if you choose the wrong combination, your little money maker allows unlimited lives and free play, or worse, it doesn't even work. And that's a decent metaphor for what we're about to get into here. Amazon Web Services gives us a staggering number of switches, account structures, identity models, network topologies, encryption strategies, governance policies. None of them are especially hard to flip individually, but knowing which combination to use for the best outcome, while balancing a variety of aspects, resiliency, security, cost, efficiency, sustainability, that's where pro-level solutions architects earn their keep. I'm Scott, and this is the AWS Solutions Architect Professional Course. Let's get into it.

0:00All right, here we go. This is the AWS Certification Landscape, but chances are you probably already knew that because hopefully you have been researching this certification right here. That's why you have arrived at this course. But I did want to point out a few things here. Well, first of all, I wanted to point out that the machine learning specialty, its days are numbered or it has been completely removed. It has been replaced by the Gen AI developer there. And these right here comprise the pro level certifications for AWS and an AWS certifications pro level is the highest level of certification. That means they're the most challenging exams to take. And having taken all of these exams right here, I would say the solutions architect is probably for me anyway, it was the most challenging because it covers so much territory. And I say all this to say that if you're coming into this course without some of this experience down here, that you would develop going through one of these associate certifications, then I would highly recommend just put this course to the side, put it on the shelf, go pursue one of these down here, and then come back and try for your

1:15solutions architect professional. The reason is because there is knowledge that you are going to develop in these associate level certifications that are going to help you greatly in a professional level exam. And I am going to assume that you already have a lot of that knowledge that you should have developed either pursuing these certifications, or maybe just through hands-on work that you've done through on the job training or something like that. Now, how do you know if you're ready for this course? Well, if you read this sentence or this phrase here, your application needs to fail over across regions with submitted RPO, serve traffic from the nearest edge, and keep a consistent session state in DynamoDB Global Tables. If you do not understand anything in that particular sentence, then maybe you're not ready for this course. But if you kind of understand most of those things, and you can tell me what RPO is, you can tell me what DynamoDB, more specifically, what's a global table versus a kind of normal table, then I think you're ready for this course.

2:23Now, if you have looked at the exam blueprint, you have seen these, no doubt. We have domains. The exam blueprint is broken up into domains, organizational complexity, design for new solutions, continuous improvement, migration, and modernization. And roughly they're 25% or a quarter of the exam material each. This is all well and good. This is very cute. But never in the history of job interviews has anybody ever asked, hey, tell me about domain one. Tell me about domain three.

3:00No, people don't think like that. The real world doesn't work in domains like this. And so this course is not going to be organized around these domains. These domains are for exam developers and exam question writers. They are not for practitioners. You want to be a practitioner. You do not want to be just an exam passer. So we are going to cover all this stuff in due time, but we're going to cover it through some scenarios. We're not going to march through domain one, then domain two, and domain three, because what I've found is that's not a really logical way to cover stuff. And it doesn't really mirror how people design things in the real world. What is in scope?

3:42Well, it's probably easier to say what is out of scope for this exam. And this is one of the reasons why this is the most difficult AWS exam out there, in my opinion. Out of scope, game lift. That's it. Everything else, everything else is in scope. That means it is fair game to show up on questions in that exam. So we have to have a very broad understanding of AWS and more specifically, not just what those services are, but specifically where to use them and how to optimize them. And sadly, game lift is not in scope. Maybe they'll come out with a game lift certification or something like that. I don't know. What is this course not? Again, kind of the same way that I would say it's easier to say out of scope. It's probably easier to say what this course is not.

4:37This is not a course where I'm going to step you through VPC basics. I'm not going to step you through here's a VPC, here's subnets, that sort of thing. You should already come to the table knowing that stuff. You should already come to the table knowing S3 buckets and different storage classes, for example. You should already know how to launch an EC2 instance. And if you don't, that's okay. I'm just saying that the prerequisite for you to jump right in into this course is having a good set of AWS knowledge. If you're coming to the table with nothing from AWS, this is not the course for you. That doesn't mean that this is not the course at some point in the future for you. That just means that you're going to have to go elsewhere to develop that foundational knowledge and then come back here when you have that mastery. So I mentioned that we are going to do this learning here. There we go. Let me get rid of that. We are going to do this learning process here. We're going to learn all this stuff through some scenarios and to help facilitate that, I have created a fictitious company. That company is called Dip Switch Industries. And if you don't know, a dip switch looks like this. And these were used all over

5:52in electronics back in the 80s and 90s. They were on motherboards. They were on arcade machines. I think in some cases they're still on garage door openers today. These are little connectors here, and it has this little switch that you can switch on and off. And it allows electrons to flow through there or not flow through there, depending on what your switch setting is. So that is a dip switch. But our company here is Dip Switch Industries. They are a vintage arcade game company. They have a trusty old PHP site that's been running on their Colo server since 2009.

6:28They have three divisions, but right now they only have one AWS account. And guess what? Their root credentials are on a post-it note that's stuck to somebody's monitor. Does this sound like a company you know? Well, of course it does. I'm sure there's hundreds and thousands of companies out there just like that. All right. So here's the three divisions. They have a marketplace division. That's where they auction off parts. They have roughly 40,000 collectors that use that marketplace. We have a restoration division, and they have three cities with places where you can bring in your vintage arcade games, and they will restore them. And then they also have an events division. And this is for hosting corporate parties and tournaments and stuff like that.

7:14And each one of these divisions has specific needs. And through the course of this course, we will get to know each of these divisions, what their challenges are, and what we need to build them on AWS to optimize their type of business. Here's the situation. And no, I'm not talking about a cringeworthy reality TV show personality. I am talking about here is the situation we find ourselves in right now. We have that one AWS account and that root password is on a post-it.

7:48Here is the prerequisite. I want you to go out there and create an AWS account. I am not going to show you how to create an AWS account. You should already know how to do that. But for your starting point, I want you to create one AWS account and you're going to log in as root, but we're going to change that quickly through this first skill, but you should have root access. I understand that maybe you're part of an organization and maybe your organization has created a sandbox account for you, maybe under AWS organizations. That's okay too, but you're going to be somewhat limited with what you can do because my bet is when they created that AWS organization setup, they probably implemented some SCPs and we will cover SCPs in due time, but they probably implemented some security measures that may prevent you from doing some of the stuff we're going to do. So I would really recommend just create an account on your own.

8:45And when the course is over, you can delete it. And most of the stuff we're going to be doing is in the free tier. There's a few things that may cost you a few cents a month or something like that. But anyway, that is one of the prerequisites. They have some public S3 buckets, they have an IAM user admin, and they don't rotate the keys. They have no cloud trail, they have no budget, they have no guardrails. We are going to fix all this.

0:00All right, so I am going to call this video the readme.md file for this course. And it's basically how to use this course and some of the methods that we are going to use going through this course. And one of the things I like to use here up front in a lot of my courses is something called Bloom's Taxonomy. And what it is, is this just a way to describe how people learn. And the way to read it here is down here at the bottom, remember, that's kind of the most foundational way of learning, that's memorization, that sort of thing.

0:34Then you have to understand it and then you have to apply it. If you've ever heard the phrase, see one, do one, teach one, that's kind of this progression right here to apply. And then beyond that, you can analyze a problem, you can evaluate a problem. And then eventually you're able to create your own material. This is stuff made of whole cloth, for example. A lot of folks, when they come into AWS and they start talking about certifications and they go through some of the base level certifications like the practitioner or maybe even the associates, they focus a lot on this stage right here.

1:10Maybe this stage also, but I think a lot of people spend way too much time trying to memorize stuff in AWS. Not once have I ever been asked, okay, what is the EC2 machine type that has eight gigabytes of RAM and four vCPUs or something like that? That is not something that a employer should find valuable. If you get asked that question in an interview, I would probably decline that job because I'm not sure I would wanna work there. No, what employers are really after is can you apply this stuff at a minimum?

1:46More likely, if you're going for maybe a senior architecture role, can you analyze, evaluate, and create new architectures based on your abilities and knowledge? So going through this course, we are not gonna spend any time at all on this stuff down here. I mean, maybe I'll explain how something works if it's something that's maybe not very obvious, but we are going to focus mostly on the apply, analyze, and evaluate, everything above understand. My learning philosophy is more of a crawl, walk, run.

2:19I wanna start simple and then we're gonna build upon that. So one of the things that you will notice here through our different projects that we're going to undertake is we are going to start, and then that project is gonna carry over across multiple skills. So it's really, really hard if you just wanna dive into one skill right in the middle of the course, you're not gonna have some of the stuff that we've built previously. And I think that's very important because again, this mirrors how the real world works. You don't just get dropped in to click a few buttons here and there.

2:50You have to build something. You have to architect something and design it, and then actually put it into practice and then test it. So that's what we are going to do. We are gonna start simple and we're gonna build upon those things. You have to do this work. You're not gonna learn anything by just kicking back and watching me click around. You have to do this. And if you have to pause the video and figure it out, that's perfectly fine. I can tell you that you are going to become frustrated at one point or another in this course. That's part of the learning process. You may become frustrated at me.

3:21You may become frustrated at AWS, but that's part of the learning process because we all have to go through that, those kind of storm clouds to get to the sunny skies on the other side. So I do want you to follow along with me, but I also want you to feel free to make this your own. That's where the real learning happens. Anybody can just follow a recipe and you can just follow where I'm clicking and where I'm not clicking and stuff like that, but that's not really learning. Where real learning happens, especially if we go back here to Bloom's Taxonomy, is you take that stuff and you can apply it and analyze it on your own.

3:58You can apply it to your own problems. So a lot of students that I've talked to will take this stuff and they'll use it as a guideline and maybe they'll create a version that is applicable to something in their organization or some challenge that they have faced. And all this stuff is really good stuff for a portfolio. So I would really encourage you to build some sort of online portfolio and all the stuff we're doing, all the diagrams, any of the scripts or anything like that, record that, write that down, do a little blog post or something like that and record that in your portfolio and attach that portfolio via hyperlink or something like that to your resume because that is going to be very, very valuable because yes, they can see on your portfolio or on your resume that maybe you passed this certification, but if you can actually show them what you can do, that's a much better demonstration of your capabilities.

4:53And that's why I want to organize this course in portfolio projects because it's real stuff that you can show an employer. Really, think of the certification as just a pleasant side effect. This is not the end game. The certification is not the end game. Your knowledge is the end game and that's what AWS wants you to have. They don't just want you to have a piece of paper that says, yeah, I passed. They want you to have that knowledge. And each project that we are going to undertake spans multiple skills.

5:25And what I mean by that is we are not going to do a project that covers domain one and then another one that covers domain two. No, these are going to be cross-functional projects. Now, they're each gonna have a theme, but we're going to be working across all those domains for all these projects. So here are the projects. So the first project we're going to call FreePlay and that's going to be primarily a governance and identity-based project. We're gonna have multiplayer mode, which is gonna be a multi-region application.

5:56We're gonna have level up, which is a migration and modernization. And finally, we're gonna have cost security operations and we're gonna cover that under something we're calling the final boss. Now, I wanted to mention something else that trips people up all the time, especially if you've been in the industry a while and you've been working with AWS for a while. And it's something that I call the practitioner's curse. And this is the situation where you get into where you've been working on AWS for a long time in a practical setting. Then you sit down to take the exam and you're like, well, the exam is saying this answer, but in reality, I know it's this other answer.

6:33You have to leave that experience at the door when you go into the exam. I know it sucks, but it's just reality because the exam lives in this nice little walled garden inside AWS. It doesn't have to worry about any other clouds. It doesn't have to worry about any other legacy systems. So it is important to keep that in mind. Oftentimes, real world experience diverges from the answer that the AWS test writers want you to select.

7:03So you have to be very, very careful of that. And I'll try to call this out when this happens. So I just wanted to mention it because it's something that trips a lot of people up. They'll go into that exam saying, yeah, I have 10 years of AWS experience and I've used all the services and they go in there and they don't do well on the exam because they are bringing that experience in there when the exam itself is written in a very different way.

0:00All right, enough jibber jabber. Let's go start building. What we're building today is we are going to build an AWS organization. You're going to start with the account that I told you to create. You already have an account, or you will soon have an account that you have created on your own. We're going to log in as root and we're going to set up AWS organizations. Now a lot of courses save this to the very end. Like it's really, really difficult. No, no, it's not difficult at all to set up AWS organizations. Plus it enables a lot of other stuff that we can do. And when you're dealing with a pro level implementation, then you're most likely going to have AWS organizations in there because you're going to have multiple accounts.

0:38We do not want to use one account for everything. That's how an amateur does it. A pro does it with multiple accounts. So AWS organizations is going to help us set that up. We are also going to implement our first OU and some workload accounts. What is an OU? Organizational unit. I'll talk about that in a second. We're going to implement organization-wide cloud trail. We are going to set up a budget alert. We are also going to set up IAM identity center. The old school way is you create IAM accounts and you just log in there. No, no, no. That's not the way we do it today.

1:12Today we use IAM identity center. Now, yes, of course, you can still create IAM accounts. I don't like to do it. There are certain services that force us to do that, like code commit, for example, but the modern way of logging into our accounts is using some federation or IAM identity center. And we are going to say goodbye to our root user. Now we can't delete it, but we are not going to use it ever again in this course, because as a best practice, you should not use your root credentials to do much of anything.

1:46There are a few things, very few things that you must do with your root account. But what I want you to do is take that little multi-factor authentication key that you've set up for your root IAM, put it away, put it in a drawer, put it in a safe somewhere. And we are not going to use that. Instead, we are going to use our IAM identity center login to do all the stuff we need. So here is our target OU structure. We need a management account, and that is the account that I am telling you to create.

2:18That is going to assume the role of a management account. We are then going to create some different OUs down here. Now this follows AWS best practices. They say we should really create a security OU and an infrastructure OU, just to keep that stuff separate. Then we have our workloads and then we have our sandbox. Now you're free to create your OUs however you like. I've seen some people create it based on the divisions in their organization or maybe geographies. That's a really good way of doing it because a lot of times maybe you have different policies or different security measures that you have to implement across different geographies. But for us, for our dip switch industries company, we are going to create an infrastructure OU and then we're going to have an infrastructure account, a security account. And then for our workloads, we're going to have the three divisions down here, marketplace restoration and events. And then in our sandbox here, we're just going to have a sandbox account that we can just do experimental stuff. That is what we are going to create in skill number one.

3:21All right, so let's create an AWS organization. So here I am logged into my management account. This is going to be our kind of top level account. This is the account that you created. So to create an organization, it's pretty easy. We just go over here to AWS organizations and we create an organization. Now notice that this is a global service. So it doesn't really matter which region you start in to do this, but here it gives us some recommendations here.

3:51This account will become the management account. So in other words, the account you are logged in as will be the management account. And you cannot change that management account. Once this organization is created, what you actually have to do if you want to change the management account is you have to create a new organization, create a new account, go in there, create a new organization, then move all your stuff over. Then you can go back and delete this AWS organization. So we're going to create an organization. That's it. That's all we have to do to create an AWS organization.

4:24Now, if you look down here, it started us off with the root of our structure here, our organizational units, our OUs, and it put our account right there in the root. In the next video, what we are going to do is we're going to build out these OUs. To resemble what we showed in the slide earlier in this video.

0:00All right, let's create some OU. So, if we go back to our structure here, we have our management account, and we wanted to create a security OU, an infrastructure OU, workloads, and sandbox. So, to do that, we just go back out here to our AWS account, and we can click down here. Oops, we got to check that little box right there, and click down here, create a new organizational unit. So, let's create security first, create that, and look at that. So, it just drops it as a, basically, kind of like a subdirectory underneath this.

0:32Now, this hierarchy is important, and it doesn't, it's not something that we can't change in the future, but how we are going to arrange this has some implications later in how we choose to manage our accounts. But for right now, let's just create all the accounts that we need to here. Let's create another OU right here, and we'll call that infrastructure. Create that, click that again, and create new, and we're going to call this workloads.

1:03And the reason I'm calling it workloads is because there's kind of a best practice, maybe an unwritten rule, I'm not really sure what it is, but basically, we do not use this management account for anything. It is off limits for us to use for any sort of production workloads. Well, I mean, we can use it, but it's not best practice too. Think about it kind of like the landlord of our organization. Now, the landlord really doesn't live in the apartments. They live someplace else, but they take care of the apartments.

1:34So that's what this management account does. So we have infrastructure that's going to contain all of our infrastructure, all our stuff that we need to operate our business. We also have security, which is going to be focused on where we keep security stuff. And then we have workloads. Now, this is where we are going to put our workloads for different divisions. So underneath this one, I want to create three additional OUs here. Let's call the first one, if we go back over here, marketplace.

2:07And I'm going to create another one here. And we'll call this restoration. And then finally, we'll create a third one here called events. All right. So what we have here is we have our workloads, then we have our OUs here. Now, mind you, there are no accounts in these. This is just a logical organization of, think about it kind of like folders. Okay, let's say that maybe I created one by accident or maybe in the wrong place.

2:40Well, I can click on that and I can come up here and I can click on the account. I can click on that and I can come up here and I can rename it or I can just delete it. Now, notice I can't move it because these things aren't really things. They're just kind of imaginary metadata. So what we can move is accounts. That's the important thing. We can put these accounts in these different OUs and depending on which OU it is in, maybe it inherits certain abilities or inabilities to do stuff.

3:11So let's create our last one right here. Let's go up here, create new, and we're going to create a sandbox. Now, you may think sandbox, oh, that's just for playing around. Well, yes, but it also has an important function here because there are certain things that we can implement that apply to the OU. And we would not necessarily want to implement those things without testing them first. So if I were to implement an SCP, for example, and again, we're going to get to what an SCP is later.

3:43But if I were to implement an SCP here and apply it and it has some bugs or maybe I configured something wrong, I want to find that out in a non-production OU. So we can use sandbox for that. I've also seen people create specific testing OUs, which is perfectly fine as well. And there are a variety of ways that you can arrange these. You can arrange these based on workloads like we did, where we're just calling out the different division workloads. You can also arrange these as dev, prod, QA, and we can even create sub-OUs here of whatever we want.

4:18So there are many, many different ways to arrange your organizational structure. This is just one. Just to satisfy my OCD here, I don't really like anything hanging out at the root. And right now our management account is hanging out at the root. So I'm going to create a new organizational unit called management. And I'm going to move my account right here into management. So I'm going to go down here, move. And then I'm going to say, hey, I want you to go into management there, move account.

4:48And it has just moved that account into management. Next, we need to create some accounts. Now, I am going to not create every single account and make you watch me do that. I'm just going to do one here. And then you can just replicate that. So we want to create an account for infrastructure. We want to create an account for sandbox, security, so forth and so on. And down here for events and marketplace and restoration, I'm going to create an account for each one of those. Now, you may be thinking that's a lot of accounts. Well, yeah, that is a lot of accounts.

5:19But that is a best practice when you're dealing with a complex implementation. You want multiple accounts. And there's a variety of reasons. And we'll get into that, why you would want multiple accounts. First and foremost, it limits your blast radius. So if you make a mistake in one account, it's not going to wipe your organization out. It's just going to be limited. The damage is going to be limited to that one account. So let's go up here. And we can click add an AWS account. And we can invite an existing account.

5:50Maybe you have existing accounts. You can invite them to join your AWS organization. Or we can create a new one. So let's create one down here that says events. And now we have to give it an email address. This email address has to be unique. It cannot be used on another account. So there's a little trick here. Depending on your mail system, there's a trick that you can use that I've used pretty successfully with most mail systems. And that is to add a little plus here. So my address is spletcher at cbtnuggets.com.

6:22So spletcher plus. And then I'm going to say CSA events. That's Certified Solutions Architect Professional Events at cbtnuggets.com. And I'm going to leave this organizational role the same there. And I'm going to click AWS account, create account. And that is going to create an account. Now it's going to take a few minutes for that account to be created. And I'm just going to pause the video and wait for that to show up. But what's going to happen here is it's going to show up right here under root.

6:54And we are going to then move that. While I'm waiting for that, I'm going to go ahead and create all my other accounts and you should do the same as well. I'm just going to put you on pause right now until that account shows up and I'll show you how to move it. Okay, so I have created all my accounts. Now notice up here, I had one account creation request fail. And that was because the email that I entered, I had apparently already used that someplace else. So that's just something that can happen if you don't use a unique email.

7:25So I use that little trick, that plus trick to create unique emails. Now you're looking at this organization, you're saying, hey, where are my accounts? Well, if you click on list over here, here are your accounts. One of the things that I want to call out right up front, look at all these numbers. Oh my goodness, he's showing his account numbers. I don't really worry about it. AWS themselves said that they do not consider account numbers to be sensitive or something that needs to be hidden. Unless of course you are a consultant and you are creating publicly facing documents and you are using your account at that company to demonstrate stuff or create blog articles or something like that.

8:04I wouldn't want my customers' account numbers floating around out there. But these are my own account numbers and I know how to secure my systems well enough that that doesn't frighten me. Just a note here that you will see my account numbers throughout. And I'm not gonna go to the trouble of blurring them out because you really can't do much with them. If you secure your accounts properly. Here are my accounts. Now I am going to move these things into their respective OU.

8:36So I'm gonna click on Sandbox there and I'm gonna move that into that OU right there. And then I am just going to repeat that process. And I'm not gonna show you each and every one. I'll show you one more here. Move and we're gonna hand this over to infrastructure. And then you can see down here if we expand that out, our infrastructure account is under our infrastructure OU. So what we want is all those accounts all in their respective OU.

0:00All right, so now our accounts have been created. They are in their respective OUs. The next thing I want to do is enable CloudTrail, and CloudTrail is going to log all API calls in and out of our accounts. So to get there, I'm just going to navigate over to CloudTrail. I'm going to not click on that little button down here that says create a trail. Instead, I'm going to go over here to trails, and that is a weird looking layout there. But anyway, I'm going to click on create trail, and let's just call this management events, the default. And I also want to enable for all accounts in my organization. There is some debate as to whether you should use your management account for CloudTrail, or maybe create a separate logging account. I'm kind of more in favor of creating a separate logging account, because then we could direct all those logs to that account and not have any other access into that account. So we can assure that our logs are not going to be tampered with and kind of maintain the integrity of those. But in our case, I think that's a bit much. But just know that if you're doing this for a large organization, that's probably a better way to go is you just create another account for logging, and then you would set up CloudTrail in that account and configure

1:16all your other accounts to route to that logging account there. So this is going to do it for us by checking that little box there. And we're going to go down here, we can create our own S3 bucket, or use an existing one, I'm just going to use an existing one here, I'm going to uncheck this encryption here, the SSE KMS encryption, I don't really need that log file validation, I don't really need that either. But you can absolutely enable that if you want to. And I would really recommend enabling encryption here. Here's one call out is that you definitely want to use a bucket key. If you're using a customer managed KMS key, then every single log activity writing out to that bucket is going to use up one of those API calls. And that can get very, very pricey. So definitely look into a bucket key, if you're doing that. And let's see everything else looks good. Let's try that. And I just want to record management events, you can absolutely record these other events if you want to. But I would recommend that you spend some time thinking through your log management strategy, you probably don't want to keep all that stuff out there indefinitely, because it could really rack up a lot of gigabytes on S3 and end up costing us some big money. So let's just leave everything default here. There we go, create trail. Alright, so it's

2:37going to go out and do its thing. Now, it's also in the background, deploying that configuration to all those other organizations, those other OUs and those other accounts. And they are going to be piping their stuff to this log. So I doubt we'll have anything out there right now. Yeah, we don't have anything out there. It usually takes maybe five to 10 minutes to start seeing stuff out here. And of course, it's also dependent on how much API activity you have going on with your account.

3:08So next, what we want to do is we want to hop over to the cost management area down in billing and cost management, and we want to create a budget for ourselves. So let's get rid of that. And we're going to go down here onto budgets right there. And we're going to create a budget. And we can use a template here, we'll just use that. And you have different templates that you can pick from here, a zero spend budget, that is good if you want to be sure that you're staying within the free tier. But I will say that's really hard to do. There's a few things, even if you have some objects out on S3, you're probably going to end up spending at least a penny. So zero budget, I usually don't use, I will use a monthly cost budget. And we'll just leave it at 100 bucks, 50 bucks, whatever you want. And what it's going to do is there's a few different conditions that it's going to notify you. Well, first, if you go beyond that budget, that monthly budget, it's going to email you and say, Hey, you've gone beyond $100 a month. Second, if it looks like you are trending to exceed that budget, it will email you as well. So let's just set up an email here and create the budget. There we go. It's as easy as that. We have enabled CloudTrail, we've enabled a budget. Next, we need to set up IAM Identity Center.

0:00Okay, so back in the olden days, we used to come out here to IAM and we'd create IAM users and we would dole them out and people would have access keys and passwords and stuff like that. But no, we don't want to do that anymore. Right here it says managing human user access accounts, there's a better way and it kind of guides us toward Identity Center right here. And that is a smart move because we don't want to manage IAM users anymore. There are cases where you just can't help it. You have to do that. But in most cases, if we're dealing with people logging into our account like us, then we don't have to do that. One of the things I'll point out here is we get this big easy button right over here, enable, but the region that you're in does make a difference. There are certain products in AWS that integrate with Identity Center that are not necessarily compatible if you have Identity Center set up in a different region. So if you are considering WorkMail, for example, I think WorkMail right now is only available in U.S. East 1 and U.S. West 2 and then it has some location over in Europe. So if you enable that and you want to enable federated logins into WorkMail and make it really easy on yourself there, if you have your IAM Identity Center set up in Ohio, then that's not going to work. I don't really care. I've found

1:20very few cases where that is a problem. And even if that is a problem, you can still set up logins just with a little additional configuration. So I tend to work in U.S. East 2 because that's a relatively new region and it doesn't have some of the cobwebs and baggage that U.S. East 1 does have. Plus it's closer to me geographically. So we are just going to click on enable right there and it's going to say, hey, is this the right region? Really, you want your AWS region to be whichever region is closest to you. Click on enable. And in a few minutes, oh, a few seconds rather, we have enabled AWS IAM Identity Center. And this is our own little registry that we can create users in. So if we scroll down here, we have our access portal. This is a URL that we can click on and it's going to bring us to our own customized login page. Now, if we were in a huge organization, maybe an organization that already had an identity provider like Okta, Google, or Encarta or something like that, then we can absolutely integrate that in as well. We just happen to be using Identity Center here because it's built into AWS. So first things first, let's

2:36create some users, actually a user. So I'm going to create my user right here. I'm going to give it my email address here and fill out some information here. And it gives me a display name. Now, it also has some other details here, and this would be important if you are setting up this as a directory. And there are some other things in here that we're going to deal with later down the road. If we wanted to use attribute-based authorization, for example, we could set some attributes here.

3:08We can set our department, our region, or whatever. So I think this is all I need. I'm going to click on next, and it's going to say, hey, what group do I want to assign this to? Well, I don't have any groups, so let me create a group. And I'm just going to call this admins, create that group. And if I go back over here, refresh, I'm going to add that to the admins group and add user. It is going to email that address that we entered there, and it's going to give us a hyperlink to click on. We're going to be prompted for entering a password and also MFA. So I'm going to move over to my email box, and I'm going to set my password and MFA for this particular user right now. And I'm just going to pause while I do that. All right, so I have set up my user right here, and it also asked me to set up an MFA method. Now, best practice is absolutely set up MFA. That should be non-negotiable, but I would probably set up multiple types of MFA. I happen to use YubiKeys, so I have several YubiKeys that I can set up there as my MFA device. I also use Bitwarden for my password vault, and I can set that up as a passkey as well. And of course,

4:26you have the one-time codes, that sort of thing. Now, one of the things I think you'll realize here, if we go under security, and let's say register device. One of the things you'll notice here is we do not have an option for SMS, and that is because SMS is not really secure. People can steal your phone number, they can hijack your SMS, that sort of thing, and AWS really doesn't support it. So we have authenticator app, security key, and a built-in authenticator. Maybe that's something like a fingerprint reader on your computer. But one of the things you'll notice here, so if we go back to our access portal, there we go, we do not have access to any accounts, and we do not have access to any applications. That's because we haven't set ourselves up to have that.

5:14So let's go back over here, and we're going to go down to permission sets, and this is how we can define what sort of permissions we're going to be allowed to have in our various accounts. Now, you can create very detailed permission sets. There are some predefined ones that I tend to use. So here are the predefined ones down here, and these kind of go along with different roles, but we want administrator access right here. So we're going to click on next, and for session duration, what I want to do is change this to eight hours. Normally, you want this session duration as short as possible. What this means is it is going to give you authorization, that authorization, this admin access for a period of session duration. So for a period of one hour, and then after one hour, you're going to have to re-authenticate yourself. You're going to have to log in again, but oftentimes I'm out here in the console for longer than that. So I just want to make this eight hours. I can also do a custom duration as well. The smaller, the more secure, the longer, the more dangerous it gets, but I definitely wouldn't have it past maybe 12 hours or something like that, and there are many other layers of security we can add on, such as geography. We can

6:32see if somebody is logging in from maybe a strange device, and we can block that log in there, but that's something for another day. We're not going to cover that right now. So click on next, and create. So we've just created this permission set right here, and then we can assign this permission set to our groups and or our users, and then also assign that to our accounts right here. So let's hop over to AWS accounts, and look at that. There's our AWS organization right there, and I want to assign users or groups. Oops, do that. Let's do all the accounts, assign users or groups, and we can assign users here or groups. I'm just going to use groups right there. Click on next, then it's going to ask us what permission set do we want to use. So this is going to allow that user, my user, administrator access to all seven accounts there, and that's exactly what I want. So click on next, and little confirmation screen, submit, and it's going to take a little while to deploy all this security. So we just, well, I guess it's done. That was quick. That's the fastest I've ever seen it deploy to seven accounts. So anyway, we have been provisioned for all those accounts. Now,

7:48notice you can do this by account. We can't really do it by OU, so that's a little bit of a quirk there. So now let's go back over here to our accounts, and we can either log out or log back in, or we can refresh, and look at that. We have all of our accounts, and we can click this little thing right here, and if we had more than one permission set assigned to us, we could see those down here. So for example, if we had billing assigned to us, we would see administrator access, then underneath that, billing, and whenever we click on that, that is going to log us in to that particular account with that access. Now also over here, we can click on access keys, and we can see how we can add access keys to maybe our CLI work. If you're doing CLI work, you would probably not use access keys here. There are some cases where you could, but I would probably set up the AWS SSO login, and that is going to take you to this little landing page.

8:45Let me go back over here. Dashboard is going to take you to this landing page right over here, and it is going to prompt you for logging in. So as a matter of fact, we can change this here. Let's say Fletcher CSAP. There we go. CSAP, and you just have to be sure that this is indeed unique, because you can't have what somebody else already has. So there we go. So we have an IPv4 only, and then we have a dual stack here, and if we click on that, it's going to take us over to our AWS portal here. Now I've already logged in, and because it's within eight hours, it's just going to go ahead and log me back in there. This is what I want you to set up, and this is the method we are going to use to get into our accounts, and we are going to say bye-bye to our root account in the next video.

0:00One last thing that we need to do before we say goodbye to our root account access, we're going to go over here and go into account. I'm going to have to blur out some of this screen because it shows some private contact information here. But from this screen, what you're going to do is scroll down, keep scrolling, keep scrolling, keep scrolling. There we go. We want to enable the IAM user enroll access for billing information. And this is going to let us see the spending on our account from our IAM identity center users. So let's click on edit, click on that, click on update. And then we have completed that access. So from here on out, we should be able to see the information, the cost information for what charges are being charged to this account. Now, just to double check here, let's go over here to security credentials and I want to be sure that we have MFA enabled. And there we do. You definitely want to have some MFA method enabled. Ideally, you're going to have one that is accessible by a few different people, because if one person's out on vacation or something like that, you don't want to have to wait until that person comes back from vacation to get the credentials to log in.

1:19So what I've seen here is you can either use some sort of password manager where you can share the credentials, or you can use a hardware token that gets kept in a central location in a vault or something like that. But there are several different ways to do that. And I would highly recommend, especially in production situations or production accounts, that you have several MFA alternatives in there.

0:00All right, let's go through these questions. Now at the end of every skill, I'm going to have a little question walk-through here where I walk through the validation questions and just give you my tips and tricks on how to maybe better approach these questions. And these are exam style questions. They're absolutely not the real exam questions. That would be completely unethical of me to share and I can get in big trouble. So never will you see any of the questions that are on the exam. These are just from my experience over the years of taking many AWS exams. Here's some of the tricks that they try to use to throw you off. And first off, here's one of the tricks, especially on the pro level exams, they have very long questions. And one of the important components of the pro level exams is time management. So they throw in these long questions just to kind of slow you down. I know it sounds a little devious and stuff, and it probably is, but the idea here is they want you to be able to know this stuff well enough that you can read through this and arrive at the right answer relatively quickly versus spending a whole lot of time. So that's why they include these things. And the second reason is they have to kind of build some rather complex scenarios to be able to test that you have that knowledge. So here we go. The first

1:17question. One of the things that I like to do is not read all this other stuff first. I'll go to the very end and try to figure out what exactly are they asking me? Which CloudTrail configuration achieves this? Okay. So I now know that we're talking about CloudTrail. Now I can go back up here and read through these things that are CloudTrail appropriate, or maybe relevant to CloudTrail. So a company, AWS organizations, they have some OUs with two member accounts. The security team wants to ensure that all API activity, well, that's exactly what CloudTrail does across every account, including any accounts created in the future, is captured without requiring any setup in the member accounts themselves. Now we are posed with four possible answers here. So let's start at the top here. Enable CloudTrail in an independent account outside the organization, which aggregates events. So I don't really think this is a good idea because we could absolutely do this, but why would we create an account outside of our organizations if our main priority was to manage the accounts inside that? So I'm going to just kind of X through that. I don't think that's a possible answer. Now, just like that, we're down to three. Create a trail in each member account configured to deliver logs to the shared S3 bucket. Well, that is a possibility.

2:37That is absolutely a possibility that we could do that, but what they're asking for up here is captured without requiring any setup in member account services themselves, especially in the future accounts. So if we were to do this, then we'd have to remember to go back out there every time we created a new account and set up that CloudTrail sending to that S3 bucket. So that is not going to fulfill our requirements. Create a trail in the management account that captures only management account events. Well, that doesn't make sense at all. I can probably eliminate that right off the bat because if I'm just capturing the management account events, then I'm not capturing the underling accounts. I don't know what you want to call it. The sub accounts, I guess. Use event bridge rules to do some other stuff. No, no, no, no. That's not a way. And that kind of leaves us with this option down here. Create an organization trail in the management account, which automatically captures management events from all current. Yes, this is the answer that I like. That's what I'm sticking to. Next question. Same deal here.

3:42Which response best describes the operational advantage of IAM Identity Center over manually configured cross account roles? You'll see this occasionally on AWS exam questions. They'll give you some possible answers down here and they'll ask you what is the best answer. And that's really important. And here's one of the cases where your practitioner's curse can kind of creep in there, because as you're reading through these things, you may say, hey, that's a perfectly valid way of doing this. And that's actually preferred when we're talking about maybe a multi-cloud environment.

4:16Well, you got to remember that AWS doesn't even acknowledge the fact that, hey, there's other clouds out there. It's certainly not in the exam setting. They certainly don't do that. But let's take a look here. IAM Identity Center credentials are encrypted with stronger algorithms. No, that's not true. We can get rid of that one right there. IAM Identity Center issues credentials that last 24 hours. Well, yeah, we could have credentials that last 24 hours while STS assume rule credentials expire after one hour and cannot be extended. Well, let's think about that.

4:50STS, that's a way to get temporary credentials. And that's one of those things that hopefully you should have learned about in one of the other courses or some of your earlier AWS work. STS, generally used to get short-term or temporary access to AWS and allowing some, maybe it's a CLI or some other script or something like that, to be able to assume a role. And it says here it expires after an hour and cannot be extended. Well, that's not the case. That is a falsehood right there. They absolutely can be extended. Well, they can be configured to be a certain duration and is definitely longer than an hour. It defaults to an hour, but you can have something that lasts longer than an hour. So just by the fact of we have a false statement in our answer here, we can eliminate that whole answer. So now, even if we're just guessing, we have a 50% chance. IAM provides a unified SSO portal where users authenticate once and see all the accounts and permissions available to them. Yes, that is exactly what IAM does. So that's a good answer right there. Let's keep on going because maybe there's a better answer. IAM Identity Center bypasses the need for MFA on cross-account access while STS assumes roles and always requires MFA.

6:10Okay. Well, this is maybe, I mean, I suppose you could, if you kind of squint, you could see that maybe that could be a possible answer, but that is not a good answer because STS assume rule does not always require MFA. Because think about it, if you're using STS in a script or something like that to grab some automated credentials, some short-term credentials, and you're prompted for an MFA, well, that's not going to work. The best answer here is this answer right there. Last question. All right. Which statement accurately describes the purpose of creating an OU structure early in this stage? They've just enabled AWS organizations much like our organization and they created a single workloads OU with one member account. All right. That's a good start.

6:57The organization currently only has two accounts total. So why would we bother setting up AWS organizations at this point? That's what they're asking us about. As a matter of fact, AWS says, hey, yeah, it's a best practice to set up AWS organizations if you have more than one account. Why? Why is that? So let's start at the bottom here. OUs provide the structure for applying governance policies to groups of accounts as the organization grows. Yes, that is a very strong answer right there. I'm going to put a little check beside that one. Let's keep going up. OUs are required by AWS organizations. You cannot create member accounts without first creating at least one OU to place them in. Well, no, this is not a true statement because if you remember, we created our AWS organization. We had root and we really didn't have any OUs underneath that.

7:46We could continue to create accounts, as many accounts as we want. They would just be sitting there at that top level root. So that is not a true answer here. OUs automatically isolate network traffic between accounts. OK, stop me just right there. That is not a true statement. So we can eliminate that one from consideration. OUs reduce costs by enabling consolidated billing discounts that only apply to accounts within the same OU and not across the entire organization. All right. So we are going to get a little bit more into cost optimization later. But one of the things that we can say right now is, yes, this enables consolidated billing. By default, your management account is the one that is going to pay the bill for all of your other accounts in your AWS organization.

8:32But we can absolutely pay the bills of other accounts under different OUs, under all the OUs, if we wanted to. So that is not a true statement. That second part is not a true statement and leaves this one down here, which is our correct answer. I hope this has been informative for you. And I'd like to thank you for viewing.