De no tener infraestructura en la nube a un entorno de AWS alineado con SOC 2
Servicios de backend que se implementan de forma independiente, sin reinicios completos
Para aprovisionar un nuevo entorno o cuenta de sandbox
Ficus Platforms, Inc.
Nueva York, NY
Fintech / Tecnología de seguros (Insurtech)
AWS Control Tower, ECS Fargate, Aurora PostgreSQL Serverless v2, Application Load Balancer, CloudFront, WAF, API Gateway, Route 53, Secrets Manager, KMS, ECR, S3, IAM Identity Center, Security Hub, GuardDuty, AWS Config, CloudTrail, CloudWatch, X-Ray, GitHub Actions, Terraform
Ficus Platforms desarrolla una moderna plataforma digital de cuentas de beneficiarios para aseguradoras de vida, lo que les permite gestionar programas de activos retenidos para sus beneficiarios. La empresa requería una infraestructura en la nube lista para producción que pudiera soportar su arquitectura de dos servicios y, al mismo tiempo, cumplir con los requisitos de conformidad con SOC 2. Avahi entregó un entorno de AWS completo desde cero, que incluye una landing zone multiconta mediante AWS Control Tower, microservicios en contenedores sobre ECS Fargate, bases de datos Aurora PostgreSQL y pipelines de CI/CD totalmente automatizados. El proyecto transformó a Ficus Platforms: pasó de no contar con infraestructura en la nube a operar una arquitectura segura, escalable y de implementación independiente de dos servicios en entornos de desarrollo, staging y producción.
Ficus Platforms es una empresa fintech con sede en Nueva York que ofrece una plataforma de interacción digital para aseguradoras de vida que gestionan programas de activos retenidos. Su plataforma atiende a dos grupos de usuarios definidos: beneficiarios que acceden a sus cuentas mediante una aplicación móvil y un portal web, y administradores que gestionan la plataforma a través de una interfaz de administración dedicada. La plataforma maneja datos financieros y personales confidenciales, incluidos números de seguridad social e información de cuentas de beneficiarios, por lo que la seguridad y el cumplimiento normativo son requisitos fundamentales para su infraestructura.
Ficus Platforms enfrentaba una brecha crítica de infraestructura que impedía a su equipo de ingeniería lanzar su producto. Cada semana sin infraestructura de producción implicaba retrasos en el lanzamiento de funcionalidades y la imposibilidad de atender a los clientes. La empresa necesitaba avanzar con rapidez y, a la vez, cumplir con rigurosos requisitos de seguridad y cumplimiento normativo.
La arquitectura de su aplicación presentaba retos específicos. La plataforma constaba de dos servicios de backend en Rust/Axum (una API orientada a los beneficiarios y una API administrativa), además de un portal de administración en Next.js, todos compartiendo una base de datos común. Sin la infraestructura adecuada, estos servicios no podían implementarse de manera independiente, lo que generaba un riesgo operativo en el que una falla o el despliegue de cualquier componente obligaría a reiniciar el servicio por completo.
Más allá de las necesidades básicas de despliegue, Ficus Platforms requería controles alineados con SOC 2 desde el primer día. Su comité de revisión de arquitectura empresarial exigía límites de auditoría claros, registro centralizado (centralized logging), cifrado en reposo y en tránsito, y decisiones de arquitectura debidamente documentadas. Un modelo de cuenta única de AWS generaría riesgos asociados al radio de impacto y complicaría los límites de auditoría exigidos para el cumplimiento.
Ficus Platforms eligió AWS como su plataforma en la nube porque ofrecía los servicios específicos necesarios para cubrir sus requerimientos operativos y de cumplimiento normativo. AWS Control Tower proporcionó una landing zone multicuenta con barreras de seguridad preconfiguradas, lo que facilitó límites de auditoría definidos entre los entornos de desarrollo, staging y producción sin necesidad de desarrollar políticas personalizadas desde cero.
La combinación de ECS Fargate para la orquestación de contenedores sin servidor y Aurora PostgreSQL Serverless v2 para las cargas de trabajo de base de datos se alineó a la perfección con su necesidad de escalabilidad automática sin la sobrecarga de gestionar infraestructura. Los servicios de seguridad nativos de AWS (Security Hub, GuardDuty, AWS Config y CloudTrail) brindaron las capacidades de monitoreo de cumplimiento y detección de amenazas necesarias para la preparación hacia SOC 2, mientras que IAM Identity Center permitió el inicio de sesión único (SSO) basado en roles en todas las cuentas.
Ficus Platforms contrató a Avahi gracias a su capacidad de entregar un entorno de AWS completo y listo para producción en un plazo ajustado de cuatro semanas. El proyecto requería experiencia en múltiples áreas: arquitectura de landing zones de AWS, orquestación de contenedores, diseño de bases de datos, automatización de CI/CD y cumplimiento de seguridad.
El enfoque de Avahi de entregar el 100% de la infraestructura como código mediante Terraform, junto con su experiencia en la implementación de controles alineados con SOC 2, garantizó que Ficus Platforms recibiera no solo una infraestructura operativa, sino también la documentación, los registros de decisiones de arquitectura (ADR) y los manuales operativos necesarios para su comité de revisión de arquitectura empresarial. La familiaridad del equipo con stacks modernos de aplicaciones (Rust, TypeScript, microservicios en contenedores) les permitió diseñar una infraestructura que se ajustara a los requisitos reales de la aplicación en lugar de imponer limitaciones arquitectónicas.
Avahi realizó una implementación integral de infraestructura en AWS que estableció las bases en la nube de Ficus Platforms en tres entornos.
Landing zone multicuenta
El proyecto comenzó con el despliegue de AWS Control Tower para crear una estructura organizacional multicuenta. La arquitectura incluye una cuenta de Management para facturación y gobernanza, una OU de Seguridad que contiene las cuentas de Log Archive y Audit para el registro centralizado y los hallazgos de seguridad, y una OU de Workloads con cuentas independientes de Desarrollo, Staging y Producción. Esta estructura aísla el radio de impacto, asegurando que un incidente de seguridad o un error de configuración en un entorno no se propague a los demás.
IAM Identity Center ofrece acceso de inicio de sesión único con conjuntos de permisos definidos por rol y cuenta. Los desarrolladores reciben PowerUserAccess en Desarrollo y ReadOnlyAccess en Staging y Producción, mientras que los cambios de infraestructura requieren permisos elevados. Las barreras de seguridad de Control Tower garantizan la protección básica: deniegan el acceso al usuario root, impiden que las cuentas abandonen la organización y bloquean la desactivación de CloudTrail.
Arquitectura de microservicios en contenedores
El backend se dividió en dos servicios de ECS Fargate que se pueden implementar de manera independiente. user-svc gestiona las solicitudes a la API de los beneficiarios desde la aplicación móvil y el portal web, mientras que admin-svc atiende a la interfaz administrativa. Cada servicio cuenta con su propia imagen de Docker, repositorio de ECR, definición de tareas de ECS, grupo de seguridad y política de escalado automático.
La estrategia de contenedores emplea compilaciones de Docker en varias etapas con cargo-chef para el almacenamiento en caché de dependencias de Rust, produciendo imágenes distroless mínimas (de aproximadamente 200 MB) que se ejecutan como usuarios no root. Un único Dockerfile compila ambos servicios mediante un argumento de compilación, lo que garantiza la coherencia al tiempo que permite despliegues independientes. Los servicios de ECS están configurados con escalado automático por seguimiento de objetivos (CPU al 70%, Memoria al 75%) con un mínimo de 1 y un máximo de 4 tareas, además de disyuntores de implementación que revierten automáticamente las implementaciones fallidas.
Base de datos y capa de datos
Aurora PostgreSQL Serverless v2 proporciona el almacén de datos relacional, configurado con escalado automático de 0.5 a 4 ACU. La base de datos se ejecuta en subredes privadas en dos Zonas de Disponibilidad, con cifrado en reposo mediante KMS y conexiones TLS en tránsito. Desarrollo utiliza una sola instancia para optimizar costos, mientras que producción está configurada para un despliegue Multi-AZ con réplicas de lectura para alta disponibilidad.
Las políticas de seguridad a nivel de fila (Row-Level Security) aplican el aislamiento de datos multiinquilino en la capa de la base de datos. El organization_id proveniente de los tokens JWT de Clerk se establece mediante SET LOCAL dentro de cada transacción de base de datos, y las políticas de RLS filtran las filas automáticamente. Esto proporciona defensa en profundidad: incluso si el código de la aplicación tiene un error, el motor de la base de datos evita la fuga de datos entre inquilinos.
Redes y enrutamiento
Cada entorno cuenta con una VPC dedicada con subredes públicas y privadas en dos Zonas de Disponibilidad. Los Application Load Balancers en subredes públicas terminan la conexión TLS (utilizando certificados gestionados por ACM con TLS 1.3) y enrutan el tráfico según la ruta: /admin/* se redirige al grupo de destino de admin-svc, mientras que el resto del tráfico se envía a user-svc. Los NAT Gateways en subredes públicas permiten la salida a internet de los recursos privados.
La arquitectura incluye distribuciones de CloudFront con WAF en el borde para aplicar restricciones geográficas y listas de IP permitidas en el servicio de administración. API Gateway proporciona regulación de tráfico (throttling), planes de uso y validación de solicitudes adicionales frente al ALB.
Automatización de CI/CD
Dos pipelines de GitHub Actions automatizan los despliegues de infraestructura y aplicaciones. El pipeline de Terraform gestiona los cambios de infraestructura mediante validación de formato, análisis de código (linting) y visualización del plan de ejecución, utilizando S3 para el almacenamiento del estado y DynamoDB para el bloqueo de estado. Controles de aprobación manual regulan la promoción de Desarrollo a Staging (una aprobación) y de Staging a Producción (dos aprobaciones).
El pipeline de la aplicación compila las imágenes de Docker para ambos servicios, ejecuta análisis de seguridad a través de Trivy, las publica en ECR y las despliega en ECS con reversión automática en caso de fallas en las comprobaciones de estado. La federación mediante OIDC de GitHub proporciona acceso a AWS sin necesidad de credenciales de larga duración. Una tarea de ECS dedicada a la migración ejecuta las migraciones de bases de datos con SQLx antes de las actualizaciones del servicio, asegurando que los cambios de esquema se completen con éxito antes de desplegar el nuevo código de la aplicación.
Seguridad y cumplimiento
Los controles alineados con SOC 2 se habilitaron desde el primer día. Security Hub consolida los hallazgos de todas las cuentas con paquetes de conformidad alineados con los criterios de SOC 2. GuardDuty brinda detección de amenazas, AWS Config supervisa el cumplimiento de los recursos y CloudTrail registra la actividad de las API en la cuenta centralizada de Log Archive. Todos los secretos (credenciales de bases de datos, claves JWT de Clerk, el pepper de SSN para el hash de datos de identificación personal [PII]) se almacenan en AWS Secrets Manager con cifrado de KMS y se inyectan en las tareas de ECS al momento del lanzamiento.
Observabilidad
CloudWatch proporciona registro centralizado con Container Insights para métricas de ECS. Paneles por servicio muestran la latencia, las tasas de error y el estado de operatividad. La integración con AWS X-Ray permite el rastreo distribuido entre servicios. Las alarmas están configuradas para respaldar la reversión automatizada y la visibilidad operativa.
Landing zone multicuenta con AWS Control Tower con entornos de Desarrollo, Staging y Producción
Dos servicios en ECS Fargate implementables de forma independiente (user-svc y admin-svc) con escalado automático
Aurora PostgreSQL Serverless v2 con seguridad a nivel de fila para aislamiento multiinquilino
Arquitectura de VPC con subredes públicas y privadas en dos Zonas de Disponibilidad por entorno
Application Load Balancers con enrutamiento basado en rutas y terminación TLS 1.3
Distribuciones de CloudFront con WAF para seguridad perimetral y restricciones geográficas
API Gateway con control de tráfico (throttling), planes de uso y validación de solicitudes
Pipelines de CI/CD en GitHub Actions para infraestructura con Terraform y despliegue de aplicaciones
Repositorios de ECR con escaneo al enviar (scan-on-push) y políticas de ciclo de vida
Integración con Secrets Manager para la gestión de credenciales
Controles de seguridad alineados con SOC 2: Security Hub, GuardDuty, AWS Config y CloudTrail
IAM Identity Center con conjuntos de permisos basados en roles
Paneles de CloudWatch, alarmas y rastreo distribuido con X-Ray
Registros de Decisiones de Arquitectura (ADR) que documentan las elecciones clave de diseño
Manuales de procedimientos operativos (runbooks) y documentación para la transferencia de conocimientos
El proyecto transformó a Ficus Platforms: pasó de no tener infraestructura en la nube a operar un entorno de AWS completamente funcional y alineado con SOC 2 en tan solo cuatro semanas. Ahora, el equipo de ingeniería puede implementar funcionalidades de forma independiente para cada servicio, sin conflictos en el despliegue ni necesidad de reinicios totales.
La estructura multicuenta proporciona límites de auditoría definidos que satisfacen los requisitos CC6.1 (acceso lógico) y CC6.6 (segmentación de red) de SOC 2, simplificando la recolección de evidencias durante su proceso de cumplimiento. La aplicación de seguridad a nivel de fila en la base de datos establece una barrera de aislamiento auditable para los datos multiinquilino, respondiendo a un criterio clave de arquitectura empresarial.
El enfoque de infraestructura como código permite a Ficus Platforms ampliar y modificar su entorno de forma autónoma. Todos los módulos de Terraform son reutilizables en los distintos entornos, y los pipelines de CI/CD admiten la promoción de una misma imagen de contenedor desde Desarrollo hacia Staging y Producción sin necesidad de recompilarla. Es posible aprovisionar nuevos entornos o cuentas de sandbox a través de Account Factory en menos de 30 minutos.
Ficus Platforms, Inc.
Nueva York, NY
Fintech / Tecnología de seguros (Insurtech)
AWS Control Tower, ECS Fargate, Aurora PostgreSQL Serverless v2, Application Load Balancer, CloudFront, WAF, API Gateway, Route 53, Secrets Manager, KMS, ECR, S3, IAM Identity Center, Security Hub, GuardDuty, AWS Config, CloudTrail, CloudWatch, X-Ray, GitHub Actions, Terraform
Ficus Platforms desarrolla una moderna plataforma digital de cuentas de beneficiarios para aseguradoras de vida, lo que les permite gestionar programas de activos retenidos para sus beneficiarios. La empresa requería una infraestructura en la nube lista para producción que pudiera soportar su arquitectura de dos servicios y, al mismo tiempo, cumplir con los requisitos de conformidad con SOC 2. Avahi entregó un entorno de AWS completo desde cero, que incluye una landing zone multiconta mediante AWS Control Tower, microservicios en contenedores sobre ECS Fargate, bases de datos Aurora PostgreSQL y pipelines de CI/CD totalmente automatizados. El proyecto transformó a Ficus Platforms: pasó de no contar con infraestructura en la nube a operar una arquitectura segura, escalable y de implementación independiente de dos servicios en entornos de desarrollo, staging y producción.
Ficus Platforms es una empresa fintech con sede en Nueva York que ofrece una plataforma de interacción digital para aseguradoras de vida que gestionan programas de activos retenidos. Su plataforma atiende a dos grupos de usuarios definidos: beneficiarios que acceden a sus cuentas mediante una aplicación móvil y un portal web, y administradores que gestionan la plataforma a través de una interfaz de administración dedicada. La plataforma maneja datos financieros y personales confidenciales, incluidos números de seguridad social e información de cuentas de beneficiarios, por lo que la seguridad y el cumplimiento normativo son requisitos fundamentales para su infraestructura.
Ficus Platforms enfrentaba una brecha crítica de infraestructura que impedía a su equipo de ingeniería lanzar su producto. Cada semana sin infraestructura de producción implicaba retrasos en el lanzamiento de funcionalidades y la imposibilidad de atender a los clientes. La empresa necesitaba avanzar con rapidez y, a la vez, cumplir con rigurosos requisitos de seguridad y cumplimiento normativo.
La arquitectura de su aplicación presentaba retos específicos. La plataforma constaba de dos servicios de backend en Rust/Axum (una API orientada a los beneficiarios y una API administrativa), además de un portal de administración en Next.js, todos compartiendo una base de datos común. Sin la infraestructura adecuada, estos servicios no podían implementarse de manera independiente, lo que generaba un riesgo operativo en el que una falla o el despliegue de cualquier componente obligaría a reiniciar el servicio por completo.
Más allá de las necesidades básicas de despliegue, Ficus Platforms requería controles alineados con SOC 2 desde el primer día. Su comité de revisión de arquitectura empresarial exigía límites de auditoría claros, registro centralizado (centralized logging), cifrado en reposo y en tránsito, y decisiones de arquitectura debidamente documentadas. Un modelo de cuenta única de AWS generaría riesgos asociados al radio de impacto y complicaría los límites de auditoría exigidos para el cumplimiento.
Ficus Platforms eligió AWS como su plataforma en la nube porque ofrecía los servicios específicos necesarios para cubrir sus requerimientos operativos y de cumplimiento normativo. AWS Control Tower proporcionó una landing zone multicuenta con barreras de seguridad preconfiguradas, lo que facilitó límites de auditoría definidos entre los entornos de desarrollo, staging y producción sin necesidad de desarrollar políticas personalizadas desde cero.
La combinación de ECS Fargate para la orquestación de contenedores sin servidor y Aurora PostgreSQL Serverless v2 para las cargas de trabajo de base de datos se alineó a la perfección con su necesidad de escalabilidad automática sin la sobrecarga de gestionar infraestructura. Los servicios de seguridad nativos de AWS (Security Hub, GuardDuty, AWS Config y CloudTrail) brindaron las capacidades de monitoreo de cumplimiento y detección de amenazas necesarias para la preparación hacia SOC 2, mientras que IAM Identity Center permitió el inicio de sesión único (SSO) basado en roles en todas las cuentas.
Ficus Platforms contrató a Avahi gracias a su capacidad de entregar un entorno de AWS completo y listo para producción en un plazo ajustado de cuatro semanas. El proyecto requería experiencia en múltiples áreas: arquitectura de landing zones de AWS, orquestación de contenedores, diseño de bases de datos, automatización de CI/CD y cumplimiento de seguridad.
El enfoque de Avahi de entregar el 100% de la infraestructura como código mediante Terraform, junto con su experiencia en la implementación de controles alineados con SOC 2, garantizó que Ficus Platforms recibiera no solo una infraestructura operativa, sino también la documentación, los registros de decisiones de arquitectura (ADR) y los manuales operativos necesarios para su comité de revisión de arquitectura empresarial. La familiaridad del equipo con stacks modernos de aplicaciones (Rust, TypeScript, microservicios en contenedores) les permitió diseñar una infraestructura que se ajustara a los requisitos reales de la aplicación en lugar de imponer limitaciones arquitectónicas.
Avahi realizó una implementación integral de infraestructura en AWS que estableció las bases en la nube de Ficus Platforms en tres entornos.
Landing zone multicuenta
El proyecto comenzó con el despliegue de AWS Control Tower para crear una estructura organizacional multicuenta. La arquitectura incluye una cuenta de Management para facturación y gobernanza, una OU de Seguridad que contiene las cuentas de Log Archive y Audit para el registro centralizado y los hallazgos de seguridad, y una OU de Workloads con cuentas independientes de Desarrollo, Staging y Producción. Esta estructura aísla el radio de impacto, asegurando que un incidente de seguridad o un error de configuración en un entorno no se propague a los demás.
IAM Identity Center ofrece acceso de inicio de sesión único con conjuntos de permisos definidos por rol y cuenta. Los desarrolladores reciben PowerUserAccess en Desarrollo y ReadOnlyAccess en Staging y Producción, mientras que los cambios de infraestructura requieren permisos elevados. Las barreras de seguridad de Control Tower garantizan la protección básica: deniegan el acceso al usuario root, impiden que las cuentas abandonen la organización y bloquean la desactivación de CloudTrail.
Arquitectura de microservicios en contenedores
El backend se dividió en dos servicios de ECS Fargate que se pueden implementar de manera independiente. user-svc gestiona las solicitudes a la API de los beneficiarios desde la aplicación móvil y el portal web, mientras que admin-svc atiende a la interfaz administrativa. Cada servicio cuenta con su propia imagen de Docker, repositorio de ECR, definición de tareas de ECS, grupo de seguridad y política de escalado automático.
La estrategia de contenedores emplea compilaciones de Docker en varias etapas con cargo-chef para el almacenamiento en caché de dependencias de Rust, produciendo imágenes distroless mínimas (de aproximadamente 200 MB) que se ejecutan como usuarios no root. Un único Dockerfile compila ambos servicios mediante un argumento de compilación, lo que garantiza la coherencia al tiempo que permite despliegues independientes. Los servicios de ECS están configurados con escalado automático por seguimiento de objetivos (CPU al 70%, Memoria al 75%) con un mínimo de 1 y un máximo de 4 tareas, además de disyuntores de implementación que revierten automáticamente las implementaciones fallidas.
Base de datos y capa de datos
Aurora PostgreSQL Serverless v2 proporciona el almacén de datos relacional, configurado con escalado automático de 0.5 a 4 ACU. La base de datos se ejecuta en subredes privadas en dos Zonas de Disponibilidad, con cifrado en reposo mediante KMS y conexiones TLS en tránsito. Desarrollo utiliza una sola instancia para optimizar costos, mientras que producción está configurada para un despliegue Multi-AZ con réplicas de lectura para alta disponibilidad.
Las políticas de seguridad a nivel de fila (Row-Level Security) aplican el aislamiento de datos multiinquilino en la capa de la base de datos. El organization_id proveniente de los tokens JWT de Clerk se establece mediante SET LOCAL dentro de cada transacción de base de datos, y las políticas de RLS filtran las filas automáticamente. Esto proporciona defensa en profundidad: incluso si el código de la aplicación tiene un error, el motor de la base de datos evita la fuga de datos entre inquilinos.
Redes y enrutamiento
Cada entorno cuenta con una VPC dedicada con subredes públicas y privadas en dos Zonas de Disponibilidad. Los Application Load Balancers en subredes públicas terminan la conexión TLS (utilizando certificados gestionados por ACM con TLS 1.3) y enrutan el tráfico según la ruta: /admin/* se redirige al grupo de destino de admin-svc, mientras que el resto del tráfico se envía a user-svc. Los NAT Gateways en subredes públicas permiten la salida a internet de los recursos privados.
La arquitectura incluye distribuciones de CloudFront con WAF en el borde para aplicar restricciones geográficas y listas de IP permitidas en el servicio de administración. API Gateway proporciona regulación de tráfico (throttling), planes de uso y validación de solicitudes adicionales frente al ALB.
Automatización de CI/CD
Dos pipelines de GitHub Actions automatizan los despliegues de infraestructura y aplicaciones. El pipeline de Terraform gestiona los cambios de infraestructura mediante validación de formato, análisis de código (linting) y visualización del plan de ejecución, utilizando S3 para el almacenamiento del estado y DynamoDB para el bloqueo de estado. Controles de aprobación manual regulan la promoción de Desarrollo a Staging (una aprobación) y de Staging a Producción (dos aprobaciones).
El pipeline de la aplicación compila las imágenes de Docker para ambos servicios, ejecuta análisis de seguridad a través de Trivy, las publica en ECR y las despliega en ECS con reversión automática en caso de fallas en las comprobaciones de estado. La federación mediante OIDC de GitHub proporciona acceso a AWS sin necesidad de credenciales de larga duración. Una tarea de ECS dedicada a la migración ejecuta las migraciones de bases de datos con SQLx antes de las actualizaciones del servicio, asegurando que los cambios de esquema se completen con éxito antes de desplegar el nuevo código de la aplicación.
Seguridad y cumplimiento
Los controles alineados con SOC 2 se habilitaron desde el primer día. Security Hub consolida los hallazgos de todas las cuentas con paquetes de conformidad alineados con los criterios de SOC 2. GuardDuty brinda detección de amenazas, AWS Config supervisa el cumplimiento de los recursos y CloudTrail registra la actividad de las API en la cuenta centralizada de Log Archive. Todos los secretos (credenciales de bases de datos, claves JWT de Clerk, el pepper de SSN para el hash de datos de identificación personal [PII]) se almacenan en AWS Secrets Manager con cifrado de KMS y se inyectan en las tareas de ECS al momento del lanzamiento.
Observabilidad
CloudWatch proporciona registro centralizado con Container Insights para métricas de ECS. Paneles por servicio muestran la latencia, las tasas de error y el estado de operatividad. La integración con AWS X-Ray permite el rastreo distribuido entre servicios. Las alarmas están configuradas para respaldar la reversión automatizada y la visibilidad operativa.
Landing zone multicuenta con AWS Control Tower con entornos de Desarrollo, Staging y Producción
Dos servicios en ECS Fargate implementables de forma independiente (user-svc y admin-svc) con escalado automático
Aurora PostgreSQL Serverless v2 con seguridad a nivel de fila para aislamiento multiinquilino
Arquitectura de VPC con subredes públicas y privadas en dos Zonas de Disponibilidad por entorno
Application Load Balancers con enrutamiento basado en rutas y terminación TLS 1.3
Distribuciones de CloudFront con WAF para seguridad perimetral y restricciones geográficas
API Gateway con control de tráfico (throttling), planes de uso y validación de solicitudes
Pipelines de CI/CD en GitHub Actions para infraestructura con Terraform y despliegue de aplicaciones
Repositorios de ECR con escaneo al enviar (scan-on-push) y políticas de ciclo de vida
Integración con Secrets Manager para la gestión de credenciales
Controles de seguridad alineados con SOC 2: Security Hub, GuardDuty, AWS Config y CloudTrail
IAM Identity Center con conjuntos de permisos basados en roles
Paneles de CloudWatch, alarmas y rastreo distribuido con X-Ray
Registros de Decisiones de Arquitectura (ADR) que documentan las elecciones clave de diseño
Manuales de procedimientos operativos (runbooks) y documentación para la transferencia de conocimientos
El proyecto transformó a Ficus Platforms: pasó de no tener infraestructura en la nube a operar un entorno de AWS completamente funcional y alineado con SOC 2 en tan solo cuatro semanas. Ahora, el equipo de ingeniería puede implementar funcionalidades de forma independiente para cada servicio, sin conflictos en el despliegue ni necesidad de reinicios totales.
La estructura multicuenta proporciona límites de auditoría definidos que satisfacen los requisitos CC6.1 (acceso lógico) y CC6.6 (segmentación de red) de SOC 2, simplificando la recolección de evidencias durante su proceso de cumplimiento. La aplicación de seguridad a nivel de fila en la base de datos establece una barrera de aislamiento auditable para los datos multiinquilino, respondiendo a un criterio clave de arquitectura empresarial.
El enfoque de infraestructura como código permite a Ficus Platforms ampliar y modificar su entorno de forma autónoma. Todos los módulos de Terraform son reutilizables en los distintos entornos, y los pipelines de CI/CD admiten la promoción de una misma imagen de contenedor desde Desarrollo hacia Staging y Producción sin necesidad de recompilarla. Es posible aprovisionar nuevos entornos o cuentas de sandbox a través de Account Factory en menos de 30 minutos.
Exploremos juntos sus oportunidades de IA de alto impacto en una sesión gratuita
