OrbitLIVE: Security Checklist
Downloads
Transcript
Hey, welcome everybody to another edition of OrbitLIVE. In this session, we’re going to talk about our AWS security checklist. We’re going to keep it at a very high level, but we’re going to go through some of the main bullet points. I’ll also share a link here where you can grab a copy of our checklist yourself.
So I think it’s important here before we jump into going through the high level points of our security checklist that we remember that its important to remember that security is a shared responsibility. And you want to make sure that you understand the shared responsibility model.
In two sentences, remember that AWS is responsible for security of the cloud. And as a consumer, or a customer, you’re responsible for the security in the cloud. And also, just, I don’t think I need to say this, but I want to say it anyways, just to… Make sure anybody watching this later is clear that what we’re talking about here today is not a one and done sort of situation.
You don’t go through the checklist and say, great, I never have to think about this again. Following best practices is something that you’re going to have to do on a regular basis and go back and re evaluate because environments change, configurations change. You gotta just make sure that you’re still adhering to your compliance requirements, not only from day one, but until the point where you decide to retire a workload.
And speaking of the shared responsibility model, this is just a link. You can scan this QR code. It’ll take you over to the shared responsibility model page. It’s literally one page, right? And it talks about who’s responsible for what. The thing to remember with the shared responsibility model is depending on the types of services you’re using infrastructure as a service versus a managed service, the demarcation point between who’s responsible, right? It’s an AWS responsibility. It’s a customer responsibility. That demarcation point is going to change.
Ideally, what we would like to do is by using Managed services, software as a service solutions on AWS. We can push that demarcation point up, meaning we’re shifting more responsibility to AWS. That lets us focus on, managing our applications, improving the customer experience, rather than having to worry or manage the day to day, care and feeding of an environment. It doesn’t mean that you have removed all of your responsibilities.
So you always want to make sure that you understand this model and make sure that you know how to apply it in your particular scenario and before we get into the checklist itself this again another QR code you can use this will dump you over and you can grab a PDF Version of the high level points.
The first section of our checklist is talking a little bit about AWS Organizations. If you’re not familiar, AWS Organizations is a service that allows you to manage multiple AWS accounts and what I’ll say, streamline the management of those accounts.
We’re not going to go in and look at every single checkbox or item that we highlight as something that we feel is important for you to do in your AWS account. You can have a look at the checklist itself, but In each of these slides, what I would like to do is just highlight some of the most important features.
So when we think about AWS organizations, some things that you really need to know are benefits of turning this on. Even our smallest customers now generally have multiple AWS accounts.
Just some terminology, when you think about AWS Organizations, you have the management account and then you have member accounts. The management account is where you’ve turned on the organization service, you’ve opted into it and then any other account that is now part of that organization is considered a member.
Couple key features. Once you enable organizations, there’s two options. There’s the, oh I can’t remember the names of them now, but basically you get all of the features of AWS organizations, or you get only consolidated billing.
I think Amazon recently changed this, so when you turn this on now, by default you get the full implementation of Organizations. Just be careful when you’re turning it on, you can switch it later, but you might as well make this decision at the very beginning. Just double check, when you turn Organizations on, that you have enabled all features.
Consolidated Billing is great, but really the power of Organizations is when you enable all of those features. So let’s talk about just a couple important parts of organizations. When you’re thinking about setting up your environment according to best practice. Once you’ve enabled the service, you’ve gone down the all features path.
You will have something called OUs, organizational units. And this is a way that you can logically organize accounts within your organization. So an organization can have multiple AWS accounts, right? Dozens, hundreds, I think there is an upper limit, but I can’t remember what it is. But in most cases you’re going to be able to put everything you need in a single AWS organization.
And then what you can do is logically organize your member accounts into OUs. And the OUs are going to be important when we talk about another… feature here in a second, but as an example, you could have a finance OU with all your finance accounts under it. You could have a marketing OU. It’s up to you how you want to organize your accounts, but you want to think about this early on and come up with a standard, and then build out that OU structure as it makes sense for you.
The next feature I want to talk about with organizations is service control policies or SCPs. SCPs are policy documents. If you’re familiar with writing JSON policy documents in IAM, then SCPs are no different, they’ll look exactly the same.
What’s different though about SCPs is they don’t grant or deny permissions. What they do is they act as a filter of permissions. And you create these SCPs to either allow or deny activities within potentially all of the member accounts within your organization or a subset of those accounts, either individual AWS accounts or at the organization or OU level.
SCPs just provide us with this additional layer of permissions management within our AWS deployment and what’s really powerful about something like a service control policy is in an individual account deployment, you have different type of entities that can access those environments, right? And the most powerful entity that you have is the root account.
The root account is the email and password combination that you use to create that account. In a standalone or single AWS account deployment, the root account is uncontrollable. It can do whatever it wants. It’s not governed by the IAM policies you create within your AWS account. When you have organizations configured and you are using service control policies those SCPs also govern what the root user can do.
So it’s really powerful. Just remember, SCPs are created within the organization’s service. They don’t actually grant or deny permissions. They just act as filters.
And then the other really important part about AWS Organizations is, again, I’m assuming here you’ve enabled all features. You have what’s called trusted access and something called delegated administration. What is this? A lot of services now management via let’s say the AWS organization service.
So the first step in setting this up is what they call trusted access. What you’re doing here in a nutshell is you’re basically trusting that service across the entire organization. There’s a long list of services that support this.
As an example, let’s say a service we’re going to talk about later on is GuardDuty. You can enable trusted access for GuardDuty and then GuardDuty would be deployed in all of the accounts within your AWS organization.
Now the delegated administration piece is equally, maybe even more important versus just trusted access. Delegated administration allows you to delegate the admin of a service into a member account within your AWS environment. So let’s use the same example of GuardDuty. You enable trusted access for GuardDuty. And then you delegate the administration of the GuardDuty service to a member account. A lot of times when we’re building this out for customers, we might create a security account, and we delegate the administration of security related services like GuardDuty to the security account.
The reason that this is important, is first off in an organization’s deployment, I mentioned management accounts and member accounts. The thing that you want to do is you want to reduce, as best you can, the number of people or, workloads, applications that need to access the management account.
Ideally we restrict that only to the what I’ll call like the overall Administrators, maybe a couple finance people that need to grab billing information things like that so with delegated administration in my example, I can administrate or sorry delegate the administration of GuardDuty to our security account and then give our security administrators access to that security account and now they can manage guard duty for all of the accounts within our organization.
In a nutshell, AWS Organizations is a really important feature or service to enable when you’re managing multiple accounts.
And I would go even further and say, even if you don’t foresee a time where you need multiple AWS accounts. You just don’t think you’ll ever do it. Still set up a management account and then create one other account, you end up with two accounts. You use your management account to enable organizations and you start working that way.
Because what we’ve seen in our experience is over time, the number of accounts grow. Just based on more workloads and different things happening. And it’s not hard, but it’s just additional work. So if you plan ahead and set up that basic structure with a stand alone management account where you enable organizations and then create your single member account, you set up that foundation so that in the future, if you needed to make changes or add additional accounts, you don’t have to go back and try to retrofit stuff in.
So that’s organizations.
The next service that we want to highlight is Identity and Access Management. I started Curious Orbit, about 7 or 8 years ago now and we have always done account reviews or account audits. And we focus a lot of our time on Identity and Access Management. It’s probably one of the most challenging services to configure properly and it’s often overlooked during the setup process because in a lot of cases you know you got a lot of stuff to get done in a short time period so inevitably what happens in a lot of accounts we review is everybody is an administrator just to get the work done and as I mentioned on this slide really what you want to think about here is least privilege give everybody, you , the users who have access to your accounts, the compute workloads, the application workloads, you want to, as best you can, provide them with just enough access to your AWS account, least privilege, to perform the operations that need to perform and nothing else. Ultimately, what Identity and Access Management does is provide you with authentication and authorization services.
A couple important highlights from our guideline document. The first is, wherever possible, start with an IAM role first. If you’re not familiar, a role allows us to give somebody or something temporary access to our AWS account.
What we’re trying to do here is, wherever possible, avoid creating entities, IAM users, things that have permanent access to an AWS account. There’s more to manage, there’s more likelihood over the long term that maybe, there’s a security incident, a password is not great, or an access key doesn’t get rotated.
So your default stance here should be, outside of least privilege, start with a role first, give somebody or something temporary access, and then revert to permanent access only when you need it.
Another thing that we always like to highlight here too is federation. Wherever possible, federate users from some other location rather than having to create and maintain everything in two places, right?
You’ve got an existing directory service you’ve got IDs or identities created there but then you go ahead and you start creating duplicate identities in AWS. Now you’re having to manage those resources in two places. So instead, create a trust between your AWS account and some existing directory service.
Maybe you’ve got something on prem that you can use. Maybe you decide to go with the AWS Identity Center. Used to be the Simple Sign On Service, SSO. Alright, and instead now you create and maintain all of your entities in one location and then with that trust relationship. you can determine, what access they have which accounts they may have access to.
Start with Federation and always use a role first. And then, as we say on this slide here, at the very top always start with least privileged. Even if you’re in a bit of a time crunch, what you should be trying very hard to do is providing just enough access to do your job, whether that’s to a person, whether that’s to an application that you’re running, just provide them with enough access to do their job and no more.
It’s hard to do. It’s easy to say here, we spend a lot of time working with our customers, fine tuning IAM policies to give just enough access. And this is another example of something that you most likely will have to revisit multiple times because, a person’s access requirements may change. An application might be refactored or updated later on and it needs more access to something else or new access to a service that you weren’t using before.
So these are the types of things that you are going to have to continuously iterate on. And you also to flip that example on its head, yeah, you might have to add more permissions later on. The other thing though is evaluate the permissions that people are actually using.
Because you might give somebody permissions to, I don’t know, service A, B, and C. And a couple months down the road, what you notice is that person is using service A and B, but not C. So what you could do there is you could tighten up that permission statement and just give them access to what they actually need.
In my silly example, A and B. This is the toughest thing to do or one of the toughest things to do. So make sure that you set expectations at the very beginning and work with your teams and help educate them on why this is important. And the fact that, you need, you’re going to need some lead time to do this properly.
Monitoring and logging. This is another thing that we often see when we review accounts. It’s interesting to see how often we run into just a lack of log data in accounts. And I can see why this happens. AWS is giant, right? More than 200 services. It’s hard to know which services to use, how to configure them.
Like it’s tough to know all of this stuff with a platform as large as AWS and as dynamic, meaning it changes so often. So it’s easy to overlook things. A couple, by no means is this meant to be a complete list of all of the logging options you have, okay? But I’m giving you a couple examples of things that we often run into based on the typical types of infrastructures.
that we’re helping customers build for their solutions. The first one in one of my favorite services is CloudTrail. If you’re not familiar with CloudTrail, CloudTrail records all API actions, all API activities that are happening within your AWS account. And another way that I like to think about AWS and describe AWS is really, it’s just a collection of APIs, right?
200 services, each of them have their own APIs. CloudTrails are going to record. everything that happens within your account. CloudTrail is enabled by default in your account, but you need to finish the configuration of your CloudTrail implementation to retain that log data. Okay, so having the last, I think by default, it’s maybe seven days of log data.
Might be okay, but we’ll talk a little bit about security and compliance later on and recording all of this API activity and persisting that log data into something like s3 And or cloud watch logs can or most likely is going to be an important part of your security and compliance Configuration, okay.
It’s a fantastic troubleshooting tool. I use it all the time. So that’s a really important Source of log data to understand what’s happening in your account. Who’s taking actions or making actions within your account. Another service that kind of gets overlooked is AWS config. The way I think about AWS config is as a content management database, a CMDB for AWS.
When you enable config, it essentially discovers resources within your account. And then records changes to those resources during their lifespan. It’s important for a number of reasons. When you combine config with CloudTrail, we now have a really complete picture of what’s happening in our account.
Okay, because now I’ve got, essentially, CI records that say, I don’t know, here’s the EC2 instance that we discovered. And here are all the things that are happening to that EC2 instance. And when you look in, in config, it’ll actually show you. This was the API call when it happened, you can drill further down into that and it’ll point you over to CloudTrail where you get the complete JSON record of everything that’s happened.
So combining these two things together, CloudTrail and Config really give you a complete understanding of what’s happening within your account. So those are the two, I would say, default, most important monitoring and logging services that we would recommend you have on in every account within your environment.
A couple other important log sources that I just want to highlight, again, things that we often see people overlook. First off, we want to reduce as best we can resources that are directly accessible from the public internet. Okay, I don’t want to put my web server on the public internet and give it a public IP address.
Instead, what I want to do is I want to put it behind something. Okay, in this case, a simple example of what you might put that behind is a load balancer. Let’s say an application load balancer, an ALB. ALB have the ability to create logs. Okay. You have to finish that configuration though. So when you deploy an ALB, by default you’re not going to collect any of the log data.
So here’s an example of where you can push that log data off to an S3 bucket. Speaking of S3, you also have S3 access logs. Same idea as the ALB logs. Everything that accesses your objects within that S3 bucket will now be recorded in another S3 bucket. The one thing to point out about S3 access logs is you may, depending on what you’re doing, you may actually be better off configuring CloudTrail to record data, S3 data events.
It’s a more convenient way to consume that information. It’s up to you though. Okay. The one thing that I would say S3 access logging in general, you are going to increase your cost, I guess we could say you’re going to increase your cost with these log services and for all of them because you’re writing data somewhere else, right?
So you’re writing data to an S3 bucket for ALB logs, let’s say you’re writing data to another S3 bucket for access logs. So you’re going to, you’re going to consume storage there, which is going to increase your bill, but it’s from my opinion, a bit of a cost of doing business. The thing to keep in mind with CloudTrail is your first copy of what they call management events within CloudTrail is free of charge.
Data events are not. So you would want to sit down and just understand the pricing models here for all of this as well, so you don’t get a surprise at the end of the month where you’re spending more than you anticipated. Thinking again about public facing workloads, right? Caching is a great way to improve customer experience, right?
Why have that customer come all the way back to, let’s just stay with our simple example coming back to an EC2 instance that’s running our Apache web server to collect, I don’t know. An image of some sort. Instead, let’s put CloudFront in front of it, right? Because now we can cache that data and deliver it close to wherever that customer originates from, depending on our CloudFront Distribution configuration cloud front is another example of a service that has logging.
As an additional feature that you can turn on. If you’re building out those public facing workloads, CloudFront makes a lot of sense to put in front of those services, but make sure you enable the logging so you get that additional insight into what’s happening. And then finally, as I mentioned already, not meant to be a complete review of every logging opportunity AWS, but just staying on the theme of these public facing workloads.
A lot of times you’ve got, let’s say, CloudFront as your entry point, right? I’m trying to get to acme widgets.com and I hit a CloudFront distribution. Maybe what I do there is I I integrate an Amazon web application firewall, a WAF, with that CloudFront distribution. So now what we’re doing as those client requests come in, they’re hitting cloud CloudFront and we’re evaluating those prior to fulfilling those requests, and we’re evaluating ’em against one or more rules that we create inside of our a w s.
web application firewall, the WAF. Another example of logging. Okay, so these are just some simple examples. Make sure as you’re architecting, you’re building out your solution, you’re starting to identify the various services that you’re using. If you’re not familiar, go and have a look in the documentation and make sure that, you understand the logging opportunities that you have and then evaluate them against what makes sense for your particular requirements.
Just remember that it’s going to affect the bill, so you want to make sure you understand the pricing models.
Alright networking. Obviously something that you’re going to deal with, and a common theme that you’ll often hear about here is this concept of multiple layers of defense. What we’re talking about here is making a request have to go through, or, What’s an analogy I can use, many hurdles before getting to the destination.
The more hurdles that we make that request go through, the less likely that it could be bad traffic hitting. Again, I’ll continue to use our silly example of an EC2 instance, right? So we’re going to have multiple opportunities to filter that client request before it hits our application running on an EC2 instance.
That’s really what we’re talking about when we think about multiple layers of defense from a networking perspective. This QR code just points you to another checklist of ours that is focused on how to build out virtual private clouds, VPCs, and AWS according to best practice. This concept of multiple layers of defense, although we’re highlighting it as part of the network slide here, you can apply this to some of the earlier concepts or the earlier services we’ve talked about.
Same idea with IAM, right? You’ve got various levels of permissions that you can put in place. We talked about service control policies. That sort of at the top level act as a filter and then if you think about, okay, that request makes it through a service control policy and now it’s in the individual AWS account, we’ve got permissions policies there, we’ve got resource policies, maybe you even have permissions boundaries, so you can see how that API action or API call has to go through multiple layers of defense.
Same idea here with network. What you’re really doing here is by layering these creating multiple layers of defense, is you’re just reducing the likelihood of bad things happening within your environment. When we think about a network of multiple layers of defense, here’s a really simple example.
The first thing is, within your VPC, you’ve got route tables. Route tables are going to control traffic flowing in and flowing out of your environments. Not control it, but route it. If you’re trying to get here, this is the path, okay? Having individual route tables for every subnet within your VPC gives you fine grained control over how that traffic is routed.
That might act as your first line of defense, right? You put your databases in a separate subnet within your VPC and then you can control what those databases can see from a route perspective, right? You can also control who’s able to route traffic to them. So you’ve got lots of options there. Your next line of defense when we think about VPCs are Network Access Control Lists or NACLs.
These are stateless firewalls. They operate at the subnet level within your VPC, okay? They are optional, but this gives us another layer of defense. Going down a step deeper, we’ve got security groups. Security groups are stateful firewalls, and these operate at the elastic network interface layer. or level, ENIs, okay, and unlike NACLs, or Network Access Control Lists, these are required.
So everything that you deploy within a VPC gets assigned at least a single Elastic Network Interface and will have at least a single security group associated to it. So now you can see route tables, Network Access Control Lists, and then security groups. If you end up running EC2 based solutions, You have an operating system that you’re responsible for, right?
Think about the shared responsibility model again. Within that operating system, don’t forget or don’t overlook some host based tools, right? If it’s a Linux based solution, you’ve got IP tables that you could set up, okay? If it’s a Windows based solution, you’ve got Windows Firewall. And then you can install any other applications.
Maybe you’ve got some sort of, intrusion prevention solution, and you install those agents on those EC2 instances. So we’ve got multiple layers of defense. In our networking environments.
Again, a really important part of setting up and protecting your environments is encryption. You want to make sure that you protect your data while it’s in transit and while it’s at rest. A few years ago, during one of their keynotes, Werner Vogels mentioned something, and I’m paraphrasing here, but he said something along the lines of dance like nobody’s watching and encrypt like everyone is.
You should keep that in the back of your head. . Encryption really should just be your default stance. When you’re creating resources within your AWS account, encryption should be enabled by default. So if you’re creating EC2 instances, those EC2 instances are going to have .
Elastic Block Store volumes associated to them. Encrypt them from day one. One of the easiest things you can do in your environment is go to the EC2 console, have a look at your default settings. I always forget what it’s called, but it’s up in the top right hand corner of the EC2 console. If you’re in the web GUI, and you can go in there and you can enable default encryption.
It won’t change anything that you already have in your environment, but going forward, any new EBS volumes, if you don’t specifically say, I want you to encrypt it using this key, it will revert to the default encryption. Lots of other services work like that as well. The way that you protect your data in AWS at least while it’s at rest, is the key management service or k m s.
There are different types of keys that exist within KMS. There are AWS managed keys, and then there are customer managed keys. Our recommendation is to use customer managed keys, CMKs. Ultimately what it does is it just gives us more control. We can create our own, what they call key policies.
Who or what has the ability to manage that key, who or what can use that key to protect data at rest? It just gives you more control. You can enforce rotation of those keys, all good stuff. But your default here should be, when you’re building out your solutions, same idea, you’re building out that reference architecture.
Very similar to what we talked about when we discussed the logging approach. Is. Understand which services you’re going to use, and then make sure you understand your encryption options. There are additional costs for customer managed keys within KMS. Work out the pricing models there, and make sure it’s built in to your solution from day one.
Earlier on, I mentioned this idea of security and compliance and what we’re going to talk about here is just to make sure that you’ve got appropriate services in place to secure your solutions from day one until you retire them. Another QR code that you can look at here. This will dump you off to another checklist that we’ve created that can help you understand what’s possible and things maybe that, that it’s not something that you’re going to do a single time, as I mentioned earlier on in the presentation, you need to review and understand your environments on a continuous basis. What is good here is that AWS does have a number of services that can help us not only review our existing environments, but assess our overall security and compliance posture.
And then. ID or identify opportunities to make adjustments. So just again a couple services to keep in the back of your head when you’re thinking about this idea of security and compliance. A service that I mentioned already is GuardDuty. Guard duty essentially does continuous threat detection within your environment.
It looks for indications of either AWS compromise at the account level, the AWS account level, or a compromise with maybe resources, supported resources. that are in your AWS account, like an EC2 instance. To me this is if you saw our previous OrbitLIVE session, we talked about must have security services.
This is an example of what I would consider to be a must have security service. And this goes nicely with the organizations discussion that we had earlier on. You enable organizations, you… And enable trusted access for GuardDuty. Okay, that means any member accounts that you add to your organization’s deployment will have GuardDuty enabled.
Okay, and then we could delegate the administration of GuardDuty so we can limit who’s accessing the management account. We could delegate that administration off to a security account. Okay. Another really important service, we use it all the time, is the AWS Security Hub. If you’re not familiar with Security Hub, this is a compliance reporting service and it has a number of compliance standards that are built into the product.
A couple of them are enabled by default. There’s an AWS Security Foundations, there’s a CIS Benchmark. If I recall, both of those are enabled by default. There’s a PCI compliance. Add on or I guess you could call it an add on. That’s not enabled by default, but you can turn it on what security hub will do is start to Basically evaluate the supported resources within your AWS account where security hub is enabled Against one or more standards that you’ve enabled and then you’ll just get a report basically that says hey, you know what?
These s3 buckets are not compliant with check s3. 1 These EC2 instances are not compliant to EC2 check 12, something like that, right? They even give you remediation information so you can drill down through that and say, okay, how do I fix S3. 1? The thing to keep in mind with Security Hub is it leverages an important feature of a service that we’ve talked about already.
The AWS config service, what it does is it uses something we didn’t talk about in this presentation today, config rules. If you want to enable Security Hub, which I would… I strongly suggest that you do. You need to have config enabled first because if you turn on security hub without config, it doesn’t have the ability to create those config rules that I mentioned and a bit of it will work but not the entire product.
Security hub is another example of a service that is supported by AWS organizations and where you can basically streamline the deployment across multiple AWS accounts. The thing to keep in mind with both GuardDuty and Security Hub, these are regional services. You’re going to need to turn it on, potentially.
There’s two camps here. Amazon will say, turn on, let’s use Security Hub as our example. Turn on Security Hub in every region within your account. Okay. A lot of times, though, what we often see customers do is enable Security Hub in the regions that they are operating in, right? They’ve identified their primary region is, let’s say, CA Central 1, and their secondary region is US West 1.
They’re going to make sure that Security Hub, Guard Duty, Config are enabled in the regions that they’re operating in. And here’s another nice benefit of something like Service Control Policies, or SCPs, in organizations. We could create… Permissions filters that then deny access to other AWS regions. So you can say, hey, you’re only able to actually make API calls and what did I say?
CA Central 1 and US West 1. So you can see how you can combine these things together. But just remember, most of the services that we’re talking about today are regional. So you’re going to have to understand how to tackle that. Within your environment. And then another service to help you ensure the security and compliance of your deployment mentioned it in passing already is the AWS web application firewall, the WAF right?
This is going to protect our public facing workloads. It has integration with a number of AWS services. I gave you a couple simple examples today. Application load balancers, cloud front, but it also supports an API gateway, app sync, a couple other services as well. You want to make sure that if you’re running those public facing workloads, you inspect those client requests before passing them on, and the WAF is an easy way to do it.
What’s also great about the WAF is Amazon has a fantastic list of AWS managed rules. Some of them we pay for, some of them are free of charge. And you can deploy your WAF and then enable those rule sets to get you going. Immediately to protect yourself against the most commonly seen attacks out there.
And then we can augment that with our own custom managed rules for our particular environment. I’ve talked about a lot of things here. And if we flip back a couple slides and we talk, actually I’m on, I’m looking right at the slide. Security and Compliance. One other thing that I can just mention here in passing is, if you’re watching this, and you’re thinking to yourself Geez, like, how do I get all of this done?
There’s a lot of things that we’ve mentioned here that, might be out of your area of expertise. Maybe you’re on a short timeline. I don’t have a slide for this, but you might consider looking at Control Tower. Control Tower will help you get started according to AWS. It’ll actually… Set up your organizations, create some basic OUs, create a couple standard accounts, like a logging account, right?
We talked about logging earlier on. Where is it? Right here, right? I didn’t get into the details of this, but quite often what we would do is we would have a dedicated log account. So we’re going to keep copies of logs in our application account to help our devs, help our operations folks just understand what’s happening.
But we’re going to aggregate that log data into a central log account. Control Tower will do some of that setup for you. Okay, at least provisioning the accounts and setting up your OUs and stuff. So if you’re thinking about this from a multi account deployment, and you don’t want to build everything from scratch, Control Tower might be an option for something that you can look at.
And then finally, I just want to point out one other thing. We talked about how important it is to remember that this is not a one and done. You are going to have to evaluate this environment or your environment on an ongoing basis. One of the best ways that I know to help you evaluate your environments is the Well Architected Framework.
I should have put a little QR code to the Well Architected Framework documentation here. I’ll update this later, but you can just Google it and you’ll find it. The Well Architected Framework is a series of documents across what they call pillars. There are six pillars, so examples of pillars would be the security pillar, the reliability pillar, the cost pillar.
Within each of these pillars, what it is essentially is a series of questions. How are you securing your AWS account? How are you building XYZ to be highly available? It’s not going to directly tell you how to do this stuff, but it’s a series of questions that you can ask yourself to evaluate your current workload against those standards that are defined by AWS.
What’s great about the Well Architected Framework is it has a built in tool. It’s called the Well Architected Tool. It’s a free tool. You can go in, you can set it all up, okay, and then you can just go through and answer the questions. And it will give you a report at the end. And it will say, hey, you know what, we’ve identified these 10 high risk items, and you can then use that, the output of that report, to identify areas where you should maybe make some changes.
Opportunities for improvement, right? So you might start looking at those sort of high risk items, and figuring out how to remediate those. to improve your environment and what you can do is just over time keep going back to that same well architected review and evaluate that workload numerous times and just ensure that over time you’re improving the setup of that solution based on best practices that are defined by AWS.
So thanks very much folks. That is the presentation for today. I should have put the last slide. Should have duplicated this slide at the very end if you’d like to grab a copy of the full account checklist Where we go through this in more detail you choose scan this QR code It’ll allow you to dump or download a PDF file and you can use that as a learning Opportunity or maybe even a way to start evaluating What’s in your environment.
So thank you very much for watching. Enjoy the rest of your week and we’ll be back at the end of the month with another session. Bye for now.