AWS Migration Architecture

As infrastructure costs increase and the business looks to reduce its reliance on outsourced infrastructure management, I’m evaluating and designing a potential migration of an established on-premises environment to AWS.

The goal is not simply to reproduce the existing environment in the cloud, but to determine which workloads should migrate as-is, which should be redesigned, and where AWS-native services can reduce infrastructure management without introducing unnecessary complexity.

I began by assessing the existing infrastructure: documenting workloads and dependencies, inventorying servers and storage at an appropriate planning level, and comparing allocated CPU, memory and storage with actual utilization.

The current environment is stable, but its physical infrastructure was intentionally provisioned with spare capacity. The migration plan therefore uses observed workload requirements rather than recreating existing servers one-to-one in EC2. Usage informs compute sizing, storage choices and estimated data-transfer requirements, while intermittent workloads are evaluated differently from always-on production services. This avoids turning unused capacity into recurring cloud cost.

The environment spans Java and Spring applications, SQL Server, legacy data, shared document storage, Windows application workloads, identity and authentication, public web applications and internal administrative systems.

• Rehost
  Move a suitable workload with minimal application change.
• Replatform
  Change the hosting model where a managed service offers a practical operational benefit.
• Refactor
  Redesign only where application change is justified by the requirement.
• Retain
  Keep a workload in place when migration would add cost or complexity without sufficient value.

A significant part of the planning involves comparing multiple technically viable solutions rather than assuming there is one correct cloud architecture.

• SQL Server on EC2 vs. RDS
• Active Directory vs. Entra ID
• AWS-native identity vs. Entra ID federation
• VPN vs. Zero Trust access
• Database document storage vs. S3
• Shared file infrastructure vs. SharePoint / OneDrive
• Terminal Server vs. cloud desktop or application streaming
• On-Demand pricing vs. Compute Savings Plans
• Hybrid infrastructure vs. an all-cloud environment
• Licensing included with services vs. separately purchased licensing
• Backup frequency, retention and disaster-recovery requirements
• Document retention and storage lifecycle policies

Cost modelling is part of the design process rather than something added after the architecture is complete.

I’ve used the AWS Pricing Calculator to model multiple versions of the environment, including On-Demand pricing and different Compute Savings Plan commitments.

I’ve also compared alternative architectures, identified licensing considerations outside AWS, evaluated workloads that do not need to operate continuously, and used existing network utilization to estimate cloud data-transfer requirements.

The goal is not to assume that moving to AWS automatically makes the environment more secure. The existing infrastructure already has established controls, so the migration needs to preserve that posture while adapting those controls to a cloud environment.

Network isolation, IAM, MFA, encryption, application-layer protection, monitoring and threat detection are being considered as part of the architecture rather than added afterward.

Selected AWS services and test instances are being used to validate assumptions before commitment to a final architecture.

This supports a phased plan in which technical, operational and financial questions can be resolved before production workloads move. Documentation and review provide decision points rather than treating migration as a single irreversible event.

• AWS
• EC2
• S3
• IAM
• VPC
• Application Load Balancer
• WAF
• GuardDuty
• CloudWatch
• EventBridge
• SNS
• Docker
• SQL Server