Como escolher uma região de cloud para uma aplicação empresarial autoalojada

Comece pelos requisitos, não por um mapa das localizações dos fornecedores

Uma região próxima pode ser conveniente, mas a proximidade, por si só, não determina se é o local certo para executar uma aplicação empresarial. Primeiro, identifique o que a aplicação armazena e processa, quem a utiliza, de que serviços depende e o que a sua organização exige em matéria de acesso e recuperação.

Registe os requisitos antes de comparar as localizações disponíveis. Separe os requisitos obrigatórios — como uma política interna ou um compromisso documentado com clientes — das preferências, como um percurso de rede mais curto para os utilizadores. Se um requisito depender de uma lei ou de um contrato, procure aconselhamento jurídico ou de conformidade adequado, em vez de tratar um seletor de regiões como uma determinação de conformidade.

• Que pessoas e processos empresariais dependem da aplicação?
• Que tipos de informação irá conter ou enviar para outros serviços?
• Existem requisitos contratuais, organizacionais ou legais relativos à localização que devam ser avaliados?
• Que necessidades de experiência dos utilizadores e de recuperação tem de suportar a solução de alojamento?
• Que detalhes continuam por esclarecer e precisam de confirmação por escrito?

Mapeie os fluxos de dados da aplicação

Faça uma lista das informações tratadas pela aplicação e registe o percurso que seguem. Comece pelos registos principais e inclua também os ficheiros carregados, as exportações geradas, os dados de autenticação, os registos da aplicação e de acesso, os dados de monitorização, as cópias de segurança e as informações enviadas para serviços ligados. Inclua as pessoas que podem aceder a essas informações ou tratá-las, bem como os sistemas que as armazenam ou processam.

Registe a categoria dos dados, o sistema ou a pessoa que os recebe, a finalidade e quaisquer informações de localização que tenha verificado. Assinale explicitamente o que não sabe. O servidor da aplicação é apenas uma parte deste mapa; por isso, verifique os detalhes de localização dos outros serviços e percursos de dados, em vez de presumir que partilham a localização do servidor.

Mantenha o mapa proporcional. Uma equipa pequena pode começar com uma tabela e atualizá-la à medida que as integrações ou os fluxos de trabalho mudam. O objetivo é tornar os percursos dos dados suficientemente visíveis para poder colocar as perguntas relevantes.

• Registos da base de dados principal e ficheiros carregados
• Exportações, ficheiros temporários e conteúdo gerado pela aplicação
• Registos da aplicação, de acesso, de erros e de monitorização
• Cópias de segurança, instantâneos e cópias utilizadas para restauro
• Acesso de suporte, administração e outras operações
• Dados enviados para serviços de identidade, email, pagamentos, análise, IA ou outros serviços ligados

Considere separadamente as necessidades dos utilizadores e as obrigações de localização

A experiência dos utilizadores e os requisitos relativos à localização dos dados são aspetos distintos. Para avaliar as necessidades dos utilizadores, identifique onde trabalham e quais são os fluxos de trabalho da aplicação mais importantes para eles. Sempre que possível, avalie a aplicação real com utilizadores representativos e percursos de acesso relevantes, em vez de se basear apenas num mapa.

Quanto às obrigações de localização, identifique os dados e o processamento específicos abrangidos por cada requisito e confirme os detalhes relevantes do fornecedor e do serviço. Mantenha estas obrigações separadas das preferências de experiência dos utilizadores e procure aconselhamento adequado para interpretar requisitos legais ou contratuais.

A [documentação do Compute Engine da Google](https://docs.cloud.google.com/compute/docs/regions-zones) indica que os utilizadores escolhem a região ou zona onde os recursos são alojados e que essa escolha determina onde os dados desses recursos são armazenados e utilizados. Esta informação descreve o Google Compute Engine; não a generalize a todos os serviços de cloud nem a todos os fluxos de dados de uma aplicação.

• Registe as principais localizações dos utilizadores e os fluxos de trabalho importantes para eles.
• Sempre que possível, valide a experiência dos utilizadores com a aplicação e percursos de acesso representativos.
• Registe as obrigações relativas à localização separadamente das preferências de experiência dos utilizadores.
• Confirme que serviços e categorias de dados estão abrangidos pela declaração de localização do fornecedor.

Verifique cada serviço ligado

Uma aplicação autoalojada pode trocar informações com serviços fora do seu servidor principal. Consoante a configuração, estes podem incluir identidade e início de sessão único, envio de email, processamento de pagamentos, análise, pontos de acesso de IA, armazenamento de ficheiros ou monitorização. Cada serviço tem os seus próprios termos, definições e práticas de tratamento de dados.

Para cada dependência, registe que informações são enviadas e porquê. Consulte a documentação do serviço ou pergunte ao respetivo fornecedor sobre os detalhes de localização, armazenamento, retenção e acesso operacional relevantes para a sua configuração. As perguntas dependerão do serviço e dos seus requisitos.

Por exemplo, a [Langfuse afirma que os clientes podem escolher uma região](https://langfuse.com/security/data-regions) para alinhar o serviço com as necessidades de residência de dados da organização. Esta afirmação diz respeito ao serviço da Langfuse; verifique os detalhes relevantes para a sua configuração, em vez de a interpretar como uma afirmação sobre todas as categorias de dados ou formas de acesso operacional.

• Inventarie as integrações, incluindo plug-ins opcionais e tarefas em segundo plano.
• Identifique os campos ou ficheiros sensíveis enviados a cada serviço.
• Consulte as definições de região e a documentação do serviço para os dados em causa.
• Pergunte se são necessárias alterações de configuração para cumprir os requisitos pretendidos.
• Registe os serviços cuja localização ou condições de tratamento continuam por esclarecer.

Pergunte aos fornecedores o que abrange cada escolha de localização

Faça perguntas precisas e específicas sobre cada serviço para perceber o que controla a seleção de uma região e que serviços estão abrangidos. Pergunte também sobre cópias de segurança, monitorização, registos e suporte operacional, quando forem relevantes para os seus requisitos. Guarde as respostas dos fornecedores juntamente com o registo da decisão.

Se utilizar alojamento gerido, pergunte quem pode aceder ao ambiente para prestar suporte operacional e em que circunstâncias. A infraestrutura gerida pode reduzir a administração da cloud que a sua equipa tem de assegurar, mas não elimina a sua responsabilidade de decidir que dados colocar na aplicação ou como gerir o acesso de utilizadores e administradores.

Numa aplicação gerida pela Airbip, as instâncias são executadas como cargas de trabalho Docker em servidores cloud da Airbip. A Airbip fornece gestão do ciclo de vida do serviço e cópias de segurança diárias, semanais e mensais configuráveis. Estas capacidades não determinam uma localização específica para os servidores ou as cópias de segurança. Consulte o site atual da Airbip e pergunte diretamente à Airbip pelos detalhes de localização relevantes para os seus requisitos antes de se basear neles.

• Que localização se aplica ao servidor da aplicação e ao armazenamento associado?
• Onde são armazenadas as cópias de segurança e que opções ou condições de localização se aplicam?
• Onde são tratados os registos e os dados de monitorização?
• Quem pode aceder ao ambiente para prestar suporte operacional?
• Que serviços ligados ou subcontratantes estão fora deste serviço de alojamento?
• Como são geridas as alterações de localização, a retenção das cópias de segurança e o restauro?

Planeie a recuperação e uma possível migração

Antes de se comprometer com uma localização, documente como recuperaria a aplicação e o que teria de alterar para a migrar. Identifique o que tem de ser restaurado, que cópias estão disponíveis, quem pode iniciar a recuperação e que informações precisa de obter junto do fornecedor de alojamento. Confirme os procedimentos relevantes em vez de presumir uma localização específica para as cópias de segurança ou a disponibilidade de recuperação entre regiões.

Pergunte se uma cópia de segurança inclui os dados e a configuração da aplicação de que precisa, como a obter e se já testou o respetivo restauro. A Airbip disponibiliza cópias de segurança diárias, semanais e mensais configuráveis; confirme a configuração aplicável e os detalhes de recuperação da sua instância, em vez de os inferir a partir das opções de periodicidade.

Se considerar uma migração, esclareça como exportar os dados da aplicação, que configurações ou integrações poderão ter de ser alteradas e como validar o novo ambiente antes de mudar os utilizadores para esse ambiente. O plano dependerá da aplicação e da solução de alojamento.

• Faça uma lista dos dados e das configurações necessários para restaurar o serviço.
• Confirme com o fornecedor a localização das cópias de segurança, a retenção, o acesso e o processo de restauro.
• Determine quem é responsável pelas tarefas de recuperação e quem está autorizado a executá-las.
• Verifique as opções de exportação e identifique as integrações que poderão precisar de ser reconfiguradas após uma migração.
• Considere testar o restauro ou a migração quando o impacto para a empresa o justificar.

Documente a decisão e as questões em aberto

Uma folha de trabalho breve facilita a revisão da decisão por outro administrador. Compare as localizações candidatas com os requisitos essenciais e distinga os factos verificados das suposições. Se um fornecedor não conseguir responder a uma questão importante, registe essa incerteza em vez de a considerar resolvida.

O resultado não tem de ser uma pontuação única: uma localização pode adequar-se às necessidades dos utilizadores e deixar por esclarecer uma questão de tratamento de dados. Encaminhe as questões legais, contratuais ou de governação por resolver para o consultor adequado antes de considerar a decisão definitiva.

• Região ou localização de alojamento candidata
• Utilizadores e fluxos de trabalho que a localização pretende servir
• Categorias de dados e serviços abrangidos pela escolha
• Serviços ligados e respetivos detalhes verificados de forma independente
• Respostas do fornecedor sobre monitorização, acesso de suporte e recuperação
• Requisitos cumpridos, compromissos aceites e evidências registadas
• Questões em aberto, responsável e data da próxima revisão

Reveja a decisão quando o sistema mudar

Reveja a decisão quando a aplicação passar a ter utilizadores em novas localizações, começar a armazenar novas categorias de informação, adicionar uma integração, alterar as disposições das cópias de segurança ou ficar sujeita a um novo requisito contratual ou regulamentar.

Uma revisão pode atualizar o mapa dos fluxos de dados, verificar a documentação do fornecedor e determinar se as suposições originais continuam válidas. Registe o que mudou e quem aprovou eventuais alterações ao alojamento ou à configuração.

• Reveja a decisão depois de adicionar ou substituir um serviço ligado.
• Volte a avaliá-la quando mudarem as localizações dos utilizadores, os fluxos de trabalho ou os tipos de dados.
• Verifique as alterações do fornecedor que possam afetar a localização, as cópias de segurança, os registos ou o acesso de suporte.
• Atualize o registo da decisão e atribua o acompanhamento das questões por resolver.