1. Visão geral do cliente
Cliente: Ingresso Seguro
Setor: Entretenimento / Eventos
Modelo: Plataforma digital de bilheteria
Região: Brasil
Ano do Projeto: 2025
A Ingresso Seguro é uma plataforma digital de bilheteria voltada para eventos, responsável por processar vendas, cancelamentos e integrações em cenários de alta concorrência e picos intensos de acesso. O ambiente opera com forte dependência de processamento assíncrono e exige alta disponibilidade durante períodos críticos, como abertura de vendas e grandes campanhas.
A solução foi construída sobre a AWS com foco em resiliência, escalabilidade e segurança operacional, utilizando majoritariamente serviços gerenciados para reduzir a complexidade de operação e permitir crescimento progressivo da plataforma.
2. O desafio
Desafio do cliente
O principal desafio da Ingresso Seguro estava relacionado à necessidade de sustentar picos previsíveis de tráfego sem comprometer a estabilidade do sistema ou a experiência do usuário. O processamento de eventos de bilheteria envolve múltiplas etapas assíncronas, integração com parceiros e persistência consistente de dados transacionais, o que torna a arquitetura sensível a gargalos e falhas de escalabilidade.
Além disso, a infraestrutura havia crescido de forma incremental ao longo do tempo, concentrando todos os ambientes em uma única conta AWS e utilizando a VPC padrão. Esse modelo atendia à operação inicial, mas passou a apresentar riscos de segurança, limitações de governança e menor previsibilidade operacional à medida que o volume de requisições aumentava.
3. Solução implementada na AWS
A arquitetura da Ingresso Seguro foi estruturada com backend desenvolvido em C#.NET Core e frontend em React, ambos executados sobre ambientes gerenciados pelo Elastic Beanstalk. O Beanstalk é responsável por orquestrar múltiplas instâncias EC2 com Auto Scaling, garantindo capacidade de resposta durante picos de acesso sem a necessidade de provisionamento manual.
O processamento crítico da plataforma foi desacoplado por meio do uso intensivo de filas do Amazon SQS. Operações como criação, cancelamento e atualização de ingressos são processadas de forma assíncrona, reduzindo a pressão sobre a API principal e o banco de dados transacional.
Os ambientes da aplicação foram organizados de acordo com sua função operacional, incluindo produção, portal, processor, QA e desenvolvimento, todos executando sobre a mesma conta AWS, porém com separação lógica por ambientes do Elastic Beanstalk.
4. Arquitetura AWS Utilizada
A arquitetura da Ingresso Seguro está implantada na Amazon Web Services, na região us-east-2 (Ohio), utilizando uma única VPC distribuída em múltiplas Availability Zones para garantir alta disponibilidade. A VPC é segmentada em sub-redes públicas e privadas, permitindo separação clara entre a camada de aplicação exposta à internet e os componentes de dados sensíveis.
O acesso dos usuários ocorre inicialmente por meio do Amazon Route 53, responsável pela resolução de DNS. A partir daí, o tráfego é direcionado para o AWS WAF, que atua como camada de proteção contra ameaças de aplicação, aplicando regras gerenciadas e personalizadas antes que qualquer requisição alcance a infraestrutura interna. Após a inspeção no WAF, o tráfego segue para um Application Load Balancer internet-facing, que distribui as requisições de forma balanceada entre as Availability Zones.
A camada de aplicação é executada sobre instâncias Amazon EC2 gerenciadas pelo AWS Elastic Beanstalk. O Elastic Beanstalk opera com grupos de Auto Scaling em pelo menos duas Availability Zones, garantindo que múltiplas instâncias estejam ativas simultaneamente. Esse modelo permite absorver variações de carga e mantém a aplicação disponível mesmo em caso de falha de instâncias ou de uma zona inteira. As instâncias do Beanstalk estão posicionadas em sub-redes públicas, recebendo tráfego exclusivamente por meio do Load Balancer.
Para acesso administrativo controlado, a arquitetura inclui um Bastion Host em Amazon EC2, também localizado em uma sub-rede pública. Esse host funciona como ponto único de entrada para administração do ambiente, evitando exposição direta das instâncias de aplicação e dos bancos de dados. O acesso aos recursos internos ocorre a partir do bastion, seguindo regras restritivas de Security Groups.
A camada de dados está isolada em sub-redes privadas, sem acesso direto à internet. Os bancos de dados utilizam o Amazon RDS, com instâncias distribuídas entre Availability Zones diferentes para garantir resiliência. O banco PostgreSQL, representado no diagrama, opera em sub-redes privadas separadas por zona, reforçando o isolamento e a alta disponibilidade. A comunicação entre a camada de aplicação e os bancos ocorre exclusivamente dentro da VPC.
A observabilidade e a operação do ambiente são suportadas por serviços gerenciados adicionais fora do fluxo principal de tráfego. O Amazon CloudWatch é utilizado para coleta de métricas, logs e alarmes, fornecendo visibilidade contínua sobre a saúde da aplicação, da infraestrutura e dos bancos de dados. Alertas operacionais são integrados ao Amazon SNS para notificação da equipe responsável. O gerenciamento de certificados TLS é realizado pelo AWS Certificate Manager, garantindo comunicação segura entre usuários e o Load Balancer. O AWS Backup complementa a arquitetura com políticas centralizadas de backup para recursos críticos, como bancos de dados e instâncias.
A VPC possui um Internet Gateway associado para permitir comunicação externa dos componentes públicos. Não há uso de NAT Gateway, decisão tomada como trade-off consciente de custo, considerando que os recursos em sub-redes privadas não necessitam de acesso de saída direto à internet no modelo atual.
De forma geral, a arquitetura segue um padrão clássico de aplicações web altamente disponíveis na AWS, combinando balanceamento de carga, auto scaling, isolamento de rede e serviços gerenciados. O desenho prioriza simplicidade operacional, resiliência e segurança, ao mesmo tempo em que mantém espaço para evolução futura, como adoção de múltiplas contas, refinamento de sub-redes privadas e expansão para cenários multi-regionais, caso os requisitos de negócio evoluam.
5. Arquitetura de Banco de Dados
A camada de dados da plataforma utiliza o Amazon RDS como serviço gerenciado de banco de dados relacional. O banco principal de produção opera em MySQL 8.0, com uma instância primária dedicada ao processamento OLTP e uma réplica de leitura configurada para absorver consultas de leitura sem impactar a carga transacional. A replicação ocorre com latência praticamente nula, permitindo uso seguro da réplica em cenários de alta demanda.
Para ambientes de teste e validação, a plataforma utiliza uma instância MySQL dedicada em menor porte. Já o armazenamento analítico e de dados históricos é realizado em um banco PostgreSQL no Amazon RDS, utilizado como datalake para consultas e análises internas.
Todos os bancos de dados estão configurados em sub-redes privadas, sem exposição pública, com acesso restrito por Security Groups específicos e conexões realizadas exclusivamente por recursos internos ou via Client VPN Endpoint.
6. Segurança
A segurança da Ingresso Seguro foi desenhada com múltiplas camadas de proteção. Todas as aplicações expostas publicamente são protegidas por um Application Load Balancer integrado ao AWS WAF. O WAF utiliza regras gerenciadas da AWS e regras customizadas para mitigar ameaças comuns de camada 7, como tentativas de injeção, tráfego automatizado e acessos suspeitos.
O controle de acesso interno é realizado por meio de Security Groups, que limitam a comunicação entre serviços apenas às portas e origens necessárias. O acesso administrativo e aos bancos de dados ocorre exclusivamente por meio de um Client VPN Endpoint, evitando exposição direta de recursos sensíveis à internet.
Credenciais, tokens e segredos da aplicação são armazenados no AWS Secrets Manager, reduzindo riscos de vazamento e facilitando a rotação segura. No nível da aplicação, cada bilheteria opera com tokens de autenticação próprios, permitindo isolamento, rastreabilidade e controle de us
7. Observabilidade e operação
A observabilidade do ambiente é centralizada no Amazon CloudWatch. Logs de aplicações, APIs e ambientes Elastic Beanstalk são enviados automaticamente para grupos de logs dedicados, com políticas de retenção ajustadas conforme a criticidade do ambiente.
O volume operacional da plataforma é elevado, com dezenas de milhões de atualizações de métricas mensais, abrangendo Elastic Beanstalk, EC2, RDS, WAF, ALB, SQS, Kinesis e ElastiCache. A equipe utiliza CloudWatch Logs Insights para análise avançada de eventos, rastreamento de erros e investigação de incidentes operacionais.
Embora alarmes já estejam configurados para alguns serviços críticos, a análise do ambiente identificou oportunidades de melhoria na criação de alertas mais proativos, especialmente relacionados a consumo de recursos, crescimento anormal de filas, erros HTTP e utilização de armazenamento.
A operação do ambiente segue processos contínuos de serviços gerenciados, com monitoramento proativo, análise recorrente de métricas e atuação preventiva para mitigação de riscos operacionais.
8. Resultados Observados
A arquitetura atual suporta picos superiores a cento e sessenta mil requisições por minuto sem interrupção do serviço. O uso de processamento assíncrono e filas desacoplou cargas críticas do banco de dados principal, reduzindo riscos de gargalo. A replicação de leitura do MySQL mantém latência praticamente zero, garantindo desempenho consistente mesmo sob alta concorrência.
A plataforma mantém alta disponibilidade durante eventos críticos e apresenta boa previsibilidade operacional, mesmo em cenários de aumento abrupto de tráfego.
9. Por que AWS
A AWS foi escolhida por permitir a construção de uma arquitetura orientada a eventos, altamente escalável e baseada em serviços gerenciados. Recursos como Elastic Beanstalk, SQS, RDS, WAF e CloudWatch reduziram significativamente a complexidade operacional, ao mesmo tempo em que ofereceram segurança, observabilidade e capacidade de crescimento sob demanda.
A combinação de alta disponibilidade multi-AZ, integração nativa entre serviços e modelo de custo sob consumo foi determinante para atender às necessidades da Ingresso Seguro.
10. Melhorias implementadas e alinhamento ao Well-Architected Framework
Como resultado da análise da arquitetura e da evolução operacional da plataforma, a Ingresso Seguro implementou um conjunto de melhorias estruturais alinhadas aos princípios do AWS Well-Architected Framework. Essas ações tiveram como objetivo elevar o nível de segurança, governança, resiliência e previsibilidade operacional do ambiente.
Os ambientes passaram a ser separados por meio do uso de AWS Organizations, permitindo isolamento adequado entre produção, homologação e demais estágios, além de facilitar a aplicação de políticas de segurança e controle de custos. Paralelamente, foram criadas VPCs dedicadas com sub-redes privadas, reduzindo significativamente a superfície de exposição e melhorando o controle do tráfego interno entre camadas da aplicação e bancos de dados.
As regras de Security Groups foram revisadas de forma abrangente, eliminando acessos desnecessários e restringindo a comunicação apenas às portas e origens estritamente necessárias. Esse processo aumentou o nível de proteção da infraestrutura sem impactar a operação da aplicação.
No aspecto de observabilidade, foram configurados alarmes proativos no Amazon CloudWatch para monitorar métricas críticas de infraestrutura, aplicação e banco de dados. Esses alarmes permitem a detecção antecipada de anomalias, contribuindo para respostas mais rápidas a incidentes e redução de riscos operacionais.
A estratégia de proteção de dados também foi fortalecida com a implementação do AWS Backup, centralizando e automatizando os backups de recursos críticos, como bancos de dados e instâncias, com políticas de retenção alinhadas às necessidades do negócio.
As políticas de Auto Scaling foram ajustadas para garantir que a capacidade da camada de aplicação seja expandida antes de atingir níveis críticos de consumo, aumentando a confiabilidade durante picos de acesso previsíveis. Além disso, foram realizadas otimizações de custo importantes, incluindo a remoção de endereços IPv4 públicos desnecessários nas instâncias e a adoção do AWS Systems Manager para acesso administrativo, reduzindo custos operacionais e elevando o padrão de segurança.
Com essas melhorias já aplicadas, a arquitetura da Ingresso Seguro alcançou um nível mais alto de maturidade, refletindo uma adoção prática e consistente das boas práticas recomendadas pela AWS, ao mesmo tempo em que mantém flexibilidade para evoluções futuras conforme o crescimento da plataforma.
11. Modelo de Serviços Gerenciados AWS (MSP)
A UpperStack atua como provedora de Serviços Gerenciados AWS (Managed Service Provider) para a plataforma Ingresso Seguro, sendo responsável pela operação contínua, estabilidade, segurança e evolução do ambiente em produção na AWS.
O escopo dos serviços gerenciados inclui o gerenciamento do ciclo de vida operacional (Day-2) da infraestrutura e das aplicações, com foco em alta disponibilidade durante eventos críticos, previsibilidade operacional e melhoria contínua da plataforma.
Os serviços são prestados com base em acordos operacionais definidos com o cliente, garantindo previsibilidade, disponibilidade e tempos de resposta adequados a eventos críticos.
As responsabilidades da UpperStack no modelo MSP incluem:
- Monitoramento proativo 24×7 da infraestrutura e dos serviços críticos, utilizando Amazon CloudWatch, alarmes e notificações integradas ao Amazon SNS
- Gestão e resposta a incidentes, com atuação direta da equipe técnica em falhas de aplicação, infraestrutura ou degradação de performance
- Gestão de capacidade e escalabilidade, garantindo que as políticas de Auto Scaling estejam alinhadas aos picos previsíveis de acesso
- Gestão de segurança, incluindo manutenção de regras do AWS WAF, revisão de Security Groups, controle de acessos e gestão segura de segredos com AWS Secrets Manager
- Gestão de backups e recuperação, por meio do AWS Backup, com políticas centralizadas e testes periódicos de restauração
- Observabilidade contínua, com análise de logs, métricas e eventos operacionais para identificação antecipada de riscos
- Otimização contínua de custos, revisando padrões de consumo, ajustes de recursos e eliminação de desperdícios
- Evolução contínua da arquitetura, alinhada às boas práticas do AWS Well-Architected Framework
Esse modelo permite que a Ingresso Seguro concentre seus esforços no negócio, enquanto a UpperStack atua como extensão do time técnico do cliente, garantindo estabilidade, segurança e escalabilidade da plataforma.
12. Conclusão
O caso da Ingresso Seguro representa uma implementação real e validável na AWS, com uso consistente de serviços gerenciados e arquitetura orientada a eventos. O estudo evidencia não apenas os resultados alcançados, mas também a maturidade técnica ao identificar riscos e estabelecer um plano claro de melhoria contínua.
Esse cenário reflete uma adoção prática dos princípios do AWS Well-Architected Framework e demonstra a capacidade da plataforma de evoluir de forma segura e escalável conforme a demanda do negócio.
