AWS solutions documentation change
Summary
Added details about Migration Assistant 3.0 architecture layers (control plane and data plane) and updated migration process steps with more technical specifics about traffic routing, Kafka usage, RFS workflow, validation methods, and cutover procedures.
Security assessment
The changes are architectural and procedural enhancements without any mention of security vulnerabilities, patches, or security incidents. Updates focus on operational workflow improvements (EKS deployment layers, Kafka usage, RFS process) without addressing authentication, authorization, encryption, or vulnerability mitigations.
Diff
diff --git a/solutions/latest/migration-assistant-for-amazon-opensearch-service/architecture-overview.md b/solutions/latest/migration-assistant-for-amazon-opensearch-service/architecture-overview.md index 70697eb3e..3c48b9482 100644 --- a//solutions/latest/migration-assistant-for-amazon-opensearch-service/architecture-overview.md +++ b//solutions/latest/migration-assistant-for-amazon-opensearch-service/architecture-overview.md @@ -24,0 +25,9 @@ AWS CloudFormation resources are created from AWS Cloud Development Kit (AWS CDK +Migration Assistant 3.0 deploys to Amazon Elastic Kubernetes Service (Amazon EKS). The solution has two layers: + + * A **control plane** that manages migration workflows. It includes the Migration Console pod, the Workflow CLI, and the Argo Workflows engine that sequences tasks, retries failures, and tracks state. + + * A **data plane** that performs the actual snapshot, metadata, backfill, capture, and replay work. It includes Reindex-from-Snapshot (RFS) workers, the Capture Proxy, the Traffic Replayer, and Strimzi-managed Apache Kafka for capture and replay. + + + + @@ -27 +36 @@ The high-level process flow for the solution components deployed with the AWS Cl - 1. Client traffic is directed to the existing cluster. + 1. **Client traffic is directed to the existing source cluster.** For zero-downtime migrations, a Kubernetes Service backed by an [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) or [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) routes traffic through the capture proxy fleet, which forwards requests to the source while simultaneously recording them. For backfill-only migrations, this step is skipped. @@ -29 +38 @@ The high-level process flow for the solution components deployed with the AWS Cl - 2. An [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) is positioned in front of the traffic capture proxy to route traffic as needed. The Application Load Balancer forwards traffic to the capture proxy, which then relays it to the source while simultaneously replicating the traffic to [Amazon Managed Streaming for Apache Kafka](https://aws.amazon.com/msk) (Amazon MSK). + 2. **The capture proxy replicates traffic to Apache Kafka.** The capture proxy relays traffic to the source cluster and simultaneously replicates the raw request/response streams to Apache Kafka, managed by Strimzi on Amazon EKS. This provides a durable record of all writes during the migration window. @@ -31 +40 @@ The high-level process flow for the solution components deployed with the AWS Cl - 3. With continuous traffic capture in place, a Reindex-from-Snapshot (RFS) is initiated by the user through the Migration Management Console. + 3. **Snapshot and backfill via Reindex-from-Snapshot.** With continuous traffic capture in place (or after pausing writes), the user submits a migration workflow from the Migration Console using the Workflow CLI. The workflow creates a point-in-time snapshot of the source cluster in [Amazon Simple Storage Service](https://aws.amazon.com/s3) (Amazon S3), migrates metadata (indexes, templates, aliases) to the Amazon OpenSearch Service domain or Amazon OpenSearch Serverless collection, and then launches RFS workers that read directly from the snapshot in Amazon S3 and bulk-index documents into the target. @@ -33 +42 @@ The high-level process flow for the solution components deployed with the AWS Cl - 4. After a backfill has been completed, the captured traffic is replayed by the user with a Traffic Replayer. + 4. **Traffic Replayer catches up the target.** After the backfill completes, the Traffic Replayer reads captured traffic from Apache Kafka and replays it against the Amazon OpenSearch Service domain or Amazon OpenSearch Serverless collection, transforming requests as needed (authentication, index names). The replayer catches the target up to real-time, closing the gap between the snapshot point-in-time and the current state. @@ -35 +44 @@ The high-level process flow for the solution components deployed with the AWS Cl - 5. The performance and behavior of traffic routed to the source and target clusters are analyzed by reviewing relevant logs and metrics. + 5. **Validate and compare.** The performance and behavior of traffic routed to the source and target clusters are analyzed by reviewing logs, metrics, and document counts in [Amazon CloudWatch](https://aws.amazon.com/cloudwatch), and by running comparison queries from the Migration Console. @@ -37 +46 @@ The high-level process flow for the solution components deployed with the AWS Cl - 6. After confirming the target cluster’s functionality meets expectations, the user redirects clients to the new target. Additionally, the user can retire and discard the old cluster’s infrastructure. + 6. **Redirect traffic and decommission.** After confirming the target cluster’s functionality meets expectations, the user redirects clients to the new Amazon OpenSearch Service domain or Amazon OpenSearch Serverless collection by updating DNS records, load balancer configuration, or application connection strings. The user keeps the source cluster available as a fallback during a rollback window, then decommissions the source and removes Migration Assistant infrastructure.