Skip to main content

Amazon Connectors

Amazon Access Analyzer

Integrates with [AWS IAM Access Analyzer](https://aws.amazon.com/iam/access-analyzer/) to retrieve findings that flag resources granting access to external (cross-account) or public principals — S3 buckets, IAM roles, KMS keys, Lambda functions, Secrets Manager secrets, SQS queues, and more. For each configured AWS account and region the connector lists the account's analyzers and walks every finding under them. It emits two paired models: a **Finding** per raw finding occurrence, and a synthetic **FindingDefinition** per exposure *shape* (`resourceType` + `isPublic`). Both models are served from a single API-response cache per sync so the Access Analyzer API is called only once even though the two models sync independently.

Amazon API Gateway

Integrates with [Amazon API Gateway](https://aws.amazon.com/api-gateway/) to inventory the API endpoints published across the configured AWS accounts and regions. API Gateway hosts two distinct API families that are exposed through separate control-plane APIs, so the connector synchronizes two models: **REST APIs** (API Gateway v1) and **HTTP / WebSocket APIs** (API Gateway v2). For each API the connector also enumerates its methods (REST) or routes (HTTP), records their authorization types, and derives whether the API exposes any unauthenticated (`NONE`-auth) surface, which drives public-exposure analysis. Both models are emitted to the UDM `ApiEndpoint` target.

Amazon Control Tower Aggregator

The Amazon Control Tower Aggregator connector integrates with AWS Control Tower to synchronize EC2 instance inventory across every account and region governed by Control Tower. It connects to the Control Tower **Audit Account** in the configured home `region` and queries a named **AWS Config aggregator** (the `aggregatorName` property) that centralizes resource configuration data from all enrolled accounts. Using the AWS Config `SelectAggregateResourceConfig` API it runs an SQL query for `AWS::EC2::Instance` resources, pages through the results, and maps each instance to the Brinqa **Host** UDM model. The connector currently supports EC2 instances only.

Amazon DynamoDB

Integrates with [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) to synchronize the contents of DynamoDB tables into the Brinqa platform. Because DynamoDB is schemaless, this connector is **generic**: each configured table is exposed as its own Brinqa object class (named after the table), and that class's schema is **discovered dynamically** by scanning a sample of the table's items and inferring an attribute per item field. Table rows are read with a parallel (segmented) `Scan` and each item becomes one Brinqa object.

Amazon EC2

Integrates with [Amazon Elastic Compute Cloud (EC2)](https://aws.amazon.com/ec2/) to synchronize compute and networking inventory across the configured AWS accounts and regions. The connector uses the AWS SDK for Java v2 `Ec2Client` to describe EC2 resources and emits ten object types: EC2 instances, security groups, subnets, route tables, network ACLs, Elastic IP addresses, network interfaces, VPC peering connections, EBS volumes, and EBS snapshots. Each object type is synced independently, once per assumed role per region.

Amazon ECR

Integrates with [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) to inventory the private container-image repositories across the configured AWS accounts and regions. For each repository the connector reads its configuration (image tag mutability, scan-on-push, encryption type and KMS key) and its exposure surface — the resource-based repository policy — so downstream analysis can flag publicly pullable repositories. The connector enumerates repositories region by region via the ECR `DescribeRepositories` API and emits one Brinqa object per repository.

Amazon ECS

Integrates with [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) to synchronize container-orchestration inventory across the configured AWS accounts and regions. The connector reads ECS clusters, services, tasks, and task definitions via the AWS SDK for Java v2 `EcsClient` and emits one Brinqa object per resource. Each of the four models maps to the `CloudResource` UDM model. ECS list operations return only ARNs, so every model pairs a `List*` call (to enumerate ARNs) with a batched `Describe*` call (to hydrate the full resource), always requesting the `TAGS` field so resource tags are populated.

Amazon ELBv2

Integrates with [AWS Elastic Load Balancing v2](https://aws.amazon.com/elasticloadbalancing/) to inventory Application, Network, and Gateway load balancers along with their target groups and the health of the individual targets registered to those groups. Across every configured AWS account and region the connector reads load balancers (`DescribeLoadBalancers`), enriches them with tags (`DescribeTags`), reads target groups (`DescribeTargetGroups`), and reads per-target health (`DescribeTargetHealth`), emitting one Brinqa object per load balancer, per target group, and per registered target/health record.

Amazon IAM

Integrates with [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) to synchronize the account's IAM configuration into the Brinqa platform. The connector reads instance profiles, roles (including their attached managed-policy ARNs and inline-policy names), the role inline policy documents, customer-managed policies, and the default version document of each customer-managed policy. IAM is a global AWS service, so the connector always calls the global IAM endpoint (`Region.AWS_GLOBAL`) regardless of the configured region; when `assumeRoleARN` lists multiple roles, each account is synced with its own IAM client.

Amazon Inspector

Integrates with [Amazon Inspector](https://aws.amazon.com/inspector/) (Inspector v2) to retrieve continuous vulnerability and network-exposure findings across the configured AWS accounts and regions. Amazon Inspector scans EC2 instances, ECR container images, and Lambda functions and produces three classes of findings — package vulnerabilities, code vulnerabilities, and network reachability issues. The connector reads those findings via the Inspector v2 `ListFindings` API (one request per severity) and derives eight Brinqa models from the same finding stream: the scanned assets (EC2 instances and other cloud resources), the findings themselves (as vulnerabilities, static code findings, and violations), and their corresponding definitions.

Amazon Lambda

Integrates with [AWS Lambda](https://aws.amazon.com/lambda/) to inventory the Lambda functions across the configured AWS accounts and regions. For each function the connector reads its configuration (runtime, packaging, VPC placement, layers, encryption key, environment variable keys) and its exposure surface — the Function URL configuration and the resource-based invocation policy — so downstream analysis can flag publicly reachable functions. The connector enumerates functions region by region via the Lambda `ListFunctions` API and emits one Brinqa object per function.

Amazon S3

Integrates with [Amazon S3](https://aws.amazon.com/s3/) to inventory the S3 buckets in the configured AWS accounts. For each bucket the connector reads ownership, region, tags, and the full public-access surface — the bucket policy, the bucket ACL, and the S3 Block Public Access (PAB) configuration — and consolidates them into a single effective-public verdict so downstream analysis can flag internet-exposed buckets. The connector enumerates buckets via the global S3 `ListBuckets` API and emits one Brinqa object per bucket.

Amazon Security Hub

Integrates with [AWS Security Hub](https://aws.amazon.com/security-hub/) to retrieve aggregated security findings across the configured AWS accounts and regions. Security Hub consolidates findings from AWS services (GuardDuty, Inspector, Macie, IAM Access Analyzer, security standards controls, etc.) and partner products into a normalized format. The connector reads those findings via either the classic `GetFindings` API (ASFF, the default) or `GetFindingsV2` (OCSF 1.6), selected with the `apiVersion` configuration property, and emits two models: a **Finding** per `(resource, finding)` pair — so a single finding that references multiple resources produces one object per resource — and a **FindingDefinition** per distinct rule/control, which carries the authoritative severity, description and remediation shared by every finding of that rule.