What Is AWS Migration? Risks, Controls, and the SRM

A migration team lifts a fleet of on-premises servers into Amazon EC2 over a weekend. The application works Monday morning. What also came along: a security group that allowed 0.0.0.0/0 on port 3389 because the old data-center firewall used to block it, a service account whose long-lived credentials are now reachable from the public internet, and an S3 bucket created to stage the data that nobody set to private. None of this is an AWS flaw. It is the old environment's assumptions, moved into a place where those assumptions no longer hold.

That is the security problem with an AWS migration. The migration is a project to move workloads. The attack surface moves with them, and the controls that used to contain it, the network perimeter, the physical boundary, the implicit trust of "it is inside our building", do not come along. New controls have to be rebuilt on the cloud's terms, and the window during the move is when gaps are widest.

This guide is the defender's view of an AWS migration: what it is, the four phases AWS structures it around, the 7 Rs that decide how much of the risk you carry forward, the shared responsibility model that draws the line between AWS and you, the security risks the move introduces, and the controls that close them. It is written for blue teamers: SOC analysts, incident response practitioners, and students prepping for detection-and-response work who inherit the environment after the migration team has moved on.

What is an AWS migration?

An AWS migration is the process of moving applications, data, and infrastructure from an on-premises data center or another cloud into Amazon Web Services. The driver is usually cost, scale, or speed of delivery. The security consequence is that responsibility for the workload splits between AWS and the customer the moment it lands, and the boundaries that used to protect it are gone.

Three shifts make this a security event, not just an operations project.

The perimeter dissolves. On-premises, a workload sits behind a network edge: a firewall, a DMZ, physical access control. In AWS, a workload is reachable from anywhere with the right credential or an open security group. The control plane is an API. Identity, not the network, becomes the boundary, and a lift-and-shift that does not rebuild around that fact carries an exposed surface into the cloud.

Configuration becomes the attack surface. AWS resources are created by API call, in seconds, often by infrastructure-as-code. A single wrong setting, a bucket left public, a security group open to the internet, an over-broad IAM policy, exposes data instantly and at scale. Most cloud incidents are not exploits. They are settings, and a migration generates thousands of new settings fast.

Responsibility splits, mid-flight. During the move, ownership of a workload is genuinely ambiguous: it may exist in both environments, with logging on one side and not the other, and a team that assumes "AWS handles security now" when AWS handles only its half. That ambiguity is the gap attackers and accidents both fall into.

The phases of an AWS migration

AWS structures a migration into four phases. Each one has a security job that, skipped, becomes a finding later. The model below is AWS's own migration journey (assess, mobilize, migrate, modernize).

Assess is where security has the most leverage and gets the least attention. The estate inventory is also a sensitivity inventory: which workloads touch regulated data, which hold credentials, which are internet-facing. Classifying that before the move tells you which workloads need the strongest controls on landing. Skipping it means discovering your crown-jewel database is in a wide-open subnet after it is already there.

Mobilize builds the landing zone, the pre-configured, secured AWS environment that workloads migrate into. This is the single highest-value security step. A landing zone with a hardened IAM baseline, organization-wide guardrails, CloudTrail enabled in every account, encryption on by default, and a sane network design means every workload that lands inherits good defaults. A landing zone built carelessly means every workload inherits the gaps.

Migrate is the dangerous window. Workloads exist in two places, temporary credentials and access paths get created to move data, and the pressure is to make it work, not to make it tight. The discipline is to validate each migration wave against the Assess-phase baseline and never let logging go dark on either side during the cutover.

Modernize is the chance to pay down the security debt a lift-and-shift created: replace long-lived keys with roles, scope the over-broad policies that got the move done, decommission the temporary access, and re-architect the carried-over network exposure. Migrations that stop at "it runs in AWS now" leave this debt in place permanently.

The 7 Rs: how much risk you carry forward

AWS describes seven migration strategies, the 7 Rs. The choice is usually framed as cost and effort, but it is also a security decision: each strategy carries a different amount of the old environment's risk into the new one. A pure lift-and-shift carries the most; a re-architecture carries the least but introduces new cloud-native surfaces to secure.

The defender's read: rehost and relocate move fast and carry the most risk forward, which is fine as long as the Modernize phase actually follows to pay it down. The retire option is underused and is the only strategy that reduces attack surface to zero, so the Assess phase should ask "can we just turn this off?" before it asks "how do we move it?" Every workload you do not migrate is one you do not have to defend.

The shared responsibility model

The shared responsibility model is the agreement that defines which security tasks AWS handles and which the customer handles. Misreading it is the root cause of a large share of cloud breaches, because teams assume AWS covers something it does not. After a migration, getting this line right is the first thing a defender has to do.

The short version: AWS secures the cloud. You secure what you put in it.

AWS calls its half "security of the cloud": the hardware, software, networking, and facilities that run AWS services. The customer's half is "security in the cloud", and exactly where the line falls depends on the service. The more managed the service, the more AWS takes on. A managed database (replatform) means AWS patches the engine; a rehosted EC2 instance means you patch the guest OS yourself. But three things never leave you no matter the service: your data, your IAM identities and policies, and your configuration.

This is why "we moved to AWS, so it is secure now" is a category error. AWS's infrastructure can be secure and your deployment wide open at the same time. The migration moved the workload; it did not move the responsibility for the layers you still own. The model tells you exactly where to point effort after a migration: at IAM, configuration, and data, because that is the customer's side of the line and where the breaches happen.

The security risks an AWS migration introduces

A migration is a concentrated burst of new resources, new identities, and new access paths created under time pressure. That is precisely the condition that produces the dominant cloud risks. These track closely with the Cloud Security Alliance's documented top cloud threats, seen through the migration lens.

Misconfiguration carried over and created. The single most common cause of cloud data exposure, and the core problem cloud security exists to solve. A rehost drags old assumptions into new defaults: a security group opened to 0.0.0.0/0 because the on-premises firewall used to handle it, logging left off because it was never on before, storage staged in a public bucket to make the move easier. These are settings a defender can find and fix, and a migration creates them by the thousand.

Over-privileged IAM and leaked credentials. Migrations run on broad permissions, because scoping every role correctly slows the move down. The migration service account often gets near-admin rights and keeps them long after cutover. Long-lived access keys get embedded in scripts, AMIs, and config files to automate the move, then linger. Once an attacker holds a valid AWS credential, the control plane sees normal activity, because to AWS it is normal activity. Over-privileged roles also open privilege escalation: a role that can pass another role or edit its own policy becomes an admin path.

Data exposure during transfer and at rest. Data in motion between environments, and data staged in interim buckets or snapshots, sits outside the controls that protected the production copy. Unencrypted volumes, public snapshots, and forgotten staging buckets are classic migration leftovers that lead straight to a data breach.

Logging blind spots. AWS activity is invisible by default until logging is turned on. During a migration, CloudTrail is frequently enabled late, configured in some accounts and not others, or not shipped anywhere a SOC can see it. An intrusion during the move leaves no trail to investigate, and the detection coverage that existed on-premises does not automatically exist in AWS.

Compliance scope drift. Regulated data that was in a tightly scoped on-premises environment lands in AWS accounts that were never assessed for HIPAA, PCI DSS, or GDPR. The obligation to protect the data moved with the data; the controls and the audit boundary did not.

Hybrid-seam exposure. During and after the migration, on-premises and AWS run connected. The link between them, a VPN or Direct Connect, plus the identity federation across it, is a new trust path. A compromise on the legacy side now has a route into AWS that did not exist before.

The through-line: almost every one of these lives on the customer's side of the shared responsibility model. An AWS migration is mostly the discipline of getting your own side of that line right while everything is in motion.

The controls that hold during and after migration

The risks above map to a short list of controls. Ordered by how much risk they remove:

1. Build a secure landing zone before any workload moves. This is the highest-leverage control, because every workload inherits it. A hardened landing zone sets the IAM baseline, enables CloudTrail across every account, turns on encryption defaults, applies organization-wide guardrails (service control policies that block the worst misconfigurations outright), and lays out the network so workloads land in private subnets by default. Get this right and most per-workload mistakes are prevented structurally.

2. Enforce least privilege and kill long-lived keys. Scope the migration service account to exactly what the move needs and revoke it at cutover, do not leave near-admin rights lying around. Replace static access keys with IAM roles and short-lived, federated credentials. Require MFA on every human account, root first. After the move, audit which permissions were actually used and strip the rest.

3. Turn on CloudTrail everywhere and ship it to a SIEM. Enable CloudTrail (and VPC Flow Logs, and the relevant service logs) in every account from the Mobilize phase, before workloads arrive, and forward them to a SIEM. You cannot detect or investigate what you never recorded. Continuous logging across the whole migration, with no dark windows during cutover, is the difference between a detectable intrusion and an invisible one.

4. Encrypt data in transit and at rest, including in flight. TLS for the transfer itself, encryption on every volume and bucket including the interim staging ones, and deliberate key management. Encryption limits the blast radius when a misconfiguration or a leaked credential exposes a store anyway.

5. Scan configuration continuously. Run a posture scanner (AWS Config, Security Hub, or an open-source tool) against every account on a schedule, not once at the end. Treat public buckets, open security groups, unencrypted volumes, and disabled logging as incidents to close, not findings to file. This targets the number-one cause of cloud breaches directly.

6. Shift checks into the pipeline. If the migration uses infrastructure-as-code, scan the templates before they deploy. Catching a public-bucket definition in a pull request is cheaper than catching it in production after a scanner, or an attacker, already found it.

7. Plan for cloud incident response. Cloud forensics is different: the evidence is API logs and snapshots, not disk images, and resources can vanish before you investigate. Know how you will preserve CloudTrail, snapshot volumes, and revoke credentials in AWS before you need to, because the on-premises runbook does not translate.

The pattern across all seven: the controls that matter most are the ones the customer owns. AWS gives you the tools (IAM, CloudTrail, Config, KMS, security groups), but configuring them correctly during the move is the work that decides whether the migration hardens you or exposes you.

The bottom line

An AWS migration moves your workloads into the cloud and the responsibility for securing the customer-owned layers along with them. The shared responsibility model is the map: AWS secures the infrastructure, you secure your data, your IAM, and your configuration, and that line does not move just because the workload did. The 7 Rs decide how much of the old environment's risk you carry forward, with rehost carrying the most and retire removing it entirely.

The migration window, when workloads live in two places, credentials are broad, and logging is uneven, is where the gaps are widest. The controls that close them are the ones you own: a secure landing zone built before anything moves, least-privilege IAM, CloudTrail everywhere shipped to a SIEM, encryption end to end, and continuous configuration scanning.