# \[Filebeat\] AWS CloudTrail Processor parses incorrect AWS region from logs
**URL:** https://discuss.elastic.co/t/filebeat-aws-cloudtrail-processor-parses-incorrect-aws-region-from-logs/312150
**Category:** Beats
**Tags:** filebeat
**Created:** [August 16, 2022, 8:30am UTC](https://discuss.elastic.co/t/filebeat-aws-cloudtrail-processor-parses-incorrect-aws-region-from-logs/312150 "2022-08-16T08:30:32Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@styks90](https://discuss.elastic.co/u/styks90)
#### Post date: [August 16, 2022, 8:30am UTC](https://discuss.elastic.co/t/filebeat-aws-cloudtrail-processor-parses-incorrect-aws-region-from-logs/312150/1 "2022-08-16T08:30:32Z")
When processing AWS CloudTrail logs, we noticed a discrepancy in the parsed AWS region compared to the region a log file originated. CloudTrail is not region specific , but monitors all configured regions and stuffs the collected log files into a s3 bucket. The s3 bucket of course is attached to a region, in our case eu-central-1.
We configured the AWS CloudTrail processor in Filebeat to listen to a sqs queue as suggested in the Filebeat configuration files to reproduce the problem from our production environment:
> # How to manual test this module
>
> - Create a CloudTrail with a S3 bucket as the storage location
> - Configure this S3 bucket to send "All object create events" to a SQS queue
> - Configure filebeat, using the SQS queue url with s3 notification setup in
> previous step.
This leads to the identical problematic situation, where the `cloud.region` is not identical to the region the log originated from, but the region where the s3 and sqs are located. For instance, `"awsRegion":"us-east-1"` is nonetheless parsed to `eu-central-1`, despite a correctly configured ingest pipeline:
```auto
{
"rename": {
"field": "json.awsRegion",
"target_field": "cloud.region",
"ignore_failure": true
}
}
```
---
### Author:  [@legoguy1000](https://discuss.elastic.co/u/legoguy1000)
#### Post date: [August 17, 2022, 6:14pm UTC](https://discuss.elastic.co/t/filebeat-aws-cloudtrail-processor-parses-incorrect-aws-region-from-logs/312150/2 "2022-08-17T18:14:25Z")
If `cloud.region` is already set, the rename will fail so it probably needs to change to a set processor instead.
---
### Author:  [@legoguy1000](https://discuss.elastic.co/u/legoguy1000)
#### Post date: [August 17, 2022, 10:05pm UTC](https://discuss.elastic.co/t/filebeat-aws-cloudtrail-processor-parses-incorrect-aws-region-from-logs/312150/3 "2022-08-17T22:05:05Z")
I created [[AWS] Update AWS cloud.region parsing by legoguy1000 · Pull Request #4024 · elastic/integrations · GitHub](https://github.com/elastic/integrations/pull/4024) to address this.
---
### Author:  [@styks90](https://discuss.elastic.co/u/styks90)
#### Post date: [August 18, 2022, 6:31am UTC](https://discuss.elastic.co/t/filebeat-aws-cloudtrail-processor-parses-incorrect-aws-region-from-logs/312150/4 "2022-08-18T06:31:48Z")
Great, thanks! We suspect that the `cloud.region` field is previously set according to the region of the sqs or the s3, where the logs aren't accessed yet.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [September 15, 2022, 8:32am UTC](https://discuss.elastic.co/t/filebeat-aws-cloudtrail-processor-parses-incorrect-aws-region-from-logs/312150/5 "2022-09-15T08:32:01Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.