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.
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.
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.
Next select Save to create the rule. The list of existing rules will then appear.
Select the new rule to see the details and confirm that they match what is desired.
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.
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.
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.
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.