AWS FTR Compliance — Plataforma Imagy

Que es AWS Foundational Technical Review (FTR)

El AWS Foundational Technical Review es un proceso de validacion tecnica que AWS aplica a soluciones de partners para verificar que cumplen con las mejores practicas de seguridad, confiabilidad y excelencia operacional. Es un requisito obligatorio para:

Obtener el estatus de AWS Partner (Software Path)
Listar la plataforma en AWS Marketplace
Acceder a beneficios del programa de partners (co-sell, funding, leads)
Demostrar a clientes enterprise que la solucion cumple estandares AWS

El FTR no es una certificacion de una sola vez — requiere cumplimiento continuo y puede ser re-evaluado periodicamente.

Por que Necesitamos FTR

Imagy es una plataforma SaaS multi-tenant para servicios financieros que se despliega en AWS. El FTR nos permite:

Credibilidad — Clientes financieros exigen que sus proveedores cumplan estandares de seguridad verificables
AWS Marketplace — Canal de distribucion clave para enterprise (facturacion consolidada, procurement simplificado)
Co-sell con AWS — Acceso al equipo de ventas de AWS para oportunidades conjuntas
Diferenciacion — Pocos competidores en LATAM tienen FTR aprobado
Compliance — Muchos controles del FTR se alinean con SOC 2 y regulaciones financieras

Categorias y Checklist de Requisitos

1. Seguridad

Requisito	Como lo Cumplimos	Servicio AWS
Autenticacion y autorizacion	Keycloak con OIDC, RBAC por tenant	Keycloak en ECS + Aurora
Encriptacion en transito	TLS 1.3 en todos los endpoints, mTLS entre servicios	ACM, ALB, Service Connect
Encriptacion en reposo	Aurora encryption, S3 SSE-KMS, EBS encryption	KMS, Aurora, S3
Gestion de secretos	AWS Secrets Manager con rotacion automatica	Secrets Manager, KMS
Aislamiento de datos (multi-tenancy)	RLS en PostgreSQL + tenant context en JWT	Aurora, Keycloak
Logging de seguridad	CloudTrail habilitado, logs de acceso centralizados	CloudTrail, CloudWatch
Vulnerability management	Dependabot, ECR image scanning, SAST en CI	ECR, CodeGuru, Dependabot
Network security	VPC con subnets privadas, Security Groups restrictivos	VPC, SG, NACLs
IAM least privilege	Task Roles por servicio, no credenciales hardcodeadas	IAM, ECS Task Roles
Incident response plan	Runbooks documentados, alertas automaticas	CloudWatch Alarms, SNS, PagerDuty

2. Confiabilidad (Reliability)

Requisito	Como lo Cumplimos	Servicio AWS
Alta disponibilidad	Multi-AZ para Aurora, ECS con min 2 tasks	Aurora Serverless v2, ECS Fargate
Backup y recovery	Aurora automated backups (35 dias), point-in-time recovery	Aurora, AWS Backup
Disaster recovery	Aurora Global Database (RPO < 1s), cross-region replication	Aurora Global, S3 CRR
Auto-scaling	ECS Service Auto Scaling, Aurora Serverless auto-scale	ECS, Aurora Serverless v2
Health checks	ALB health checks, ECS container health checks	ALB, ECS
Graceful degradation	Circuit breakers (Polly), fallback a cache	ElastiCache (Valkey), Polly
Dependency isolation	Bulkhead pattern, timeouts configurados	ECS Service Connect
Data durability	Aurora 6 copias en 3 AZs, S3 11 9s durability	Aurora, S3

3. Excelencia Operacional (Operational Excellence)

Requisito	Como lo Cumplimos	Servicio AWS
Infrastructure as Code	Terraform para toda la infraestructura	Terraform + AWS Provider
CI/CD pipeline	GitHub Actions con deploy automatizado	GitHub Actions, ECR, ECS
Monitoring y observabilidad	Metricas, logs y traces centralizados	CloudWatch, X-Ray, OpenTelemetry
Alerting	Alarmas por servicio con escalamiento	CloudWatch Alarms, SNS, PagerDuty
Runbooks	Procedimientos documentados para incidentes comunes	Confluence + SSM Documents
Change management	PRs con review obligatorio, feature flags	GitHub, LaunchDarkly
Cost optimization	Right-sizing, Savings Plans, tagging strategy	Cost Explorer, Budgets
Tagging strategy	Tags obligatorios: Environment, Service, Team, CostCenter	AWS Organizations Tag Policies

4. Rendimiento (Performance Efficiency)

Requisito	Como lo Cumplimos	Servicio AWS
Caching strategy	Valkey para queries frecuentes, CDN para assets	ElastiCache (Valkey), CloudFront
Database optimization	Read replicas (CQRS), connection pooling (PgBouncer)	Aurora Read Replicas, RDS Proxy
Async processing	RabbitMQ para operaciones no-criticas	Amazon MQ / RabbitMQ en ECS
CDN	CloudFront para frontend SPA y assets estaticos	CloudFront, S3
Right-sizing	Fargate con CPU/memory ajustados por servicio	ECS Fargate
Load testing	k6 para tests de carga antes de cada release major	k6, CloudWatch

Arquitectura de Referencia para FTR

Documentacion Requerida por AWS

AWS solicita documentacion especifica durante el proceso de FTR. Debemos mantener estos documentos actualizados:

Documentos Obligatorios

Documento	Descripcion	Ubicacion
Architecture Diagram	Diagrama de arquitectura con todos los servicios AWS	`docs/architecture/overview.md`
Data Flow Diagram	Flujo de datos incluyendo encriptacion	`docs/architecture/data-strategy.md`
Security Controls	Controles de seguridad implementados	`docs/architecture/security.md`
Shared Responsibility Model	Como dividimos responsabilidades con AWS	`docs/compliance/shared-responsibility.md`
Incident Response Plan	Procedimiento ante incidentes de seguridad	`docs/operations/incident-response.md`
Backup and Recovery Plan	Estrategia de backups y RTO/RPO	`docs/operations/backup-recovery.md`
Well-Architected Review	Self-assessment del Well-Architected Framework	`docs/compliance/well-architected.md`
Deployment Runbook	Proceso de deployment documentado	`docs/operations/deployment.md`

Evidencias Tecnicas

Evidencia	Como Generarla
Encriptacion en reposo habilitada	Screenshot de Aurora/S3 encryption settings
CloudTrail habilitado	Export de configuracion de CloudTrail
Multi-AZ configurado	Terraform output mostrando AZ distribution
IAM policies (least privilege)	Export de Task Role policies
Security Groups restrictivos	Export de SG rules
Automated backups	Configuracion de Aurora backup retention
Vulnerability scanning	Reporte de ECR image scan
Logging centralizado	Dashboard de CloudWatch con logs de todos los servicios

Timeline y Proceso de Certificacion

Fases del Proceso

Fase 1: Preparacion (4-6 semanas)

Implementar todos los controles de seguridad listados arriba
Configurar monitoring y alerting completo
Documentar arquitectura y procedimientos operacionales
Ejecutar Well-Architected Review interno
Resolver hallazgos criticos y altos

Fase 2: Self-Assessment (2 semanas)

Completar el cuestionario de FTR (proporcionado por AWS Partner team)
Recopilar evidencias tecnicas (screenshots, exports, configs)
Validar que cada control esta implementado y documentado
Identificar gaps y crear plan de remediacion

Fase 3: Remediacion (2-4 semanas)

Resolver los gaps identificados en el self-assessment
Implementar controles faltantes
Actualizar documentacion
Ejecutar tests de seguridad (penetration testing si aplica)

Fase 4: Review con AWS (2-3 semanas)

AWS Partner Solutions Architect revisa la solucion
Sesiones de Q&A sobre arquitectura y controles
Posibles hallazgos adicionales que requieren remediacion
Iteracion hasta que todos los requisitos se cumplan

Fase 5: Aprobacion

AWS emite la aprobacion de FTR
Se habilita el listing en AWS Marketplace
Se activan beneficios del programa de partners

Cumplimiento Continuo

El FTR no es un evento unico. AWS puede re-evaluar en cualquier momento y los controles deben mantenerse activos permanentemente.

Monitoreo Automatizado de Compliance

AWS Config Rules Activas

Regla	Que Valida
`encrypted-volumes`	Todos los EBS volumes estan encriptados
`rds-storage-encrypted`	Aurora tiene encriptacion habilitada
`s3-bucket-server-side-encryption-enabled`	Buckets S3 con SSE
`cloudtrail-enabled`	CloudTrail activo en todas las regiones
`iam-no-inline-policy-check`	No hay inline policies en IAM
`ecs-task-definition-nonroot-user`	Containers no corren como root
`vpc-sg-open-only-to-authorized-ports`	Security Groups restrictivos
`secretsmanager-rotation-enabled-check`	Secretos con rotacion activa

Revisiones Periodicas

Actividad	Frecuencia	Responsable
Security Hub review	Semanal	DevOps/SRE
Well-Architected Review	Trimestral	Arquitectura
Penetration testing	Anual	Seguridad externa
IAM access review	Mensual	DevOps
Dependency vulnerability scan	Continuo (CI)	Automatizado
Backup restoration test	Trimestral	DevOps/SRE
Incident response drill	Semestral	Todo el equipo
Cost optimization review	Mensual	DevOps + Finanzas

Alertas de Drift

Si algun control deja de cumplirse, se genera una alerta automatica:

hcl

# Terraform — AWS Config Rule con remediacion automatica
resource "aws_config_config_rule" "encrypted_volumes" {
  name = "imagy-encrypted-volumes"

  source {
    owner             = "AWS"
    source_identifier = "ENCRYPTED_VOLUMES"
  }

  tags = {
    Environment = "production"
    Compliance  = "ftr"
    Service     = "platform"
  }
}

resource "aws_config_remediation_configuration" "encrypt_volume" {
  config_rule_name = aws_config_config_rule.encrypted_volumes.name
  target_type      = "SSM_DOCUMENT"
  target_id        = "AWS-EnableEbsEncryptionByDefault"
  automatic        = true

  maximum_automatic_attempts = 3
  retry_attempt_seconds      = 60
}

Mapeo FTR a Controles Existentes

Para facilitar la auditoria, este mapeo conecta cada requisito del FTR con el steering o ADR donde se documenta la implementacion:

Requisito FTR	Documento de Referencia
Identity and Access Management	`steerings/identity-context.md`
Data Protection (encryption)	`steerings/secrets-management.md`
Network Security	`architecture/infrastructure.md`
Logging and Monitoring	`architecture/infrastructure.md`
Incident Response	`operations/incident-response.md`
Business Continuity	`operations/backup-recovery.md`
Change Management	`steerings/git-workflow.md`
Secure Development	`steerings/coding-standards.md`
Testing	`steerings/testing-standards.md`
Multi-tenancy Isolation	`architecture/multi-tenancy.md`
Database Security	`steerings/database-migrations.md`
API Security	`steerings/api-contracts.md`

Checklist Pre-Submission

Antes de solicitar la revision formal con AWS, validar que todos estos items estan completos:

[ ] Encriptacion en reposo habilitada en Aurora, S3, EBS, ElastiCache
[ ] Encriptacion en transito (TLS 1.3) en todos los endpoints
[ ] CloudTrail habilitado en todas las regiones
[ ] VPC con subnets privadas para servicios y datos
[ ] Security Groups con reglas minimas necesarias
[ ] IAM Task Roles con least privilege por servicio
[ ] Secrets Manager con rotacion automatica configurada
[ ] Multi-AZ habilitado para Aurora y ECS
[ ] Backups automaticos con retencion >= 35 dias
[ ] Monitoring con alarmas para metricas criticas
[ ] Logging centralizado en CloudWatch
[ ] Distributed tracing con X-Ray/OpenTelemetry
[ ] CI/CD pipeline con tests automatizados
[ ] Infrastructure as Code (Terraform) para todos los recursos
[ ] Vulnerability scanning en imagenes Docker (ECR)
[ ] Dependency scanning (Dependabot/Snyk)
[ ] Incident response plan documentado
[ ] Backup restoration testeado
[ ] Well-Architected Review completado
[ ] Documentacion de arquitectura actualizada
[ ] Data flow diagram con puntos de encriptacion
[ ] Tagging strategy implementada en todos los recursos

AWS FTR Compliance — Plataforma Imagy ​

Que es AWS Foundational Technical Review (FTR) ​

Por que Necesitamos FTR ​

Categorias y Checklist de Requisitos ​

1. Seguridad ​

2. Confiabilidad (Reliability) ​

3. Excelencia Operacional (Operational Excellence) ​

4. Rendimiento (Performance Efficiency) ​

Arquitectura de Referencia para FTR ​

Documentacion Requerida por AWS ​

Documentos Obligatorios ​

Evidencias Tecnicas ​

Timeline y Proceso de Certificacion ​

Fases del Proceso ​

Fase 1: Preparacion (4-6 semanas) ​

Fase 2: Self-Assessment (2 semanas) ​

Fase 3: Remediacion (2-4 semanas) ​

Fase 4: Review con AWS (2-3 semanas) ​

Fase 5: Aprobacion ​

Cumplimiento Continuo ​

Monitoreo Automatizado de Compliance ​

AWS Config Rules Activas ​

Revisiones Periodicas ​

Alertas de Drift ​

Mapeo FTR a Controles Existentes ​

Checklist Pre-Submission ​