Antes de iniciar o texto, gostaria de afirmar que o termo “whitelabel domain” não me agrada muito, mas infelizmente não achei outra definição. Fico aberto a sugestões :).

SaaS

Este artigo possui alguns tópicos nas primeiras seções pois algumas definições necessitam ser contextualizadas, bem como desafios e motivações. Então caso já entenda sobre o assunto e quer apenas saber como fazer isso na AWS, sugiro que siga direto para a seção “Configurando a solução na AWS”.
Vamos lá!
Para contextualizar o que vamos debater, deixo aqui a definição do que é um Software as a Service (SaaS):
Software como serviço, do inglês Software as a service (SaaS), é uma forma de distribuição e comercialização de software. No modelo SaaS, o fornecedor do software se responsabiliza por toda a estrutura necessária à disponibilização do sistema (servidores, conectividade, cuidados com segurança da informação), e o cliente utiliza o software via internet, pagando um valor pelo serviço.[1][2]
Fonte: Wikipédia

Após essa definição, podemos focar nos principais desafios das empresas que produzem “Software as a Service” (SaaS) enfrentam e dentre eles podemos elencar:
• Entregar a melhor experiência aos clientes
• Possibilitar customização do software
• Um rápido delivery de atualizações e melhorias
• Conseguir o menor custo possível para o cliente.
Como seria esperado, as empresas que contratam um SaaS buscam fazer algumas customizações, como configurar seu próprio domínio para uso, por exemplo.

Cenário

Imagine o seguinte cenário: A Startup “Leandro Cloud” vai produzir um ERP no modelo SaaS cuja URL é “https://erp.leandro.cloud”. O software ficou pronto e diversos clientes começam a comprar uma assinatura mensal desse software, dentre eles a RHCompany. Só que a RHCompany possui uma exigência em que este software seja acessado via “https://erp.rhcompany.com.br”, isopor conta de uma regra de compliance da empresa. E agora, o que a empresa Leandro Cloud precisa fazer para isso? Abaixo temos algumas possibilidades:

• Implementar uma solução utilizando Let’s Encrypt nos servidores.
• Se a empresa utiliza Kubernetes, por exemplo, pode resolver isso com TLS termination em um ingress controller.
• Pode solicitar a RHCompany que faça o TLS termination nos seus load balancers e apenas configure o DNS.
• Pode disponibilizar o acesso ao sistema sem HTTPS.
• Pode enviar o código do sistema para a empresa RHCompany para que ela execute nos servidores dela.

Todas as soluções acima são possíveis e a empresa Leandro Cloud não precisaria utilizar nenhum serviço da AWS, mas todos eles trazem um ou mais problemas, tais como: complexidade de implantação, fuga do conceito de SaaS, segurança, custo recorrente de manutenção, desvio do foco do negócio, mudanças complexas no cliente, equipe altamente especializada, entre outros. E é aí onde a Leandro Cloud pode utilizar soluções 100% AWS para resolver este problema com baixo custo, baixa necessidade de manutenção e totalmente automatizado.
Neste momento talvez você esteja se perguntando: não basta apenas a RHCompany apontar o DNS para o endereço que a Leandro Cloud disponibilizar? A resposta é: Sim e não.

Se falarmos de customização de URL, sim, basta apenas uma entrada no DNS e a customização “está pronta”, mas e o HTTPS? Como resolver isso? O que vai acontecer quando alguém acessar “https://erp.rhcompany.com.br”? E aqui temos a parte da resposta que é não e vamos entender o porquê.

Um breve resumo sobre HTTPS (SSL/TLS)

Segundo a Wikipédia, a definição de HTTPS é a seguinte:
HTTPS (Hyper Text Transfer Protocol Secure — protocolo de transferência de hipertexto seguro) é uma implementação do protocolo HTTP sobre uma camada adicional de segurança que utiliza o protocolo SSL/TLS. Essa camada adicional permite que os dados sejam transmitidos por meio de uma conexão criptografada e que se verifique a autenticidade do servidor e do cliente por meio de certificados digitais. A porta TCP usada por norma para o protocolo HTTPS é a 443.
E é justamente pelo motivo de termos uma conexão criptografada que verifica autenticidade do servidor e do cliente, que o HTTPS exige que um certificado digital seja configurado para isso, pois é ele que vai garantir esta autenticidade.

Um certificado digital é um documento eletrônico, geralmente configurado no servidor que o sistema está executando. Ele vai garantir que aquele servidor, o qual está hospedando o site “https://erp.rhcompany.com.br” tem autorização de utilizar aquele nome, uma vez que todos os trâmites prévios de validação foram realizados.

Se este certificado não for emitido pela RHCompany e configurado nos servidores da Leandro Cloud, então o site “https://erp.rhcompany.com.br” vai informar que aquele certificado não é seguro, assim trazendo diversos problemas de segurança. Por este motivo, a Leandro Cloud precisa pedir a RHCompany que autorize utilizar um certificado com o nome “erp.rhcompany.com.br” em seus servidores.

NOTA: Ao ler esse artigo, é possível notar que na barra de endereço existe um cadeado, que ao clicar em “Informações do Certificado” encontramos a informação do certificado que garante que ele é valido para o domínio medium.com.

Certificado valido emitido para medium.com

Configurando a solução na AWS

Agora que entendemos os desafios e motivações que uma solução como essa exige, vamos compreender como ao utilizar os serviços 100% gerenciados, você pode ter seu SaaS, multi-tenant e whitelabel domain na AWS compartilhando os mesmos recursos de back-end e infraestrutura, tais como: EC2, Lambda, ECS, EKS, AppRunner, entre outros.

Neste artigo vamos abordar um SaaS utilizando as seguintes tecnologias na AWS:
• API Gateway para configurar as rotas do backend
• Lambda para executar códigos Python de backend
• ACM para criar os certificados
• S3 para hospedar meu site estático em qualquer framework JavaScript
• Cloudfront para distribuir o tráfego otimizado e suportar terminação SSL

Arquitetura da solução

Achei um projeto que tem um código que possibilita se adaptar a essa necessidade, então caso queira automatizar, utilize o código do seguinte repositório.

Lambda

A função Lambda não é um ponto extremamente relevante neste processo, mas eu vou mostrar como ela foi criada:

A função acima testa o domínio que está acessando e define as variáveis de retorno. Absolutamente existem outras dezenas formas de programar isso, mas é apenas um exemplo.

Você pode ser back-end em EC2/ECS/EKS/AppRunner e vai funcionar do mesmo jeito. Outro ponto que precisamos frisar é que seu back-end vai ter regras de negócios complexas, CORS, chaves de verificação e coisas do tipo, mas a intenção aqui é demonstrar a solução funcionando.

Essa função Lambda é única e vai servir para atender todo o ambiente multi-tenant.

API Gateway

Foi criada uma API Rest no API Gateway com apenas uma rota “/” com GET e utilizando a Lambda acima como PROXY INTEGRATION.

ATENÇÃO: lembre-se de habilitar o CORS.

API Gateway

Essa API Gateway é única e vai servir para atender todo o ambiente multi-tenant.

S3

Foi criado um bucket chamado “medium-saas-multitenant” para hospedar nosso front-end estático. Também foi criada uma página HTML simples com apenas uma chamada para a API Gateway criada anteriormente e que vai consultar o back-end. Essa página vai simular a index do nosso sistema ERP e verificar qual domínio está acessando o sistema para customizar a página inicial. Neste bucket você pode ter seu site estático desenvolvido em VueJs, React, Angular, Flutter ou qualquer outro framework desses que gera sites estáticos em JS/HTML/CSS.
O seguinte arquivo HTML foi criado:

Página inicial do ERP

Esse bucket é único e vai servir para atender todo o ambiente multi-tenant.

ACM

O AWS Certificate Manager (ACM) é um serviço que permite provisionar, gerenciar e implantar facilmente certificados Secure Sockets Layer (SSL)/Transport Layer Security (TLS) para uso com os serviços da AWS e os recursos internos conectados. Em outras palavras, o ACM é um serviço que emite certificados de forma gratuita, para você utilizar dentro da AWS. Imagine o ACM como os tradicionais CA (Certificate Authority) de mercado: GoDaddy, IdenTrust, Let’s Encrypt, GlobalSign, outros.
E onde vamos utilizar o ACM em nossa solução? Lembra-se que no começo desse artigo informamos que a RHCompany precisa autorizar a emissão de um certificado com o nome erp.rhcompany.com.br para ser utilizado nos servidores da Leandro Cloud? Pois é isto que vamos fazer agora:

Como você pode imaginar, a RHCompany é uma empresa fictícia e eu não possuo esse domínio, então para esse teste eu vou utilizar 2 domínios que eu possuo: awscdk.cloud e cloudarchitects.solutions.
Abra o console do ACM na AWS e vamos emitir o certificado. Como iremos utilizar esse certificado para uso no Cloudfront, obrigatoriamente você deve emitir este certificado na us-east-1.
Vamos emitir dois certificados: um para o domínio erp.awscdk.cloud e outro para erp.cloudarchitects.solutions. Clique em “Request a Certificate” -> “Request a public certificate” -> Insira o nome “erp.awscdk.cloud” no domain name -> Selecione o método DNS de validação -> Clique em next até o final e copie os endereços de DNS informados pelo ACM. Esses DNS devem ser enviados para o cliente para que ele insira em sua zona, pois são esses DNS que vão autorizar a validação do certificado.
Aguarde até que o cliente insira os DNS e o ACM coloque o status do certificado em verde e escrito “Issued”. Enquanto o certificado não ficar com status “Issued” você não vai poder usar ele no Cloudfront.

Certificados emitidos.

ATENÇÃO: O ACM tem uma quota de 2500 certificados, mas você pode pedir aumento de quota na AWS.

Cloudfront

Antes de iniciarmos essa etapa, é importante frisar que qualquer conta possui 200 distribuições de quota no Cloudfront, mas que pode ser pedido seu aumento via Service Quotas no painel da AWS. Então se sua solução tiver muitos clientes, solicite este aumento na AWS, pois teremos que ter 1 distribuição Cloudfront para cada cliente.
Agora que já temos todo nosso back-end montado, nosso site estático hospedado e nossos certificados emitidos, é hora de configurarmos o whitelabel domain do cliente e termos a solução completa.
Abra o console do cloudfront e crie uma distribuição. Preencha os seguintes campos:
• Origin: Selecione o bucket “medium-saas-multitenant” que criamos anteriormente. O Cloudfront já vai preencher isso para você.
• Configure a Origin Access Identity como quiser
• Protocol Policy: Redirect HTTP to HTTPS
• Alternate Domain Name (CNAME): Adicione o dominio erp.awscdk.cloud
• Custom SSL Certificate: Selecione o certificado erp.awscdk.cloud criado anteriormente
• Default root object: index.html

Após a criação da distribuição, o Cloudfront vai informar um nome como XXXXXXXXXXX.cloudfront.net. Anote esse endereço e envie para o cliente criar o registro erp.dominio (CNAME) no DNS dele. Neste caso vamos inserir para o domínio erp.awscdk.cloud o CNAME d1ce578qu63jhs.cloudfront.net, que foi fornecido pelo Cloudfront.

Repita os mesmos passos acima para o domínio erp.cloudarchitects.solutions.

Agora que temos tudo configurado, basta acessar os sites https://erp.awscdk.cloud/ e https://erp.cloudarchitects.solutions/ e temos a solução SaaS compartilhando diversos recursos da AWS e utilizando uma solução de whitelabel domain.

https://erp.awscdk.cloud/

https://erp.cloudarchitects.solutions/

Para finalizar, vamos aos prós e contras.

Prós

• Por ser uma solução Serverless, não requer administração de infra
• Baixo custo
• Possibilidade de automatizar
• Provisionamento da configuração em minutos

Contras

• Uma atualização do front-end tem que “triggar” um invalidation em todas as distribuições do Cloudfront. Mas isso pode ser facilmente automatizado com um S3 Event trigando um Lambda.
• A limitação de 200 distribuições de Cloudfront pode ser um problema inicialmente, mas dá para solicitar a AWS o aumento.
• A emissão de ACM e validação são processo assíncronos, então isso gera um pouco de trabalho para escrever uma automação. Mas pode ser feito com StepFunctions, por exemplo. Pode ser também agendado um evento no EventBridge para isso.
• CORS pode ser um problema

Veja o último artigo do nosso #cloudspecialist em nosso blog!