Contents
- AWS vs. the competition: where it actually wins
- Recommended architecture by company size
- Landing Zone and AWS Organizations accounts
- IAM and identity: the foundation of everything
- Core services to start: EC2, RDS, S3, CloudFront, VPC
- Costs: pricing model and pitfalls
- When to use Control Tower
- Next step
- Frequently asked questions
Most enterprise AWS migrations don't fail in the technical execution. They fail in the first 60 days, when leadership treats AWS as a data center with an API instead of an operating model. Workloads get lifted, bills double, and the security team finds out two quarters later that production runs under a single root account with 47 IAM users.
This guide is built for CTOs, VP Engineering, and Cloud Architects running their first serious migration (or fixing a rushed one). It walks through the architectural decisions that matter on day one: account structure, identity, core services, and the cost traps that turn a 3-year business case into a board-level problem. If you want the broader cloud strategy context first, start with our complete cloud migration guide.
The assumption here is simple: you've already decided AWS is on the table. Now you need to move without breaking production, without burning cash, and without locking your team into a design you'll regret in 18 months.
AWS vs. the competition: where it actually wins
AWS leads in market share and breadth of services, but that's not a reason to choose it. The practical differentiators for enterprise buyers are: the maturity of the partner and staffing ecosystem, the depth of compliance certifications (FedRAMP, HIPAA, PCI-DSS, SOC), and the granularity of IAM and networking primitives. For a direct comparison against Google Cloud on pricing, data, and AI workloads, see our GCP vs. AWS breakdown.
Where AWS loses ground: the UX is dense, native BigQuery-class analytics require stitching (Redshift + Glue + Athena), and egress pricing is aggressive. Pick AWS when your priority is service breadth, regulated workloads, or a large talent pool. Pick elsewhere when your team is small and you need opinionated defaults.
Recommended architecture by company size
The right landing architecture depends on headcount, workload count, and compliance scope. A 30-person SaaS doesn't need the same blueprint as a 5,000-employee bank.
| Company profile | Accounts | Networking | Governance |
|---|---|---|---|
| Startup / <50 eng | 3–5 accounts (prod, staging, shared, security, log archive) | Single VPC per account, public + private subnets | AWS Organizations + SCPs |
| Mid-market / 50–500 eng | 10–20 accounts, one per workload + environment | Transit Gateway, centralized egress | Control Tower + custom guardrails |
| Enterprise / 500+ | 50+ accounts, OU hierarchy by business unit | Multi-region Transit Gateway, hub-and-spoke, Direct Connect | Control Tower + Config Conformance Packs + custom SCPs |
The common mistake is over-engineering on day one. A mid-market company doesn't need 50 accounts; it needs a structure it can grow into without re-architecting.
Landing Zone and AWS Organizations accounts
A Landing Zone is the pre-wired foundation: multi-account structure, baseline networking, centralized logging, identity federation, and guardrails. Building it manually takes 8–12 weeks for an experienced team. Using AWS Control Tower cuts that to days, with the tradeoff of opinionated defaults.
At minimum, your Organization should include:
- Management account: billing and Organizations only. No workloads.
- Log Archive account: centralized CloudTrail and Config logs, write-only for most roles.
- Security / Audit account: read access to all accounts for GuardDuty, Security Hub, IAM Access Analyzer.
- Shared Services account: directory services, CI/CD, shared tooling.
- Workload accounts: one per environment per workload (prod, staging, dev).
Organize accounts into OUs (Organizational Units) by function, not by team. SCPs (Service Control Policies) apply at the OU level and act as hard ceilings on what any principal in that account can do, regardless of IAM permissions.
IAM and identity: the foundation of everything
IAM is where most breaches happen. [VERIFY: per IBM Cost of a Data Breach 2025, misconfigured cloud identity accounts for roughly 15–20% of cloud incidents]. Get this wrong and no amount of network controls will save you.
Non-negotiables for enterprise IAM:
- No IAM users for humans. Federate through IAM Identity Center (formerly SSO) connected to Okta, Entra ID, or your IdP. Humans get temporary credentials, never long-lived keys.
- Role-based access only. Permissions attach to roles, roles are assumed. Use permission sets in Identity Center to propagate roles across accounts.
- Least privilege, enforced. Start from AWS managed policies, then tighten with IAM Access Analyzer findings after 30 days of usage data.
- MFA everywhere, including break-glass root accounts stored in a physical safe.
- Service-to-service auth uses IAM roles for EC2, ECS task roles, or IRSA for EKS. Never embed access keys.
If your current AWS environment has more than a handful of IAM users with console access and long-lived keys, that's remediation priority one before any migration expands the blast radius.
Core services to start: EC2, RDS, S3, CloudFront, VPC
The surface area of AWS is overwhelming. For 80% of enterprise migrations, five services do the heavy lifting:
- VPC: your private network. Plan CIDR ranges across all accounts up front; overlapping ranges block Transit Gateway peering later. Reserve /16 per environment, /20 per VPC.
- EC2: virtual machines. Default to Graviton (ARM) for ~20% price-performance gains where your stack supports it. Use Auto Scaling Groups, not standalone instances.
- RDS: managed relational databases. Multi-AZ for production, automated backups, and Performance Insights on from day one. Aurora for workloads that justify the premium.
- S3: object storage. Block public access at the account level, enable versioning and default encryption, and set lifecycle policies before data volume makes them expensive to apply.
- CloudFront: CDN and edge caching. Pair with S3 for static assets and with ALB for dynamic content. Reduces egress costs and latency.
Observability is the sixth service you can't skip. Wire CloudWatch, CloudTrail, and centralized logs into the Log Archive account from day one. Our AWS monitoring and observability guide covers the full stack.
Costs: pricing model and pitfalls
AWS pricing is transparent but unforgiving. The on-demand list price is the worst price you'll ever pay. Enterprises that don't actively manage cost overspend by [VERIFY: 30–35% on average according to Flexera State of the Cloud 2025].
The pitfalls that bite hardest:
- Data egress. Moving data out of AWS costs $0.05–$0.09/GB. Cross-region and cross-AZ traffic also charges. Architect for data locality.
- NAT Gateway. $0.045/hour plus $0.045/GB processed. A busy VPC can generate five-figure monthly NAT bills. Use VPC endpoints for S3, DynamoDB, and other AWS services.
- Idle resources. Unattached EBS volumes, idle RDS instances, forgotten dev environments. Tag everything and run weekly cleanup automation.
- On-demand for steady workloads. Commit to Savings Plans or Reserved Instances for baseline capacity. 1-year commitments typically save 30–40%; 3-year saves 50%+.
- Log storage. CloudWatch Logs and S3 log archives grow silently. Set retention policies and move cold data to S3 Glacier.
Set up AWS Budgets with alerts at 50%, 80%, and 100% of forecast before a single production workload lands.
When to use Control Tower
AWS Control Tower automates Landing Zone setup: it provisions the management structure, baseline SCPs, centralized logging, and Identity Center integration. It's the right default for most organizations starting fresh or with fewer than 20 accounts.
Use Control Tower when: you're standing up a new AWS Organization, your compliance requirements map to its preventive and detective guardrails, and your team doesn't have deep AWS platform engineering capacity.
Avoid or extend Control Tower when: you already have a heavily customized Organization (migrating in is painful), you need guardrails Control Tower doesn't offer natively (supplement with Config Conformance Packs and custom SCPs), or you operate at a scale where its opinionated defaults become constraints. Large enterprises often use Control Tower for the baseline and layer custom IaC on top for account vending and advanced governance.
Next step
An AWS migration that skips the Landing Zone, IAM design, or cost governance will cost 2–3x more to fix than to build correctly. If you're scoping a migration or cleaning up one that moved too fast, contact us to book a 30-minute diagnostic. We'll review your current state and give you a prioritized remediation or migration plan.
Frequently asked questions
Need to optimize your cloud infrastructure?
Schedule a free assessment with our team.
Talk to an expert