Category: AWS Config

We announced AWS Config Rules (Dynamic Compliance Checking for Cloud Resources) at AWS re:Invent and made a preview available to interested customers.

As I noted at the time, you can use these rules to verify that existing and newly launched AWS resources conform to your organization’s security guidelines and best practices without having to spend time manually inspecting them. Instead, you define rules (AWS Lambda functions) that are run when resources are created or changed. The rule has access to the Configuration Item associated with the resource, and can also make calls to other AWS API functions as needed.

Available Now
Today we are making Config Rules accessible to all AWS customers, with initial availability in the US East (Northern Virginia) region and the ability to create up to 25 Config Rules per account.

We added some important features during the preview:

• Support for additional IAM and EC2 resource types. You can now write rules that process IAM Users, Groups, Roles, including customer-managed policies. You can also write rules that process EC2 Dedicated Hosts.
• Lambda Blueprints to help create custom rules. You now have access to blueprints for periodic rules and for rules that run in response to changes.
• CloudFormation Support for Config and for Config Rules. You can now automate the setup of AWS Config for new accounts, and you can automate the creation and configuration of the Config Rules.

Several AWS partners are already making great use of Config Rules in production. For example, Alert Logic, CloudHealth Technologies and Trend Micro Deep Security are using Config Rules as integral parts of their respective flagship products.

Creating a Custom Rule
I will create a rule that inspects an IAM Policy named DBSuperUserPolicy. I want to make sure that the policy has only one user, DBSuperUser, attached to it. If this is the case, the Policy is compliant; otherwise, it is not.

I start by creating a Lambda function using one of the new blueprints. I open up the Lambda Console, click on Create a Lambda function, and locate the blueprint that I want to use. I enter “config” in the search box:

I want my rule to run every time the IAM Policy is changed, so I select the first blueprint, config-rule-change-triggered. Then I enter a name and description for the function:

The code provided in the blueprint includes a function named evaluateCompliance. This function is the heart of the rule; it is activated on each configuration change and always returns one of the following strings:

• NOT_APPLICABLE -The rule does not apply to the resource or the resource type that it was given.
• COMPLIANT – The rule is relevant to the resource, and the resource is configured in a compliant way.
• NON_COMPLIANT – The rule is relevant to the resource, and the resource is not configured in a compliant way.

I replace the default implementation of the function with my own. It looks like this:

function evaluateCompliance(configurationItem, ruleParameters, context)
{
  if ((configurationItem.resourceType !== 'AWS::IAM::Policy') || 
      (configurationItem.resourceName !== 'DBSuperUserPolicy'))
    return 'NOT_APPLICABLE';
  if (configurationItem.relationships[0].resourceName === ruleParameters.attachedIAMUser)
  {
    if (configurationItem.relationships[1])
      return 'NON_COMPLIANT';
    else
      return 'COMPLIANT';
  }
  else
    return 'NON_COMPLIANT';
}

This rule is simple and powerful! Let’s go through it, line-by-line.

• Lines 3 and 4 check to see if the rule was invoked on an IAM Policy named DBSuperUserPolicy; line 5 returns NOT_APPLICABLE if this is not the case.
• Line 6 verifies that there is an IAM User attached to the Policy; line 14 returns NON_COMPLIANT if this is not the case.
• Line 8 verifies that there is no more than one User attached to the Policy; line 9 returns NON_COMPLIANT if this is not the case.
• Line 11 returns COMPLIANT to indicate that the Policy has exactly one IAM User attached, and is therefore compliant.

As you can see, this simple, 15-line function is all that you need to enforce an organization-wide policy across all of your AWS resources.

I also need to create an IAM Role so that the function can send the results to AWS Config:

If the function needs to access other AWS resources or APIs, I would amend the policy document accordingly. I select the role, confirm that I want to create the function, and I am already halfway there:

With the function in place, I need to arrange for Config Rules to call it as needed. I visit the Config Rules Console and click on Add Rule:

At this point I can choose one of the seven AWS managed rules, or I can click on Add custom rule (sounds good to me):

Now I name my rule, point it at my Lambda function (via its ARN), and indicate that I want it to be run when the configuration of an IAM Policy changes:

The rule will be evaluated within a few minutes; I can verify that my function has been invoked by taking a peek at the function’s Monitoring tab in the Lambda console:

From looking at these metrics I can see that the function has been run 7 times (I have that number of customer-managed IAM Policies), that each invocation lasts for less than 1 second, and that the invocations are not raising any errors. So far, so good!

Exercising the Rule
With the function running and attached to the rule, the next step is to make sure that it performs as expected. I create an IAM Policy named DBSuperUserUsagePolicy and attach user jeff to it (this is not in compliance with my rule, and it should be marked as such):

After allowing some time for the rule to be run, I return to the Config Rules console and I can see that there’s an issue:

I can learn more with a click:

If I don’t recall making the change or don’t know who did it (I did, but I was tired and clearly made a mistake), I can click on the Config timeline to learn more:

After some investigation I realize that I was supposed to use DBSuperUser, and update my Policy accordingly:

I wait a few minutes and check the rule details again. I am good to go – my resource is now compliant with my policy:

My change is reflected in the timeline (as you can see, I actually do spend some time away from the keyboard; I created the policy last night and edited it this morning):

Finally, I can see that my Lambda function was invoked after I updated my policy:

CloudFormation Support
You can now use CloudFormation templates to create your Config Rules and your Lambda functions. Here’s how you would create a rule that references a function called VolumeAutoEnableIOComplianceCheck:

"ConfigRuleForVolumeAutoEnableIO": {
      "Type": "AWS::Config::ConfigRule",
      "Properties": {
        "ConfigRuleName": "ConfigRuleForVolumeAutoEnableIO",
        "Scope": {
          "ComplianceResourceId": {"Ref": "Ec2Volume"},
          "ComplianceResourceTypes": ["AWS::EC2::Volume"]
        },
        "Source": {
          "Owner": "CUSTOM_LAMBDA",
          "SourceDetails": [{
              "EventSource": "aws.config",
              "MessageType": "ConfigurationItemChangeNotification"
          }],
          "SourceIdentifier": {"Fn::GetAtt": ["VolumeAutoEnableIOComplianceCheck", "Arn"]}
        }
      },
      "DependsOn": "ConfigPermissionToCallLambda"
    },

Partner Support
As I mentioned earlier, several AWS partners are already making great use of this feature. Here’s some more information on their offerings:

Alert Logic Cloud Insight allows customers to use AWS Config to configure checks for additional custom vulnerabilities. Learn more on the Alert Logic Partner Page.

CloudHealth Technologies stores AWS infrastructure configuration history and supports searching of changes by group, access to historical changes, and a history of asset configuration. Learn more on the CloudHealth Technologies Partner Page.

Trend Micro provides a comprehensive set of security controls. Learn more on the Trend Micro Partner Page.

Availability and Pricing
Config Rules is now available in the US East (Northern Virginia) region and you can start using it today. Now that it is generally available, you will be charged for usage as described on the Config Rules Pricing page.

— Jeff;

The flexible, dynamic nature of the AWS cloud gives developers and admins the flexibility to launch, configure, use, and terminate processing, storage, networking, and other resources as needed. In any fast-paced agile environment, security guidelines and policies can be overlooked in the race to get a new product to market before the competition.

Imagine that you had the ability to verify that existing and newly launched AWS resources conformed to your organization’s security guidelines and best practices without creating a bureaucracy or spending your time manually inspecting cloud resources.

Last year I announced that you could Track AWS Resource Configurations with AWS Config. In that post I showed you how AWS Config captured the state of your AWS resources and the relationships between them. I also discussed Config’s auditing features, including the ability to select a resource and then view a timeline of configuration changes on a timeline.

New AWS Config Rules
Today we are extending Config with a powerful new rule system. You can use existing rules from AWS and from partners, and you can also define your own custom rules. Rules can be targeted at specific resources (by id), specific types of resources, or at resources tagged in a particular way. Rules are run when those resources are created or changed, and can also be evaluated on a periodic basis (hourly, daily, and so forth).

Rules can look for any desirable or undesirable condition. For example, you could:

• Ensure that EC2 instances launched in a particular VPC are properly tagged.
• Make sure that every instance is associated with at least one security group.
• Check to make sure that port 22 is not open in any production security group.

Each custom rule is simply an AWS Lambda function. When the function is invoked in order to evaluate a resource, it is provided with the resource’s Configuration Item.  The function can inspect the item and can also make calls to other AWS API functions as desired (based on permissions granted via an IAM role, as usual). After the Lambda function makes its decision (compliant or not) it calls the PutEvaluations function to record the decision and returns.

The results of all of these rule invocations (which you can think of as compliance checks) are recorded and tracked on a per-resource basis and then made available to you in the AWS Management Console. You can also access the results in a report-oriented form, or via the Config API.

Let’s take a quick tour of AWS Config Rules, with the proviso that some of what I share with you will undoubtedly change as we progress toward general availability. As usual, we will look forward to your feedback and will use it to shape and prioritize our roadmap.

Using an Existing Rule
Let’s start by using one of the rules that’s included with Config. I open the Config Console and click on Add Rule:

I browse through the rules and decide to start with instances-in-vpc. This rule verifies that an EC2  instance belong to a VPC, with the option to check that it belongs to a specific VPC. I click on the rule and customize it as needed:

I have a lot of choices here.  The Trigger type tells Config to run the rule when the resource is changed, or periodically. The Scope of changes tells Config which resources are of interest. The scope can be specified by resource type (with an optional identifier) by tag name, or by a combination of tag name and value. If I am checking EC2 instances, I can trigger on any of the following:

• All EC2 instances.
• Specific EC2 instances, identified by a resource identifier.
• All resources tagged with the key “Department.”
• All resources tagged with the key “Stage” and the value “Prod.”

The Rule parameters allows me to pass additional key/value pairs to the Lambda function. The parameter names, and their meaning, will be specific to the function. In this case, supplying a value for the vpcid parameter tells the function to verify that the EC2 instance is running within the specified VPC.

The rule goes in to effect after I click on Save. When I return to the Rules page I can see that my AWS configuration is now noncompliant:

I can investigate the issue by examining the Config timeline for the instance in question:

It turns out that this instance has been sitting around for a while (truth be told I forgot about it). This is a perfect example of how useful the new Config Rules can be!

I can also use the Config Console to look at the compliance status of all instances of a particular type:

Creating a New Rule
I can create a new rule using any language supported by Lambda. The rule receives the Configuration Item and the rule parameters that I mentioned above, and can implement any desired logic.

Let’s look at a couple of excerpts from a sample rule. The rule applies to EC2 instances, so it checks to see if was invoked on one:

function evaluateCompliance(configurationItem, ruleParameters) {
    if (configurationItem.resourceType !== 'AWS::EC2::Instance') {
        return 'NOT_APPLICABLE';
    } else {
        var securityGroups = configurationItem.configuration.securityGroups;
        var expectedSecurityGroupId = ruleParameters.securityGroupId;
        if (hasExpectedSecurityGroup(expectedSecurityGroupId, securityGroups)) {
            return 'COMPLIANT';
        } else {
            return 'NON_COMPLIANT';
        }
    }
}

If the rule was invoked on an EC2 instance, it checks to see if any one of a list of expected security groups is attached to the instance:

function hasExpectedSecurityGroup(expectedSecurityGroupId, securityGroups) {
    for (var i = 0; i < securityGroups.length; i++) {
        var securityGroup = securityGroups[i];
        if (securityGroup.groupId === expectedSecurityGroupId) {
            return true;
        }
    }
    return false;
}

Finally, the rule stores the result of the compliance check  by calling the Config API’s putEvaluations function:

config.putEvaluations(putEvaluationsRequest, function (err, data) {
    if (err) {
        context.fail(err);
    } else {
        context.succeed(data);
    }
});

The rule can record results for the item being checked or for any related item. Let’s say you are checking to make sure that an Elastic Load Balancer is attached only to a specific kind of EC2 instance. You could decide to report compliance (or noncompliance) for the ELB or for the instance, depending on what makes the most sense for your organization and your compliance model. You can do this for any resource type that is supported by Config.

Here’s how I create a rule that references my Lambda function:

On the Way
AWS Config Rules are being launched in preview form today and you can sign up now.  Stay tuned for additional information!

— Jeff;

PS – re:Invent attendees can attend session SEC 314: Use AWS Config Rules to Improve Governance of Your AWS Resources (5:30 PM on October 8th in Palazzo K).

AWS Config lets you track changes to your AWS resources over time (read my AWS re:Invent post, Track AWS Resource Configurations With AWS Config for more information, and my AWS Config Update for a walk-through).

Today we are making AWS Config available in five additional AWS regions. We are also making Config’s email notification messages a bit more user (and email filter) friendly. Finally, I have some news from Japan — our partner LogStorage now supports AWS Config with their Integrated Log Management application.

More Regions
AWS Config is now available in a total of nine AWS regions. Here’s the full lineup:

• US East (Northern Virginia)
• EU (Ireland)
• Asia Pacific (Sydney)
• US West (Oregon)
• Asia Pacific (Tokyo) – New
• US West (Northern California) – New
• Asia Pacific (Singapore) – New
• South America (São Paulo) – New
• EU (Frankfurt) – New

Improved Notifications
AWS Config delivers a notification to Amazon Simple Notification Service (SNS) each time that it detects a configuration change for a supported AWS resource. You can choose to create an email subscription in order to receive timely notification of these changes:

We recently (March 27, 2015) improved the email messages in order to make them more readable and to make them easier to filter and process from within your email client. The subject line now includes the region, resource type, resource id, change type (create, update, or delete), and AWS account id. The email message also displays the updated fields in a easy to view format. The email is still in JSON, so you can also use it programmatically:

We have also given you the ability to disable SNS notifications entirely.

To learn more about this handy new feature, read Example Amazon SNS Notification and Email from AWS Config in the AWS Config Developer Guide.

Support from LogStorage
The integrated log management application from AWS partner LogStorage now supports AWS Config. Of particular note is the ability to search on individual fields of the notification and to set alerts that are driven by the results. For example, you can easily watch for configuration changes that involve all of your EC2 instances which use a particular AMI. You can also detect when EC2 instances are launched and do not use a set of pre-approved AMIs; this allows you to easily detect usage that is not in accord with your internal standards and practices. Here is what it looks like:

You can also display a diagram of your AWS resources and explore the relationships (as reported by AWS Config) between them:

For more information about this product, read Welcome to Logstorage.

— Jeff;

I first wrote about AWS Config last fall as part of our burst of announcements that we made during AWS re:Invent in Las Vegas. At that time I discussed the dynamic nature of the AWS cloud and how organizations face new challenges with regard to asset tracking, inventory management, change management, and governance when they move their operations to the cloud.

Today we are moving AWS Config out of Preview. We are also making it available in three additional regions and are now recording calls to the Config API in AWS CloudTrail. To top things, off, AWS Partner ServiceNow is ready to talk about the work that they have done to use the information generated by Config to drive their Configuration Management Database (CMDB).

Three More Regions
As we often do, we launched AWS Config in the US East (Northern Virginia) region. Today we are adding support for the US West (Oregon), EU (Ireland), and Asia Pacific (Sydney) regions, with support for others also on the drawing board.

My initial blog post provided a detailed look at the Console interface to AWS Config. During the preview we made a number of stylistic and usability improvements to this interface, based in part on feedback from our customers. For a change of pace, let’s take a look at the data that it collects and stores.

When I enabled AWS Config for my AWS account I created an AWS bucket called jbarr_starling_logs and set up the proper IAM permissions to allow Config to write to the bucket. At that time, Config took an initial inventory of my AWS configuration and stored it as a ConfigSnapshot:

The snapshot file is in JSON form and can be formatted and inspected using the jq command. Here’s a small excerpt to give you a flavor for what’s inside the file:

This excerpt describes one of my EC2 instances (“OscarDriver1”). As you can see, the snapshot contains information about the instance and the other AWS resources (Elastic Network Interfaces, Subnets, Security Groups, EBS Volumes, and so forth) that are related to it in some way (in most cases, you would use an application to analyze, visualize, and act on this information).

I can also use the cli-deliver-config-snapshot command to request fresh snapshots as needed.

Earlier today I made a slew of changes to my VPC configuration and deleted some resources that I no longer needed. Here’s what was written to the bucket shortly thereafter:

As you can see, there’s an entry for each AWS resource that I touched in some way. As was the case for the data in the initial snapshot, this information contains a lot of detail:

Now, let’s suppose that one of my colleagues was surprised by one of the changes and was wondering when a particular VPC was deleted.  She could simply log in to to Console, enter the id (or a tag), and see for herself:

Here’s what she will see:

The example above illustrates some (but not all) of Config’s major features. It illustrates recording of configuration changes and delivery to Amazon S3. This happens on a continuous basis as changes are made to the resources. The console takes this recorded information and gives you the ability to browse through it in a structured fashion. The raw snapshot and change information (similar in concept to a dump of a SQL database) is also available to third-party and custom-built tools.

You can also tell Config to send configuration change notifications to an Amazon Simple Notification Service (SNS) topic. You can do this from within the Console:

If you want to centralize notifications that were generated in more than one region, simply create a single Amazon Simple Queue Service (SQS) queue and route (publish) all of the notifications to the queue.

CloudTrail Logging
The calls that you (or the console) make to the Config APIs are now captured and recorded by AWS CloudTrail. You can use this information to see if Config has been enabled or disabled over time.

ServiceNow Integration
AWS Partner ServiceNow provides a comprehensive solution for enterprises to manage services deployed in the Amazon cloud. ServiceNow integrates AWS Config with the ServiceNow CMDB, and allows you to manage usage and costs of your AWS resources at the application, service, and cost center levels. Here’s how it displays the information:

To learn more, take a look at ServiceNow Configuration Management.

Available Now
Config is available for use in the regions that I mentioned above. As detailed on the Config Pricing page, you pay based on the number of Configuration Items (changes to your resources) that are recorded each month, along with the usual charges for S3 storage and SNS usage. In most cases these charges will be very modest in comparison to the charges for the use of the actual AWS resources.

— Jeff;

One of the coolest aspects of the Cloud is its dynamic nature. Resources can be created, attached, configured, used, detached, and destroyed in a matter of minutes. Some of these changes are triggered by a direct human action; others have their origins in AWS CloudFormation templates or take place in response to Auto Scaling triggers. The resources themselves, as well as their connections, settings, and other attributes, change over time.

With all of this change happening, organizations of all sizes face some new challenges when it comes to asset tracking, inventory management, change management, and governance in the Cloud. They need to know what was changed, when it happened, and how the change might affect other AWS resources. This need might arise due to an unexpected configuration change, a suspected system failure, a compliance audit, or a possible security incident. Regardless of the cause, having access to the right data enables a deep, data-driven forensic analysis.

Traditional configuration management tools were built in an era where resources and the relationships between them changed infrequently. These tools were costly, complex, and required some care and feeding.

Introducing AWS Config
We aim to address these challenges with AWS Config. This new AWS service captures the initial state of your AWS resources (EC2 instances and related items to start, with others planned) and the relationships between them, and then tracks creations, deletions, and property changes for analysis, visualization, and archiving.

You can enable AWS Config with two clicks! Once enabled, it discovers resources and records their current configurations and any changes to them. This configuration data can be viewed in timeline fashion in the AWS Management Console. AWS Config also delivers these CIs to you. Configuration changes are streamed to an Amazon Simple Notification Service (SNS) topic of your choice and are also snapshotted to an Amazon Simple Storage Service (S3) S3 bucket (also of your choice) every 6 hours. You can also process this data using tools from our partners (see below) or on your own.

AWS Config understands and tracks the relationships between your AWS resources. It knows that an EBS volumes can be mounted to an EC2 instance, and that the instance can be associated with (among other things) Security Groups, Elastic IP Addresses, VPCs, and Elastic Network Interfaces

With AWS Config, you get full visibility in to the state of your AWS resources. You can watch them change over time, and you can view the full history of configuration changes for a resource. You can see the connections between resources and determine how a change to one resource could potentially affect other resources. AWS Config gives you the information that you need to have in order to work productively in an environment that is subject to constant change!

You can discover all of your AWS resources and determine which resources are outside of policy for your organization. For example, you might want to track down all resources that are not within a production VPC. You might want to see which instances a particular Elastic IP address has been associated with over the course of the last two weeks. Or, you might need to know the state of a resource as of a particular date.

Using AWS Config
AWS Config is enabled on a per-account, per-Region basis. It is accessible from the AWS Management Console, the AWS Command Line Interface (CLI), and also provides a basic lookup API.

I start by enabling AWS Config for my account (within a particular Region). I can create a new SNS topic and S3 bucket, use a topic and bucket of my own, or I can use a topic and a bucket that belongs to a different AWS account (with proper permission):

I need to provide AWS Config with access to my AWS resources. This is done using an IAM role:

Data will begin to appear in the bucket and change notifications will be sent to the SNS topic. Here’s what the bucket looks like:

Unless you are building your own tools for AWS Config, you will probably not spend any time looking at the bucket or the data (scroll down to Inside the AWS Config Data if you want to know more). Instead, you will use the Console or a third-party tool. The Console lets you select a resource and then view configuration changes on a timeline:

Partner Support
Members of the AWS Partner Network (APN) have been working with AWS Config in order to address a variety of customer use cases.

Launch partners for AWS Config include:

1. 2^nd Watch
2. CloudCheckr
3. CloudNexa
4. Evident.IO
5. Red Hat Cloud Forms
6. RedSeal Networks
7. Splunk

Here’s what they have to offer, in their own words and screen shots!

2^nd Watch enterprise tools will allow users to visually see changes as they occur in their environment both in real-time and playback mode. The integration with AWS Config events also includes integration with New Relic application alerts, Amazon CloudWatch alarms and AWS CloudTrail events to simplify workload management. Customers have a visual tool to simplify event management and incident resolution.

AWS Config offers users the ability to create and maintain an audit history for their environment. The logs present an invaluable aid for security and compliance. The dynamic nature of the cloud, however, presents challenges for properly leveraging the logs. CloudCheckr‘s compliance policy engine already converts AWS CloudWatch metrics and CloudTrail logs into actionable information. AWS Config represents a natural extension further into this area.

Cloudnexa integrates with AWS Config to get a snapshot of resources in the AWS account, and for audit of historical configuration changes. This capability makes it unnecessary for Cloudnexa to design, build and maintain software and infrastructure to get these features.

AWS Config allows Red Hat CloudForms customers to enforce policies and ensure compliance for workloads running in Amazon Web Services. This extends the same level of control that CloudForms customers already enjoyed for virtualization and private cloud workloads to the public cloud.

AWS Config enables customers to track and store the history of Amazon VPC configurations and configuration changes in Amazon S3. With AWS Config, RedSeal customers get even more information so they can strengthen the defenses on their AWS-based networks.

Splunk provides software and cloud services that enable you to collect, index and harness machine data generated by the applications, servers, networks, sensors and other systems that power your business. The Splunk App for AWS, integrated with AWS Config, enables you to gain real-time and historical visibility into the configuration of AWS resources and how these resources relate to one another. You can also use the app to correlate data from AWS Config and AWS CloudTrail in order to gain a comprehensive view into security and compliance in your AWS account.

Inside the AWS Config Data (Developers Only)
Let’s take an inside look at the data generated by AWS Config. Here is a small portion of the snapshot data associated with a single EC2 instance. As you can see it includes complete identifying information, lists the set of tags on the instance, and describes the relationships that the instance has with a security group and an EBS volume:

{
  "configurationItemVersion" : "1.0",
  "configurationItemCaptureTime":"2014-10-28T02:30:36.989Z",
  "configurationStateId":2,
  "relatedEvents":["f8cdf490-3ddc-41ac-9cfd-9e1268dfba93"],

  "awsAccountId":"448164394201",
  "configurationItemStatus":"OK",
  "resourceId":"i-7053641e",
  "ARN":"arn:aws:ec2:us-east-1:348414629041:instance/i-7053641e",
  "awsRegion":"us-east-1",
  "availabilityZone":"us-east-1b",
  "configurationStateMd5Hash":"6ae267fafa03d87827137290c8b303e2",
  "resourceType":"AWS::EC2::Instance",
  "resourceCreationTime":"2013-04-26T19:36:06.000Z",

  "tags":{
   "UserTagDemo":"TemporaryTag",
   "Name":"RoadTripBlogServer"
  },

  "relationships":[
  {
    "resourceId":"sg-6e371c06",
    "resourceType":"AWS::EC2::SecurityGroup",
    "name":"Is associated with SecurityGroup"
  },

  {
    "resourceId":"vol-357a5f6c",
    "resourceType":"AWS::EC2::Volume",
    "name":"Is attached to Volume"
  }
  ]
}

AWS Config will send a notification to the given SNS topic each time it detects a change. The body of the notification contains detailed information about the change:

{
  "configurationItemDiff":{
    "changedProperties":{
    },
    "changeType":"CREATE"
  },

  "configurationItem":{
    "configurationItemVersion":"1.0",
    "configurationItemCaptureTime":"2014-11-04T02:28:33.146Z",
    "configurationStateId":1,
    "relatedEvents":[
       "f8cdf490-3ddc-41ac-9cfd-9e1268dfba93"
    ],

    "awsAccountId":"448164394201",
    "configurationItemStatus":"ResourceDiscovered",
    "resourceId":"vol-02fecb4d",
    "ARN":"arn:aws:ec2:us-east-1:348414629041:volume/vol-02fecb4d",
    "awsRegion":"us-east-1",
    "availabilityZone":"us-east-1a",
    "configurationStateMd5Hash":"16772ac8f8ccc7ed493a878f3bd88f8c",
    "resourceType":"AWS::EC2::Volume",
    "resourceCreationTime":"2014-11-04T02:25:10.281Z",
    "tags":{ },
    "relationships":[ ],

   "configuration":{
      "volumeId":"vol-02fecb4d",
      "size":2,
      "snapshotId":"",
      "availabilityZone":"us-east-1a",
      "state":"available",
      "createTime":"2014-11-04T02:25:10.281Z",
      "attachments":[ ],
      "tags":[ ],
      "volumeType":"gp2",
      "iops":6,
      "encrypted":false
    }
  },
  "notificationCreationTime":"2014-11-04T02:28:33.345Z",
  "messageType":"ConfigurationItemChangeNotification",
  "recordVersion":"1.2"
}

AWS Config will also send an SNS notification each time it stores a new snapshot of the current configuration.

AWS Config APIs
AWS Config provides two APIs that allow you to retrieve the resource configuration information:

• GetResourceConfigHistory – Look up configurations for a given resource within a given historical time range.
• DeliverConfigSnapshot – Trigger the creation of a full snapshot of your resources for delivery to S3.

Pricing and Availability
AWS Config is available in limited preview form and you can start using it today in the US East (Northern Virginia) Region. We plan to make it available in all public AWS Regions

With AWS Config, you are charged based on the number of resources and configuration changes recorded for supported resources in your AWS account (Configuration Items). There is no up-front commitment and you can stop recording Configuration Items at any time.

You will be charged $3.00 per 1000 Configuration Items recorded per month. Standard S3 rates apply for the storage of Configuration snapshots and Configuration history files. Standard rates also apply to any notifications delivered via SNS.

If you generate 10,000 Configuration Items per month, you can expect to pay less than $0.13 per month in S3 storage charges. The AWS Free Tier provides you will 1 million SNS notifications per month (you’ll get about 10,000 notifications if you have 10,000 Configuration Items).

— Jeff;