Preguntas frecuentes sobre Amazon Data Firehose

La API de Firehose está disponible en los SDK de Amazon Web Services. Puede consultar la lista de plataformas y lenguajes de programación para los SDK de Amazon Web Services en Herramientas de Amazon Web Services.

El agente de Kinesis es una aplicación precompilada de Java que ofrece una forma fácil de recopilar y enviar datos al flujo de Firehose. Puede instalar el agente en entornos de servidor basados en Linux, como servidores web, servidores de registro y servidores de base de datos. El agente supervisa determinados archivos y envía continuamente datos al flujo de Firehose. En este momento, el agente de Amazon Kinesis es compatible con Amazon Linux, Red Hat Enterprise Linux y Microsoft Windows. Para obtener más información, consulte Escritura con agentes.

Puede descargar e instalar el agente de Kinesis con el siguiente comando y enlace:

• En Amazon Linux: sudo yum install –y aws-kinesis-agent
• En Red Hat Enterprise Linux: sudo yum install –y https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn1.noarch.rpm
• Desde GitHub: awlabs/amazon-kinesis-agent
• En Windows: https://docs.aws.amazon.com/kinesis-agent-windows/latest/userguide/getting-started.html#getting-started-installation

Puede agregar datos a un flujo de Firehose a través del agente de Kinesis o mediante las operaciones PutRecord y PutRecordBatch de Firehose. La operación PutRecord permite incluir un solo registro de datos en una llamada a la API, mientras que la operación PutRecordBatch permite incluir varios registros de datos en una llamada a la API. Para obtener más información, consulte PutRecord y PutRecordBatch.

Cuando crea o actualiza su flujo de Firehose con la consola de AWS o las API de Firehose, puede configurar un clúster o tema de Amazon MSK como origen del flujo de Firehose. Una vez configurado, Firehose leerá automáticamente los datos de su tema MSK y los cargará en los buckets de S3 especificados.

Puede reducir la complejidad y la sobrecarga del funcionamiento de su aplicación transformando y cargando en Amazon S3 datos de streaming originados en sus temas de Amazon MSK sin necesidad de código. Por ejemplo, con Amazon MSK y Firehose, obtiene características integradas de transformación y conversión de datos sin código, como la conversión de formato Parquet/ORC, el almacenamiento en búfer de datos y la validación de datos del lado del servidor. También dispone de reintentos automáticos de entrega, retención de datos, escalado automático y redundancia, para que los datos se entreguen de forma fiable.

Para utilizar esta característica, los clústeres MSK deben tener habilitados puntos de conexión públicos o enlaces privados.

Sí, Firehose puede conectarse a clústeres de Amazon MSK que estén disponibles en diferentes cuentas de AWS. Firehose también puede realizar entregas a buckets de S3 que pertenezcan a cuentas diferentes.

El momento del punto de control para empezar a consumir datos del tema de Amazon MSK es el momento de creación de la secuencia de Firehose. Firehose no lee los valores de compensación personalizados.

Cuando crea o actualiza su flujo de Firehose mediante la consola de AWS o las API de Firehose, puede configurar un flujo de Firehose como origen de su flujo de Firehose. Una vez configurado, Firehose leerá datos automáticamente del flujo de Firehose y los cargará en destinos específicos.

Firehose llama al flujo de datos GetRecords() de Kinesis una vez por segundo para cada partición de Kinesis.

Firehose comienza a leer los datos desde la posición más reciente del flujo de datos de Kinesis cuando está configurado como el origen de un flujo de Firehose. Para obtener más información sobre la posición del flujo de datos de Kinesis, consulte GetShardIterator en la referencia de la API del servicio de flujo de datos de Kinesis.

Sí, es posible. Sin embargo, tenga en cuenta que la llamada a GetRecords() desde Firehose se contabiliza en la limitación controlada de su partición de Kinesis, por lo que debe planificar el flujo de Firehose junto con las demás aplicaciones de Kinesis para que no se vea limitado. Para obtener más información, consulte Límites de Kinesis Data Streams en la guía para desarrolladores de Kinesis Data Streams.

No, no es posible. Cuando un flujo de datos de Kinesis esté configurado como origen de un flujo de Firehose, las operaciones PutRecord y PutRecordBatch de Firehose estarán deshabilitadas. Debe agregar datos a su flujo de datos de Kinesis mediante las operaciones PutRecord y PutRecords de Kinesis Data Streams.

Para agregar datos al flujo de Firehose desde AWS IoT, debe crear una acción de AWS IoT que envíe eventos al flujo de Firehose. Para obtener más información, consulte Escritura en Amazon Data Firehose con AWS IoT en la guía para desarrolladores de Firehose.

Al crear o actualizar su flujo de Firehose a través de la consola de AWS o las API de Firehose, puede configurar Direct PUT como origen de su flujo de Firehose. Una vez que se crea el flujo, puede configurar el flujo de Firehose que ha creado como flujo de Firehose en la sección Registros a la venta de la consola de registros de flujo de VPC.

Para agregar datos a su flujo de Firehose desde Registros de CloudWatch, debe crear un filtro de suscripción de Registros de CloudWatch que envíe eventos al flujo de Firehose. Para obtener más información, consulte uso de filtros de suscripción de Registros de CloudWatch en la guía para desarrolladores de Amazon CloudWatch.

Para agregar datos al flujo de Firehose desde Eventos de CloudWatch, debe crear una regla de Eventos de CloudWatch que envíe eventos al flujo de Firehose. Para obtener más información, consulte Escritura en Amazon Data Firehose con Eventos de CloudWatch en la guía para desarrolladores de Firehose.

Agregue datos a su flujo de Firehose desde la consola de AWS EventBridge. Para obtener más información, consulte la documentación de AWS EventBridge.

Firehose permite cifrar los datos después de haberlos entregado en un bucket de Amazon S3. Mientras crea el flujo de Firehose, puede cifrar los datos con una clave de AWS Key Management Service (KMS) propia. Para obtener más información sobre KMS, consulte AWS Key Management Service.

Firehose asume el rol de IAM que usted especifica para obtener acceso a recursos como un bucket de Amazon S3 y un dominio de Amazon OpenSearch. Para obtener más información, consulte Control del acceso con Firehose en la guía para desarrolladores de Firehose.

Sí, Firehose usa AWS PrivateLink para conectarse a las bases de datos que se encuentran dentro de la VPC.

Sí, cuando configura una transmisión de entrega de Firehose, puede seleccionar tablas y columnas específicas en su base de datos de origen. Firehose ofrece actualizaciones de CDC solo para las tablas y columnas seleccionadas.

Sí, cuando configura Firehose para que entregue una transmisión de CDC a las tablas de Apache Iceberg en Amazon S3, puede configurar la transmisión para que entregue registros de diferentes tablas de origen a diferentes tablas de Apache Iceberg.

Firehose admite la conversión de formato de datos sin procesar o JSON a los formatos requeridos por sus almacenes de datos de destino, como Apache Parquet y Apache ORC, sin necesidad de crear canalizaciones de procesamiento de datos propias. Firehose también permite particionar dinámicamente los datos de streaming antes de la entrega a S3 con claves definidas de forma estática o dinámica como “customer_id” o “transaction_id”. Firehose agrupa los datos según estas claves y realiza la entrega en prefijos de S3 con una clave única, lo que facilita la ejecución de análisis de alto rendimiento y rentables en S3 con Athena, EMR y Redshift Spectrum.

Además de la opción de conversión de formato incorporada en Amazon Data Firehose, también puede utilizar una función de AWS Lambda para preparar y transformar los datos sin formato que entran en el flujo de Firehose antes de cargarlos en los destinos. Puede configurar una función de AWS Lambda para transformar datos cuando cree un flujo de Firehose o cuando edite uno existente. Amazon ha creado varios proyectos de Lambda que puede elegir como inicio rápido. Para obtener más información, consulte la guía para el desarrollador de Amazon Data Firehose.

Con Amazon Data Firehose, puede comprimir los datos antes de entregarlos a Amazon S3. En la actualidad, el servicio admite los formatos de compresión GZIP, ZIP y SNAPPY. El formato GZIP solo es compatible si los datos se cargan luego en Amazon Redshift.

Puede utilizar la característica de suscripción de Registros de CloudWatch para transmitir datos desde Registros de CloudWatch a Firehose. Todos los eventos de registro de Registros de CloudWatch ya se encuentran comprimidos con el formato gzip, por lo que debería mantener la configuración de compresión de Firehose sin comprimir para evitar una compresión doble. Para obtener más información acerca de la característica de suscripción de Registros de CloudWatch, consulte Filtros de suscripción con Amazon Data Firehose en la guía del usuario de Registros de Amazon CloudWatch.

Todos los registros transformados por Lambda deben devolverse a Firehose con los siguientes tres parámetros; de lo contrario, Firehose rechazará los registros y los tratará como errores de transformación de datos.

• recordId: Firehose pasa a Lambda un recordld con cada registro durante la invocación. Cada registro transformado debe ser devuelto con exactamente el mismo recordId. Cualquier diferencia entre el recordId original y el devuelto se tratará como error de transformación de datos.
   
• result: el estado del resultado de transformación de cada registro. Se permiten los siguientes valores para este parámetro: "Ok" si el registro se transforma como se pretendía. "Dropped" si la lógica de procesamiento omite el registro intencionadamente, tal y como se pretendía. "ProcessingFailed" si el registro no se puede transformar tal y como correspondería. Cuando Firehose genera métricas de SucceedProcessing.Records y SucceedProcessing.Bytes trata los registros devueltos con estado de "Ok" y "Dropped" como registros procesados y los que tienen el estado "ProcessingFailed" como registros que no se han podido procesar.
   
• datos: la carga de datos transformados con codificación based64.

Si habilita la transformación de datos con Lambda, Firehose podrá registrar las invocaciones de Lambda y los errores de entrega de datos en Amazon CloudWatch Logs para que le sea posible consultar los registros de errores específicos si ocurre una falla en una invocación de Lambda o en la entrega de datos. Para obtener más información, consulte Supervisión con Registros de Amazon CloudWatch.

Si usa la transformación de datos con Lambda, puede habilitar el respaldo de los registros originales y Amazon Data Firehose entregará en un bucket de S3 diferente los datos entrantes sin transformar. Podrá especificar un prefijo adicional para colocarlo antes del prefijo de tiempo UTC "AAAA/MM/DD/HH" que genera Firehose.

La partición dinámica de Firehose elimina las complejidades y los retrasos de la partición manual en el origen o después de almacenar los datos y permite un análisis más rápido para consultar conjuntos de datos optimizados. Esto hace que los conjuntos de datos estén disponibles inmediatamente para que las herramientas de análisis ejecuten sus consultas con eficiencia y mejora el control de acceso preciso a los datos. Por ejemplo, los clientes de automatización de marketing pueden particionar los datos al momento por ID de cliente, lo que permite que las consultas específicas de los clientes consulten conjuntos de datos optimizados y entreguen resultados más rápidamente. Los clientes de operaciones de TI o supervisión de seguridad pueden crear grupos en función de la marca de tiempo de los eventos incrustada en los registros, de forma que puedan consultar conjuntos de datos optimizados y obtener resultados más rápidamente. Esta característica, junto con la conversión de formato existente de JSON a parquet de Amazon Data Firehose, convierte Amazon Data Firehose en una opción de ETL en streaming ideal para S3.

Puede configurar la característica de partición de datos de Firehose con la consola de administración de AWS, las CLI o los SDK. Al crear o actualizar un flujo de Firehose, seleccione Amazon S3 como el destino de entrega para el flujo de Firehose y habilite la partición dinámica. Puede especificar claves o crear una expresión que se evaluará en tiempo de ejecución para definir las claves usadas para la partición. Por ejemplo, puede seleccionar un campo de datos en el flujo de entrada como el ID de cliente y definir una expresión de prefijo de S3 como customer_id=!{partitionKey:customer_id}/, que se evaluará en tiempo de ejecución según los registros capturados para definir a qué prefijo de S3 entregar los registros.

Firehose admite la conversión de parquet/ORC de fábrica al escribir datos a Amazon S3. Firehose también se integra con funciones Lambda, de forma que puede escribir su propio código de transformación. Firehose también dispone de compatibilidad incorporada con la extracción de los campos de datos de claves de los registros en formato JSON. Firehose también es compatible con el lenguaje de análisis JQ para permitir las transformaciones en las claves de partición. Para obtener más información, consulte la guía para desarrolladores de Firehose.

Sí, Firehose puede respaldar todos los registros sin transformar en el bucket de S3 al tiempo que entrega registros transformados en el destino. Puede habilitar la copia de seguridad de los registros originales cuando cree o actualice flujo de Firehose.

La frecuencia de entrega de datos en Amazon S3 se determina según del valor que se haya configurado para el tamaño y el intervalo del búfer de S3 para el flujo de Firehose. Firehose envía los datos de entrada a un búfer antes de entregarlos en Amazon S3. Puede configurar los valores del tamaño del búfer de S3 (de 1 MB a 128 MB) o intervalo del búfer (de 0 a 900 segundos), y la condición que primero se cumpla activará la entrega de los datos en Amazon S3. Si ha habilitado Apache Parquet o la partición dinámica, su tamaño de búfer es en MB y varía de 64 MB a 128 MB para el destino de Amazon S3, para el que 128 MB es el valor predeterminado. Recuerde que en circunstancias en las que la entrega de datos al destino queda rezagada con respecto a la ingesta de datos en el flujo de Firehose, Firehose aumenta el tamaño del búfer dinámicamente para ponerse al corriente y asegurarse de que todos los datos se entreguen en sus destinos.

El tamaño del búfer se aplica después de la compresión. Por tanto, si decide comprimir los datos, el tamaño de los objetos contenidos en el bucket de Amazon S3 puede ser menor que el tamaño del búfer que ha especificado.

El usuario de Redshift necesita privilegios de inserción (INSERT) en Redshift para copiar datos del bucket de Amazon S3 en la instancia de Redshift.

Si su instancia de Redshift se encuentra en una VPC, tiene que desbloquear las direcciones de IP de Firehose desde su VPC para conceder a Amazon Data Firehose acceso a su instancia de Redshift. Para obtener más información sobre cómo desbloquear IP en su VPC, consulte concesión de acceso a Firehose a un destino de Amazon Redshift en la guía para desarrolladores de Amazon Data Firehose.

Para los destinos de Redshift, Amazon Data Firehose entrega primero los datos en el bucket de Amazon S3 y, a continuación, emite un comando COPY (copiar) de Redshift para cargar los datos desde su bucket de S3 a la instancia de Redshift.

Actualmente, una sola transmisión de Firehose puede entregar datos a una sola tabla de Snowflake. Para entregar datos a varias tablas de Snowflake, debe crear varias secuencias de Firehose.

Firehose usa la semántica de entrega “exactamente una vez” para Snowflake. Esto significa que cada registro se entrega a Snowflake exactamente una vez, incluso si hay errores o reintentos. Sin embargo, este tipo de entrega no garantiza que no haya duplicados en los datos de un extremo a otro, ya que el productor u otras partes del proceso de ETL pueden duplicar los datos.

Se espera que la mayoría de las secuencias de datos se entreguen en 5 segundos.

Amazon OpenSearch Service le permite realizar fácilmente análisis interactivo de registros, supervisión de aplicaciones en tiempo real, búsqueda de sitios web y mucho más. OpenSearch es un conjunto de búsqueda y análisis distribuido de código abierto derivado de Elasticsearch. Amazon OpenSearch Service ofrece las últimas versiones de OpenSearch, compatibilidad con 19 versiones de Elasticsearch (versiones 1.5 a 7.10) y capacidades de visualización con tecnología de OpenSearch Dashboards y Kibana (versiones 1.5 a 7.10). Haga clic aquí para obtener más información sobre Amazon OpenSearch.

Firehose puede rotar su índice de Amazon OpenSearch Service en función de una duración de tiempo. Puede configurar dicha duración al momento de crear el flujo de Firehose. Para obtener más información, consulte Rotación de índice para el destino de Amazon OpenSearch en la guía para desarrolladores de Amazon Data Firehose.

Cuando carga datos en Amazon OpenSearch Service, Firehose puede realizar copias de seguridad de todos los datos o solo de aquellos que no se pudieron entregar. Para aprovechar esta característica y evitar la pérdida de datos, debe proporcionar un bucket de Amazon S3 de backup.

La configuración del flujo de Firehose se puede cambiar en cualquier momento. Puede hacerlo con la consola de Firehose o la operación UpdateDestination. El flujo de Firehose permanece en estado activo mientras se actualizan las configuraciones, por lo que puede continuar enviándole datos. Las configuraciones actualizadas suelen surtir efecto al cabo de unos minutos.

Cuando se entrega una VPC de destino, puede cambiar el URL de punto de conexión de destino, siempre y cuando se pueda acceder al nuevo destino dentro del mismo VPC, subredes y grupos de seguridad. Para cambios de VPC, subredes y grupos de seguridad, debe recrear el flujo de Firehose.

La entrega de Data Firehose solo puede realizar entregas a una cuenta diferente de Amazon OpenSearch Service cuando Firehose y Amazon OpenSearch Service están conectadas a través de un punto de encale público.

Si Firehose y Amazon OpenSearch Service están conectados a través de una VPC privada. El flujo de Firehose y la VPC de dominio de destino de Amazon OpenSearch Service deben estar en la misma cuenta.

No, el flujo de Firehose y el dominio de Amazon OpenSearch Service de destino deben estar en la misma región.

La frecuencia de entrega de datos en Amazon OpenSearch Service se determina según los valores que se hayan configurado para el tamaño y el intervalo del búfer para el flujo de Firehose. Firehose envía los datos de entrada a un búfer antes de entregarlos en Amazon OpenSearch Service. Puede configurar los valores del tamaño del búfer de OpenSearch (de 1 MB a 100 MB) o el intervalo del búfer (de 0 a 900 segundos), y la condición que primero se cumpla activará la entrega de los datos en Amazon OpenSearch Service. Tenga en cuenta que en circunstancias en las que la entrega de datos al destino queda rezagada con respecto a la ingesta de datos en el flujo de Firehose, Amazon Data Firehose aumenta el tamaño del búfer dinámicamente para ponerse al corriente y asegurarse de que todos los datos se entreguen en sus destinos.

En los destinos de Redshift, Amazon Data Firehose genera archivos de manifiestos para cargar objetos de Amazon S3 en la instancia de Redshift por lotes. La carpeta de manifiestos almacena los archivos de manifiesto que genera Firehose.

Si se utiliza el modo “todos los documentos”, Amazon Data Firehose concatena múltiples registros de entrada a partir de la configuración de búfer del flujo de Firehose y, a continuación, los entrega en el bucket de S3 como objeto de S3. Independientemente de qué modo de respaldo se configure, los documentos fallidos se entregan en el bucket de S3 con un formato JSON determinado que proporciona información adicional, como el código de error y la hora del intento de entrega. Para obtener más información, consulte Copia de seguridad en Amazon S3 para el destino de Amazon OpenSearch en la guía para desarrolladores de Amazon Data Firehose.

Por el momento, cada flujo de Firehose solo puede entregar datos en un solo bucket de Amazon S3. Si quiere entregar datos en varios buckets de S3, puede crear varios flujos de Firehose.

Por el momento, cada flujo de Firehose solo puede entregar datos a una única tabla y a una única instancia de Redshift. Si quiere entregar datos a varia instancias o varias tablas de Redshift, puede crear varios flujos de Firehose.

Por el momento, cada flujo de Firehose solo puede entregar datos en un solo domino y en un solo índice de Amazon OpenSearch Service. Si quiere entregar datos en varios dominios o índices de Amazon OpenSearch Service, puede crear varios flujos de Firehose.

Cuando habilite Firehose para entregar datos en un destino de Amazon OpenSearch Service en una VPC, Amazon Data Firehose crea una o más interfaces de red elástica entre cuentas (ENI) en la VPC para cada subred que elija. Amazon Data Firehose utiliza estas ENI para entregar los datos a la VPC. La cantidad de ENI se escala automáticamente para cumplir con los requerimientos del servicio.

Sí, una sola transmisión de Firehose puede entregar datos a varias tablas de Apache Iceberg.

Sí, Firehose admite la conexión al catálogo de datos de AWS Glue en una cuenta diferente o en una región de AWS diferente.

Sí, puede usar la característica de transformación de datos con Lambda al entregar tablas de Apache Iceberg. 

De manera predeterminada, cada flujo de Firehose puede recibir hasta 2000 transacciones por segundo, 5000 registros por segundo y 5 MB por segundo. Puede aumentar este límite muy fácilmente al enviar una solicitud de incremento del límite de servicio.

Amazon Data Firehose utiliza, al menos una vez, semántica para la entrega de datos. Excepcionalmente, como, por ejemplo, si se excede el tiempo de espera de la solicitud en un intento de entrega de datos, los reintentos de entrega que realiza Firehose pueden ocasionar duplicados si la solicitud inicial termina siendo aceptada.

Si el origen de datos es Direct PUT y la entrega de datos a su bucket de Amazon S3 falla, Amazon Data Firehose volverá a intentar entregar los datos cada 5 segundos durante un periodo máximo de 24 horas. Si el problema persiste después del periodo máximo de retención de 24 horas, Amazon Data Firehose descarta los datos.

Si el origen de datos es el flujo de datos de Kinesis y falla la entrega de datos a su bucket de Amazon S3, Amazon Data Firehose volverá a intentar entregar los datos cada 5 segundos durante un periodo máximo de lo que está configurado en Kinesis Data Streams.

Si la entrega de datos a la instancia de Redshift falla, Amazon Data Firehose volverá a intentar entregar los datos cada 5 minutos durante un periodo máximo de 120 minutos. Después de 120 minutos, Amazon Data Firehose omitirá el lote actual de objetos de S3 listos para COPY (copiar) y pasará al siguiente lote. La información relativa a los objetos omitidos se entrega al bucket de S3 en la forma de un archivo de manifiestos en la carpeta de errores. Este archivo de manifiestos se puede utilizar para realizar la operación manualmente. Para obtener información sobre cómo copiar los datos manualmente a partir de los archivos de manifiestos, consulte Uso de un manifiesto para especificar archivos de datos.

Con Amazon OpenSearch Service como destino, puede especificar durante cuánto tiempo se volverá a intentar la entrega (entre 0 y 7200 segundos) cuando cree el flujo de Firehose. Si la entrega de datos en el dominio de Amazon OpenSearch no se concreta, Amazon Data Firehose volverá a intentar entregar los datos durante el tiempo especificado. Una vez transcurrido dicho periodo, Amazon Data Firehose omitirá el lote actual de datos y pasará al siguiente. Los datos sobre los documentos que se omitieron se entregarán en el bucket de S3 en la carpeta opensearch_failed, que puede utilizar para replicarlos manualmente.

Se pueden dar dos tipos de errores cuando Firehose intenta invocar la función Lambda para la transformación de datos:

• El primer tipo es cuando la invocación de la función falla por razones como el alcance del límite del tiempo de espera de la red o los límites de la invocación de Lambda. En estos contextos, Firehose intenta realizar la invocación tres veces de forma predeterminada y luego omite ese lote de registros específico. Los registros omitidos se tratan como registros que no se han podido procesar. Puede configurar el número de reintentos de invocación entre 0 y 300 con las API CreateDeliveryStream y UpdateDeliveryStream. En este tipo de error, también puede utilizar la característica de registro de errores de Firehose para emitir errores de invocación a Registros de CloudWatch. Para obtener más información, consulte Supervisión con Registros de Amazon CloudWatch.
   
• El segundo tipo de error ocurre cuando el resultado de transformación de un registro aparece como “ProcessingFailed” al ser devuelto de la función de Lambda. Firehose trata estos registros como registros que no han podido procesarse. En este tipo de error, también puede utilizar la característica de registro de Lambda para emitir registros de errores a Registros de CloudWatch. Para obtener más información, consulte Acceso a Registros de Amazon CloudWatch para AWS Lambda.

En ambos tipos de error, los registros de procesamiento no realizado se entregan en el bucket S3, en la carpeta processing_failed.

El tamaño de los objetos S3 entregados suele ser igual al tamaño del búfer especificado si se cumple la condición del tamaño del búfer antes de que se cumpla la condición del intervalo del búfer. Sin embargo, cuando la entrega de datos al destino queda rezagada con respecto a la escritura de datos en el flujo de Firehose, Firehose aumenta el tamaño del búfer dinámicamente para ponerse al corriente y asegurarse de que todos los datos se entreguen en sus destinos. En estas circunstancias, el tamaño de los objetos de S3 entregados puede ser mayor que el tamaño de búfer especificado.

La carpeta de errores almacena los archivos de manifiestos que contienen información de los objetos de S3 que no se han cargado en la instancia de Redshift. Puede volver a cargar estos objetos manualmente mediante el comando COPY de Redshift. Para obtener información sobre cómo copiar los datos manualmente a partir de los archivos de manifiestos, consulte Uso de un manifiesto para especificar archivos de datos.

La carpeta opensearch_failed almacena los documentos que no pudieron cargarse en su dominio de Amazon OpenSearch. ¿Qué sucede si falla el envío de datos a mi dominio de Amazon OpenSearch? Puede volver a indexar estos documentos manualmente para su replicación.

La carpeta processing_failed almacena los registros que no se han podido transformar en la función de AWS Lambda. Puede volver a procesar estos registros manualmente.

La consola de Firehose muestra métricas clave sobre el funcionamiento y el rendimiento, como el volumen de datos entrantes y entregados. Amazon Data Firehose también se integra en Métricas de Amazon CloudWatch para recopilar, ver y analizar las métricas correspondientes a los flujos de Firehose. Para obtener más información sobre las métricas de Amazon Data Firehose, consulte Supervisión con Métricas de Amazon CloudWatch en la guía para desarrolladores de Amazon Data Firehose.

Amazon Data Firehose se integra en Registros de Amazon CloudWatch, de modo que podrá ver los registros de los errores específicos si falla la transformación o la entrega de datos. Puede habilitar los registros de errores al crear el flujo de Firehose. Para obtener más información, consulte Supervisión con Registros de Amazon CloudWatch en la guía para desarrolladores de Amazon Data Firehose.

Amazon Data Firehose se integra en AWS Identity and Access Management, un servicio que permite controlar de forma segura el acceso de los usuarios a sus recursos y productos de AWS. Por ejemplo, puede crear una política que permita agregar datos al flujo de Firehose únicamente a un usuario o a un grupo específico. Para obtener más información sobre cómo administrar y controlar el acceso al flujo, consulte Control del acceso con Amazon Data Firehose.

Amazon Data Firehose se integra en AWS CloudTrail, un servicio que registra las llamadas a la API de AWS de su cuenta y le entrega archivos de registro. Para obtener más información sobre el registro de llamadas a la API y la lista de las operaciones de la API de Amazon Data Firehose admitidas, consulte Registro de las llamadas a la API de Amazon Data Firehose con AWS CloudTrail.

En la actualidad, Firehose no está disponible dentro del nivel gratuito de AWS. La capa gratuita de AWS es un programa que ofrece pruebas gratuitas de varios servicios de AWS. Para obtener más información, consulte Nivel gratuito de AWS.

Firehose aplica un esquema de precios sencillo de pago por uso. No hay costos iniciales ni cuotas mínimas y solo tendrá que pagar por los recursos que consuma. Los precios de Amazon Data Firehose se basan en el volumen de datos (GB) que se consuman y teniendo en cuenta que cada registro se redondea a los 5 KB siguientes si Direct PUT y el flujo de datos Kinesis son los orígenes. En el caso de que los registros a la venta sean el origen, el precio se basa en el volumen de datos (GB) que consuma Firehose. Para obtener más información sobre el precio de Amazon Data Firehose, consulte Precios de Amazon Data Firehose.

El redondeo a 5 KB se calcula en el nivel de registro y no en el nivel de operación de la API. Por ejemplo, si la llamada PutRecordBatch contiene dos registros de 1 KB, el volumen de datos de esa llamada se calculará como 10 KB. (5 KB por registro).

No, los costos asociados con el uso de Amazon S3, Amazon Redshift, Amazon OpenSearch Service y AWS Lambda, incluidos el almacenamiento y las solicitudes, se facturan aparte. Para obtener más información, consulte Precios de Amazon S3, Precios de Amazon Redshift, Precios de Amazon OpenSearch Service y Precios de AWS Lambda.

Mediante el acuerdo de nivel de servicio (SLA) de Amazon Data Firehose se garantiza un porcentaje de tiempo de funcionamiento mensual de al menos 99,9 % para Amazon Data Firehose.

Será elegible para recibir crédito del SLA para Amazon Data Firehose bajo el acuerdo de Amazon Data Firehose si más de una zona de disponibilidad en las que ejecuta una tarea, dentro de la misma región, tiene un porcentaje de tiempo de funcionamiento mensual inferior al 99,9 % durante cualquier ciclo de facturación mensual.

Para obtener información completa sobre los términos y condiciones del acuerdo, así como detalles sobre cómo enviar una reclamación, consulte la página con detalles del acuerdo de Amazon Data Firehose.