Deploy de aplicação

Existem vários caminhos para subir um backend na AWS. Vamos do mais simples e manual ao mais sofisticado e automatizado.

Caminho 1 — SSH na EC2 (cru e direto)

Funciona para aprender e para projetos pequenos. Você sobe uma EC2, conecta via SSH, instala dependências e roda sua aplicação.

# 1. Conectar na EC2
ssh -i key.pem ubuntu@<PUBLIC-IP>
 
# 2. Fazer o upload do binário Go (compilado localmente para linux/amd64)
# Em outra aba do terminal, na sua máquina:
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o api .
scp -i key.pem ./api ubuntu@<PUBLIC-IP>:/opt/api
 
# 3. Na EC2: tornar executável e criar serviço systemd
chmod +x /opt/api
 
cat > /etc/systemd/system/api.service <<EOF
[Unit]
Description=API Service
After=network.target
 
[Service]
ExecStart=/opt/api
Restart=always
RestartSec=5s
 
[Install]
WantedBy=multi-user.target
EOF
 
systemctl enable --now api

Caminho 2 — Elastic Beanstalk (PaaS)

O Elastic Beanstalk é um "deploy fácil" da AWS. Você empacota sua aplicação em um zip, faz upload, e o Beanstalk provisiona EC2, ALB, Auto Scaling e CloudWatch automaticamente.

# Instalar o EB CLI
pip install awsebcli
 
# Inicializar projeto (Go platform)
eb init -p go-1.x minha-api --region sa-east-1
 
# Criar ambiente de produção
eb create prod-env
 
# Subir nova versão
eb deploy

Em poucos minutos, sua API está no ar com Load Balancer, Auto Scaling e logs configurados.

Caminho 3 — Containers (ECS / EKS)

Hoje em dia, a maioria dos backends roda em containers Docker. A AWS oferece dois serviços:

• ECS (Elastic Container Service): orquestrador próprio da AWS, mais simples de aprender.
• EKS (Elastic Kubernetes Service): Kubernetes gerenciado. Padrão da indústria, mas mais complexo.

Ambos podem rodar em modo Fargate (serverless — você não gerencia EC2) ou em modo EC2 (você gerencia o cluster).

Fluxo típico com ECS Fargate

1. Você escreve um Dockerfile da aplicação
2. Faz build da imagem e envia para o ECR (registry de containers da AWS)
3. Cria uma Task Definition ("como rodar 1 instância da minha app")
4. Cria um Service ECS ("sempre mantenha 3 tasks rodando, atrás desse ALB")
5. Cada deploy = build da imagem + update do service

# Dockerfile para uma API Go com multi-stage build
FROM golang:1.26-alpine AS builder
WORKDIR /build
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o server .
 
FROM alpine:3.19
RUN adduser -D -u 1000 appuser
USER appuser
WORKDIR /app
COPY --from=builder /build/server .
EXPOSE 8080
CMD ["./server"]

Caminho 4 — Serverless (Lambda + API Gateway)

Para casos onde sua API tem tráfego intermitente, você paga só pelas requisições (e não pela máquina rodando 24/7), e não quer gerenciar nem container.

Você escreve uma função, configura o API Gateway na frente, e cada requisição HTTP invoca uma execução da Lambda. Escala de 0 a milhares de execuções paralelas automaticamente.

// main.go — Lambda em Go usando aws-lambda-go
package main
 
import (
    "context"
    "encoding/json"
 
    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
)
 
func handler(ctx context.Context, req events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    id := req.PathParameters["id"]
    product, err := db.GetProduct(ctx, id)
    if err != nil {
        return events.APIGatewayProxyResponse{StatusCode: 500}, err
    }
    body, _ := json.Marshal(product)
    return events.APIGatewayProxyResponse{StatusCode: 200, Body: string(body)}, nil
}
 
func main() {
    lambda.Start(handler)
}

Comparativo — Qual caminho escolher?

CI/CD — Automatizando o deploy

Em qualquer modelo sério, você não faz deploy manual. Configura uma pipeline que faz build, testes, e deploy automaticamente a cada push.

Serviços AWS para isso: CodeCommit (git), CodeBuild (CI), CodeDeploy (CD) e CodePipeline (orquestrador). Mas o padrão da indústria hoje é usar GitHub + GitHub Actions, ou GitLab CI, e o pipeline sai chamando a AWS.