When I worked in a data center environment in a previous role, our team knew that, at certain times of the year, external auditors would be coming on site to analyze our environment. This could have been for a number of different compliance controls, such as for PCI DSS (Payment Card Industry Data Security Standard) for example. In addition, some compliance controls were not always external, and we had stringent internal requirements that stipulated specific do’s and don’ts when it came to the configuration of hardware resources.
These internal and external compliance requirements meant that there was a huge emphasis on ensuring that all controls were being met and proving that they had been met. This often meant that vast amounts of spreadsheets and other change management systems had to be manually kept up to date for all changes within the data center. This might include installing additional RAM into a server or decommissioning entire storage area networks (SANs).
If these records were incorrect, we would risk the chance of failing the audit. As a result, a lot of man hours had to be invested in resource management on a weekly basis to ensure that the team was compliant across a range of controls.
Compliance in the cloud
Compliance in a cloud environment is different. One of the fundamental elements of cloud computing is that resources can rapidly change, which is very different from a data center environment. A typical cloud environment will scale up and down and in and out depending on demand and other thresholds, which allows it to elastically evolve. Trying to maintain compliance on resources in an environment that is forever changing can be a huge headache.
For the purposes of an audit and other compliance requirements for your resources, at any given time, you will need to know certain information:
- Exactly what resources you have and the functions that they are performing
- Their current status and configuration
- If your resources have any dependencies against one another and their relationships
- A complete history of all changes that have occurred on a resource and when
- Whether the resource is meeting both internal and external compliance requirements
Introducing AWS Config
Trying to maintain a record of this information within your AWS environment can be achieved but at a big cost of effort. You could perform a ‘describe’ or ‘list’ using the AWS CLI against your resources to find some of this information, but developing a system to output those results into a readable and easy to manage format is another matter altogether.
AWS soon realized this, and to help rectify the problem that many customers were experiencing, AWS introduced a service called AWS Config. AWS Config is a managed service that can do all of this for you, and more, by performing the following tasks on your behalf:
- Capture resource changes
- Act as a resource inventory
- Store configuration history for individual resources
- Provide a snapshot in time of current resource configurations
- Enable notifications of when a change has occurred on a resource
- Provide information on who made the change and when, through AWS CloudTrail integration
- Perform security analysis within your AWS environment
- Provide relationship connectivity information between resources
- Enforce Config rules that check the compliance of your resource against specific controls
When it comes to resource management, AWS can be a great help. However, in this post, I’d like to focus on the last bullet in the list above: Config Rules.
AWS Config Rules
Config Rules allow you to manage resource compliance by acting as an automatic resource compliance checker. When a change is made to a resource, AWS Config will check to see if the resource matches a rule (with the help of a Lambda function). If it does, AWS Config will check the compliance of that resource against the rule once the changes have been made.
There are two types of Config Rules within AWS Config:
- AWS Managed Config Rules
- Custom Config Rules
AWS Managed Rules are predefined and cover best practices and common compliance checks. These rules currently operate over the following topic areas:
- Management Tools
- Security, Identity, & Compliance
For many of these Managed Rules, you can alter specific parameters to fit your requirements as we will see coming up.
Custom Rules allow you to set your own compliance checks with your own Lambda functions, which is where the logic of the rule itself is evaluated. If you can write your own Lambda functions, then you can truly take advantage of these Config Rules. This will allow you to optimize your environment by ensuring that all compliance requirements have been fulfilled, which may not be possible within the limited AWS Managed Rules.
How AWS Config Rules work
Let’s look at a sample scenario to see how Config Rules can help you meet compliance requirements:
Scenario: You have a number of fleets of EC2 instances with EBS volumes running a number of different applications within auto scaling groups. Internal standards and compliance requires that the EC2 instances MUST be either c3.4xlarge or m1.xlarge instance types. In addition, the EBS volumes MUST be EBS optimized for efficient I/O throughput and ALL EC2 and EBS resources MUST be tagged with an ‘ApplicationName’ and ‘ProjectName’. External compliance controls also dictate that data MUST be encrypted at all times.
This can easily be achieved during the initial deployment as you can ensure that the correct configuration and settings are deployed. However…
Once the initial deployment was carried out, you then handed the environment over to Support & Operations to maintain and look after it. Over time, the environment would be subject to general maintenance, the removal and adding of resources, and other incidents.
While they would have been aware of the compliance requirements, the Support & Operations team may not have maintained it at all times. This could have been due to human error or lack of knowledge. These things happen.
For example, they may have updated the launch configuration of an auto scaling group and selected the incorrect instance type, or they may have forgotten to enable encryption on the EBS volumes or failed to select an optimized volume. As applications were rolled out, they also may have forgotten to tag those instances.
As a result, your environment is now in a state of non-compliance, failing both internal and external requirements and controls.
This situation can easily be avoided with the use of AWS Config Rules. In this example, we could have used a number of AWS Managed Rules to notify us that non-compliant resources were in operation, allowing us to take the necessary action. It’s important to note that non-compliant resources still function as normal; AWS Config simply flags them as non-compliant. These are some of the rules that could have been used:
- Desired-instance-type: Checks whether your EC2 instances are c3.4xlarge or m1.xlarge
- Ebs-optimized-instance: Checks whether EBS optimization is enabled for your EC2 instances
- Encrypted-volumes: Checks whether EBS volumes that are in an attached state are encrypted
- Required-tags: Checks whether your resources have the tag ‘ApplicationName’ and ‘ProjectName’
Let’s look at how just a couple of these rules would have been configured, starting with desired-instance types:
Select the rule from the list of AWS Managed Rules within AWS Config:
This will allow you to edit specific parameters of that rule. In the screenshot below, you will see the ‘Managed rule name.’ This is the name of the AWS Lambda Function that is used to evaluate the compliance of the resource against the rule.
The ‘Resources’ listed shows which resource type I want the rule to be applied against. In this case, it is all EC2: instances.
Finally, the Key Value pair allows me to indicate which instance type(s) the resource must adhere to, and in our scenario, I have set this to c3.4xlarge and m1.xlarge.
Now, let’s take a look at the Rule used for checking the tagging compliance.
Again, the rule is selected from the list of AWS Managed Rules within AWS Config:
In the screenshot below, we have the AWS Lambda function listed, along with the resource types that the rule should be applied to. I have included EC2: Instances and EC2: Volumes as our requirements indicated that both of these resource types required tagging.
The parameters at the bottom allow me to add both tags required: ‘ApplicationName’ and ‘ProjectName.’ In addition, I can add the values that are available for each of the tags.
Once the rules have been configured and are up and running, AWS Config will identify if there are any non-compliant resources against your rules.
The example below shows two instances that are non-compliant with the desired-instance-type rule.
From this simple scenario, you can understand the value of AWS Config for providing a continuous monitoring solution for compliance, as well as a wide range of uses.
Maintaining compliance does not have to be a huge manual and resource intensive operation. AWS Config monitors your resources and performs a lot of these evaluations for you. This not only saves you time and money, but it also reduces your risk of non-compliance.
New Cloud Academy course: Introduction to AWS Config
If you would like to learn more, check out our new course on AWS Config. We will cover how AWS Config works, how to configure it, how to put it to use in your environment, and we’ll talk about the other functions it provides from a resource management perspective. In AWS Config: An Introduction we will cover.
- What is AWS Config? You will learn about the service and the functions that it provides
- Key Components: We will break it down to take a closer look at all of the components and their relationships to each other and the role they play as a part of the AWS Config service
- Service Integration: We will look at how the AWS Config service integrates with other AWS Services
- Managing compliance with AWS Config: Here, we will focus more on how to maintain compliance using AWS Config for both internal or external requirements or standards
- Use cases and best practices: We will focus on some of the use cases for AWS Config so that you will understand the scenarios for using AWS Config to help you maintain, support, and operate your AWS environment
Get started with AWS Config: An Introduction today.
AWS Security: Bastion Host, NAT instances and VPC Peering
Effective security requires close control over your data and resources. Bastion hosts, NAT instances, and VPC peering can help you secure your AWS infrastructure. Welcome to part four of my AWS Security overview. In part three, we looked at network security at the subnet level. This ti...
Top 13 Amazon Virtual Private Cloud (VPC) Best Practices
Amazon Virtual Private Cloud (VPC) brings a host of advantages to the table, including static private IP addresses, Elastic Network Interfaces, secure bastion host setup, DHCP options, Advanced Network Access Control, predictable internal IP ranges, VPN connectivity, movement of interna...
Big Changes to the AWS Certification Exams
With AWS re:Invent 2019 just around the corner, we can expect some early announcements to trickle through with upcoming features and services. However, AWS has just announced some big changes to their certification exams. So what’s changing and what’s new? There is a brand NEW ...
New on Cloud Academy: ITIL® 4, Microsoft 365 Tenant, Jenkins, TOGAF® 9.1, and more
At Cloud Academy, we're always striving to make improvements to our training platform. Based on your feedback, we released some new features to help make it easier for you to continue studying. These new features allow you to: Remove content from “Continue Studying” section Disc...
AWS Security Groups: Instance Level Security
Instance security requires that you fully understand AWS security groups, along with patching responsibility, key pairs, and various tenancy options. As a precursor to this post, you should have a thorough understanding of the AWS Shared Responsibility Model before moving onto discussi...
Cloud Migration Risks & Benefits
If you’re like most businesses, you already have at least one workload running in the cloud. However, that doesn’t mean that cloud migration is right for everyone. While cloud environments are generally scalable, reliable, and highly available, those won’t be the only considerations dri...
Real-Time Application Monitoring with Amazon Kinesis
Amazon Kinesis is a real-time data streaming service that makes it easy to collect, process, and analyze data so you can get quick insights and react as fast as possible to new information. With Amazon Kinesis you can ingest real-time data such as application logs, website clickstre...
Google Cloud Functions vs. AWS Lambda: The Fight for Serverless Cloud Domination
Serverless computing: What is it and why is it important? A quick background The general concept of serverless computing was introduced to the market by Amazon Web Services (AWS) around 2014 with the release of AWS Lambda. As we know, cloud computing has made it possible for users to ...
Google Vision vs. Amazon Rekognition: A Vendor-Neutral Comparison
Google Cloud Vision and Amazon Rekognition offer a broad spectrum of solutions, some of which are comparable in terms of functional details, quality, performance, and costs. This post is a fact-based comparative analysis on Google Vision vs. Amazon Rekognition and will focus on the tech...
New on Cloud Academy: CISSP, AWS, Azure, & DevOps Labs, Python for Beginners, and more…
As Hurricane Dorian intensifies, it looks like Floridians across the entire state might have to hunker down for another big one. If you've gone through a hurricane, you know that preparing for one is no joke. You'll need a survival kit with plenty of water, flashlights, batteries, and n...
Amazon Route 53: Why You Should Consider DNS Migration
What Amazon Route 53 brings to the DNS table Amazon Route 53 is a highly available and scalable Domain Name System (DNS) service offered by AWS. It is named by the TCP or UDP port 53, which is where DNS server requests are addressed. Like any DNS service, Route 53 handles domain regist...
How to Unlock Complimentary Access to Cloud Academy
Are you looking to get trained or certified on AWS, Azure, Google Cloud Platform, DevOps, Cloud Security, Python, Java, or another technical skill? Then you'll want to mark your calendars for August 23, 2019. Starting Friday at 12:00 a.m. PDT (3:00 a.m. EDT), Cloud Academy is offering c...