Lab : Análise e Concepção de Arquitetura EC2
Objetivos do Lab
Este lab é um exercício de concepção e análise. Você irá:
- ✅ Analisar arquiteturas EC2 existentes
- ✅ Identificar boas práticas e erros
- ✅ Projetar sua própria arquitetura
- ✅ Justificar suas escolhas técnicas
Abordagem Teórica
Este lab não requer acesso à AWS. Você trabalhará em papel/documento com diagramas e análises.
Duração Estimada
2 horas
Parte 1 : Análise de Arquitetura Existente
Cenário : Site E-Commerce
Aqui está a arquitetura atual de um site e-commerce:
┌─────────────────────────────────────────────────────────────┐
│ RÉGION : us-east-1 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ AZ : us-east-1a │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Instance EC2 : i-web001 │ │ │
│ │ │ Type : t2.micro │ │ │
│ │ │ AMI : Amazon Linux 2 │ │ │
│ │ │ IP Publique : 52.1.2.3 │ │ │
│ │ │ │ │ │
│ │ │ Applications : │ │ │
│ │ │ - Apache (port 80) │ │ │
│ │ │ - MySQL (port 3306) │ │ │
│ │ │ - Application PHP │ │ │
│ │ │ │ │ │
│ │ │ Security Group : sg-default │ │ │
│ │ │ Règles : │ │ │
│ │ │ - Inbound: SSH (22) - 0.0.0.0/0 │ │ │
│ │ │ - Inbound: HTTP (80) - 0.0.0.0/0 │ │ │
│ │ │ - Inbound: MySQL (3306) - 0.0.0.0/0 │ │ │
│ │ │ │ │ │
│ │ │ Stockage : 8 GB EBS (gp2) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Questões de Análise
Questão 1 : Problemas de Segurança
Identifique pelo menos 3 problemas de segurança nesta arquitetura.
💡 Dica
Observe:
- As regras do Security Group
- A localização do MySQL
- A arquitetura de instância única
Questão 2 : Problemas de Disponibilidade
Identifique os riscos de disponibilidade desta arquitetura.
💡 Dica
Considere:
- Número de zonas de disponibilidade
- Ponto único de falha (SPOF)
- Capacidade de escalabilidade
Questão 3 : Problemas de Performance
O site fica lento durante promoções. Quais são as possíveis causas?
💡 Dica
Analise:
- O tipo de instância
- A separação dos componentes
- O armazenamento
Parte 2 : Correção da Arquitetura
Exercício : Propor uma Arquitetura Melhor
Redesenhe a arquitetura corrigindo os problemas identificados.
Restrições:
- Orçamento moderado (sem instâncias gigantes)
- O site deve estar disponível 99,9%
- O banco de dados deve ser seguro
- Deve suportar picos de tráfego (promoções)
Template de Resposta
Preencha este template:
NOVA ARQUITETURA PROPOSTA
=========================
Região : _____________
Zonas de Disponibilidade utilizadas : ____________
COMPONENTE 1 : Servidor(es) Web
-------------------------------
- Número de instâncias : _____
- Tipo de instância : _____
- AMI : _____
- Placement : _____
- Security Group :
- Inbound : _____
- Outbound : _____
COMPONENTE 2 : Banco de Dados
-----------------------------
- Serviço/Instância : _____
- Tipo : _____
- Placement : _____
- Security Group :
- Inbound : _____
COMPONENTE 3 : (Opcional)
-------------------------
- _____
JUSTIFICATIVAS
--------------
1. Por que este tipo de instância? _____
2. Por que esta configuração de rede? _____
3. Como você garante alta disponibilidade? _____
Parte 3 : Diagrama de Arquitetura
Exercício : Desenhar a Arquitetura
Crie um diagrama de arquitetura profissional incluindo:
Elementos obrigatórios:
- A região AWS
- Pelo menos 2 zonas de disponibilidade
- As instâncias EC2 (web)
- O banco de dados (separado)
- Os Security Groups com suas regras
- As conexões de rede
Ferramentas sugeridas:
- Draw.io (gratuito): https://app.diagrams.net/
- Lucidchart (gratuito limitado)
- PowerPoint/Google Slides
- Papel e caneta (foto a ser anexada)
Exemplo de Estrutura
┌─────────────────────────────────────────────────────────────┐
│ RÉGION : __________ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────┐ │
│ │ [Seu componente] │ │
│ └──────────────────────────────────────┘ │
│ │
│ ┌───────────────────┐ ┌───────────────────┐ │
│ │ AZ : ____ │ │ AZ : ____ │ │
│ │ │ │ │ │
│ │ [Instâncias] │ │ [Instâncias] │ │
│ │ │ │ │ │
│ └───────────────────┘ └───────────────────┘ │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ [Banco de dados] │ │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Parte 4 : Estudo de Caso - Escolha de Instâncias
Cenário A : Startup - MVP
Contexto:
- Aplicação web simples (blog + formulário de contato)
- 100 visitantes/dia esperados
- Orçamento muito limitado (< $20/mês)
- Equipe de 2 desenvolvedores
Perguntas:
1. Que tipo de instância você recomenda?
2. Qual região?
3. Quais compromissos você faz?
Cenário B : PME - Aplicação Corporativa
Contexto:
- ERP/CRM para 50 funcionários
- Banco de dados PostgreSQL (20 GB)
- Uso das 8h às 18h, segunda a sexta
- Necessidade de desempenho constante
Perguntas:
1. Que tipo de instância para a aplicação?
2. Que tipo de instância para o banco de dados?
3. É necessário usar instâncias Reserved?
Cenário C : E-Commerce - Black Friday
Contexto:
- Site e-commerce existente
- Tráfego normal: 1000 visitantes/hora
- Black Friday: 50000 visitantes/hora (pico)
- Catálogo de 10000 produtos
Perguntas:
1. Como lidar com o pico de tráfego?
2. Qual estratégia de scaling?
3. Que tipos de instâncias para cada nível de carga?
Parte 5 : Tabela Resumo das Escolhas
Complete esta tabela para cada cenário:
| Critério | Cenário A | Cenário B | Cenário C |
|---|---|---|---|
| Instância Web | |||
| Instância BDD | |||
| Modelo de preço | |||
| Número de AZ | |||
| Custo estimado/mês | |||
| Justificativa principal |
Entregáveis do Lab
Documento a ser Entregue
Crie um documento (Word, PDF ou Markdown) contendo:
1. Página de título
- Nome, data, título do lab
2. Parte 1 : Análise (20%)
- Lista de 3+ problemas de segurança
- Lista de riscos de disponibilidade
- Análise dos problemas de performance
3. Parte 2 : Correção (25%)
- Template preenchido com a nova arquitetura
- Justificativas detalhadas
4. Parte 3 : Diagrama (25%)
- Diagrama de arquitetura claro e legível
- Legenda dos componentes
- Security Groups documentados
5. Parte 4 : Estudos de Caso (20%)
- Respostas para os 3 cenários
- Justificativas das escolhas
6. Parte 5 : Tabela (10%)
- Tabela resumo preenchida
Grade de Avaliação
| Critério | Pontos |
|---|---|
| Identificação correta dos problemas | 4 |
| Arquitetura corrigida coerente | 5 |
| Diagrama claro e completo | 5 |
| Escolha de instâncias justificada | 4 |
| Tabela resumo completa | 2 |
| Total | 20 |
Correção - Parte 1 (Consulte após realizar o exercício)
📋 Ver correção
Problemas de Segurança
-
SSH aberto para todos (0.0.0.0/0)
- Risco: Ataques de força bruta
- Solução: Restringir ao IP do administrador
-
MySQL exposto publicamente (0.0.0.0/0)
- Risco: Acesso não autorizado ao banco de dados
- Solução: Fechar a porta, acesso apenas interno
-
Tudo na mesma instância
- Risco: Se a instância for comprometida, tudo está vulnerável
- Solução: Separar web e banco de dados
-
Uso do SG padrão
- Risco: Regras não auditadas
- Solução: Criar SGs específicos
Problemas de Disponibilidade
-
Apenas uma AZ
- Risco: Falha na zona = site fora do ar
- Solução: Multi-AZ
-
Instância única (SPOF)
- Risco: Falha da instância = site fora do ar
- Solução: Múltiplas instâncias + Load Balancer
-
Sem backup visível
- Risco: Perda de dados
- Solução: Snapshots EBS, RDS Multi-AZ
Problemas de Performance
-
t2.micro muito pequena
- Créditos burst acabam rapidamente
- Solução: t3.small no mínimo para produção
-
MySQL na mesma instância
- Competição por recursos
- Solução: Instância dedicada ou RDS
-
8 GB de armazenamento insuficiente
- Solução: EBS gp3, maior
Recursos para o Lab
Ícones AWS
Documentação
Calculadora de Preços
Parabéns! Você concluiu o lab de arquitetura EC2. Essas habilidades de concepção são essenciais para todo arquiteto cloud.