Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comprendre les concepts des requêtes planifiées

Avant de créer des requêtes planifiées, comprenez ces concepts clés qui affectent le mode d'exécution de vos requêtes et l'endroit où les résultats sont fournis.

Séparation des rôles IAM

Les requêtes planifiées nécessitent deux rôles IAM distincts : l'un pour exécuter les requêtes et l'autre pour fournir des résultats à Amazon S3 ou aux bus d' EventBridge événements Amazon. Comprendre pourquoi cette séparation existe vous aide à configurer correctement les autorisations et à tirer parti des avantages opérationnels et de sécurité qu'elle apporte.

L'architecture à deux rôles répartit les responsabilités entre l'accès aux données et leur livraison. Le rôle d'exécution des requêtes accède aux données de votre journal et exécute des requêtes, tandis que le rôle de livraison de destination écrit les résultats vers la destination que vous avez choisie. Cette séparation suit le principe du moindre privilège : chaque rôle ne dispose que des autorisations dont il a besoin pour sa fonction spécifique.

Cette séparation offre des avantages pratiques pour vos opérations. Du point de vue de la sécurité, si vous devez modifier l'endroit où les résultats sont fournis, vous ne modifiez que le rôle de livraison de destination sans modifier les autorisations d'exécution des requêtes. À des fins de conformité et d'audit, vous pouvez clairement savoir quel rôle accède aux données de journal sensibles et quel rôle écrit sur des systèmes externes. Cela permet de démontrer plus facilement que votre infrastructure d'analyse des journaux suit les meilleures pratiques en matière de sécurité.

Utilisation entre régions et entre comptes

Une requête planifiée est créée dans une région spécifique et s'exécute dans cette région. Cependant, vous pouvez interroger des groupes de journaux et fournir des résultats par région et par compte. Vous devez configurer un ou plusieurs AWS comptes en tant que comptes de surveillance et les associer à plusieurs comptes sources. Un compte de surveillance est un AWS compte central qui permet de consulter et d'interagir avec les données d'observabilité générées à partir des comptes sources. Un compte source est un AWS compte individuel qui génère des données d'observabilité pour les ressources qu'il contient. Les comptes sources partagent leurs données d'observabilité avec le compte de surveillance. Vous pouvez donc configurer des requêtes planifiées à partir du compte de surveillance à l'aide des groupes de journaux de tous les comptes associés.

Approche alternative : utilisez la centralisation CloudWatch des journaux pour répliquer les données des journaux de plusieurs comptes et régions vers un compte de surveillance central. Cela vous permet de créer des requêtes planifiées dans une seule région qui accèdent à tous vos journaux centralisés, d'éviter les requêtes interrégionales et de simplifier la gestion des autorisations IAM.

Expressions de planification et gestion des fuseaux horaires

Le calendrier que vous définissez détermine le moment et la fréquence d'exécution de votre requête. Le choix de la bonne expression de planification influe sur le moment où vous recevez les résultats et sur la quantité de données que vous interrogez. La compréhension des types d'expressions vous permet de choisir entre simplicité et précision.

Les expressions Cron fournissent un contrôle précis du calendrier, vous permettant de spécifier les heures, les jours de la semaine ou les jours du mois exacts. Utilisez des expressions cron lorsque vous devez exécuter des requêtes à des heures ouvrées spécifiques ou s'aligner sur les plannings opérationnels. Dans la console, vous pouvez également planifier des requêtes à l'aide d'options de calendrier simples.

Toutes les requêtes planifiées sont exécutées en UTC, quel que soit votre fuseau horaire local ou l'emplacement de vos AWS ressources. Cela est particulièrement important lorsque vous planifiez des requêtes pour les heures ouvrables ou pour des analyses urgentes. Par exemple, si votre entreprise exerce ses activités à l'heure de l'Est des États-Unis et que vous souhaitez obtenir un rapport quotidien à 9 h 00 ET, vous devez tenir compte du décalage UTC (14 h UTC pendant l'heure d'été, 13 h 00 UTC dans le cas contraire). Planifiez vos expressions de planification en tenant compte de l'UTC afin de garantir que les requêtes soient exécutées aux heures prévues.

Choix d'une langue de requête

Les requêtes planifiées prennent en charge trois langages de requête différents, et votre choix influe à la fois sur la façon dont vous rédigez les requêtes et sur la facilité avec laquelle votre équipe peut les gérer. Le langage approprié dépend de vos exigences en matière d'analyse et des compétences existantes de votre équipe.

Si vous filtrez et agrégez principalement des données de journal, le langage de requête CloudWatch Logs Insights propose la syntaxe la plus simple. Pour les transformations de données complexes où vous devez remodeler ou enrichir les données en plusieurs étapes, l'approche de pipeline de PPL facilite le suivi de la logique. Lorsque vous devez effectuer des jointures ou des agrégations complexes similaires à des opérations de base de données, SQL fournit une syntaxe familière que les équipes expérimentées peuvent adopter rapidement.

Sélection de destinations et cas d'utilisation

L'endroit où vous envoyez les résultats de la requête détermine ce que vous pouvez en faire. Ce choix façonne l'ensemble de votre flux de travail en aval, qu'il s'agisse de créer des analyses à long terme, de déclencher des réponses automatisées, ou les deux. Comprendre les points forts de chaque type de destination vous aide à concevoir l'architecture adaptée à votre cas d'utilisation.

Les destinations Amazon S3 sont optimisées pour le stockage et le traitement par lots. Lorsque vous devez conserver les résultats de vos requêtes pendant des mois ou des années, analyser les tendances au fil du temps ou alimenter des plateformes d'analyse, Amazon S3 fournit un stockage rentable avec une rétention illimitée. EventBridge les destinations sont optimisées pour une automatisation en temps réel. Lorsque les résultats d'une requête doivent déclencher des actions immédiates, comme l'envoi d'alertes, le démarrage de flux de travail ou la mise à jour EventBridge de systèmes, les résultats sont des événements auxquels vos applications peuvent réagir instantanément. Par défaut, tous les événements de fin de requête sont automatiquement envoyés sous forme d'événements au bus d'événements par défaut, ce qui permet l'intégration avec les systèmes de traitement en aval, les fonctions Lambda ou d'autres architectures pilotées par les événements. Les résultats ne sont publiés vers les destinations que lorsque la requête est exécutée avec succès.

Format et structure des résultats de requête

Pour les destinations Amazon S3, les résultats des requêtes sont fournis au format JSON avec la même structure que la réponse de l' GetQueryResults API. Pour Amazon, EventBridge comprendre le format des résultats des requêtes planifiées vous permet de concevoir des flux de travail de traitement et d'intégration en aval.

Les résultats des requêtes sont fournis au format JSON avec la structure suivante :

{
    "version": "0",
    "id": "be72061b-eca2-e068-a7e1-83e01d6fe807",
    "detail-type": "Scheduled Query Completed",
    "source": "aws.logs",
    "account": "123456789012",
    "time": "2025-11-18T11:31:48Z",
    "region": "us-east-1",
    "resources": [
        "arn:aws:logs:us-east-1:123456789012:scheduled-query:477b4380-b098-474e-9c5e-e10a8cc2e6e7"
    ],
    "detail": {
        "queryId": "2038fd57-ab4f-4018-bb2f-61d363f4a004",
        "queryString": "fields @timestamp, @message, @logStream, @log\n| sort @timestamp desc\n| limit 10000",
        "logGroupIdentifiers": [
            "/aws/lambda/my-function"
        ],
        "status": "Complete",
        "startTime": 1763465460,
        "statistics": {
            "recordsMatched": 0,
            "recordsScanned": 0,
            "estimatedRecordsSkipped": 0,
            "bytesScanned": 0,
            "estimatedBytesSkipped": 0,
            "logGroupsScanned": 1
        }
    }
}

Les principaux éléments sont les suivants :