118. The landing zone: Managing multiple AWS accounts
In this episode, we provide an introductory overview of AWS's best practices for managing infrastructure using multiple accounts under an organization. We discuss the advantages of this approach and how to get started creating your own multi-account environment, or "landing zone".
AWS Bites is brought to you by fourTheorem, an AWS Partner that does CLOUD stuff well, including helping you set up your AWS organisation! If that’s something you are looking for, go to fourtheorem.com to read more about us and to get in touch!
In this episode, we mentioned the following resources.
- AWS Definition of Landing Zone
- Series of articles "Managing AWS accounts like a PRO"
- AWS Organizations service (docs)
- IAM Identity Center service (docs)
- Control Tower (docs)
- org-formation
- Our previous episode "AWS Governance and landing zone with Control Tower, OrgFormation and Terraform"
- granted.dev
- AWS SSO util
- Leapp
- Cloud Glance
Today, we're diving into a fundamental practice for managing your AWS infrastructure using multiple accounts. Whether you're a seasoned cloud expert or you're just dipping your toes into AWS waters, this best practice can really make a difference to the way you handle your business applications and your data. And if you've ever explored the AWS Well-Architected Framework, you might have come across mentions of the benefits of multiple accounts from enhancing operational excellence to bolstering security and cost optimization.
At fourTheorem, with our work, we've seen firsthand how using this approach can really make a huge difference in organizations' cloud strategies, regardless of your cloud maturity level. But how do you actually implement this strategy without getting overwhelmed? Well, that's where we come in. And in this episode, we're hoping to give you an introduction on everything you need to know when it comes to managing AWS organizations and accounts.
And we'll also share a number of AWS services and tools that you can use to make your own life easy and do all of this management using infrastructure as code. Welcome to another episode of AWS Bites with myself, Eoin and Luciano. AWS Bites is brought to you by fourTheorem, an AWS partner that does lots of cloud stuff really well, including helping you to set up your AWS organization. If that's something you're looking for, go to fourtheorem.com to read more about us and to get in touch.
Using multiple accounts under an organization, no matter what size you are, it's often referred to as a landing zone. AWS uses this term landing zone quite a lot, and they've got a definition which says that landing zone is a well-architected multi-account AWS environment that's a starting point from which you can deploy workloads and applications. And it provides you with a baseline to get started with multi-account architecture, including identity and access management, governance, data security, network design, and logging. There's a link to that full verbatim description in the show notes. But what are the advantages of having multiple AWS accounts?
There are several advantages. The first one that I would like to start with is isolation. And I mean isolation of resources because every single AWS account operates independently and it provides effectively a boundary for resources. So this kind of isolation allows you to get better security compliance and also the way you access these resources, you have effectively more controls around who is allowed to do that and what kind of access level they have.
Different teams in fact can have their own accounts. For instance, if you organize your teams by business domains, you could create accounts in AWS that represent those business domains and that reduce the risk of interference. For instance, different teams might not be worried about, for instance, exhausting each other quotas. Maybe, I don't know, the usual example that we make is the number of Lambdas that they can run at a given point in time.
Different teams will have their own quota to manage and they're not going to be conflicting with each other, which is a great thing to have when you're thinking about running lots of workloads at scale. And that is also important in terms of security standards and it can make easy to comply with regulations such as GDPR, HIPAA, or PCI and things like that. Because since you have more isolation, it's easier to prove that you are basically not leaking data and you are complying with all the standards that this kind of regulation will impose on you.
Another similar aspect is what we generally call environment segregation. This is more on the idea that even within the same domain, you might still want to provision multiple accounts because you want to use different accounts for different environments. For instance, if you have, let's say, the usual e-commerce example, you might have a domain that is called, I don't know, maybe fulfillment. In that domain, you deploy specific workloads.
You might want to use different accounts, one for instance, for development, one for testing, one for production. And this is really useful because you are effectively minimizing the risk of disruption to those systems while you are experimenting, for instance, because you want to build a new feature or maybe you want to try maybe a different database. You can do all these things in environments that are dedicated to testing and building before you actually move all this stuff into production where you might create disruption if you didn't have a chance to test things properly.
And this approach also allows you to separate testing data or development data from the actual production data, which is another great thing, for instance, when you have applications that are managing customer sensitive data. In that case, you probably don't want to give access to that production data with customer sensitive data to the other environments where you are effectively just testing and lots of developers are going to need to access that data to create all sorts of different test cases.
Another advantage is short-lived developer credentials. This comes because when you have multiple accounts and you are using IAM identity center and AWS organizations, effectively you have to pick a specific account and a specific role to work with every time you need to do something programmatically. And this is very convenient because you can prepare specific roles for specific accounts. For instance, you might have a role that only allows you to read logs from S3 and it's a read only type of role.
And you are going to assume that specific role when you need to read S3 logs. And that's basically limiting the plus radius. If accidentally you do something else, maybe because you are writing a script and try to automate something, you are not going to risk that maybe you can delete files or maybe you can access a database that you're not allowed to access to. And of course, you can take that example and use it for other use cases.
Maybe I don't know, not just logs, but you can think about managing budget. You can think about accessing databases. You can think about security roles where you can go and check maybe, I don't know, guard duty or other things like that. So all of this stuff is very powerful. And when it comes to programmatic credentials, you basically don't use anymore the long-lived credentials because you can use tools that will give you temporary credentials only to access the specific role that you need to access to for one hour, two hours, four hours, or something like that.
It's not going to be long lasting credentials that are going to live in your machines and might be easy to steal and abuse for other things in the future. And finally, another point is cost management because by separating resources into different accounts, you have a natural bucket, which is that account in terms of collecting and aggregating all the costs for the meaningful purpose of that specific account.
So of course you can use tags, but you know that with tags you need to be very diligent. And if you want to aggregate cost by tag, you might be forgetting about tagging certain resources or you might be using different tags and they don't necessarily match all the time. From the account perspective, it's much easier to just say, give me all the cost in this account. And you can also easily set up budgets and alarms to say, for this particular account, maybe it's a development account.
I don't expect to be spending more than $200 a month maybe. And if you go higher than that, just send me an alarm. So you can easily create these kind of utilities that will tell you whether you are spending more than you are supposed to be spending on a specific account. So I guess the final point is that doing this structure, creating effectively a landing zone with all sorts of different accounts can be a little bit challenging.
And hopefully after this episode, it's going to feel a little bit less scary, but there are lots of benefits that are really, really important. So I will say that don't be scared, just get on board with it. And the sooner you do all of this, the better it's going to be. And I guess that leads me to another question, because maybe you are not a big company with thousands of employees. You don't necessarily need hundreds of accounts. You don't have multiple workloads. Maybe you are just a solo developer. Maybe you are a student. Maybe you are just learning about AWS. Is it worth for you to go through all this journey and learn all these different things? Or you can just be better off with long-lived credentials, one account, and just keep to doing things in the standard way, so to speak.
This is probably a matter of opinion, but I think we believe that everyone using AWS should invest a little bit of time learning how to set up the organization and effectively managing multiple accounts. And one of the main messages I'd say is that it's not that complicated. It doesn't take a huge amount of time to do it. And it is worth the investment because everybody is generally moving towards multiple accounts anyway.
So if you're not exploring a little bit how that all works, then you might be left behind a little bit and you might start getting a little bit of FOMO. So why would you do it if you're a solo developer or just experimenting in AWS? Why would you bother setting up accounts? Well, you're going to learn, right? So I'd say for learning purposes, even if you're hosting some side projects, there's lots of benefits for you.
We already mentioned some of the benefits you went through with Luciana. And they're even valid when you're running small workloads on AWS. And it helps you just to be a bit more organized when you're deploying lots of different hobby projects or your own blog or whatever it is to AWS. But if at some point you decide to invest a little bit more on AWS and maybe you're doing freelancing or you're working for a company doing a lot on AWS, having your own multi-account environment is definitely going to help you there.
So maybe if one of your side projects starts to pick up and you decide to turn it into a commercial project, it could be the start of a new SaaS service. If you've put a little bit of manners around your landing zone to begin with, then that's certainly going to help you. Or if you want someone to give you a help at some point, you need to hire somebody else to work on the code with you or get some more contributions.
Then it's easier to give them access to your organization if you've got a little bit of segregation between all of the stuff you've deployed in there. Maybe eventually you want to grow your efforts into a proper company and you have multiple teams and multiple departments and they want to interact with an AWS organization. Or maybe eventually you'll sell the whole lot for billions and you'll be a startup unicorn.
I don't know if you care, but if you were to do that and if you were to retire and go and live on a Caribbean island, you might want to know that what you've left behind is somewhat well organized for the people who have to keep maintaining it. So I suppose the point here is that investing in setting up the landing zone, it's just like creating a great foundation. And it doesn't matter if you want to start small. It really doesn't take very long. You can turn on organizations and start creating new accounts very quickly and then start adding some of the more advanced governance and compliance type stuff later on. And it really just helps you to grow your AWS presence and get off to a good start. And you get all those benefits like temporary credentials and sign on with your Google account or whatever identity provider you want to use, even the built-in one.
Yeah. It's worth reminding that an account at the end of the day is just a container for resources within AWS. And another interesting detail that I think you will start to realize very quickly when you create your second account is that every single account is uniquely tied to an email address. So you might need to start thinking also how to get aliases for all the different accounts so that you are effectively managing all of them under one email.
Otherwise, it might get a little bit messy. So that's another concern. And if you use things like Gmail, it's easy to generate aliases. You can use, for instance, the plus syntax to just say, I don't know, Luciano plus production at gmail.com, something like that. So this is just a practical tip, something you will start to face very quickly when you create multiple accounts. But the other question you might have is, okay, but how many accounts do I need to create?
And what is a way to organize them that kind of makes sense? Because initially you might just be lost in trying to think, okay, right now I've been using one account for everything. Maybe I can see a future where I might need a second account for another workload, but is there any best practice on how to organize accounts in a more scalable way that allows me to grow even 10 years down the line? You have a structure that can fulfill what you need to do.
And really there isn't one way to do that. AWS gives you a bunch of different tools so that you can actually put a structure in place. And I think it's worth mentioning a little bit more what is the naming that AWS gives you to the different entities that you can use to organize effectively your organization accounts. So generally there is a root entity, which is kind of a high level container for your accounts.
And initially when you open your first account, you effectively have this root and only your own first account, which is generally referred to as the management account, because it's the one that will allow you to control all the other accounts. And then you can create additional accounts directly in the root level. So they will all be affected at the same level of depth. Imagine maybe a file system can help you out.
It's like you have only one folder and then you have a bunch of files into that folder. But you can also decide to create sub levels. And the tool that AWS gives you is called organizational unit or OU. And the idea is that effectively that's a group that you can create and inside the group you can create additional accounts and you can even nest additional organizational units. So again, in the analogy of file system, it's like you can nest multiple folders and eventually you will have files into this kind of structure, hierarchical structure.
So at this point, you know that you can organize all your accounts under groups and create this kind of logical hierarchy where somehow you try to divide things in a way that makes sense. But what kind of groups would you want to create? And again, this is totally up to you, but there are some sensible common practices. For instance, it's very common to go with a security OU and this is going to be a group that contains all the accounts where you might want to deploy security related services, for instance, GuardDuty.
Then very common, you would have a sandbox OU and this is where you do all your experiments. Maybe if you want to try a new service, deploy like something random quickly just to have a feeling for what that new service looks like, you will have accounts like for doing workshops or to just do experimentation. And you might even use automation there to just delete every single resource in those accounts, maybe every weekend or at the end of the day, just because these are very disposable accounts where you just do stuff for trying things around.
You don't want to for things you deploy there to stick longer. Then generally you would have some kind of workloads, organizational unit. And this is probably one of the most important ones or the ones that you will be using the most because this is where you deploy your workloads. And you might want to organize accounts there by environment as we suggested before. So for instance, you might even have multiple levels.
For instance, inside workloads, you might have another set of OUs to divide your different business domains. And then inside every OU for the business domain, you might have multiple accounts for development, testing, pre-production, production, QA, whatever makes sense to you in terms of environments. And then you might have other utility OUs or account. For instance, I've seen commonly organization will want to have a place where they can test different policies that maybe they want to put in place.
So it could be common to have either an account called policy testing account, or maybe an organization unit where you might deploy multiple accounts. Or you might also have a suspended OU where you might move things that you want to delete or that you are suspending for whatever reason makes sense in your organization. And this is generally useful because when you want to delete an account, you cannot delete it straight away. There is a period of time where the account is going to stay there pending deletion. So it might make sense just to move it somewhere else where you can easily control access and make sure that people are not going to go there and create new resources as you are in that process of deletion. So now that I think you should have a little bit of a better idea of what are the capabilities and what are some common ways of organizing the accounts, where can we get started? What is the next thing that people should be doing?
Well thankfully, we have your excellent step-by-step guide you wrote on the fourTheorem blog Luciano that shows you exactly how to set up IAM identity center and AWS organizations and use those to create your perfectly crafted landing zone. So we don't have to repeat all of those steps here, but we'll link the article in the show notes for you. What might be more interesting is just to give you a quick overview on the different parts of it.
So the different services we used in that article and explain why they exist. Now we've already talked about AWS organizations. That's your account management service that really enables you to consolidate multiple AWS accounts together. And it gives you that account management, consolidated billing, which is very important if you want to avoid getting hundreds of invoices from AWS every month. And as an administrator of an organization, you can create accounts in it, invite other accounts into the organization, and you can also do various things with other services that give you budgetary security and compliance needs as well.
So other services are becoming more and more integrated into AWS organizations as we push more towards this model of doing things. And the next really important one and very interesting one, if you're just setting it up for your own personal account is IAM Identity Center. It's pretty much distinct from IAM and it used to be just called AWS Single Sign-On. So we're just still getting used to the new name.
And this is for really managing human user access to AWS resources. And it's a place where you can assign users, create users, link users to an external identity provider and manage the level of access. So you can configure an IDP, which will allow you to log on with one of your existing login providers to an AWS organization. And then you can link your users to the roles and the permissions they will get with individual AWS accounts or groups of AWS accounts.
Now the article we mentioned shows in a lot of detail what all the steps are that you can follow to go from zero to a fully functional landing zone with multiple accounts and user roles. We'd really recommend trying that out. And if you don't have an external identity provider for your own personal account, you can use the built-in one, which is nice. You don't have to use Google Workspaces or Azure AD.
There's a built-in one which allows you to get up and running pretty quickly. And then you've got nice enterprise level temporary credentials and all of that good stuff. Now moving on to Control Tower, it is available in the management console. And the idea of it is that it gives you a way to set up and govern that landing zone. It's AWS's solution to creating a landing zone really. It is the easiest way from an AWS native perspective to get up and running.
We talked about the pros and cons of this versus alternatives in one of our previous podcasts which we'll be talking about again and link in the show notes. But it's really a Control Tower is a higher level AWS service that allows you to set up that landing zone and then provision more accounts and provision resources in those accounts. Control Tower is generally used as a AWS management console feature. It's good to get familiar with the concepts. Those of us who like infrastructure as code don't necessarily think it's the best solution for long-term management and we prefer to use infrastructure as code, utils. Control Tower does integrate with some infrastructure as code tools, but it's really management console first. So Luciano, what options do we have around infrastructure as code?
Yes. The main tool that we use most of the time and we are seeing most of the community referring to is called OrgFormation. And this is an open source tool developed by the community. So it's not an official AWS tool service or solution. It's an open source project maintained by the community. And it's a really interesting project because it allows you to effectively fill some of the missing features of CloudFormation.
Because if you would want to use CloudFormation to manage all these things with infrastructure as code, you very quickly will bump into the problem that when you deploy a stack with CloudFormation is effectively tied to one specific account. So you will need to write all your orchestration to switch between accounts, use different credentials just to try to deploy different resources. So OrgFormation tries to backfill for that kind of missing feature and it does a lot more.
There is actually on the repository a very interesting PDF file that you can download with 50 different examples showcasing the capabilities of OrgFormation. So definitely recommended to look at that just to have a feel for what else can it do more on top of CloudFormation. But at the end of the day, still using CloudFormation behind the scenes to deploy resources for you on the different accounts.
So the idea is that once you set up OrgFormation, you can apply changes automatically and reduce manual work and inconsistency and mistakes. So you're not going to go to your management account, log in in the web console, and then start to click around to change things. But rather you'll be maintaining YAML files that describe everything that represents the current state of your landing zone, all your accounts and permissions, resources, policies, everything that you want to manage in a more centralized way with Infrastructure as Com.
And just to give you some example, what you could do, for instance, is just in your YAML, and by the way, you have a command at the very beginning that allows you to import the shape of your organization unit and accounts. So the first command that you generally would run is that one, and then you have a good starting point. You don't have to rewrite everything from scratch the first time that you decide to use OrgFormation.
But once you have that YAML file, maybe you would want to create a new organization unit and a new account under it. That generally means changing a few lines of YAML, adding maybe a few extra things in there, and then you can just apply that template and it's going to deploy everything for you, making sure to apply the diff correctly and deploy only the changes that you actually have applied to your template.
And you can also create things like SCPs. By the way, we have another episode dedicated to those if you're curious to learn more about SCPs, so we'll add the link to that episode as well. You can also create arbitrary resources and provision them under various accounts. Maybe you would want to have an event bridge in every single account because you might want to use that to communicate across accounts.
You can easily do something like that with OrgFormation. And another cool thing, and that is actually a very good example in OrgFormation, in the set of example provided by OrgFormation itself, is that you can add tags to every single account. And for instance, one thing that you can do with that is use a specific tag that represents what is the budget threshold for that specific account. And then you can easily provision alarms that will notify you if you are going over that threshold in specific accounts.
So it makes it also very easy to control costs and you can just follow the example and provision that kind of stuff very, very quickly. Now is this the only tool? Of course not. There are other tools that you can use. In our previous episode that you mentioned, or in episode 96, we made a little bit of a comparison between OrgFormation, Terraform and Control Tower. So Terraform is another contender and it is generally a really good one because it gives you a really good diff, for instance, of what is going to change before you apply the changes, which is definitely something you want to do, especially for bigger organizations.
But the one problem that Terraform has is that it might be a little bit tricky to write very abstract code just because the way that Terraform manages different accounts is by configuring different AWS providers. And when you provision a resource, you always need to prefix that resource with the provider name. It's not something that you can easily generalize. So it might be a little bit difficult sometimes to create very reusable modules that you might provision into different accounts and you might end up doing a little bit of copy paste.
Now maybe there is a solution for that, but I'm not entirely aware of that kind of solution. Maybe something that Terraform can make it easier in future releases. But as it stands today, that's one of the complexities that people bump into. Still, it's a good tool if you're used to use Terraform. Probably it's not the end of the world to do a little bit of copy paste because most likely you're not going to change the structure of your organization every single day.
But just be aware that there are trade offs there. Now I guess if you want to know a little bit more about all these details and differences, again, we will put a link in the show notes to our previous episode because that one has a little bit more depth when it comes to describing the different tools and what are the different strengths and weaknesses. Now I think one last thing that we might want to cover is a little bit more detail on programmatic access. You mentioned that it is something that you will get some advantages in the way you can manage programmatic access, but should we share in practice maybe some of the tools that can help with all of that?
Yeah, if you're moving to managing multiple accounts, then the first question is how do I manage multiple credentials? How do I know which account I'm using when I set up credentials? What happens if you've got multiple AWS organizations and then you're managing multiple AWS accounts in multiple organizations? It can become a bit of a minefield. So there are plenty of tools, luckily, now that make it easier to manage all of that stuff.
So let's say, for example, you just want to play around and deploy something in a sandbox account. How do you get programmatic credentials with a CLI for that specific account? There's a few tools that can be used and a lot of these tools, as well as offering programmatic access, will allow you to launch into the AWS console with the right credentials for the account you want to use as well. And one of our favorites is granted.dev.
Luciano's article we mentioned at the beginning, we show how to set that up. So that's all covered there and that's a really nice one. There's other alternatives like AWS SSO util by Ben Kehoe, which we've used quite a lot in the past. There's another couple which I haven't used personally, but look pretty good. One is Leapp by Noovalari (and that's Leapp with two Ps.) Again, there'll be a link in the show notes and Cloud Glance.
And Leapp and Cloud Glance will also offer you a visual UI. So there might be great alternatives if you're looking for more of a visual approach rather than a terminal approach to managing the craziness of multiple AWS accounts in multiple organizations. If you want to check any of those out, the links will be in the show notes and you won't regret it. If you haven't used any of those tools, I don't think you'll regret adopting them.
I think at this point we can just summarize and wrap up. I think today we highlighted really what the importance of setting up landing a zone and using multiple accounts in the first place for different business applications and data. It's something you should be doing regardless of the size of your team or the level of cloud maturity. We also mentioned the advantages, isolation, environment segregation, short-lived credentials, cost management and security. We also give you a few examples of how an organization structure could look and which tools and AWS services you can use to create them. Then we finally talked about some of the tools you can use to simplify short-lived programmatic credentials and access to the console. Did we miss anything important? Do you have any additional cool setup in your landing zone or have any additional tips to share? Or if you haven't even done it yet, what's holding you back? Let us know in the comments below and reach out to us on our social channels because we'd love to know what you think. Until the next time, goodbye.
Use the arrow keys to move between transcript segments, Home or End to jump to the first or last segment, and Enter to seek in the video.
Help us to make this transcription better! If you find an error, please submit a PR with your corrections.