OrbitLIVE: Essential AWS Security Services
Welcome everybody to today’s orbit live. Today, we’re gonna be talking about essential security services in AWS, so let’s jump right in.
The idea of this session is not to be a comprehensive look at all of the possible security services that are available to us in Amazon. But to look at the things that we would consider to be the most important, and in some cases, things that we see often overlooked that are essential to protecting not only your account, but the resources within that account. We wanna dive into those in more detail.
The first service that we wanna look at is identity and access management. And I know a few of you are probably thinking, is that really an essential security service when you think about the security services themselves. I I think it is. And I the reason I wanted to start with this is we review and manage a lot of AWS accounts for customers. And what we often find is that the identity and access management service IAM is often overlooked.
And what ends up happening is you have less than appropriate security in many cases. If you’re not familiar with IAM, what this is, it’s the authentication and authorization service in AWS. It’s a free service It’s included in every account. It’s also a global service, which means the resources that you create within IAM exist across all of the regions within your AWS account. Right? So let’s talk about some of the key parts of IAM.
The first thing I wanna talk about is Iam users. Iam users provide resources or entities, let’s call them with permanent access to your AWS account and the resources within that account.
The thing that’s important to remember here is that I am users, they don’t necessarily have to be people. It could be a person, Joe from accounting, or it could be an application.
The challenge that we see a lot of people run into with I’m users is remember that I’m users have permanent access to your AWS account.
And you should really avoid creating resources that have permanent access to your account unless you have no other means necessary to provide either that person or an application with the access that they require. We’ll talk a little bit about better ways to do this in the next couple slides. Ideally, what you would like to do is provide temporary access, and we’ll talk a little bit about how to do that in a second. If you do find yourself in a situation where you have I am users in your account. One of the things that I wanna make sure you’re aware of is that you want to reduce the management overhead associated with managing permissions for individual users.
And the best way to do that is manage your access through group membership.
So you’ve got a DBA group You put all of the DBA users into the DBA group, and then you manage those permissions at the group level. All of the members of the group inherit the permissions associated with that group membership. The thing you have to keep in mind here is without groups within your IAM deployment, you manage permissions at the individual user level, and while that might not be a big deal at the beginning, you have a small number of users to manage as your account grows over time. And if you continue down the path of providing permanent access your AWS account, you can see how the management overhead, you go from a couple users to a couple dozen users to a couple hundred users the management of those permissions becomes much more intensive.
And as you have more permissions to manage, You can also see how you may find yourself in a situation where mistakes happen and somebody or something has permissions to your account or service within the account that they shouldn’t have.
Ideally, we want to provide temporary access. Temporary access is always better than permanent access. And the way that you do this within AWS is with a role. Rolls are beneficial for two particular reasons.
It’s more secure. There’s no permanent credentials for us to manage. There’s a service behind the scenes, the security token service STS that is actually responsible for providing temporary credentials Those temporary credentials, it’s more secure because there’s less for us to manage. The credentials are taken care of by another service, And that means with less to manage, there’s less likelihood of us making a mistake.
There’s less likelihood of permanent credentials leaking out of the environment. How you decide to provide temporary access to your AWS account is completely up to you. You can do cross account access where you still have IAM users, but maybe And those users, whether it’s a person or an application, then assumes a role in another account, to get that temporary access You could federate your users from some other directory service, maybe something that exists outside of AWS. You could also use something like Amazon SSO, which is now called the Identity Center, you could use that as a way to centrally manage all of your users, and then provide them with temporary access through role management to your various AWS accounts.
The last entity that I wanna just mention quickly here is controlling who has access to what.
The way that we do this in IAM is through what are called IAM policies.
Essentially, a policy is a JSON document that allows you to define permissions who has access to your account, what has access to your account, and then what actions can they perform against services? And really, as I mentioned already, we review a lot of accounts for customers, and this is where we see most people struggle And the challenge here is that you should be approaching everything you do from a least privilege. You wanna make sure that you don’t end up with every user in your account or every application that needs access to your account becoming an administrator, and this is where we see a lot of people struggle.
What we end up finding in a lot of accounts is you might have twenty users or twenty roles that exist within your account, and the majority of those users or roles, let’s just make a number up. Eighteen of them have permissions that far exceed what they actually need to to perform their job on a regular basis. So, really, what you wanna do here is make sure that you take the time and this is gonna take some time to not only learn how to build lease privilege I am policies, but also maintain those lease privilege I am policies or permission, sorry, over time.
Another thing that we often see people struggle with is that I’ve created and they were valid six months ago, but you’ve never looked at them since. And requirements change. So this is not something that you just create a single time and then never go back and look at again, you’re gonna have to constantly be evaluating those policy documents, those permissions documents, and ensure they’re still effective. Right? I’m giving somebody or something just enough access to perform the activities that they need to perform and no more.
The other thing I wanted to point out are the different types of policy documents.
There are two main types of policy documents that we wanna talk about today. The first are managed policies. And there are two types of managed policies. We have AWS managed policies. These are policy documents that are created and maintained on our behalf by AWS.
You can use these policies wherever you would like. You could associate them to your users, you could associate them to your groups, your roles, However, you wanna use them. But remember that you have no control over what’s in those documents. Amazon creates them and maintains on our behalf. It’s a great starting point. It’ll get you running very quickly.
However, what we would generally suggest that you do is use customer manager policies.
These are policies created within I’m that we create and that we’re responsible for managing.
The reason that I would suggest that you use customer managed policies is it gives you finer control. Right? It gives us more granular control over the permissions that we’re providing to entities, users, applications, whatever it might be. That’s not to say that AWS managed policies aren’t starting point and quite often, we will take an AWS managed policy and use it as the starting point for now a customer managed policy because maybe we need a Let’s just make a number up. We need three quarters of what’s in that policy document, but the other quarter we don’t need. So we can’t modify the AWS managed policy but we use that as the basis for our customer policy.
Another type of policy document that I just wanna mention briefly you can create inline policies.
In line policies are embedded directly into the resource. You put an inline policy and you associate it directly with the IAM user, Joe, as an example. So it allows us to create a one to one relationship.
Manage policies can be used across multiple entities, and they exist independently from those entities, versus an in mind policy since it’s embedded directly in the entity, in our example, if we delete the IAM user, Joe, any inline policy that we’ve associated with that user also goes with it. One additional, policy document that you should know about, it’s a little bit of a more advanced concept is what’s called a permissions boundary. Your permissions boundary is still a permissions document that you created maintained within IAM, but it’s important to remember that a permissions boundary doesn’t grant permissions itself. What it does is it sets maximum permissions. The way to think about a permissions boundary is think of it like a filter.
It sets the maximum permissions allowed, and then, you know, but still is going to take in any other identity policies or resource policies that may be associated with the user or the action that you’re trying to take.
I mentioned earlier on that creating and maintaining least privilege over time is difficult.
You need to be able to regularly evaluate the permissions documents, the policy documents that we’ve talked about, you need to be able to regularly evaluate those and make sure that they’re still appropriate for what it is that you’re trying to do.
I would suggest strongly that you enable the IAM access analyzer within your environments.
The analyzer, once you’ve enabled it, it does a bunch of things for us, or it provides us with additional information. The first is it provides us with a view of any permissions documents that allow access outside of what is called your zone of trust. We’ll talk a little bit more about this later on, but essentially what it’s doing is it’s saying, hey, your zone of trust is an account. And there’s this particular policy that allows access from outside of that zone of trust.
It’s gonna highlight those for you. Might be perfectly valid. It might be something that you created yourself, but it’s great to understand what has access to your environment outside of that Zona trust. So that’s the first benefit of it.
The next thing is the IAM access analyzer helps validate your policies. It does simple grammar checking, but it also evaluates those policy documents against a set of predefined AWS best practices. So that’s great. The other nice thing you can do is you can use the IMAC analyzer to help you generate your policies.
The way that it does this is it uses it uses log data from another service we’re gonna talk about in more detail here in a second, cloud trail.
So it takes all of that information from cloud trail it can help you to find those policies. So turn on I’m access analyzer. The other nice thing is there not something we’ll talk about today and any great detail, there’s a slide for this, there’s also something called the s three axis analyzer.
The s three axis analyzer depends on I’m access analyzer to be in place, but the s three analyzer does essentially the same thing. What it’s gonna do is it’s going to look at all the s three resources in your environment and determine you know, proper configuration. It’s also gonna determine if there are permissions documents associated with those s three buckets that allow access from outside your account. So Once the IAM access analyzer is turned on, have a look at the s three axis analyzer as well.
In the previous slide, I mentioned cloud trail.
Cloudtrail is super important. This is pretty much the very first thing that we would enable in an account that we’re managing or an account that we’re creating, it’s important to remember that everything we do in AWS, regardless of how you’re interacting with AWS, through the management console programmatically, Everything we do is an API call. Cloudtrail records all of those API calls.
And once you’ve finished the configuration of cloud trail, it will store all of those API calls for the time period that you define.
And Cloudtrail is really important for a number of reasons. First off, I think it’s a fantastic troubleshooting tool.
The biggest challenge that we see people run into in AWS is generally permissions.
You’re trying to do something. You don’t have permissions to perform that action. The very first place that I would start, if I find myself in that situation, or I’m helping somebody else with a permissions issue is cloudtrail. I can very quickly go into cloud trail.
I can look at a particular user, let’s say, as an example, and I can see the API calls that user made in which ones were allowed and which ones we received and access denied for. Great troubleshooting tool. Use it all the time. In addition to that, it also may help you meet your compliance requirements because now I have a log that can help illustrate all of the activity that’s happening in the account.
Regardless if it’s from a person, an application, another AWS service, everything is an API call, and Cloudtrail will record all of that activity for us and store it, so might help you with your compliance requirements as well.
A couple key things to think about with Cloudrow, Unlike IAM, cloudtrail is a regional service.
Best practice is to turn cloudtrail on in every region in every account. I mentioned also that Cloud Trail is there already. When you create a new AWS account, cloud trail will be enabled, but it doesn’t permanently store your log data. So you need to, as I mentioned already, finish the configuration.
Essentially what you’re doing when you’re finishing that configuration is you’re, well, configuring cloud trail to to push those logs somewhere, an s three bucket, cloud, locked log destination, maybe a combination of both. It’s, again, up to you to decide what you need to do. You just need to make sure that that trail has been configured. You create a trail and you configure it to retain that data, those log entries over an appropriate period of time.
It’s also really important to make sure that you protect the cloud trail logs.
How do you do that? First off, you want to limit access to those logs.
One of the best ways that that we know to limit access to those logs is get the logs out of the account. So let’s say you’ve got an account for a marketing project, and you’ve configured cloud trail in that. You’ve created a trail in that account. Great.
Okay. One of the first things that we would do then is we would have a centralized account. Let’s call it a log archive account. And we would configure, in this example, Cloudtrail, to aggregate all of its log data into that log archive account.
We can push all of that data from every account in every region into now an s three bucket that sits in a central logging account.
One of the best ways to protect your logs is just keep people away. Keep people away. Keep applications away from those logs. So now that we’ve got all of that log data in one location, you can see how we can limit access more effectively in that single AWS account.
The other thing that’s really important here, and this really goes for data in general. You wanna make sure that one you’re protecting your data while it’s in transit, and two, you’re protecting your data while it’s at rest. So cloudtrail log data that’s being stored in s three, even cloud wash logs follows that same best practice. Right?
Make sure that your logs are protected at rest. By default, it’s gonna use server side encryption with KMS keys, we would recommend that you take a little more control over that key management and you create your own customer managed keys And you still managed through KMS, but now it’s a key that you control, you manage the permissions of that key, and you use that key to protect those cloud watch logs. Or sorry, cloudtrail logs. And then finally, the last thing is you wanna make sure that you protect the integrity of those logs.
Even pushing all the logs into a centralized account AWS doesn’t mean that somebody or something doesn’t go in there and try to alter those logs. You never know. You can enable what’s called log file integrity on your cloud trail logs, and this is essentially creating a hash of all those log files, and we’ll notify you if the hash doesn’t match. So now I know something’s been modified.
Okay? So That is one of the most important services.
Cloud Trail, set that up and get it configured.
The next service I wanna talk about is AWS config. I think of AWS config as a configuration management database for AWS. And, again, this one often gets overlooked. So let’s talk a little bit about what this is.
To overly generalize AWS config records all of the changes in your account. It discovers resources as they’re deployed within your account and then records those changes. You know now exactly who or what?
Made a change or created a resource within your account, and this is why AWS config is so important.
It is important to remember that like cloudtrail AWS config is a regional service, Ideally, you want to enable config in every region and every account.
At a minimum, though, I would suggest that you enable config in any of the regions that you’re operating in. Okay? Fair minimal. Ideally, though, you turn it on everywhere.
Another nice feature of config that is is easy to overlook is what they call configuration snapshots. Configuration snapshots give us a picture of all of the resources and their current configuration at that moment in time.
Once you’ve enabled configuration snapshots, then you get those pictures, right, those little slices of time.
It’s important to make sure that log data gets stored somewhere, and I would suggest that you very similar to cloud trail is you aggregate those configuration snapshots coming from config into a centralized account.
It might even be the same account where you’ve pushed off your cloudtrail logs, that centralized security account or log archive account. And this is where the real power of config comes into play. K? It’s great to have configuration information, go back over time and look at how things have changed, You can use that CMDB sort of concept to understand possible effects of changes in your environment you wanna I don’t know, modify a security group.
What resources is that security group related to? Those are all the great parts of just config in general. But this is where the real power of config comes. This is what are called config rules.
Config rules allow us to monitor the resources in our accounts according to compliance. Right? So now we can use rules that we say well, we talked about security groups. So let’s use that as the example.
No security group in this account should ever have port x y z open to the internet. You could create that as a config rule. And then what config will do is it will give you a compliance report. It’ll say, well, you have fifty security groups in your account, forty eight of them are compliant. These two are not.
How does it determine that compliance through config rules?
The best about config rules is you don’t have to create everything from scratch. Over time AWS has added a ton. Every time I seem to turn around, there seems to be more AWS managed config rules.
You can then just take those config rules from AWS and enable them in your account. So you don’t have to build everything from scratch. K. And then when you have very unique use cases, you could go ahead and create your own custom config rules or customer managed config rules if you wanna think about it that way. One last thing I’ll say about config rules before we move on, an additional feature that really makes this powerful, so Getting a compliance report is one thing.
I’ve got those I don’t even know what I said now. Twenty security groups, eighteen of them are compliant, two are not. So those two noncompliant security group configurations, you have to go fix them. Right? You have to remove that rule that says allow port x y z from the public Internet.
Takes time. Everybody’s busy. One of the benefits just general benefits of AWS from my perspective is It’s really just a collection of APIs, so it can be highly automated.
And config has a feature that can help us automate that remediation.
It’s called a remediation action. You can define that config rule and then you can create an a remediation action that says, if something is non compliant, perform this action. So in my simple use case, I could have a remediation action that says, well, if you find this port open, remove it, and it would go and remove that port.
So now I don’t have to wait for somebody to go and fix that. It does it for us. So config rules are really where I believe the true power of AWS config is when you combine these two services together, config and cloudtrail, you really have a complete picture of what’s happening in your environment. Who did what? When did they do it? Right. What was the outcome of those actions?
K. And when you when you add in config rules, Now we know who, what, where, when, and is it compliant.
Right? Is it meeting our our compliance guidelines?
And ideally, if it isn’t, let’s remediate it automatically.
The next service that I wanna highlight is guard duty. Guard duty is a managed service that uses machine learning, anomaly detection, various data sources from AWS from third party threat detection services to help monitor not only your account but specific services within your account, and really what it’s trying to do is identify unusual activity. Whether that activity is at the account level or within the services that are supported by guard duty.
And then what it does when sees something unusual, it generates what’s called a finding.
This is a service that is so easy to turn on. You absolutely should be in every account that you deploy in every region that you’re operating in, again, at a minimum. Ideally, it’s in every region, but if you wanted to tone it back a little bit, make sure that it’s in every region that operating in. So turning guard duty on is easy. The challenging part with guard duty, at least in our experience, is taking action.
The action piece is always the hard part. This isn’t unique to guard duty. Right?
So let’s say again, we determine or guard duty See some type of anomalous activity happening within your account. It generates a finding.
If nobody’s watching those findings, or you don’t have automation in place to take action on those findings, then you can see where this falls apart. Right? So make sure that not only do you enable guard duty, but you have, ideally, automation in place, but you don’t have to boil the ocean here. But make sure that at least you have a process that says we will do x, y, and z every day in guard duty as you work towards the process of automating those findings.
Now can you automate everything? The Remi of those findings? No. In that case, you’ve got some sort of notification system or something like that built out that tells the people that need to know that they do have some activity that needs to happen here.
K. So that’s guard duty.
The next service I wanna highlight is Amazon Security Hub. What security hub allows us to do is enable a set of security standards. There’s a number of security standards that are supported A subset of those security standards are enabled by default, but what happens is security hub uses those standards the ones you’ve enabled to evaluate your current account configuration and the services within those accounts against that security standard. It helps you with compliance.
Right? There are fifty checks. You pass forty of them. You’ve failed these ten. Now you can go off and figure out what it is that you’ve missed and configure it properly.
The important thing to remember about security hub first off is security hub relies on AWS config.
Really, what security hub is doing is it’s creating config rules.
If you turn on security hub, before you have AWS config enabled, it will partially work, but not really. So you wanna make sure that prior to turning on security hub, config is deployed in the appropriate region where you’re gonna enable security hub because security hub, and, as I’ve already mentioned, are, again, regional services, gotta make sure they’re turned on in the right spot.
So that’s security hub.
The next must have security service is inspector.
There are two versions of inspector. I think both are still available. You wanna make sure that you’re using version two. I think it is the newest version.
The reason is the original inspector was an agent based solution. I think in version two, the agents still exist, but you don’t have to use them. So What’s great about Inspector is we can run vulnerability assessments across EC two based solutions, It supports scanning container images that are stored in the elastic container registry ECR, and it also supports Lambda functions. So now we have an automated vulnerability assessment service within our environment that will automatically go out and start doing this work for you.
Don’t have to install agents. You don’t have to configure anything.
Turn it on. It’s gonna start working away in your account.
Like the other services that we’ve talked about to this point, it generates findings. So as an example, if it’s scanning an EC two it’s gonna come back and give you a list of the Cves, things that you need to patch. And it’s gonna categorize those, right, from high severity to low severity. Gives you a great picture of the current status of your environment and activities that you might need to take. So that’s inspector.
If you are building workloads that are public facing, you absolutely should use the AWS web application firewall.
It provides an additional layer of protection in front of those public facing resources. It supports a bunch of different AWS services, So cloud fraud, the API gateway, the rest implementation of the API gateway, application load balancers, a few other things as well. If I’m putting a load balancer, out in front of a customer’s environment or a cloudfront distribution out in front of a load balancer, let’s say. The WAV is gonna be there. The WAV allows us to inspect all of those incoming requests.
And what’s great about the WAV is This is the first example of a service that is outside of its global, right, up to this point. All the other security service we’ve talked about are regional specific. With the WAV implementation, it’s gonna operate. The global infrastructure, it’s gonna operate at the end. So what happens is a client request comes in we can intercept that client request close to where it originates, right, close to that customer themselves, and evaluate that request against rules within our WAV. Also, great about the WAV is you don’t have to build all the rules from scratch.
Amazon has a large set of managed rules. There are third party providers that also create rule sets.
Couple things to keep in mind. AWS offers a number of free managed rules.
Great. Right? They also have paid rules. So in addition to the cost of running the WAV, you pay for those managed rules, and then you’ve got these third parties in the ABBS marketplace that will also provide you rules for a fee.
So just make sure you calculate the cost of this when you’re thinking about putting a WAV in front of your infrastructure. I’m not dissuading you from using those managed rules. They’re fantastic. Make sure you understand the pricing model so you don’t get scared at the end of the month with a surprise bill.
In addition to those managed rule sets, you can also create your own custom rule sets. So quite often what we’ll end up doing is using a combination. Right? Quite often we’ll use a set of AWS managed rules, cover off a lot of the basic stuff, and then in those very unique instances for that customer, we’ll then augment whatever is available through AWS with rules that are specific for our customers.
So you can mix and match them. As I mentioned at the beginning, right, as I’m going through the slides, I’m like, oh, I should have talked about this. I should have talked about that. By no means, is this a complete list of all the security services?
I consider the list that we’ve just gone through to be sort of the minimum.
Security services. And, yes, these will increase the costs of your AWS deployment, but I think The overall cost increase is most times not crazy. And if you plan ahead properly, you can at least estimate those costs early in your project, so you understand nobody gets surprised at the end of the month with a bill that they didn’t expect because you’ve laid out some estimates on those costs. As we are going through the slides, you’ll notice that I said, okay, we’ve gotta deploy this.
We’ve gotta deploy this. We gotta deploy this. These are all additional steps, right, things that you have to take into consideration. So how could we streamline this?
How could we make it a little easier?
Or AWS organizations is a great way to help you streamline the process of setting these servers these services up.
But also ensuring that they’re enabled in every account that you have. If you’re not familiar with database organizations, this is a service that helps you manage multiple AWS accounts, centrally.
As part of this service, what we can do is we can create administration or delegated administration. So I can say guard duty must be enabled on all accounts within our organization. So when you add a new account, guard duty gets enabled, the other really great thing about organizations is it allows you to delegate the administration of these services. Now, first thing to point out is AWS organization doesn’t support every service in Amazon. But it supports the services that we’ve talked about today. I think it’s about, let’s just say, thirty ish services are supported by AWS organizations. The last time I looked, The other thing to keep in mind with AWS organizations is not all the services that it supports what it calls delegated administration.
Deligator administration, though, is really great because what you wanna do is as best you can avoid allowing anybody or anything access to the management account. The management account is where you turn on your AWS organization service. So what I could do is I could delegate let’s use guard duty as the example. I could delegate the administration of guard duty to our security account. So now the administrator doesn’t have that to access the management account I can give them access to our security account through, let’s say, AWS identity center.
They log in there with a role, so they only have temporary access, right, no permissions to manage locally in that account, and then they can administer the guard duty service across all of the accounts within our organization.
The other nice thing about organization is when you enable a service, I think they call it trusted access, and then you have delegated administration.
When you enable that service in the organization’s solution, you can no longer so what you’ve got is management accounts and member accounts. So I’m gonna go into the management account, and I’m gonna say enable guard duty across all of my accounts, the member accounts.
Even if I’m an administrator in one of those member accounts, I log in I go to the guard duty console, I can see all the stuff there. Right? I can see my findings. I can look at the configuration. But if I try to change anything, it will say This service is administered from count x y z. So it also gives you that ability or the ability to restrict who can do what, to these really important services in your member accounts.
So streamline the deployment, simplify the management, And then on top of that, if we think about AWS organizations as a security service, it has some other things that are really interesting.
The one that comes top to mind here is what’s called a service control policy in SCP.
It’s just a JSON document again. Right? It’s very similar to permissions boundaries in the sense that it acts as a filter. So it doesn’t grant permissions or deny permission. Filters permissions.
What’s really interesting about service control policies, though, or SCPs is they operate outside of the individual accounts themselves. And it means that even if you log in as a root user, an administrative user, if I have an SCP in that account that says, you cannot disable cloud trail. Even if you log in as the root user, you can’t disable that service. So SCPs managed within the organization’s service and apply to everything in an AWS account, including the root user.
Now the challenge with AWS organizations is you still have to do the work. You still have to turn the service on. Then you still have to enable trusted access for the services. Then you still have to delegate the administrators for those various services.
All of this can be scripted. K? So it’s not like you have to do everything through the management console. But it’s still a lot of work. There’s things that you have to do and there’s it’s easy to overlook things. What’s nice about organizations is it gives us complete control. But with that level of control, means that we have some administrative overhead.
So what if you find yourself in a situation where you’re like, hey, listen, we gotta do this kind of stuff But I don’t have a big team, or I don’t have a lot of maybe the skills to know exactly how this is done. I’ve never done it before. How could you streamline that? This is where another service comes into place.
And this is control tower. And control tower is, another offering from AWS.
That allows us to start weekly and build out a secure environment based on AWS practice.
And then With Control Tower, what’s different about it from organizations is it takes care of a lot of that administration for you. It’s based off organizations.
But it’s doing some of that work for you. And then on top of that, it provides all sorts of built in controls, both detective and preventive controls.
Out of box. You don’t have to create them.
You create your control tower implementation.
You import existing accounts or you create new AWS accounts and then control tower takes over the management of that and implements those controls. Streamlines the process helps you manage an environment and ensure that you’re managing that environment according to your particular best practices.
The thing you have to take into consideration here, everything’s always a trade off. Right? The convenience of something like control tower does mean though that we’re gonna give up a little bit of control. So you might not be able to do everything exactly the way that you wanted, If you did it through something like organizations, but the trade off here is that we have less day to day administration We’ve got a bunch of built in controls that we didn’t have to think about. And we can augment them with additional controls where it makes sense, so trade off.
So that is our quick tour of essential security services in AWS. Thanks very much for joining me today. One last thing before we go. We recently were approved as an AWS well architected partner So I just wanna pass along that if you’re interested, you can listen to this and you’re like, geez, I’m not quite sure where we are in this journey.
I would love to offer out to everybody a AWS well architected review, where we’ll work with you and your team to evaluate Your current workload against the standards that have been developed by AWS over the years, it’s part of the well architected framework, I’d be more than happy to discuss it in more details if you’re interested. So thanks very much for joining me today. We’ll be back next month. Bye