AWS prescriptive-guidance documentation change
Summary
Updated documentation links, corrected service names (e.g., 'Amazon Data Firehose' to 'Amazon Kinesis Data Firehose'), fixed minor grammatical issues, and adjusted section formatting (bold headers to markdown subheadings).
Security assessment
The changes are primarily editorial (link updates, naming corrections, grammar fixes) and structural (formatting headers). No explicit security vulnerabilities, mitigations, or new security features are introduced. The mention of 'secure way to ingest' in the Kinesis Data Firehose section is not new and does not address a specific security issue.
Diff
diff --git a/prescriptive-guidance/latest/opensearch-service-migration/data-flow.md b/prescriptive-guidance/latest/opensearch-service-migration/data-flow.md index 393bcccb2..f267fac58 100644 --- a//prescriptive-guidance/latest/opensearch-service-migration/data-flow.md +++ b//prescriptive-guidance/latest/opensearch-service-migration/data-flow.md @@ -26 +26 @@ Data ingestion focuses on how to get data into your Amazon OpenSearch Service do -There are many different ways to create or modernize your ingestion design. There are many open-source tools for building a self-managed ingestion pipeline. OpenSearch Service supports integration with [Fluentd](https://www.fluentd.org/), [Logstash](https://github.com/opensearch-project/logstash-output-opensearch), or [OpenSearch Data Prepper](https://docs.opensearch.org/latest/data-prepper/). These tools are popular with most log analytics solutions developers. You can deploy these tools on an Amazon EC2 instance, on Amazon Elastic Kubernetes Service (Amazon EKS), or on premises. Both Logstash and Fluentd support Amazon OpenSearch Service domains as an output destination. However, this will require you to maintain, patch, test, and keep the Fluentd or Logstash software versions up to date. +There are many different ways to create or modernize your ingestion design. There are many open-source tools for building a self-managed ingestion pipeline. OpenSearch Service supports integration with [Fluentd](https://www.fluentd.org/), [Logstash](https://github.com/opensearch-project/logstash-output-opensearch), or [OpenSearch Data Prepper](https://opensearch.org/docs/latest/data-prepper/index/). These tools are popular with most log analytics solutions developers. You can deploy these tools on an Amazon EC2 instance, on Amazon Elastic Kubernetes Service (Amazon EKS), or on premises. Both Logstash and Fluentd support Amazon OpenSearch Service domains as an output destination. However, this will require you to maintain, patch, test, and keep the Fluentd or Logstash software versions up to date. @@ -28 +28 @@ There are many different ways to create or modernize your ingestion design. Ther -To reduce your operational overhead, you can use one of the AWS managed services that support integration with Amazon OpenSearch Service. For example, [Amazon OpenSearch Ingestion](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ingestion.html) is a fully managed, serverless data collector that delivers real-time log, metric, and trace data to Amazon OpenSearch Service domains. With OpenSearch Ingestion, you no longer need to use third-party solutions such as Logstash or [Jaeger](https://www.jaegertracing.io/) to ingest data into your OpenSearch Service domains. You configure your data producers to send data to OpenSearch Ingestion. Then, it automatically delivers the data to the domain or collection that you specify. You can also configure OpenSearch Ingestion to transform your data before delivering it. +To reduce your operational overhead, you can use one of the AWS managed services that support integration with Amazon OpenSearch Service. For example, [Amazon OpenSearch Ingestion](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ingestion.html) is a fully managed, serverless data collector that delivers real-time log, metric, and trace data to Amazon OpenSearch Service domains. With OpenSearch Ingestion, you no longer need to use third-party solutions like Logstash or [Jaeger](https://www.jaegertracing.io/) to ingest data into your OpenSearch Service domains. You configure your data producers to send data to OpenSearch Ingestion. Then, it automatically delivers the data to the domain or collection that you specify. You can also configure OpenSearch Ingestion to transform your data before delivering it. @@ -30 +30 @@ To reduce your operational overhead, you can use one of the AWS managed services -Another option is [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html), which is a fully managed service that helps build a serverless ingestion pipeline. Firehose provides a secure way to ingest, transform, and [deliver streaming data to Amazon OpenSearch Service domains](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html). It can automatically scale to match the throughput of your data, and it requires no ongoing administration. Firehose can also transform incoming records by using AWS Lambda, compress, and batch the data before loading it into your OpenSearch Service domain. +Another option is [Amazon Kinesis Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html), which is a fully managed service that helps build a serverless ingestion pipeline. Kinesis Data Firehose provides a secure way to ingest, transform, and [deliver streaming data to Amazon OpenSearch Service domains](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/integrations.html). It can automatically scale to match the throughput of your data, and it requires no ongoing administration. Kinesis Data Firehose can also transform incoming records by using AWS Lambda, compress, and batch the data before loading it into your OpenSearch Service domain. @@ -38 +38 @@ Migration planning is a good time to assess whether your current ingestion pipel -When planning for data ingestion and storage, be sure to plan and agree on data retention. For log analytics use cases, it's critical that you have the right policies created within your domain to retire the historic data. When you are moving from an existing on-premises and cloud VM based architecture, you could be using a particular type of instance for all your data nodes. Data nodes have same CPU, memory, and storage profile. Most customers would configure high throughput storage to cater to their high-speed indexing requirement. This singular storage profile architecture is called _hot node only_ architecture, or hot-only. Hot-only architecture couples storage with compute, which implies that you need to add compute nodes if your storage requirement increases. +When planning for data ingestion and storage, be sure to plan and agree on data retention. For log analytics use cases, it's critical that you have right policies created within your domain to retire the historic data. When you are moving from an existing on-premises and cloud VM based architecture, you could be using a particular type of instance for all your data nodes. Data nodes have same CPU, memory, and storage profile. Most customers would configure high throughput storage to cater to their high-speed indexing requirement. This singular storage profile architecture is called _hot node only_ architecture, or hot-only. Hot-only architecture couples storage with compute, which implies that you need to add compute nodes if your storage requirement increases. @@ -50 +50 @@ This section covers different ways and patterns that you can use to migrate an E - * Whether you want to copy data from an existing self-managed cluster or you are rebuilding from the original data source (log files, product catalog database) + * Whether you want to copy data from an existing self-managed cluster or you are rebuilding from original the data source (log files, product catalog database) @@ -63 +63 @@ This section covers different ways and patterns that you can use to migrate an E -**Build from a snapshot** +### Build from a snapshot @@ -78 +78 @@ For additional considerations, see _Snapshot considerations_ in the [Stage 4 – -**Build from the source** +### Build from the source @@ -95 +95 @@ For information about options for building from the source, see _2\. Building fr -**Reindex remotely from an existing Elasticsearch or OpenSearch environment** +### Reindex remotely from an existing Elasticsearch or OpenSearch environment @@ -99 +99 @@ This approach uses the [remote reindex API](https://docs.aws.amazon.com/opensear -**Use open-source data migration tools** +### Use open-source data migration tools