AWS Integration: Core Services Delivered to S3

Taylor Walton

07-Oct-2026

AWS Integration: Core Services Delivered to S3

This guide covers the AWS services that write their logs directly into an S3 bucket:

• AWS CloudTrail ⭐ (recommended)
• Amazon GuardDuty ⭐ (recommended)
• VPC Flow Logs
• Elastic Load Balancing access logs (ALB, CLB, NLB)
• S3 server access logs

Start with the "AWS Integration: Getting Started and Access Setup" article(https://socfortress.supportbench.net/ar-1138/). This guide is Step 2 of that process. Once your logs are flowing, go back to it to create the read-only access and test it.

Use one bucket for everything. All of these services can deliver to the same S3 bucket. The recommended approach is to let CloudTrail create the bucket (section 1), then point the other services at that same bucket using a different prefix (folder) for each.

As you go, note down for each service: the bucket, the prefix, the region(s), and any KMS key ARN. You'll send these to us at the end.

1. AWS CloudTrail ⭐

CloudTrail records API activity and console sign-ins across your account.

Using AWS Organizations? Create the trail from your management account and select Enable for all accounts in my organization. One organization trail then covers every account. Note your Organization ID.

Console:

1. Go to CloudTrail > Trails > Create trail.
2. Trail name: socfortress-trail.
3. Storage location: select Create new S3 bucket and give it a name (for example acme-socfortress-logs). CloudTrail creates the bucket with the correct permissions automatically.
   • If you use an existing bucket instead, it needs a bucket policy that allows CloudTrail to write to it. See "Amazon S3 bucket policy for CloudTrail" under Helpful documentation.
4. Log file SSE-KMS encryption: if this is enabled, note the KMS key ARN. SOCFortress will need decrypt permission for it (Getting Started article, Step 3).
5. Click Next. Under Event type, select Management events, with Read and Write API activity.
   • Data events (for example S3 object-level or Lambda invocations) are optional and can be high volume and cost. Only enable them if you specifically need them.
6. Click Next, then Create trail.

Trails created in the console log all regions by default, which is what we recommend.

Where the logs land: s3://BUCKET/AWSLogs/ACCOUNT_ID/CloudTrail/REGION/YYYY/MM/DD/

Note for SOCFortress: bucket name, KMS key ARN (if any), Organization ID (if an organization trail).

2. Amazon GuardDuty ⭐

GuardDuty is AWS's managed threat detection service. Findings are exported to S3 and are always encrypted with a KMS key.

GuardDuty is regional. Enable it, and configure the export, in each region you use.

2a. Create a KMS key for the export (once per region)

1. Go to KMS > Customer managed keys > Create key.
2. Symmetric, Encrypt and decrypt, in the same region as your log bucket.
3. Give it an alias (for example socfortress-guardduty) and finish creating it. Note the key ARN.

2b. Enable GuardDuty and configure the export

1. Go to GuardDuty and click Get started > Enable GuardDuty (skip this if it's already enabled).
2. Go to Settings > Findings export options > S3 bucket > Configure now.
3. Select Existing bucket in your account, and choose your log bucket.
   • Log file prefix: guardduty (recommended).
4. KMS encryption: select your KMS key from step 2a.
5. Apply the policies GuardDuty shows you. These are required:
   • Click View policy for S3 bucket, copy it, and add it to the bucket's policy (S3 > your bucket > Permissions > Bucket policy).
   • Click View policy for KMS key, copy it, and add it to the key's policy (KMS > your key > Key policy > Edit).
6. Save.
7. Under Findings export options, set Frequency for updated findings to Update CWE and S3 every 15 minutes. The default is 6 hours, which delays your alerts.

Note for SOCFortress: bucket name, prefix (guardduty), KMS key ARN, and the region(s) where GuardDuty is enabled. Remember to add the kms:Decrypt statement for this key to the SOCFortress policy (Getting Started article, Step 3).

3. VPC Flow Logs (optional)

VPC Flow Logs capture network traffic metadata (source, destination, port, accept or reject).

1. Go to VPC > Your VPCs, select the VPC, open the Flow logs tab, and click Create flow log.
2. Filter: All (or Reject to capture only blocked traffic and reduce volume).
3. Maximum aggregation interval: 10 minutes (default) is fine.
4. Destination: Send to an Amazon S3 bucket.
5. S3 bucket ARN: arn:aws:s3:::YOUR_LOG_BUCKET
6. Log record format: AWS default format. Custom formats may not be parsed correctly.
7. Click Create flow log. AWS adds the bucket permission it needs automatically.

Repeat for each VPC you want to monitor.

Where the logs land: s3://BUCKET/AWSLogs/ACCOUNT_ID/vpcflowlogs/REGION/YYYY/MM/DD/

Note for SOCFortress: the VPCs and regions enabled. Remember to add the ec2:DescribeFlowLogs statement to the SOCFortress policy (Getting Started article, Step 3).

4. Elastic Load Balancing access logs (optional)

1. Go to EC2 > Load Balancers and select the load balancer.
2. Open the Attributes tab and click Edit.
3. Under Monitoring, turn on Access logs.
4. S3 URI: s3://YOUR_LOG_BUCKET/ALB (use CLB or NLB as the prefix for those types).
5. Save.

Bucket policy required: load balancers need permission to write to your bucket. If AWS shows a permissions error when you save, add the bucket policy from "Enable access logs for your load balancer" under Helpful documentation.

Network Load Balancers only produce access logs for TLS listeners.

Note for SOCFortress: load balancer type(s) (ALB / CLB / NLB), the prefix used for each, and the region(s).

5. S3 server access logs (optional)

These record requests made to other buckets you want to monitor.

1. Go to S3 and select the bucket you want to monitor (not the SOCFortress log bucket itself).
2. Open the Properties tab, go to Server access logging, and click Edit.
3. Select Enable.
4. Destination: s3://YOUR_LOG_BUCKET/s3-server-logs/
5. Save. AWS updates the destination bucket's permissions when you do this in the console.

Repeat for each bucket you want to monitor.

Don't enable server access logging on the log bucket itself, pointing back to itself. That creates an endless loop of log files.

Note for SOCFortress: the prefix (s3-server-logs) and which buckets are being logged.

Next step

Once logs are appearing in your bucket, go back to AWS Integration: Getting Started and Access Setup(https://socfortress.supportbench.net/ar-1138/) and complete Step 3 onward to create the read-only access, test it, and send us the details.

Helpful documentation

Wazuh

• CloudTrail: https://documentation.wazuh.com/current/cloud-security/amazon/services/supported-services/cloudtrail.html
• GuardDuty: https://documentation.wazuh.com/current/cloud-security/amazon/services/supported-services/guardduty.html
• VPC Flow Logs: https://documentation.wazuh.com/current/cloud-security/amazon/services/supported-services/vpc.html
• Elastic Load Balancing: https://documentation.wazuh.com/current/cloud-security/amazon/services/supported-services/elastic-load-balancing/index.html
• S3 server access logs: https://documentation.wazuh.com/current/cloud-security/amazon/services/supported-services/server-access.html

AWS

• Creating a trail: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html
• Amazon S3 bucket policy for CloudTrail: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.html
• Exporting GuardDuty findings to S3: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_exportfindings.html
• Publishing flow logs to Amazon S3: https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-s3.html
• Enable access logs for your Application Load Balancer: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html
• Enabling Amazon S3 server access logging: https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html