Discovery e Inventory

Después del deploy, con el connector en status Connected en el dashboard, el primer proceso que ejecuta es el discovery de recursos. Esto significa que el connector escanea automáticamente todas las cuentas de la Organization (o la cuenta específica configurada) e identifica los recursos disponibles basándose en los tipos de recursos seleccionados durante el deploy.

Este proceso es continuo — no es un escaneo único. El connector periódicamente verifica si hay nuevos recursos creados, recursos eliminados o cambios en recursos existentes. El catálogo en Apono se actualiza automáticamente, sin necesidad de acción manual.

El discovery es pasivo y de lectura. Solo identifica y cataloga recursos — no altera, crea ni elimina nada en tu infraestructura. Los permisos de escritura se usan solo cuando un Access Flow concede o revoca un acceso.

El alcance del discovery depende de las integraciones seleccionadas durante el deploy del connector. Para AWS, los principales tipos de recursos son:

Inventory — El Catálogo Centralizado

Todos los recursos descubiertos de todos los connectors e integraciones se reúnen en un único lugar: la pestaña Inventory en el dashboard de Apono. Esto incluye recursos de AWS, GCP, Azure, Kubernetes, bases de datos y cualquier otra integración configurada — todo centralizado en la misma vista.

El listado del Inventory muestra las siguientes columnas:

Columna	Descripción
Resources	Nombre del recurso descubierto.
Permissions	Cantidad de permisos asociados al recurso.
Risk Scores	Puntuación de riesgo calculada por Apono basándose en el tipo de recurso y los permisos.
Integration	A qué integración pertenece el recurso (ej: AWS, GCP, Kubernetes).
Resource Type	Tipo del recurso (ej: EC2 Instance, RDS Database, S3 Bucket).

Al hacer clic en un recurso, se accede a dos vistas detalladas:

• Permissions — lista todos los permisos disponibles para ese recurso y quién tiene acceso.
• Resource Details — muestra las tags del recurso, incluyendo metadatos como aws_account_id, aws_account_name, región y cualquier tag personalizada que hayas aplicado en AWS.

Esta visibilidad centralizada es valiosa incluso antes de crear cualquier Access Flow. Con el Inventory, puedes visualizar rápidamente todo el inventario de recursos de todas las cuentas e integraciones en un único panel.

Es exactamente aquí donde el modo Read-Only del connector se muestra útil. Organizaciones que quieren primero visualizar el inventario de recursos antes de gestionar accesos pueden hacer el deploy en Read-Only, validar el discovery y después actualizar a Full-Access cuando estén listas.

Filtrado y Organización de Recursos

Con una Organization grande, el discovery puede retornar cientos o miles de recursos. El Inventory ofrece filtros para navegar y organizar este volumen:

Filtros Disponibles

Directamente en la interfaz del Inventory, es posible filtrar por:

• Integration — filtrar por integración (AWS, GCP, Kubernetes, etc.).
• Resource Type — filtrar por tipo de recurso (EC2 Instance, RDS Database, S3 Bucket, etc.).
• Resource Name — buscar recursos por nombre.
• More Filters — filtros adicionales disponibles:
  • Resource Path — ruta del recurso en la jerarquía de la integración.
  • Resource Tag — filtrar por tags asociadas al recurso.
  • Resource Status — estado actual del recurso.
  • Permission Name — filtrar por nombre de permiso asociado.
  • Resource Risk Level — nivel de riesgo del recurso.
  • Permission Risk Level — nivel de riesgo del permiso.

Los filtros disponibles por clic ya son suficientes para la gran mayoría de los casos. Sin embargo, para escenarios más complejos, Apono también soporta AQL (Apono Query Language) — un lenguaje de consulta que permite construir filtros avanzados combinando múltiples criterios con operadores lógicos.

Scopes — Guardando Filtros como Agrupamientos

Uno de los recursos poderosos del Inventory es la posibilidad de guardar un filtro como un Scope. Un Scope es un agrupamiento lógico de recursos basado en los criterios de filtrado que definiste.

¿Por qué es esto importante? Porque al crear un Access Flow, puedes apuntar a un Scope en lugar de seleccionar recursos individualmente. Esto significa que:

• Un único Flow cubre todos los recursos del Scope — en lugar de crear un flow por recurso o por tipo de recurso, creas un flow para el agrupamiento completo, mucho más abarcador.
• El Scope es dinámico — cuando un nuevo recurso es descubierto y corresponde a los criterios del filtro, automáticamente entra en el Scope y pasa a estar cubierto por el Access Flow asociado.
• Sin mantenimiento manual — no es necesario actualizar el flow cuando recursos son creados o eliminados.

Una buena práctica es alinear la estrategia de tagging de AWS con los Scopes en Apono. Si tus recursos ya están etiquetados por ambiente, equipo y sensibilidad, basta crear Scopes basados en esas tags y asociarlos a los Access Flows correspondientes — la configuración se vuelve simple y escalable.

La Importancia de Etiquetar los Recursos

Apono funciona mejor cuando los recursos de AWS están bien etiquetados. Sin tags, la única forma de definir el alcance de un Access Flow es seleccionar recursos individualmente — lo que no escala y exige actualización manual siempre que un recurso es creado o eliminado.

Con tags, los Access Flows se vuelven declarativos: en lugar de decir "este flow se aplica a la base prod-db-orders", dices "este flow se aplica a todos los recursos con Environment: production y DataClassification: pii". Esto cubre automáticamente cualquier recurso actual y futuro que corresponda a los criterios.

Tags Recomendadas para Apono

No toda tag existente en tu organización es relevante para control de acceso. Las tags más útiles para Apono son aquellas que reflejan nivel de riesgo, propiedad y contexto de negocio:

Tag	Valores Comunes	Cómo la Utiliza Apono
Environment	production, staging, development, pci-dss	Definir reglas de aprobación diferentes por ambiente — automática en dev, gestor en staging, gestor + seguridad en producción o pci
Team	backend, infra, data, security	Restringir qué equipos pueden solicitar acceso a qué recursos
DataClassification	public, internal, confidential, pii	Aplicar flujos de aprobación más rigurosos para recursos con datos sensibles
CostCenter o Project	proyecto-x, plataforma, fintech	Segmentar accesos por proyecto o área de negocio
ManagedBy	terraform, manual, cloudformation	Identificar recursos gestionados por IaC (útil para restringir cambios manuales)

No es necesario tener todas estas tags desde el inicio. Lo más importante es tener al menos la tag de ambiente (Environment) — ella sola ya permite diferenciar entre recursos de producción y no-producción, que es la segmentación más crítica para control de acceso.

Aplicando Tags en Escala

Si tu organización aún no tiene una estrategia de tagging consolidada, existen formas de implementar sin depender de acción manual en cada recurso:

• Tag Policies (AWS Organizations): Definen qué tags son obligatorias y qué valores son permitidos. Esto garantiza consistencia — un recurso sin la tag Environment puede ser bloqueado en la creación.
• Terraform/CloudFormation: Agrega default_tags en el provider de Terraform o tags en los templates de CloudFormation para que todo recurso creado por IaC nazca etiquetado.
• AWS Config Rules: Crea reglas que identifiquen recursos sin tags obligatorias y genere alertas para corrección.
• Tagging retroactivo: Para recursos existentes, usa el AWS Tag Editor (en la consola) o scripts con la API resourcegroupstaggingapi para aplicar tags en lote.

# Ejemplo: default_tags en el provider Terraform
# Todos los recursos creados por este provider heredan estas tags automáticamente
provider "aws" {
  region = "us-east-1"

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

Etiquetar recursos no es solo una buena práctica para Apono — es una buena práctica para todo en AWS: control de costos, seguridad, cumplimiento y operaciones. Si tu organización invierte tiempo en una estrategia de tagging consistente, el beneficio se multiplica en todas las herramientas que consumen esas tags, incluyendo Apono.

Workaround: Integraciones Separadas por Cuenta

Para organizaciones que aún no poseen una estrategia de tagging madura, existe una alternativa: crear integraciones separadas en AWS — una para cada cuenta o grupo de cuentas.

En lugar de una única integración que descubre todo, puedes configurar integraciones individuales como:

• Integración Producción — cubre solo las cuentas de producción.
• Integración Staging — cubre solo las cuentas de staging.
• Integración Dev — cubre solo las cuentas de desarrollo.

Con esto, incluso sin tags, es posible crear un Access Flow que apunte a la integración de producción y automáticamente cubra todos los recursos de esa cuenta. Funciona como una segmentación por cuenta en lugar de por tag.

Aunque funciona, este enfoque genera más integraciones que gestionar y es menos flexible que usar tags. Lo ideal es combinarlo con una estrategia de tagging progresiva — comienza separando por cuentas y, a medida que la madurez de tagging aumenta, migra a Scopes basados en tags.

Frecuencia y Latencia del Discovery

El discovery no es en tiempo real — opera en ciclos periódicos. En la práctica esto significa:

• Recursos nuevos pueden tardar algunos minutos en aparecer en el catálogo de Apono después de ser creados en AWS.
• Recursos eliminados son eventualmente eliminados del catálogo cuando el connector detecta que ya no existen.
• Cambios en tags se actualizan en el próximo ciclo de discovery.

Para la mayoría de los escenarios, esta latencia es insignificante. Los Access Flows se configuran una vez y se aplican automáticamente a recursos que entran y salen del alcance. El hecho de que un recurso tarde algunos minutos en aparecer no impacta el flujo de trabajo diario.

Troubleshooting del Discovery

Si los recursos esperados no aparecen en el catálogo, verifica:

• Tipo de recurso habilitado: ¿El tipo de recurso (ej: RDS, EC2) fue seleccionado durante el deploy o agregado posteriormente en las integraciones?
• Alcance de cuentas: ¿El recurso está en una cuenta que forma parte del alcance configurado (OU o cuenta específica)?
• Permisos del connector: ¿El cross-account role tiene permisos de lectura para el tipo de recurso en cuestión? En modo Read-Only, los permisos son de lectura; en Full-Access, son de lectura y escritura.
• Región: ¿El recurso está en una región cubierta por el connector? El discovery abarca todas las regiones por defecto, pero verifica si no hay restricciones de red.
• SSM Agent (para EC2): Las instancias EC2 solo aparecen para acceso SSM si tienen el SSM Agent instalado y activo.

Si el connector está con status Connected pero ningún recurso aparece, el problema más común es que el tipo de recurso no fue habilitado en las integraciones. Verifica en Integrations → Catalog → AWS si los recursos deseados están seleccionados.