On an architecture slide, connecting AWS to a SOC is one arrow: AWS on the left, SIEM on the right. In a real environment, that arrow crosses accounts, teams, resource policies, queues, KMS keys, and sometimes an MSP change process.

The technical connector is often the easy part. The delay begins when nobody has mapped the complete collection path before the first IAM request is submitted.

Start by separating two collection paths

I divide AWS security data into two integration paths before discussing a product or parser. They may end in the same SIEM, but their owners, interfaces, and failure modes are different.

1. AWS-native logs and findings

Typical sources include CloudTrail, VPC Flow Logs, Elastic Load Balancing access logs, AWS WAF logs, GuardDuty findings, and Security Hub findings.

For high-volume data, a common enterprise pattern is to centralize logs in an S3 bucket owned by a dedicated logging or security account. An S3 event notification is delivered to SQS, and the SIEM collector uses the queue message to retrieve the corresponding object.

CloudWatch Logs, Amazon Data Firehose, Kinesis Data Streams, EventBridge, or Lambda can be added for streaming, filtering, and transformation. They are design choices, not mandatory steps in every SIEM integration.

Security Hub and Security Lake should not be treated as interchangeable log forwarders. Security Hub aggregates and normalizes security findings. Security Lake centralizes supported security data in OCSF and is the better fit when a normalized security data lake is the actual requirement.

2. EC2-hosted security platforms

The second path starts with a third-party security management platform running on EC2. Trend Micro Deep Security Manager is one example. Firewall managers, vulnerability platforms, and other security products can follow the same operating model.

This path is product-led rather than AWS-log-led. The SIEM may collect by syslog, API, agent, vendor connector, or an AWS-compatible export feature. Before building anything, confirm which component initiates the connection, whether the product can assume a role, whether it uses S3 and SQS, and whether it supports cross-account access and customer-managed KMS keys.

That short compatibility check prevents a cloud team from building a delivery path that the security product cannot consume.

Both paths eventually meet at permission

In an enterprise, the SOC rarely owns every account in the path. A cloud platform team or MSP may control IAM roles, the central log bucket, SQS, and KMS. Each missing permission can therefore become a separate request with a separate owner and lead time.

1. S3 access is approved.
2. The collector cannot receive the SQS notification.
3. SQS access is approved.
4. The first object uses a customer-managed KMS key.
5. A third request is opened for decryption.

This is not an exotic failure. It is what happens when the request describes a destination—“give the SIEM access”—instead of the complete retrieval sequence.

Prefer an IAM role over an IAM user

An IAM user usually means placing a long-lived access key and secret key in the SIEM. That creates rotation work, outage risk during key replacement, and a larger exposure window if the credential leaks. Many enterprise security standards prohibit or strongly discourage this pattern.

When the SIEM supports it, create a dedicated cross-account role. The role trust policy allows the SIEM principal to call sts:AssumeRole and restricts the request with the vendor-provided External ID. The role ARN and External ID are then registered in the SIEM, which receives temporary credentials instead of storing a permanent AWS secret.

Keep two questions separate during design and troubleshooting:

• Who can assume the role? The role trust policy answers this.
• What can the assumed role do? The role permission policy and applicable resource policies answer this.

S3 itself does not have an IAM-style “trust relationship.” For an S3 collection path, check the role trust policy, role permission policy, and bucket policy separately.

Submit one access package, not five tickets

The exact actions must come from the SIEM vendor documentation and your architecture. A typical S3-and-SQS review covers the following layers:

Before submitting the access request, record the SIEM principal or AWS account ID, vendor-generated External ID, role ARN convention, S3 bucket and prefix ARNs, SQS queue ARN and Region, KMS key ARN, source and destination accounts, and a test sequence covering role assumption, queue consumption, object retrieval, and decryption.

Also check the controls that are easy to miss: bucket and queue resource policies, KMS key policy, permissions boundaries, and organization SCPs. A correct role policy cannot override an explicit deny elsewhere.