Apono Query Language
Learn the key concepts of the Apono Query Language
The Apono Query Language (AQL) provides a simple, intuitive syntax for filtering cloud resources, integrations, and permissions.
This reference documents query construction, available components, and common filtering examples.
When you are first starting to build queries, you can quickly learn how to build them by following these steps:
On the Inventory page, click Basic.
Click AQL. The AQL syntax will appear in the code box.
Syntax
The following is a basic AQL query.
AQL uses a simple field-operator-value pattern.
Attribute or tag to query
Comparative logic
value
Expected value for the field
AQL values must be enclosed in double quotes (""). A backslash (\) can be used to escape special characters inside a string.
AQL does not support embedded newlines inside string values and rejects single quotes ('').
field
The field component specifies the attribute of your cloud resources to query.
All resource field names are case sensitive and strictly matched.
For example, when querying for a resource type (resource_type), AQL rejects Resource_Type because the casing is incorrect and resource_types because it does not match a supported field name.
resource_name
Human-readable display name for the resource
resource_name contains "prod"
resource_path
Hierarchical path within the integration
resource_path contains "us-east-1"
resource_source_id
Native identifier in the source system, such as an ARN
resource_source_id = "arn:aws:iam::123:role/admin"
All permission field names are case sensitive and strictly matched.
For example, when querying for a permission name (permission_name), AQL rejects Permission_Name because the casing is incorrect and permission_names because it does not match a supported field name.
permission_name
Human-readable display name for the permission
permission_name = "ReadOnly"
permission_risk_level
Permission risk level
permission_risk_level = "critical"
The integration field name is case sensitive and strictly matched.
For example, when querying for an integration (integration), AQL rejects Integration because the casing is incorrect and integrations because it does not match a supported field name.
All metadata field names are case sensitive and strictly matched.
For example, when querying for a resource tag (resource_tag), AQL rejects Resource_Tag because the casing is incorrect and resource_tags because it does not match a supported field name.
resource_tag["key"]
Resource tags
resource_tag["environment"] = "prod"
resource_context["key"]
Resource context
resource_context["region"] = "us-east-1"
permission_context["key"]
Permission context
permission_context["access"] = "write"
operator
The operator component defines how to evaluate the field against the specified value.
Basic operators that test for equality and inequality between values
=
Checks if values are the same
resource_type = "aws-account-dynamodb-table"
!=
Checks if values are different
integration != "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Operators that perform case-sensitive text comparisons against literal string values
All string matching operators are case sensitive.
For example, when checking if a literal string is contained (contains) as a substring, AQL rejects CONTAINS because the casing is incorrect.
contains
Checks if a value contains another literal string as a substring
(resource_tag["aws:cloudformation:stack-name"] contains "apono-cloudtrail")
not_contains
Checks if a value does NOT contain a literal string as a substring
permission_name not_contains "admin"
starts_with
Checks if a value begins with a specific string
resource_name starts_with "aws"
ends_with
Checks if a value ends with a specific string
(resource_tag["env"] ends_with "dev")
Operators that check if values exist within defined sets of options
All list operators are case sensitive.
For example, when checking if a value is in a list (in), AQL rejects IN because the casing is incorrect.
in (_)
Checks if the value is one of a list
Use a comma-separated list enclosed in parentheses. Do not add a comma after the final item.
resource_type in ("aws-account-dynamodb-table", "aws-account-s3", "aws-account-sns-topic")
resource_source_id in ("arn:aws:s3:::bucket-a", "arn:aws:s3:::bucket-b")
not_in (_)
Checks if the value is NOT one of a list
Use a comma-separated list enclosed in parentheses. Do not add a comma after the final item.
(resource_tag["aws:cloudformation:stack-name"] not_in ("apono-cloudtrail", "apono-doxy-dev"))
Operators that combine multiple conditions to create complex queries
Logic operators are not case sensitive.
and | AND
Checks if both conditions are true
resource_type = "aws-account-s3" AND permission_name = "admin"
or | OR
Checks if either condition is true
resource_type = "aws-account-s3" OR resource_name contains "playground"
not | NOT
Negates a condition
integration = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" and not resource_type = "aws-account-sns-topic"
Unsupported
Operators not supported by AQL
*
Wildcards
resource_name = "prod-*"
<, >, <=, >=
Numeric comparison
resource_risk_level <= "high"
^, $, +, ?
Regular expressions (regex)
resource_name = "^prod"
resource_name = "prod-?s"
between
Ranges
between "2024-01-01" and "2024-12-31"
exists
Existence checks
exists(resource_tag["owner"])
null
Null checks
resource_tag["owner"] = null
Common Queries
The following AQL queries demonstrate how to efficiently locate, audit, and manage cloud resources and permissions. They cover common use cases such as identifying high-risk assets, tracking access levels, and enforcing security policies.
Use these queries as a foundation and customize them to fit your specific environment and compliance requirements.
Resource Queries
Queries focused on locating and filtering cloud infrastructure resources
Permission Queries
Queries that manage and audit access control settings
Combined Queries
Advanced patterns that merge resource and permission conditions for precise access control
Best Practices
Follow these best practices to write AQL queries that are clear, efficient, and easy to modify. These guidelines improve readability, execution speed, and adaptability.
Start with a specific condition
AQL processes conditions from left to right. Starting with a specific filter improves efficiency.
Use lists instead of multiple OR conditions
When checking multiple values, in (...) is more concise and performs better than chaining multiple or conditions.
Use parentheses to avoid ambiguity
Without parentheses, complex conditions can be misinterpreted and return unexpected results. Grouping conditions explicitly ensures the query evaluates as intended.
Last updated
Was this helpful?