# AWS Best Practices

When granting AWS access permissions, listing individual ARNs in IAM policies can quickly cause you to exceed [AWS's inline policy character limit](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entity-length). Apono solves this through [access scopes](https://docs.apono.io/docs/inventory/access-scopes) and the [Apono Query Language (AQL)](https://docs.apono.io/docs/inventory/apono-query-language). These solutions use regex patterns to efficiently manage resource groups instead of listing individual ARNs.

For additional protection, Apono has implemented a **100-resource threshold** as a guardrail when individual ARN specification is needed.

The following sections explain how Apono prevents you from exceeding AWS's inline policy limit:

* Create strategic AWS resource groupings for access flows
* Understand how Apono provides clear warnings when the AWS policy limit is exceeded
* Learn how Apono maintains consistent behavior whether your team uses Portal, Teams, or Slack

For example, instead of individually specifying 200 S3 buckets in a policy (which would exceed AWS's limit), you can use resource tags to group them by environment or function.

{% hint style="info" %}
Apono validates for the following types of AWS resources:

* ASM Secret
* DynamoDB table
* EC2 Connect
* EC2 Manage
* S3 Bucket (by "any resource" and region tags)
* SNS Topic
* SQS queue
  {% endhint %}

***

### Prerequisite

<table><thead><tr><th width="246">Item</th><th>Description</th></tr></thead><tbody><tr><td><strong>Apono Connector</strong></td><td><p>On-prem <a href="../../apono-connector-for-aws">connection</a> serving as a bridge between an AWS instance and Apono</p><p><strong>Minimum Required Version</strong>: 1.7.0</p><p>Use the following steps to <a href="../../apono-connector-for-aws/updating-a-connector-in-aws">update an existing connector</a>.</p></td></tr></tbody></table>

***

### Admin Guidance

When defining access flows that include AWS resources, your resource definition strategy directly impacts policy management.

#### Questions

Before selecting AWS resources for an access flow, consider the following questions:

* Can all resources of an integration be selected?
* Have tags been applied to logically group resources by environment, function, or team?
* Can an [access scope](https://docs.apono.io/docs/inventory/access-scopes) be created to group resources across multiple AWS integrations?
* Is individual resource selection truly necessary for security requirements?

#### Resource Definition Strategies

To effectively manage AWS permissions while avoiding policy character limits, you can use access scopes, integrations, or bundles. **When possible, we strongly recommend using access scopes or AQL.**

The following table explains the strategy for each approach.

<table><thead><tr><th width="191">Type</th><th>Strategy</th></tr></thead><tbody><tr><td><strong>Access Scopes</strong></td><td><p>(<strong>Strongly Recommended</strong>, <a href="../../../access-flows/access-flows">All Access Flows</a>) Use when you need dynamic, rule-based resource grouping</p><p><br>Access scopes and AQL let you create flexible filters that adapt to your changing infrastructure. This makes them ideal for scenarios like <em>all production databases</em> or <em>EC2 instances in the eu-region</em>.</p></td></tr><tr><td><strong>Integrations</strong></td><td><p>(<a href="../../../access-flows/creating-access-flows-in-apono/automatic-access-flows">Automatic Access Flow</a>) Use when providing access to an entire AWS account or organization, or to resources that share specific tags</p><p>Integrations let you align permissions with your organization structure:</p><ul><li>Use <strong>tags</strong> in your cloud environment to group resources, such as <em>production</em>, <em>eu-region</em>, <em>customer-support</em>.</li><li>Apply <strong>Any resources</strong> when all resources of the integration can be included.</li></ul><p>This strategy is ideal for scenarios like <em>managing cross-account DevOps access</em> or <em>regional support team permissions</em>.</p></td></tr><tr><td><strong>Bundles</strong></td><td><p>(<a href="../../../access-flows/creating-access-flows-in-apono/automatic-access-flows">Automatic Access Flow</a>, <a href="../../../access-flows/creating-access-flows-in-apono/self-serve-access-flows">Self Serve Access Flow</a>) Use when packaging related resources as a cohesive unit for user requests</p><p>Bundles let you create logical groupings of permissions that serve specific functions.</p><p>When <a href="../../../access-flows/create-bundles">creating a bundle</a> explore one of the following options:</p><ul><li>Use <strong>tags</strong> in your cloud environment to group resources, such as <em>production</em>, <em>eu-region</em>, <em>customer-support</em>.</li><li>Apply <strong>Any resources</strong> when all resources of the integration can be included.</li></ul><p>This strategy is ideal for scenarios like <em>complete development environment access</em> or <em>full analytics platform access</em>.</p></td></tr></tbody></table>

#### Apono Safeguard

If you select too many AWS resources for an access flow, the Apono UI will display a warning message instructing you to reduce the number of selected resources.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXcDJyqA61tTW5e45u0zyq20AAUcPtyJHgSANhDP2qhP5BPKxYLNDxYZj-dAXJ7qYRS_1990FBhhEkpNY9ZmyTvag2iycU8TZ_PW-tZypDiBZ9GPSVYboi5ywkWLDqrhKUEwbAWaAA?key=PbgIpkvwx-rfVpSxnt1_h4HI" alt="" width="563"><figcaption><p>Warning message</p></figcaption></figure>

<table><thead><tr><th width="190">Access Flow</th><th>Conditions</th></tr></thead><tbody><tr><td><strong>Automatic</strong></td><td><ul><li>You have selected more than 100 AWS resources by name (<strong>Select by name</strong>) from one integration or between multiple integrations.</li><li>You have selected more than 100 AWS resources by name (<strong>Select by name</strong>) within one bundle or between multiple bundles.</li></ul></td></tr><tr><td><strong>Self Serve</strong></td><td><ul><li>You have selected more than 100 AWS resources within one bundle or between multiple bundles.</li></ul></td></tr></tbody></table>

***

### Requestor Guidance

When requesting access to many AWS resources, Apono will warn you if you have selected too many AWS resources.

<figure><img src="https://1094436629-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fv6MBfUGvblSdAz31yJXm%2Fuploads%2Fgit-blob-f501348e6743d51509ba589deccede587ef6f139%2FScreenshot%202025-01-27%20at%2010.26.44.png?alt=media" alt=""><figcaption><p>Warning message</p></figcaption></figure>

You will receive different notifications about AWS resource limits depending on which platform you use to submit your access request:

* **Portal & Teams**: Apono displays a warning before submission when you click Request, preventing requests that exceed the limit.

{% hint style="info" %}
In some cases, the request might pass initial validation but still trigger a post-submission notification to select fewer resources.
{% endhint %}

* **Slack**: Apono processes your request first, then sends a message if you need to resubmit with fewer resources.

#### Known Limitations While Building Access Flows, Bundles, and Access Scopes

The following configurations within access flows or when bundling multiple resources will exceed AWS policy size constraints.

* **Specifying resources by name or ID:** Selecting specific resource names or IDs one by one.
* **S3 buckets**: as AWS does not support tagging buckets, it should be handled with region tags or through access scopes or AQL patterns where possible.
* **Excluding a list of resource names or ID**: choosing a list of resources to exclude can similarly inflate policy size and is best handled through access scopes or AQL patterns where possible.