Discovery and Inventory

After deployment, with the connector in Connected status on the dashboard, the first process it executes is resource discovery. This means the connector automatically scans all Organization accounts (or the specific account configured) and identifies available resources based on the resource types selected during deployment.

This process is continuous — it's not a one-time scan. The connector periodically checks for newly created resources, removed resources, or changes to existing resources. The Apono catalog is updated automatically, without manual action.

Discovery is passive and read-only. It only identifies and catalogs resources — it does not alter, create, or remove anything in your infrastructure. Write permissions are only used when an Access Flow grants or revokes access.

The discovery scope depends on the integrations selected during connector deployment. For AWS, the main resource types are:

Inventory — The Centralized Catalog

All discovered resources from all connectors and integrations are gathered in a single place: the Inventory tab on the Apono dashboard. This includes resources from AWS, GCP, Azure, Kubernetes, databases, and any other configured integration — all centralized in the same view.

The Inventory listing displays the following columns:

Column	Description
Resources	Name of the discovered resource.
Permissions	Number of permissions associated with the resource.
Risk Scores	Risk score calculated by Apono based on the resource type and permissions.
Integration	Which integration the resource belongs to (e.g., AWS, GCP, Kubernetes).
Resource Type	Type of the resource (e.g., EC2 Instance, RDS Database, S3 Bucket).

When clicking on a resource, you access two detailed views:

• Permissions — lists all available permissions for that resource and who has access.
• Resource Details — displays the resource's tags, including metadata such as aws_account_id, aws_account_name, region, and any custom tags you've applied in AWS.

This centralized visibility is valuable even before creating any Access Flow. With the Inventory, you can quickly visualize the entire resource inventory from all accounts and integrations in a single panel.

This is exactly where the connector's Read-Only mode proves useful. Organizations that want to first visualize the resource inventory before managing access can deploy in Read-Only, validate the discovery, and then upgrade to Full-Access when ready.

Resource Filtering and Organization

With a large Organization, discovery can return hundreds or thousands of resources. The Inventory offers filters to navigate and organize this volume:

Available Filters

Directly in the Inventory interface, you can filter by:

• Integration — filter by integration (AWS, GCP, Kubernetes, etc.).
• Resource Type — filter by resource type (EC2 Instance, RDS Database, S3 Bucket, etc.).
• Resource Name — search resources by name.
• More Filters — additional filters available:
  • Resource Path — resource path in the integration hierarchy.
  • Resource Tag — filter by tags associated with the resource.
  • Resource Status — current resource status.
  • Permission Name — filter by associated permission name.
  • Resource Risk Level — resource risk level.
  • Permission Risk Level — permission risk level.

The click-available filters are already sufficient for the vast majority of cases. However, for more complex scenarios, Apono also supports AQL (Apono Query Language) — a query language that allows building advanced filters combining multiple criteria with logical operators.

Scopes — Saving Filters as Groupings

One of the Inventory's powerful features is the ability to save a filter as a Scope. A Scope is a logical grouping of resources based on the filtering criteria you defined.

Why is this important? Because when creating an Access Flow, you can point to a Scope instead of selecting resources individually. This means:

• A single Flow covers all resources in the Scope — instead of creating a flow per resource or per resource type, you create a flow for the entire, much broader grouping.
• The Scope is dynamic — when a new resource is discovered and matches the filter criteria, it automatically enters the Scope and becomes covered by the associated Access Flow.
• No manual maintenance — there's no need to update the flow when resources are created or removed.

A good practice is to align your AWS tagging strategy with Scopes in Apono. If your resources are already tagged by environment, team, and sensitivity, simply create Scopes based on those tags and associate them with the corresponding Access Flows — the configuration becomes simple and scalable.

The Importance of Tagging Resources

Apono works best when AWS resources are well tagged. Without tags, the only way to define an Access Flow's scope is to select resources individually — which doesn't scale and requires manual updates whenever a resource is created or removed.

With tags, Access Flows become declarative: instead of saying "this flow applies to the prod-db-orders database", you say "this flow applies to all resources with Environment: production and DataClassification: pii". This automatically covers any current and future resource matching the criteria.

Recommended Tags for Apono

Not every tag in your organization is relevant for access control. The most useful tags for Apono are those that reflect risk level, ownership, and business context:

Tag	Common Values	How Apono Uses It
Environment	production, staging, development, pci-dss	Define different approval rules by environment — automatic in dev, manager in staging, manager + security in production or pci
Team	backend, infra, data, security	Restrict which teams can request access to which resources
DataClassification	public, internal, confidential, pii	Apply more rigorous approval flows for resources with sensitive data
CostCenter or Project	project-x, platform, fintech	Segment access by project or business area
ManagedBy	terraform, manual, cloudformation	Identify IaC-managed resources (useful for restricting manual changes)

You don't need to have all these tags from the start. The most important is to have at least the environment tag (Environment) — it alone allows differentiating between production and non-production resources, which is the most critical segmentation for access control.

Applying Tags at Scale

If your organization doesn't yet have a consolidated tagging strategy, there are ways to implement without depending on manual action on each resource:

• Tag Policies (AWS Organizations): Define which tags are mandatory and which values are allowed. This ensures consistency — a resource without the Environment tag can be blocked at creation.
• Terraform/CloudFormation: Add default_tags in the Terraform provider or tags in CloudFormation templates so every IaC-created resource is born tagged.
• AWS Config Rules: Create rules that identify resources without mandatory tags and generate alerts for correction.
• Retroactive tagging: For existing resources, use AWS Tag Editor (in the console) or scripts with the resourcegroupstaggingapi API to apply tags in bulk.

# Example: default_tags in the Terraform provider
# All resources created by this provider inherit these tags automatically
provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      Environment        = "production"
      Team               = "backend"
      DataClassification = "internal"
      ManagedBy          = "terraform"
    }
  }
}

Tagging resources is not just a good practice for Apono — it's a good practice for everything in AWS: cost control, security, compliance, and operations. If your organization invests time in a consistent tagging strategy, the benefit multiplies across all tools that consume these tags, including Apono.

Workaround: Separate Integrations per Account

For organizations that don't yet have a mature tagging strategy, there is an alternative: create separate AWS integrations — one for each account or group of accounts.

Instead of a single integration that discovers everything, you can configure individual integrations like:

• Production Integration — covers only production accounts.
• Staging Integration — covers only staging accounts.
• Dev Integration — covers only development accounts.

With this, even without tags, it's possible to create an Access Flow that points to the production integration and automatically covers all resources in that account. It works as account-based segmentation instead of tag-based.

Although this works, this approach generates more integrations to manage and is less flexible than using tags. The ideal is to combine it with a progressive tagging strategy — start by separating by accounts and, as tagging maturity increases, migrate to tag-based Scopes.

Discovery Frequency and Latency

Discovery is not real-time — it operates in periodic cycles. In practice this means:

• New resources may take a few minutes to appear in Apono's catalog after being created in AWS.
• Removed resources are eventually removed from the catalog when the connector detects they no longer exist.
• Tag changes are updated on the next discovery cycle.

For most scenarios, this latency is insignificant. Access Flows are configured once and automatically apply to resources entering and leaving scope. The fact that a resource takes a few minutes to appear doesn't impact the daily workflow.

Discovery Troubleshooting

If expected resources don't appear in the catalog, check:

• Resource type enabled: Was the resource type (e.g., RDS, EC2) selected during deployment or added later in integrations?
• Account scope: Is the resource in an account that's part of the configured scope (OU or specific account)?
• Connector permissions: Does the cross-account role have read permissions for the resource type in question? In Read-Only mode, permissions are read; in Full-Access, they are read and write.
• Region: Is the resource in a region covered by the connector? Discovery covers all regions by default, but check for network restrictions.
• SSM Agent (for EC2): EC2 instances only appear for SSM access if they have the SSM Agent installed and active.

If the connector has Connected status but no resources appear, the most common issue is that the resource type was not enabled in integrations. Check in Integrations → Catalog → AWS whether the desired resources are selected.