Amazon AWS SysOps – AWS Account Management part 1

1. Section Intro

Now we are getting into the AWS account management section and in this section we’ll see all there is to know about health dashboards, AWS organizations and the billing console. There’s no fancy diagram for these services, but they are asked at the exam for the sysups perspective and also whether sys ups in the real life. You will need to know in and out these skills to be able to be a great sysups. I’m really excited. This will be a short section, but I’m sure it will be full of learning. Let’s get started.

2. AWS Health Dashboards

Okay, let’s start by something easy, but that you absolutely need to know as a sys hubs. The first is around the service health dashboard, so it will show all the region and all the service health. That means that every day you know if a service is working, could be is there an S three failure, is RDS working correctly, is EC Two working correctly? And you also get historical information for each day so you can go back in time and see if a service has been reliable or not. The idea is that you know whether or not our service is working and you can pick a region where you think there is less failures. Overall there’s no failures, but that’s how AWS communicates. If there is any service that experiences any type of downtime or impairment to how it works, you can also have an RSS feed that you can subscribe to and you can access the status dashboard through this URL.

So let’s go on it right now. So if on Google you tap AWS status dashboard, you will find a link called Alice Service Health Dashboard. And this basically will show you a whole lot of information around how each service is doing. So the idea is that on this dashboard we get for every region. So North America, South America, Europe and Asia Pacific. The information around how the service is functioning. So for example, if we look at North America and we want to know how EC Two is going, we scroll down all the way to when we find EC Two, which I can’t find because there are so many services. Here it is. Amazon Elastic Compute cloud. And so for example, in North Virginia, while the service is operating normally, so it’s actually very rare to see anything that’s not going to be a green tick.

As you can see right now, everything is green in all the regions. So that means that AWS is working just fine. But if there’s any outage happening, then you will find it here. You can also ask for the status history, so you can basically look over time how the service was doing. So for example, if you go to Europe and we want to know how API gateway in Ireland was doing, well, we can go back over time and keep on clicking on the arrow here just to see every week if the service had any downtime. As you can see right now, we don’t get any downtime, and here we don’t get any information for Stockholm because the API gateway in Stockholm get put into effect on this date of December 11, as we can see. But so here you get some information around the status history and the service.

So you can see service can be operating normally where you can get just an informational message, or a service degradation, or a service disruption.So this is obviously the worst one, but service degradation is good to know as well, and normally is going on as well. So this is how you would design your Amazon, but the question that comes up is, okay, look at all these services, look at all these regions. I don’t really need all these for me, maybe I’m just using five services in one region in Amazon. So how do I know how this applies to me? And the answer is the personalized view. Personal Health Dashboard is a global service and it will show how AWS outages will directly impact you. So instead of getting a global view with all the services and seeing over time how they are, you get a Personal Health Dashboard.

And in case of anything happening on AWS, on your resources, then you know about it. And so the cool thing is that because you know how it’s your resources, you can list your issues and you can see actions you can do to remediate these issues. And so that’s how it really matters. And so in the exam, they will ask you which dashboard is right for you. So if you’re looking for entire information around all the services, all the regions, the status dashboard is fine. But if you’re looking just impact to you, for example, there is an outage in S three and you want to know how many resources are impacted, then the Personal Health Dashboard will be the one. So to access it, we can just use this link, and the link can also be used using this orange button.

So it’s phg AWS Amazon. com. And so as you can see right now, there’s no issues in the past seven days. So you can set a specific start time if you wanted to. So you can set start time was seven days ago or whatever, and you can see all the issues overall. So you can see that over time how many issues were open and closed. For example, there was a Kms operational issue in SA East One starting on December 12. And so you can see when it was resolved and over time how it impacted. But if you wanted to see just how some changes impact you, then you would look at this dashboard and you see that right now there’s zero open issues, zero schedule change, and zero notifications.

Because I don’t have much in my AWS account, maybe you get more if you have a big AWS account. You can also access these issues directly using the little bell on the top line, so you get alerts. And so when the bell is orange, that’s open issues. So that’s things you should look at definitely. And if it’s blue, you get information around the schedule changes and the other notifications overall, any kind of notification you should look at just to make sure it doesn’t impact you too severely. But overall, if you wanted to design an application on AWS, if you make it multiaz, usually you’re going to be fine, but still this is very helpful to know how you can see all the open issues in AWS and how they impact you using the personal health dashboard. So hope you liked it, and I will see you in the next lecture.

3. AWS Organizations Overview

So let’s get into the multi account realm with AWS Organizations. So, AWS Organizations is a global service and it is allowing you to manage multiple AWS accounts in your organization. The main account is going to be called the Master account and you cannot change it. And the other accounts within your organizations are member accounts. The member accounts can only be part of one organization, although they can be moved from one organization to another. It’s called a migration and we’ll see how to do this in this theory lecture as well. So, the benefits of organizations is that you get consolidated billing across all the accounts and with a single payment method.

So you can have as many accounts as you want and they will all be billing under the master accounts and the pricing benefits you get from aggregated usage. For example, if you have a volume discount for EC two or Amazon is three, you get it at the organization level. So it’s really great to federate all these accounts into one organization to pay less and simplify your billing methods. And there’s a really cool API that allows you to automate the AWS account creation. So you can create a list account on demand using an API through Organization and make sure that the billing of that account will be rolled back into the bigger accounts. So what would we have multiple accounts in AWS? We have multiple strategies for it.

For example, you may want to create one account per department or percuss center or per environment, for example, for dev, test and prod, or based on regulatory restrictions, for example, or for better resource isolation. So you want to make sure that you don’t have resources that can talk to each other within the same Vpc. So you create two accounts and you don’t pair them together and so the resources are virtually isolated. There’s also good, you have per account services limits and also isolated account for lugging. So there’s multiple strategies for multiple accounts and it depends really on the wish of the main architects in your organization. Now, there is a difference between having multiple accounts or one account with multiple Vpc in it.

Okay? The thing is, if you have multiple accounts, you know they’re really well separated and you have different user accounts and so on. Whereas if you have one giant account with multiple Vpc, there is a chance that your resources may talk to one another, there’s a chance that the users also get access to multiple VPCs and so on. So it’s really up to you to choose what you want to have and how you want to run your organization. You can have also tagging standards for billing purposes and you can enable cloud trail on all accounts to send the logs to a central, for example, Amazon’s free account and also have cloud watch logs sent to a central logging account. So many, many different strategies for your cross accounts.

And if you wanted to administer all the accounts, then you can establish cross account roles for admin purposes, where the master accounts can assume an admin role into any of the children accounts. Okay, so how do we organize all these accounts? We organize them using organizational units or Ou. So you can organize them by business units. For example, in this example we have the master account, and then we have the sales ou, the retail ou, and the finance ou, and under each Ou we have different accounts. So the sales account one two, retail account one two, and so on. Or you can have it by environment. For example, you have the master account, and then you’re going to have production, development Ou and test Ou.

And within each ou, again multiple accounts. Or you can be project based, project one, project two, project three, and multiple accounts. Again, this could be completely different. You can mix and match. It’s really up to you to design the type of Ou you want, but it gives you some ideas around how Ous are being used. So for your organization, let’s have a look at all the possibilities. You have the roots Ou, we have the root accounts, that’s the master account, and then you can have Ous within it. For example, a development Ou with two accounts in it, a prod Ou with two accounts in it, and another ou deep within the prod, which is the finance ou with another two account in it, and another Ou within prod, again, which is the Hrou with two accounts in it. So we see the kind of structure we can create with organizations, and you can go really crazy.

You can assign accounts to whatever ou you want, and they will inherit some rules and some scp. I will see in the next lecture, in the next slide of security. So hopefully you can visualize now what an Ou is, because we’re getting into the security of these Ou. There is something called a service Control policy or Scp. It allows you to whitelist or blacklist im actions applied at the Ou or account level, but it doesn’t apply to the master account. The SCPs have no effects on the master account. So the Scp will see an example very shortly. They can be applied to only the users and the roles of the account, including a route. So if you apply an Scp onto your account within an Ou, and you say you cannot use EC Two, even an admin within that account cannot use EC Two.

But the Scp does not apply to service linked roles. So this is the service roles that other services use to integrate with organizations. Okay? Scp must have an explicit allow to allow things, so by default it does not allow anything. And so use cases for Scp, and this is what the exam will test you on, would be to restrict access to certain services. For example, you’re saying, okay, in my production accounts, you cannot use EMR or to enforce PCI compliance by explicitly disabling services that are not compliant with PCI yet in AWS. So I’ll try to make this a little bit clearer. Let’s have a look at our ou. So we have the root Ou with a root account A, production ou with an account A in it, and with an Hrou with account B and a finance ou with account C.

So let’s assume that you usually do this on the root ou. You add an scp called full AWS Access, which tells that every services in every action can be done, basically allowing you to use your account. But let’s apply a deny access Athena SAP onto the master account. Now, what can the master account do or cannot do? Well, the master account can do anything because it inherited the full Aos access scp from the root Ou. And even though we have attached a deny access Athena scp to the master account because it is the master account of your root ou, no scp apply. And therefore this scp will apply to the master account is completely not taken into account. So, to summarize, we’ve inherited stuff from the root Ou, and the scp applied to the master account.

To deny anything does not apply. Now let’s go on. We have a deny redshift SAP that is applied to the prod Ou, and an authorized redshift scp applied to the account A. So now about account A, it can do anything because you have full access SAP, but it cannot access redshift because there is a deny redshift SAP applied to the prod Ou. And even though I have attached an authorized redshift SAP to my account A, because we have an explicit deny on redshift at the Ou level, the deny is going to take precedence over the authorized. So even though I have this authorized redshift scp on account A, actually that authorize is useless because we already have a deny at the Ou level.

So it’s interesting for you to know that this is a full tree. And so account A is going to inherit the scp at its level, at the Ou level, and even the roots of the Ou. So it goes like a tree. And so if one of these says deny, then it’s going to be a deny. Now let’s look at Hrou. It has a deny A list lambda scp. And so what about account B? Well, it can do anything because of the full access, but it cannot access redshift because it’s within the prod Ou, it’s the bigger Ou, and also it cannot access AWS lambda because it’s within the Hrou. So account C, though in finance ou, is not affected by this deny AWS lambda scp because it’s only applied to the Hru but not the finance ou.

And therefore account C has the exact same permission as account A, which is to do anything but access redshift. Hopefully that makes sense. If you understand this, you basically understood scp and their power. So let’s take an example of what it looks like. An scp looks just like aim policy. So this is allow all actions. So we allow star on star. So do you say you can do anything but deny dynamodb? And we’re saying the effect is deny on dynamodb star for any resource. Another strategy would be to whitelist only a certain type of services. So we’re saying allow EC two star and cloud watch star on resource star, but any other services but EC two and cloud watch cannot be usable if you don’t know exactly what this means.

If you want more examples, there’s a link right here that takes you to the documentation and shows you different ous SCPs you can have. Okay, finally, before we get into the hands on, how about moving accounts? So say we have orga and b, and we want to move an account from orga a to b. To migrate accounts, you need to know the process. The first thing is to remove the member accounts from the old organization. Then you send an invite to the new organization to include that account. And then you accept the invite for the new organization so that the member accounts can join it. So you can see in migrate diagram hup. That’s how the account went in. So it left the first one, and then it got an invite from the second one, and it was migrated.

And if you want to migrate the master account, so you want to migrate the roots account of your organization, then you need to migrate every single account within it. And then when you’re done, you delete the organization and you migrate the account that is standalone back into orgB. So that makes sense. It’s just step that looked natural, but it’s once you set it, you know it’s possible. And you will be able to answer an exam question based on this. All right, so that’s it. We’ll try to make we’ll try to make a tourist organization much clearer in the next lecture for the hands on, but you get a good overview of what it is. I hope you like this lecture, and I will see you in the next lecture.