Using the AWS Config Service to Detect Unexpected Resource Usage

Posted by Doug Toppin

May 25, 2017 3:07:36 PM Cloud Enablement, aws

This is the first of a few related posts on the subject of the importance of controlling and constraining your AWS account resource creation abilities particularly in terms of IAM accounts.

A recent lesson learned caused us to research the area of unexpected resource usage in an AWS account. Trying out the AWS Batch service inadvertently resulted in the launch of an EC2 c4.large instance which ran for a day before we noticed that it was running. This was a surprise because the launch was not explicit, nor was the instance tagged with a descriptive name.  After terminating the instance we realized that with this particular account only a limited set of instance types should ever be run and the AWS Config service can be used to detect things outside of normal operational expectations.

AWS Config can be set up using rules that are evaluated and a report generated for anything that fails the rule checks. In this case a rule was created listing the 3 instance types that would be expected to be found for this account. When the Config rules are checked any instance not falling in that list will be reported as non compliant. Note that this service does not prevent the launch of out of norm types but only reports on them so you have to take the action to correct the issue. A subsequent post will cover how IAM policies can be used to prevent a launch in the first place.

Associated with this concern in general is the fact that AWS has a large number of EC2 instance types that can be launched of which some have a significant cost. The x1.32xlarge costs $13 per hour for example. It is reasonable to detect this sort of instance running or prevent it entirely before it becomes a cost issue. 

When a rule is created a trigger is also specified. The rule will automatically be run when a configuration change affecting the specified resources occurs. It can be also be configured to run automatically on a time scheduled basis. Where this is helpful is for circumstances such as detecting when a change is made for something not controlled by policies or otherwise that were in effect at the creation time.

Setting up the Config service

The following is an example of how the Config service can be used to confirm that only a limited set of instance types are running. The rule can be either custom entered or using one from a set of templates already in place.

First select the Config service console. Next select the Rules interface and filter on instance to reduce the set of choices. The template called desired-instance-type is the one we will use for this example.

 

config-03.png 

Enter a name for the rule and a description of what it is intended for. Note that DESIRED_INSTANCE_TYPE is the existing rule used by the template.

 

AWS Configure Managed Rule

 

The next step is to select the resource types that you want to be checked for compliance. EC2: Instance has already been set by the template. Associated with that are the InstanceType values that match your needs. For this example we are using m3.medium,t2.micro,t2.nano separated by commas.

AWS Managed Rule Trigger

 

Next select Save to create the rule. The list of existing rules will then appear.

AWS Save Managed Rule

 

Select the new rule to see the details and confirm that they match what is desired.

 

AWS managed rule select

 

To confirm that that the rule acts as expected try launching an instance type that is not in the list. After the instance is successfully launched the Confirg service should be automatically triggered and a Noncompliant report status should appear. The instance-id can be selected to go directly to that instance in the EC2 console. Manage resource can also be selected to get to the instance information. 

config-08.png

 

Once you confirm that the instance out of compliance entry is the new one then terminate it by whatever method you are most comfortable with.

 

config-09.png

 

Note that terminating instances also qualifies as a configuration change so the Config service rules will run again. The result should be that everything is once again in compliance.

config-10.png

There are numerous other templates that can be used for a variety of resource configurations which may be of interest for your account.

From reporting to restrictions

AWS IAM policies can be created that will allow or disallow resource usage and then applied to the IAM accounts that should be limited.

This would further mitigate the risk around accidental launches due to the lack of familiarity with a service or something like an auto-scaling group that includes that type. Malicious intent is another risk area. AWS accounts inherently have resource count limits protecting the account as well as the account holder budget.  These limits can be increased upon request, which means that multiple instances of unexpected types might be automatically launched in the worst case. These measures reduce the impact of the risk but the ability to prevent which is as important as the ability to detect.

Since most AWS accounts, particularly small company or personal, are not likely to need the entire set of instance types one strategy is to set up the Config service to include a rule to check for only a limited set and then run the compliance report at regular intervals.

Check back with our blog for future posts on this and other subjects of interest.

Subscribe to the Vizuri Blog

 

Posted by Doug Toppin

Doug Toppin has been involved in software systems design and development in both the commercial and defense realms for more than 30 years. His experience includes small and large scale systems with high processing and availability requirements in a variety of applications.

Find me on:

    
Request a Complimentary Docker Consultation

An Open View

Vizuri Blog

Subscribing to our blog is a great way to stay up to date with the latest information from Vizuri, as well as our strategic partners. We focus on providing a range of content that is practically useful and relevant from both a technical and business perspective.

We promise to respect your privacy.

×