When developing and deploying solutions for your organization, you will most likely be governed by a framework or set of principles or processes that must be followed. The principles will clearly define both what is not acceptable from a risk perspective and the security controls that must be put in place to prohibit the action. The process might describe the path you need to take through the organization to gain approval to make a change. 

An example here could be that users of an AWS account shouldn't be able to deploy resources into a Virtual Private Cloud (VPC) that has direct access from the internet. There are various components that would need to be put in place to make sure this couldn't happen, such as IAM policies, service control policies, network access control lists, and security groups. Such security controls could be spread across multiple locations and services to mitigate the risk of users creating public resources. Responsibility for maintaining these controls could be spread across different teams as well—as in having an identity team and a network team. This is stacking up to be a complex challenge, so how do we make sure the configuration of these distributed controls is adhered to?

This is where a combination of resource tagging, Lambda functions, and AWS Config can help. With Config, we can set up security rules and guard rails that we can then manage as code. We still need to configure the IAM policies as a first defense (for example, denying the AllocateAddress API action), but then we should create a custom rule in AWS Config to check whether we have any elastic IPs attached to an instance. If we find one attached, then we may want to first detach the address and notify the owner of the instance (which would hopefully be found in the tag). This is a real example of security defense in depth, where we trust that something won't happen but then verify and check it nonetheless.

AWS Config works by continuously recording changes in configurations against the resources that the service has discovered and added to the inventory. The service can then use this information to check against the various rules that have been enabled. Rules can be AWS-built or custom-made using a Lambda integration. A rule evaluates a configuration and determines the compliance state of a resource, which could be either:

• COMPLIANT: The resource meets the criteria set by the rule.
• NON_COMPLIANT: The resource doesn't comply with the rule.
• NOT_APPLICABLE: Can occur if the resource was deleted or removed from the rule's scope.
• INSUFFICIENT_DATA: If AWS Config has not received an evaluation for the resource or rule.

If a rule determines that a resource is out of compliance, then AWS Config can send notifications to a Simple Notification Service (SNS) topic. This is where you can integrate a remediation workflow in your chosen technology. A good idea would be to use Lambda for this. 

In creating rules that trigger automatic remediation activities, what we're actually doing is achieving continuous compliance with the governance requirements set by our organization. Moving into the next section, we will go through an example of how to implement this.