
Automate compliance checks, manage configurations at scale, and more with AWS Config. Jillian interv
Loading summary
Rodolfo Brennas
This is episode 714 of the AWS.
Gillian Ford
Podcast, released on March 31, 2025. Welcome everyone to the AWS Podcast. I'm your host for today, Gillian Ford. And we've got a topic that applies to everyone, which I'm really excited about, which is AWS config or if you wanted me to understand what's running in your environment, internal IT requirements, compliance, security, all that fun stuff. We are going to be talking about how you can use it and I've got two experts on this topic. Let's introduce the experts here. So let's start with Tim. Tim Honeychurch.
Tim Honeychurch
Hi, Jillian. Really thrilled to be here. Talk about one of my favorite topics in the world, AWS config. So I'm Tim Honeychurch. I'm a principal specialist here on the cloud governance team and really looking forward to our conversation today.
Gillian Ford
Awesome. And Rodolfo Brennas.
Rodolfo Brennas
Hi, Jillian. I'm very excited to be here. I'm part of the cloud governance focus area here in aws. I'm a principal solutions architect and I focus in governance and compliance. And yeah, pretty excited to be here.
Gillian Ford
Love it. And for the folks who aren't familiar with AWS config, Tim, how would you describe it to them?
Tim Honeychurch
It's a bit of a challenge to describe everything that config does because it is such a multifaceted tool. But we like to keep it simple by saying that can use config to assess, audit and evaluate the resources in your AWS environment. It meets several use cases. Primarily what we. What we're going to be talking about today, I think, is the ability to have visibility into all of your resources and to use config to track where you are from a compliance standpoint. So we'll dig into some of those a little bit more. But just think visibility, assess, audit and evaluate.
Gillian Ford
I like that acronym. Actually, it's not even an acronym, but what you were just using describe config and definitely want to dive into that more because those are things that I see too with customers who are using config. They're using it for their external compliance requirements, understanding what's running in your AWS account and your internal IT requirements and definitely for security. So, Rodolfo, let's kind of start to break out how those can be used. So can you tell us how can config be used to understand what's running in your AWS account?
Rodolfo Brennas
Yes, of course. So basically, when you start talking about AWS config, the first thing that you all like to do is to enable it, right? Enable it. It's pretty simple, it's pretty straightforward. And how it's done is basically you go into your account, you go to the service and you enable it. And once you enable it, what it does is starts recording all the resources that are deployed within that account, within that region. So it creates what we call a config record. That is basically creates like a snapshot of all the resources within your account and start tracking the changes on those resources. And those changes is what we call configuration items, right? So every single time you make a change in one of your resources, it track it and then it gives you that timeline of the configuration changes on that particular resource. So it's basically through that config recorder that gets enabled. As I mentioned, AWS config is a service that you enable on accounts and on regions. So for example, you need to enable it in all the regions that you are actually running your workloads. And once you enable it, start recording though, it creates that snapshot and then it tracks the changes to that initial, let's say, baselining that it did.
Gillian Ford
And then once you enable it, like you can go into the config to config in the AWS console and see everything that's running.
Rodolfo Brennas
Yeah, exactly. So it's pretty simple. Once that initial baselining, it's complete, basically you just can go into the service and it actually gives you a very nice dashboard that includes all the main resource tabs that you're tracking, every single resource or every single services that it can have the ability to be tracked in. AWS config is going to be tied to what we call resource types, right? So just to give you an example, EC2 instances, right? That's a pretty common service that our customers use. Every single EC2 instance is divided in what we call resource types. So a resource type for EC2 instance can be a security group, could be an ENI, so it gets populated in that regard. So if you want to change, if any of the resources get changed, you will see that from the inventory capability that is there in the console for config, you can aggregate this as well. For example, if you are looking into capabilities across your organization, you can do this on using what we call AWS config aggregators. That is basically gives you the capability for you run an aggregation into a single delegated account and you can have the visibility of your inventory on a single place. It could be for multiple accounts, could be for multiple regions within one account, or for the whole organization. So it Gives you that main capability for you to centralize from the console to see the inventory of resources that you are currently using. And if there is a change associated to one of the resources, you can see what is related to it. So for example, you can go to the resource and say, okay, let me see, you will get like a history of changes, right? And on that timeline you will say, oh, there was an API that changed this resource. And I can just from the config console go to see what actually API was, what was the call, who did it, and you can track that from a centralized point of view.
Gillian Ford
I love that use case of being able to see everything that's running in your account, especially when customers are thinking about compliance and security. But there's some companies that also like to have their own internal IT requirements that are different from compliance or security. So how can they use config to be able to enforce those requirements?
Rodolfo Brennas
Yeah, and that's a great question, Gillian. So for example, as I mentioned, you have the capability for you to track the changes on those resources, but AWS config also gives you the capability or also has the feature for you to run your own evaluation policies. So for this we can leverage what we call AWS config rules. Those AWS config rules can be deployed centrally or on your single accounts. And we have around 300 or 400 AWS managed rules that are basically rules that we see from the field that are useful for our customers that they can leverage. Those are rules that are already there for them to run. Just to give you an example, if they have a particular, let's say requirement for you to rotate your AWS access keys right every 90 days, you can run that. That's basically something that a lot of our customers are concerned. They can choose that rule. And also if they want a multi AC deployment for one load balancer, for example, they can do that. Not just focusing on security, but from the operational point of view you can also do that cost optimization techniques. You could say, yeah, I'm trying to go to the next gen on ebs. I would like all my EBS volumes to be on GP3, for example. You can do that from AWS config rules. And once you have like an internal policy of, let's say common controls that you would like to deploy from AWS config, you can leverage what we call AWS conformance packs. So a conformance pack is basically a group of AWS config rules and those can be centrally deployed. Customers can aggregate as much Rules as they want, they can create those rules. As I mentioned, we have AWS managed rules, but there's also the capability for customers to create their own rules using Lambda or using Guard as a language within the capabilities of custom rules. So they can create their own custom rules matching on the policies that they want to meet, and then run those as detective mechanisms and also even proactively. So there is an API in AWS config that allows you to actually check the configuration resource before it gets deployed if you are running like infrastructure as code. So that's one capability that moving, shifting left to compliance, you can figure it out if that's something that you want to deploy even from the start. That's the main capability that customers can deploy. Run that internal IT requirements to make sure that it is following the best practices that they already defined that they want to keep.
Gillian Ford
That's a great call out about custom rules and also the actual rules that are within config so that people can be able to create their own custom rules based on their own internal requirements. And for anything that's compliance, which this is the big one, I see that most customers end up going down the journey of using config is when it comes to compliance. So, Tim, can you talk about how config can be used for, for continuous compliance in your account?
Tim Honeychurch
Yeah, I love that term, continuous compliance. So we mentioned at the top, assess, audit and evaluate, right? In this case, we're talking about the audit part, right? So, you know, the use case I'll describe becoming more and more common where customers are subject to particular regulatory frameworks, compliance frameworks, and you know, you think about config as being able to gather the information and the status of all of those resources to see if they are matching up against those compliance standards and what the regulators and auditors are looking for. So that's wonderful. But you know, those regulators and auditors don't necessarily have access to the console to be able to see those, those dashboards and inspect for themselves the status of those controls. So that's when we talk about how we can extend what config does into a couple of our other services. And in this particular case, there's a AWS service called Audit Manager that we can use to set up the ability to capture the status of those controls in a report on an ongoing basis. As you said, continuous, that can then be shared with auditors on a regular basis. So it's really powerful, right, to be able to have this really deep capture of all of the status of those Controls according to the particular frameworks. And as Rodolfo mentioned, there's lots of different conformance packs and ways that we can set up those controls to match the compliance framework in question and then be able to send those into a reporting package that can be accessed by whomever needs to. So that process, that operation is a really huge part of utilizing this service to help maintain the requirements of those control frameworks.
Gillian Ford
Got it. So these conformance packs that are within config, it sounds like it makes it easier for customers who have certain compliance requirements where there is a pack to. It can be able to check one of those packs and then it has a whole bunch of checks that Config does on your behalf, Correct?
Tim Honeychurch
Yep. So if you think hipaa, PCI Fedramp, you know, they all have their own specific sets, some of the controls are common across them. But to be able to set those up in config and then pull the results of that into a report for the HIPAA regulators or the, the PCI regulators, that's the, the workflow that, that we're talking about.
Gillian Ford
Really exciting. Let's. And security. I know Rodolfo, you started to talk a little bit about security earlier when you were giving the example of rules, but tell us more about what are some of the other things that config can do to help be able to enforce security in your environment.
Rodolfo Brennas
Yes, of course. So. Well, for all the security folks over there, I actually started a security specialist. So this is a topic that is pretty close to my heart. So one of the cool, let's say integrations that we have with AWS config is that actually powers a lot of other services within AWS that are actually tailored or created for the security Persona. Looking into aws, one of the key integrations that we have with AWS config is integrations, for example, with Security Hub. Security Hub is actually a service. It's a managed service that allows you to deploy security frameworks within your organization. And the way that it works at a very high level is actually it use AWS config in the backend to deploy several managed rules on your behalf. Right. Aligning to those security best practices that we mentioned. Right. So what happens if you want to follow AWS best practices? Pci, dss. Right. CIS frameworks for security, you can use the conformance packs that I mentioned, but you can also leverage the integration with services like Security Hub that allows you to actually run that centrally and actually deploy best practices checks to follow current guideline in terms of how you should deploy and other services that actually integrates and actually goes to the governance capabilities, not just from security. For example, how do you manage the policies or the security group rules, right. Or your firewall configurations. That is also an integration with Firewall Manager within AWS that actually in the backend, again, it powers a lot of AWS config capabilities like resource inventory capabilities and not just the tracking, but also the deployment of those managed rules on the customer behalf. So for all the security Personas over there, like those specific teams that are looking to apply or to enforce best practices and actually detect if something is going out of compliance in terms of the security guardrails that they would like to proceed there is that capability that the integration is there natively. One of the key benefits of AWS config is that it is developed to integrate very easily with AWS services. And when we speak about operations, right. We speak about security. All the cloud architects that are looking, for example to have a secure landing zone operate on their organization, they deploy managed services like Control Tower. Control Tower, again, actually highly depends. It's a mandatory service for you to have in order to deploy the controls that are available there. All the detective controls available in Control Tower for operational and security guidelines and guardrails are actually powered by AWS config rules and recorders in the backend. So that whole picture gets completed. And also you will like to see. Yeah, I want to know what, for example, if I realize that I have a specific resource that it switched from encrypted at rest as a default mechanism, somebody changed it and now it is not encrypting my data. Right. What happens? I want to know of course that something went out of compliance for me to fix it. But I also want to know who did it and when it happened. Right. Because it's something different that if it happens like an hour ago or happens. If it happened like two or three days ago, the severity of that change will be bigger. So you also would like to understand that. And that's where config also comes into place. Just to complete that picture of going something out of compliance. How you can easily track that within minutes from the history changes that are available in the console.
Tim Honeychurch
Yeah, I'm going to tag on a little bit to what Rodolfo was saying. Like from my perspective, one of the best kept secrets about config is its relationship to the security use case. Right. Most folks think about config from a inventory management or purely as we were just talking about compliance, which are huge use cases. But the tie in and the relationship between Security Services and config is big and we want to make sure people know about that.
Gillian Ford
Yeah, these are great callouts. A tie in between config and Security Services and how it's really powering a lot of these other services that people are relying on behind the scenes. Audit Manager, Security Hub One thing that I see that's really common, especially I work with startups is when they're still in the stages of defining their process. So they will turn on Security Hub, they'll turn on Audit Manager and so they've got all these notifications there, but they don't necessarily have a process to be able to quickly take actions on them. So Rodolfo, I'd love to understand from you, is there a process that you could recommend for companies to be able to quickly take actions from config?
Rodolfo Brennas
Yes, of course. We always say that we should automate everything that we are able to. Right. We don't want our engineers especially like in those startup companies that you mentioned, companies that organizations that probably they don't have a very spread team or they don't have a huge team to start actually looking into this and actually make remediations. So we want to support our customers in able to give them the capabilities for them to automate as much as possible. And if it is something that is there in the console that is easy to use, even better. Right. They don't have to create their own custom code in order to run some auto remediations. So AWS config as a service actually as I mentioned natively integrates with a lot of services. So of course we have an integration with AWS System Manager. Within System Manager there is a capability for you to run your own automations. There are of course managed documents over there that you can leverage. So just to give you an example, once you deploy those AWS config managed rules or those custom rules that you created to evaluate specific policies within your environment that are deployed there for you to follow specific policies, you can easily from the console say okay, if there is a drift within the compliance of this particular resource, I want to run an auto remediation from there from the console that actually what it's going to do in the backend actually run an automation from System Manager that with the proper permissions will actually correct that particular resource. So again following the example of the encryption on an S3 bucket, for example, you can say okay, if there is a non encrypted S3 bucket, I can run an auto remediation from System Manager that will actually encrypt that bucket again. And so of course that will save a lot of time and effort, manual effort, for our engineers to stop looking at the console and just making sure that, yeah, somebody created an S3 bucket that is not compliant through auto remediation, also through ticketing. Right. You can actually make sure that a. You are not, let's say, I don't want to say wasting the engineers time, but given them the capability for them to focus in more strategic projects and more complex issues that just enable encryption. Right. So running those auto remediations and that capability that is natively there in AWS config, of course, is of great impact in a positive way for them.
Tim Honeychurch
Yeah, I'll jump in again. Julian, like one of the things you're going to. You started to notice here over the last couple of points we've been discussing is how config works with other services. Right. So we've talked about Audit Manager, talked about Security Hub, now we just talked about Systems Manager. And again, I think one of the other best kept secrets about config is its ability to interact with those other services, to provide that comprehensive solution. And that's a big part of the story we want to tell Tim.
Gillian Ford
Also I want to understand from you is at least I see this a lot with customers is that they think, oh, I'm just going to put in my production environment because that's the one that's most important. But you actually tell customers all the time, hey, you should actually put it into your development environment. So why is that?
Tim Honeychurch
Yeah, it's an interesting dynamic by way of experience. I was on a team that managed the finances for our AWS account when I was a customer. And there's always pressure, right, to control your spending and be careful with which resources you are spending a lot of money on. So there's often a little bit of a mistake made by customers to say, well, you know, these are just internal development resources. I'm not really worried about it from a production standpoint. You know, I won't use config to monitor those resources. And why we say that might be a mistake is because those development resources are there for a reason, right? They're there to help you develop your, your products and develop your applications on those resources. If there are things happening with the way that those resources are managed, there are changes made that you're not familiar with that could really interrupt and interfere with your development cycle. Right. So you know, a best practice would be to utilize config to monitor those resources as well, so that you have the same real time visibility as you do in production about changes that may impact your ability to to do what your business needs you to do with those resources.
Gillian Ford
Ah, so not making mistakes in production that could have been prevented. I like it. That will get people's attention, right, Adolfo? So for those that are already using config and they feel like they're got a good grasp of how to use it, there's probably some other things that you see that they might not necessarily have been aware of. So what are some of those advanced features that they should start to think about using?
Rodolfo Brennas
Yes, of course. So. Well, one of the main capabilities that is available within AWS config is the advanced query capabilities, right. So we often see our customers ask us, hey, is there a way for me, for example, to track all the EKS clusters that I deployed in the past month that has this particular tag? Right. Is there a way for me to do that? Yeah. Are you running AWS config? Yes, I'm doing it. So from AWS config it gives you that it's already there, it's information that you can track easily there. So for example, there is this advanced query capability that allows you to do that. So for example, if you have a specific requirement that you would like to pull a report on advanced queries, gives you the capability for you to run specific, let's say, queries within your environment. If you're leveraging things like aggregator, you will have that on a multi account, multi region fashion. During re invent last year, we actually released the natural language query processor within advanced queries that actually allows customers to ask questions in plain English, right? The thing with AWS config, as it is a very dynamic environment, as probably most of you already know, we release new features, we release new services, we release new resource types very often and how those queries are actually built. You will need to know the SQL statements, right? You will need to know the name, the resource type. There is some knowledge that customers need to have or read the documentation to actually run the query. This natural language processor allows you to just ask the question how many EKs cluster I have with this particular tag, right? So, and that actually build the query for you. You can populate that query and just ask that question and it will run against your current inventory management. So it's a very easy use cases that I see most of our customers are not aware of the power of that query capability that I would say is very useful and I save a lot of time to our customers when they're trying to pull these kind of particular reports that their managers ask to.
Gillian Ford
Wow, that is awesome. I think a lot of people are definitely not and that you can just be able to ask something as simply like in that example, just in natural language. I love it. So last question here is. So if they've got multiple environments, multiple AWS accounts, what are some best practices to be able to manage their configuration data at scale?
Rodolfo Brennas
Yes, of course. So remember that I mentioned at the beginning that every single time you enable AWS config, it starts recording everything, right? It creates a recorder and starts tracking changes within your resource types. Now, one of the best practices that we recommend our customers to follow is in terms of global resources. Remember that I mentioned that AWS config is a service that gets enabled per region per account. So that means that resources that are deploy in specific regions makes sense, right? But what happens with all the global resources that are used in aws? Examples are mostly related to IAM controls, right? If you're aware like IAM roles, those are deployed globally and that means that you don't have to track those resources on every single region. So AWS config released a capability for you to exclude or to change the recording periodic of those resources. So for example, if you're talking about global resources, this particular case, you only need to track those on a single region. There is no need for you to track those resources on every region, because that just means that you're going to track the same thing all over again on every region and you want to optimize the cost of config. So we recommend, unless there is a specific use case where you need to track everything on every region, could be compliance or internal auditing needs. But if there's no specific need for you to track everything on every region, you can just say, okay, for global resources, I'm going to track the changes only in my main region and I can exclude this particular resource type from all the other regions. That way I don't get double charged, for example. Also, if you have ephemeral resources running in your accounts that are changing more than four times or 20 times, that are very ephemeral in that regard, that are changing a lot, or they are just getting created and getting deleted. If those are changing a lot, those are basically going to generate configuration items within your environment. That means that how AWS config actually gets priced is basically in the amount of changes, our resources, or the evaluations on top of that. Resource. So we also recommend customers that have a specific use case for resources that they don't want to track that often because they don't have a need for it. Right. It's a conversation of the risk that they have and the environment that they are running. They can decide, okay, I'm going to change the strategy of my recording. Either excluding global resources from the region recorder, or you can just change the continuous recording of a particular resource to a periodic recording type. So those kind of flexibility allows customers to manage the cost at scale. And of course, the integration with the aggregators allows you to centrally do that. Also, one of the things that AWS config supports from configuration data at scale and in terms of management is that it supports delegation of management of the service. Right. We recommend to our customers from a security perspective, not to use the management account to run production workloads. The same goes to audit. So from an audit perspective, you can have your auditing or security account for AWS config. And one of the best practices that we recommend is for you to delegate the administration of that particular service to that audit or security account. So that's part of the strategies that our customers are following in order not just to reduce costs with the changes on the recorded itself, but also from a management perspective at scale. How do you actually aggregate that multi region, multi account fashion into one single account for your management that is a delegated account? So I would say that those are like the main considerations, of course, the integration with organizations for AWS config.
Gillian Ford
San Tim, Rodolfo, you both have given people a lot to really think about in terms of how they can really best utilize AWS for continuous compliance, whether it's knowing what's running in your account, being able to manage your internal IT requirements, or your security requirements. So thank you both for being here on the AWS podcast.
Rodolfo Brennas
No, thank you, Julian.
Tim Honeychurch
Thank you so much, Julian. Yeah, it's a great opportunity. I appreciate the great conversation.
AWS Podcast Episode #714: Beyond Compliance - Assess, Audit, and Evaluate with AWS Config
Release Date: March 31, 2025
In Episode #714 of the AWS Podcast, hosted by Gillian Ford, Amazon Web Services delves deep into the capabilities of AWS Config—a pivotal service for developers and IT professionals focused on storage, security, infrastructure, and more. Joining Gillian are two AWS Config experts: Tim Honeychurch, a Principal Specialist on the Cloud Governance team, and Rodolfo Brennas, a Principal Solutions Architect specializing in governance and compliance. Together, they explore how AWS Config transcends basic compliance to offer comprehensive assessment, auditing, and evaluation of AWS environments.
Gillian Ford opens the discussion by highlighting the multifaceted nature of AWS Config, succinctly capturing its essence through Tim's initial description:
“We like to keep it simple by saying that you can use Config to assess, audit and evaluate the resources in your AWS environment.” (01:13)
Tim Honeychurch emphasizes AWS Config's role in providing visibility and compliance tracking:
“Think visibility, assess, audit and evaluate.” (01:49)
Rodolfo Brennas elaborates on the fundamental functionalities:
“Once you enable it, it starts recording all the resources that are deployed within that account and region, creating a snapshot and tracking changes.” (02:23)
Key Features:
Beyond external compliance, AWS Config serves internal IT needs by enforcing organizational policies and best practices. Rodolfo discusses the flexibility AWS Config offers for internal governance:
“AWS Config also gives you the capability to run your own evaluation policies using AWS Config Rules.” (05:41)
AWS Config Rules and Conformance Packs:
Use Cases:
Continuous compliance is a critical aspect for organizations subject to regulatory frameworks. Tim Honeychurch underscores how AWS Config facilitates ongoing compliance:
“Continuous compliance captures the status of controls in a report on an ongoing basis, which can be shared with auditors regularly.” (08:23)
Integration with Audit Manager:
Benefits:
Security is a paramount concern, and AWS Config plays a vital role in fortifying AWS environments. Rodolfo Brennas highlights the integration of AWS Config with other AWS security services:
“AWS Config powers services like Security Hub and Firewall Manager, enabling centralized deployment and management of security best practices.” (11:07)
Key Integrations:
Automated Remediation:
Scaling AWS Config across multiple accounts and regions requires strategic planning. Rodolfo provides actionable best practices:
“Exclude global resources from regional recorders to optimize costs and reduce redundancy.” (22:27)
Recommendations:
For seasoned AWS Config users, tapping into advanced functionalities can unlock greater efficiencies. Rodolfo introduces the advanced query capabilities:
“The natural language query processor allows customers to ask questions in plain English, simplifying report generation.” (20:09)
Advanced Queries:
Use Cases:
In this comprehensive episode, Gillian Ford, Tim Honeychurch, and Rodolfo Brennas illuminate the extensive capabilities of AWS Config beyond mere compliance. From enabling continuous compliance and enhancing security to managing internal IT requirements and leveraging advanced features, AWS Config emerges as an indispensable tool for modern cloud governance. By adhering to best practices and fully utilizing its integrations and automation capabilities, organizations can achieve robust, scalable, and efficient management of their AWS environments.
“Continuous compliance captures the status of controls in a report on an ongoing basis, which can be shared with auditors regularly.” (08:23)
“AWS Config also gives you the capability to run your own evaluation policies using AWS Config Rules.” (05:41)
For more insights and updates on AWS services, stay tuned to the Official AWS Podcast.