Skip to content

AWS Integration

The AWS integration connects your Amazon Web Services accounts to Fencer for infrastructure security scanning and log monitoring. It has two catalog entries: AWS - Amazon Web Services (Scan), which inventories and assesses your AWS resources for misconfigurations, and AWS - Amazon Web Services (Monitor), which ingests CloudTrail and other AWS logs from S3 into Security Monitoring for detection.

  • An active Fencer organization with a valid subscription.
  • The Administrator role in your Fencer organization.
  • An AWS account and a user who can create IAM policies and roles.
  • For monitor connections: a plan that includes Security Monitoring, and an S3 bucket containing your AWS logs (e.g., CloudTrail, VPC Flow Logs).

Fencer uses AWS IAM cross-account roles to securely access your AWS environment. You create an IAM role in your AWS account with a trust policy that allows Fencer’s principal to assume it, using an external ID for additional security. Fencer then assumes this role via STS to perform read-only operations against your account.

For Scan connections, Fencer inventories resources across the regions you choose (every region by default) — including EC2 instances, RDS databases, S3 buckets, Lambda functions, ECS/EKS clusters, networking components, and more — then runs infrastructure security checks to identify misconfigurations. It also syncs IAM users and IAM Identity Center users into identity management. Fencer rescans each connected account daily, or weekly on plans without daily scheduled scans.

For Monitor connections, you replicate logs from your S3 bucket into a bucket Fencer provisions for you, where they are ingested for detection rule processing.

  1. Go to Admin > Integrations, click the AWS - Amazon Web Services (Scan) card under Available Integrations, and click Continue.
  2. Fencer generates a unique external ID for your connection and shows a setup guide beside the form. Pick a method from its tabs: Manual Setup, CLI Instructions (runs setup-fencer-aws-roles.sh), Terraform, or Pulumi. Every method’s snippets already carry Fencer’s principal ARN and your external ID.
  3. With Manual Setup, you create a read-only policy from the JSON shown (for example FencerAdditionalViewPrivileges), then a role with a Custom trust policy (see the example below), and attach FencerAdditionalViewPrivileges, ViewOnlyAccess, AWSSecurityHubReadOnlyAccess, and SecurityAudit to it. Name the role FencerScannerRole or similar. Two optional steps let Fencer scan containers running in EKS and apply one-click fixes (a separate FencerFixerPermissions policy).
  4. Fill in the form:
    • Role ARN — the ARN of the role you created.
    • Role STS Trust Policy External ID — filled in for you and read-only; it must match the sts:ExternalId condition on the role’s trust policy.
    • Environment — Production, Development, Test, or Mixed.
    • Your name or alias for this AWS connection (optional) — defaults to the environment.
    • Scan registry images and Scan container images — both on by default.
    • Regions to scan — Scan every region, Scan only the regions I select, or Scan every region except the ones I select.
  5. Click Connect. Fencer validates the role assumption and, on success, triggers an initial cloud infrastructure scan, architecture discovery, and an identity sync.

Connecting an AWS account that was connected before restores its existing connection.

The monitor connection setup is a six-step wizard:

  1. Go to Admin > Integrations, click the AWS - Amazon Web Services (Monitor) card, and click Continue. Review the prerequisites and click Continue again.
  2. Setup Event Source: fill in Display Name (optional), choose the Log Source Type, and enter the Source Bucket ARN (the S3 bucket where your AWS logs are stored) and, optionally, a Source Bucket Prefix. Log source types:
    • AWS CloudTrail
    • AWS VPC Flow Logs
    • AWS ALB Access Logs
    • AWS ALB Connection Logs
    • AWS NLB Access Logs
    • AWS S3 Bucket Access Logs
    • AWS RDS PostgreSQL STD Logs
    • AWS Route53 DNS Query Logs
  3. Tick Is your S3 bucket encrypted with a custom KMS key? if it is, then click Continue. Fencer provisions the destination bucket and the ingestion pipeline, which can take a minute.
  4. Create the IAM role: follow the policy and role instructions. The trust policy quotes Fencer’s principal ARN and your external ID. Click Continue.
  5. Setup Connection: enter the Role ARN and, optionally, a name, then click Validate Role. If another data source already replicates from the same bucket, Fencer offers to reuse its role.
  6. Setup Bucket Replication: create the S3 replication rule from your source bucket to Fencer’s destination bucket as shown, then click Complete Setup.
  • Scan connections: on Admin > Integrations, click Edit on the connection. You can change the Role ARN, environment, name, and the two container image toggles (the external ID is read-only), then click Save changes. The regions to scan and the account’s asset settings are edited in the cards below the form.
  • Monitor connections: expand the AWS Monitor card and click Edit Data Source. Under Connection, update the Role ARN or name and click Save. Under Event Source, update the display name, source bucket ARN, or prefix and click Set — after changing the bucket, update the bucket policies and roles to match.

Click Remove on a scan connection, or Remove Data Source on a monitor data source, and confirm. Scan connections soft-delete the associated cloud account and its resources. Monitor connections soft-delete the batch data source; if no other data sources reference the same AWS connection, the connection itself is also removed.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "<Fencer Scanner Principal ARN>"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "<your-external-id>"
}
}
}
]
}

The setup guide shows this policy with <Fencer Scanner Principal ARN> and <your-external-id> already replaced by Fencer’s principal ARN and your connection’s external ID.

Once connected, Fencer discovers resources across these categories:

  • Compute: EC2 instances, Lambda functions, Elastic Beanstalk environments
  • Containers: ECS clusters/tasks/task definitions, EKS clusters/deployments/pods, ECR repositories and images
  • Databases: RDS instances and clusters, Aurora, DynamoDB, DocumentDB, ElastiCache, MemoryDB, OpenSearch
  • Storage: S3 buckets
  • Networking: VPCs, subnets, security groups, VPN connections, Route 53 zones/domains, Direct Connect, Network Firewall
  • Application Traffic: API Gateways, Elastic Load Balancers, Amplify apps
  • Content Delivery: CloudFront distributions and functions
  • Security: WAF Web ACLs, CloudTrail trails
  • Analytics: Redshift clusters, Athena workgroups, CloudWatch alarms
  • Messaging: SNS topics, SQS queues, SES identities, MQ brokers
  • Role assumption fails during setup: Verify that the trust policy on your IAM role includes the correct Fencer principal ARN and external ID. The external ID in the form must match the one in the trust policy.
  • Connection shows an issue: Before each scan, Fencer assumes the role and calls sts:GetCallerIdentity, then ec2:DescribeRegions. If the role cannot be assumed or GetCallerIdentity fails, the connection shows Issue; if only DescribeRegions fails, it shows Needs attention. Re-verify the role permissions and trust policy.
  • Monitor connection not receiving logs: Confirm that the S3 replication rule from your source bucket to the Fencer destination bucket is enabled, and that the role it uses has the permission policy from the setup steps.
  • KMS-encrypted buckets: If your source bucket uses a custom KMS key, tick the KMS option during setup so the permission policy Fencer generates includes the KMS permissions replication needs.