AWS Security ChangesHomeSearch

AWS solutions documentation change

Service: solutions · 2026-05-19 · Documentation low

File: solutions/latest/migration-assistant-for-amazon-opensearch-service/aws-well-architected-design-considerations.md

Summary

Updated Well-Architected design considerations: expanded supported migration sources/targets, added IRSA authentication, RFS improvements, EKS execution details, and sustainability enhancements

Security assessment

The change adds documentation for IRSA (IAM Roles for Service Accounts) implementation, which improves security by eliminating long-lived credentials. However, there's no evidence this addresses a specific security vulnerability. The IRSA documentation constitutes security feature documentation.

Diff

diff --git a/solutions/latest/migration-assistant-for-amazon-opensearch-service/aws-well-architected-design-considerations.md b/solutions/latest/migration-assistant-for-amazon-opensearch-service/aws-well-architected-design-considerations.md
index 2b50ac383..72da09014 100644
--- a//solutions/latest/migration-assistant-for-amazon-opensearch-service/aws-well-architected-design-considerations.md
+++ b//solutions/latest/migration-assistant-for-amazon-opensearch-service/aws-well-architected-design-considerations.md
@@ -19 +19,3 @@ This section describes how we architected this solution using the principles and
-  * The solution enables users to transition from legacy, self-managed OpenSearch and OpenSearch clusters to AWS OpenSearch, a managed service that significantly reduces the operational burden associated with maintaining outdated systems.
+  * The solution enables users to transition from legacy, self-managed Elasticsearch, OpenSearch, and Apache Solr clusters to Amazon OpenSearch Service and Amazon OpenSearch Serverless, managed services that significantly reduce the operational burden associated with maintaining outdated systems.
+
+  * Migrations are described once in workflow configuration and executed as Amazon EKS workloads with built-in approval gates, retry logic, and resumable backfill, which makes migrations repeatable and reduces operator guesswork.
@@ -28 +30,3 @@ This section describes how we architected this solution using the principles and
-  * The solution facilitates user migration to Amazon OpenSearch Service, which is regularly updated to uphold a strong security posture.
+  * The solution facilitates user migration to Amazon OpenSearch Service and Amazon OpenSearch Serverless, which are regularly updated to uphold a strong security posture.
+
+  * The Amazon EKS deployment uses [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) so the Migration Console pod and the Argo workflow executor pods authenticate to Amazon OpenSearch Service, Amazon OpenSearch Serverless, and other AWS services without long-lived credentials.
@@ -37 +41,3 @@ This section describes how we architected this solution using the principles and
-  * The solution introduces a lightweight proxy layer between the client and the source cluster to capture data reliably using Kafka. This ensures that requests can be replayed on the target cluster, with the flexibility to modify or resend any failed requests.
+  * The solution introduces a lightweight proxy layer between the client and the source cluster to capture data reliably using Apache Kafka. This ensures that requests can be replayed on the Amazon OpenSearch Service domain or Amazon OpenSearch Serverless collection, with the flexibility to modify or resend any failed requests.
+
+  * RFS tracks per-shard progress automatically; backfill resumes from the last checkpoint after a failure without restarting completed shards or duplicating documents.
@@ -47,0 +54,2 @@ This section describes how we architected this solution using the principles and
+  * RFS reads Lucene segment files directly from Amazon S3 snapshots, allowing massive parallelism (one worker per shard) without adding live load on the source cluster.
+
@@ -57 +65 @@ This section describes how we architected this solution using the principles and
-  * The solution operates on AWS Fargate within Elastic Container Service, ensuring cost-effectiveness as charges are incurred only for the duration that the containers are active.
+  * Migration workloads run as short-lived pods on Amazon EKS, ensuring cost-effectiveness as charges are incurred only for the duration that the pods are active.
@@ -59 +67 @@ This section describes how we architected this solution using the principles and
-  * For those interested in a preliminary local trial, a local version of the solution can be built and deployed in a user’s own environment before cloud implementation. Detailed instructions and resources for this are available at the OpenSearch Migrations GitHub repository: https://github.com/opensearch-project/opensearch-migrations.
+  * For those interested in a preliminary local trial, the solution can be evaluated on a local Kubernetes cluster before AWS implementation. The solution source code is available at the OpenSearch Migrations GitHub repository: https://github.com/opensearch-project/opensearch-migrations.
@@ -68 +76,3 @@ This section describes how we architected this solution using the principles and
-  * The solution allows customers to migrate their workloads to more environmentally friendly hardware, for example Graviton instance types.
+  * The solution allows customers to migrate their workloads to Amazon OpenSearch Service and Amazon OpenSearch Serverless on more environmentally friendly hardware, for example AWS Graviton instance types.
+
+  * Short-lived migration workers on Amazon EKS only consume compute, memory, and storage during active migration phases, reducing idle resource utilization.