AWS Migration Security: 10-Point Checklist
Published on · Updated on
Replaced outdated AWS security guidance with current service behavior and added evidence-based cutover criteria for all ten checklist points.
A secure AWS migration needs checks that prove each workload is ready for cutover. Use this checklist to map the systems, data, identities, connections, and vendors in scope, assign an owner to each control, and keep evidence that shows the control works.
Apply the checks to the migration path as well as the destination: staging copies, temporary credentials, transfer services, test environments, and rollback data can all expose production information. AWS and the customer share security responsibilities; what the customer configures depends on the AWS services in use and the workload.
How to use this checklist
Start with an inventory of the source and target systems, AWS accounts and Regions, data stores, network paths, people and workloads with access, and third parties involved. For each item below, record the owner, the evidence, any gap, and the decision required before cutover. Keep the same record after migration so operations teams can verify ongoing controls.
| Security check | Evidence to retain |
|---|---|
| 1. Encrypt stored data and every transfer path | Service configuration, key policy, and a tested encrypted connection |
| 2. Use short-lived, least-privilege access | Identity and role map, MFA settings, and access review results |
| 3. Allow only approved network flows | Network diagram, security group and route review, and connectivity test results |
| 4. Map compliance duties to owners | Control matrix, data-location decisions, and reviewed audit evidence |
| 5. Prove backup recovery meets business targets | Approved RPO/RTO and a successful restore exercise with measured results |
| 6. Check application and deployment security | Build and scan results, patch status, and tested web protections where needed |
| 7. Reconcile data after transfer | Transfer reports, validation results, and resolved exceptions |
| 8. Collect the security signals you need | Logging and detection coverage, retention settings, and a tested alert route |
| 9. Exercise the incident response plan | Current contacts, runbook, exercise findings, and assigned follow-up actions |
| 10. Constrain and review third-party access | Vendor access record, role trust policy, and evidence of access monitoring |
10 security checks for an AWS migration
1. Encrypt data at rest and in transit
Inventory databases, volumes, object stores, snapshots, backups, logs, and temporary migration copies. Select the encryption option for each service based on data sensitivity, access needs, and the applicable policy. Amazon S3 now encrypts new objects by default with SSE-S3, but check existing objects and every other service explicitly; a bucket default does not retroactively change objects already stored.
Where you use customer-managed AWS KMS keys, restrict key use to the roles and services that need it, review key policies, and enable rotation when required by policy. KMS key rotation changes key material; it does not re-encrypt the data already protected by that key. Re-encrypt stored data separately when your security requirement calls for a new encryption key.
Require TLS for application and service traffic. A private AWS Direct Connect link is not encrypted in transit by default. If you use it, add an appropriate encryption layer such as TLS, an IPsec VPN, or MACsec on a supported connection; MACsec protects a specific link and does not provide end-to-end encryption across every network segment. See the AWS guidance for S3 default encryption, KMS key rotation, and encryption with Direct Connect.
Verify: retain encryption configuration for each store and copy, key-policy review, and a test showing that transfer paths use approved encryption. Ready when: every in-scope data store and transfer path has an owner, an approved protection method, and no unexplained plaintext exception.
2. Replace standing access with scoped roles
Federate workforce users through your identity provider, such as AWS IAM Identity Center, and grant access with permission sets or roles that issue temporary credentials. Use workload roles for applications and automation. Avoid creating IAM users with long-lived access keys for people; retain them only for a documented use case that cannot use federation or roles.
Apply least privilege, require MFA for human access (especially privileged access and the root user), and review who can assume each role. Separate migration operator, application, and break-glass permissions so temporary migration access can be removed without disrupting the workload. AWS recommends federation and temporary credentials for human users and roles for workloads in its IAM security best practices.
Verify: retain the human and workload identity map, role trust and permission policies, MFA coverage, and a test using representative users and workload roles. Review S3-specific access paths with this guide to Amazon S3 access management. Ready when: each identity has a business owner and only the permissions needed for its task, with unused credentials removed and emergency access tested.
3. Restrict and test network paths
Map required traffic between on-premises systems, migration tools, AWS services, and users. Put resources in subnets that match their exposure needs, keep databases and internal services off public routes when they do not need internet access, and review route tables, gateways, endpoints, DNS, and ingress and egress.
Use security groups as the primary resource-level control: they are stateful and allow traffic. Network ACLs are stateless subnet-level controls that allow or deny traffic; use them where subnet-wide guardrails are useful and account for return traffic explicitly. Enable VPC Flow Logs where they help investigate whether actual traffic matches the approved design. AWS explains the distinct roles of security groups, network ACLs, and VPC Flow Logs.
Verify: retain the reviewed network diagram and rule exports, then test required paths and expected denials from representative source locations. Ready when: every allowed path has a documented purpose and owner, and unapproved paths fail the connectivity test.
4. Assign compliance controls and evidence
List the legal, contractual, and internal requirements that apply to the workload, then map each control to its owner, implementation, and evidence. Check the scope and conditions of the AWS services and Regions you plan to use. Region selection can be part of a data-location decision, but it does not by itself make an application or organization compliant.
Under the AWS shared responsibility model, AWS protects the cloud infrastructure while customer duties depend on the services, data, and workload. AWS Artifact provides AWS compliance reports and other documents for review; they are evidence about AWS controls, not a certification of your particular workload. Have the responsible compliance or legal owner confirm which requirements and evidence apply. For more on shared controls across AWS and on-premises systems, see our hybrid cloud security and compliance guide.
Verify: retain the approved control matrix, data-location rationale, relevant AWS Artifact documents, and owner sign-off. Ready when: every applicable control has an accountable owner and a specific piece of evidence, and unresolved gaps have an explicit disposition before cutover.
5. Test recovery against RPO and RTO
Set a recovery point objective (RPO) for acceptable data loss and a recovery time objective (RTO) for acceptable service downtime for each workload. Choose backup frequency, retention, copies, and recovery design to meet those business targets. A successful backup job is not proof that the application can recover.
Restore selected backups into an isolated test environment. Check data integrity, dependencies, application behavior, access, and the operator runbook; record actual recovery time and the age of the recovered data. AWS recommends periodic recovery tests to confirm backups meet RPO and RTO. Its AWS Backup restore testing can help exercise restores, and our disaster recovery testing guide covers application-level validation.
Verify: retain the approved RPO/RTO, restore logs, data checks, and measured results. Ready when: an end-to-end restore meets the workload targets and a named operator can repeat it; otherwise adjust the design or obtain an explicit business decision before relying on it.
6. Secure application code and deployment
Include application dependencies, container images, infrastructure definitions, secrets, build permissions, and operating system patching in the migration review. Scan source and dependencies, prevent secrets from entering repositories or build output, review infrastructure changes, and test authentication and authorization paths in the deployed application.
Amazon Inspector checks software vulnerabilities in supported EC2 instances, ECR images, and Lambda functions; its EC2 scanning also assesses network exposure. Check the coverage of each scan type because the service does not assess every application or deployment risk. AWS WAF controls matching HTTP(S) requests to supported resources through a web ACL; it does not replace secure code, identity checks, patching, or application testing. See Amazon Inspector scan types and how AWS WAF works.
Verify: retain build and scan results, exception approvals, patch status, and tests for key application access paths. Ready when: findings that block release are fixed or explicitly accepted by the right owner, and application protections match the actual threats and supported resources.
7. Protect and reconcile data during transfer
Choose a transfer method based on data volume, available bandwidth, change rate, downtime window, and operating constraints. For AWS DataSync, checksum verification checks copied data during transfer and can perform additional comparison at the end of a run. For database moves with AWS Database Migration Service (AWS DMS), enable data validation only after checking that the source and target are supported; validation adds queries and time, requires a primary key or unique index for tables, and has other documented limits.
Do not base a 2026 plan on obsolete physical-transfer assumptions: AWS lists Snowmobile as shut down on March 14, 2024. Since November 7, 2025, Snowball Edge devices have been available only to existing customers. AWS directs new customers to DataSync for online transfers, AWS Data Transfer Terminal for physical transfers, or partner solutions. Confirm current eligibility and availability before selecting a transfer service. See the AWS DataSync verification options, DMS validation requirements and limits, service shutdown list, and Snow device availability notice. For DataSync run diagnosis, see our DataSync troubleshooting guide.
Compare source and target counts, checksums, database validation results, and application-level queries that matter to the workload. Maintain a manifest of transferred data and investigate skipped files, mismatches, unsupported objects, and records changed during replication; do not treat a successful transfer status as proof that the target is complete.
Verify: retain the transfer manifest and execution report, reconciliation results, DMS exceptions, and sign-off from the data owner. Ready when: all required data is accounted for, discrepancies are resolved or accepted, and the target passes representative application checks.
8. Separate audit, configuration, threat, and operations signals
Choose each service for the signal it provides and the response it enables:
- AWS CloudTrail records account activity and API actions. Trails and event data stores need deliberate retention and coverage choices; management events are recorded by default, while data events such as object-level activity are not all included by default.
- AWS Config records supported resource configuration history and evaluates configured rules.
- Amazon GuardDuty analyzes supported data sources for suspicious activity and produces security findings.
- Amazon Inspector scans supported workloads for software vulnerabilities and assesses EC2 network exposure.
- AWS Security Hub CSPM helps review posture checks and findings from integrated services.
- Amazon CloudWatch collects operational metrics and logs and supports alarms and dashboards.
Enable the coverage required in every account and Region in scope, configure retention to match your audit and investigation needs, and route actionable findings to a team that can respond. CloudWatch resource metrics alone are not an audit trail or a complete security detection plan.
Verify: retain a signal-coverage matrix, sample events or findings, retention settings, alert-routing details, and evidence that a test alert reached the right responder. Ready when: required activity is recorded, a detection signal is generated and delivered, and an owner knows how to triage it. For account-wide scanning and finding workflows, see our guide to Amazon Inspector and Security Hub.
9. Prepare and exercise incident response
Define who can declare an incident, who leads containment, who preserves evidence, how legal and communications teams are engaged, and how decisions are recorded. Prepare runbooks for likely migration risks such as exposed credentials, unintended public access, failed replication, suspicious API calls, or data exfiltration. Keep response access available even if normal identity systems or network paths are disrupted.
Run a tabletop or controlled technical exercise before cutover. Test how responders find the relevant CloudTrail events and security findings, disable or replace a compromised credential, isolate an affected resource without destroying evidence, and restore service safely. Record decisions, timing, missing permissions, and actions with named owners.
Verify: retain the current contact and escalation list, runbook version, exercise record, and closed or tracked follow-up actions. Ready when: an on-call responder can execute the first containment steps and reach the right decision-makers using the documented process.
10. Constrain third-party access and data handling
List vendors, migration tools, managed service providers, and software agents that can access AWS accounts or customer data. Record what data each receives, which systems it can reach, how long access is needed, how the vendor reports incidents, and how access and data are removed when the work ends.
For cross-account AWS access, prefer a narrowly scoped role over shared long-term credentials. Restrict its trust policy to the expected principal and require an external ID supplied for your customer relationship. An external ID helps address the confused deputy problem, but AWS does not treat it as a secret and it does not replace least privilege or vendor review. Log and periodically review role assumptions and revoke access when it is no longer needed. See AWS guidance on third-party role access and external IDs.
Verify: retain vendor and data-flow records, the approved trust and permission policies, sample access events, incident contacts, and an access-removal procedure. Ready when: every external identity has an accountable owner, a limited purpose and duration, monitored activity, and a tested revocation path.
FAQs
Does choosing an AWS Region make a migration compliant?
No. Region and service choices can help meet data-location and service-scope requirements, but compliance also depends on the workload, customer configuration, processes, evidence, and applicable obligations. Have the responsible compliance owner review the control matrix and supporting evidence.
Does a successful backup or transfer job prove the data is ready?
No. Restore a backup and validate that the application works within its RTO and RPO. After a migration transfer, reconcile the source and target and run application-level checks before cutover.