AWS

Conecta una cuenta AWS en Account → Cloud accounts. Elige AWS y luego Add account. Mantén ese drawer abierto mientras lanzas el stack.

Koltto no pide una access key. El stack crea un rol de solo lectura llamado koltto/KolttoReaders. La cuenta de Koltto asume ese rol, y solo si el ExternalId del stack coincide con el que muestra el drawer.

El gasto viene del Cost and Usage Report en tu bucket S3, no de Cost Explorer. Es el mismo reporte que documenta la facturación de AWS: líneas por hora con resource IDs, entregadas por AWS a un bucket que tú posees.

Una cuenta vs una organización

El stack corre en una cuenta AWS. Esa es toda la configuración si solo tienes una cuenta — sin paso extra.

Configuración	Qué cubre este stack
Una cuenta AWS (sin organización, o la única cuenta)	Inventory, métricas de CloudWatch y costo de esa cuenta.
AWS Organizations — payer	Lo mismo, en el payer. El CUR en el payer puede incluir gasto de cuentas vinculadas. Inventory y métricas se quedan en el payer hasta que cada miembro tenga su propio rol.
Cuentas member / child	No lances este stack en un member. Con DeployToOrganization = Yes en el payer, AWS crea ahí el rol de miembro. Koltto no pide que abras cada cuenta hija.

organizations:ListAccounts está permitido para que Koltto vea el roster de la org. El payer sigue siendo una sola conexión en Koltto. Ejecuta Refresh data después del update del stack para que aparezcan las cuentas nuevas.

Qué hace “Launch CloudFormation in AWS”

El botón no cambia tu cuenta por sí solo. Abre la consola de CloudFormation en us-east-1 con la plantilla de Koltto en S3 y el ExternalId del drawer ya puesto. El recurso del reporte de costos solo existe en us-east-1, así que todos los stacks de clientes se crean ahí. No se crea nada hasta que elijas Create stack. Necesitas permiso en esa cuenta de AWS para crear IAM y, si dejas que el stack cree el reporte, S3 y un Cost and Usage Report.

Cuando el stack termina, esto queda en tu cuenta:

• Un rol de solo lectura koltto/KolttoReaders. Koltto puede asumirlo solo con el ExternalId del drawer. Puedes quitar el acceso después borrando el rol o el stack. El stack no crea una access key.
• O un CUR por hora nuevo y el bucket koltto-cur-<account-id> (prefix koltto), o solo el permiso para leer un bucket CUR que ya tienes. Ese bucket nuevo bloquea el acceso público. Solo AWS Billing, y solo esta cuenta, puede escribir objetos en él. El reporte incluye resource IDs.

El bucket se cobra en tu cuenta de AWS. Koltto no hospeda ese bucket. Borrar el stack elimina el rol y, si este stack creó el reporte, detiene ese reporte. El bucket y los archivos que ya tiene se quedan, para no borrar el historial de facturación. Si quieres quitarlo, bórralo tú en S3. Un reporte que ya era tuyo no forma parte de este stack, así que borrarlo no toca ese bucket.

Lanzar el stack

1. En el drawer de agregar cuenta, copia el ExternalId. Deja el drawer abierto. Puedes pegarlo de nuevo si la página se recarga.
2. Elige Launch CloudFormation in AWS.
3. Crea el stack en us-east-1. Nombre KolttoReaders. Confirma que ExternalId coincide con el drawer. En el formulario de Koltto pon Region en us-east-1.
4. En la página de opciones, antes de crear o actualizar:

Opción	Qué elegir
Express mode	Déjalo apagado. Si el create falla, debe revertirse.
Behavior on failure	Roll back all resources.
Disable deployment validations	Déjalo apagado.
Resource auto-import	Disable. El rol y el bucket ya pertenecen a este stack. Enable puede adoptar otros recursos que no son parte de este cambio.
Reconocimiento de IAM	Marca la casilla. El template crea un rol con nombre propio.

1. Parámetros:

Parámetro	Cuándo usarlo
ExternalId	El valor del drawer de Koltto. Obligatorio. No dejes el placeholder koltto-pending.
CreateCostReport = Yes (default)	CUR por hora nuevo con resource IDs, más bucket koltto-cur-<account-id> y prefix koltto. El stack también permite que AWS Billing entregue objetos a ese bucket.
CreateCostReport = No	Ya tienes un CUR (reporte legacy o Data Exports en el mismo bucket). Define ExistingCurBucket y ExistingCurPrefix. El stack solo crea IAM. El reporte existente debería incluir resource IDs.
DeployToOrganization = No (default)	Una sola cuenta. No se crean roles en otras cuentas.
DeployToOrganization = Yes	AWS instala el rol de miembro en cada cuenta bajo OrganizationalUnitId, incluidas las que agregues después. Antes activa el acceso de confianza de CloudFormation StackSets en la cuenta de administración. Pega el id de Root (r-xxxx) desde Organizations → AWS accounts.

Copia AccountId, CurS3Bucket y CurPrefix de la pestaña Outputs del stack al drawer, y guarda. Esos tres salen igual en los dos casos: el bucket que creó este stack, o ExistingCurBucket / ExistingCurPrefix si ya tenías un reporte.

El nombre del bucket está listo cuando el stack termina. El primer archivo CUR puede tardar hasta 24 horas. En la consola de AWS Billing, Cost and Usage Reports muestra el reporte que creó el stack (o el existente al que apuntaste). Inventory puede empezar en cuanto guardas; el gasto se queda vacío hasta que ese archivo exista y ejecutes Refresh data → Cost.

Qué puede hacer el rol

Solo lectura. Koltto no puede crear, iniciar, detener ni eliminar tus recursos.

Área	Acciones permitidas
Identidad	sts:GetCallerIdentity
Roster de la organización	organizations:ListAccounts
Inventory	List y describe de solo lectura para EC2, EFS, balanceadores, RDS, Aurora, ElastiCache, DynamoDB, ECS, EKS, Lambda, Redshift y OpenSearch, más s3:ListAllMyBuckets, s3:GetBucketLocation, s3:GetBucketTagging
Metrics	cloudwatch:ListMetrics, cloudwatch:GetMetricData
Costo	s3:ListBucket, s3:GetBucketLocation y s3:GetObject solo en el bucket del CUR, no en todos los buckets
Otras cuentas	Si DeployToOrganization es Yes, un StackSet crea koltto/KolttoReaders en esas cuentas. El rol del payer también puede sts:AssumeRole ese mismo rol.

No incluido: Cost Explorer, Resource Explorer, listar llaves de objetos fuera del bucket CUR, ni ninguna acción de escritura.

La memoria de EC2 en Inventory solo aparece si la instancia tiene el agente de CloudWatch (o equivalente) publicando memoria. CPU, disco, load balancer y storage no necesitan ese agente.

Campos del formulario

Campo	Qué ingresar
Name	Una etiqueta en Koltto (prod-core).
Region	Región home para la API. En la primera conexión usa us-east-1, la misma región del stack.
ExternalId	Lo muestra Koltto. Pega el mismo valor en el stack. No inventes otro.
Account ID	ID de cuenta AWS de 12 dígitos (output AccountId del stack).
CUR S3 bucket	Output CurS3Bucket del stack. Obligatorio.
CUR prefix	Output CurPrefix del stack (koltto cuando el stack creó el reporte). Opcional si tu reporte existente no tiene prefix.

Después de guardar

Koltto comprueba que puede asumir el rol. Si el stack usó otro ExternalId, el guardado falla y no se almacena nada. Luego empieza Inventory. Ejecuta Refresh data → Cost para que Overview y Spend Analytics se llenen — después de que el primer archivo CUR esté en el bucket. Ejecuta Metrics si quieres Opportunities.

Puedes editar el bucket CUR y el prefix después.

Esta cuenta se vuelve una organización después

No borres el stack. En la cuenta de administración, abre CloudFormation en us-east-1 y activa el trusted access de StackSets si aún no está.

Update del stack KolttoReaders. Elige Replace current template y la misma URL de S3 del botón, para que aparezcan los parámetros nuevos. No cambies el ExternalId.

Pon DeployToOrganization en Yes y OrganizationalUnitId en el id de Root (r-xxxx) de Organizations → AWS accounts. Usa la misma tabla de opciones del primer lanzamiento, incluido Resource auto-import = Disable, y acepta IAM.

Cuando el update termine, ejecuta Refresh data en Koltto una vez. Una cuenta hija que agregues después bajo ese root recibe el rol desde AWS. No la agregas en Koltto. Un cambio de permisos más adelante es otro update de este mismo stack del payer, no un stack en cada hija.

El inventario cubre EC2, EKS, instancias RDS, clusters de Aurora, snapshots de base de datos, ElastiCache, EBS, S3, EFS, balanceadores, NAT gateways, grupos de CloudWatch Logs y WAFv2 (regional y CloudFront). Un stack ya creado lista los servicios nuevos solo después de actualizarlo. Hasta esa actualización, si falta un permiso se omite ese servicio y el resto del sync sigue.