# Amazon Web Services There are several ways to configure Veza to connect to Amazon Web Services (AWS). The method you choose depends on your security requirements and the data sources in your environment. Typically, Veza should connect by [assuming an IAM role](#using-an-iam-role). > If you need to discover non-cloud native data sources within an AWS account, you should use an [Insight Point](#using-an-insight-point) for secure authentication. As a less secure but easy-to-establish connection method, you can optionally [connect to AWS as an IAM user](#using-an-iam-user). If possible, you should integrate your primary AWS Organization account, to enable full extraction of Service Control Policies (SCPs), Resource Control Policies (RCPs), and Organizational Units (OUs). When a primary OU is configured, other accounts not yet connected to Veza can still be audited using the Veza Access Graph. To register AWS accounts at scale using CloudFormation, see [Register AWS Accounts with CloudFormation](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-cloudformation.md). Deployment methods include Control Tower, AWS Organizations StackSet, and single-account stack deployment. ## Supported services Veza extracts the following AWS services. Use the **Limit Services** option when configuring the integration to enable only the services needed — see [Limiting Extractions](/4yItIzMvkpAvMVFAamTf/integrations/configuration/limits.md#limit-services) for instructions. Core services (IAM, STS, and SSO/Identity Center) are always extracted and cannot be disabled. * **Amazon Bedrock**: Agents, foundation models, knowledge bases, guardrails * **Amazon Certificate Manager**: Certificates * **Amazon Cognito**: Identity pools * **Amazon DocumentDB**: Clusters, databases, users, roles * **Amazon DynamoDB**: Tables, streams, secondary indexes * **Amazon EC2**: Instances, VPCs, security groups * **Amazon ECR**: Private and public repositories * **Amazon EKS**: Clusters * **Amazon EMR**: Clusters, studios, notebook executions * **Amazon Neptune**: Clusters, instances * **Amazon Organizations**: Organizational units, accounts, SCPs, RCPs * **Amazon RDS**: Clusters, instances * **Amazon RDS MySQL**: Databases, tables, users, roles * **Amazon RDS Oracle**: Instances, tenant databases * **Amazon RDS PostgreSQL**: Databases, schemas, tables, users, groups * **Amazon Redshift**: Clusters, databases, users, groups * **Amazon Redshift Cluster**: Databases, schemas, tables, users * **Amazon S3**: Buckets, bucket policies * **Amazon Secrets Manager**: Secrets * **Amazon Systems Manager**: Parameters * **AWS Databricks**: Workspaces, clusters, users, groups * **AWS KMS**: Customer-managed keys * **AWS Lambda**: Functions, layers ## 1. Create a Veza-AWS connector policy Whether connecting using an IAM role or IAM user, you will need to create an IAM policy that grants Veza permission to make read-only API calls. You should customize this policy based on the AWS services that Veza will discover. The documentation below provides the base policy for IAM only (required) and the full set of available services. The full policy includes permissions for extracting all supported services. If limiting the services that Veza extracts, building a policy that includes only the needed services achieves a least privilege best practice. To create the role manually using [AWS IAM Console](https://console.aws.amazon.com/iam/home#/home), choose *Policies* > *Create* and select the *JSON* tab. Copy the policy shown below, and give it a name (for example `veza-aws-connector`):
Minimum policy for AWS IAM only ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "STS", "Effect": "Allow", "Action": [ "sts:GetCallerIdentity" ], "Resource": "*" }, { "Sid": "Tag", "Effect": "Allow", "Action": [ "tag:GetResources" ], "Resource": "*" }, { "Sid": "IAM", "Effect": "Allow", "Action": [ "iam:GetAccountAuthorizationDetails", "iam:ListPolicies", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListRoles", "iam:ListGroupsForUser", "iam:ListAttachedRolePolicies", "iam:ListAttachedUserPolicies", "iam:ListUsers", "iam:ListAttachedGroupPolicies", "iam:ListGroups", "iam:GetUser", "iam:GetRole", "iam:ListUserPolicies", "iam:ListGroupPolicies", "iam:ListRolePolicies", "iam:GetUserPolicy", "iam:GetGroupPolicy", "iam:GetRolePolicy", "iam:ListSAMLProviders", "iam:GetSAMLProvider", "iam:ListOpenIDConnectProviders", "iam:GetOpenIDConnectProvider", "iam:ListAccessKeys", "iam:GetAccessKeyLastUsed", "iam:ListInstanceProfiles", "iam:ListAccountAliases", "iam:ListMFADevices", "iam:GetLoginProfile" ], "Resource": "*" } ] } ```
Complete policy for all supported services (2026.3.16) ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "STS", "Effect": "Allow", "Action": [ "sts:GetCallerIdentity" ], "Resource": "*" }, { "Sid": "Tag", "Effect": "Allow", "Action": [ "tag:GetResources" ], "Resource": "*" }, { "Sid": "SSO", "Effect": "Allow", "Action": [ "sso:ListAccountAssignments", "sso:ListPermissionSets", "sso:ListAccountsForProvisionedPermissionSet", "sso:ListInstances", "sso:DescribePermissionSet", "sso:ListTagsForResource", "identitystore:DescribeUser", "identitystore:DescribeGroup", "identitystore:ListUsers", "identitystore:ListGroups", "identitystore:ListGroupMemberships" ], "Resource": "*" }, { "Sid": "IAM", "Effect": "Allow", "Action": [ "iam:GetAccountAuthorizationDetails", "iam:ListPolicies", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListRoles", "iam:ListGroupsForUser", "iam:ListAttachedRolePolicies", "iam:ListAttachedUserPolicies", "iam:ListUsers", "iam:ListAttachedGroupPolicies", "iam:ListGroups", "iam:GetUser", "iam:GetRole", "iam:ListUserPolicies", "iam:ListGroupPolicies", "iam:ListRolePolicies", "iam:GetUserPolicy", "iam:GetGroupPolicy", "iam:GetRolePolicy", "iam:ListSAMLProviders", "iam:GetSAMLProvider", "iam:ListOpenIDConnectProviders", "iam:GetOpenIDConnectProvider", "iam:ListAccessKeys", "iam:GetAccessKeyLastUsed", "iam:ListInstanceProfiles", "iam:ListAccountAliases", "iam:ListMFADevices", "iam:GetLoginProfile" ], "Resource": "*" }, { "Sid": "EC2", "Effect": "Allow", "Action": [ "ec2:DescribeSecurityGroups", "ec2:DescribeVpcs", "ec2:DescribeInstances" ], "Resource": "*" }, { "Sid": "Redshift", "Effect": "Allow", "Action": [ "redshift:DescribeClusters", "redshift:GetClusterCredentials", "redshift-data:ExecuteStatement", "redshift-data:GetStatementResult", "redshift-data:DescribeStatement" ], "Resource": "*" }, { "Sid": "RDS", "Effect": "Allow", "Action": [ "rds:DescribeDBClusters", "rds:DescribeDBInstances", "rds:DescribeGlobalClusters", "rds-db:connect", "rds:DescribeTenantDatabases" ], "Resource": "*" }, { "Sid": "DocumentDB", "Effect": "Allow", "Action": [ "docdb-elastic:GetCluster", "docdb-elastic:ListClusters" ], "Resource": "*" }, { "Sid": "DynamoDB", "Effect": "Allow", "Action": [ "dynamodb:ListTables", "dynamodb:DescribeTable", "dynamodb:ListStreams", "dynamodb:DescribeStream" ], "Resource": "*" }, { "Sid": "EMR", "Effect": "Allow", "Action": [ "elasticmapreduce:ListClusters", "elasticmapreduce:DescribeCluster", "elasticmapreduce:ListNotebookExecutions", "elasticmapreduce:DescribeNotebookExecution", "elasticmapreduce:ListInstanceGroups", "elasticmapreduce:ListInstanceFleets", "elasticmapreduce:ListInstances", "elasticmapreduce:ListStudios", "elasticmapreduce:DescribeStudio" ], "Resource": "*" }, { "Sid": "S3", "Effect": "Allow", "Action": [ "s3:GetBucketPolicy", "s3:ListAllMyBuckets", "s3:GetBucketLocation", "s3:GetBucketPublicAccessBlock", "s3:GetAccountPublicAccessBlock", "s3:GetBucketObjectLockConfiguration", "s3:GetEncryptionConfiguration", "s3:GetBucketLogging", "s3:GetBucketOwnershipControls", "s3:GetBucketRequestPayment", "s3:GetReplicationConfiguration", "s3:GetBucketWebsite", "s3:GetBucketPolicyStatus" ], "Resource": "*" }, { "Sid": "KMS", "Effect": "Allow", "Action": [ "kms:GetKeyPolicy", "kms:ListAliases", "kms:ListKeyPolicies", "kms:ListKeys", "kms:ListResourceTags", "kms:DescribeKey" ], "Resource": "*" }, { "Sid": "Organization", "Effect": "Allow", "Action": [ "organizations:DescribeOrganization", "organizations:DescribePolicy", "organizations:ListChildren", "organizations:DescribeOrganizationalUnit", "organizations:ListPolicies", "organizations:ListPoliciesForTarget", "organizations:ListRoots", "organizations:DescribeAccount" ], "Resource": "*" }, { "Sid": "Cognito", "Effect": "Allow", "Action": [ "cognito-identity:DescribeIdentityPool", "cognito-identity:GetIdentityPoolRoles", "cognito-identity:ListIdentityPools" ], "Resource": "*" }, { "Sid": "Lambda", "Effect": "Allow", "Action": [ "lambda:ListFunctions", "lambda:ListTags", "lambda:GetFunctionConfiguration", "lambda:GetFunction", "lambda:ListLayers", "lambda:ListLayerVersions" ], "Resource": "*" }, { "Sid": "EKS", "Effect": "Allow", "Action": [ "eks:ListClusters", "eks:DescribeCluster" ], "Resource": "*" }, { "Sid": "SecretsManager", "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:ListSecrets" ], "Resource": "*" }, { "Sid": "SystemsManager", "Effect": "Allow", "Action": [ "ssm:DescribeParameters", "ssm:ListTagsForResource" ], "Resource": "*" }, { "Sid": "ECR", "Effect": "Allow", "Action": [ "ecr:DescribeRegistry", "ecr:DescribeRepositories", "ecr:ListTagsForResource", "ecr-public:DescribeRepositories", "ecr-public:ListTagsForResource" ], "Resource": "*" }, { "Sid": "CloudTrail", "Effect": "Allow", "Action": [ "cloudtrail:GetTrail" ], "Resource": "*" }, { "Sid": "CertificateManager", "Effect": "Allow", "Action": [ "acm:ListCertificates", "acm:DescribeCertificate", "acm:ListTagsForCertificate" ], "Resource": "*" }, { "Sid": "RolesAnywhere", "Effect": "Allow", "Action": [ "rolesanywhere:ListTrustAnchors", "rolesanywhere:GetTrustAnchor", "rolesanywhere:ListCrls", "rolesanywhere:GetCrl", "rolesanywhere:ListProfiles", "rolesanywhere:GetProfile", "rolesanywhere:ListTagsForResource" ], "Resource": "*" }, { "Sid": "Bedrock", "Effect": "Allow", "Action": [ "bedrock:ListFoundationModels", "bedrock:ListCustomModels", "bedrock:ListImportedModels", "bedrock:ListAgents", "bedrock:GetAgent", "bedrock:GetGuardrail", "bedrock:ListAgentAliases", "bedrock:ListAgentVersions", "bedrock:GetAgentVersion", "bedrock:ListAgentActionGroups", "bedrock:ListAgentKnowledgeBases", "bedrock:ListKnowledgeBases", "bedrock:ListDataSources", "bedrock:ListPrompts", "bedrock:ListPromptRouters", "bedrock:ListGuardrails" ], "Resource": "*" } ] } ```
> Veza provides CloudFormation templates to assist in creating the policy and even register the AWS account with Veza. For more information see documentation for [Add Existing AWS Accounts](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-cloudformation/aws-organizations.md) and [Control Tower](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-cloudformation/aws-control-tower.md). > If your organization uses Terraform, you can use the following configuration to automate creation of a new policy and role: {% file src="/files/OsGnQR9tbUJ0nMFqgNfx" %} This policy grants the attached principal (IAM user, role, or Insight Point EC2 Instance Profile) the privileges required to discover IAM and tags metadata for the AWS account. It enables Veza to gather entities and authorization relationships for: * Organization * S3 Buckets * EC2 Instances * RDS Databases (MySQL, PostgreSQL) * [DocumentDB](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-documentdb.md) Clusters and Databases (regular and elastic clusters) * Neptune Databases (Global Databases, Clusters, and Instances) * Redshift Data Warehouses * Systems Manager Parameter Store * IAM Identity Providers (both SAML and OIDC) * IAM Roles Anywhere (Trust Anchors, Certificate Revocation Lists, and Profiles) * AWS Certificate Manager (X.509 certificates) * AWS Bedrock (AI agents, foundation models, custom models, knowledge bases, prompts, guardrails) {% hint style="success" %} To enable discovery of AWS IAM Identity Center entities, **Trusted Access** needs to be enabled for the service using either the AWS IAM Identity Center console or the AWS Organizations console: 1. From the AWS Organizations console, navigate to **Services**. 2. Choose **AWS IAM Identity Center**. 3. Choose **Enable trusted access**. 4. Check the box to show the option to enable trusted access without performing additional setup steps. 5. Type "enable" to confirm the change, then click to enable trusted access. See [Enabling trusted access with IAM Identity Center](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-sso.html#integrate-enable-ta-sso) for detailed instructions. {% endhint %} Notes: * Full extraction of Redshift, RDS, and DocumentDB databases requires a local user, which you will need to create and identify in the Veza access policy. For detailed instructions, see the setup guides for RDS [MySQL](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/rds-mysql.md), [PostgreSQL](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/rds-postgresql.md), [DocumentDB](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-documentdb.md), and [AWS Redshift](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-redshift.md). * More details are available on the **Administration** > *Events* page and the integration details view when required permissions are unavailable, or credentials are invalid. * If you want to [limit the extraction](/4yItIzMvkpAvMVFAamTf/integrations/configuration/limits.md) of specific AWS services and resources, you can do so when adding the provider to Veza or using the "Edit Integration" menu. * Service control policies (SCPs), resource control policies (RCPs), and organization units (OUs) are discovered only when connecting to an AWS [organization management account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/org-management.html). RCPs establish permissions boundaries for resources within the organization and are evaluated when calculating effective permissions for supported services (currently AWS Bedrock). * **AWS Certificate Manager Support**: Additional IAM permissions (`acm:ListCertificates`, `acm:DescribeCertificate`, `acm:ListTagsForCertificate`) are required to discover and track X.509 certificates used for authentication across AWS services. * **Enhanced Identity Provider Discovery**: The integration now discovers both SAML and OIDC Identity Providers from AWS IAM, providing complete visibility into identity federation configurations. * **IAM Roles Anywhere**: The integration discovers trust anchors, certificate revocation lists, and profiles used for certificate-based authentication, enabling organizations to track workload access from outside AWS. See [Notes & Supported Entities](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-info.md) for more details on the Veza-AWS integration and supported services ## 2. Configure AWS discovery #### Using an IAM role AWS discovery using an assumed IAM role is the recommended method. The steps below will enable a Veza AWS principal to assume a new role within your organization's AWS account for identity, resource, and authorization discovery. You will need the ID of the Veza AWS account the role will apply to. To get this value: 1. Go to Veza **Integrations** > **Add Integration** 2. Select **AWS** and add a new AWS account * Choose "Assume AWS IAM Role" as the *Authentication Method.* * Fill in the Account ID, Role Name and External ID * Account ID will be the 12-digit numeric ID for the AWS Account being added * Choose a role name based on organization naming policies, for example `veza-discovery-ro` * Generate a UUID or other complex value to use for the external ID 3. Once the values have been filled in, Veza will populate an AWS Trust relationship policy {% hint style="warning" %} The example below uses placeholder values. Replace the account ID, role name, and external ID with the values from your Veza configuration. {% endhint %} **Example policy shown in Veza**: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::[[VEZA_ACCOUNT_ID]]:role/[[TENANT_ID]]-insight-point" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "[[YOUR_EXTERNAL_ID]]" } } } ] } ``` > When creating the role in AWS, ensure that the principal AWS account and external ID values match the ones in the Veza-provided policy. To create the AWS role, you will need administrator access to the AWS account. Complete the steps below using the [AWS Management Console](https://aws.amazon.com/console/): 1. Navigate to **IAM** > *Roles*. Click “Create a role”. 2. Select "AWS account" as the trusted entity, then choose "Another AWS account" as the trusted entity type. Provide the Veza AWS account ID retrieved using the steps above, or provided by your support team. 3. Check the box to require an External ID and give it a unique value. Copy down this External ID, and supply it when [adding the AWS account to Veza](#3-add-the-aws-account-to-veza) using the *New Cloud Provider* wizard. * If you've already saved the Veza configuration, verify that the External IDs are the same. 4. Attach the [IAM policy](#1-create-a-veza-aws-connector-policy) that will permit Veza to extract information about your AWS account. 5. Add optional tags, and give the role a name, description, and verify the trusted entity is correct. Keep note of the new role's name, as it will be required to finish [adding the provider](#3-add-the-aws-account-to-veza) on the Veza **Integrations** page. #### Using an Insight Point Connecting using a role or user will allow Veza to extract information for cloud-native data services using the appropriate APIs (such as AWS S3 and Redshift). However, for data services (for example SQL Server on EC2 Instance, or Oracle on EC2 Instance) that are not cloud-native or not available to external callers, Veza will need to establish connections directly to the entity using an [Insight Point](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md) deployed to your cloud or local environment. If you are connecting the account using an Insight Point, the AWS IAM policy must be updated to enable connection to the Veza ECR repository. Instead of attaching the policy to an IAM user, you will apply the policy to the role assigned to an Insight Point's EC2 instance profile. See the full [Insight Point](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md) instructions for detailed steps. You will need to deploy the Insight Point, and: 1. Create an AWS IAM role with EC2 as the trusted entity. 2. Attach the Veza IAM policy to the role. 3. Assign the role to your Insight Point instance profile. #### Using an IAM user From your AWS account dashboard, create an IAM user and attach the appropriate policy: 1. From the **Specify User Details** interface, input a user name (such as `veza_connector`) and click *Next*. 2. Select the policy you created earlier, and attach it to the new user. 3. Once you have created the IAM user, copy the *Access Key ID* and *Secret Access Key* (you will need to repeat the previous steps if the key is lost). ## 3. Add the AWS account to Veza To enable the provider as a new data source for Veza, navigate to Veza **Integrations** > *Add Integration* > *AWS*. Depending on the authentication method you select in [Step 2](#2-configure-aws-discovery) above, some different information will be required: **Assuming an AWS IAM Role:** This is the recommended method for conducting discovery on AWS and allows Veza to assume an IAM role with the appropriate privileges. * **Account ID**: Enter your AWS Account ID (12-digit number). * **Name**: Provide a display name for this AWS integration in Veza. * **Role Name**: Provide the name of the AWS IAM role you configured with the Veza IAM account as a trusted entity. Use the role name as it appears in the AWS UI (not the full ARN). * **External ID**: This must match the IAM role "trusted entity": * If you **have created the AWS role**, enter the `External ID` you provided from the AWS console. * If you **haven't created the role** at this point, copy the random identifier that appears here, and provide it as the `External ID` when adding [Veza as the trusted entity in AWS](#2-configure-aws-discovery). When you click *Save*, a policy will display, showing the UUID that will be used as the external ID and the trusted AWS account number. If the values aren't the same, you should copy the policy on this screen, and update the Veza connector policy in AWS to match. **Using an IAM user Access Key ID / Secret Access Key:** While user credentials are easy to generate and configure, this option should be considered less secure than IAM role assumption. * Provide the `AWS Access Key ID` and `Secret Access Key` for the IAM user created in [Step 2](#using-an-iam-user). **Using an Insight Point:** Once you have deployed an Insight Point, you can opt to conduct discovery using the IAM role assigned to the Insight Point's EC2 instance profile. * Provide a `Name` to display for the new provider, the AWS `Account ID`, and the local `DB Username`. * From the `Insight Point` list, choose the Insight Point associated with the [policy to use for discovery](#using-an-insight-point). **AWS configuration fields** | Field | Details | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Insight Point | Leave default unless using an Insight Point for discovery. | | Authentication Method | See options below (assuming an AWS IAM Role is recommended). | | Account ID | Your AWS account ID (12-digit number). | | Role name | IAM role to assume. | | External ID | Role external ID (if assuming an AWS IAM role). | | Regions | Regions to discover (required). | | AWS Access Key ID | For the IAM user to connect as (optional). | | AWS Secret Access Key | For the IAM user to connect as (optional). | | Extraction Policy Name | If provided, Veza will check that the specified policy exists in the AWS account and contains all required permissions. | | Gather system tables | Option to gather additional RDS MySQL system tables `sys`, `performance_schema`, `mysql`, and `information_schema`. | | Gather PostgreSQL system schemas | Option to gather PostgreSQL system schemas like `pg_catalog` and `information_schema` (default: false). | | RDS database-level only | Extract only database-level metadata for RDS, skipping table and column details (default: false). | | DB User | Database local username for all RDS and Redshift extraction (optional). | | Redshift DB User | Local username for Redshift extraction (optional). | | RDS MySQL DB User | Local username for MySQL extraction (optional). | | RDS PostgreSQL DB User | Local username for PostgreSQL extraction (optional). | | RDS Oracle DB User | Local username for Oracle extraction (optional). | | RDS Oracle DB Password | Password for Oracle database extraction (optional, encrypted). | | DocumentDB DB User | Local username for DocumentDB database extraction (optional). See [DocumentDB](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/aws-documentdb.md) for setup. | | DocumentDB DB Password | Password for DocumentDB database extraction (optional, encrypted). | | Enable usage for Lifecycle Management | Toggle to enable [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/provisioning.md) capabilities for AWS IAM Identity Center | > You can additionally set allow and deny lists to databases and buckets, or by choosing *Limit Services Extracted* and selecting the services to enable. See [Limiting Extractions](/4yItIzMvkpAvMVFAamTf/integrations/configuration/limits.md) for more information. ### Allow and deny list field values The following allow and deny list fields are available for the AWS integration. When configured, only matching resources are extracted (allow list) or excluded from extraction (deny list). | Field | What it filters | Value format | Example | | --------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- | | S3 Bucket Allow/Deny List | S3 buckets | Bucket [name](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) | `my-data-bucket`, `*-prod-*` | | RDS Database Allow/Deny List | RDS databases | Database [name](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html) | `production-db` | | Redshift Database Allow/Deny List | Redshift databases within a cluster | Database ARN: `arn:aws:redshift:{region}:{account-id}:dbname:{cluster-name}/{database-name}` | `arn:aws:redshift:us-east-1:123456789012:dbname:my-cluster/sales` | {% hint style="info" %} **Redshift databases:** The allow and deny list filters match against the full database ARN, not just the database name. To build the correct ARN, combine your cluster name and database name in the format above. {% endhint %} ## Enable Lifecycle Management The AWS integration supports [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/provisioning.md) capabilities for AWS IAM Identity Center, enabling automated user provisioning, deprovisioning, and group membership management across your AWS organization. To enable Lifecycle Management for your AWS integration, you will need additional SCIM API permissions beyond the standard read-only permissions required for basic integration. These include permissions for creating, updating, and deleting users and groups in AWS IAM Identity Center. Key requirements: * AWS IAM Identity Center must be configured for programmatic access * Additional IAM permissions for Identity Store operations (create, update, delete users and groups) * SCIM API access must be enabled in your AWS IAM Identity Center instance To enable Lifecycle Management: 1. In Veza, go to the **Integrations** overview 2. Search for your AWS integration 3. Check the box to **Enable usage for Lifecycle Management** For detailed configuration instructions, supported actions, and workflow examples, see the [AWS IAM Identity Center Lifecycle Management guide](/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws/provisioning.md). ### Identity mapping AWS integrations support custom identity mapping to connect AWS identities with users and groups in other integrated systems. In addition to standard user and group mappings, AWS uniquely supports **Roles to Users** mapping mode, which allows you to map AWS IAM Roles to local users in any destination system (such as custom applications, Snowflake, SQL Server, or other integrated platforms). For configuration details, see [Custom Identity Mappings](/4yItIzMvkpAvMVFAamTf/integrations/configuration/custom-identity-mappings.md). ### Enable Audit Log Extraction AWS integrations can process CloudTrail audit logs to enable Activity Monitoring and usage analytics. This requires you to enable audit log extraction in the integration details after saving the configuration. To enable this option, expand the additional actions dropdown menu (three dots), and click **Enable Audit Logs**: ![Enabling Audit Log Extraction for an AWS integration.](/files/k52eMy2aEAUP2qG1HbJR) * **CloudTrail Name**: The ARN or name of the CloudTrail trail to process (e.g., `arn:aws:cloudtrail:us-east-1:123456789012:trail/MyTrail`) * **CloudTrail Region**: The AWS region where the CloudTrail trail is configured * **Extract for Organization**: When enabled, processes CloudTrail logs for all accounts in the AWS Organization (requires Organization management account) * **Skip Audit Log Extraction**: Disable CloudTrail log processing entirely (default: false) When enabled, audit log extraction provides: * **Activity Monitoring**: Track user and service activities across AWS resources * **Usage Metadata**: Collect data access patterns for compliance and security analysis * **Principal Activity Tracking**: Monitor IAM user activities and access patterns Audit log extraction requires the `AUDITLOG_DATA_ACTIVITY` feature enabled for your tenant. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/aws.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.