I'm the only person at our small company with meaningful IT knowledge and AWS experience, and I'm currently responsible for managing our AWS environment. I'm studying for the Solutions Architect and CloudOps Engineer certifications, but I need to establish a secure foundation before that process is complete. We plan to have an experienced consultant review the environment before launch.
Because our SaaS product serves a security-sensitive industry, we need strong security, reliability, and separation of duties despite having only one person who currently needs AWS access. I'm looking for practical guidance on setting up an AWS organization, accounts, organizational units, IAM roles, permissions, and service control policies without overengineering the environment.
Specifically:
1. What guides, templates, tools, or security and compliance checks would you recommend for designing permissions and SCPs for a small but security-conscious company?
2. Which accounts and OUs are truly useful at this stage? I'm considering separate security and logging accounts, along with sandbox and production OUs containing one account per product. Should I also create accounts for shared services, networking, or other functions?
3. Is Control Tower a reasonable choice for this situation, or is it too restrictive, complicated to remove, or likely to enable unnecessary paid services? Are there simpler alternatives?
4. I've already written Terraform/OpenTofu code for remote state and initial resources. Should I use it to manage the organization, accounts, SCPs, and roles too, or is the initial organization setup better handled manually?
I'm especially interested in advice that balances strong security and availability with the reality of a very small team.
4 Answers
Look at AWS Organizations best practices, the Well-Architected Framework, and the AWS security baseline guidance before deciding on specific SCPs. Start with preventative guardrails such as blocking unsupported regions, preventing changes to centralized logging, requiring approved security settings, and protecting the organization’s root and security resources. Use IAM roles and federated access instead of permanent access keys, require MFA, centralize audit logs, and enable detective controls so mistakes are visible. Test every SCP in a nonproduction account because an overly broad deny can lock out administrators or break essential services.
Control Tower can provide useful landing-zone guardrails and account provisioning, but it is opinionated and adds operational complexity. It is not automatically the best choice for a small environment. Compare it with a simpler Organizations setup or an established infrastructure-as-code framework, and confirm what services and costs each option introduces. Any framework should be tested in a disposable organization first; some foundational changes are difficult to unwind cleanly.
Managing the organization and its accounts with Terraform or OpenTofu is reasonable and gives you repeatability, reviewable changes, and recovery documentation. Keep the bootstrap process carefully separated from workload infrastructure, protect the state, and avoid creating a circular dependency where the organization account needs resources that can only be created after the organization exists. A small amount of initial click-based setup may be unavoidable for the root account, billing, or identity bootstrap, but record it and move as much as practical into version-controlled code. Have someone experienced review both the code and the operating procedures before production launch.
The security and availability requirements are the most important part of this question. A single person who is still learning IAM and AWS architecture is a significant operational risk, so leadership should understand that this cannot safely be treated as a routine setup task. Use the AWS Well-Architected Framework as a starting point, and involve an experienced AWS consultant or partner early rather than waiting until the end. You also need a plan for emergencies, backups, monitoring, credential recovery, and what happens when the sole administrator is unavailable.
A multi-account organization is a sensible foundation, but keep the initial design focused. A common starting point is a management account used only for billing, identity federation, and organization policies; a dedicated logging or audit account for centralized CloudTrail and other security logs; a security account for delegated services such as GuardDuty and Security Hub; and, where needed, separate networking or shared-services accounts for DNS, connectivity, and common infrastructure. Add workload accounts for sandbox and production after those foundations are working. The exact account list should follow your compliance and operational needs rather than copying a reference architecture blindly.
That makes sense. My main concern is avoiding a design that is too large to operate while still keeping production isolated and recoverable.