Maintaining HIPAA compliance when migrating with AWS Transform MGN

Healthcare organizations migrating regulated workloads to AWS must maintain security and privacy controls at every phase, including replication, testing, and cutover, not just after workloads reach production. This post shows how to layer HIPAA controls onto the proven multi-account AWS Transform MGN (formerly AWS Application Migration Service) migration architecture using AWS Resource Access Manager, covering encrypted private replication, audit continuity, and evidence collection. 

Prerequisites 

• An executed AWS Business Associate Agreement (BAA) covering your AWS accounts 

• Working knowledge of AWS Transform MGN and the end-to-end cutover workflows 

• Familiarity with HIPAA Security Rule requirements for data in transit and at rest 

• AWS accounts configured with AWS Organizations (org-wide CloudTrail, RAM subnet sharing, Config conformance packs, Security Hub delegated admin) 

• Private connectivity from on-premises to AWS (Direct Connect or Site-to-Site VPN) 

The compliance gap in migration planning 

During an active migration, PHI traverses new pathways , from on-premises servers through replication channels into AWS staging environments. Each hop requires explicit controls: 

• Data in transit: TLS 1.2+ encryption over private network paths 

• Data at rest: Customer-managed AWS Key Management Service (AWS KMS) encryption for staging volumes,snapshots, and AMIs (provides independent key disable/delete and CloudTrail logging of key usage per §164.312(b)) 

• Access controls: Least-privilege migration roles with immediate revocation post-cutover 

• Audit continuity: Organization CloudTrail for all migration API activity (infrastructure), plus OS/database/application audit logs that survive the migration intact (data plane) — see Audit logging continuity 

The architecture in this post addresses each of these. 

Architecture overview 

The following figure shows the reference architecture for a HIPAA-eligible migration using AWS MGN with a multi-account structure and a shared staging VPC. 

Figure 1: HIPAA-eligible multi-account migration architecture with AWS Transform MGN by using Shared Staging VPC via AWS Resource Access Manager (AWS RAM) 

This architecture uses AWS Organizations with a Central Migration Account that owns the Shared Staging VPC and shares it to target accounts via AWS RAM, plus a separate Security/Log Archive Account for audit-integrity isolation. This is an established pattern (see Use AWS RAM and AWS MGN to Govern your Migration at Scale in AWS). This post layers HIPAA compliance controls on top. 

Multi-account structure 

Note: This account separation aligns with the AWS Security Reference Architecture (SRA) , migration operators cannot access audit evidence. If using AWS Control Tower, the Security/Log Archive Account maps to the Audit and Log Archive accounts, with the Organization Trail and Config aggregator pre-configured. 

Key design decisions for HIPAA compliance 

• Centralized replication: MGN replication managed from the Central Migration Account. Create the security group centrally (restricting TCP 1500 from the on-premises CIDR) and referenced in the replication template. Drift detected by HIPAA conformance pack rules and custom AWS Config rules. 

• Customer-managed KMS keys: Cross-account grants to target accounts for encrypt/decrypt, scoped via kms:ViaService. Provides independent key disable/delete and CloudTrail logging of key usage (§164.312(b)). Key rotation turned on; grants retired post-cutover. 

• Private replication: No public IP on replication servers; VPC interface endpoints for MGN data and control planes. 

• Account-level scope isolation: Production PHI in a separate account with separate IAM boundaries. Test cutovers happen in the Shared Staging VPC; validated workloads move to target workload VPCs. 

• Organization CloudTrail (SSE-KMS): Captures all infrastructure API activity across all accounts with log file validation turned on. 

• Security Hub + AWS Config: Security Hub delegated admin aggregates compliance findings. Config HIPAA conformance pack deployed organization-wide simultaneously. 

• Audit-integrity isolation: Evidence S3 in the Security/Log Archive Account, inaccessible to migration operators. SCPs prevent log tampering. 

• VPC Flow Logs: ALL traffic (accepted and rejected) delivered to centralized Evidence S3 bucket. 

Note: AWS Transform MGN is a HIPAA-eligible service. For a standard MGN rehost, the core services — EC2, EBS, and MGN — and supporting services (KMS, VPC, CloudTrail, Config, Security Hub, S3, IAM) are all HIPAA-eligible. If your migration introduces additional services, validate each against the HIPAA Eligible Services Reference. 

HIPAA controls bolted onto the existing RAM+MGN pattern 

Preventive guardrails (SCPs) 

Deploy the following Service Control Policies at the Organization level to prevent tampering with compliance infrastructure: 

• Deny cloudtrail:StopLogging and cloudtrail:DeleteTrail on the Organization trail 

• Deny config:DeleteConfigRule, config:DeleteConformancePack, config:StopConfigurationRecorder 

• Deny ec2:DeleteFlowLogs in the staging and workload VPCs 

• Deny ec2:CreateInternetGateway and ec2:AttachInternetGateway in the Central Migration Account (staging VPC must remain private) 
• Deny all ePHI-account actions when aws:MultiFactorAuthPresent is false (DenyWithoutMFA) — enforce MFA on all operator IAM identities during the migration window

These SCPs enforce that even privileged migration operators cannot disable audit controls during the migration window. 

AWS Config HIPAA conformance pack 

Deploy the AWS Config HIPAA conformance pack to continuously evaluate resources against HIPAA Security Rule requirements. 

Before you run the command, complete these one-time setup steps: 

1. Turn on AWS Config in each account with a configuration recorder and delivery channel. See Getting started with AWS Config. 
2. Designate a delegated administrator for organization-wide conformance packs. See Config in AWS Organizations. 
3. Download the Operational Best Practices for HIPAA Security sample template (this is the pre-built rule set) and upload it to an S3 bucket that AWS Config can read. 

Run the following command from the delegated administrator account (the Security/Log Archive Account in this architecture). It requires the config:PutOrganizationConformancePack permission: 

aws configservice put-organization-conformance-pack \ 
   --organization-conformance-pack-name hipaa-security-conformance-pack \ 
   --template-s3-uri s3://your-config-bucket/operational-best-practices-for-hipaa_security.yaml \ 
   --delivery-s3-bucket your-config-delivery-bucket

Key rules included in the pack: encrypted-volumes, cloud-trail-encryption-enabled, vpc-flow-logs-enabled, iam-user-mfa-enabled, s3-bucket-server-side-encryption-enabled. 

Using AWS Transform in the compliance workflow 

With the compliant architecture established, assess your workloads before replication. AWS Transform assessments, the assessment and EC2 right-sizing tool separate from AWS Transform MGN, provides cloud-based business case and right-sizing recommendations for the migration planning phase. 

Important: AWS Transform assessments is a Total Cost of Ownership (TCO) and EC2 right-sizing tool. Although it is a HIPAA-eligible service, it does not natively identify HIPAA-eligible target services or flag non-eligible recommendations, so the cross-reference in Step 2 is manual. Its discovery tool collects inventory, configuration, and performance metadata, not the data stored on your servers. 

Step 1: Run the Transform assessment 

Run the assessment to identify recommended target EC2 instance types, storage configurations, and AWS services for your workloads. 

Step 2: Cross-reference against HIPAA-eligible services 

Compare the Transform output against the AWS HIPAA Eligible Services. For a standard MGN rehost, the core services (EC2, EBS) are HIPAA-eligible. 

Deep dive: HIPAA compliance during active replication and cutover 

This section covers maintaining compliance during the active migration. 

Replication configuration : Configure AWS MGN replication with the following HIPAA controls

• Encryption in transit: 

Replication traffic uses TLS 1.2 with PFS (ECDHE cipher suites), and MGN control plane API calls use HTTPS (port 443). See AWS MGN Infrastructure Security. 

• Encryption at rest: 

Configure EBS encryption for all replication volumes by specifying a customer-managed KMS key ARN in AWS MGN replication settings. 

• Private replication (no public IP): 

Configure AWS MGN to route replication data over private IP and disable public IP assignment on replication servers. This requires VPC interface endpoints in the Shared Staging VPC: 

Note: Replace <region> with your migration Region (for example, us-east-1). The ec2.<region>.amazonaws.com value scopes this key to Amazon EC2 usage only. Each interface endpoint requires a security group allowing HTTPS (443) from the staging subnet CIDR. 

• Network isolation: 

Create the replication security group in the Central Migration Account (restricting inbound TCP 1500 from the on-premises CIDR) and share it to target accounts via AWS RAM. Replication servers launched in each target account attach this shared security group to as specified in the MGN replication template. 

aws ec2 create-security-group \ 
   --group-name mgn-replication-sg-hipaa \ 
   --description "MGN replication - TCP 1500 from on-premises only" \ 
   --vpc-id vpc-xxxxxxxxx \ 
   --tag-specifications 'ResourceType=security-group,Tags=[{Key=Name,Value=mgn-replication-sg-hipaa}]' 
 
aws ec2 authorize-security-group-ingress \ 
   --group-id sg-xxxxxxxxx \ 
   --protocol tcp \ 
   --port 1500 \ 
   --cidr 10.1.0.0/24 

Cross-account KMS key policy: 

The following key policy (applied in the Central Migration Account) grants encrypt/decrypt permissions to target accounts, scoped to EC2/EBS usage via the kms:ViaService and kms:GrantIsForAWSResource conditions: 

{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Sid": "AllowCentralAccountAdministration",
       "Effect": "Allow",
       "Principal": { "AWS": "arn:aws:iam::111111111111:root" },
       "Action": "kms:*",
       "Resource": "*"
     },
     {
       "Sid": "AllowProductionAccountUsage",
       "Effect": "Allow",
       "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
       "Action": [
         "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*",
         "kms:GenerateDataKey*", "kms:DescribeKey", "kms:CreateGrant"
       ],
       "Resource": "*",
       "Condition": {
         "StringEquals": {
           "kms:ViaService": "ec2.<region>.amazonaws.com"
         },
         "Bool": { "kms:GrantIsForAWSResource": "true" }
       }
     },
     {
       "Sid": "AllowNonProductionAccountUsage",
       "Effect": "Allow",
       "Principal": { "AWS": "arn:aws:iam::333333333333:root" },
       "Action": [
         "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*",
         "kms:GenerateDataKey*", "kms:DescribeKey", "kms:CreateGrant"
       ],
       "Resource": "*",
       "Condition": {
         "StringEquals": {
           "kms:ViaService": "ec2.<region>.amazonaws.com"
         },
         "Bool": { "kms:GrantIsForAWSResource": "true" }
       }
     }
   ]
} 

Note: Replace <region> with your migration Region (the ec2.<region>.amazonaws.com value scopes this key to Amazon EC2 usage). Enable automatic key rotation. Post-cutover, retire KMS grants issued to MGN service roles using kms:RevokeGrant. The kms:ViaService condition in the policy restricts usage to Amazon EC2, so the grant cannot be misused for arbitrary decryption of other resources. See Using a CMK with MGN and Cross-account KMS key policy. 

Full replication configuration template: 

The following CLI creates the replication configuration template with all required parameters for private, encrypted replication: 

aws mgn create-replication-configuration-template \
   --region us-east-1 \
   --staging-area-subnet-id subnet-0abc123def456 \
   --replication-servers-security-groups-ids sg-0abc123def456 \
   --replication-server-instance-type t3.small \
   --use-dedicated-replication-server false \
   --default-large-staging-disk-type GP3 \
   --ebs-encryption CUSTOM \
   --ebs-encryption-key-arn arn:aws:kms:us-east-1:111111111111:key/cmk-example-key-id \
   --bandwidth-throttling 0 \
   --data-plane-routing PRIVATE_IP \
   --create-public-ip false \
   --associate-default-security-group false \
   --tags "Key=compliance,Value=hipaa" 

Note: –data-plane-routing PRIVATE_IP and –create-public-ip false are essential for HIPAA. Without them, replication servers receive public IPs and attempt to route data over the internet. The configuration intent must be explicit. See MGN replication server settings. 

Testing: MGN test instances contain real PHI 

Critical understanding: AWS MGN performs block-level replication. A test cutover instance is a byte-for-byte copy of the source server. It contains full production PHI. Test instances require production-equivalent compliance controls. 

Required controls for AWS MGN test instances: 

• Encrypted with customer-managed KMS key (inherited from replication configuration) 
• No public IP; launched in the Shared Staging VPC private subnet 
• Full CloudTrail and VPC Flow Log coverage 
• Restricted IAM access : Only migration operators should have access, with time-limited sessions. 
• Short lifetime : Terminate test instances immediately after validation; do not leave them running 

PHI masking is NOT applicable to AWS MGN test instances. Masking tools (Amazon Comprehend Medical, AWS Glue DataBrew, Amazon Macie and AWS Lake Formation) operate on data pipelines, not on replicated EBS volumes. If your testing requires non-PHI data, maintain a separate synthetic test environment generated outside the MGN replication flow. Do not attempt to mask data on a live AWS MGN test instance. See Common techniques to detect PHI and PII data using AWS Services. 

IAM roles: service-managed vs. operator-facing 

AWS MGN IAM roles fall into two categories with different post-cutover actions: 

Immediate revocation is the recommended approach: detach operator-facing policies (e.g., AWSApplicationMigrationFullAccess) and revoke KMS grants the moment cutover is confirmed. See detach-role-policy and revoke-grant. 

For details on AWS MGN IAM policies, see AWSApplicationMigrationReplicationServerPolicy. 

Audit logging continuity 

HIPAA §164.312(b) requires audit controls on systems containing ePHI. For rehosted workloads, you address this at two distinct layers: 

Before migration: Verify source servers have OS/database audit logging shipping to a central destination. Use the Amazon CloudWatch agent, Windows Event Forwarding, Linux auditd, or database-native audit. 

During migration: Install the CloudWatch agent (or equivalent) on source servers before the MGN agent so it replicates with the disk image and continues logging on the target without a gap. 

Post-migration: Verify log flow resumes on target instances (check the CloudWatch Log Group for the migrated instance ID). 

Cutover: maintaining audit continuity and planning for rollback 

The cutover window is the highest-risk period. Before declaring cutover complete, verify: 

• Organization CloudTrail trail is actively logging (control plane coverage) 
• VPC Flow Logs confirm traffic shifted to the target workload VPC (data plane coverage) 
• AWS Config conformance pack shows no NON_COMPLIANT rules 
• Revoke operator-facing IAM migration roles 

Rollback planning: Before AWS MGN finalization, replication continues and you can revert DNS to on-premises at any time. Lower DNS TTLs to 60 seconds 24-48 hours before cutover to enable rapid failback. Document rollback criteria and decision authority before cutover begins. 

Post-migration compliance validation 

After cutover, validate the compliance controls established pre-migration and confirm backup/DR to satisfy HIPAA contingency planning requirements. 

Validate Config compliance 

The conformance pack (deployed pre-migration) continuously evaluates resources against HIPAA Security Rule requirements. After cutover, confirm no resources are non-compliant: 

aws configservice get-conformance-pack-compliance-details \
   --conformance-pack-name hipaa-security-conformance-pack \
   --filters '{"ComplianceType": "NON_COMPLIANT"}' 

AWS Security Hub with NIST SP 800-53 Rev. 5 

AWS Security Hub does not have a native “HIPAA security standard.” For HIPAA compliance, enable NIST SP 800-53 Rev. 5, the closest proxy to the HIPAA Security Rule technical safeguards, combined with the AWS Config HIPAA conformance pack. 

Before running this command, turn on Security Hub and set the delegated administrator for your organization. See Setting up AWS Security Hub and Designating a Security Hub administrator account. Run the following from the Security/Log Archive Account (the delegated administrator); it requires the securityhub:BatchEnableStandards permission 

Turn on NIST 800-53 in Security Hub: 

aws securityhub batch-enable-standards \
   --standards-subscription-requests \
   '[{"StandardsArn": "arn:aws:securityhub:us-east-1::standards/nist-800-53/v/5.0.0"}]' 

Security Hub aggregates findings from Config rules, Amazon GuardDuty, and other integrated services, giving you a consolidated compliance view. This Config-to-Security Hub pattern is described in Monitor, Alert, Remediate HIPAA Findings on AWS. 

Alerting: Configure Amazon EventBridge to route CRITICAL Security Hub findings to Amazon SNS during the migration window for immediate operator notification. 

VPC Flow Logs implementation 

Enable VPC Flow Logs in all VPCs capturing ALL traffic (accepted + rejected) with delivery to the centralized Evidence S3 bucket in the Security/Log Archive Account. HIPAA §164.316(b)(2)(i) requires 6-year retention — consider S3 Lifecycle policies to Glacier after 90 days. 

For implementation guidance, see APG: Configure VPC Flow Logs for centralization across AWS accounts. 

Post-migration backup and disaster recovery 

HIPAA §164.308(a)(7) requires a contingency plan including data backup, disaster recovery, and emergency mode operation. A newly rehosted workload has no backup regime on day one unless you configure it. 

Recommended approach: 

• AWS Backup with a CMK-encrypted vault and vault lock (compliance mode, immutable retention) 
• Cross-account and cross-Region backup copies for disaster recovery 
• Backup plan targeting all EBS volumes tagged with the migration identifier 

Configure AWS Backup in each target account immediately post-cutover. Do not leave newly migrated workloads unprotected. 

Evidence collection for auditors 

The Evidence S3 bucket must be integrity-protected:

• S3 Object Lock (compliance mode), versioning, SSE-KMS encryption, and access logging turned on 
• Bucket policy denying s3:DeleteObject and s3:PutBucketPolicy from all principals except the Security account root 

Artifact-to-HIPAA-control mapping: 

Cleaning up

After cutover is confirmed, decommission migration-only resources while retaining compliance infrastructure.

Retain:

• Organization CloudTrail, AWS Config conformance pack, Security Hub delegated admin
• Evidence S3 bucket (Object Lock, versioning, deny-delete policy)
• VPC Flow Logs and AWS Backup vaults in all workload account

Decommission:

• Shared Staging VPC (subnets, route tables, VPC endpoints)
• MGN replication configuration templates and replication server security groups
• Operator-facing IAM migration roles and custom cross-account KMS grants (kms:RevokeGrant)
• AWS RAM resource shares for staging subnets
• Test cutover instances and associated EBS snapshots

How is evidence provided to auditors? 

Grant auditors read-only access to the Evidence S3 bucket via a dedicated cross-account IAM role. For continuous evidence collection, use AWS Security Hub combined with an Amazon EventBridge → S3 pipeline to archive CRITICAL findings as durable evidence artifacts

Conclusion and next steps 

Migrating HIPAA-regulated workloads to AWS doesn’t require choosing between speed and compliance. The pattern in this post layers HIPAA controls onto the proven multi-account AWS MGN migration architecture using AWS RAM. It provides controls and evidence to help support PHI compliance across the replication, testing, and cutover phases. 

To get started, execute your AWS BAA and deploy the multi-account structure described in this post, then work through the pre-migration checklist that follows. 

Pre-migration checklist: 

• BAA executed; all services validated against the HIPAA Eligible Services list 
• Multi-account structure deployed (Security/Log Archive, Central Migration, Non-Production, Production) 
• Customer-managed KMS keys configured with cross-account grants and rotation turned on 
• Staging VPC: no IGW, VPC endpoints for MGN/EC2/S3; replication template with –data-plane-routing PRIVATE_IP, –create-public-ip false 
• Organization CloudTrail active (SSE-KMS, log file validation) with SCPs preventing tampering 
• VPC Flow Logs turned on in all VPCs with centralized delivery to Evidence S3 
• Config HIPAA conformance pack + NIST 800-53 Rev. 5 in Security Hub deployed pre-migration 
• OS/database audit logging verified on source servers (CloudWatch agent installed pre-migration) 
• Operator-facing IAM roles identified for immediate post-cutover revocation 
• MFA enforced on all operator IAM identities via DenyWithoutMFA SCP
• Rollback criteria defined with DNS TTL strategy 
• AWS Backup plan configured for post-migration workloads 
• Evidence S3 bucket configured (Object Lock, versioning, deny-delete) with collection plan documented 

Related resources  

• HIPAA Security Rule on AWS: Technical Safeguards Implementation and Readiness Guidance
• AWS Security Reference Architecture (SRA) 
• AWS HIPAA Eligible Services Reference 
• Use AWS RAM and AWS MGN to Govern your Migration at Scale in AWS 
• APG: Connect to MGN data and control planes over a private network 
• HIPAA Omnibus Final Rule 
• AWS Prescriptive Guidance: Secure Migrations Framework 
• AWS Transform MGN Documentation 
• AWS BAA Process