An AWS migration does not make an application compliant by itself. Compliance depends on which legal, contractual, and internal requirements apply, what data and services are in scope, and whether the controls work during transfer, cutover, and ongoing operations.

  • Determine applicable requirements before choosing Regions or services.
  • Map each requirement to an owner, a control, and evidence you can verify.
  • Test the migration path and keep monitoring after cutover.

AWS publishes assurance reports for specific programs and services and offers tools that can support compliance. Your organization remains responsible for how it uses and configures those services and for evaluating its own control evidence.

Scope compliance before the migration

Set the compliance boundary before selecting a migration wave. Include the source environment, AWS accounts and Regions, applications, data stores, copies made for migration, and the people or vendors that can access them. Compliance requirements apply to a system and its use, not to an AWS account or service name in isolation.

Map the requirements that apply

Ask the owners of privacy, security, legal, and business controls to identify the laws, contracts, and internal policies that cover the workload. Applicability can depend on the organization, its activities, the people whose data it processes, the data type, customer commitments, and the services involved.

For example, the GDPR applies to processing in the context of an establishment in the EU, even when processing takes place elsewhere. It can also apply to organizations outside the EU when they offer goods or services to people in the EU or monitor their behavior there; its scope is not limited to EU citizens. Transfers of personal data to third countries outside the European Economic Area (EEA) are addressed separately in Chapter V, which provides for permitted transfer mechanisms and safeguards. The regulation does not create a blanket rule that all EU personal data must stay in an EU Region. A national law, sector rule, contract, or regulator may set additional location requirements, so have the responsible compliance or legal owner assess the actual case. See the official GDPR text and the European Commission's guidance on international data transfers.

For a U.S. workload involving electronic protected health information (ePHI), determine whether HIPAA applies to your organization and service providers. HHS explains that a cloud service provider can be a business associate when it creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate. Confirm the required business associate agreement, risk analysis, safeguards, and AWS service eligibility for the workload; AWS eligibility does not by itself make the workload compliant. See HHS guidance on HIPAA and cloud computing and the current AWS HIPAA Eligible Services Reference.

Under AWS's shared responsibility model, AWS protects the infrastructure that runs its services, while customer responsibilities depend on the service and workload. Customers manage the guest operating system and application software on Amazon EC2. With more abstracted services, AWS operates more of the platform, but customers still manage their data, permissions, and service configuration. Map each control to the party that operates it.

AWS Artifact provides AWS security and compliance documents that can support an audit or help evaluate AWS-operated controls. Those reports do not show that your application is compliant: AWS notes that customers must develop or obtain documents about their own security and compliance. Treat Artifact documents as one evidence source alongside your workload configuration, processes, and test results.

Classify data and map its flows

Inventory personal information, health information, payment card data, financial records, credentials, and other confidential data. Trace each category from its source through the application, migration tooling, target services, and consumers. Include temporary exports, staging buckets, replicas, snapshots, backups, logs, caches, and test environments; these copies can fall within the same control boundary as production data.

Document application dependencies and trust boundaries so related systems are not separated in a way that bypasses access, logging, or retention controls. Amazon Macie can help discover sensitive data in eligible Amazon S3 objects, but it does not inventory every data store or map every application flow. Check its analysis scope and coverage, then use source-system inventories and data owners to fill the gaps. See how Macie automated sensitive data discovery works.

Build a control and evidence checklist

Translate each requirement into a migration check. For every control, record:

  • the requirement, system boundary, data, and migration stages it covers;
  • the owner and whether the control is operated by your organization, AWS, or another provider;
  • the configuration or process that implements it, plus how it will be tested;
  • the evidence to retain, its required retention period, and who reviews it; and
  • any gap, compensating control, approver, and date when the exception must be reviewed.

Use our AWS migration security checklist to organize practical checks for encryption, access, network paths, recovery, data reconciliation, monitoring, incident response, and third-party access.

Choose and sequence the migration carefully

Choose the migration approach around control gaps

Rehosting, replatforming, and refactoring are technical migration approaches, not compliance levels. Rehosting can preserve application behavior and its existing control gaps. Replatforming or refactoring may change identity flows, data paths, operational duties, and the AWS services in scope. For each approach, identify which controls carry over, which need to be redesigned, and how the result will be tested before cutover.

Do not treat a fast migration as compliant because its destination is an AWS service, or assume a larger redesign automatically improves compliance. If a required control cannot be completed before cutover, document the exposure, interim protection, decision owner, and deadline for closing the gap.

Prioritize systems by risk and dependency

Sequence migration waves using data sensitivity, business impact, control readiness, technical dependencies, and recovery options. A development system is not automatically low risk if it contains production data or credentials. Start with a representative workload whose controls can be tested, and bring dependent systems into the same plan when their data flows cross a compliance boundary.

Set a cutover gate for each wave: required controls are implemented, evidence is available, transfer results are reconciled, recovery has been exercised, and unresolved exceptions have an explicit decision from the right owner.

Check AWS service scope and configuration

Review the current AWS services in scope by compliance program for the specific standard or assurance report you rely on. Scope can differ by program and may include feature exclusions. An AWS service appearing in a report describes AWS's assessed controls; it does not approve your architecture or establish that your use of the service satisfies a law, contract, or audit requirement.

Check service documentation for the controls you must configure. Encryption, backups, data retention, logging, and access behavior vary by service and by option. Record which configuration implements each requirement and verify it on the resources used in the migration.

Design for data location, access, and protection

Set data location and network boundaries

Choose AWS Regions from the applicable data-location rules, customer commitments, service availability, and recovery design. Review each service's behavior and the location of migration copies, replicas, backups, logs, and disaster recovery environments. Availability Zones are locations within a Region; using more than one can improve resilience but does not create a separate country or regulatory boundary.

Use account structure, network segmentation, and service-specific controls to limit where resources can be created and where data can move. The IAM condition key aws:RequestedRegion controls which service endpoint a request invokes; AWS documents that it does not control the operation's full impact, and some operations can affect resources in other Regions. For example, an S3 replication configuration can copy objects across Regions. Treat a Region policy as one guardrail and separately review resource location, replication, and service-specific settings. See the AWS documentation for global condition keys.

Configure encryption and workforce access

Define encryption requirements from the data classification and applicable controls. Check the at-rest options for each data store, backup, snapshot, and migration copy, and restrict the identities that can use or administer encryption keys. At-rest encryption does not replace access control or protect data after an authorized principal decrypts it.

Require encrypted connections for sensitive transfers and application traffic, and verify TLS at each endpoint. A certificate service can issue certificates, but the endpoint still needs a secure protocol policy and applications must validate certificates correctly. AWS's data-in-transit guidance describes protections for connections between users, services, and on-premises systems.

Federate workforce access through an identity provider and grant least-privilege roles with temporary sessions. AWS IAM Identity Center, formerly called AWS Single Sign-On, can manage access to AWS accounts. If users authenticate through an external identity provider, that provider manages MFA; configure and verify MFA at the identity source. IAM Identity Center can manage MFA for supported identity sources that it controls. See what IAM Identity Center provides and its MFA configuration guidance. Use separate workload roles for applications, review privileged access, and maintain a monitored emergency access procedure.

For migrations with on-premises systems, also review identity, network, encryption, and evidence boundaries in our hybrid cloud security and compliance guide.

Automate checks with clear limits

AWS Config can record changes for supported resource types and evaluate rules against the resources in its configured scope. Enable recording for the relevant accounts and Regions, choose the resource types to track, and confirm each rule evaluates the resources you intend to check. A Config result is evidence about the rule and resources covered, not a complete assessment of a legal framework.

AWS Security Hub Cloud Security Posture Management (Security Hub CSPM) runs checks for supported security controls and can consolidate findings. Configure its coverage and prerequisites, including AWS Config recording where required. Its findings can help identify configuration gaps, but a control pass or security score is not a compliance attestation. See the AWS guidance for AWS Config resource recording and Security Hub CSPM.

Monitor controls and retain evidence after migration

Collect the audit events you need

Configure AWS CloudTrail for the accounts and Regions in scope, with retention and access protections that match investigation and audit needs. CloudTrail trails log management events by default, but data events such as access to S3 objects are not included by default; select the data events required for your workload and account for their cost. CloudTrail records AWS activity, so collect corresponding application, identity-provider, network, and on-premises logs when they are part of the control. See CloudTrail event types and logging behavior.

Route Config and Security Hub findings to named owners. Use automated remediation only for understood actions that have been tested against representative resources and can be reversed or safely contained. Review alert routing and log access with a test event rather than assuming that enabled services are delivering evidence to responders.

Review control drift and remediation

When a finding appears, determine whether it represents a real control gap, a resource outside the intended scope, or an incomplete evaluation. Correct the issue at its source, verify the control again, and record who approved any exception. Avoid automatic deletion or isolation actions unless their effect, authority, and recovery path have been tested.

Review evidence against the requirement

Build an evidence set for each requirement from the configuration, policy, process, event records, access review, restore test, or migration reconciliation that demonstrates how the control operates. Preserve dates, owners, scope, exceptions, and test results so an auditor can assess the evidence in context. Review evidence and resource coverage when the workload, service, Region, data flow, or responsible provider changes.

Use AWS Artifact reports for AWS-operated controls, then add evidence for your own configurations, people, applications, and processes. Automated checks can help with monitoring, but the responsible compliance owner must evaluate whether the full evidence set meets the applicable requirement.

Prepare a cutover decision

Before each migration wave, confirm that the data and system boundary is documented, every applicable control has an owner, and the chosen services and locations have been reviewed. Test access, encryption, transfer completeness, alert delivery, restore procedures, and rollback steps using the actual workload.

Keep a record of accepted gaps and the decisions that justify proceeding. After cutover, continue the same control reviews against the live environment and update the evidence when the architecture or obligations change.

FAQs

Does migrating to AWS make an application compliant?

No. AWS publishes assurance evidence for assessed infrastructure and services and offers tools, but your organization must determine applicable requirements, configure the services it uses, operate its controls, and assess evidence for the workload.

Does GDPR require EU personal data to stay in an EU AWS Region?

GDPR does not create a blanket EU-only hosting rule. Its territorial scope and rules for transfers to third countries are separate questions. Other laws, contracts, or sector requirements may impose data-location restrictions.

Do AWS Config or Security Hub CSPM prove compliance?

No. They can provide findings about supported AWS resources and configured checks. Assess their coverage and use their results as evidence inputs alongside the controls and records for your full system.