Deployments in production environments tend to be huge, both in terms of numbers of resources and the number of services being used. It is a tedious process to just manage these resources, monitoring these resources becomes becomes exponentially difficult as the size of the deployment grows. There is a big chance that changes to the configuration of servers/resources might go unnoticed and eventually cause severe issues the least of which is down time.
To help manage configuration of such huge deployments/resources in your account, AWS has a specific service known as AWS Config. It is a fully managed governance service which provides us with AWS resource inventory, config history and config change notification. What does this mean? It enables us to assess, audit and evaluate resources in our AWS account. This service monitors configuration of our resources continuously, which makes delegates the responsibility of checking configuration of resources to a single service and makes life easier for an AWS Engineer. Its also possible to monitor and record changes to configuration of resources of our choice so that we are notified when a change occurs and due to the recorded changes, it is also possible for us to know who made changes to the resources, this also makes Config helpful in scenarios where there is a security flaw in the system and we need to understand which resources have been affected.
This is a per region managed service, that is, management of Config needs to be done on a per region basis, data of all the regions can be viewed from any region on the Config dashboard though. It is not as sleek as CloudTrail, to enable governance for each region we need to go to each region and do it separately whereas that isn’t the case with CloudTrail.
Change notifications need to follow some certain rules which need to be breached so that there is a notification being sent to the account owner. There are 2 types of Config rules:
- AWS Managed Rules : There are 40 rules which are pre-defined by AWS which can be readily used by us to define the rules of our account.
- Custom Rules : Custom rules are those which can be defined by us, in case we need to define a rule which AWS does not define itself.
Information of any region can be viewed but rules are on a per region basis.
How does it work?
Every action taken fires an event to AWS Config, every event is stored inside an Config S3 bucket. This event can also trigger a lambda function, or a lambda function can be scheduled to check AWS Config to check for changes.
- Config items : Point in time attributes of a resource. (Which ports are open, which items does the ACL hold etc)
- Config Snapshots : Collection of config items. Collected at regular intervals of time set by the user.
- Config stream : Real time stream of changed config items.
- Config history: Collection of config items for a resource over time.
- Config recorder: That configuration of config that records and stores config items.
The trigger can be periodic or we can have rules which trigger a compliance check such as whenever any of the resources undergo a config change then that triggers a compliance check.
AWS Config is an important service for the AWS SOA, AWS DOP and AWS Security Speciality certification exams as well as an integral part of governance of an AWS account's deployments, I hope this has improved your understanding on this topic.