Skip to content
The wide availability of public cloud services like AWS has introduced numerous beneficial features for companies. Quick infrastructure deployment, scaling with just a few clicks, paying only for what you actually use, and offloading the responsibility of managing services to your cloud provider while focusing your efforts on your product are just a few of these. However, working with a public cloud service creates some of its own challenges, including the difficulty of auditing your resources, which is where AWS Config comes in.
Given the need for placing increased attention on security (which should always be a critical factor to consider) and compliance with required standards, it is important to understand AWS Config which can help you audit these aspects of your business. If you work with Amazon’s public cloud, it’s a service that is available to you and this post will look at what it is, what it does, and why you should use it in your Amazon cloud environment.
What Is AWS Config?
AWS Config is a service created specifically for assessing, monitoring, and auditing configuration changes within the AWS cloud by using various rules. It is a fully managed service, and it works by continuously recording resources configurations to a chosen S3 bucket and comparing them to the desired state. You can look at detailed configuration histories, review these configuration changes, and, most importantly, respond to anything that is not matching the predefined rules. Whatever your compliance standards or security requirements might be, AWS Config can be of great use to you.
AWS Config comes with a lot of built-in rules. They are easily searchable; all you have to do is pick a rule to be enforced, as shown in the screenshot below:
The evaluation of these rules can happen on a configuration change or be set up to run periodically at a scheduled time. Additionally, you can take a remediation action. This can be anything from sending a message to an SNS topic telling you that the change has taken place to something more active, like starting or even terminating a non-compliant instance.
AWS Config’s existing 100 or so built-in rules cover most common use cases and requirements. If these are not enough, or if you simply need more control over the remediation process, you can add custom rules as well. Custom rules rely upon AWS Lambda functions, but you need to create those Lambda functions yourself so that they can best suit your specific needs. After you have the desired S3 Lambda in place, you simply add a custom rule that will trigger it.
The use of AWS Config costs $0.003 per configuration recorded within your AWS account, with an additional $0.001 per each rule evaluation. On top of those costs, you need to pay for the S3 storage cost of the configuration files (they don’t consume much space, so that cost should be minimal) as well as SNS and Lambda costs if you use them for notifications or custom rules.
AWS Config Rules to Consider
There are a lot of pre-built rules waiting within AWS Config, some of which are crucial in most AWS environments. Here are some of the rules that you should consider enabling within AWS Config, whether you are just starting with the AWS cloud or are already utilizing it.
1. IAM Root Access Key Check
One of the very first things that you should do when creating a new AWS account is create an admin user that will be used to create everything else needed in that account. The root user itself should be locked and its password safely stored away. You should never have AWS access keys (for programmatic access) generated for the root user. Since that user has unlimited control over your account, losing that user can have serious consequences. This is why the “iam-root-access-key-check” rule is very important.
This rule is very simple; it checks whether or not access keys have been generated for the root user. If so, the rule will be non-compliant.
While this rule might seem obvious, it is commonly overlooked. Add this rule as soon as your AWS account is up and running.
2. Root Account MFA Enabled
This rule goes hand in hand with the previous one. It ensures that multi-factor authentication is enabled for your root user. Storing your root password safely is still recommended, but this additional step will add another layer of security when it comes to protecting your entire AWS environment from an intrusion.
3. Access Keys Rotated
Even with root user information safely stored away, you will still have various users with different levels of access, along with admins who probably have almost complete control over the AWS infrastructure and services.
To make sure that your resources are properly protected, best practices dictate the regular rotation of programmatic access keys. This rule will check to see whether or not the keys have been rotated within the number of days specified. The number of days you set here depends on the level of security you need to enforce.
4. S3 Bucket Public Write and Public Read Prohibited
One of the most common mistakes people make when working in the AWS Cloud is having their S3 buckets publicly accessible. Whether or not you have data that needs to be kept private and secure, making sure that your buckets are only accessible to those who need access to them is of utmost importance. After all, data is everything these days.
There are exceptions, of course. You might need to serve content that should be publicly available, or you might use your buckets so that others can upload the data to them. Either way, understand your use case, and make sure to run an environment that is as secure as possible.
5. EC2 Instance No Public IP
This is another rule that handles unwanted public access to your cloud resources. By misconfiguring a VPC (an AWS service that deploys and controls an entire network on top of which your AWS resources will run), you can easily have your instances running with a public IP address. Unless this is something you need to do as a business requirement, it is wise to make sure that your EC2 instances are running with only a private IP address attached. Instead of checking everything by hand or creating a custom solution to do this for you, this rule will have you covered.
6. Desired Instance Type
If your company wants to use a specific instance type, this rule will make sure that you don’t have EC2 instances running anything undesired. You can use this to ensure that more expensive instances aren’t running and adding unnecessary costs. This rule can also help you be certain that your AWS environment using only the most optimal instance type for your product.
7. CloudFormation Stack Drift Detection Check
Infrastructure as a code has received a great deal of attention lately, and most customers rely on AWS CloudFormation (though Terraform has been making an impact as well) to templatize and provision their whole infrastructure. However, larger companies and bigger projects can end up with a stack drift—a situation whereby your defined stack differs slightly from what is actually running in your AWS cloud.
With AWS Config, you can easily detect stack drift using the “cloudformation-stack-drift-detection-check” rule.
Summary
AWS Config provides a simple way for your cloud environment to stay secure and compliant, thanks to its various predefined rules that can be deployed quickly and easily. In this article, we have reviewed only some of these rules, but there are many more that can be very useful for protecting your resources in the cloud. Additionally, creating custom rules affords you limitless possibilities. AWS Config is a powerful tool that should be considered by every business running on Amazon’s cloud.