Why Your Cloud Account Needs 2 Administrators, Not 1 or 10

TL;DR — A cloud account with only one administrator can lock your business out of billing, DNS, backups, and production systems if that person leaves, loses access, or makes a mistake. The safest default is usually 2 human administrators plus day-to-day lower-privilege roles: enough for recovery and continuity, not enough to create chaos. Reading time: ~7 min

What it is and where it sits

When we say "administrator" here, we mean an account with top-level permissions over your cloud environment: billing, identity and access management (IAM, the system that controls who can do what), networking, backups, DNS, and often the ability to delete resources.

This is not just "someone who can deploy the app." In most cloud providers, the cloud account sits above the servers, databases, storage buckets, domains, and access policies your application depends on. If the admin layer is mismanaged, everything under it is at risk.

A cloud account admin typically controls:

• who can sign in
• who can reset passwords or enforce MFA (multi-factor authentication, usually an app code or hardware key)
• who can view invoices and change payment methods
• who can create or delete production resources
• who can grant themselves or others more access

In a typical architecture, the cloud account is the control plane (the management layer), not the app itself. Your customers talk to your app. Your team talks to the cloud dashboard and identity system that operate the app.

[Customer Browser] ---- 1. HTTPS request ----> [Your App]
[Your App] ---- 2. read/write ----> [Database]
[Your App] ---- 3. files ----> [Object Storage]

[Admin User]
| 4. sign in to dashboard
v
[Cloud Account / IAM] ---- 5. manage ----> [App]
[Cloud Account / IAM] ---- 6. manage ----> [Database]
[Cloud Account / IAM] ---- 7. manage ----> [DNS / Network]
[Cloud Account / IAM] ---- 8. manage ----> [Billing / Backups]

Why does this matter? Because the cloud account admin role replaces a lot of old-world "someone has the root password" behavior. Years ago, a company might have had one server admin with SSH keys and a registrar login in a spreadsheet. In modern cloud setups, those powers are concentrated in the provider account and identity system. That is better for auditability, but only if access is designed well.

The practical design goal is simple:

• not one admin, because that creates a single point of failure
• not many admins, because that creates too many ways to cause damage

For most small and mid-sized businesses, the sweet spot is usually:

• 2 human admins minimum
• sometimes a 3rd emergency/break-glass admin (an account reserved for emergencies)
• everyone else gets narrower roles

How it actually works

Let’s walk through one realistic example: your agency manages your production app, and your internal operations manager handles billing and vendor relationships.

The setup

You have:

• one cloud provider account
• production app servers and database inside it
• DNS managed either in the same provider or another provider
• two human admins:
  • Admin A: your agency’s technical lead
  • Admin B: your company’s operations or finance owner
• all developers use non-admin roles for daily work

Step-by-step: what happens when one admin disappears

Imagine Admin A leaves the agency, loses their laptop, or their email account is disabled unexpectedly.

If Admin A was the only administrator, you may lose the ability to:

• approve access changes
• rotate secrets (passwords, API keys, certificates)
• change DNS during an outage
• restore backups
• update payment details if a card expires
• prove ownership to support

With a second admin already in place, the recovery path is straightforward.

1. Admin B signs into the cloud provider dashboard.
2. Admin B goes to the provider’s access area. In many providers this is something like:
   • Account/Organization Settings → Users
   • Security → Identity & Access
   • Admin Console → Members
3. Admin B disables or removes Admin A’s access.
4. Admin B invites a replacement admin or restores access for the agency under a new named user.
5. Admin B reviews recent audit logs (records of who changed what) for anything suspicious.
6. Admin B rotates sensitive credentials if needed:
   • API tokens
   • deployment keys
   • database passwords used by humans
   • DNS API credentials
7. The app keeps running because day-to-day systems were not tied to one person’s login.

That is the happy path.

Now the opposite problem: too many admins.

Suppose 9 people have full admin rights because it was "easier." Then:

• one person can accidentally delete a database snapshot
• another can weaken firewall rules
• another can create unmanaged API keys
• another can change billing contacts and nobody notices
• incident response becomes slower because nobody knows who changed what

The issue is not just malice. It is normal human error multiplied by broad permissions.

A good operating model is:

• 2 admins can recover the account if one is unavailable
• only those admins can grant admin rights
• engineers use role-based access for their actual jobs
• temporary elevated access is granted only when needed, then removed

A concrete end-to-end example

A production certificate expires because DNS needs a fix.

• A developer notices the app is failing TLS (the lock icon / secure connection).
• The developer does not have admin rights to edit DNS, which is good.
• They alert the team.
• Admin A is on a flight and unavailable.
• Admin B signs in, updates the DNS record or delegates the task to a limited DNS role.
• Service is restored.
• Afterward, Admin B removes any temporary elevated access.

If there had been only one admin, you might have waited hours while customers saw downtime. If there had been 10 admins, the DNS may already have been changed by several people with no clear ownership.

When to use it (and when not to)

This is less about company size than business risk. If the cloud account contains anything important, you need redundancy at the admin level.

You probably don’t need many administrators if:

• your goal is just convenience
• people only need to deploy code, not manage billing or identity
• you are using admin as a shortcut because roles were never set up

You probably do need at least two administrators if:

• the account holds production systems
• invoices, DNS, backups, or domains are tied to it
• an external agency or contractor has meaningful operational responsibility
• one person leaving would create panic

Trade-offs

Every security control has a cost. Here is the honest version.

There is also a people risk: if both admins are from the same vendor or agency, you still have concentration risk. A strong pattern is one admin from the service provider side and one from the customer side.

Another trade-off is lock-in. Every cloud provider names roles differently and places them in different menus. The principle is portable; the clicks are not. That means your process should describe the outcome, not only one vendor’s exact labels.

In practice

Below are practical examples you can adapt. The dashboard path should be your first choice; CLI is useful for teams already using infrastructure automation.

Example 1: Add a second admin in the dashboard

In your provider’s dashboard, look for a path similar to:

• Account Settings → Users / Members → Invite user
• Organization Settings → Access → Add member
• Security / IAM → Users → Assign role

Invite a named person, not a shared mailbox. Assign the smallest role that still has full account recovery ability; in many providers that role is called Owner, Administrator, or Account Admin.

⚠️ Before you remove the old sole admin, sign out and verify the new admin can sign in with MFA. Otherwise you can lock yourself out.

A simple internal checklist you can paste into your runbook:

- [ ] Invite second named admin from a different person/team
- [ ] Require MFA on both admin accounts
- [ ] Confirm both admins can access billing, IAM, and production resources
- [ ] Record where recovery codes or hardware keys are stored
- [ ] Remove admin rights from day-to-day developer accounts
- [ ] Review audit log after changes

What it does: this turns "we hope someone can get in" into a repeatable process. Gotcha: many teams stop after sending the invite and never verify the second admin actually completed setup.

Example 2: AWS CLI — list who has administrator access

If your team uses AWS and already has CLI access, this command helps identify roles and users with the AWS-managed AdministratorAccess policy attached.

aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

What it does: shows users, groups, and roles attached to a common full-admin policy. Gotcha: this does not catch every custom policy that is effectively admin, so treat it as a starting point, not a complete audit.

Example 3: Terraform — create a tightly scoped DNS editor role instead of giving admin

If your infrastructure is managed as code (configuration stored in files), define a narrower role for operational tasks.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets",
        "route53:ListHostedZones",
        "route53:ListResourceRecordSets"
      ],
      "Resource": "*"
    }
  ]
}

What it does: allows DNS changes without broad account administration. Gotcha: teams often give admin because a narrow role was never written; this is exactly the kind of role that lets you keep the admin count low.

Example 4: Internal policy snippet you can adopt today

cloud_admin_policy:
  minimum_human_admins: 2
  maximum_human_admins_default: 3
  shared_accounts_allowed: false
  mfa_required: true
  quarterly_access_review: true
  break_glass_account: optional
  break_glass_storage: "sealed company password manager vault"

What it does: gives your team a default rule instead of arguing case by case. Gotcha: if you create a break-glass account, do not use it for normal work or it stops being an emergency path.

Further reading

• AWS IAM User Guide — the sections on IAM best practices and access reviews
• Microsoft Learn — Azure role-based access control documentation
• Google Cloud documentation — IAM roles and service accounts
• NIST Cybersecurity Framework 2.0
• The "Authentication" and "Access Control" sections of the OWASP Cheat Sheet Series

This article was written by an AI system and published pending human review. Verify anything you intend to act on.