Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
AWS account setup checklist for a new product (2026) The first-week setup we use for new AWS accounts: root user lockdown, Organizations, Identity Center, keyless CI/CD, guardrails and billing alerts.
A founder creates an AWS account on a Sunday with a personal email and a personal card, launches an EC2 instance, and ships. Two years later the product has paying customers, the founder's inbox still holds the root login, three developers share one IAM user, and nobody can say why the bill doubled last March. All of it is cheaper to prevent in the first week than to untangle later.
Short answer: an AWS account setup checklist for a new product comes down to six things. Own the account with a company email, lock the root user with MFA, give people access through IAM Identity Center, split production and non-production into separate accounts, switch on budgets and CloudTrail, and let CI deploy through short-lived roles instead of stored keys.
Below is the order we work through, with commands for the parts that are easy to get wrong. It assumes a small team and one product, not an enterprise landing zone.
1. Ownership and the root user The account belongs to the company, so the details on it should too. Use a shared mailbox or distribution list such as aws-root@yourcompany.com for the root email, not one person's address. Put a company card on billing. Record the account ID and the legal entity name somewhere the directors can find them.
Enable MFA on the root user straight away. AWS now requires it for root users, and a hardware security key or passkey is the better choice over an authenticator app. Register at least two MFA devices, held by two different people, so losing one phone does not lock the company out. Do not create access keys for the root user. If any exist, delete them. Set the alternate contacts for billing, operations and security under Account settings, so AWS notices reach someone who will act on them. Store the root password in the company password manager and write down who may use it, and for what. After this, the root user should hardly ever be used. Day-to-day work happens through identities you can audit and revoke.
2. Use an Organization and separate accounts Even a two-person team benefits from AWS Organizations. The account you created becomes the management account, and it should run no workloads at all: only billing, the organisation itself and identity. Workloads live in member accounts. A simple layout that scales well:
Management: billing, Organizations, IAM Identity Center. Nothing else. Production: the live product and its data. Staging (or non-production): development and test environments, where people can experiment. Optionally a log archive or security account, once you have more than a couple of workload accounts. Separate accounts give you a hard boundary that IAM policies inside one account never quite match. A mistake in staging cannot delete a production database, costs are split per account without tagging gymnastics, and you can give a contractor access to staging only. Member accounts are free to create. With centralised root access management turned on in the organisation, you can also remove root credentials from member accounts entirely.
AWS Control Tower can automate this layout with guardrails. It is worth it once you have several accounts; for three accounts, setting things up by hand or with infrastructure as code is often clearer.
3. People and pipelines: no long-lived keys Enable IAM Identity Center in the management account and create users there, or connect it to Google Workspace or Microsoft Entra ID if you already use one. People sign in through the access portal and receive temporary credentials for the accounts and permission sets you assign. The AWS CLI supports this directly:
aws configure sso
# follow the prompts, then:
aws sso login --profile prod-readonly
aws s3 ls --profile prod-readonlyCreate a small set of permission sets, for example Admin, Developer and ReadOnly, rather than one per person. Give production write access to as few people as possible. Most people need ReadOnly there. Require MFA in Identity Center for every user. When someone leaves, disabling them in one place blocks new sign-ins to every account. Sessions already issued last until they expire, so keep session durations short. Long-lived IAM users with access keys are the most common way small AWS accounts get compromised: a key ends up in a laptop backup, a public repository or a .env file in a container image. If a tool genuinely needs an IAM user, scope it tightly and rotate the key.
CI/CD pipelines should assume an IAM role through OpenID Connect instead of holding an access key as a secret. For GitHub Actions you add GitHub as an identity provider in IAM, then create a role whose trust policy only accepts tokens from your repository and branch:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:your-org/your-app:ref:refs/heads/main"
}
}
}]
}The workflow then uses aws-actions/configure-aws-credentials with role-to-assume and needs id-token: write permission. Keep the sub condition specific. A job that uses a GitHub environment sends repo:your-org/your-app:environment:production instead of the branch ref, so match what your workflow sends. A wildcard such as repo:your-org/* lets any repository in the organisation deploy to production. Give the role only the permissions the deployment needs, and use a separate role per account.
4. Guardrails worth switching on in week one A handful of settings close the gaps we see most often. Most are free; GuardDuty and Security Hub are billed by usage after a 30-day trial. Some are per region, so apply them in every region you use:
# Block public S3 access for the whole account
aws s3control put-public-access-block \
--account-id 111122223333 \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
# Encrypt new EBS volumes by default (per region)
aws ec2 enable-ebs-encryption-by-default --region ap-south-1
# Turn on GuardDuty threat detection (per region)
aws guardduty create-detector --enable --region ap-south-1CloudTrail: the console's event history only keeps 90 days of management events. Create an organisation trail that writes to an S3 bucket in a separate account, so you have a longer record that a compromised workload account cannot delete. Regions: pick your primary region deliberately, based on where users and data need to be. Then use a service control policy to deny the regions you do not use, keeping exceptions for global services such as IAM. IAM Access Analyzer: it flags resources shared outside your organisation, such as a bucket or role trusted by an unknown account. Security Hub: useful once the basics are in place, as a single list of misconfigurations to work through. Default VPCs: decide whether to keep them. Many teams build their own VPC with infrastructure as code and remove the defaults to avoid accidental public instances. 5. Billing visibility from day one Surprise bills on young accounts usually come from something left running, a NAT gateway nobody noticed, data transfer, or leaked credentials used for crypto mining. You cannot prevent all of them, but you can hear about them within a day.
Create a monthly cost budget in AWS Budgets with alerts at 50%, 80% and 100% of actual spend, plus one on forecasted spend. Send them to a shared address, not one inbox. Turn on Cost Anomaly Detection with a daily summary, so a sudden spike on one service is flagged before the month ends. Agree a tagging scheme early, for example project, environment and owner, and activate those as cost allocation tags in the Billing console. Tags only appear in cost reports after activation. Remember public IPv4 addresses are charged hourly, including ones attached to running instances. Count them. Review Cost Explorer monthly, grouped by account and service. If cost predictability matters more than flexibility, read our comparison of Lightsail and EC2 before you size anything. A fixed bundle can be the right first step.
6. Build it as code, and plan for recovery Everything after the root user and the Organization is best defined in Terraform, OpenTofu or the AWS CDK and kept in version control. That gives you a review step for changes to production, a record of why something exists, and a way to rebuild staging from scratch. It also makes moving workloads between accounts or regions realistic.
Decide early where backups live. AWS Backup can copy snapshots to another account, which protects you if the production account itself is compromised. Then restore one, on a schedule, so you know the copies work.
The checklist Root email is a company mailbox; root has MFA on two devices and no access keys. Alternate contacts are set for billing, operations and security. AWS Organizations is enabled; the management account runs no workloads. Separate production and non-production accounts exist. People sign in through IAM Identity Center with MFA; no shared IAM users. CI/CD deploys through an OIDC role scoped to one repository and branch. S3 Block Public Access, EBS default encryption and GuardDuty are on in every region you use. An organisation CloudTrail writes to a bucket outside the workload accounts. Unused regions are denied with a service control policy. Budgets, anomaly alerts and cost allocation tags are active. Infrastructure is in code, and backups are copied to another account and test-restored. If you are starting fresh, this is a day or two of careful work. If you are retrofitting it onto an account that already runs production, do it in stages: root and billing first, then people access, then accounts and guardrails. Moving live workloads into a new account structure is the hardest step. It needs a written plan for DNS, data and downtime, and a rollback, rather than a few console clicks.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789