Pass Amazon AWS Certified Solutions Architect - Professional Exam in First Attempt Easily

Getting started with the course

1. New Exam Blueprint 2019

Hey everyone and welcome back. In today's video, we will be discussing the new exam blueprint for the AWS Certified Solutions Architect Professional Certification. So, AWS has released a new blueprint for the Solutions Architect Professional Certification, and any exam after February 2019 will be based on the newer blueprint. Now, when you compare this new blueprint with the older one, you will typically find that 60% to 70% of the topics are still overlapping. Now, this certification-based video course is based on the new blueprint, which is suitable for the 2019 Certification Exam and onwards. The following are the five domains that you will find in the Official Blueprint. The first step is to design for organisational complexity, and then to design for a new solution. Then you have migration planning, cost control, and continuous improvement for existing solutions.

So let me quickly show you the official Exam Blueprint. So this is a new Exam Blueprint, and if we go a bit down, you will see that there are five domains that are available. Among these five domains, the domain two andthe domain five constitutes to be the highestin terms of percentage of examination. So if you just combine them, it goes to 60%. So these are the most important domains. Along with that, all the domains are specifically important because professional certification is challenging. So make sure you go through all of the videos that we have as part of the course in all of the domains. Now this exam blueprint is more streamlined.

Now, if you take a look at the older blueprint of the exam, it had eight domains; however, we just have five. Among these, the importance of a well-architected framework cannot be overstated. Now let me quickly show you. Now, if you typically look into the well-architected frameworks, the "pillars," you have operational excellence. You have security, reliability, performance efficiency, and cost optimization. Now, if you look into the domain two, if you see domain two constitutes to be 31% and within the domain two, if you look into 2.2, it states that data minus solution to design and implement strategy to meet reliability requirements. So you have the reliability pillar here. You have the reliability pillar in the well-architected framework as well.

Then you have business continuity. So business continuity is more of a subset of the reliability pillar when you compare it with the well-architected framework. After that, you have the performance. Now, performance is also one of the pillars of the Well-Architected Framework. Then if you go a bit up, there is a security pillar, and you see there is also a security pillar here. Then you have an entire section dedicated to cost control. So there is also a cost optimization pillar in the architecture framework. So it is very important that we understand we're Architected framework before we go ahead for the exams. And this is the reason why, if you go a bit up here, you see it in one of the suggested white if you go Well, an architected framework is present.

Hide

New Domain 1 - Design for Organizational Complexity

1. Multi-Account Strategy for Enterprises

Hey everyone and welcome back. In today's video, we will be discussing the multiaccount strategy in AWS. Now, in one of the recent organisations that I have been working with, we had close to 80 AWS accounts. Now, in order to manage so many AWS accounts, you will need proper planning and a strategy. And hence, as a solutions architect, it is very important for us to know some of the challenges and some of the ways in which you can overcome them when you start working in enterprises. So let's go ahead and understand more about it. Now, a multiple-account strategy is definitely great because it gives you the highest amount of isolation between the resources as well as security. So typically, what many organisations do is have regional-level isolation.

So they have a North Virginia region for development instances; they have an Oregon region for production instances, although that can be sufficient. But it is not a best practise because if someone creates an IAM policy for the developer, and if that is not very isolated, the developer might have access to the production environment. So having multiple accounts is always great to have multiple accounts. As a result, you should keep a separate AWS account for development and another for production, and avoid giving developers access to the production environment except for high-level read-only access. Anyways, when an organisation uses multiple AWS accounts, there are certain considerations that you need to remember, otherwise things will become messy pretty soon. So there are four things that you need to take care of.

One is the identity account architecture, another is the logging account architecture, a third is the publishing account architecture, and a fourth is the billing structure. So let's go ahead and understand each one of them. So the first one is the identity account architecture. So let's say that you have five AWS accounts over here. You do not want to create individual users in each of these accounts. So let's say that I have five accounts, and I have a new person who has joined the team. Now, I can add that username to each of these five AWS accounts, but it will soon become messy. So it is recommended to manage all the users in a centralized place instead of adding each user to an individual AWS account.

Now, this specific architecture of handling the users in a centralized location can be achieved with the help of cross account. I am roles as well as with the federation. We'll be discussing more about this in the upcoming videos. But for this, we just have a high-level overview of what each of these points really means. The second is the logging account structure. So basically it is very important that all the logs should be stored in a centralized place where it can be monitored and analyzed on a regular basis. So if you see over here, I have account A and account B.

Now, account A's cloud trail logs are going to the central account S three bucket, and account B's configlock is going to the central account S three bucket. So this is just for representation. However, the cloud trail log, the config log, the AWSVPC flow log—all of those locks from all your AWS accounts should be stored in a centralised S3 bucket. Now, this centralized SI bucket is from where you can go ahead and analyse the logs on a regular basis.

So maybe if you are using solutions like Splunk, Splunk can fetch the lock from the central SV bucket, and it can go ahead and check for security or other anomalies. Now, the third is the publishing account architecture. Now, this is very important because, let's say, you have multiple AWS accounts. I'll give you some real-world examples. As we discussed, we used to have 80 AWS accounts. Now, what developers used to do in each and every AWS account was have different teams have access, and some people would launch Red Hat instances. Some people will launch Ubuntu; some will launch Amazon Linux; some will launch Sentos. So there is no standardization that is happening. And typically the security team is responsible for providing the hardened image, which many organisations often refer to as the golden image." So it is very important that if you have multiple accounts, you need to ensure that the developer only launches the instances that are security-hardened and approved by the security team.

So that standardisation is extremely important. So you're the publishing account. The architecture really comes into play where you have the EC-2 AMI. So let's say that this EC-2 AMI is being created by the security team. Now, this AMI can be shared across all the accounts, and you can create an IM policy that the development team can only launch new instances if they are from a specific AMI. You can even make use of the service catalogue for such cases.

So, this is the publishing account architecture, and the last one is the billing structure. Now, basically, you can make use of the consolidated billing feature in AWS organisations so that you have a single place to track the entire bill. So here you have a master account, and these are the child accounts that are connected. So you have consolidated billing over here. So the great benefit here is that it is easy to track, it is easy to switch, you can see all the bills, and you have the advantage of the combined usage as well. and there is no extra. We will be discussing this in the relevant videos where we discuss the billing structure. Indeed.

2. Identity Account Architecture

Hey everyone and welcome back. In today's video we will be discussing the identity account architecture in detail. We will also have a small demonstration so that it becomes better understood. Now, typically, small organisations begin the journey with a single AWS account. When you only have one AWS account, management becomes much easier. So let's say a developer wants access to this account. So you can go ahead and create an I m user and password, and you can go ahead and create an access and secret key if required. And if the developer is leaving the organization, you can go ahead and disable the username and password and deactivate the access and secret key. So this part of management is pretty simple. However, when the organisation becomes big, the part about identity becomes quite challenging. So now what we have is multiple AWS accounts.

Now let's assume that you have five AWS accounts, and there is a developer who needs access to each one of them. Now in a simplistic very basic approach what you'll do you create the username and password of the developer in account one, then you create an account two, then in three, then in four and then in five. Similarly, you'll generate the developer's assessment secret key in 1234 and 5. Now that the developer is leaving the organisation again, you'll have to log into all five accounts; you'll have to deactivate the access and secret key; you'll have to disable the user.

Now, this is not a very idle approach because, typically, when an organisation becomes big, they will have hundreds of employees, and you do not really want to add the employee details to each and every A account individually. So in order to solve the problem, you have the architecture of an identity account. So what happens in an identity account is that you have a single dedicated AWS account. In this case, we refer to it as an identity account, and you create the username and password for this specific account. So you create a username and password, and you create a secret key for a single account. You now establish a trust relationship between multiple AWS accounts in your organisation and this identity account. So now what will happen is that the developer will have to log into his identity account, and from here he'll be able to switch and log into various other AWS accounts depending on the permission sets that he has. Now if a new person joins your organization, all you have to do is add him to this identity account. If he leaves the organization, you have to remove him from this identity account, and if you forget the password, all you have to do is reset his password from this single AWS account. So management becomes much simpler in this type of architecture. So for our demo purposes, what we'll be doing is having two accounts.

One will be the identity account, and the second will be the production account. And the user will be created in the identity account rather than the production account. However, we will look into how exactly he'll be able to log in to the production account even without his IAM user being created here. So this type of architecture requires three steps of implementation. Create a user in account A first. So account A is basically the identity account.

Second, create the cross-account role in account B. And third, allow users to switch to account B role. Now, we'll be looking into each of these steps in the next video of the practical session. However, in today's video, I'll quickly give you a demo on what exactly it might look like. So this is the account A will refer to as the identity account. Now, if you see this account ID, it starts with zero377 and ends with "now let me log into this account with the im user that I have created." All right, so I have logged into the identity account. One thing to keep in mind is that if you have a dedicated identity account, make sure that the user does not have any access to the services.

So, if I quickly open up the EC 2-year, you can see that it is giving not authorized permission, and this is the recommended way to ensure that you do not give permission other than switch roles. That will be looking into the next video's identity in the AWS account. Now for the demo session, this is the identity account that the user called Yurt has logged in from. Now he wants to log into a production account. So this is the account that he needs to log into.

So in order to do that, he needs to have a sign-in link. So the sign-in link looks something like this. Now, if you look at the sign-in link, let me actually press Enter. So this is the sign-in link for the production account, which is account B. Now, if you look here, the account number is a little different. It starts with phi a phi, and the role is called Cab. Now we can call it a production account. Here you can put it as a display name, and you can click on "switch roles."

So once you click on "switch roles," what will happen is the user will login to the production account so he'll be able to switch the cross-account role that was created over here. So this is the production account. Now, this is the account where you can give the user the appropriate permission. So let's say that this Yash user wants to have access to all three. Then you can give access to the S3 console to the Yash user.

So currently there are no buckets. So this is how it will look. But s3 access is being granted. So currently I am locked in as an administrator user in the new account, which the year has logged in. If you notice that this account has a sign-in link with the number 585, Now within your I have a role which is created and this role is called as Cap Labs and this role has the Amazon S three read only access and the Yash user has basically assumed this specific role and he has inherited all the permissions which is associated with this role. And since this role has an S three read only access, yash will be able to perform the read only operations in S three. So this is the high-level overview in terms of the architecture of identity. In the next video, we'll start from scratch, and we'll look into how exactly we can go ahead and create the cross-account role for the identity.

3. Creating Cross-Account IAM Roles

Hey everyone and welcome back. In today's video, we'll perform the practical related to the delegation that we were discussing yesterday. So for our practical needs, what are the things that we need is?The first thing is an identity account. So this will be the first AWS account, and on the right hand side, you have one more, which is the production account. So there will be two accounts, which are needed. And we already discussed the overview architecture, where we'll create a user in Account A. We will create a cross-account role in account B and will allow users to switch to the account B role. So a very simple step-by-step methodology So let's begin.

Now here I am in my Google Chrome browser, and this is my first account, which is starting from 871. And along with that, I have one more account. This is running in my Firefox browser, which is starting from 453 as the initial start. Now the account that is running in my Chrome So that will be an identity account, and the account that is running in Firefox will be a production account. So the user is something that we will be creating within our identity account. So let's go to the I. And I already have a certain user which are created for other practical's. I'll create a new user, I'll name him Bob, and I'll give him list management access. I'll go ahead and click on Next, and the user will be created. Perfect.

So now that the user has been created, let's look into the second step. The second step is creating a cross-account role in account B. So let's switch to Account B. And within here, I'll go to Im, select Roles, and then click on Create a Role. Now there are various types of roles that can be created. Since we are going to work with delegation or cross-account access, we'll select another AWS account button. So this is the button that we will be selecting, and within here we will have to put the account ID from which the user will be originating from. The role is getting created in the production account, but the users in the identity account will be assuming this rule. So we have to enter the account ID of this identity account. So in order to find that, I'll go to the support center yet again. I'll copy the account number and I'll paste it over here. I'll select "Next permission."

So let me choose S-3 full access for the permission. I'll click on "next review," and the role name that I'll give is "Cross Account," and I'll go ahead and create a role. Perfect. So our role is created and when you click on the role you will have the role here you will have the link. So this is the link that the user from the identity account needs to be given. and one very important part is the trust relationship. so within the trust relationship. If I click on Edit trust relationship, you will see that the account ID of the identity account is present in the principle, and the action that is permitted is the Sets assumed role. So any principal from this specific account ID, which is the identity account, will be allowed to perform STS assumed roles for this specific role that has been t, will be allow So now we have done the second step as well, and the last step that is needed is to allow the user to switch to the account roster. So, since then, we've created the user let me go to the I am.

So basically, we need to allow this Bob user to assume the role of the account be. So for the role that we created in the production account, we have to allow Bob to assume that role. So, one very important part to remember So let me go to Bob, and within here, I'll select inline policy. I'll select the JSON document, and I already have a template for that. I'll copy this template, and I'll paint it over here. I'll be pasting it below the lecture so that you will be able to use it. Now, within this template, within the action, we must specify the ARN of the role that was created in the production account, and within the resource, we must specify the action by which the user is allowed to perform its duties and assume a role.

So if you will see this role, this has the ARN and this is the arm that we need to paste over that was crea. So I'll go ahead and click on review policy, and within here I'll name it "cross account hyphen productions" so that we can know that this policy allows assuming the role that belongs to the production e I'll name it "So now that we have a base set up, we need to test if everything is working perfectly. So in order to test, I'll open up one more browser, which is going to be an Opera, and from there we'll log in to the Bob account. So it seems that opera is not opening. So anyways, I'll open up our Internet Explorer. So I have various kinds of browsers installed so that we can have a backup as well as perform a practical task perfectly.

So, the first thing we need to do from Internet Explorer is log in with Bob's credentials to this identity account, because the user bob is created within this identity account. So first we have to log into this account with user Bob's credentials. So this is the console. I'll go ahead and put the username as Bob, and for the password, let me just close the prompt. I'll go to the security credentials, let me just reset the password, I'll auto-generate the password, and I'll not select this option, "Require password reset." So otherwise, when the user logs in, he'll have to reset the password. I just want to keep it simple. for the time being. I'll just copy the her wise, when the So now I'm logged in. So if you see this, this is Bob's identity account.

Now let me quickly show you this. So currently, Bob has logged into this identity account. Now from this identity account, Bob needs to log into the production account. Now, since we have already created a cross-account role in a production account, all that we need is to give Bob the link to this specific role that we have created. Now this link can be accessed from the CA production role. So if you see it has given us the link, I'll take the link and, within the new tab, I'll paste the link. Now that we've arrived at the switch role screen, I'll go ahead and click on switch roll. Perfect. So now, if you'll see over here, I am logged in to the production account. And, since we've given S3 complete access, let's quickly check to see if anything else is opening. So here it is saying "unauthorized." And if I go ahead and click on S3, the S3 seems to be working perfectly.

So this is a great thing because, as you can see, since we have two accounts, the user only has to remember the username and password associated with this identity account. And there can be any number of accounts like production, depth, and stage, and all that Bob has to remember is the credentials of the identity account, and from this identity account he can switch to various other AWS accounts. So this is about delegation. If you want, you can even click back to Bob, and you will be again redirected to the identity account. So next time you want to switch to the production account, you can click over here and select CA production.

And now you're in the production account. So this is how easy it is for the cross-account role to be created. And if you have multiple accounts, I've seen organizations with more than 50 AWS accounts, and having a cross-account role was highly requested during that time to ensure full control and a good user experience. So this is it for today's video. I hope this has been informative for you, and I look forward to seeing the next video. Bye.

4. AWS Organizations

Hey everyone and welcome back. In today's video we will be discussing AWS organizations. Now, AWS organization is one of the services that I would strongly advise you to use, especially if you have multiple AWS accounts. So let's go ahead and understand more about organizations. So the AWS organization basically offers policy-based management as well as the feature of consolidated billing. So there are two primary features of an AWS organization. One is the consolidated billing, and the second is generally called all features, where you can even control the access-related permissions for the child account through a central AWS organization account.

So we'll discuss about each one of them. So let's first discuss these policy-based controls, or the policy-based management of organizations. So within your you have an AWS organization. So this is basically an AWS account that the organization is running. You are now establishing a policy from this central AWS account to the AWS account one, essentially denying the disablement of cloud trails. So no one from the AWS account will be able to disable the cloud trail log, not even the root account. Now, in the second AWS account, you have another policy called deny all but S3. So any user on this account, AWS account two, will not be able to see any feature of SRE that would include the root account. So this is what the policy-based restriction is all about.

So let's look into the practical aspect, and I'll give you an overview demo on what exactly it would look like. Before we start with the practice, I just like to make sure that this central account is also referred to as the master account. And these accounts, where the policies have been applied, are also referred to as "the child account." So, in the event that I mention a master and child account, just I hope you understand what a Master Account is and what a Child Account is. Now I'm in my AWS organization's console. So this is the console of the master account. Now there are two accounts, which are linked over here. Within the second account, if you'll notice, this is the account ID. Now, within the policies section, if I just expand it, there are two policies attached: one is full AWS access, and the other is deny. So deny; this deny policy basically denies all the S-three operations.

So basically what we have done is, if we look into the PPT, let's assume that this is the account where we have added a deny all but S3 policy. So let me log in to that account. So this is the chat account, and if you'll see over here, it is showing the master account email address, and basically it is also showing the organisation ID. So basically, I am part of this master account organization. So if I go back to the AWS console, basically, I am logged in as root. So if I quickly show you If I quickly go to my security credentials, you will see that I am actually logged in as a root user. So this is the root user with which I am logged in. Now, because we had added an explicit S-3 deny policy through the organization, let me open up S-3, and as you can see, it is showing you access denied.

So even with the root user, you will not be able to bypass the control policies that have been set by the AWS organization. So apart from S-3, I should be able to see all the things, but since the S-3 policy was added, I'll not be able to do that. Even the root or even the administrator user will not be able to bypass the policies that have been set by the master AWS Organization account for the various child accounts. Now, for the second feature, we were already discussing this. So if I quickly go here, the next feature is the consolidated billing. So, again, consolidated billing can be set for the AWS organization. Now, I have already enabled consolidated billing, so if I quickly show you that part as well, So this is my billing dashboard. If I'll go to the consolidated billing, it says that your account is now a member of an organization.

So basically, I already have consolidated billing enabled. So if you want to quickly see my master account, this is my master AWS Organizations account. I'll go to the bills if I go to my billing dashboard. And let me just select the last month, which was May, and within bills by account, you would actually see that there are two bills for two accounts. Now, I already have a similar name in both accounts since both belong to me. However, within Bill by Account, you would actually see that there are two accounts that have been reflected. In addition, if I quickly go to June, and Bill, by the account, you will see that one account has $0.0 and the second account has $0.1. So this $0.1 belongs to my current account, which is my master account. so you see 0.1. However, that $0.0 actually belongs to the child account. So since both of these are part of the consolidated billing family, you will actually see both of these accounts within billing.

Hide