Implementaciones de SaaS de varios inquilinos

Las empresas de SaaS ofrecen soluciones para un gran número de inquilinos. Las implementaciones de varios inquilinos de los servicios de periferia de AWS (por ejemplo, CloudFront, AWS WAF, etc.) requieren que se tomen las decisiones de diseño con cautela para cumplir con los requisitos empresariales, como la flexibilidad, el costo, la escalabilidad y los gastos operativos.

Tenga en cuenta las siguientes decisiones de arquitectura al diseñar una solución de varios inquilinos con CloudFront:

• ¿Utiliza el mismo nombre de host para todos los inquilinos (p. ej., saas.com/tenant1, saas.com/tenant2) o nombres de host distintos? Si utiliza el mismo nombre de host, tiene la opción de llevar a cabo la implementación con una única distribución de CloudFront.
• Si utiliza nombres de host distintos, ¿utiliza el mismo nombre de dominio (p. ej., tenant1.saas.com, tenant2.saas.com) o nombres distintos (p. ej., tenant1.com, tenant2.com)? Una distribución de CloudFront se puede asociar a un único certificado TLS, que puede alojar varios nombres de host (certificados SAN). Cuando usa el mismo nombre de dominio, tiene la opción de implementar una distribución de CloudFront por inquilino o implementar una única distribución con un certificado comodín CNAME y TLS (*.saas.com) para todos los inquilinos. Si los dominios son diferentes, tiene la opción de implementar una distribución de CloudFront por inquilino o implementar varias distribuciones, cada una con un certificado SAN que pueda alojar hasta 100 dominios diferentes. Sin embargo, cuantos más dominios adjunte al mismo certificado TLS, más fricción agregará al proceso de emisión del certificado TLS.
• ¿Quién controla el nombre del dominio? Si los inquilinos controlan su dominio, se necesitarán pasos adicionales para agregar su nombre de host como CNAME a una distribución de CloudFront. Por motivos de seguridad, CloudFront requiere que adjunte un certificado TLS válido que cubra el nombre de host para demostrar la propiedad del dominio. Los inquilinos deben compartir su propio certificado TLS, que cargaría en ACM, o permitirle emitir un certificado TLS en su nombre mediante ACM. Con el segundo enfoque, ACM requiere que creen un token de CNAME en su DNS para demostrar la propiedad del dominio.
• ¿Los inquilinos comparten el mismo contenido o contenido diferente? Si comparten contenido común, considere la posibilidad de alojar el contenido compartido en un único dominio que puedan usar diferentes inquilinos. Esto se traduce en una mejor tasa de aciertos de caché para el contenido compartido.
• Si usa una distribución de CloudFront para varios inquilinos, ¿aloja a los inquilinos en el mismo origen o en orígenes diferentes? Si utiliza el mismo origen (por ejemplo, un solo bucket de S3 o un solo ALB), puede diferenciar a los inquilinos por la ruta de URL o el encabezado de host. Agregue el encabezado de host a la clave de caché si elige este método para diferenciar a los inquilinos. Si utiliza orígenes diferentes (por ejemplo, un bucket de S3 por inquilino o la partición de inquilinos en clústeres de ALB), necesita una función de Lambda@Edge en el evento de la solicitud de origen para dirigir el tráfico al origen correcto. Tenga en cuenta que si usa una ruta para diferenciar a los inquilinos (por ejemplo, saas.com/tenant1, saas.com/tenant2), puede dirigir de forma nativa a diferentes inquilinos a sus orígenes mediante los comportamientos de caché de CloudFront, pero tiene cuotas en cuanto al número de comportamientos por distribución de CloudFront.
• ¿Su diseño respeta las cuotas de AWS por servicio de AWS y por cuenta de AWS?
  
  

Tenga en cuenta las siguientes ventajas y desventajas en cuanto a su diseño. Tenga en cuenta que puede implementar ventajas y desventajas diferenciadas para ofertas de varios niveles. Por ejemplo, en el nivel básico en el que controla el nombre del dominio, todos los inquilinos comparten la misma distribución de CloudFront. Los arrendatarios prémium dispondrían cada uno de una distribución de CloudFront dedicada con un dominio personalizado y protecciones de seguridad mediante AWS WAF.

En este escenario, crea un subdominio (tenant1.saas.com) para cada inquilino. Route 53 se configura con un registro de alias comodín (*.saas.com) para una distribución de CloudFront y también se configura con un CNAME comodín (*.saas.com), con el encabezado de host incluido en la clave de la caché. El origen de un ALB que atiende solicitudes dinámicas distingue de forma nativa a los inquilinos mediante el encabezado de host. Tenga en cuenta que, en este escenario, se aplicará una única invalidación de contenido a todos los inquilinos, ya que las invalidaciones de CloudFront son independientes de los encabezados que forman parte de la clave de la caché, como el encabezado de host. Un bucket de S3 que ofrece contenido estático necesitaría una función de CloudFront configurada en el evento de la solicitud del espectador para leer el encabezado de host y volver a escribir la URL en el directorio de inquilinos de S3 (por ejemplo, tenant1.saas.com/index.html -> s3://bucket:arn/tenant1/index.html). Si ofrece el mismo contenido a todos los inquilinos desde S3 (por ejemplo, la misma aplicación de una sola página), pero diferencia a los inquilinos con las API, considere la posibilidad de usar esta solución sencilla.

Si aloja inquilinos en orígenes diferentes, necesitará una función de Lambda@Edge configurada en el evento de la solicitud de origen para dirigir las solicitudes de un inquilino al origen que aloja el inquilino. Para obtener más información sobre esta implementación, lea los siguientes casos prácticos:

• OutSystems usa Lambda@Edge para dirigir a los inquilinos en los clústeres de NLB a fin de obtener información sobre cómo OutSystems implementó este enrutamiento en sus clústeres de NLB.
• Arc XP usa Lambda@Edge para dirigir a los inquilinos en los buckets de S3

En este escenario, dedique una distribución de CloudFront a cada inquilino y automatice el proceso (por ejemplo, la creación de la distribución y la emisión del certificado TLS mediante Amazon Certificate Manager). Asegúrese de aumentar las cuotas pertinentes (p. ej., el número de distribuciones por cuenta o el número de certificados TLS) de antemano. En algunos casos, debe particionar sus distribuciones de CloudFront en varias cuentas de AWS.

Si CloudFront no puede satisfacer la escala de sus requisitos, considere la posibilidad de crear una flota de proxies inversos (por ejemplo, basados en NLB y EC2) para terminar las conexiones TCP o TLS que esté liderada por Global Accelerator para mejorar la seguridad y el rendimiento. Tenga en cuenta que, en este escenario, debe implementar el almacenamiento en caché en el proxy inverso si es necesario.

• SaaS en AWS