Now, the CloudFormation Stack operation has completed, and we should expect to be able to see the rule within our AWS config dashboard. So, we navigate right back onto our AWS config rules. We're going to refresh the page. And now we get to see a rule ec2-volume-inuse-check; it has detected one non-compliant. Also, eip-attached has detected also one non-compliant. And of course, in this particular case, the EC2SG has been set as compliant.

So, we have three out of four rules actually indicating whether compliance or non-compliance has actually been established. So, we see we have a volume that is loose. We have an Elastic IP address that is actually also loose. The security group is actually indicated as compliant. So, let's go and take a quick look at this particular security group. When we navigate to it, one of the items that we're going to see is how the security group, the inbound rules. Once we refresh it, you get to see how they have been altered in order to be able to comply with HTTP and HTTPS for both IPV 4 as IPV6.

So, our Lambda function, for the most part, actually was aggressive in terms of being able to introspect the security group and be able to change whatever existing rules were according to some permissions that were preprogrammed within the Lambda function. In this case, all of it HTTP, HTTPS with regards to both protocol IPV 4 and IPV6. So, that actually explain how come when we actually look at the rules, then we get to see that they are compliant.

Now, if we actually take care of examining the elastic IP attached, we see that there's a particular resource here that is non-compliant. We can actually manage remediation. And in managing remediation, then we can actually set to manual remediation and then select a systems manager automation document. We can actually put it on automatic remediation. And then, on automatic remediation, we're going to look for the document that is going to be releasing that particular elastic IP address.

The idea of rate limits actually applies when we have fleets of instances. The concurrent execution rate defines a particular number of instances that will be incurring in this remediation. That way, your entire fleet doesn't get taken down, and you can actually, incrementally or interleaving wise, be able to implement remediation. For the resource parameter, we are going to be using the allocation ID; and of course, for the automation role, we have created an automation role here within Identity and Access Management. We're going to get to see that role ARN in a second. And we get to see here the SSMAutomationRole4EC2, which gives us AmazonEC2FullAccess.

We copy here the ARN for that particular role and we configured the automation assumed role to be that. So, we have once again, automatic remediation, remediation action details, release the IP if it's not attached to anything. We ignored the rate limits for Resource ID, we have Allocationid and we have the SSMAutomationRoll4EC2. Then in due time, we will expect the rules to then become compliant or simply not report a detective compliance, as it is the case here. We manually deleted the volume not being in use, and we see that the elastic IP attach rule no longer has the non-compliant setting. So, only the custom Lambda functions, the security group repair, and of course, the Lambda function that we deployed for easy-to-desire instance type now have enough information to indicate compliance. So, this will be it. In terms of rule demonstration for Cloud Academy, this is Jorge Negrón. Thanks for watching.

Working with AWS Config Rules Part 2

About

Learning Objectives

Intended Audience

Prerequisites