The course is part of this learning path
As companies move more and more mission-critical information and workloads onto the AWS cloud, DevOps Engineers need to implement more sophisticated and secure methods of managing data and processes. This course on Governance on AWS teaches skills to manage complexity and direction on increasingly large AWS cloud accounts and installations.
Learn how to:
- Model the resource governance and compliance life cycles
- Inventory the actors, actresses and action triples in governance
- Use AWS CloudTrail for help with AWS API call audits
- Use CloudWatch Alarms and Metrics for Billing
- Use AWS Config Rules and Timelines
- Practice good management of IAM credentials and policy structures
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
- Welcome back to the Cloud Academy Course on Governance on Amazon Web Services. In this lecture, we'll be going over resource states and the different resources that those can entail. So, for resource states, we have a number of tools available to us that we'll be looking at a console actually after we get past this slide. We'll be looking at AWS Config, resource tagging, CloudWatch Metrics, CloudWatch Alarms, AWS Trusted Advisor, and the billing console. So as we talked about in the title slide there where we went through our inventory, we're going to be talking about the resource management aspect of our governance plan. So, we can imagine that the tools that we might be looking for for something like governance where we're managing resource states would be underneath the management tools header. So, if I tab over to the management tools header in the services dropdown, I should find the AWS Config service. So if we read the description there, AWS Config gives you inventory of your AWS resources lets you audit resource configuration, history, and notifies you when resource configurations change. So, clicking into the service, we can see that we get a white screen as Amazon takes a while to load. But we get the landing page when I have config configured. There was just a start button if you've never configured it before, it will ask you to add these rules. Once we begin setting up AWS Config, we can see that we have these rules. So an AWS Config rule is a way for your system to in an ongoing manner check the status of different resources and make sure that you're compliant with different policies. So AWS Config doesn't support all resources in the entire AWS cloud yet but it does support a number of useful ones. So, CloudTrail is a resource type that we're going to get into a little bit later here when we talk about transition states. But one of our compliance rules here is that if I have a regional installation, I need to have CloudTrail enabled. So because CloudTrail is another governance tool in a different section but we can see that in the AWS Config console, we're getting this nice ability to see if we've actually complied with important policies that I might have. So, the last successful invocation of this check was a while ago. But what this tells me is that the last time I made a change to the CloudTrail resource was on January 9th and that I was compliant at that time that I made that change. So, the periodic polling here means that the CloudTrail enabled check is actually run in a cron schedule effectively with this certain frequency. It's not turned off but what we see when we go to these rules here is that I am able to add other rules. So right now, this account in this region actually doesn't have any volumes or elastic IP addresses so it's neither incompliant or not compliant because there's nothing to operate over. But I can add these custom rules where I can pick from a number of different resources that I might want to...a number of different things that I might want to check. So I already picked CloudTrail, enable the IP attached and encrypt in volumes. You might also want to check encrypt restricted SSH or EC2 instances in VPC if you have an older Amazon account that also supports non-VPC EC2 instances. For instance, required tags you might want to also select. So, if I select a rule, it gives me that automatic name associated with the existing name, required tags as a managed rule. So this is a fixed field here. I give it a description of any kind I want when I'm sitting up my compliance. I select a trigger type where if there are configuration changes that are noticed by the system, only check then, else always check. So, what we need to realize here is that this will rerun every time that a resource within scope in this setting here whenever one of these guys changes, we'll get a configuration change. I'm actually just going to run a periodic check. I wish I could, but the system is going to force me to do configuration changes only because it's a required tags. It's a system resource. I can select whether I want the scope of the changes to be associated by resources tags or all changes. So, if we see that little tool tip there, then we can understand the different options that we get. And we can configure these different rule parameters. Right. So we can set the different tags that we want to check. Right. So if I just hit save then tada, we have a new AWS Config rule and we can see that this thing is evaluating and we will eventually get either a green, red, or a yellow message where we're either compliant, not compliant, or no resources in scope. But this is our tool, our main vehicle by which we can do ongoing custom checks of the different compliance rules that we have set forth or policies. So this is the AWS Config enables the policy in compliance portions of our three-step model where we set a policy. We run a system where we can actually do these evaluations and make sure that we're compliant, compliance right there. And then number three, we do remediation. So, there is no...from the console, there's no direct way to make AWS Config automatically enact your compliance, third step where you have to do the enforcement. But we at least get scalable, extensible validation that we are complying with our existing policies. So, resource tagging is actually the next thing that we're going to talk about. So let's first look at resources in general inside of AWS Config. We can select from a blanket group of EC2 or IAM at this time or CloudTrail. So these are the only supported resources at this time. I can select a CloudTrail here and hit lookup. It'll find all of my resources that are that type and we can click on this little icon here for the config timeline to see all of the times that I did alterations to this resource. So, this is pretty neat. If we look at our compliance roadmap here or governance roadmap, this is a huge win for me, resource management part of our Fig. 3 right. So we manage or resources or transition states in our actors. We have a pretty convincing way to manage the states of our different resources with the AWS Config because it allowed me to do a listing inventory. And then once I actually got the individual line items, I was further able to go open the thing up and see a timeline of the entire system. So, AWS Config is great. We also can go back to the top level here and we can actually change different settings of this AWS Config. And if we want to do automated enforcement, where I'm able to actually close the loop and not only declare a policy in config, automatically check for it but I can also extend it to make me automatically fix things. If I create logic that will automatically fix things, I can use SNS as the messaging system whereby I can notify some fixing system that will do my enforcement. So I could simply configure an Amazon Lambda to subscribe to this SNS topic and have that Lambda already contain logic to repair any problems or a subset of the problems that config might complain about once it gets broadcasted. So this is pretty fancy. We can actually use AWS Config to completely close that loop in conjunction with Lambda. So next, we're going to talk about resource tagging. The primary place that people are used to thinking about resource tagging is inside EC2 and EBS where we can tag individual resources with different values. So if I go and I create a new volume, if I want to, say, create a new instance for my project, my Andrew School Stuff project, then I can just walk through default settings and I can say... So, what I get with resource tagging is when I set this up and hit go on my instance, once I've launched my instance, I will get the ability to organize by billing. So, if I open this up, and I look at my instance, these tags that I've set up for name and such will persist and there are things that I can use when I'm doing my billing subdivisions. So this is a primarily a billing reduction or billing management technique. So, whenever I have these key value pairs, I can simply go into the Billing Management Console and check what my spending is according to those tags. So, I'm not actually sure if they'll show up since I just did this about two seconds ago, but inside of this Cost Explorer, we can do sorting by tags. Yeah, so my tags haven't shown up yet because we haven't waited for enough time. But the idea here is that what you can do is you can go to this Billing Management Console, go to the Cost Explorer and since we were supposed to talk about the Billing Console in this lecture anyway, the tags are very closely connected here. My EC2 monthly cost and usage for this account since I don't use it very much are very low, I am able to actually organize by tag and do different filtration and such after I actually get a billing line item for a tag. So if I came back and looked at this tomorrow in this account, then I would start seeing tags up here. I can also group by different values and such. So, this is one way that I could do my governance is I just set tags to everything and then go back and review to see if I've actually hit my numbers that I'm expecting. So I can filter my tags for resource types that are supporting these tags. The most common of which people will be thinking about are EC2. So, that's the best practice for billing and cost management as is, of course, visiting the billing and cost management page and going to the Cost Explorer Console. So, you can also, imagine that this overview month to date spending, that cost explorer that we went to just a second ago is underneath. Here is the third bullet as of the time of this recording. But we can also navigate to cost allocation tags. So, we can, when we're getting reports from our billing reports, I can also further select different tags that we're talking about. So, if I want to save my cost allocation tags, go back to Cost Explorer and still nothing appearing. But when we get our billing reports at the end of the month, those cost allocation tags will show up as a grouping that we can actually utilize. So, this is how we would do our billing and management there. There's another way that we can do billing management that segues nicely into the other portions that we're going to talk about on this lecture here. If we go into CloudWatch, we can actually set up CloudWatch Alarms to configure on billing. So, I actually don't have any configured right now but we can do that by going over to follow these instructions, right. So if you click on the preferences page in the left navigation from the billing console, we can do receive billing alerts. So these would be our CloudWatch Alarms, and let's go back to CloudWatch. Now I can create an alarm to tell me when my system exceeds $1,000 in a month. So, it'll take some time for this to move away from insufficient data, but you just watched me create a pretty sophisticated piece of governance where I'm actually going to get notified. Mine is configured so it will text me and send it into my chat system. Oop, it just notified me that I had a subscription there. This will actually notify me based on how much I'm spending. So, my new billing system I have AWS Config. I have all these nice billing systems that I can use alerts for. Everything will tell me when something goes wrong, right. Whenever I have any kind of resource changes that go wrong.
About the Author
Nothing gets me more excited than the AWS Cloud platform! Teaching cloud skills has become a passion of mine. I have been a software and AWS cloud consultant for several years. I hold all 5 possible AWS Certifications: Developer Associate, SysOps Administrator Associate, Solutions Architect Associate, Solutions Architect Professional, and DevOps Engineer Professional. I live in Austin, Texas, USA, and work as development lead at my consulting firm, Tuple Labs.