- Devido a problemas de soberania de dados e conformidade com o GDPR gerados por serviços de nuvem dos EUA, surgiu a necessidade de migrar para uma nuvem europeia
- Mesmo abrindo mão totalmente da conveniência e dos serviços integrados da AWS, foi possível obter redução imediata de custos e maior clareza sobre os dados com hospedagem europeia como a Hetzner
- Para aumentar a eficiência operacional da infraestrutura, foi criada uma automação baseada em Ansible e um sistema de monitoramento autogerenciado
- Com a construção própria, passou-se a contar com uma arquitetura que facilita auditorias transparentes e com maior rigor no desenho de segurança
- Também foram obtidas vantagens estratégicas para o negócio, como redução de 90% nos custos e menor risco de vigilância dos EUA
Processo de migração da AWS para a nuvem europeia (Hetzner) e estratégia para manter a ISO 27001
O dilema de um CTO europeu: questões de conformidade fora da AWS
- Uma preocupação recorrente entre líderes de tecnologia vem das limitações dos provedores de nuvem dos EUA
- Embora houvesse satisfação com os robustos serviços certificados pela ISO 27001 oferecidos pela AWS, por causa do CLOUD Act e da FISA dos EUA não era possível evitar que os dados de clientes na Europa ficassem expostos à jurisdição americana
- Surgiu, assim, uma situação em que se tornou difícil cumprir as promessas do GDPR, independentemente da localização real dos servidores
- Percebeu-se que a conta anual de nuvem, de US$ 24.000, era excessiva em relação à demanda real
- Ficou claro que depender do futuro da empresa de um único provedor sediado nos EUA era um risco estratégico
Apresentação do caso real da Datapult
- A Datapult é uma empresa dinamarquesa de software de gestão de força de trabalho, e precisa de confiabilidade em nível financeiro para escalas de funcionários, ajustes de pagamento de horas extras e gestão de dados de ponto
- Os requisitos legais vinham sendo atendidos de acordo com o workflow baseado em AWS, mas o processo de migração para soluções on-premises ou alternativas independentes exigia revisão jurídica adicional
Receios ao deixar a AWS e as perdas reais
- Abrir mão da conveniência integrada da AWS representa uma grande barreira psicológica de entrada
- Perdem-se a praticidade e a automação de recursos como Lambda, RDS com um clique e várias ferramentas nativas de conformidade regulatória
- Isso leva à substituição de serviços gerenciados por maior controle direto e mais responsabilidade
Efeitos esperados da nuvem europeia e ganhos práticos
- A migração para provedores europeus (Hetzner, OVHcloud) trouxe benefícios imediatos em soberania de dados, GDPR e ISO 27001
- Comprovação real de residência de dados, permitindo comunicação mais transparente com clientes e melhor resposta a auditorias
- Redução de custos inesperada (90%) e maior transparência orçamentária
- Mesmo abrindo mão da conveniência da AWS, houve avanço técnico com processos de automação mais robustos (configuração com Ansible) e melhoria da segurança
- Em comparação com antes, foram conquistadas mais autonomia, mais capacidade de inovação e uma infraestrutura verificável
Estratégia concreta de transição e principais lições
- Automação de conformidade com Ansible
- Foi implementada uma gestão de infraestrutura autodescritiva, em que todas as configurações dos servidores se conectam diretamente aos controles do Anexo A da ISO 27001
- Construção de um sistema de monitoramento alternativo à AWS
- Com a combinação de Prometheus, Grafana e Loki, tornou-se possível ter monitoramento corporativo no nível do AWS CloudWatch e resposta rápida a incidentes
- Implementação de security by design para reforçar o desenho de segurança
- Na ausência de ferramentas de segurança gerenciadas, a automação com Ansible fortaleceu o ISMS (sistema de gestão de segurança da informação) e facilitou a conformidade para os desenvolvedores
Efeitos estratégicos para além da tecnologia
- Minimização do risco de conformidade causado por leis de vigilância dos EUA
- Uso da infraestrutura de hospedagem europeia como diferencial comercial, elevando a confiança e o valor da marca
- Criação de uma estrutura para reinvestir no core do negócio os 90% economizados em custos de nuvem
Guia prático para aplicar a estratégia de migração
- Com base na experiência de migrar de uma infraestrutura AWS para uma nuvem europeia com soberania mantendo a ISO 27001, é possível oferecer diretrizes reproduzíveis
- Para CTOs e fundadores que consideram trocar a AWS por uma nuvem europeia, é possível oferecer consultoria personalizada sobre análise de custos, risco de conformidade e cronograma de execução
- Em uma hora, é possível organizar a diferença de custos, os principais riscos legais e as etapas iniciais da migração
1 comentários
Comentários do Hacker News
Nós reduzimos custos reimplementando por conta própria os recursos centrais da AWS, mas muita gente ignora o custo real de uma hospedagem no estilo DIY, especialmente coisas como suporte 24 horas por dia. Se você tentar construir esse suporte internamente, o custo pode acabar sendo bem alto. US$ 24.000 por ano de uso da AWS equivale a 1 ou 2 meses de um excelente freelancer de DevOps, ou cerca de 1/3 de FTE de um desenvolvedor de baixo custo, e com esse orçamento é difícil esperar suporte de prontidão 24/7. Claro, essa escolha pode fazer sentido, mas é uma pena que não tenham divulgado com franqueza tudo, inclusive o tempo de desenvolvimento e os custos de administração. Eu também estou avaliando uma escolha parecida, mas mais por exigências de negócio, como clientes alemães, do que por economia. Ainda assim, tudo vai ficar mais complexo e também será preciso ampliar a equipe. Como CTO, meu tempo é limitado, e me envolver diretamente nesse tipo de trabalho é a pior forma de usar esse tempo. Acho que deveria focar mais no avanço da empresa e do produto. Pessoalmente, acho Terraform excessivo para algo desse porte, e Ansible parece se encaixar melhor como um caso de YAGNI (You Ain’t Gonna Need It).
As pessoas entendem errado e acham que grandes provedores de nuvem como AWS, Azure e GCP realmente oferecem suporte 24/7 para a aplicação, mas na prática não é assim. A infraestrutura apenas funciona “mais ou menos” bem, e no fim ainda é preciso ter especialistas para evitar explosões de custo ou verificar manualmente problemas de integração. A ideia de que a cobrança real da nuvem é o TCO (custo total de propriedade) é um mito completamente errado
Se você tentar copiar 100% dos recursos da AWS, pode sair caro, mas se só precisa de 80%, a situação muda. Além disso, não dá para ignorar o esforço de configurar a AWS e continuar aprimorando esse conhecimento técnico. Por exemplo, em vez do dashboard da AWS, você pode usar ferramentas melhores como Grafana. No fim, tudo depende da escala e da variedade dos requisitos. Nem sempre o martelo mais caro é a resposta certa
Olhando apenas para a economia, isso significa reduzir em US$ 21.600 por ano, ou 90% dos US$ 24.000 originais. Mas com esse orçamento você não contrata um engenheiro de SRE/DevOps na Europa. Pelo contrário, acho que com o tempo o custo total de propriedade vai subir, porque você mesmo terá de cuidar de toda a infraestrutura no longo prazo. Ainda assim, torço pela iniciativa
Se você considerar o risco de o governo dos EUA exigir que a Amazon suspenda à força a conta, usar AWS pode ser arriscado. Acho isso ainda mais relevante num momento em que se fala em guerra entre os EUA e a Europa (Groenlândia)
Acho simplista demais esse cálculo bruto de US$ 24.000 por ano. Sinto falta de uma estimativa concreta de custo de pessoal: quantas pessoas seriam necessárias para montar esses serviços na AWS e quanto trabalho humano seria preciso para reduzir algo que custava de US$ 48 mil a US$ 100 mil para US$ 24 mil
Acho que só com a combinação de Prometheus, Grafana e Loki já foi possível reproduzir por conta própria, ou até superar, o nível de monitoramento que havia na AWS. Sempre me surpreende que essas ferramentas sejam tão excelentes e, ainda assim, os serviços de monitoramento da AWS sejam caros, lentos e tenham uma UX decepcionante. Na prática, o custo de monitoramento foi a parte mais rápida e desagradável da minha experiência com a AWS
A principal desvantagem da Hetzner é o problema de IPs contaminados por usuários maliciosos, além da necessidade de lidar com falhas de hardware e upgrades. Fiquei curioso se isso não preocupou vocês. Também queria saber como resolveram o problema de explosão no uso de memória do Loki e se existem outras alternativas
O problema de IP contaminado é tratado fazendo proxy do acesso dos usuários via Cloudflare e configurando o firewall (
ufw) para aceitar conexão apenas de fontes autorizadas e dos IPs da Cloudflare, bloqueando na prática o acesso externo direto. Falhas de hardware e upgrades podem ser resolvidos rapidamente com um setup em Terraform, substituindo máquinas e ampliando capacidade em pouco tempo. Monitoramos o hardware com Prometheus e node exporter para receber alertas antecipados, e não houve falhas em 9 meses. O app quase não tem dados, e o banco de dados é testado com frequência em cenários de restauração. O problema de memória do Loki foi resolvido combinando várias medidas, como política de retenção e separação de índices, ajuste fino de concorrência de consultas e limites de memória, adoção de labels no estilo promtail e logging estruturado, e substituição de registros antigos por backup em object storage ougrepO problema que tivemos com o Loki veio do fato de que as configurações padrão de implantação, como as do Helm básico, não eram bem otimizadas. Depois de aplicar as dicas de performance citadas no blog — redefinir índices, adicionar instâncias somente leitura e incorporar outras recomendações — vimos uma melhora clara de desempenho. Como a intenção parece ser empurrar o usuário para o serviço de nuvem da própria empresa, acho que no começo é preciso apanhar um pouco
Como alternativa ao Loki, recomendo Victoria. É muito mais rápido e tem ótima reputação, mas escolhemos Loki levando em conta a diversidade de mantenedores do projeto. Compensamos as desvantagens com os métodos mencionados acima
Compartilhando o link https://en.wikipedia.org/wiki/Sybil_attack. Provedores de nuvem caros têm a vantagem de construir reputação de IP de forma parecida com PoW (proof of work)
ISO 27001 é um padrão internacional de gestão de segurança e uma diretriz popular na Europa. Nos EUA ele quase não é usado, e muitas empresas europeias às vezes não entendem bem essa diferença. A base dos padrões de segurança nos EUA é o SOC 2, que é menos rigoroso que o ISO 27001 e mais familiar ao mercado americano
O ISO 27001, por si só, não é exatamente um padrão rígido ou sufocante; em geral, ele exige o básico que deveria ser feito ao usar software. O difícil mesmo é comprovar tudo por documentação, enquanto no SOC 2 a carga documental é visivelmente menor
Tendo passado por SOC 2 e ISO 27001, acho frustrante que a auditoria do SOC 2 dependa muito mais da capacidade e da intuição do auditor do que dos controles práticos. O ISO 27001 me parece uma auditoria muito mais clara e justa
Pedem que alguém cite apenas uma grande empresa americana de nuvem que não tenha certificação ISO 27001
Eu também fiz algo parecido com Azure e reduzi 90%. Tenho a impressão de que as grandes empresas impõem de propósito uma experiência de abstração de serviços complexa, tornando cada vez mais difícil operar as coisas de forma simples
Um dos motivos para pagar AWS é reduzir a carga operacional e, de fato, usando banco de dados gerenciado da AWS deixei de sentir o estresse de antes ao fazer upgrade de cluster MySQL. Claro que só isso não justifica os custos altos, mas considero um valor considerável
Os números não fazem sentido para mim. Se houver 90% de redução sobre US$ 24.000 por ano, isso dá US$ 200 por mês, que é basicamente o preço de um único servidor da Hetzner. Nesse caso, parece que daria para usar apenas um servidor, sem sistema distribuído. Fiquei curioso sobre o volume real de requisições por segundo e o número de usuários
Para cumprir ISO 27001, não dá para operar só com um único servidor; também é necessário um servidor separado para logs e monitoramento. A complexidade aparece independentemente da carga. Os funcionários não fazem login todos os dias e, por ser um app de agendamento, às vezes só verificam 1 ou 2 vezes por semana. O DAU fica entre 10 mil e 20 mil, com pico de 1.500 a 2.000 conexões simultâneas e média de 50 a 150. O motivo de o custo em nuvem subir é o peso do processamento de dados do app, por causa de recursos em tempo real e regras trabalhistas complexas. Por exemplo, atribuição de turnos envolve regras diferentes até para cálculo de bônus, e a otimização da escala também exige bastante computação
Corrigem que não são US$ 2.400, e sim US$ 200
Fiquei curioso sobre como fazem criptografia de disco. Na AWS isso é automático, mas nunca vi uma implementação realmente boa disso em provedores de hospedagem comuns. Também apontam que guardar a chave de criptografia na partição de boot torna tudo inútil
Eu gosto muito da Hetzner e até rodo meu mecanismo de busca lá. Acho excelente usar servidor físico
Além de OVH e Hetzner, eu também gostaria de recomendar a UpCloud entre as nuvens europeias. A vantagem da UpCloud é que os núcleos de CPU parecem ser todos núcleos reais, e não vCPU baseada em threads. Só é uma pena faltar referência oficial sobre isso. Não é fácil comparar OVH, Hetzner e hyperscalers, mas no caso da Hetzner há essa diferença de eles usarem, em sua maioria, peças de consumidor. Apresentação da UpCloud