What is AWS Organizations for?
Imagine you open an AWS account. You use it for everything, testing and production. As you may know, AWS has limits / service quotas imposed on each account. Some (known as soft limits) can be changed, but might take time, some change automatically behind the scenes, and some are fixed, permanent, static, and rather low. So you're humming along, and I am going to use a contrived example here, but imagine you use Route 53 Resolver as a key part of your infrastructure, and attach one or two query log configurations for each application you have, and you operate entirely in us-east-2. One day, you deploy a new application to production but, it fails. Why? Because you can only have 20 query log configurations per region in the service. Hard limit. What do you do? Spin up a new account, right? But you might say "isn't that problem just going to happen later then in your example?" And you'd be right, you'll need more production accounts eventually anyway. This is, in fact, a great reason to use Organizations.
Let's try another example. You are just starting out. You grant permissions rather liberally, and some roles have ec2:* with no conditions or resource filters. One day, one of your finops engineers writes a script to terminate low utilization EC2 instances in the testing environment, those with 10% or under utilization. But a typo makes it's way into the script! Someone meant to write " == 'testing' " in the code but wrote " != 'testing' " instead. And now it ran against your production environment just as you were done spinning up 1000 instances for a big promotion that your marketing team just sent 1 million emails about. Suddenly every instance disappears. A bad day.
What is AWS Organizations?
At the core, Organizations is a way to create lines in the sand between logical business units in your company. It also allows you to separate concerns and reduce the blast radius in the case of things like unauthorized access, or malicious employees, or prying eyes. When you create an organization in an account, that account is now the head of an organization of 1 account. You can easily create more accounts and add them to your organization, or invite accounts that already exist to your organization. You can create a logical hierarchy to group these accounts into organization units, so all the engineering accounts are in the engineering OU, all the finance and accounting accounts are in the finance OU, and so on. You can enable organizational billing, which centralizes the cost management into the head of the organization (sometimes called the payer account) and now individual accounts do not have to worry about credit cards and invoices, simplifying the process of paying your AWS bill. You can enable Service Control Policies (SCPs) which govern every entity (including the root user) in the child accounts (note: nothing can stop the root user in the payer account, no SCPs can ever apply to them). You can also enable CloudFormation StackSets, which allows you to deploy infrastructure using CloudFormation templates to any account in your organization.
Practical Application
So what? The TL;DR is that you should immediately create an organization in some AWS account if you do not already have one. If you already have an account, I actually recommend opening another account and making THAT one the payer account, and inviting your existing account into the organization. This is because you want the payer account to do as LITTLE as possible. Minimal infrastructure is the right amount of infrastructure, no compute, no databases, no mission critical resources. Buckets and Marketplace agreements and subscriptions are ideally here, but little else.
Immediately create another account to house all the security concerns. You can delegate things like CloudTrail, GuardDuty, Config Recorders, and Security Hub to home in that security account but cover the entire organization. You can have buckets in that account where you ship all your security-focused logs. Give very few people anything more than read access in this account, and you've got a secure place should the need ever arise. There is far more to discuss here, and you can see a good reference architecture maintained by AWS here.