Amazon Data Firehose era precedentemente noto come Amazon Kinesis Data Firehose
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Comprendi la distribuzione dei dati di Amazon Data Firehose
Una volta inviati allo stream Firehose, i dati vengono consegnati automaticamente alla destinazione prescelta.
Importante
Se utilizzi la Kinesis Producer Library (KPL) per scrivere i dati su un flusso di dati Kinesis, puoi utilizzare l'aggregazione per abbinare i record che scrivi al flusso di dati Kinesis. Se poi utilizzi quel flusso di dati come fonte per il tuo flusso Firehose, Amazon Data Firehose disaggrega i record prima di consegnarli alla destinazione. Se configuri il flusso Firehose per trasformare i dati, Amazon Data Firehose disaggrega i record prima di inviarli a. AWS Lambda Per ulteriori informazioni, consulta gli argomenti Sviluppo di produttori del flusso di dati Amazon Kinesis tramite la Kinesis Producer Library e Aggregazione nella Guida per sviluppatori del flusso di dati Amazon Kinesis.
Argomenti
- Configura il formato di consegna dei dati
- Comprendi la frequenza di consegna dei dati
- Gestire gli errori di consegna dei dati
- Configurazione del formato del nome oggetto Amazon S3
- Configura la rotazione dell'indice per Service OpenSearch
- Comprendi la distribuzione tra AWS account e regioni
- Record duplicati
- Mettere in pausa e riprendere uno stream di Firehose
Configura il formato di consegna dei dati
Per la distribuzione dei dati ad Amazon Simple Storage Service (Amazon S3), Firehose concatena più record in entrata in base alla configurazione di buffering del flusso Firehose. Quindi distribuisce i record ad Amazon S3 come oggetto Amazon S3. Per impostazione predefinita, Firehose concatena i dati senza delimitatori. Se si desidera disporre di nuovi delimitatori di riga tra i record, è possibile aggiungere nuovi delimitatori di riga abilitando la funzionalità nella configurazione della console Firehose o nel parametro API.
Per la distribuzione dei dati ad Amazon Redshift, Firehose invia innanzitutto i dati in entrata al bucket S3 nel formato descritto in precedenza. Firehose emette quindi un comando Amazon COPY Redshift per caricare i dati dal bucket S3 al cluster con provisioning di Amazon Redshift o al gruppo di lavoro Serverless Amazon Redshift. Assicurati che, dopo che Amazon Data Firehose ha concatenato più record in entrata in un oggetto Amazon S3, l'oggetto Amazon S3 possa essere copiato nel cluster con provisioning di Amazon Redshift o nel gruppo di lavoro Amazon Redshift Serverless. Per ulteriori informazioni, vedi i parametri del formato dati del comando COPY di Amazon Redshift.
Per la distribuzione dei dati a OpenSearch Service e OpenSearch Serverless, Amazon Data Firehose memorizza nel buffer i record in entrata in base alla configurazione di buffering del flusso Firehose. Quindi genera una richiesta in blocco di OpenSearch Service o OpenSearch Serverless per indicizzare più record nel cluster di servizio o nella raccolta Serverless. OpenSearch OpenSearch Assicurati che il record sia codificato in UTF-8 e appiattito in un oggetto JSON a riga singola prima di inviarlo ad Amazon Data Firehose. Inoltre, l'rest.action.multi.allow_explicit_indexopzione per il cluster di OpenSearch servizio deve essere impostata su true (impostazione predefinita) per accettare richieste in blocco con un indice esplicito impostato per record. Per ulteriori informazioni, consulta OpenSearch Service Configure Advanced Options nella Amazon OpenSearch Service Developer Guide.
Per la consegna dei dati a Splunk, Amazon Data Firehose concatena i byte inviati. Se nei dati vuoi dei delimitatori, come un carattere di nuova riga, devi inserirli manualmente. Verifica che Splunk sia configurato per analizzare questo tipo di delimitatori.
Quando distribuisci dati a un endpoint HTTP di proprietà di un fornitore di servizi di terze parti supportato, puoi utilizzare il servizio Amazon Lambda integrato per creare una funzione per trasformare i record in entrata nel formato che corrisponde a quello previsto dall'integrazione del fornitore di servizi. Contatta il fornitore di servizi di terze parti di cui hai scelto l'endpoint HTTP come destinazione per saperne di più sul formato di record accettato.
Per la consegna dei dati a Snowflake, Amazon Data Firehose memorizza internamente i dati nel buffer per un secondo e utilizza le operazioni dell'API di streaming Snowflake per inserire dati in Snowflake. Per impostazione predefinita, i record inseriti vengono cancellati e trasferiti nella tabella Snowflake ogni secondo. Dopo aver effettuato la chiamata di inserimento, Firehose emette una CloudWatch metrica che misura il tempo impiegato per il commit dei dati su Snowflake. Attualmente Firehose supporta solo un singolo elemento JSON come payload di record e non supporta gli array JSON. Assicurati che il payload di input sia un oggetto JSON valido e che sia ben formato senza virgolette, virgolette o caratteri di escape aggiuntivi.
Comprendi la frequenza di consegna dei dati
Ogni destinazione Firehose ha una propria frequenza di consegna dei dati. Per ulteriori informazioni, consulta Comprendi i suggerimenti per il buffering.
Gestire gli errori di consegna dei dati
Ogni destinazione Amazon Data Firehose dispone di una propria gestione degli errori di consegna dei dati.
- Amazon S3
-
La distribuzione dei dati sul bucket S3 potrebbe non riuscire per diversi motivi. Ad esempio, il bucket potrebbe non esistere più, il ruolo IAM che Amazon Data Firehose presuppone potrebbe non avere accesso al bucket, il problema di rete o eventi simili. In queste condizioni, Amazon Data Firehose continua a riprovare per un massimo di 24 ore fino al completamento della consegna. Il tempo massimo di archiviazione dei dati di Amazon Data Firehose è di 24 ore. Se la distribuzione dei dati non va a buon fine per più di 24 ore, i dati vengono persi.
- Amazon Redshift
-
Per una destinazione Amazon Redshift, puoi specificare una durata dei tentativi (0—7200 secondi) durante la creazione di uno stream Firehose.
La distribuzione dei dati sul cluster con provisioning Amazon Redshift o sul gruppo di lavoro Amazon Redshift serverless potrebbe non riuscire per diversi motivi. Ad esempio, potresti avere una configurazione del cluster errata del tuo flusso Firehose, un cluster o un gruppo di lavoro in manutenzione o un errore di rete. In queste condizioni, Amazon Data Firehose riprova per il periodo di tempo specificato e salta quel particolare batch di oggetti Amazon S3. Le informazioni relative agli oggetti non elaborati vengono inviate al bucket S3 sotto forma di file manifest nella cartella
errors/, che potrai utilizzare per recuperare le informazioni manualmente. Per ulteriori informazioni su come copiare manualmente i file manifest, consulta Utilizzo di un manifest per specificare i file di dati. - Amazon OpenSearch Service e OpenSearch Serverless
-
Per la destinazione OpenSearch Service e OpenSearch Serverless, è possibile specificare una durata del nuovo tentativo (0—7200 secondi) durante la creazione del flusso Firehose.
La consegna dei dati al cluster di OpenSearch servizio o alla raccolta OpenSearch Serverless potrebbe non riuscire per diversi motivi. Ad esempio, si potrebbe avere una configurazione errata del cluster di OpenSearch servizio o della raccolta OpenSearch Serverless del flusso Firehose, OpenSearch un cluster di servizio OpenSearch o una raccolta Serverless in manutenzione, un errore di rete o eventi simili. In queste condizioni, Amazon Data Firehose riprova per il periodo di tempo specificato e quindi salta quella particolare richiesta di indice. I documenti non elaborati vengono distribuiti sul bucket S3 nella cartella
AmazonOpenSearchService_failed/, che potrai utilizzare per recuperare le informazioni manualmente.Per OpenSearch Service, ogni documento ha il seguente formato JSON:
{ "attemptsMade": "(number of index requests attempted)", "arrivalTimestamp": "(the time when the document was received by Firehose)", "errorCode": "(http error code returned by OpenSearch Service)", "errorMessage": "(error message returned by OpenSearch Service)", "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)", "esDocumentId": "(intended OpenSearch Service document ID)", "esIndexName": "(intended OpenSearch Service index name)", "esTypeName": "(intended OpenSearch Service type name)", "rawData": "(base64-encoded document data)" }Per OpenSearch Serverless, ogni documento ha il seguente formato JSON:
{ "attemptsMade": "(number of index requests attempted)", "arrivalTimestamp": "(the time when the document was received by Firehose)", "errorCode": "(http error code returned by OpenSearch Serverless)", "errorMessage": "(error message returned by OpenSearch Serverless)", "attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)", "osDocumentId": "(intended OpenSearch Serverless document ID)", "osIndexName": "(intended OpenSearch Serverless index name)", "rawData": "(base64-encoded document data)" } - Splunk
-
Quando Amazon Data Firehose invia dati a Splunk, attende una conferma da parte di Splunk. Se si verifica un errore o la conferma non arriva entro il periodo di timeout del riconoscimento, Amazon Data Firehose avvia il contatore della durata dei nuovi tentativi. Continua a riprovare fino alla scadenza della durata dei nuovi tentativi. Dopodiché, Amazon Data Firehose lo considera un errore di consegna dei dati ed esegue il backup dei dati nel bucket Amazon S3.
Ogni volta che Amazon Data Firehose invia dati a Splunk, che si tratti del tentativo iniziale o di un nuovo tentativo, riavvia il contatore del timeout di conferma. Attende quindi il riconoscimento che deve arrivare da Splunk. Anche se la durata del nuovo tentativo scade, Amazon Data Firehose attende comunque il riconoscimento fino a quando non lo riceve o non viene raggiunto il timeout di conferma. Se la conferma scade, Amazon Data Firehose verifica se è rimasto del tempo nel contatore dei tentativi. Se rimane del tempo, riprova ancora e ripete la logica fino a quando non riceve un riconoscimento o stabilisce che il tempo dei nuovi tentativi è scaduto.
Una mancata ricezione di un riconoscimento non è l'unico tipo di errore di distribuzione dei dati che si può verificare. Per informazioni sugli altri tipi di errori di distribuzione dei dati, consulta Errori di distribuzione dei dati Splunk. Qualunque errore di distribuzione dei dati attiva la logica di ripetizione se la durata dei nuovi tentativi è maggiore di 0.
Di seguito è riportato un esempio di record degli errori.
{ "attemptsMade": 0, "arrivalTimestamp": 1506035354675, "errorCode": "Splunk.AckTimeout", "errorMessage": "Did not receive an acknowledgement from HEC before the HEC acknowledgement timeout expired. Despite the acknowledgement timeout, it's possible the data was indexed successfully in Splunk. Amazon Data Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.", "attemptEndingTimestamp": 13626284715507, "rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==", "EventId": "49577193928114147339600778471082492393164139877200035842.0" } - Destinazione endpoint HTTP
-
Quando Amazon Data Firehose invia dati a una destinazione endpoint HTTP, attende una risposta da tale destinazione. Se si verifica un errore o la risposta non arriva entro il periodo di timeout della risposta, Amazon Data Firehose avvia il contatore della durata dei nuovi tentativi. Continua a riprovare fino alla scadenza della durata dei nuovi tentativi. Dopodiché, Amazon Data Firehose lo considera un errore di consegna dei dati ed esegue il backup dei dati nel bucket Amazon S3.
Ogni volta che Amazon Data Firehose invia dati a una destinazione endpoint HTTP, che si tratti del tentativo iniziale o di un nuovo tentativo, riavvia il contatore del timeout di risposta. Quindi attende che arrivi una risposta dalla destinazione endpoint HTTP. Anche se la durata del nuovo tentativo scade, Amazon Data Firehose attende comunque la risposta finché non la riceve o non viene raggiunto il timeout di risposta. Se il timeout di risposta scade, Amazon Data Firehose verifica se è rimasto del tempo nel contatore dei tentativi. Se rimane del tempo, riprova ancora e ripete la logica fino a quando non riceve una risposta o stabilisce che il tempo per i nuovi tentativi è scaduto.
Una mancata ricezione di una risposta non è l'unico tipo di errore di distribuzione dei dati che si può verificare. Per informazioni sugli altri tipi di errori di distribuzione dei dati, consulta Errori di distribuzione dei dati dell'endpoint HTTP
Di seguito è riportato un esempio di record degli errori.
{ "attemptsMade":5, "arrivalTimestamp":1594265943615, "errorCode":"HttpEndpoint.DestinationException", "errorMessage":"Received the following response from the endpoint destination. {"requestId": "109777ac-8f9b-4082-8e8d-b4f12b5fc17b", "timestamp": 1594266081268, "errorMessage": "Unauthorized"}", "attemptEndingTimestamp":1594266081318, "rawData":"c2FtcGxlIHJhdyBkYXRh", "subsequenceNumber":0, "dataId":"49607357361271740811418664280693044274821622880012337186.0" } - Destinazione Snowflake
-
Per la destinazione Snowflake, quando si crea uno stream Firehose, è possibile specificare una durata del nuovo tentativo opzionale (0-7200 secondi). Il valore predefinito per la durata dei nuovi tentativi è 60 secondi.
L'invio dei dati alla tabella Snowflake potrebbe non riuscire per diversi motivi, ad esempio una configurazione errata della destinazione Snowflake, un'interruzione di Snowflake, un errore di rete, ecc. La politica sui nuovi tentativi non si applica agli errori non recuperabili. Ad esempio, se Snowflake rifiuta il payload JSON perché nella tabella manca una colonna aggiuntiva, Firehose non tenterà di consegnarla nuovamente. Al contrario, crea un backup di tutti gli errori di inserimento dovuti a problemi di payload JSON nel bucket di errori S3.
Allo stesso modo, se la consegna non riesce a causa di un ruolo, una tabella o un database errati, Firehose non riprova e scrive i dati nel bucket S3. La durata del nuovo tentativo si applica solo in caso di errore dovuto a un problema del servizio Snowflake, problemi temporanei di rete, ecc. In queste condizioni, Firehose riprova per il periodo di tempo specificato prima di consegnarli a S3. I record con errori vengono inviati nella cartella snowflake-failed/, che è possibile utilizzare per il riempimento manuale.
Di seguito è riportato un esempio di JSON per ogni record che invii a S3.
{ "attemptsMade": 3, "arrivalTimestamp": 1594265943615, "errorCode": "Snowflake.InvalidColumns", "errorMessage": "Snowpipe Streaming does not support columns of type AUTOINCREMENT, IDENTITY, GEO, or columns with a default value or collation", "attemptEndingTimestamp": 1712937865543, "rawData": "c2FtcGxlIHJhdyBkYXRh" }
Configurazione del formato del nome oggetto Amazon S3
Quando Firehose fornisce dati ad Amazon S3, il nome della chiave dell'oggetto S3 segue il <evaluated prefix><suffix>formato, dove il suffisso ha il formato - - - - - - - - <Firehose stream name><Firehose stream version><year><month><day><hour><minute><second><uuid><file extension><Firehose stream version>inizia con 1 e aumenta di 1 per ogni modifica di configurazione del flusso Firehose. È possibile modificare le configurazioni dei flussi Firehose (ad esempio, il nome del bucket S3, i suggerimenti di buffering, la compressione e la crittografia). È possibile farlo utilizzando la console Firehose o l'operazione UpdateDestinationAPI.
Perché<evaluated prefix>, Firehose aggiunge un prefisso orario predefinito nel formato. YYYY/MM/dd/HH Questo prefisso crea una gerarchia logica nel bucket, in cui ogni barra (/) crea un livello nella gerarchia. È possibile modificare questa struttura specificando un prefisso personalizzato che include espressioni valutate in fase di esecuzione. Per informazioni su come specificare un prefisso personalizzato, consulta Prefissi personalizzati per Amazon Simple Storage Service Objects.
Per impostazione predefinita, il fuso orario utilizzato per il prefisso e il suffisso orario è in UTC, ma puoi modificarlo con il fuso orario che preferisci. Ad esempio, per utilizzare l'ora solare giapponese anziché l'UTC, puoi configurare il fuso orario per Asia/Tokyo nell'impostazione dei parametri AWS Management Console o nell'API (). CustomTimeZone L'elenco seguente contiene i fusi orari supportati da Firehose per la configurazione del prefisso S3.
Di seguito è riportato un elenco di fusi orari supportati da Firehose per la configurazione del prefisso S3.
<file extension>Non è possibile modificare il campo del suffisso tranne. Quando si abilita la conversione o la compressione del formato dei dati, Firehose aggiungerà un'estensione di file in base alla configurazione. La tabella seguente illustra l'estensione di file predefinita aggiunta da Firehose:
| Configurazione | Estensione di file |
|---|---|
| Conversione del formato dei dati: Parquet | .parquet |
| Conversione del formato dei dati: ORC | .orc |
| Compressione: Gzip | .gz |
| Compressione: Zip | .zip |
| Compressione: Snappy | .snappy |
| Compressione: Hadoop-Snappy | .hsnappy |
È inoltre possibile specificare l'estensione di file che si preferisce nella console o nell'API Firehose. L'estensione del file deve iniziare con un punto (.) e può contenere caratteri consentiti: 0-9a-z! -_.*' (). L'estensione del file non può superare i 128 caratteri.
Nota
Quando si specifica un'estensione di file, questa sostituirà l'estensione di file predefinita aggiunta da Firehose quando è abilitata la conversione o la compressione del formato dei dati.
Configura la rotazione dell'indice per Service OpenSearch
Per la destinazione del OpenSearch servizio, è possibile specificare un'opzione di rotazione dell'indice basata sul tempo tra una delle cinque opzioni seguenti:NoRotation,OneHour, OneDayOneWeek, oOneMonth.
A seconda dell'opzione di rotazione scelta, Amazon Data Firehose aggiunge una parte del timestamp UTC di arrivo al nome di indice specificato. Ruota il timestamp aggiunto di conseguenza. L'esempio seguente mostra il nome dell'indice risultante in OpenSearch Service per ogni opzione di rotazione dell'indice, dove si trova il nome dell'indice specificato myindex e il timestamp di arrivo è. 2016-02-25T13:00:00Z
| RotationPeriod | IndexName |
|---|---|
NoRotation |
myindex |
OneHour |
myindex-2016-02-25-13 |
OneDay |
myindex-2016-02-25 |
OneWeek |
myindex-2016-w08 |
OneMonth |
myindex-2016-02 |
Nota
Con l'opzione OneWeek, Data Firehose crea automaticamente gli indici utilizzando il formato <YEAR>-w<WEEK NUMBER> (ad esempio, 2020-w33), in cui il numero della settimana viene calcolato utilizzando il tempo UTC e secondo le seguenti convenzioni statunitensi:
-
Una settimana inizia di domenica
-
La prima settimana dell'anno è la prima settimana che contiene un sabato dell'anno in corso
Comprendi la distribuzione tra AWS account e regioni
Amazon Data Firehose supporta la distribuzione di dati verso destinazioni endpoint HTTP tra diversi account. AWS Lo stream Firehose e l'endpoint HTTP che scegli come destinazione possono appartenere a diversi account. AWS
Amazon Data Firehose supporta anche la distribuzione di dati verso destinazioni endpoint HTTP in tutte le regioni. AWS È possibile inviare dati da un flusso Firehose in una AWS regione a un endpoint HTTP in un'altra regione. AWS È inoltre possibile inviare dati da un flusso Firehose a una destinazione endpoint HTTP al di fuori delle AWS regioni, ad esempio al proprio server locale impostando l'URL dell'endpoint HTTP sulla destinazione desiderata. Per questi scenari, ai costi di distribuzione si aggiungono ulteriori costi di trasferimento dati. Per ulteriori informazioni, consulta la sezione Trasferimento dati
Record duplicati
Amazon Data Firehose utilizza la at-least-once semantica per la distribuzione dei dati. In alcune circostanze, ad esempio quando scadono i tempi di consegna dei dati, i nuovi tentativi di consegna da parte di Amazon Data Firehose potrebbero creare duplicati se la richiesta originale di consegna dei dati alla fine viene accolta. Questo vale per tutti i tipi di destinazione supportati da Amazon Data Firehose.
Mettere in pausa e riprendere uno stream di Firehose
Dopo aver configurato uno stream Firehose, i dati disponibili nella sorgente del flusso vengono continuamente consegnati alla destinazione. In situazioni in cui la destinazione del flusso è temporaneamente non disponibile (ad esempio, durante operazioni di manutenzione programmate), potresti voler sospendere temporaneamente la distribuzione dei dati e riprenderla quando la destinazione sarà nuovamente disponibile. Nelle sezioni seguenti viene illustrato come eseguire questa operazione:
Importante
Quando utilizzi l'approccio descritto di seguito per mettere in pausa e riprendere uno stream, dopo averlo ripreso, vedrai che pochi record vengono consegnati al bucket di errori in Amazon S3 mentre il resto dello stream continua a essere recapitato alla destinazione. Questa è una limitazione nota dell'approccio e si verifica perché un numero limitato di record, che non era possibile consegnare in precedenza alla destinazione dopo più tentativi, vengono considerati falliti.
Comprendere come Firehose gestisce gli errori di consegna
Quando si configura uno stream Firehose, per molte destinazioni come OpenSearch gli endpoint Splunk e HTTP, si configura anche un bucket S3 in cui è possibile eseguire il backup dei dati che non vengono consegnati. Per ulteriori informazioni su come Firehose esegue il backup dei dati in caso di consegne non riuscite, vedere Data Delivery Failure Handling. Per ulteriori informazioni su come concedere l'accesso ai bucket S3 in cui è possibile eseguire il backup dei dati che non vengono consegnati, consulta Concedere l'accesso a Firehose a una destinazione Amazon S3. Quando Firehose (a) non riesce a consegnare i dati alla destinazione dello stream e (b) non riesce a scrivere i dati nel bucket S3 di backup in caso di consegne non riuscite, di fatto sospende la consegna dello stream fino a quando i dati non possono essere consegnati alla destinazione o scritti nella posizione di backup S3.
Sospensione di uno stream Firehose
Per sospendere la distribuzione dello stream in Firehose, rimuovete innanzitutto le autorizzazioni che consentono a Firehose di scrivere nella posizione di backup S3 per le consegne non riuscite. Ad esempio, se desideri mettere in pausa lo stream Firehose con OpenSearch una destinazione, puoi farlo aggiornando le autorizzazioni. Per ulteriori informazioni, vedere Concedere a Firehose l'accesso a una destinazione di OpenSearch servizio pubblico.
Rimuovi l'autorizzazione "Effect": "Allow" per l'azione s3:PutObject e aggiungi esplicitamente un'istruzione che applichi l'autorizzazione Effect": "Deny" all'azione s3:PutObject per il bucket S3 utilizzato per il backup delle distribuzioni non riuscite. Quindi, disattiva la destinazione dello stream (ad esempio, disattivando il OpenSearch dominio di destinazione) o rimuovi le autorizzazioni per Firehose di scrivere nella destinazione. Per aggiornare le autorizzazioni per altre destinazioni, consulta la sezione relativa alla tua destinazione in Controlling Access with Amazon Data Firehose. Dopo aver completato queste due azioni, Firehose interromperà la distribuzione degli stream e potrai monitorarla utilizzando le CloudWatch metriche per Firehose.
Importante
Quando si sospende la distribuzione dello stream in Firehose, è necessario assicurarsi che l'origine dello stream (ad esempio, in Kinesis Data Streams o in Managed Service for Kafka) sia configurata per conservare i dati fino alla ripresa della distribuzione dello stream e alla consegna dei dati alla destinazione. Se la fonte è DirectPut, Firehose conserverà i dati per 24 ore. Se la distribuzione del flusso non riprende e i dati non vengono distribuiti prima della scadenza del periodo di conservazione dei dati, potrebbe verificarsi una perdita di dati.
Ripresa di uno stream Firehose
Per riprendere la consegna, ripristina innanzitutto la modifica apportata in precedenza alla destinazione dello stream attivando la destinazione e assicurandoti che Firehose disponga delle autorizzazioni per consegnare lo stream alla destinazione. Successivamente, ripristina le modifiche apportate in precedenza alle autorizzazioni applicate al bucket S3 per il backup delle distribuzioni non riuscite. Vale a dire, applica l'autorizzazione "Effect": "Allow" per l'azione s3:PutObject e rimuovi l'autorizzazione "Effect": "Deny" sull'azione s3:PutObject per il bucket S3 utilizzato per il backup delle distribuzioni non riuscite. Infine, monitorate utilizzando le CloudWatch metriche di Firehose per confermare che lo stream venga recapitato alla destinazione. Per visualizzare e risolvere gli errori, usa il monitoraggio di Amazon CloudWatch Logs per Firehose.
