AWS Integration: Getting Started and Access Setup

Taylor Walton

07-Oct-2026

AWS Integration: Getting Started and Access Setup

This guide explains how SOCFortress collects logs from your Amazon Web Services (AWS) environment, which AWS services you can send us, and how to create the read-only access we need.

Start here. Every AWS integration begins with this article. You'll set up log delivery for the services you choose (using the service guides linked below), then come back to finish the access setup and test it yourself before sending anything to us.

How it works

1. Your AWS services write their logs into an S3 bucket in your account.
2. You create a dedicated IAM user with read-only access to that bucket.
3. You send us the user's access key through a secure channel.
4. Our Wazuh platform reads new log files from the bucket on a schedule and turns them into security alerts in your SIEM.

We never delete, modify or write anything in your AWS account. The access you create in this guide is read-only.

Step 1: Choose which services to send

⭐ Recommended baseline: start with CloudTrail + GuardDuty. Together they cover the large majority of what matters for security monitoring in AWS. You can add more services later.

Some services add to your AWS bill (for example CloudTrail data events, VPC Flow Logs and GuardDuty). Talk to us if you're unsure which to enable.

Step 2: Set up log delivery

Follow the guide for each service you chose:

• Core Services Delivered to S3 (CloudTrail, GuardDuty, VPC Flow Logs, load balancers, S3 server access logs): [LINK TO CORE SERVICES ARTICLE]

While you work through it, note down:

• The S3 bucket name your logs are delivered to. We recommend one dedicated bucket for all services.
• The prefix (folder) used for each service, if any.
• The AWS region(s) where you enabled each service.
• Any KMS key ARN used to encrypt the logs (for example GuardDuty, or CloudTrail with SSE-KMS).

Keep the bucket private. Block all public access should stay enabled.

Come back here once logs have started appearing in the bucket.

Step 3: Create the read-only IAM policy

1. In the AWS console, go to IAM > Policies > Create policy.
2. Switch to the JSON editor and paste the policy below. Replace YOUR_LOG_BUCKET with your bucket name.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "SOCFortressReadLogBucket",
 "Effect": "Allow",
 "Action": [
 "s3:GetObject",
 "s3:ListBucket"
 ],
 "Resource": [
 "arn:aws:s3:::YOUR_LOG_BUCKET",
 "arn:aws:s3:::YOUR_LOG_BUCKET/*"
 ]
 }
 ]
}

1. Add these extra statements if they apply to you. Add them inside the "Statement": [ ... ] list, separated by commas.

   If your logs are encrypted with a KMS key (always the case for GuardDuty, and for CloudTrail if SSE-KMS is enabled). Add one KMS key ARN per key:

   {
    "Sid": "SOCFortressDecryptLogs",
    "Effect": "Allow",
    "Action": "kms:Decrypt",
    "Resource": "arn:aws:kms:REGION:ACCOUNT_ID:key/KEY_ID"
   }
   

   If you enabled VPC Flow Logs:

   {
    "Sid": "SOCFortressDescribeFlowLogs",
    "Effect": "Allow",
    "Action": "ec2:DescribeFlowLogs",
    "Resource": "*"
   }
   

2. Click Next, name the policy SOCFortress-Wazuh-ReadOnly, and click Create policy.

Don't add delete permissions (s3:DeleteObject). SOCFortress only needs to read your logs.

Step 4: Create the IAM user and access key

1. Go to IAM > Users > Create user.
2. User name: socfortress-wazuh. Leave Provide user access to the AWS Management Console unchecked. This user only needs programmatic access.
3. Click Next, choose Attach policies directly, select SOCFortress-Wazuh-ReadOnly, and create the user.
4. Open the new user, go to the Security credentials tab, and under Access keys click Create access key.
5. Choose the use case Application running outside AWS (or Command Line Interface), confirm, and click Create access key.
6. Copy or download the Access key ID and Secret access key now. AWS only shows the secret once.

Treat the access key like a password. Don't email it or paste it into a chat or ticket.

Step 5: Test the access yourself

Before sending anything to us, confirm the new user can read your logs. You'll need the AWS CLI installed on your computer, or you can use AWS CloudShell (the >_ icon in the console).

1. Create a temporary test profile with the new user's key:

   aws configure --profile socfortress-test
   

   Enter the Access key ID, the Secret access key, and your default region (for example us-east-1). Leave the output format blank.

2. Confirm the key is valid:

   aws sts get-caller-identity --profile socfortress-test
   

   Expected: JSON showing your account ID and "Arn": "arn:aws:iam::ACCOUNT_ID:user/socfortress-wazuh".

3. Confirm the user can list your logs:

   aws s3 ls s3://YOUR_LOG_BUCKET/ --recursive --profile socfortress-test --page-size 10
   

   You should see log files (for CloudTrail, under AWSLogs/ACCOUNT_ID/CloudTrail/...). Press Ctrl+C once you've seen a few lines.

4. Confirm the user can download a log file. Copy one file name from the previous output:

   aws s3 cp s3://YOUR_LOG_BUCKET/PATH/TO/ONE/LOG/FILE.json.gz ./socfortress-test.json.gz --profile socfortress-test
   

   If your logs are KMS-encrypted (GuardDuty, or CloudTrail with SSE-KMS), test one of those files too. This confirms the KMS permission works.

5. Clean up. Delete the downloaded test file, and remove the [socfortress-test] section from your AWS credentials file (~/.aws/credentials on Mac/Linux, %USERPROFILE%\.aws\credentials on Windows).

Reading the result

Step 6: Send the details to SOCFortress

Upload the following to your OneHub folder (not email):

1. Access key ID and Secret access key
2. AWS account ID (and your AWS Organization ID if you set up an organization trail)
3. S3 bucket name
4. For each service you enabled: the prefix/folder, the region(s), and any KMS key ARN
5. Confirmation that your self-test in Step 5 passed

We'll configure the integration and let you know once your AWS logs are visible in your SIEM.

Good to know

• Key rotation: an IAM user can have two access keys at once. To rotate, create a second key, send it to us securely, and deactivate and delete the old key once we confirm the switch.
• Offboarding: to stop the integration, deactivate or delete the access key, or delete the socfortress-wazuh user. Your log delivery to S3 keeps working independently.
• Storage costs: consider an S3 lifecycle rule on the log bucket (for example, expire logs after 90 days) to control storage costs. We read new files shortly after they arrive.

Helpful documentation

Wazuh

• Using Wazuh to monitor AWS: https://documentation.wazuh.com/current/cloud-security/amazon/index.html
• Monitoring AWS services (prerequisites and supported services): https://documentation.wazuh.com/current/cloud-security/amazon/services/index.html

AWS

• Creating an IAM user: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html
• Managing access keys for IAM users: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
• Installing the AWS CLI: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Questions? Reply to your support case and we'll help.