Organizations allow you to manage multiple AWS accounts, with one manager account, and several member accounts. Each member account can only exist within one organizations. The benefit of using an organization is you have the ability to get discounts on resources shared by the account like EC2 or S3. You are also able to utilize reserved instances or savings plans across multiple accounts, so if one account doesn’t utilize them another one can. An organization can simplify payment by consolidating it to one payment method under the manager account.
Your organization is made up of a root organization unit (OU) that is where the manager account will sit and multiple sub OUs which can have accounts underneath them. For example you may have a project OU with accounts for test, dev, production. You can have multiple OUs under your ROU and each of those OUs can have their own set of accounts. The benefits to using multiple accounts is namely security, there is a higher degree of separation between completely different account then attempting to have all services communicate through one AWS account. I should note, you can put OUs into other OUs as well the account will inherit all permissions for ALL the OUs they are under, deny will always beat allow in terms of permissions.
You have the ability to use CloudTrail and CloudWatch logs to send all data to your centralized management account instead of manually reviewing this information individually across each account. As an additional security benefit you can utilize Service Control Policies (SCP), this will define what OUs and separate accounts can do in your organization, what access they have, what actions they can perform, etc. SCP does not apply to the manager / root account, that will have full access. An explicit allow is needed in SCP for each resource. There are really two major approaches to take. You could have a blocklist that defines all resources as allowed and will specify certain resources that will be denied such as IAM or EC2. Or, you can have an allow list that only defines the resources that are allowed since all resources are blocked by default, from which you set certain actions that are allowed such as CloudTrail and S3. For better security I would recommend utilizes an allow list and only specifying the resources that are needed.
As a final example, you have account A which is under OU 3 and that has a policy which allows S3 access. OU3 is under OU2 which has a policy that denies S3 access. OU2 is under OU 1 which allows all resources. OU1 > OU2 > OU3 > Account A would be the structure, you can have multiple accounts in each OU as well. So account A would inherit all access from OU1, Deny S3 from OU2, and allow S3 from OU3. Account A would have access to everything, except S3 as the deny will take precedence no matter what layer it’s at, even if there’s an explicit allow as we can see on OU3. If the account is within the hierarchy then the deny will apply.