AWS foundations for a mid-sized company's first custom apps

Why set up foundations for one app

It's tempting to create one AWS account, click together what the first app needs, and tidy up later. Later is easy to postpone. Production and test resources end up mixed together, nobody is sure which resources are safe to delete, the bill can't be split by app, and access has drifted to a few people with administrator rights.

A basic foundation isn't a large project. Most of it is configuration you set once: an account structure, sign-on, a pipeline pattern, logging and budgets. Done alongside the first app, it becomes the template every later app follows.

Accounts: the first decision

In AWS, an account is the hardest boundary between workloads: separate permissions, separate limits, separate bills. AWS Organizations groups accounts under one management account, with consolidated billing and policies that apply across them. A starting structure for a mid-sized company looks like this:

AWS Control Tower can set up this kind of structure with a baseline of controls applied for you; setting up Organizations directly is also reasonable at this size. Either way, add service control policies for a few firm rules, such as restricting which regions can be used and preventing anyone from turning off audit logging. As more apps arrive, you can split non-production and production further, per app or per team.

Identity and access

• Single sign-on for people. Connect AWS IAM Identity Center to your identity provider (Microsoft Entra ID, Okta or similar), so AWS access follows the same joiners-and-leavers process as everything else.
• Roles, not users. People get temporary credentials through permission sets per account: read-only, developer, administrator. No IAM users with access keys for day-to-day work.
• Lock down the root user of every account: strong password, MFA, and no access keys.
• Least privilege for apps. Each app's compute (Lambda functions, containers) gets its own IAM role with only the permissions it needs.
• Secrets in a secrets manager. Database passwords and third-party API keys live in AWS Secrets Manager or Parameter Store, never in code or environment files in the repository.

Infrastructure as code

Define every resource in code, review changes like any other code, and deploy them through a pipeline. That gives you a record of what exists and why, the ability to rebuild an environment, and identical dev and production setups. The three common choices:

All three are sound. Pick one per company rather than per project, so everyone can read everyone else's infrastructure. Whichever you choose, the code should be able to create the whole environment from an empty account, rather than relying on resources someone once created by hand.

CI/CD with OIDC, not stored keys

A deployment pipeline needs permission to change AWS. The older approach stores an access key in the CI system, where it lives forever and can leak. The better approach is OpenID Connect (OIDC): GitHub Actions and most other CI systems can present a short-lived token that AWS trusts, and the pipeline assumes an IAM role for the length of the job.

Environments

Most first apps need two environments, dev and production, defined by the same code with different settings. Add a staging environment when you need to test against production-like data or integrations before release. Keep environment differences in configuration, not in separate copies of the infrastructure code, so they can't quietly drift apart.

If the app has to reach systems in your own data center or plant, plan the connection early. A site-to-site VPN or AWS Direct Connect link, and the firewall rules on your side, usually involve people outside the project, so start those conversations early.

Monitoring and audit

• Audit trail. An organization-wide CloudTrail trail delivering to the log archive account, so management activity in every account (and any data events you choose to enable) is recorded somewhere app teams can't change.
• Threat detection. Amazon GuardDuty turned on across accounts, with findings routed to someone who will read them.
• App logs and metrics. CloudWatch logs with a set retention period per environment, and metrics for the things users feel: errors, latency, failed jobs.
• Alarms that reach people. CloudWatch alarms on those metrics, sent through SNS to email or your chat tool, with a named owner for each app.
• Backups. AWS Backup plans, or the database's own automated backups, with a restore tested at least once before launch.

Cost guardrails

Cloud costs surprise people when nobody is watching them, not because AWS is inherently expensive. A few settings make spending visible from the first day.

Foundation checklist

Our experience includes AWS infrastructure as code with CDK, CloudFormation and Terraform, CI/CD with GitHub Actions and OIDC, multi-environment deployments, and monitoring with CloudWatch. Round Table, our own product, runs on AWS with its infrastructure defined in AWS CDK, GitHub Actions for CI/CD and separate dev and production environments. See AWS cloud & DevOps for how we'd set up yours.

Sources

• What is AWS Organizations? and service control policies (AWS)
• What is AWS Control Tower? (AWS)
• What is IAM Identity Center? and root user best practices (AWS)
• What is AWS Secrets Manager? (AWS)
• AWS CDK developer guide (AWS)
• Configuring OpenID Connect in Amazon Web Services (GitHub)
• AWS Site-to-Site VPN (AWS)
• Creating a trail for an organization and GuardDuty with Organizations (AWS)
• What is AWS Backup? (AWS)
• AWS Budgets, Cost Anomaly Detection and activating cost allocation tags (AWS)