Visão geral

As empresas de SaaS operam soluções para um grande número de locatários. As implantações multilocatárias dos serviços de borda da AWS (por exemplo, CloudFront, AWS WAF etc.) exigem decisões de design cuidadosas para atender aos requisitos de negócios, como flexibilidade, custo, escalabilidade e sobrecarga operacional.

Decisões arquitetônicas

Considere as seguintes decisões arquitetônicas ao projetar uma solução de multilocatário usando o CloudFront:

  • Você usa o mesmo nome de host para todos os locatários (por exemplo, saas.com/tenant1, saas.com/tenant2) ou nomes de host separados? Se você usa o mesmo nome de host, tem a opção de implantar usando uma única distribuição do CloudFront.
  • Se você usa nomes de host separados, está usando o mesmo nome de domínio (por exemplo, tenant1.saas.com, tenant2.saas.com) ou nomes separados (por exemplo, tenant1.com, tenant2.com)? Uma distribuição do CloudFront pode ser associada a um único certificado TLS, que pode hospedar vários nomes de host (certificados SAN). Ao usar o mesmo nome de domínio, você tem a opção de implantar uma distribuição do CloudFront por locatário ou implantar uma única distribuição com certificado curinga CNAME e TLS (*.saas.com) para todos os locatários. Se os domínios forem diferentes, você tem a opção de implantar uma distribuição do CloudFront por locatário ou implantar várias distribuições, cada uma com um certificado SAN que pode hospedar até 100 domínios diferentes. No entanto, quanto mais domínios você anexa ao mesmo certificado TLS, mais atrito adiciona ao processo de emissão do certificado TLS.
  • Quem controla o nome do domínio? Se os locatários controlarem seu domínio, etapas adicionais serão necessárias para adicionar seu nome de host como CNAME a uma distribuição do CloudFront. Por motivos de segurança, o CloudFront exige que você prove sua propriedade do domínio anexando um certificado TLS válido que abrange o nome do host. Os locatários precisam compartilhar seus próprios certificados TLS, que você carregaria no ACM, ou permitir que você emita um certificado TLS em nome deles usando o ACM. Com a segunda abordagem, o ACM exige que eles criem um token CNAME no DNS para provar que são proprietários do domínio.
  • Os locatários compartilham o mesmo conteúdo ou conteúdo diferente? Se eles compartilharem conteúdo comum, considere hospedar o conteúdo compartilhado em um único domínio que possa ser usado por diferentes locatários. Isso resulta em uma melhor taxa de acerto de cache para conteúdo compartilhado.
  • Se você usa uma distribuição do CloudFront para vários locatários, os locatários são hospedados na mesma origem ou em origens diferentes? Se você estiver usando a mesma origem (por exemplo, um único bucket do S3 ou um único ALB), poderá diferenciar os locatários pelo caminho do URL ou pelo cabeçalho Host. Adicione o cabeçalho Host à chave de cache se você escolher esse método de diferenciação de locatários. Se estiver usando origens diferentes (por exemplo, um bucket do S3 por locatário ou a fragmentação de locatários em clusters de ALB), precisará de um evento em solicitação de origem do Lambda@Edge para rotear o tráfego até origem correta. Observe que, se você estiver usando o path para diferenciar locatários (por exemplo, saas.com/tenant1, saas.com/tenant2), poderá rotear de forma nativa diferentes locatários para suas origens usando comportamentos de cache do CloudFront, mas você tem cotas sobre o número de comportamentos por distribuição do CloudFront.
  • Seu design respeita as cotas da AWS por serviço e por conta da AWS?

Considere as vantagens e desvantagens abaixo no seu design. Observe que você pode implementar compensações diferenciadas para ofertas de vários níveis. Por exemplo, no seu nível básico em que você controla o nome de domínio, todos os locatários compartilham a mesma distribuição do CloudFront. Cada um dos seus locatários Premium teria uma distribuição dedicada do CloudFront com um domínio personalizado e proteções de segurança usando o AWS WAF.

  Cada locatário é hospedado em uma distribuição dedicada do CloudFront Vários locatários hospedados na mesma distribuição do CloudFront
Observabilidade Disponível nativamente por locatário Disponível no nível de distribuição, é necessário um esforço extra para extrair métricas por locatário usando logs
Raio de influência Uma mudança afeta apenas um locatário Uma única mudança afeta todos os locatários
Sobrecarga operacional Requer automação em grande escala, com implementações em lote para evitar a controle de utilização no nível da API do CloudFront Baixa
Personalização Cada locatário pode ter sua própria configuração diferente Mesma configuração para todos os locatários. Quando você habilita o WAF, ele é cobrado para todas as solicitações
Performance Cada distribuição do CloudFront precisa ser aquecida pelo tráfego separadamente (por exemplo, conexões com a origem) Todos os locatários se beneficiam com uma distribuição aquecida do CloudFront

Uma distribuição do CloudFront pode ser anexada a uma única WebACL do AWS WAF. A mesma WebACL pode ser usada em várias distribuições do CloudFront. As vantagens e desvantagens mencionadas anteriormente também se aplicam à implantação do WAF, além das seguintes:

  Usar uma WebACL por locatário Usar a mesma WebACL para vários locatários
Preço O custo da WebACL/regras aumenta linearmente com o número de locatários O custo da WebACL/Rules é independente do número de locatários
Falsos positivos Uma atualização de regra só pode causar falsos positivos com um único locatário Uma atualização de regra pode causar falsos positivos em vários locatários individuais

Casos de uso comuns

Subdomínio por locatário

Nesse cenário, você cria um subdomínio (tenant1.saas.com) para cada locatário. O Route 53 é configurado com o registro Alias curinga (*.saas.com) para uma distribuição do CloudFront, também configurada com o caractere curinga CNAME (*.saas.com), com cabeçalho Host incluído na chave de cache. Uma origem de ALB que atende a solicitações dinâmicas distingue nativamente os locatários usando o cabeçalho Host. Observe que, nesse cenário, uma única invalidação de conteúdo será aplicável a todos os locatários, porque as invalidações do CloudFront são independentes de cabeçalhos que fazem parte da chave de cache, como o cabeçalho Host. Um bucket do S3 que serve conteúdo estático precisaria de uma função do CloudFront configurada no evento de solicitação do visualizador para ler o cabeçalho Host e reescrever a URL no diretório do locatário no S3 (por exemplo, tenant1.saas.com/index.html -> s3://bucket:arn/tenant1/index.html). Se você estiver veiculando o mesmo conteúdo para todos os locatários do S3, por exemplo, a mesma aplicação de página única, mas diferenciando os locatários com APIs, considere esta solução simples.

Se você estiver hospedando locatários de origens diferentes, precisará de uma função do Lambda@Edge configurada no evento em solicitação de origem para rotear as solicitações de um locatário para a origem que hospeda o locatário. Para saber mais sobre essa implementação, leia os seguintes estudos de caso:

Locatários com domínios próprios

Nesse cenário, dedique uma distribuição do CloudFront para cada locatário e automatize o processo (por exemplo, criação de distribuição e emissão de certificados TLS usando o Amazon Certificate Manager). Certifique-se de aumentar as cotas relevantes (por exemplo, número de distribuições por conta, número de certificados TLS) com antecedência. Em certos casos, você precisa fragmentar suas distribuições do CloudFront em várias contas da AWS.

Encerre o TLS nos seus servidores

Se a escala de seus requisitos não puder ser satisfeita pelo CloudFront, considere criar uma frota de proxy reverso (por exemplo, com base em NLB e EC2) para encerrar as conexões TCP/TLS e usar o Global Accelerator para melhorar a segurança e a performance. Observe que, nesse cenário, você precisa implementar o armazenamento em cache no seu proxy reverso, se necessário.

Recursos

Esta página foi útil para você?

 Feedback