

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Suscripciones entre cuentas y regiones
<a name="CrossAccountSubscriptions"></a>

Puede colaborar con un propietario de otra AWS cuenta y recibir sus eventos de registro en sus AWS recursos, como una transmisión de Amazon Kinesis o Amazon Data Firehose (esto se conoce como intercambio de datos entre cuentas). Por ejemplo, los datos de este registro de eventos se pueden leer desde una transmisión centralizada de Amazon Kinesis Data Streams o Firehose para realizar un procesamiento y análisis personalizados. El procesamiento personalizado resulta especialmente útil al colaborar y analizar datos en muchas cuentas.

Por ejemplo, el grupo de seguridad de información de una empresa podría desear analizar datos de detección de intrusiones en tiempo real o de comportamientos anómala para poder realizar una auditoría de cuentas en todas las divisiones de la empresa recopilando sus registros de producción federada para procesamiento central. Se puede recopilar una transmisión en tiempo real de los datos de eventos en esas cuentas y entregarla a los grupos de seguridad de la información, que pueden usar Amazon Kinesis Data Streams para adjuntar los datos a sus sistemas de análisis de seguridad existentes.

**nota**  
El grupo de registros y el destino deben estar en la misma AWS región. Sin embargo, el recurso de AWS al que apunta el destino puede estar ubicado en una región diferente. En los ejemplos de las secciones siguientes, todos los recursos específicos de una región se crean en Este de EE. UU. (Norte de Virginia).

Si ha configurado cuentas de miembros AWS Organizations y trabaja con ellas, puede utilizar la centralización de registros para recopilar datos de registro de las cuentas de origen en una cuenta de supervisión central. 

Al trabajar con grupos de registros centralizados, se pueden utilizar estas dimensiones de los campos del sistema al crear filtros de suscripción.
+ `@aws.account`- Esta dimensión representa el ID de AWS cuenta desde el que se originó el evento de registro.
+ `@aws.region`- Esta dimensión representa la AWS región en la que se generó el evento de registro. 

Estas dimensiones ayudan a identificar el origen de los datos de registro, lo que permite filtrar y analizar de forma más detallada las métricas derivadas de los registros centralizados. 

**Topics**
+ [Intercambio de datos de registro entre cuentas y regiones mediante Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis.md)
+ [Uso compartido de datos de registro entre cuentas y regiones mediante Firehose](CrossAccountSubscriptions-Firehose.md)
+ [Suscripciones a nivel de cuenta multirregional mediante Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis-Account.md)
+ [Suscripciones a nivel de cuenta entre cuentas y regiones mediante Firehose](CrossAccountSubscriptions-Firehose-Account.md)

# Intercambio de datos de registro entre cuentas y regiones mediante Amazon Kinesis Data Streams
<a name="CrossAccountSubscriptions-Kinesis"></a>

Al crear una suscripción entre cuentas, puede especificar una única cuenta o una organización para que sea el remitente. Si especifica una organización, este procedimiento permite que todas las cuentas de la organización envíen registros a la cuenta de receptor.

Para compartir los datos de registro entre cuentas, es necesario establecer un emisor y receptor de datos de registro:
+ **Remitente de los datos de registro**: obtiene la información de destino del destinatario e informa a CloudWatch Logs de que está listo para enviar sus eventos de registro al destino especificado. En los procedimientos descritos en el resto de esta sección, se muestra al remitente de los datos de registro con un número de AWS cuenta ficticio de 1111.

  Si va a tener varias cuentas de una organización que envíen registros a una cuenta de destinatario, puede crear una política que otorgue a todas las cuentas de la organización el permiso para enviar registros a la cuenta de destinatario. Aún tiene que configurar filtros de suscripción independientes para cada cuenta de remitente.
+ **Destinatario de los datos de registro**: configura un destino que encapsula una transmisión de Amazon Kinesis Data Streams y permite a CloudWatch Logs saber que el destinatario desea recibir los datos de registro. A continuación, el destinatario comparte la información sobre este destino con el remitente. En los procedimientos que se describen en el resto de esta sección, se muestra al destinatario de los datos de registro con un número de AWS cuenta ficticio, el número de cuenta 999.

Para empezar a recibir eventos de registro de usuarios con varias cuentas, el destinatario de los datos de registro crea primero un destino de CloudWatch registros. Cada destino consta de los siguientes elementos fundamentales:

**Nombre de destino**  
El nombre del destino que desea crear.

**ARN de destino**  
El nombre del recurso de Amazon (ARN) del AWS recurso que quieres usar como destino del feed de suscripción.

**ARN del rol**  
Un rol AWS Identity and Access Management (IAM) que otorga a CloudWatch Logs los permisos necesarios para colocar los datos en la transmisión elegida.

**Política de acceso**  
Un documento de política de IAM (en formato JSON, escrito con la gramática de política de IAM) que rige el conjunto de los usuarios a los que se les permite escribir en su destino.

**nota**  
El grupo de registros y el destino deben estar en la misma AWS región. Sin embargo, el AWS recurso al que apunta el destino puede estar ubicado en una región diferente. En los ejemplos de las secciones siguientes, todos los recursos específicos de una región se crean en EE. UU. Este (Norte de Virginia).

**Topics**
+ [Configuración de una nueva suscripción entre cuentas](Cross-Account-Log_Subscription-New.md)
+ [Actualización de una suscripción entre cuentas existente](Cross-Account-Log_Subscription-Update.md)

# Configuración de una nueva suscripción entre cuentas
<a name="Cross-Account-Log_Subscription-New"></a>

Siga los pasos de estas secciones para configurar una nueva suscripción de registro entre cuentas.

**Topics**
+ [Paso 1: crear un destino](CreateDestination.md)
+ [Paso 2: (solo si se utiliza una organización) crear un rol de IAM](CreateSubscriptionFilter-IAMrole.md)
+ [Paso 3: Permisos Add/validate de IAM para el destino de varias cuentas](Subscription-Filter-CrossAccount-Permissions.md)
+ [Paso 4: crear un filtro de suscripción](CreateSubscriptionFilter.md)
+ [Validación del flujo de eventos de registro](ValidateLogEventFlow.md)
+ [Modificación de la suscripción al destino en tiempo de ejecución](ModifyDestinationMembership.md)

# Paso 1: crear un destino
<a name="CreateDestination"></a>

**importante**  
Todos los pasos de este procedimiento deben realizarse en la cuenta del destinatario de los datos de registro.

En este ejemplo, la cuenta receptora de los datos de registro tiene un identificador de AWS cuenta de 10000 9999, mientras que el identificador de la AWS cuenta del remitente de los datos de registro es 1111.

 En este ejemplo, se crea un destino mediante una transmisión de Amazon Kinesis Data Streams RecipientStream llamada y una función que CloudWatch permite a Logs escribir datos en ella. 

Cuando se crea el destino, CloudWatch Logs envía un mensaje de prueba al destino en nombre de la cuenta del destinatario. Cuando el filtro de suscripciones se active más adelante, CloudWatch Logs envía los eventos de registro al destino en nombre de la cuenta de origen.

**Para crear un destino**

1. En la cuenta del destinatario, cree una transmisión de destino en Amazon Kinesis Data Streams. En el símbolo del sistema, escriba:

   ```
   aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
   ```

1. Espere hasta que el flujo de se active. **Puede utilizar el comando **aws kinesis describe-stream** para comprobar la. StreamDescription StreamStatus**propiedad. Además, tome nota del valor **StreamDescription.streamArn porque** lo pasará a CloudWatch Logs más adelante:

   ```
   aws kinesis describe-stream --stream-name "RecipientStream"
   {
     "StreamDescription": {
       "StreamStatus": "ACTIVE",
       "StreamName": "RecipientStream",
       "StreamARN": "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream",
       "Shards": [
         {
           "ShardId": "shardId-000000000000",
           "HashKeyRange": {
             "EndingHashKey": "34028236692093846346337460743176EXAMPLE",
             "StartingHashKey": "0"
           },
           "SequenceNumberRange": {
             "StartingSequenceNumber": "4955113521868881845667950383198145878459135270218EXAMPLE"
           }
         }
       ]
     }
   }
   ```

   El flujo puede tardar un minuto o dos en mostrarse en el estado activo.

1. Crea el rol de IAM que otorga a CloudWatch Logs el permiso para colocar datos en tu transmisión. En primer lugar, tendrás que crear una política de confianza en un archivo **\$1/ TrustPolicyFor** CWL.json. Utilice un editor de texto para crear este archivo de política; no utilice la consola de IAM.

   Esta política incluye una clave de contexto de condición global `aws:SourceArn` que especifica la `sourceAccountId` para ayudar a prevenir el problema de seguridad de suplente confuso. Si aún no conoce el ID de cuenta de origen en la primera llamada, le recomendamos que coloque el ARN de destino en el campo ARN de origen. En las llamadas posteriores, debe configurar el ARN de origen para que sea el ARN de origen real que recopiló desde la primera llamada. Para obtener más información, consulte [Prevención del suplente confuso](Subscriptions-confused-deputy.md). 

   ```
   {
       "Statement": {
           "Effect": "Allow",
           "Principal": {
               "Service": "logs.amazonaws.com"
           },
           "Condition": {
               "StringLike": {
                   "aws:SourceArn": [
                       "arn:aws:logs:region:sourceAccountId:*",
                       "arn:aws:logs:region:recipientAccountId:*"
                   ]
               }
           },
           "Action": "sts:AssumeRole"
       }
   }
   ```

1. Ejecute el comando **aws iam create-role** para crear el rol de IAM y especifique el archivo de política de confianza. Toma nota del valor Role.Arn devuelto porque también se pasará a Logs más adelante: CloudWatch 

   ```
   aws iam create-role \
   --role-name CWLtoKinesisRole \
   --assume-role-policy-document file://~/TrustPolicyForCWL.json
   
   {
       "Role": {
           "AssumeRolePolicyDocument": {
               "Statement": {
                   "Action": "sts:AssumeRole",
                   "Effect": "Allow",
                   "Condition": {
                       "StringLike": {
                           "aws:SourceArn": [
                               "arn:aws:logs:region:sourceAccountId:*",
                               "arn:aws:logs:region:recipientAccountId:*"
                           ]
                       }
                   },
                   "Principal": {
                       "Service": "logs.amazonaws.com"
                   }
               }
           },
           "RoleId": "AAOIIAH450GAB4HC5F431",
           "CreateDate": "2015-05-29T13:46:29.431Z",
           "RoleName": "CWLtoKinesisRole",
           "Path": "/",
           "Arn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
       }
   }
   ```

1. Crea una política de permisos para definir qué acciones puede realizar CloudWatch Logs en tu cuenta. Primero, usa un editor de texto para crear una política de permisos en un archivo **\$1/ PermissionsFor CWL.json:**

   ```
   {
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "kinesis:PutRecord",
         "Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
       }
     ]
   }
   ```

1. Asocie la política de permisos al rol mediante el comando **aws** iam: put-role-policy

   ```
   aws iam put-role-policy \
       --role-name CWLtoKinesisRole \
       --policy-name Permissions-Policy-For-CWL \
       --policy-document file://~/PermissionsForCWL.json
   ```

1. Una vez que la transmisión esté en estado activo y haya creado el rol de IAM, puede crear el destino de los CloudWatch registros.

   1. Este paso no asocia una política de acceso a su destino y solo es el primer paso de los dos que completan la creación de un destino. Anote el valor de **DestinationArn** que se devuelve en la carga:

      ```
      aws logs put-destination \
          --destination-name "testDestination" \
          --target-arn "arn:aws:kinesis:region:999999999999:stream/RecipientStream" \
          --role-arn "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
      
      {
        "DestinationName" : "testDestination",
        "RoleArn" : "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
        "DestinationArn" : "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
        "TargetArn" : "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream"
      }
      ```

   1. Una vez que se haya completado el paso 7a, en la cuenta del destinatario de los datos de registro, asocie una política de acceso con el destino. Esta política debe especificar los **registros:** la PutSubscriptionFilter acción y otorga permiso a la cuenta del remitente para acceder al destino.

      La política concede permiso a la AWS cuenta que envía los registros. Puede especificar solo esta cuenta en la política o, si la cuenta de remitente es miembro de una organización, la política puede especificar el ID de organización de la organización. De esta forma, puede crear una sola política para permitir que varias cuentas de una organización envíen registros a esta cuenta de destino.

      Utilice un editor de texto para crear un archivo denominado `~/AccessPolicy.json` con una de las siguientes declaraciones de política.

      Este primer ejemplo de política permite a todas las cuentas de la organización que tienen un ID de `o-1234567890` enviar registros a la cuenta de destinatario.

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Principal": "*",
                  "Action": "logs:PutSubscriptionFilter",
                  "Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
                  "Condition": {
                      "StringEquals": {
                          "aws:PrincipalOrgID": [
                              "o-1234567890"
                          ]
                      }
                  }
              }
          ]
      }
      ```

------

      En el siguiente ejemplo, solo se permite que la cuenta del remitente de los datos de registro (111111111111) envíe los registros a la cuenta del destinatario de los datos de registro.

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "111111111111"
                  },
                  "Action": "logs:PutSubscriptionFilter",
                  "Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
              }
          ]
      }
      ```

------

   1. Adjunte la política que creó en el paso anterior al destino.

      ```
      aws logs put-destination-policy \
          --destination-name "testDestination" \
          --access-policy file://~/AccessPolicy.json
      ```

      Esta política de acceso permite a los usuarios de la AWS cuenta con el ID 1111 llamar al destino con el ARN arn:aws:logs **PutSubscriptionFilter**::55559999:Destination:TestDestination. *region* Se PutSubscriptionFilter rechazará cualquier intento de otro usuario de llamar a este destino.

      Para validar los privilegios de un usuario con una política de acceso, consulte [Uso del validador de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) en la *Guía del usuario de IAM*.

Cuando hayas terminado, si los estás utilizando AWS Organizations para tus permisos multicuenta, sigue los pasos que se indican. [Paso 2: (solo si se utiliza una organización) crear un rol de IAM](CreateSubscriptionFilter-IAMrole.md) Si está concediendo permisos directamente a la otra cuenta en lugar de utilizar Organizations, puede omitir ese paso y continuar con [Paso 4: crear un filtro de suscripción](CreateSubscriptionFilter.md).

# Paso 2: (solo si se utiliza una organización) crear un rol de IAM
<a name="CreateSubscriptionFilter-IAMrole"></a>

En la sección anterior, si ha creado el destino mediante una política de acceso que otorga permisos a la organización en la que está esa cuenta `111111111111`, en lugar de conceder permisos directamente a la cuenta `111111111111`, siga los pasos de esta sección. De lo contrario, puede ir directamente a [Paso 4: crear un filtro de suscripción](CreateSubscriptionFilter.md).

Los pasos de esta sección crean un rol de IAM, que CloudWatch puede asumir y validar si la cuenta del remitente tiene permiso para crear un filtro de suscripción para el destino del destinatario. 

Realice los pasos de esta sección en la cuenta del remitente. El rol debe existir en la cuenta del remitente y usted especifica el ARN de este rol en el filtro de suscripción. En este ejemplo, la cuenta del remitente es `111111111111`.

**Para crear la función de IAM necesaria para las suscripciones de registros multicuenta, utilice AWS Organizations**

1. Cree la siguiente política de confianza en un archivo `/TrustPolicyForCWLSubscriptionFilter.json`. Utilice un editor de texto para crear este archivo de política; no utilice la consola de IAM.

   ```
   {
     "Statement": {
       "Effect": "Allow",
       "Principal": { "Service": "logs.amazonaws.com" },
       "Action": "sts:AssumeRole"
     }
   }
   ```

1. Cree un rol de IAM que utilice la política. Anote el valor `Arn` que devuelve el comando, ya que lo necesitará más tarde en este procedimiento. En este ejemplo, usaremos `CWLtoSubscriptionFilterRole` para el nombre del rol que estamos creando.

   ```
   aws iam create-role \ 
        --role-name CWLtoSubscriptionFilterRole \ 
        --assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
   ```

1. Cree una política de permisos para definir las acciones que CloudWatch Logs puede realizar en su cuenta.

   1. En primer lugar, utilice un editor de texto para crear la siguiente política de permisos en un archivo denominado: `~/PermissionsForCWLSubscriptionFilter.json`.

      ```
      { 
          "Statement": [ 
              { 
                  "Effect": "Allow", 
                  "Action": "logs:PutLogEvents", 
                  "Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*" 
              } 
          ] 
      }
      ```

   1. Ingrese el siguiente comando para asociar la política de permisos que acaba de crear con el rol que creó en el paso 2.

      ```
      aws iam put-role-policy  
          --role-name CWLtoSubscriptionFilterRole  
          --policy-name Permissions-Policy-For-CWL-Subscription-filter 
          --policy-document file://~/PermissionsForCWLSubscriptionFilter.json
      ```

Cuando haya terminado, puede proceder a [Paso 4: crear un filtro de suscripción](CreateSubscriptionFilter.md).

# Paso 3: Permisos Add/validate de IAM para el destino de varias cuentas
<a name="Subscription-Filter-CrossAccount-Permissions"></a>

Según la lógica de evaluación de políticas AWS multicuenta, para acceder a cualquier recurso multicuenta (como una transmisión de Kinesis o Firehose utilizada como destino para un filtro de suscripciones), debe tener una política basada en la identidad en la cuenta remitente que proporcione acceso explícito al recurso de destino multicuenta. Para obtener más información sobre la lógica de evaluación de políticas, consulte [Lógica de evaluación de políticas entre cuentas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).

Puede adjuntar la política basada en la identidad al rol de IAM o al usuario de IAM que utilice para crear el filtro de suscripción. Esta política debe estar presente en la cuenta de envío. Si utiliza la función de administrador para crear el filtro de suscripciones, puede omitir este paso y continuar con [Paso 4: crear un filtro de suscripción](CreateSubscriptionFilter.md).

**Para agregar o validar los permisos de IAM necesarios para el uso entre cuentas**

1. Introduzca el siguiente comando para comprobar qué rol de IAM o usuario de IAM se utiliza para ejecutar los comandos de registro. AWS 

   ```
   aws sts get-caller-identity
   ```

   El comando devuelve un resultado similar al siguiente:

   ```
   {
   "UserId": "User ID",
   "Account": "sending account id",
   "Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
   }
   ```

   Anote el valor representado por *RoleName* o. *UserName*

1. Inicie sesión Consola de administración de AWS en la cuenta remitente y busque las políticas adjuntas con el rol de IAM o el usuario de IAM que aparecen en el resultado del comando que ingresó en el paso 1.

1. Compruebe que las políticas adjntas a este rol o usuario brindan permisos explícitos para llamar a `logs:PutSubscriptionFilter` en el recurso de destino entre cuentas. 

   La siguiente política proporciona permisos para crear un filtro de suscripción en cualquier recurso de destino solo en una sola AWS cuenta, la cuenta: `999999999999`

------
#### [ JSON ]

****  

   ```
   {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
           {
               "Sid": "AllowSubscriptionFiltersOnAccountResources",
               "Effect": "Allow",
               "Action": "logs:PutSubscriptionFilter",
               "Resource": [
                   "arn:aws:logs:*:*:log-group:*",
                   "arn:aws:logs:*:123456789012:destination:*"
               ]
           }
       ]
   }
   ```

------

   La siguiente política proporciona permisos para crear un filtro de suscripción solo en un recurso de destino específico nombrado `sampleDestination` en una sola AWS cuenta, la cuenta`123456789012`:

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "AllowSubscriptionFiltersonAccountResource",
               "Effect": "Allow",
               "Action": "logs:PutSubscriptionFilter",
               "Resource": [
                   "arn:aws:logs:*:*:log-group:*",
                   "arn:aws:logs:*:123456789012:destination:sampleDestination"
               ]
           }
       ]
   }
   ```

------

# Paso 4: crear un filtro de suscripción
<a name="CreateSubscriptionFilter"></a>

Después de crear un destino, la cuenta del destinatario de los datos de registro puede compartir el ARN de destino (arn:aws:logs:us-east-1:999999999999:destination:testDestination) con otras cuentas de AWS para que puedan enviar eventos de registro al mismo destino. A continuación, los usuarios de estas otras cuentas remitentes crean un filtro de suscripción en sus grupos de registro respectivos frente a este destino. El filtro de suscripción inicia de inmediato el flujo de datos de registro en tiempo real desde el grupo de registro elegido al destino especificado.

**nota**  
Si concede permisos para el filtro de suscripción a toda una organización, tendrá que usar el ARN del rol de IAM en el que creó [Paso 2: (solo si se utiliza una organización) crear un rol de IAM](CreateSubscriptionFilter-IAMrole.md).

En el siguiente ejemplo, se crea un filtro de suscripción en una cuenta remitente. El filtro está asociado a un grupo de registros que contiene AWS CloudTrail eventos, de modo que cada actividad registrada con AWS las credenciales «Root» se envía al destino que creó anteriormente. Ese destino encapsula una transmisión llamada "»RecipientStream.

En el resto de los pasos de las siguientes secciones, se supone que ha seguido las instrucciones de la *Guía del AWS CloudTrail usuario sobre* cómo [enviar CloudTrail eventos a los CloudWatch registros](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) y ha creado un grupo de registros que contiene sus CloudTrail eventos. En estos pasos se supone que el nombre de este grupo de registro es `CloudTrail/logs`.

Al introducir el siguiente comando, asegúrese de haber iniciado sesión como usuario de IAM o de utilizar el rol de IAM para el que agregó la política, en [Paso 3: Permisos Add/validate de IAM para el destino de varias cuentas](Subscription-Filter-CrossAccount-Permissions.md).

```
aws logs put-subscription-filter \
    --log-group-name "CloudTrail/logs" \
    --filter-name "RecipientStream" \
    --filter-pattern "{$.userIdentity.type = Root}" \
    --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```

El grupo de registros y el destino deben estar en la misma AWS región. Sin embargo, el destino puede apuntar a un AWS recurso, como una transmisión de Amazon Kinesis Data Streams, que se encuentre en una región diferente.

# Validación del flujo de eventos de registro
<a name="ValidateLogEventFlow"></a>

Tras crear el filtro de suscripción, CloudWatch Logs reenvía todos los eventos de registro entrantes que coinciden con el patrón de filtrado a la transmisión que está encapsulada en la transmisión de destino denominada "». **RecipientStream** El propietario del destino puede comprobar que esto está ocurriendo utilizando el get-shard-iterator comando **aws kinesis** para capturar un fragmento de Amazon Kinesis Data Streams y utilizando **el comando aws kinesis** get-records para obtener algunos registros de Amazon Kinesis Data Streams:

```
aws kinesis get-shard-iterator \
      --stream-name RecipientStream \
      --shard-id shardId-000000000000 \
      --shard-iterator-type TRIM_HORIZON

{
    "ShardIterator":
    "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
}

aws kinesis get-records \
      --limit 10 \
      --shard-iterator
      "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
```

**nota**  
Puede que tenga que volver a ejecutar el comando get-records varias veces antes de que Amazon Kinesis Data Streams comience a devolver datos.

Debería ver una respuesta con una serie de registros de Amazon Kinesis Data Streams. El atributo de datos del registro de Amazon Kinesis Data Streams se comprime en formato gzip y, a continuación, se codifica en base64. Puede examinar los datos sin procesar desde la línea de comando utilizando el siguiente comando de Unix:

```
echo -n "<Content of Data>" | base64 -d | zcat
```

Los datos descodificados y descomprimidos en base64 se formatean como JSON con la siguiente estructura:

```
{
    "owner": "111111111111",
    "logGroup": "CloudTrail/logs",
    "logStream": "111111111111_CloudTrail/logs_us-east-1",
    "subscriptionFilters": [
        "RecipientStream"
    ],
    "messageType": "DATA_MESSAGE",
    "logEvents": [
        {
            "id": "3195310660696698337880902507980421114328961542429EXAMPLE",
            "timestamp": 1432826855000,
            "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
        },
        {
            "id": "3195310660696698337880902507980421114328961542429EXAMPLE",
            "timestamp": 1432826855000,
            "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
        },
        {
            "id": "3195310660696698337880902507980421114328961542429EXAMPLE",
            "timestamp": 1432826855000,
            "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
        }
    ]
}
```

Los elementos fundamentales de esta estructura de datos son los siguientes:

**owner**  
El ID de AWS cuenta de los datos de registro originarios.

**logGroup**  
El nombre del grupo de registro de los datos de registro de origen.

**logStream**  
El nombre del flujo de registros de los datos de registro de origen.

**subscriptionFilters**  
La lista de nombres de filtros de suscripción que coincide con los datos de registro de origen.

**messageType**  
Los mensajes de datos utilizan el tipo “DATA\$1MESSAGE”. A veces, CloudWatch los registros pueden emitir registros de Amazon Kinesis Data Streams del tipo «CONTROL\$1MESSAGE», principalmente para comprobar si se puede acceder al destino.

**logEvents**  
Los datos de registro reales, representados como un conjunto de registros de eventos de registro. La propiedad ID es un identificador único de cada evento de registro.

# Modificación de la suscripción al destino en tiempo de ejecución
<a name="ModifyDestinationMembership"></a>

Puede encontrar situaciones en las que tenga que añadir o eliminar la pertenencia de algunos usuarios de un destino de su propiedad. Puede utilizar el comando `put-destination-policy` en su destino con la nueva política de acceso. En el siguiente ejemplo, una cuenta **111111111111** añadida anteriormente deja de enviar más datos de registro y se habilita la cuenta **222222222222**.

1. Busca la política que está asociada actualmente con el destino **TestDestination** y anota lo siguiente: **AccessPolicy**

   ```
   aws logs describe-destinations \
       --destination-name-prefix "testDestination"
   
   {
    "Destinations": [
      {
        "DestinationName": "testDestination",
        "RoleArn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
        "DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
        "TargetArn": "arn:aws:kinesis:region:999999999999:stream/RecipientStream",
        "AccessPolicy": "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\", \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"111111111111\"}, \"Action\": \"logs:PutSubscriptionFilter\", \"Resource\": \"arn:aws:logs:region:999999999999:destination:testDestination\"}] }"
      }
    ]
   }
   ```

1. Actualice la política para reflejar que la cuenta **111111111111** está detenida y que la cuenta **222222222222** está habilitada. Coloca esta política en el archivo **\$1/ .json: NewAccessPolicy**

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "",
               "Effect": "Allow",
               "Principal": {
                   "AWS": "222222222222"
               },
               "Action": "logs:PutSubscriptionFilter",
               "Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
           }
       ]
   }
   ```

------

1. Llame **PutDestinationPolicy**para asociar la política definida en el **NewAccessPolicyarchivo.json** con el destino:

   ```
   aws logs put-destination-policy \
   --destination-name "testDestination" \
   --access-policy file://~/NewAccessPolicy.json
   ```

   Esto finalmente deshabilitará los eventos de registro del ID de cuenta **111111111111**. Los eventos de registro del ID de cuenta **222222222222** empiezan a fluir al destino en cuanto el propietario de la cuenta **222222222222** crea un filtro de suscripción.

# Actualización de una suscripción entre cuentas existente
<a name="Cross-Account-Log_Subscription-Update"></a>

Si actualmente tiene una suscripción de registros entre cuentas en la que la cuenta de destino concede permisos solo a cuentas de remitentes específicas y desea actualizar esta suscripción para que la cuenta de destino conceda acceso a todas las cuentas de una organización, siga los pasos de esta sección.

**Topics**
+ [Paso 1: actualizar los filtros de suscripción](Cross-Account-Log_Subscription-Update-filter.md)
+ [Paso 2: actualizar la política de acceso de destino existente](Cross-Account-Log_Subscription-Update-policy.md)

# Paso 1: actualizar los filtros de suscripción
<a name="Cross-Account-Log_Subscription-Update-filter"></a>

**nota**  
Este paso solo es necesario para las suscripciones entre cuentas de los registros creados por los servicios enumerados en [Habilitar el registro desde AWS los servicios](AWS-logs-and-resource-policy.md). Si no está trabajando con registros creados por uno de estos grupos de registro, puede ir directo a [Paso 2: actualizar la política de acceso de destino existente](Cross-Account-Log_Subscription-Update-policy.md).

En algunos casos, debe actualizar los filtros de suscripción en todas las cuentas de remitente que envían registros a la cuenta de destino. La actualización añade una función de IAM, que permite CloudWatch asumir y validar que la cuenta del remitente tiene permiso para enviar los registros a la cuenta del destinatario.

Siga los pasos de esta sección para cada cuenta de remitente que desee actualizar para utilizar el ID de organización para los permisos de suscripción entre cuentas.

En los ejemplos de esta sección, dos cuentas, `111111111111` y `222222222222`, ya cuentan con filtros de suscripción creados para enviar registros a la cuenta `999999999999`. Los valores de filtro de suscripción existentes son los siguientes:

```
## Existing Subscription Filter parameter values
    \ --log-group-name "my-log-group-name" 
    \ --filter-name "RecipientStream" 
    \ --filter-pattern "{$.userIdentity.type = Root}" 
    \ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```

Si tiene que encontrar los valores de los parámetros de filtro de suscripción actuales, ingrese el siguiente comando.

```
aws logs describe-subscription-filters 
    \ --log-group-name "my-log-group-name"
```

**Para actualizar un filtro de suscripción y empezar a usar la organización IDs para los permisos de registro entre cuentas**

1. Cree la siguiente política de confianza en un archivo `~/TrustPolicyForCWL.json`. Utilice un editor de texto para crear este archivo de política; no utilice la consola de IAM.

   ```
   {
     "Statement": {
       "Effect": "Allow",
       "Principal": { "Service": "logs.amazonaws.com" },
       "Action": "sts:AssumeRole"
     }
   }
   ```

1. Cree un rol de IAM que utilice la política. Anote el valor `Arn` del valor `Arn` que devuelve el comando, ya que lo necesitará más tarde en este procedimiento. En este ejemplo, usaremos `CWLtoSubscriptionFilterRole` para el nombre del rol que estamos creando.

   ```
   aws iam create-role 
       \ --role-name CWLtoSubscriptionFilterRole 
       \ --assume-role-policy-document file://~/TrustPolicyForCWL.json
   ```

1. Crea una política de permisos para definir las acciones que CloudWatch Logs puede realizar en tu cuenta.

   1. En primer lugar, utilice un editor de texto para crear la siguiente política de permisos en un archivo denominado: `/PermissionsForCWLSubscriptionFilter.json`.

      ```
      { 
          "Statement": [ 
              { 
                  "Effect": "Allow", 
                  "Action": "logs:PutLogEvents", 
                  "Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*" 
              } 
          ] 
      }
      ```

   1. Ingrese el siguiente comando para asociar la política de permisos que acaba de crear con el rol que creó en el paso 2.

      ```
      aws iam put-role-policy 
          --role-name CWLtoSubscriptionFilterRole 
          --policy-name Permissions-Policy-For-CWL-Subscription-filter 
          --policy-document file://~/PermissionsForCWLSubscriptionFilter.json
      ```

1. Ingrese el siguiente comando para actualizar el filtro de suscripción.

   ```
   aws logs put-subscription-filter 
       \ --log-group-name "my-log-group-name" 
       \ --filter-name "RecipientStream" 
       \ --filter-pattern "{$.userIdentity.type = Root}" 
       \ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
       \ --role-arn "arn:aws:iam::111111111111:role/CWLtoSubscriptionFilterRole"
   ```

# Paso 2: actualizar la política de acceso de destino existente
<a name="Cross-Account-Log_Subscription-Update-policy"></a>

Después de actualizar los filtros de suscripción en todas las cuentas de remitente, puede actualizar la política de acceso de destino en la cuenta de destinatario.

En los ejemplos siguientes, la cuenta de destinatario es `999999999999` y el destino se llama `testDestination`.

La actualización permite que todas las cuentas que forman parte de la organización con ID `o-1234567890` envíen registros a la cuenta de destinatario. Solo las cuentas que tienen filtros de suscripción creados enviarán registros a la cuenta del destinatario.

**Para actualizar la política de acceso de destino en la cuenta de destinatario a fin de empezar a utilizar un ID de organización para obtener permisos**

1. En la cuenta del destinatario, utilice un editor de texto para crear un archivo `~/AccessPolicy.json` con el siguiente contenido.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "",
               "Effect": "Allow",
               "Principal": "*",
               "Action": "logs:PutSubscriptionFilter",
               "Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
               "Condition": {
                   "StringEquals": {
                       "aws:PrincipalOrgID": [
                           "o-1234567890"
                       ]
                   }
               }
           }
       ]
   }
   ```

------

1. Ingrese el siguiente comando para adjuntar la política que acaba de crear al destino existente. Para actualizar un destino para usar una política de acceso con un identificador de organización en lugar de una política de acceso que muestre una AWS cuenta específica IDs, incluye el `force` parámetro.
**aviso**  
Si está trabajando con registros enviados por uno de los AWS servicios incluidos en la lista[Habilitar el registro desde AWS los servicios](AWS-logs-and-resource-policy.md), antes de realizar este paso, debe haber actualizado los filtros de suscripción de todas las cuentas de remitentes, tal y como se explica en la sección[Paso 1: actualizar los filtros de suscripción](Cross-Account-Log_Subscription-Update-filter.md).

   ```
   aws logs put-destination-policy 
       \ --destination-name "testDestination" 
       \ --access-policy file://~/AccessPolicy.json
       \ --force
   ```

# Uso compartido de datos de registro entre cuentas y regiones mediante Firehose
<a name="CrossAccountSubscriptions-Firehose"></a>

Para compartir los datos de registro entre cuentas, es necesario establecer un emisor y receptor de datos de registro:
+ **Remitente de los datos de registro**: obtiene la información de destino del destinatario e informa a CloudWatch Logs de que está listo para enviar sus eventos de registro al destino especificado. En los procedimientos descritos en el resto de esta sección, se muestra al remitente de los datos de registro con un número de AWS cuenta ficticio de 1111.
+ **Destinatario de los datos de registro**: configura un destino que encapsula una transmisión de Amazon Kinesis Data Streams y permite a CloudWatch Logs saber que el destinatario desea recibir los datos de registro. A continuación, el destinatario comparte la información sobre este destino con el remitente. En los procedimientos descritos en el resto de esta sección, se muestra al destinatario de los datos de registro con un número de AWS cuenta ficticio, 222222222222.

En el ejemplo de esta sección, se utiliza un flujo de entrega de Firehose con almacenamiento de Amazon S3. También puede configurar flujos de entrega de Firehose con diferentes parámetros. Para obtener más información, consulte [Creación de un flujo de entrega de Firehose](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).

**nota**  
El grupo de registros y el destino deben estar en la misma AWS región. Sin embargo, el AWS recurso al que apunta el destino puede estar ubicado en una región diferente.

**nota**  
 Se admite el filtro de suscripción de Firehose para el flujo de entrega de una ***misma cuenta*** y ***entre regiones***. 

**Topics**
+ [Paso 1: creación de un flujo de entrega de Firehose](CreateFirehoseStream.md)
+ [Paso 2: creación de un destino](CreateFirehoseStreamDestination.md)
+ [Paso 3: Permisos Add/validate de IAM para el destino multicuenta](Subscription-Filter-CrossAccount-Permissions-Firehose.md)
+ [Paso 4: crear un filtro de suscripción](CreateSubscriptionFilterFirehose.md)
+ [Validación del flujo de eventos de registro](ValidateLogEventFlowFirehose.md)
+ [Modificación de la suscripción al destino en tiempo de ejecución](ModifyDestinationMembershipFirehose.md)

# Paso 1: creación de un flujo de entrega de Firehose
<a name="CreateFirehoseStream"></a>

**importante**  
 Antes de realizar los siguientes pasos, debe utilizar una política de acceso para que Firehose pueda acceder a su bucket de Amazon S3. Para obtener más información, consulte [Control del acceso](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) en la *Guía para desarrolladores de Amazon Data Firehose*.   
 Todos los pasos en esta sección (Paso 1) deben realizarse en la cuenta del destinatario de los datos de registro.   
 En los ejemplos siguientes, se utiliza Este de EE. UU. (Norte de Virginia). Reemplace esta región por la región correcta para su implementación. 

**Creación de un flujo de entrega de Firehose que se utilice como destino**

1. Cree un bucket de Amazon S3:

   ```
   aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
   ```

1. Cree el rol de IAM que concede permiso a Firehose para incluir datos en el bucket.

   1. En primer lugar, utilice un editor de texto para crear una política de confianza en un archivo `~/TrustPolicyForFirehose.json`.

      ```
      { "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
      ```

   1. Cree el rol de IAM y especifique el archivo de política de confianza que acaba de crear.

      ```
      aws iam create-role \ 
          --role-name FirehosetoS3Role \ 
          --assume-role-policy-document file://~/TrustPolicyForFirehose.json
      ```

   1. El resultado de este comando debería ser similar a lo siguiente. Haga una nota del nombre del rol y del ARN del rol.

      ```
      {
          "Role": {
              "Path": "/",
              "RoleName": "FirehosetoS3Role",
              "RoleId": "AROAR3BXASEKW7K635M53",
              "Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
              "CreateDate": "2021-02-02T07:53:10+00:00",
              "AssumeRolePolicyDocument": {
                  "Statement": {
                      "Effect": "Allow",
                      "Principal": {
                          "Service": "firehose.amazonaws.com"
                      },
                      "Action": "sts:AssumeRole",
                      "Condition": {
                          "StringEquals": {
                              "sts:ExternalId": "222222222222"
                          }
                      }
                  }
              }
          }
      }
      ```

1. Cree una política de permisos para definir las acciones que Firehose puede realizar en su cuenta.

   1. En primer lugar, utilice un editor de texto para crear la siguiente política de permisos en un archivo denominado: `~/PermissionsForFirehose.json`. Según el caso de uso, es posible que tenga que agregar más permisos a este archivo.

      ```
      {
          "Statement": [{
              "Effect": "Allow",
              "Action": [
                  "s3:PutObject",
                  "s3:PutObjectAcl",
                  "s3:ListBucket"
              ],
              "Resource": [
                  "arn:aws:s3:::amzn-s3-demo-bucket",
                  "arn:aws:s3:::amzn-s3-demo-bucket/*"
              ]
          }]
      }
      ```

   1. Ingrese el siguiente comando para asociar la política de permisos que acaba de crear con el rol de IAM.

      ```
      aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
      ```

1. Introduzca el comando siguiente para crear el flujo de entrega de Firehose. Sustituya *my-role-arn* y *amzn-s3-demo-bucket2-arn* por los valores correctos para su implementación.

   ```
   aws firehose create-delivery-stream \
      --delivery-stream-name 'my-delivery-stream' \
      --s3-destination-configuration \
     '{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
   ```

   El resultado debería tener un aspecto similar al siguiente:

   ```
   {
       "DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
   }
   ```

# Paso 2: creación de un destino
<a name="CreateFirehoseStreamDestination"></a>

**importante**  
Todos los pasos de este procedimiento deben realizarse en la cuenta del destinatario de los datos de registro.

Cuando se crea el destino, CloudWatch Logs envía un mensaje de prueba al destino en nombre de la cuenta del destinatario. Cuando el filtro de suscripciones se active más adelante, CloudWatch Logs envía los eventos de registro al destino en nombre de la cuenta de origen.

**Para crear un destino**

1. Espere a que el flujo de Firehose que creó en [Paso 1: creación de un flujo de entrega de Firehose](CreateFirehoseStream.md) se active. Puede utilizar el siguiente comando para comprobar la **StreamDescription. StreamStatus**propiedad.

   ```
   aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
   ```

   Además, tome nota de la **DeliveryStreamDescription. DeliveryStreamValor ARN**, ya que tendrá que usarlo en un paso posterior. Resultado de ejemplo de este comando:

   ```
   {
       "DeliveryStreamDescription": {
           "DeliveryStreamName": "my-delivery-stream",
           "DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
           "DeliveryStreamStatus": "ACTIVE",
           "DeliveryStreamEncryptionConfiguration": {
               "Status": "DISABLED"
           },
           "DeliveryStreamType": "DirectPut",
           "VersionId": "1",
           "CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
           "Destinations": [
               {
                   "DestinationId": "destinationId-000000000001",
                   "S3DestinationDescription": {
                       "RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
                       "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
                       "BufferingHints": {
                           "SizeInMBs": 5,
                           "IntervalInSeconds": 300
                       },
                       "CompressionFormat": "UNCOMPRESSED",
                       "EncryptionConfiguration": {
                           "NoEncryptionConfig": "NoEncryption"
                       },
                       "CloudWatchLoggingOptions": {
                           "Enabled": false
                       }
                   },
                   "ExtendedS3DestinationDescription": {
                       "RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
                       "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
                       "BufferingHints": {
                           "SizeInMBs": 5,
                           "IntervalInSeconds": 300
                       },
                       "CompressionFormat": "UNCOMPRESSED",
                       "EncryptionConfiguration": {
                           "NoEncryptionConfig": "NoEncryption"
                       },
                       "CloudWatchLoggingOptions": {
                           "Enabled": false
                       },
                       "S3BackupMode": "Disabled"
                   }
               }
           ],
           "HasMoreDestinations": false
       }
   }
   ```

   El flujo de entrega puede tardar un minuto o dos en mostrarse en el estado activo.

1. Cuando la transmisión de entrega esté activa, crea la función de IAM que concederá a CloudWatch Logs el permiso para colocar datos en tu transmisión de Firehose. En primer lugar, tendrás que crear una política de confianza en un archivo **TrustPolicyFor\$1/** CWL.json. Utilice un editor de texto para crear esta política. Para obtener más información sobre CloudWatch los puntos de enlace de Logs, consulte los puntos de [enlace y las cuotas de Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html). 

   Esta política incluye una clave de contexto de condición global `aws:SourceArn` que especifica la `sourceAccountId` para ayudar a prevenir el problema de seguridad de suplente confuso. Si aún no conoce el ID de cuenta de origen en la primera llamada, le recomendamos que coloque el ARN de destino en el campo ARN de origen. En las llamadas posteriores, debe configurar el ARN de origen para que sea el ARN de origen real que recopiló desde la primera llamada. Para obtener más información, consulte [Prevención del suplente confuso](Subscriptions-confused-deputy.md). 

   ```
   {
       "Statement": {
           "Effect": "Allow",
           "Principal": {
               "Service": "logs.region.amazonaws.com"
           },
           "Action": "sts:AssumeRole",
           "Condition": {
               "StringLike": {
                   "aws:SourceArn": [
                       "arn:aws:logs:region:sourceAccountId:*",
                       "arn:aws:logs:region:recipientAccountId:*"
                   ]
               }
           }
        }
   }
   ```

1. Utilice **aws iam create-role** para crear el rol de IAM y especifique el archivo de política de confianza que acaba de crear. 

   ```
   aws iam create-role \
         --role-name CWLtoKinesisFirehoseRole \
         --assume-role-policy-document file://~/TrustPolicyForCWL.json
   ```

   A continuación, se muestra un ejemplo de la salida. Anote el valor de `Role.Arn` devuelto, ya que lo necesitará en un paso posterior.

   ```
   {
       "Role": {
           "Path": "/",
           "RoleName": "CWLtoKinesisFirehoseRole",
           "RoleId": "AROAR3BXASEKYJYWF243H",
           "Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
           "CreateDate": "2021-02-02T08:10:43+00:00",
           "AssumeRolePolicyDocument": {
               "Statement": {
                   "Effect": "Allow",
                   "Principal": {
                       "Service": "logs.region.amazonaws.com"
                   },
                   "Action": "sts:AssumeRole",
                   "Condition": {
                       "StringLike": {
                           "aws:SourceArn": [
                               "arn:aws:logs:region:sourceAccountId:*",
                               "arn:aws:logs:region:recipientAccountId:*"
                           ]
                       }
                   }
               }
           }
       }
   }
   ```

1. Cree una política de permisos para definir qué acciones puede realizar CloudWatch Logs en su cuenta. Primero, usa un editor de texto para crear una política de permisos en un archivo **\$1/ PermissionsFor CWL.json:**

   ```
   {
       "Statement":[
         {
           "Effect":"Allow",
           "Action":["firehose:*"],
           "Resource":["arn:aws:firehose:region:222222222222:*"]
         }
       ]
   }
   ```

1. Asocie la política de permisos con el rol mediante el siguiente comando:

   ```
   aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
   ```

1. Una vez que la transmisión de entrega de Firehose esté en estado activo y hayas creado la función de IAM, puedes crear el destino de los CloudWatch registros.

   1. Este paso no asociará una política de acceso a su destino y solo es el primer paso de los dos que completan la creación de un destino. Anote el ARN del nuevo destino que se devuelve en la carga, porque lo utilizará como `destination.arn` en un paso posterior.

      ```
      aws logs put-destination \                                                       
          --destination-name "testFirehoseDestination" \
          --target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
          --role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
      
      {
          "destination": {
              "destinationName": "testFirehoseDestination",
              "targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
              "roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
              "arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
      }
      ```

   1. Después de completar el paso previo, en la cuenta del destinatario de los datos de registro (222222222222), asocie una política de acceso con el destino.

      Esta política permite que la cuenta del remitente de los datos de registro (111111111111) tenga acceso al destino justo en la cuenta del destinatario de los datos de registro (222222222222). Puedes usar un editor de texto para colocar esta política en el archivo **\$1/ .json: AccessPolicy**

------
#### [ JSON ]

****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement" : [
          {
            "Sid" : "",
            "Effect" : "Allow",
            "Principal" : {
              "AWS" : "111111111111"
            },
            "Action" : "logs:PutSubscriptionFilter",
            "Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
          }
        ]
      }
      ```

------

   1. Esto crea una política que define quién tiene acceso de escritura al destino. Esta política debe especificar los **registros: PutSubscriptionFilter** acción para acceder al destino. Los usuarios entre varias cuentas utilizarán la acción **PutSubscriptionFilter** para enviar eventos de registro al destino:

      ```
      aws logs put-destination-policy \
          --destination-name "testFirehoseDestination" \
          --access-policy file://~/AccessPolicy.json
      ```

# Paso 3: Permisos Add/validate de IAM para el destino multicuenta
<a name="Subscription-Filter-CrossAccount-Permissions-Firehose"></a>

Según la lógica de evaluación de políticas AWS multicuenta, para acceder a cualquier recurso multicuenta (como una transmisión de Kinesis o Firehose utilizada como destino para un filtro de suscripciones), debe tener una política basada en la identidad en la cuenta remitente que proporcione acceso explícito al recurso de destino multicuenta. Para obtener más información sobre la lógica de evaluación de políticas, consulte [Lógica de evaluación de políticas entre cuentas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).

Puede adjuntar la política basada en la identidad al rol de IAM o al usuario de IAM que utilice para crear el filtro de suscripción. Esta política debe estar presente en la cuenta de envío. Si utiliza la función de administrador para crear el filtro de suscripciones, puede omitir este paso y continuar con [Paso 4: crear un filtro de suscripción](CreateSubscriptionFilter.md).

**Para agregar o validar los permisos de IAM necesarios para el uso entre cuentas**

1. Introduzca el siguiente comando para comprobar qué rol de IAM o usuario de IAM se utiliza para ejecutar los comandos de registro. AWS 

   ```
   aws sts get-caller-identity
   ```

   El comando devuelve un resultado similar al siguiente:

   ```
   {
   "UserId": "User ID",
   "Account": "sending account id",
   "Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
   }
   ```

   Anote el valor representado por *RoleName* o. *UserName*

1. Inicie sesión Consola de administración de AWS en la cuenta remitente y busque las políticas adjuntas con el rol de IAM o el usuario de IAM que aparecen en el resultado del comando que ingresó en el paso 1.

1. Compruebe que las políticas adjntas a este rol o usuario brindan permisos explícitos para llamar a `logs:PutSubscriptionFilter` en el recurso de destino entre cuentas.

   La siguiente política proporciona permisos para crear un filtro de suscripción en cualquier recurso de destino solo en una sola AWS cuenta, la cuenta: `999999999999`

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "AllowSubscriptionFiltersOnAnyResourceInOneSpecificAccount",
               "Effect": "Allow",
               "Action": "logs:PutSubscriptionFilter",
               "Resource": [
                   "arn:aws:logs:*:*:log-group:*",
                   "arn:aws:logs:*:123456789012:destination:*"
               ]
           }
       ]
   }
   ```

------

   La siguiente política proporciona permisos para crear un filtro de suscripción solo en un recurso de destino específico nombrado `sampleDestination` en una sola AWS cuenta, la cuenta`123456789012`:

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
           "Sid": "AllowSubscriptionFiltersOnSpecificResource",
               "Effect": "Allow",
               "Action": "logs:PutSubscriptionFilter",
               "Resource": [
                   "arn:aws:logs:*:*:log-group:*",
                   "arn:aws:logs:*:123456789012:destination:amzn-s3-demo-bucket"
               ]
           }
       ]
   }
   ```

------

# Paso 4: crear un filtro de suscripción
<a name="CreateSubscriptionFilterFirehose"></a>

Cambie a la cuenta de envío, que es 111111111111 en este ejemplo. Ahora creará el filtro de suscripción en la cuenta de envío. En este ejemplo, el filtro está asociado a un grupo de registros que contiene AWS CloudTrail eventos, de modo que cada actividad registrada con AWS las credenciales «Root» se envía al destino que creaste anteriormente. Para obtener más información sobre cómo enviar AWS CloudTrail eventos a los CloudWatch registros, consulte [Enviar CloudTrail eventos a los CloudWatch registros](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) en la *Guía del AWS CloudTrail usuario*.

Al introducir el siguiente comando, asegúrese de haber iniciado sesión como usuario de IAM o de utilizar el rol de IAM para el que agregó la política, en [Paso 3: Permisos Add/validate de IAM para el destino multicuenta](Subscription-Filter-CrossAccount-Permissions-Firehose.md).

```
aws logs put-subscription-filter \
    --log-group-name "aws-cloudtrail-logs-111111111111-300a971e" \                   
    --filter-name "firehose_test" \
    --filter-pattern "{$.userIdentity.type = AssumedRole}" \
    --destination-arn "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
```

El grupo de registros y el destino deben estar en la misma AWS región. Sin embargo, el destino puede apuntar a un AWS recurso, como un arroyo Firehose, que se encuentra en una región diferente.

# Validación del flujo de eventos de registro
<a name="ValidateLogEventFlowFirehose"></a>

Tras crear el filtro de suscripción, CloudWatch Logs reenvía todos los eventos de registro entrantes que coinciden con el patrón de filtrado al flujo de entrega de Firehose. Los datos comienzan a aparecer en su bucket de Amazon S3 en función del intervalo de tiempo de búfer que se establece en el flujo de entrega de Firehose. Una vez que haya transcurrido el tiempo suficiente, puede verificar los datos comprobando su bucket de Amazon S3. Escriba el siguiente comando para comprobar el bucket:

```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket' 
```

El resultado de ese comando será similar a lo siguiente:

```
{
    "Contents": [
        {
            "Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
            "LastModified": "2021-02-02T09:00:26+00:00",
            "ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
            "Size": 198,
            "StorageClass": "STANDARD",
            "Owner": {
                "DisplayName": "firehose+2test",
                "ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
            }
        }
    ]
}
```

Puede recuperar un objeto específico del bucket al introducir el siguiente comando. Reemplace el valor de `key` con el valor que encontró en el comando anterior.

```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```

Los datos en el objeto de Amazon S3 se comprimen con el formato gzip. Puede examinar los datos sin procesar desde la línea de comando mediante uno de los siguientes comandos:

Linux:

```
zcat testfile.gz
```

macOS:

```
zcat <testfile.gz
```

# Modificación de la suscripción al destino en tiempo de ejecución
<a name="ModifyDestinationMembershipFirehose"></a>

Puede encontrar situaciones en las que tenga que agregar o eliminar remitentes de registros de un destino de su propiedad. Puedes usar la **PutDestinationPolicy**acción en tu destino con una nueva política de acceso. En el siguiente ejemplo, una cuenta **111111111111** agregada anteriormente deja de enviar datos de registro y se habilita la cuenta **333333333333**.

1. Busca la política que está asociada actualmente con el destino **TestDestination** y anota lo siguiente: **AccessPolicy**

   ```
   aws logs describe-destinations \
       --destination-name-prefix "testFirehoseDestination"
   
   {
       "destinations": [
           {
               "destinationName": "testFirehoseDestination",
               "targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
               "roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
               "accessPolicy": "{\n  \"Version\" : \"2012-10-17\",\n  \"Statement\" : [\n    {\n      \"Sid\" : \"\",\n      \"Effect\" : \"Allow\",\n      \"Principal\" : {\n        \"AWS\" : \"111111111111 \"\n      },\n      \"Action\" : \"logs:PutSubscriptionFilter\",\n      \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n    }\n  ]\n}\n\n",
               "arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
               "creationTime": 1612256124430
           }
       ]
   }
   ```

1. Actualice la política para reflejar que la cuenta **111111111111** está detenida y que la cuenta **333333333333** está habilitada. Coloca esta política en el archivo **\$1/ .json: NewAccessPolicy**

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement" : [
       {
         "Sid" : "",
         "Effect" : "Allow",
         "Principal" : {
           "AWS" : "333333333333 "
         },
         "Action" : "logs:PutSubscriptionFilter",
         "Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
       }
     ]
   }
   ```

------

1. Use el siguiente comando para asociar la política definida en el **NewAccessPolicyarchivo.json** con el destino:

   ```
   aws logs put-destination-policy \
       --destination-name "testFirehoseDestination" \                                                                              
       --access-policy file://~/NewAccessPolicy.json
   ```

   Esto finalmente deshabilita los eventos de registro del ID de cuenta **111111111111**. Los eventos de registro del ID de cuenta **333333333333** empiezan a fluir al destino en cuanto el propietario de la cuenta **333333333333** crea un filtro de suscripción.

# Suscripciones a nivel de cuenta multirregional mediante Amazon Kinesis Data Streams
<a name="CrossAccountSubscriptions-Kinesis-Account"></a>

Al crear una suscripción entre cuentas, puede especificar una única cuenta o una organización para que sea el remitente. Si especifica una organización, este procedimiento permite que todas las cuentas de la organización envíen registros a la cuenta de receptor.

Para compartir los datos de registro entre cuentas, es necesario establecer un emisor y receptor de datos de registro:
+ **Remitente de los datos de registro**: obtiene la información de destino del destinatario e informa a CloudWatch Logs de que está listo para enviar sus eventos de registro al destino especificado. En los procedimientos descritos en el resto de esta sección, se muestra al remitente de los datos de registro con un número de AWS cuenta ficticio de 1111.

  Si va a tener varias cuentas de una organización que envíen registros a una cuenta de destinatario, puede crear una política que otorgue a todas las cuentas de la organización el permiso para enviar registros a la cuenta de destinatario. Aún tiene que configurar filtros de suscripción independientes para cada cuenta de remitente.
+ **Destinatario de los datos de registro**: configura un destino que encapsula una transmisión de Amazon Kinesis Data Streams y permite a CloudWatch Logs saber que el destinatario desea recibir los datos de registro. A continuación, el destinatario comparte la información sobre este destino con el remitente. En los procedimientos que se describen en el resto de esta sección, se muestra al destinatario de los datos de registro con un número de AWS cuenta ficticio, el número de cuenta 999.

Para empezar a recibir eventos de registro de usuarios con varias cuentas, el destinatario de los datos de registro crea primero un destino de CloudWatch registros. Cada destino consta de los siguientes elementos fundamentales:

**Nombre de destino**  
El nombre del destino que desea crear.

**ARN de destino**  
El nombre del recurso de Amazon (ARN) del AWS recurso que quieres usar como destino del feed de suscripción.

**ARN del rol**  
Un rol AWS Identity and Access Management (IAM) que otorga a CloudWatch Logs los permisos necesarios para colocar los datos en la transmisión elegida.

**Política de acceso**  
Un documento de política de IAM (en formato JSON, escrito con la gramática de política de IAM) que rige el conjunto de los usuarios a los que se les permite escribir en su destino.

**nota**  
El grupo de registros y el destino deben estar en la misma AWS región. Sin embargo, el AWS recurso al que apunta el destino puede estar ubicado en una región diferente. En los ejemplos de las secciones siguientes, todos los recursos específicos de una región se crean en EE. UU. Este (Norte de Virginia).

**Topics**
+ [Configuración de una nueva suscripción entre cuentas](Cross-Account-Log_Subscription-New-Account.md)
+ [Actualización de una suscripción entre cuentas existente](Cross-Account-Log_Subscription-Update-Account.md)

# Configuración de una nueva suscripción entre cuentas
<a name="Cross-Account-Log_Subscription-New-Account"></a>

Siga los pasos de estas secciones para configurar una nueva suscripción de registro entre cuentas.

**Topics**
+ [Paso 1: crear un destino](CreateDestination-Account.md)
+ [Paso 2: (solo si se utiliza una organización) crear un rol de IAM](CreateSubscriptionFilter-IAMrole-Account.md)
+ [Paso 3: crear una política de filtrado de suscripciones a nivel de cuenta](CreateSubscriptionFilter-Account.md)
+ [Validación del flujo de eventos de registro](ValidateLogEventFlow-Account.md)
+ [Modificación de la suscripción al destino en tiempo de ejecución](ModifyDestinationMembership-Account.md)

# Paso 1: crear un destino
<a name="CreateDestination-Account"></a>

**importante**  
Todos los pasos de este procedimiento deben realizarse en la cuenta del destinatario de los datos de registro.

En este ejemplo, la cuenta receptora de los datos de registro tiene un identificador de AWS cuenta de 10000 9999, mientras que el identificador de la AWS cuenta del remitente de los datos de registro es 1111.

 En este ejemplo, se crea un destino mediante una transmisión de Amazon Kinesis Data Streams RecipientStream llamada y una función que CloudWatch permite a Logs escribir datos en ella. 

Cuando se crea el destino, CloudWatch Logs envía un mensaje de prueba al destino en nombre de la cuenta del destinatario. Cuando el filtro de suscripciones se active más adelante, CloudWatch Logs envía los eventos de registro al destino en nombre de la cuenta de origen.

**Para crear un destino**

1. En la cuenta del destinatario, cree una transmisión de destino en Amazon Kinesis Data Streams. En el símbolo del sistema, escriba:

   ```
   aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
   ```

1. Espere hasta que el flujo de se active. **Puede utilizar el comando **aws kinesis describe-stream** para comprobar la. StreamDescription StreamStatus**propiedad. Además, tome nota del valor **StreamDescription.streamArn porque** lo pasará a CloudWatch Logs más adelante:

   ```
   aws kinesis describe-stream --stream-name "RecipientStream"
   {
     "StreamDescription": {
       "StreamStatus": "ACTIVE",
       "StreamName": "RecipientStream",
       "StreamARN": "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream",
       "Shards": [
         {
           "ShardId": "shardId-000000000000",
           "HashKeyRange": {
             "EndingHashKey": "34028236692093846346337460743176EXAMPLE",
             "StartingHashKey": "0"
           },
           "SequenceNumberRange": {
             "StartingSequenceNumber": "4955113521868881845667950383198145878459135270218EXAMPLE"
           }
         }
       ]
     }
   }
   ```

   El flujo puede tardar un minuto o dos en mostrarse en el estado activo.

1. Crea el rol de IAM que otorga a CloudWatch Logs el permiso para colocar datos en tu transmisión. En primer lugar, tendrás que crear una política de confianza en un archivo **\$1/ TrustPolicyFor** CWL.json. Utilice un editor de texto para crear este archivo de política; no utilice la consola de IAM.

   Esta política incluye una clave de contexto de condición global `aws:SourceArn` que especifica la `sourceAccountId` para ayudar a prevenir el problema de seguridad de suplente confuso. Si aún no conoce el ID de cuenta de origen en la primera llamada, le recomendamos que coloque el ARN de destino en el campo ARN de origen. En las llamadas posteriores, debe configurar el ARN de origen para que sea el ARN de origen real que recopiló desde la primera llamada. Para obtener más información, consulte [Prevención del suplente confuso](Subscriptions-confused-deputy.md). 

   ```
   {
       "Statement": {
           "Effect": "Allow",
           "Principal": {
               "Service": "logs.amazonaws.com"
           },
           "Condition": {
               "StringLike": {
                   "aws:SourceArn": [
                       "arn:aws:logs:region:sourceAccountId:*",
                       "arn:aws:logs:region:recipientAccountId:*"
                   ]
               }
           },
           "Action": "sts:AssumeRole"
       }
   }
   ```

1. Ejecute el comando **aws iam create-role** para crear el rol de IAM y especifique el archivo de política de confianza. Toma nota del valor Role.Arn devuelto porque también se pasará a Logs más adelante: CloudWatch 

   ```
   aws iam create-role \
   --role-name CWLtoKinesisRole \
   --assume-role-policy-document file://~/TrustPolicyForCWL.json
   
   {
       "Role": {
           "AssumeRolePolicyDocument": {
               "Statement": {
                   "Action": "sts:AssumeRole",
                   "Effect": "Allow",
                   "Condition": {
                       "StringLike": {
                           "aws:SourceArn": [
                               "arn:aws:logs:region:sourceAccountId:*",
                               "arn:aws:logs:region:recipientAccountId:*"
                           ]
                       }
                   },
                   "Principal": {
                       "Service": "logs.amazonaws.com"
                   }
               }
           },
           "RoleId": "AAOIIAH450GAB4HC5F431",
           "CreateDate": "2023-05-29T13:46:29.431Z",
           "RoleName": "CWLtoKinesisRole",
           "Path": "/",
           "Arn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
       }
   }
   ```

1. Crea una política de permisos para definir qué acciones puede realizar CloudWatch Logs en tu cuenta. Primero, usa un editor de texto para crear una política de permisos en un archivo **\$1/ PermissionsFor CWL.json:**

   ```
   {
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "kinesis:PutRecord",
         "Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
       }
     ]
   }
   ```

1. Asocie la política de permisos al rol mediante el comando **aws** iam: put-role-policy

   ```
   aws iam put-role-policy \
       --role-name CWLtoKinesisRole \
       --policy-name Permissions-Policy-For-CWL \
       --policy-document file://~/PermissionsForCWL.json
   ```

1. Una vez que la transmisión esté en estado activo y haya creado el rol de IAM, puede crear el destino de los CloudWatch registros.

   1. Este paso no asocia una política de acceso a su destino y solo es el primer paso de los dos que completan la creación de un destino. Anote el valor de **DestinationArn** que se devuelve en la carga:

      ```
      aws logs put-destination \
          --destination-name "testDestination" \
          --target-arn "arn:aws:kinesis:region:999999999999:stream/RecipientStream" \
          --role-arn "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
      
      {
        "DestinationName" : "testDestination",
        "RoleArn" : "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
        "DestinationArn" : "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
        "TargetArn" : "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream"
      }
      ```

   1. Una vez que se haya completado el paso 7a, en la cuenta del destinatario de los datos de registro, asocie una política de acceso con el destino. Esta política debe especificar los **registros:** la PutSubscriptionFilter acción y otorga permiso a la cuenta del remitente para acceder al destino.

      La política concede permiso a la AWS cuenta que envía los registros. Puede especificar solo esta cuenta en la política o, si la cuenta de remitente es miembro de una organización, la política puede especificar el ID de organización de la organización. De esta forma, puede crear una sola política para permitir que varias cuentas de una organización envíen registros a esta cuenta de destino.

      Utilice un editor de texto para crear un archivo denominado `~/AccessPolicy.json` con una de las siguientes declaraciones de política.

      Este primer ejemplo de política permite a todas las cuentas de la organización que tienen un ID de `o-1234567890` enviar registros a la cuenta de destinatario.

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Principal": "*",
                  "Action": [
                      "logs:PutSubscriptionFilter",
                      "logs:PutAccountPolicy"
                  ],
                  "Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
                  "Condition": {
                      "StringEquals": {
                          "aws:PrincipalOrgID": [
                              "o-1234567890"
                          ]
                      }
                  }
              }
          ]
      }
      ```

------

      En el siguiente ejemplo, solo se permite que la cuenta del remitente de los datos de registro (111111111111) envíe los registros a la cuenta del destinatario de los datos de registro.

------
#### [ JSON ]

****  

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Sid": "",
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "111111111111"
                  },
                  "Action": [
                      "logs:PutSubscriptionFilter",
                      "logs:PutAccountPolicy"
                  ],
                  "Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
              }
          ]
      }
      ```

------

   1. Adjunte la política que creó en el paso anterior al destino.

      ```
      aws logs put-destination-policy \
          --destination-name "testDestination" \
          --access-policy file://~/AccessPolicy.json
      ```

      Esta política de acceso permite a los usuarios de la AWS cuenta con el ID 1111 llamar al destino con el ARN arn:aws:logs **PutSubscriptionFilter**::55559999:Destination:TestDestination. *region* Se PutSubscriptionFilter rechazará cualquier intento de otro usuario de llamar a este destino.

      Para validar los privilegios de un usuario con una política de acceso, consulte [Uso del validador de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) en la *Guía del usuario de IAM*.

Cuando hayas terminado, si los estás utilizando AWS Organizations para tus permisos multicuenta, sigue los pasos que se indican. [Paso 2: (solo si se utiliza una organización) crear un rol de IAM](CreateSubscriptionFilter-IAMrole-Account.md) Si está concediendo permisos directamente a la otra cuenta en lugar de utilizar Organizations, puede omitir ese paso y continuar con [Paso 3: crear una política de filtrado de suscripciones a nivel de cuenta](CreateSubscriptionFilter-Account.md).

# Paso 2: (solo si se utiliza una organización) crear un rol de IAM
<a name="CreateSubscriptionFilter-IAMrole-Account"></a>

En la sección anterior, si ha creado el destino mediante una política de acceso que otorga permisos a la organización en la que está esa cuenta `111111111111`, en lugar de conceder permisos directamente a la cuenta `111111111111`, siga los pasos de esta sección. De lo contrario, puede ir directamente a [Paso 3: crear una política de filtrado de suscripciones a nivel de cuenta](CreateSubscriptionFilter-Account.md).

Los pasos de esta sección crean un rol de IAM, que CloudWatch puede asumir y validar si la cuenta del remitente tiene permiso para crear un filtro de suscripción para el destino del destinatario. 

Realice los pasos de esta sección en la cuenta del remitente. El rol debe existir en la cuenta del remitente y usted especifica el ARN de este rol en el filtro de suscripción. En este ejemplo, la cuenta del remitente es `111111111111`.

**Para crear la función de IAM necesaria para las suscripciones de registros multicuenta, utilice AWS Organizations**

1. Cree la siguiente política de confianza en un archivo `/TrustPolicyForCWLSubscriptionFilter.json`. Utilice un editor de texto para crear este archivo de política; no utilice la consola de IAM.

   ```
   {
     "Statement": {
       "Effect": "Allow",
       "Principal": { "Service": "logs.amazonaws.com" },
       "Action": "sts:AssumeRole"
     }
   }
   ```

1. Cree un rol de IAM que utilice la política. Anote el valor `Arn` que devuelve el comando, ya que lo necesitará más tarde en este procedimiento. En este ejemplo, usaremos `CWLtoSubscriptionFilterRole` para el nombre del rol que estamos creando.

   ```
   aws iam create-role \ 
        --role-name CWLtoSubscriptionFilterRole \ 
        --assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
   ```

1. Cree una política de permisos para definir las acciones que CloudWatch Logs puede realizar en su cuenta.

   1. En primer lugar, utilice un editor de texto para crear la siguiente política de permisos en un archivo denominado: `~/PermissionsForCWLSubscriptionFilter.json`.

      ```
      { 
          "Statement": [ 
              { 
                  "Effect": "Allow", 
                  "Action": "logs:PutLogEvents", 
                  "Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*" 
              } 
          ] 
      }
      ```

   1. Ingrese el siguiente comando para asociar la política de permisos que acaba de crear con el rol que creó en el paso 2.

      ```
      aws iam put-role-policy  
          --role-name CWLtoSubscriptionFilterRole  
          --policy-name Permissions-Policy-For-CWL-Subscription-filter 
          --policy-document file://~/PermissionsForCWLSubscriptionFilter.json
      ```

Cuando haya terminado, puede proceder a [Paso 3: crear una política de filtrado de suscripciones a nivel de cuenta](CreateSubscriptionFilter-Account.md).

# Paso 3: crear una política de filtrado de suscripciones a nivel de cuenta
<a name="CreateSubscriptionFilter-Account"></a>

Después de crear un destino, la cuenta del destinatario de los datos de registro puede compartir el ARN de destino (arn:aws:logs:us-east-1:999999999999:destination:testDestination) con otras cuentas de AWS para que puedan enviar eventos de registro al mismo destino. A continuación, los usuarios de estas otras cuentas remitentes crean un filtro de suscripción en sus grupos de registro respectivos frente a este destino. El filtro de suscripción inicia de inmediato el flujo de datos de registro en tiempo real desde el grupo de registro elegido al destino especificado.

**nota**  
Si concede permisos para el filtro de suscripción a toda una organización, tendrá que usar el ARN del rol de IAM en el que creó [Paso 2: (solo si se utiliza una organización) crear un rol de IAM](CreateSubscriptionFilter-IAMrole-Account.md).

En el siguiente ejemplo, se crea una política de filtrado de suscripciones a nivel de cuenta en una cuenta de envío. El filtro se asocia a la cuenta `111111111111` del remitente para que cada evento de registro que coincida con el filtro y los criterios de selección se envíe al destino creado anteriormente. Ese destino encapsula una transmisión llamada "». RecipientStream

El campo `selection-criteria` es opcional, pero es importante usarlo si quiere excluir de un filtro de suscripción los grupos de registro que pueden provocar una recursión infinita de registros. Para obtener más información sobre este problema y determinar qué grupos de registro excluir, consulte [Prevención de recursión de registros](Subscriptions-recursion-prevention.md). Actualmente, NOT IN es el único operador compatible para `selection-criteria`.

```
aws logs put-account-policy \
    --policy-name "CrossAccountStreamsExamplePolicy" \
    --policy-type "SUBSCRIPTION_FILTER_POLICY" \
    --policy-document '{"DestinationArn":"arn:aws:logs:region:999999999999:destination:testDestination", "FilterPattern": "", "Distribution": "Random"}' \
    --selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
    --scope "ALL"
```

Los grupos de registro y el destino de la cuenta del remitente deben estar en la misma región de AWS . Sin embargo, el destino puede apuntar a un AWS recurso, como una transmisión de Amazon Kinesis Data Streams, que se encuentre en una región diferente.

# Validación del flujo de eventos de registro
<a name="ValidateLogEventFlow-Account"></a>

Tras crear la política de filtrado de suscripciones a nivel de cuenta, CloudWatch Logs reenvía todos los eventos de registro entrantes que coincidan con el patrón de filtrado y los criterios de selección a la transmisión encapsulada en la transmisión de destino denominada «». **RecipientStream** El propietario del destino puede comprobar que esto está ocurriendo utilizando el get-shard-iterator comando **aws kinesis** para capturar un fragmento de Amazon Kinesis Data Streams y utilizando **el comando aws kinesis** get-records para obtener algunos registros de Amazon Kinesis Data Streams:

```
aws kinesis get-shard-iterator \
      --stream-name RecipientStream \
      --shard-id shardId-000000000000 \
      --shard-iterator-type TRIM_HORIZON

{
    "ShardIterator":
    "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
}

aws kinesis get-records \
      --limit 10 \
      --shard-iterator
      "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
```

**nota**  
Puede que tenga que volver a ejecutar el `get-records` comando varias veces antes de que Amazon Kinesis Data Streams comience a devolver datos.

Debería ver una respuesta con una serie de registros de Amazon Kinesis Data Streams. El atributo de datos del registro de Amazon Kinesis Data Streams se comprime en formato gzip y, a continuación, se codifica en base64. Puede examinar los datos sin procesar desde la línea de comando utilizando el siguiente comando de Unix:

```
echo -n "<Content of Data>" | base64 -d | zcat
```

Los datos descodificados y descomprimidos en base64 se formatean como JSON con la siguiente estructura:

```
{
    "owner": "111111111111",
    "logGroup": "CloudTrail/logs",
    "logStream": "111111111111_CloudTrail/logs_us-east-1",
    "subscriptionFilters": [
        "RecipientStream"
    ],
    "messageType": "DATA_MESSAGE",
    "logEvents": [
        {
            "id": "3195310660696698337880902507980421114328961542429EXAMPLE",
            "timestamp": 1432826855000,
            "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
        },
        {
            "id": "3195310660696698337880902507980421114328961542429EXAMPLE",
            "timestamp": 1432826855000,
            "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
        },
        {
            "id": "3195310660696698337880902507980421114328961542429EXAMPLE",
            "timestamp": 1432826855000,
            "message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
        }
    ]
}
```

Los elementos clave en la estructura de datos anterior son los siguientes:

**messageType**  
Los mensajes de datos utilizarán el tipo “DATA\$1MESSAGE”. A veces, CloudWatch los registros pueden emitir registros de Amazon Kinesis Data Streams del tipo «CONTROL\$1MESSAGE», principalmente para comprobar si se puede acceder al destino.

**owner**  
El ID de AWS cuenta de los datos de registro originarios.

**logGroup**  
El nombre del grupo de registro de los datos de registro de origen.

**logStream**  
El nombre del flujo de registros de los datos de registro de origen.

**subscriptionFilters**  
La lista de nombres de filtros de suscripción que coincide con los datos de registro de origen.

**logEvents**  
Los datos de registro reales, representados como un conjunto de registros de eventos de registro. La propiedad “id” es un identificador único de cada evento de registro.

**policyLevel**  
Es el nivel en el que se aplicó la política. “ACCOUNT\$1LEVEL\$1POLICY” es el `policyLevel` de la política de filtrado de suscripciones a nivel de cuenta.

# Modificación de la suscripción al destino en tiempo de ejecución
<a name="ModifyDestinationMembership-Account"></a>

Puede encontrar situaciones en las que tenga que añadir o eliminar la pertenencia de algunos usuarios de un destino de su propiedad. Puede utilizar el comando `put-destination-policy` en su destino con la nueva política de acceso. En el siguiente ejemplo, una cuenta **111111111111** añadida anteriormente deja de enviar más datos de registro y se habilita la cuenta **222222222222**.

1. Busca la política que está asociada actualmente con el destino **TestDestination** y anota lo siguiente: **AccessPolicy**

   ```
   aws logs describe-destinations \
       --destination-name-prefix "testDestination"
   
   {
    "Destinations": [
      {
        "DestinationName": "testDestination",
        "RoleArn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
        "DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
        "TargetArn": "arn:aws:kinesis:region:999999999999:stream/RecipientStream",
        "AccessPolicy": "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\", \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"111111111111\"}, \"Action\": \"logs:PutSubscriptionFilter\", \"Resource\": \"arn:aws:logs:region:999999999999:destination:testDestination\"}] }"
      }
    ]
   }
   ```

1. Actualice la política para reflejar que la cuenta **111111111111** está detenida y que la cuenta **222222222222** está habilitada. Coloca esta política en el archivo **\$1/ .json: NewAccessPolicy**

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "",
               "Effect": "Allow",
               "Principal": {
                   "AWS": "222222222222"
               },
               "Action": [
                   "logs:PutSubscriptionFilter",
                   "logs:PutAccountPolicy"
               ],
               "Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
           }
       ]
   }
   ```

------

1. Llame **PutDestinationPolicy**para asociar la política definida en el **NewAccessPolicyarchivo.json** con el destino:

   ```
   aws logs put-destination-policy \
   --destination-name "testDestination" \
   --access-policy file://~/NewAccessPolicy.json
   ```

   Esto finalmente deshabilitará los eventos de registro del ID de cuenta **111111111111**. Los eventos de registro del ID de cuenta **222222222222** empiezan a fluir al destino en cuanto el propietario de la cuenta **222222222222** crea un filtro de suscripción.

# Actualización de una suscripción entre cuentas existente
<a name="Cross-Account-Log_Subscription-Update-Account"></a>

Si actualmente tiene una suscripción de registros entre cuentas en la que la cuenta de destino concede permisos solo a cuentas de remitentes específicas y desea actualizar esta suscripción para que la cuenta de destino conceda acceso a todas las cuentas de una organización, siga los pasos de esta sección.

**Topics**
+ [Paso 1: actualizar los filtros de suscripción](Cross-Account-Log_Subscription-Update-filter-Account.md)
+ [Paso 2: actualizar la política de acceso de destino existente](Cross-Account-Log_Subscription-Update-policy-Account.md)

# Paso 1: actualizar los filtros de suscripción
<a name="Cross-Account-Log_Subscription-Update-filter-Account"></a>

**nota**  
Este paso solo es necesario para las suscripciones entre cuentas de los registros creados por los servicios enumerados en [Habilitar el registro desde AWS los servicios](AWS-logs-and-resource-policy.md). Si no está trabajando con registros creados por uno de estos grupos de registro, puede ir directo a [Paso 2: actualizar la política de acceso de destino existente](Cross-Account-Log_Subscription-Update-policy-Account.md).

En algunos casos, debe actualizar los filtros de suscripción en todas las cuentas de remitente que envían registros a la cuenta de destino. La actualización añade una función de IAM, que permite CloudWatch asumir y validar que la cuenta del remitente tiene permiso para enviar los registros a la cuenta del destinatario.

Siga los pasos de esta sección para cada cuenta de remitente que desee actualizar para utilizar el ID de organización para los permisos de suscripción entre cuentas.

En los ejemplos de esta sección, dos cuentas, `111111111111` y `222222222222`, ya cuentan con filtros de suscripción creados para enviar registros a la cuenta `999999999999`. Los valores de filtro de suscripción existentes son los siguientes:

```
## Existing Subscription Filter parameter values
{
    "DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
    "FilterPattern": "{$.userIdentity.type = Root}",
    "Distribution": "Random"
}
```

Si tiene que encontrar los valores de los parámetros de filtro de suscripción actuales, ingrese el siguiente comando.

```
aws logs describe-account-policies \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-name "CrossAccountStreamsExamplePolicy"
```

**Para actualizar un filtro de suscripción y empezar a usar la organización IDs para los permisos de registro entre cuentas**

1. Cree la siguiente política de confianza en un archivo `~/TrustPolicyForCWL.json`. Utilice un editor de texto para crear este archivo de política; no utilice la consola de IAM.

   ```
   {
     "Statement": {
       "Effect": "Allow",
       "Principal": { "Service": "logs.amazonaws.com" },
       "Action": "sts:AssumeRole"
     }
   }
   ```

1. Cree un rol de IAM que utilice la política. Anote el valor `Arn` del valor `Arn` que devuelve el comando, ya que lo necesitará más tarde en este procedimiento. En este ejemplo, usaremos `CWLtoSubscriptionFilterRole` para el nombre del rol que estamos creando.

   ```
   aws iam create-role 
       \ --role-name CWLtoSubscriptionFilterRole 
       \ --assume-role-policy-document file://~/TrustPolicyForCWL.json
   ```

1. Crea una política de permisos para definir las acciones que CloudWatch Logs puede realizar en tu cuenta.

   1. En primer lugar, utilice un editor de texto para crear la siguiente política de permisos en un archivo denominado: `/PermissionsForCWLSubscriptionFilter.json`.

      ```
      { 
          "Statement": [ 
              { 
                  "Effect": "Allow", 
                  "Action": "logs:PutLogEvents", 
                  "Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*" 
              } 
          ] 
      }
      ```

   1. Ingrese el siguiente comando para asociar la política de permisos que acaba de crear con el rol que creó en el paso 2.

      ```
      aws iam put-role-policy 
          --role-name CWLtoSubscriptionFilterRole 
          --policy-name Permissions-Policy-For-CWL-Subscription-filter 
          --policy-document file://~/PermissionsForCWLSubscriptionFilter.json
      ```

1. Introduzca el siguiente comando para actualizar la política de filtrado de suscripciones.

   ```
   aws logs put-account-policy \
       --policy-name "CrossAccountStreamsExamplePolicy" \
       --policy-type "SUBSCRIPTION_FILTER_POLICY" \
       --policy-document '{"DestinationArn":"arn:aws:logs:region:999999999999:destination:testDestination", "FilterPattern": "{$.userIdentity.type = Root}", "Distribution": "Random"}' \
       --selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
       --scope "ALL"
   ```

# Paso 2: actualizar la política de acceso de destino existente
<a name="Cross-Account-Log_Subscription-Update-policy-Account"></a>

Después de actualizar los filtros de suscripción en todas las cuentas de remitente, puede actualizar la política de acceso de destino en la cuenta de destinatario.

En los ejemplos siguientes, la cuenta de destinatario es `999999999999` y el destino se llama `testDestination`.

La actualización permite que todas las cuentas que forman parte de la organización con ID `o-1234567890` envíen registros a la cuenta de destinatario. Solo las cuentas que tienen filtros de suscripción creados enviarán registros a la cuenta del destinatario.

**Para actualizar la política de acceso de destino en la cuenta de destinatario a fin de empezar a utilizar un ID de organización para obtener permisos**

1. En la cuenta del destinatario, utilice un editor de texto para crear un archivo `~/AccessPolicy.json` con el siguiente contenido.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "",
               "Effect": "Allow",
               "Principal": "*",
               "Action": [
                   "logs:PutSubscriptionFilter",
                   "logs:PutAccountPolicy"
               ],
               "Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
               "Condition": {
                   "StringEquals": {
                       "aws:PrincipalOrgID": [
                           "o-1234567890"
                       ]
                   }
               }
           }
       ]
   }
   ```

------

1. Ingrese el siguiente comando para adjuntar la política que acaba de crear al destino existente. Para actualizar un destino para usar una política de acceso con un identificador de organización en lugar de una política de acceso que muestre una AWS cuenta específica IDs, incluye el `force` parámetro.
**aviso**  
Si está trabajando con registros enviados por uno de los AWS servicios incluidos en la lista[Habilitar el registro desde AWS los servicios](AWS-logs-and-resource-policy.md), antes de realizar este paso, debe haber actualizado los filtros de suscripción de todas las cuentas de remitentes, tal y como se explica en la sección[Paso 1: actualizar los filtros de suscripción](Cross-Account-Log_Subscription-Update-filter-Account.md).

   ```
   aws logs put-destination-policy 
       \ --destination-name "testDestination" 
       \ --access-policy file://~/AccessPolicy.json
       \ --force
   ```

# Suscripciones a nivel de cuenta entre cuentas y regiones mediante Firehose
<a name="CrossAccountSubscriptions-Firehose-Account"></a>

Para compartir los datos de registro entre cuentas, es necesario establecer un emisor y receptor de datos de registro:
+ **Remitente de los datos de registro**: obtiene la información de destino del destinatario e informa a CloudWatch Logs de que está listo para enviar sus eventos de registro al destino especificado. En los procedimientos descritos en el resto de esta sección, se muestra al remitente de los datos de registro con un número de AWS cuenta ficticio de 1111.
+ **Destinatario de los datos de registro**: configura un destino que encapsula una transmisión de Amazon Kinesis Data Streams y permite a CloudWatch Logs saber que el destinatario desea recibir los datos de registro. A continuación, el destinatario comparte la información sobre este destino con el remitente. En los procedimientos descritos en el resto de esta sección, se muestra al destinatario de los datos de registro con un número de AWS cuenta ficticio, 222222222222.

En el ejemplo de esta sección, se utiliza un flujo de entrega de Firehose con almacenamiento de Amazon S3. También puede configurar flujos de entrega de Firehose con diferentes parámetros. Para obtener más información, consulte [Creación de un flujo de entrega de Firehose](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).

**nota**  
El grupo de registros y el destino deben estar en la misma AWS región. Sin embargo, el AWS recurso al que apunta el destino puede estar ubicado en una región diferente.

**nota**  
 Se admite el filtro de suscripción de Firehose para el flujo de entrega de una ***misma cuenta*** y ***entre regiones***. 

**Topics**
+ [Paso 1: creación de un flujo de entrega de Firehose](CreateFirehoseStream-Account.md)
+ [Paso 2: creación de un destino](CreateFirehoseStreamDestination-Account.md)
+ [Paso 3: crear una política de filtrado de suscripciones a nivel de cuenta](CreateSubscriptionFilterFirehose-Account.md)
+ [Validación del flujo de eventos de registro](ValidateLogEventFlowFirehose-Account.md)
+ [Modificación de la suscripción al destino en tiempo de ejecución](ModifyDestinationMembershipFirehose-Account.md)

# Paso 1: creación de un flujo de entrega de Firehose
<a name="CreateFirehoseStream-Account"></a>

**importante**  
 Antes de realizar los siguientes pasos, debe utilizar una política de acceso para que Firehose pueda acceder a su bucket de Amazon S3. Para obtener más información, consulte [Control del acceso](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) en la *Guía para desarrolladores de Amazon Data Firehose*.   
 Todos los pasos en esta sección (Paso 1) deben realizarse en la cuenta del destinatario de los datos de registro.   
 En los ejemplos siguientes, se utiliza Este de EE. UU. (Norte de Virginia). Reemplace esta región por la región correcta para su implementación. 

**Creación de un flujo de entrega de Firehose que se utilice como destino**

1. Cree un bucket de Amazon S3:

   ```
   aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
   ```

1. Cree el rol de IAM que concede permiso a Firehose para incluir datos en el bucket.

   1. En primer lugar, utilice un editor de texto para crear una política de confianza en un archivo `~/TrustPolicyForFirehose.json`.

      ```
      { "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
      ```

   1. Cree el rol de IAM y especifique el archivo de política de confianza que acaba de crear.

      ```
      aws iam create-role \ 
          --role-name FirehosetoS3Role \ 
          --assume-role-policy-document file://~/TrustPolicyForFirehose.json
      ```

   1. El resultado de este comando debería ser similar a lo siguiente. Haga una nota del nombre del rol y del ARN del rol.

      ```
      {
          "Role": {
              "Path": "/",
              "RoleName": "FirehosetoS3Role",
              "RoleId": "AROAR3BXASEKW7K635M53",
              "Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
              "CreateDate": "2021-02-02T07:53:10+00:00",
              "AssumeRolePolicyDocument": {
                  "Statement": {
                      "Effect": "Allow",
                      "Principal": {
                          "Service": "firehose.amazonaws.com"
                      },
                      "Action": "sts:AssumeRole",
                      "Condition": {
                          "StringEquals": {
                              "sts:ExternalId": "222222222222"
                          }
                      }
                  }
              }
          }
      }
      ```

1. Cree una política de permisos para definir las acciones que Firehose puede realizar en su cuenta.

   1. En primer lugar, utilice un editor de texto para crear la siguiente política de permisos en un archivo denominado: `~/PermissionsForFirehose.json`. Según el caso de uso, es posible que tenga que agregar más permisos a este archivo.

      ```
      {
          "Statement": [{
              "Effect": "Allow",
              "Action": [
                  "s3:PutObject",
                  "s3:PutObjectAcl",
                  "s3:ListBucket"
              ],
              "Resource": [
                  "arn:aws:s3:::amzn-s3-demo-bucket",
                  "arn:aws:s3:::amzn-s3-demo-bucket/*"
              ]
          }]
      }
      ```

   1. Ingrese el siguiente comando para asociar la política de permisos que acaba de crear con el rol de IAM.

      ```
      aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
      ```

1. Introduzca el comando siguiente para crear el flujo de entrega de Firehose. Sustituya *my-role-arn* y *amzn-s3-demo-bucket2-arn* por los valores correctos para su implementación.

   ```
   aws firehose create-delivery-stream \
      --delivery-stream-name 'my-delivery-stream' \
      --s3-destination-configuration \
     '{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
   ```

   El resultado debería tener un aspecto similar al siguiente:

   ```
   {
       "DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
   }
   ```

# Paso 2: creación de un destino
<a name="CreateFirehoseStreamDestination-Account"></a>

**importante**  
Todos los pasos de este procedimiento deben realizarse en la cuenta del destinatario de los datos de registro.

Cuando se crea el destino, CloudWatch Logs envía un mensaje de prueba al destino en nombre de la cuenta del destinatario. Cuando el filtro de suscripciones se active más adelante, CloudWatch Logs envía los eventos de registro al destino en nombre de la cuenta de origen.

**Para crear un destino**

1. Espere a que el flujo de Firehose que creó en [Paso 1: creación de un flujo de entrega de Firehose](CreateFirehoseStream-Account.md) se active. Puede utilizar el siguiente comando para comprobar la **StreamDescription. StreamStatus**propiedad.

   ```
   aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
   ```

   Además, tome nota de la **DeliveryStreamDescription. DeliveryStreamValor ARN**, ya que tendrá que usarlo en un paso posterior. Resultado de ejemplo de este comando:

   ```
   {
       "DeliveryStreamDescription": {
           "DeliveryStreamName": "my-delivery-stream",
           "DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
           "DeliveryStreamStatus": "ACTIVE",
           "DeliveryStreamEncryptionConfiguration": {
               "Status": "DISABLED"
           },
           "DeliveryStreamType": "DirectPut",
           "VersionId": "1",
           "CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
           "Destinations": [
               {
                   "DestinationId": "destinationId-000000000001",
                   "S3DestinationDescription": {
                       "RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
                       "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
                       "BufferingHints": {
                           "SizeInMBs": 5,
                           "IntervalInSeconds": 300
                       },
                       "CompressionFormat": "UNCOMPRESSED",
                       "EncryptionConfiguration": {
                           "NoEncryptionConfig": "NoEncryption"
                       },
                       "CloudWatchLoggingOptions": {
                           "Enabled": false
                       }
                   },
                   "ExtendedS3DestinationDescription": {
                       "RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
                       "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
                       "BufferingHints": {
                           "SizeInMBs": 5,
                           "IntervalInSeconds": 300
                       },
                       "CompressionFormat": "UNCOMPRESSED",
                       "EncryptionConfiguration": {
                           "NoEncryptionConfig": "NoEncryption"
                       },
                       "CloudWatchLoggingOptions": {
                           "Enabled": false
                       },
                       "S3BackupMode": "Disabled"
                   }
               }
           ],
           "HasMoreDestinations": false
       }
   }
   ```

   El flujo de entrega puede tardar un minuto o dos en mostrarse en el estado activo.

1. Cuando la transmisión de entrega esté activa, crea la función de IAM que concederá a CloudWatch Logs el permiso para colocar datos en tu transmisión de Firehose. En primer lugar, tendrás que crear una política de confianza en un archivo **TrustPolicyFor\$1/** CWL.json. Utilice un editor de texto para crear esta política. Para obtener más información sobre CloudWatch los puntos de enlace de Logs, consulte los puntos de [enlace y las cuotas de Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html). 

   Esta política incluye una clave de contexto de condición global `aws:SourceArn` que especifica la `sourceAccountId` para ayudar a prevenir el problema de seguridad de suplente confuso. Si aún no conoce el ID de cuenta de origen en la primera llamada, le recomendamos que coloque el ARN de destino en el campo ARN de origen. En las llamadas posteriores, debe configurar el ARN de origen para que sea el ARN de origen real que recopiló desde la primera llamada. Para obtener más información, consulte [Prevención del suplente confuso](Subscriptions-confused-deputy.md). 

   ```
   {
       "Statement": {
           "Effect": "Allow",
           "Principal": {
               "Service": "logs.amazonaws.com"
           },
           "Action": "sts:AssumeRole",
           "Condition": {
               "StringLike": {
                   "aws:SourceArn": [
                       "arn:aws:logs:region:sourceAccountId:*",
                       "arn:aws:logs:region:recipientAccountId:*"
                   ]
               }
           }
        }
   }
   ```

1. Utilice **aws iam create-role** para crear el rol de IAM y especifique el archivo de política de confianza que acaba de crear. 

   ```
   aws iam create-role \
         --role-name CWLtoKinesisFirehoseRole \
         --assume-role-policy-document file://~/TrustPolicyForCWL.json
   ```

   A continuación, se muestra un ejemplo de la salida. Anote el valor de `Role.Arn` devuelto, ya que lo necesitará en un paso posterior.

   ```
   {
       "Role": {
           "Path": "/",
           "RoleName": "CWLtoKinesisFirehoseRole",
           "RoleId": "AROAR3BXASEKYJYWF243H",
           "Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
           "CreateDate": "2023-02-02T08:10:43+00:00",
           "AssumeRolePolicyDocument": {
               "Statement": {
                   "Effect": "Allow",
                   "Principal": {
                       "Service": "logs.amazonaws.com"
                   },
                   "Action": "sts:AssumeRole",
                   "Condition": {
                       "StringLike": {
                           "aws:SourceArn": [
                               "arn:aws:logs:region:sourceAccountId:*",
                               "arn:aws:logs:region:recipientAccountId:*"
                           ]
                       }
                   }
               }
           }
       }
   }
   ```

1. Cree una política de permisos para definir qué acciones puede realizar CloudWatch Logs en su cuenta. Primero, usa un editor de texto para crear una política de permisos en un archivo **\$1/ PermissionsFor CWL.json:**

   ```
   {
       "Statement":[
         {
           "Effect":"Allow",
           "Action":["firehose:*"],
           "Resource":["arn:aws:firehose:region:222222222222:*"]
         }
       ]
   }
   ```

1. Asocie la política de permisos con el rol mediante el siguiente comando:

   ```
   aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
   ```

1. Una vez que la transmisión de entrega de Firehose esté en estado activo y hayas creado la función de IAM, puedes crear el destino de los CloudWatch registros.

   1. Este paso no asociará una política de acceso a su destino y solo es el primer paso de los dos que completan la creación de un destino. Anote el ARN del nuevo destino que se devuelve en la carga, porque lo utilizará como `destination.arn` en un paso posterior.

      ```
      aws logs put-destination \                                                       
          --destination-name "testFirehoseDestination" \
          --target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
          --role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
      
      {
          "destination": {
              "destinationName": "testFirehoseDestination",
              "targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
              "roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
              "arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
      }
      ```

   1. Después de completar el paso previo, en la cuenta del destinatario de los datos de registro (222222222222), asocie una política de acceso con el destino. Esta política permite que la cuenta del remitente de los datos de registro (111111111111) tenga acceso al destino justo en la cuenta del destinatario de los datos de registro (222222222222). Puede utilizar un editor de texto para incluir esta política en el archivo `~/AccessPolicy.json`:

------
#### [ JSON ]

****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement" : [
          {
            "Sid" : "",
            "Effect" : "Allow",
            "Principal" : {
              "AWS" : "111111111111"
            },
            "Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
            "Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
          }
        ]
      }
      ```

------

   1. Esto crea una política que define quién tiene acceso de escritura al destino. Esta política debe especificar las acciones `logs:PutSubscriptionFilter` y `logs:PutAccountPolicy` para acceder al destino. Los usuarios entre cuentas utilizarán las acciones `PutSubscriptionFilter` y `PutAccountPolicy` para enviar eventos de registro al destino.

      ```
      aws logs put-destination-policy \
          --destination-name "testFirehoseDestination" \
          --access-policy file://~/AccessPolicy.json
      ```

# Paso 3: crear una política de filtrado de suscripciones a nivel de cuenta
<a name="CreateSubscriptionFilterFirehose-Account"></a>

Cambie a la cuenta de envío, que es 111111111111 en este ejemplo. Ahora creará la política de filtrado de suscripciones a nivel de cuenta en la cuenta de envío. En el siguiente ejemplo, el filtro hace que cada evento de registro que contiene la cadena `ERROR` en todos los grupos de registro excepto en dos se envíe al destino creado anteriormente. 

```
aws logs put-account-policy \
    --policy-name "CrossAccountFirehoseExamplePolicy" \
    --policy-type "SUBSCRIPTION_FILTER_POLICY" \
    --policy-document '{"DestinationArn":"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination", "FilterPattern": "{$.userIdentity.type = AssumedRole}", "Distribution": "Random"}' \
    --selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
    --scope "ALL"
```

Los grupos de registro y el destino de la cuenta desde la que se realiza el envío deben estar en la misma región de AWS . Sin embargo, el destino puede apuntar a un AWS recurso, como un arroyo Firehose, que se encuentra en una región diferente.

# Validación del flujo de eventos de registro
<a name="ValidateLogEventFlowFirehose-Account"></a>

Tras crear el filtro de suscripción, CloudWatch Logs reenvía todos los eventos de registro entrantes que coincidan con el patrón de filtro y los criterios de selección al flujo de entrega de Firehose. Los datos comienzan a aparecer en su bucket de Amazon S3 en función del intervalo de tiempo de búfer que se establece en el flujo de entrega de Firehose. Una vez que haya transcurrido el tiempo suficiente, puede verificar los datos comprobando su bucket de Amazon S3. Escriba el siguiente comando para comprobar el bucket:

```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket' 
```

El resultado de ese comando será similar a lo siguiente:

```
{
    "Contents": [
        {
            "Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
            "LastModified": "2023-02-02T09:00:26+00:00",
            "ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
            "Size": 198,
            "StorageClass": "STANDARD",
            "Owner": {
                "DisplayName": "firehose+2test",
                "ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
            }
        }
    ]
}
```

Puede recuperar un objeto específico del bucket al introducir el siguiente comando. Reemplace el valor de `key` con el valor que encontró en el comando anterior.

```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```

Los datos en el objeto de Amazon S3 se comprimen con el formato gzip. Puede examinar los datos sin procesar desde la línea de comando mediante uno de los siguientes comandos:

Linux:

```
zcat testfile.gz
```

macOS:

```
zcat <testfile.gz
```

# Modificación de la suscripción al destino en tiempo de ejecución
<a name="ModifyDestinationMembershipFirehose-Account"></a>

Puede encontrar situaciones en las que tenga que agregar o eliminar remitentes de registros de un destino de su propiedad. Puedes usar las `PutAccountPolicy` acciones **PutDestinationPolicy**y en tu destino con la nueva política de acceso. En el siguiente ejemplo, una cuenta **111111111111** agregada anteriormente deja de enviar datos de registro y se habilita la cuenta **333333333333**.

1. Busca la política que está asociada actualmente con el destino **TestDestination** y anota lo siguiente: **AccessPolicy**

   ```
   aws logs describe-destinations \
       --destination-name-prefix "testFirehoseDestination"
   ```

   Los datos devueltos pueden tener el siguiente aspecto.

   ```
   {
       "destinations": [
           {
               "destinationName": "testFirehoseDestination",
               "targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
               "roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
               "accessPolicy": "{\n  \"Version\" : \"2012-10-17\",\n  \"Statement\" : [\n    {\n      \"Sid\" : \"\",\n      \"Effect\" : \"Allow\",\n      \"Principal\" : {\n        \"AWS\" : \"111111111111 \"\n      },\n      \"Action\" : \"logs:PutSubscriptionFilter\",\n      \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n    }\n  ]\n}\n\n",
               "arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
               "creationTime": 1612256124430
           }
       ]
   }
   ```

1. Actualice la política para reflejar que la cuenta **111111111111** está detenida y que la cuenta **333333333333** está habilitada. Coloca esta política en el archivo **\$1/ .json: NewAccessPolicy**

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement" : [
       {
         "Sid" : "",
         "Effect" : "Allow",
         "Principal" : {
           "AWS" : "333333333333 "
         },
         "Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
         "Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
       }
     ]
   }
   ```

------

1. Use el siguiente comando para asociar la política definida en el **NewAccessPolicyarchivo.json** con el destino:

   ```
   aws logs put-destination-policy \
       --destination-name "testFirehoseDestination" \                                                                              
       --access-policy file://~/NewAccessPolicy.json
   ```

   Esto finalmente deshabilita los eventos de registro del ID de cuenta **111111111111**. Los eventos de registro del ID de cuenta **333333333333** empiezan a fluir al destino en cuanto el propietario de la cuenta **333333333333** crea un filtro de suscripción.