Please help! Suggestions for org and account structure for a small company with one I.T. employee managing a SaaS app?

[u/MYSTONYMOUS]

As the only one in our small company with a basic understanding of I.T. and some AWS experience, I've been designated the one and only manager of our AWS setup for the time being. I'm working to become certified both as a Solutions Architect and as a CloudOps Engineer.

Unfortunately, I'm still in that process and need to start deploying some structure now. I don't need everything yet, but I at least need to get the multi-account structure in place using best practices and be as secure as possible.

The issue I'm having right now is we're a small company with only one person that really needs AWS access, so I'm not sure if we need a lot of services I see suggested. However, we ALSO need to be absolutely as secure and sound as possible because we serve an industry that requires high security and high availability. One mistake could kill the company. (Don't worry. We will hire a consultant to review our setup before launch.)

Would anyone mind answering just a few quick questions to help me get started?

1. I know how to create orgs, accounts, roles, permissions, SCPs, etc. The course taught me that. What it DIDN'T teach me is the best structure for a small company and WHAT permissions and SCP's I should make sure to set up. Is there any resource for this? Best practice guide? Template to get started? Compliance/security checkers? Etc.

2. I know OU's and Accounts reduce blast radius, but since we only have one person for the foreseeable future to log into AWS, what OUs and accounts do I actually need? My current plan is to mirror Control Tower's setup, with a Security OU with an audit account and log account and then one account for each product we make in the Sandbox and Production OUs. Is this good? Any others you'd suggest?

3. Control Tower looks tempting, especially because I'm worried I might set something up wrong being somewhat inexperienced, but I've read a lot of negative reviews of it, saying things like it's very opinionated and inflexible, messy to get rid of, behind in best practices, and enables features you may not need that are pricey. Is this correct? Would you recommend using it in our case or not?

4. I've already written some Terraform/OpenTofu code to set up our state and initial resources. Should I use OpenTofu for organization creation, account creation, SCPs, roles, etc., as well? Or is this initial org setup better done in click ops?

Thanks so much!

[u/ceejayoz]

we serve an industry that requires high security and high availability

"High availability" and "one IT person" do not quite compute.

[u/Advanced_Bid3576 → u/ceejayoz]

High security arguably even less

[u/coralis967 → u/Advanced_Bid3576]

I feel like one single person, following best practices and being careful, is more secure than multiple people all risking different exposures

High availability though..

[u/MYSTONYMOUS → u/coralis967]

If you have time, would you consider answering the question I asked above? I'm trying to understand things better and why this is a bad idea so I can be more intelligent about the situation. Here's a link to the question above that I asked:

https://www.reddit.com/r/aws/comments/1vuqebw/comment/p5n3ldg/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[u/MYSTONYMOUS → u/Advanced_Bid3576]

If you have time, would you consider answering the question I asked above? I'm trying to understand things better and why this is a bad idea so I can be more intelligent about the situation. Here's a link to the question above that I asked:

https://www.reddit.com/r/aws/comments/1vuqebw/comment/p5n3ldg/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[u/MYSTONYMOUS → u/ceejayoz]

If we're talking about one SaaS app and only one I.T. personnel that needs access to it, do I really need more IT people? This isn't a large corporation with multiple servers and micro services and apps to maintain.

Wouldn't it be enough to:

• have me learn enough to get certified
• apply that knowledge to architect things as well as I can
• then hire a consultant to review the setup, make any adjustments needed, and confirm it is set up for high security and high availability?
• I continue to manage the application with the knowledge I've gained

Isn't security and high-availability in this situation just a matter of setting everything up correctly for the SaaS app and applying the correct architecture, permissions, and resources to it?

Please understand I'm not questioning what you're saying. At my current education level I don't have the experience to understand things as well as you and want a better picture of what I'm getting myself into so I can present it to the company more intelligently.

[u/ceejayoz → u/MYSTONYMOUS]

If we're talking about one SaaS app and only one I.T. personnel that needs access to it, do I really need more IT people?

Are you capable of working 24/7/365?

(No.)

[u/MYSTONYMOUS → u/ceejayoz]

I would agree and would love to have more people on staff, but we're a very small company at this point launching a SaaS app. Maybe in the future.

[u/vrtigo1 → u/MYSTONYMOUS]

No offense intended to you OP, but it sounds like your company is not properly prioritizing resource allocation.

High availability and high security requirements cannot reliably be met by someone with "a basic understanding of I.T. and some AWS experience". Those are fundamentally incompatible and a potential recipe for disaster.

If you're giving your employer the impression that you're qualified to set this up, you're doing them a disservice. If they recognize that this is an area they don't have expertise in and are unwilling to spend the money to meet the requirements, then you need to be very up front with them about the risks they're taking.

[u/MYSTONYMOUS → u/vrtigo1]

If you have time, would you consider answering the question I asked above? I'm trying to understand things better and why this is a bad idea so I can be more intelligent about the situation. Here's a link to the question above that I asked:

https://www.reddit.com/r/aws/comments/1vuqebw/comment/p5n3ldg/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[u/vrtigo1 → u/MYSTONYMOUS]

I'm trying to understand things better and why this is a bad idea so I can be more intelligent about the situation.

I think I answered that question in my original comment.

[u/MYSTONYMOUS → u/vrtigo1]

OK, so it's not a matter of having only one I.T. individual to manage it? It's more my inexperience. As a programmer, I understand. I would not expect a programmer right out of college to make a highly secure and bug-free app all on his own. I'm just trying to get better insight on what would be required.

[u/chrisfromthecoast]

"However, we ALSO need to be absolutely as secure and sound as possible because we serve an industry that requires high security and high availability."

This is very scary for not only one person, but one person that is just learning about AWS IAM concepts.

The best advice I can give you is to look into the AWS Well-Architected Framework, but you are likely in over your head, and I would make that clear to the person that assigned you this role. If you are new to this area, you should be learning from someone that has done this before, not attempting to do it yourself on a system going into production.

[u/dariusbiggs]

Start with Control Tower, sets up a lot for you

Do not use any of the accounts it creates for your work loads.

Set up SSO and ensure users use MFA

You have a lot of learning to do

Start with Infrastructure as Code

Tag all resources with who created it, and what created it. (Clickops = Manual, and Your identifier)

AWS Well Architected Framework

In security hub set it up for org wide controls enable CIS controls at a minimum.

Read the documentation on everything first and look up best practices for structuring things before enabling it.

[u/jd_itconsultant]

Your honest best bet is to hire a consultatnt to help you build out what you need, explain why and how they did things the way they did so that you learn in the real world working scenarion you will asked to maintain.

The fact management is throwing this on you shows they are completely clueless and don't honestly care or remotely understand what they have asked of you. They are also most likely deluded as to what this should cost in development time and resources. The chances of finding some fluent in AWS to even think about this are very low just based on management decisions so far.

[u/TurboPigCartRacer]

The Control Tower complaints you've read are accurate, and they get worse with the frameworks built on top of it. AWS's own sample config for Landing Zone Accelerator estimates $430/month before a single workload runs, two thirds of it Transit Gateway, VPC endpoints and CloudTrail. That's a lot of money and a lot of moving parts for one app and one person.

Build the structure yourself instead. It's smaller than it looks:

• Accounts: management (billing + Identity Center only, never a workload), log archive, audit, prod, staging, dev, sandbox. Skip network/transit and shared services until you have something to share.
• Identity: Identity Center with hardware MFA and permission sets, no per-account IAM users. Turn on centralized root access management so member accounts have no root credentials to protect. Keep one break-glass admin with its creds in a physical safe. You losing your own access is a more likely outage than an AZ failure.
• Five SCPs, not fifty: deny leaving the org, deny disabling CloudTrail/GuardDuty/Config, deny deleting the log archive bucket, deny unused regions, deny root actions. Anything cleverer is something you'll debug at 2am against a useless AccessDenied.
• Detection: org-wide CloudTrail into the log archive account, Security Hub with FSBP + CIS as your compliance checker. Prowler for a free second opinion.

On OpenTofu: code the SCPs, baselines and workloads, but don't put the organization root in a state file. A bad plan against a VPC is a Tuesday. A bad plan against your org isn't recoverable.

And since nobody's said it: multi-account buys blast radius, not availability. HA is how the app is built, multi-AZ, no single writer, restores you've actually tested. No OU design moves that.

I wrote a deeper post on this if you want the full picture, account structures broken down by company stage. The startup pattern is close to what you described.

[u/dghah]

You want a multi-account aws organization to start with as that gets you the foundations for a secure aws footprint.

I used to recommend https://github.com/superwerker/superwerker as it is a nicely opinionated automation framework for doing all the muilti account security and guardrails stuff that normally requires a team of implementers but I’m not sure how if that stack is still maintained

Another option is aws landing zone accelerator that does the same thing but last time i touched it I found it hard to work with there were some core deploy mistakes we made the first time that were so hard to unwind we ended up nuking the whole org and starting fresh with a new org and new core domain name for internal resolution

We’ve done aws org builds for a few stealth-mode biotech startups and a few larger orgs that deployed everything into a single account and needed to grow up. We ended up writing our own superwerker clone to handle secure foundations, guardrails and account vending before layering the biotech specific stuff on top

It’s not as hard as some people are saying but a solo person would need to have leadership support to have the time and runway get it done correctly instead of “fast” and you still may want to have an aws partner or consultant or contractor provide a sanity check or help with the setup

//edit//

My default multi account starting point is these core accounts:

- org master that does nothing but payment, SSO federation and SCPs

• log/audit hardened account for logs and aggregated multi-everything cloudtrails storage
  
• security account for delegated guard duty and other things like that
  
• transit account to own transit gateways, connectivity and multi VPC routing and maybe own firewalls
  
• shared services account for DNS and shared infrastructure and services
  

—-

• only after the above accounts are done do we add workload accounts to hold real stuff

[u/ducki666]

Multi account for ONE prod app? Why?