Hello and welcome to this short lecture on AWS Config Service Integration where we shall look at the relationships between AWS Config and other AWS services.

AWS Config has a specific relationship with the following AWS services, SNS, SQS, S3, CloudTrail and IAM. Let's start by looking at SNS.

We have already covered much of this in the previous lecture where I explained how SNS is used as the configuration stream for CIs and other important event notifications. By using SNS you can subscribe multiple different endpoints to the SNS topic created as a part of your configuration recorder information to extract data and process information. And this is where SQS comes in. If you had multiple accounts, you may want to have AWS Config in each account subscribed to the same topic in a primary AWS account. This is possible by allowing access of the service principle to publish to the same topic in the primary account. See the 'permissions for the Amazon SNS topic' within the following AWS developer guide for a sample policy on how to do this.

The Simple Queue Service, SQS, can be subscribed to the AWS Config topic, the configuration stream, which gives you a highly available and decoupled environment for the data within your configuration streams. By using SQS it allows you to create and use your own applications to extract only information and data that is pertinent to you. There can be vast amount of data coming into the configuration stream but you might only want to be notified and made aware of any changes that may relate to any potential security issues. As a result, you may want to pull information from the queue that only relate to security groups, NACLS, IAM roles etc. or any other resource type that could affect the security of your environment.

If you did decide to have different configuration streams in each region, so effectively different SNS topics, then you could still subscribe the same SQS queue to multiple SNS topics preventing your application from poling from multiple queues to process data from the configuration stream. S3 is used to store the configuration history files and any configuration snapshots of your data within a single bucket. And again, this bucket is defined within the configuration recorder. You can get AWS Config to create a new bucket for you or select an existing bucket. If you have multiple AWS accounts you may want to aggregate your configuration history and snapshot files into the same S3 bucket for your primary account. However, you will need to grant the right access for the service principle which is config.amazonaws.com to be able to write to the S3 bucket. Take a look at the section 'Granting AWS Config Access to an Amazon S3 Bucket in Another Account' within the following link for a sample policy on how to do this.

AWS CloudTrail interacts with AWS Config at the configuration item level. If we remember back to the section in the previous lecture the CI is comprised of five different sections. The final section, Related Events, displays the AWS CloudTrail event ID that is related to the change that triggered the creation of the CI for that resource. This feature is very useful when identifying who or what made the change to the effective resource. This CloudTrail data can be accessed via the AWS Config Dashboard within the AWS Management console, which will then link you directly to the event within CloudTrail. For more information on CloudTrail we have a course AWS CloudTrail, An Introduction that will define exactly what the services and how it works.

Conversely, when CloudTrail tracks and recalls changes made within the AWS Config itself, the following APIs are tracked, DeleteDeliveryChannel. This deletes the delivery channel. DeliverConfigSnapshot. This sends a configuration snapshot to S3. DescribeConfigurationRecorderStatus. This returns the status of a specified configuration recorder. DescribeConfigurationRecorders. This returns the details of a specific configuration recorder. DescribeDeliveryChannels. This returns information about a specific delivery channel. GetResourceConfigHistory. This retrieves a list of configuration items for a specified resource. PutConfigurationRecorder. This creates a new configuration record. PutDeliveryChannel. This creates a new delivery channel for an S3 bucket and SNS topic. StartConfigurationRecorder. This starts recording data for supported resources within your account as per your configuration. And finally, StopConfigurationRecorder. And this stops recording the data.

The final service that has a relationship with AWS Config is IAM. And again, we briefly covered this in the previous lecture. As AWS Config has relationships with other services, specifically SNS and S3, the use of an IAM role is required to enable the service to publish data to an SNS topic for configuration streams and S3 to store configuration history files and configuration snapshots. The policy for this access would look similar to the following on screen. In addition to this access, AWS Config must also be able to perform the described list and some get API calls against all supported services within the region. As a result, the same IAM role also has a second policy attached which allows access to perform these actions against those resources.

That brings us to the end of this lecture of how other AWS services interact with AWS Config. Coming up next we'll start to look at how to manage specific compliance with AWS Config. We briefly touched on this earlier when we looked at the config rules, so we'll now look at this in greater depth.