<h2>IAM: Controle de Acesso e Identidade na AWS</h2>
<p>O Identity and Access Management (IAM) é o alicerce da segurança em qualquer ambiente AWS. Não se trata apenas de criar usuários e senhas — é sobre implementar o princípio do menor privilégio, garantindo que cada identidade (usuário, aplicação, serviço) tenha exatamente as permissões necessárias, nem mais, nem menos. Em um cenário DevOps, você está constantemente criando integrações entre sistemas, configurando CI/CD, e delegando responsabilidades. Sem um IAM bem estruturado, você cria brechas de segurança que podem comprometer toda a infraestrutura.</p>
<p>A estrutura do IAM gira em torno de quatro componentes principais: Users (usuários), Groups (grupos), Roles (funções) e Policies (políticas). Políticas são documentos JSON que definem quais ações são permitidas ou negadas em quais recursos. Um usuário pode ser um membro humano da equipe ou uma conta de serviço para integração. Grupos agrupam usuários com permissões similares. Roles são diferentes — você não as "loga" diretamente; em vez disso, você as assume temporariamente, o que é perfeito para instâncias EC2, Lambda ou para federar identidades externas.</p>
<h3>Criando Usuários e Políticas</h3>
<p>Vamos criar um usuário IAM para um desenvolvedor que precisa de acesso específico a S3 e EC2. Usaremos a AWS CLI, que é a ferramenta padrão para automação DevOps.</p>
<pre><code class="language-bash"># Criar um usuário IAM
aws iam create-user --user-name dev-team-member
Criar uma chave de acesso para o usuário
aws iam create-access-key --user-name dev-team-member
Adicionar uma política inline ao usuário (não recomendado em produção)
aws iam put-user-policy --user-name dev-team-member --policy-name dev-s3-ec2-policy --policy-document file://policy.json</code></pre>
<p>O arquivo <code>policy.json</code> contém as permissões. Vamos ser granulares:</p>
<pre><code class="language-json">{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::meu-bucket-dev",
"arn:aws:s3:::meu-bucket-dev/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*"
}
]
}</code></pre>
<p>Este usuário pode listar e acessar objetos no S3, mas não pode deletá-los ou criar novos buckets. Na EC2, pode visualizar instâncias e iniciar/parar, mas não pode terminar ou modificar segurança. Este é o conceito de menor privilégio em ação.</p>
<h3>Roles e Assunção Temporária</h3>
<p>Em produção, você não quer credenciais de longa duração para aplicações. Use Roles. Uma instância EC2 pode assumir uma Role, recebendo credenciais temporárias via metadados. Vamos criar uma Role para uma aplicação rodar em EC2:</p>
<pre><code class="language-bash"># Criar documento de confiança (quem pode assumir a role)
cat > trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
Criar a role
aws iam create-role --role-name app-server-role --assume-role-policy-document file://trust-policy.json
Anexar política à role
aws iam put-role-policy --role-name app-server-role --policy-name app-policy --policy-document file://app-policy.json
Criar um perfil de instância (necessário para EC2)
aws iam create-instance-profile --instance-profile-name app-server-profile
aws iam add-role-to-instance-profile --instance-profile-name app-server-profile --role-name app-server-role</code></pre>
<p>Quando você lança uma EC2 com este perfil, a aplicação dentro da instância pode acessar automaticamente as credenciais via <code>http://169.254.169.254/latest/meta-data/iam/security-credentials/</code>. Ferramentas como boto3 (Python) ou SDK oficial já buscam isso automaticamente.</p>
<p>---</p>
<h2>VPC: Isolamento de Rede e Conectividade</h2>
<p>A Virtual Private Cloud (VPC) é sua rede privada na AWS. Você define o espaço de endereços IP, cria subnets, configura roteamento e controla o fluxo de tráfego. Diferente do IAM, que é global, VPCs são regionais. Em um cenário DevOps, você provavelmente terá múltiplas VPCs: uma para desenvolvimento, outra para staging, outra para produção. Isso garante isolamento de falhas e permite políticas de rede distintas.</p>
<p>A estrutura típica é: você cria uma VPC com um CIDR block (por exemplo, <code>10.0.0.0/16</code>), depois subdivide em subnets (públicas e privadas). Subnets públicas têm acesso à internet via Internet Gateway; subnets privadas se conectam via NAT Gateway. Security Groups atuam como firewalls no nível de instância, enquanto Network ACLs (NACLs) controlam tráfego no nível de subnet. Para DevOps, compreender essa estrutura é vital — você configurará ambientes isolados, definirá políticas de rede e debugará conectividade constantemente.</p>
<h3>Criando uma VPC com Subnets e Roteamento</h3>
<p>Vamos construir uma arquitetura básica: uma VPC com subnets públicas e privadas.</p>
<pre><code class="language-bash"># Criar VPC
VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 --query 'Vpc.VpcId' --output text)
echo "VPC criada: $VPC_ID"
Habilitar DNS (importante para EC2 se comunicar)
aws ec2 modify-vpc-attribute --vpc-id $VPC_ID --enable-dns-hostnames
Criar Internet Gateway
IGW_ID=$(aws ec2 create-internet-gateway --query 'InternetGateway.InternetGatewayId' --output text)
aws ec2 attach-internet-gateway --internet-gateway-id $IGW_ID --vpc-id $VPC_ID
Criar subnet pública
PUBLIC_SUBNET=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.0.1.0/24 --query 'Subnet.SubnetId' --output text)
Criar subnet privada
PRIVATE_SUBNET=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.0.2.0/24 --query 'Subnet.SubnetId' --output text)
Criar tabela de rotas para subnet pública
PUBLIC_RT=$(aws ec2 create-route-table --vpc-id $VPC_ID --query 'RouteTable.RouteTableId' --output text)
Adicionar rota padrão via Internet Gateway
aws ec2 create-route --route-table-id $PUBLIC_RT --destination-cidr-block 0.0.0.0/0 --gateway-id $IGW_ID
Associar tabela de rotas à subnet pública
aws ec2 associate-route-table --subnet-id $PUBLIC_SUBNET --route-table-id $PUBLIC_RT
echo "VPC Config:"
echo "VPC: $VPC_ID, Public Subnet: $PUBLIC_SUBNET, Private Subnet: $PRIVATE_SUBNET, IGW: $IGW_ID"</code></pre>
<p>Neste ponto, você tem uma VPC com uma subnet pública (conectada à internet) e uma privada (isolada). Instâncias na subnet pública receberão IPs públicos e poderão alcançar a internet. Instâncias na privada não têm rota para internet — elas precisariam de um NAT Gateway em uma subnet pública para iniciar conexões de saída.</p>
<h3>Security Groups: Firewall de Aplicação</h3>
<p>Security Groups controlam tráfego de entrada e saída. Ao contrário de NACLs (que são stateless), Security Groups são stateful — se você permite tráfego de entrada, a resposta é automaticamente permitida. Vamos criar um Security Group para um servidor web:</p>
<pre><code class="language-bash"># Criar Security Group
SG_ID=$(aws ec2 create-security-group --group-name web-sg --description "Security group para servidores web" --vpc-id $VPC_ID --query 'GroupId' --output text)
Permitir HTTP de qualquer lugar
aws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 80 --cidr 0.0.0.0/0
Permitir HTTPS de qualquer lugar
aws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 443 --cidr 0.0.0.0/0
Permitir SSH apenas de um IP específico (seu escritório, por exemplo)
aws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 22 --cidr 203.0.113.0/32
Permitir tráfego de saída (padrão já permite tudo, mas vamos ser explícito)
aws ec2 authorize-security-group-egress --group-id $SG_ID --protocol tcp --port 443 --cidr 0.0.0.0/0
echo "Security Group criado: $SG_ID"</code></pre>
<p>Observe que limitamos SSH a um IP específico. Em produção, você pode usar um bastion host ou Systems Manager Session Manager em vez de SSH direto. Este é um princípio DevOps: minimize exposição desnecessária.</p>
<p>---</p>
<h2>EC2: Compute na Prática</h2>
<p>EC2 (Elastic Compute Cloud) é a máquina virtual da AWS. Em DevOps, você usa EC2 para rodar aplicações, servidores web, bancos de dados ou qualquer carga de trabalho computacional. O termo "instância" refere-se a um servidor EC2 rodando. Você escolhe o tipo de instância (t3.micro, m5.large, etc.), o sistema operacional (AMI), o armazenamento, a rede e permissões de acesso. Automatizar o provisionamento de EC2 é um pilar de DevOps — você fará isso via scripts, Terraform, CloudFormation ou ferramentas de orquestração.</p>
<p>Existem diferentes formas de lançar EC2: on-demand (pague por hora), reserved (compromisso de 1-3 anos com desconto), spot (oferta de preço mais baixo, mas pode ser interrompida). Para desenvolvimento, on-demand é comum. Para produção, você mistura reserved (baseline previsível) com on-demand ou spot (para picos). Vamos lançar uma instância on-demand e configurá-la como servidor web com um script de inicialização.</p>
<h3>Lançando uma Instância EC2</h3>
<pre><code class="language-bash"># Buscar a AMI mais recente do Ubuntu 22.04
AMI_ID=$(aws ec2 describe-images \
--owners 099720109477 \
--filters "Name=name,Values=ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*" \
--query 'sort_by(Images, &CreationDate)[-1].ImageId' \
--output text)
echo "Usando AMI: $AMI_ID"
Criar um par de chaves para acesso SSH (se não existir)
aws ec2 create-key-pair --key-name my-key-pair --query 'KeyMaterial' --output text > my-key-pair.pem
chmod 400 my-key-pair.pem
Script de inicialização (user data)
cat > user-data.sh << 'EOF'
#!/bin/bash
set -e
Atualizar pacotes
apt-get update
apt-get install -y nginx
Iniciar nginx
systemctl start nginx
systemctl enable nginx
Criar página HTML simples
cat > /var/www/html/index.html << 'HTML'
<!DOCTYPE html>
<html>
<head><title>Welcome</title></head>
<body>
<h1>Servidor rodando na AWS!</h1>
<p>Hostname: $(hostname)</p>
</body>
</html>
HTML
EOF
Lançar instância
INSTANCE_ID=$(aws ec2 run-instances \
--image-id $AMI_ID \
--instance-type t3.micro \
--key-name my-key-pair \
--security-group-ids $SG_ID \
--subnet-id $PUBLIC_SUBNET \
--associate-public-ip-address \
--iam-instance-profile Name=app-server-profile \
--user-data file://user-data.sh \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-server-1}]' \
--query 'Instances[0].InstanceId' \
--output text)
echo "Instância lançada: $INSTANCE_ID"
Aguardar que a instância esteja rodando
aws ec2 wait instance-running --instance-ids $INSTANCE_ID
echo "Instância está rodando"
Obter o IP público
PUBLIC_IP=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].PublicIpAddress' --output text)
echo "IP Público: $PUBLIC_IP"
echo "Acesse: http://$PUBLIC_IP"</code></pre>
<p>Este script faz várias coisas importantes:</p>
<ol>
<li><strong>Busca a AMI mais recente</strong>: Isso evita hard-coding IDs que mudam com o tempo.</li>
<li><strong>Cria um par de chaves</strong>: SSH é o padrão para acessar instâncias Linux.</li>
<li><strong>Define user data</strong>: O script é executado na primeira inicialização, instalando e configurando nginx.</li>
<li><strong>Associa a Role IAM</strong>: A instância herda permissões automaticamente.</li>
<li><strong>Lança com tag</strong>: Facilita identificação e automação posterior.</li>
</ol>
<h3>Monitorando e Terminando Instâncias</h3>
<pre><code class="language-bash"># Descrever instâncias (filtrar por tag)
aws ec2 describe-instances \
--filters "Name=tag:Name,Values=web-server-1" "Name=instance-state-name,Values=running" \
--query 'Reservations[0].Instances[0].[InstanceId,InstanceType,PublicIpAddress,State.Name]' \
--output table
Parar instância (dados preservados, mas para de faturar)
aws ec2 stop-instances --instance-ids $INSTANCE_ID
Iniciar novamente
aws ec2 start-instances --instance-ids $INSTANCE_ID
Terminar instância (destruir permanentemente)
aws ec2 terminate-instances --instance-ids $INSTANCE_ID
Aguardar término
aws ec2 wait instance-terminated --instance-ids $INSTANCE_ID</code></pre>
<p>Um ponto crucial: parar não é o mesmo que terminar. Stop preserva o volume EBS e a configuração; você paga apenas pelo armazenamento. Terminate destrói a instância e seus volumes (a menos que você configure para preservar). Em desenvolvimento, você frequently para/inicia para economizar. Em produção, use Auto Scaling Groups para gerenciar frota de instâncias automaticamente.</p>
<p>---</p>
<h2>S3: Armazenamento de Objetos e Distribuição</h2>
<p>S3 (Simple Storage Service) é o serviço de armazenamento de objetos da AWS. É imutável, durável e altamente escalável. Você armazena dados em "buckets" (contêineres) organizados em "chaves" (caminho do arquivo). Diferente de um sistema de arquivos, S3 é um storage chave-valor — não há conceito de diretórios, apenas prefixos nas chaves que simulam hierarquia. Para DevOps, S3 é ubíquo: você o usa para backups, armazenar logs, distribuir assets de aplicações, hospedar sites estáticos e integrar com pipelines CI/CD.</p>
<p>S3 oferece vários recursos poderosos: versionamento (manter histórico de objetos), encryption (criptografia em repouso), lifecycle policies (expirar ou arquivar dados automaticamente), e access logging. Você controla quem acessa via políticas de bucket e ACLs. Para DevOps, é essencial entender como aplicações acessam S3 (via SDK), como integrar com CI/CD (armazenar artefatos), e como estruturar buckets para escalabilidade e segurança.</p>
<h3>Criando Buckets e Configurando Acesso</h3>
<pre><code class="language-bash"># Criar bucket (nomes são globalmente únicos)
BUCKET_NAME="meu-app-bucket-$(date +%s)"
aws s3 mb s3://$BUCKET_NAME --region us-east-1
Habilitar versionamento
aws s3api put-bucket-versioning --bucket $BUCKET_NAME --versioning-configuration Status=Enabled
Habilitar encryption por padrão
aws s3api put-bucket-encryption --bucket $BUCKET_NAME --server-side-encryption-configuration '{
"Rules": [
{
"ApplyServerSideEncryptionByDefault": {
"SSEAlgorithm": "AES256"
}
}
]
}'
Bloquear acesso público (segurança padrão)
aws s3api put-public-access-block --bucket $BUCKET_NAME --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
Habilitar logging de acesso
aws s3api put-bucket-logging --bucket $BUCKET_NAME --bucket-logging-status '{
"LoggingEnabled": {
"TargetBucket": "'$BUCKET_NAME'",
"TargetPrefix": "logs/"
}
}'
echo "Bucket criado: $BUCKET_NAME"</code></pre>
<p>Este bucket agora é hardened: versionado, criptografado, inacessível publicamente e com logging. Qualquer acesso é rastreado. Próximo passo: adicionar uma política de ciclo de vida.</p>
<h3>Lifecycle Policies e Gerenciamento de Dados</h3>
<pre><code class="language-bash"># Criar política que move objetos antigos para Glacier (mais barato)
aws s3api put-bucket-lifecycle-configuration --bucket $BUCKET_NAME --lifecycle-configuration '{
"Rules": [
{
"Id": "ArchiveRule",
"Filter": {"Prefix": "backups/"},
"Status": "Enabled",
"Transitions": [
{
"Days": 30,
"StorageClass": "GLACIER"
}
],
"Expiration": {
"Days": 365
}
}
]
}'
Fazer upload de arquivo
aws s3 cp /path/to/file.txt s3://$BUCKET_NAME/backups/file-$(date +%Y%m%d).txt
Listar objetos
aws s3 ls s3://$BUCKET_NAME/ --recursive
Baixar arquivo
aws s3 cp s3://$BUCKET_NAME/backups/file-20240101.txt ./
Deletar arquivo
aws s3 rm s3://$BUCKET_NAME/backups/file-20240101.txt</code></pre>
<p>Esta política diz: "Objetos no prefixo <code>backups/</code> são movidos para Glacier após 30 dias (muito mais barato que S3 padrão) e deletados após um ano." Isso reduz custos automaticamente. Glacier é ideal para dados que você precisa manter por conformidade, mas não acessa frequentemente.</p>
<h3>Integrando S3 com Aplicações via SDK</h3>
<p>Vamos escrever um script Python que sua aplicação pode usar para armazenar e recuperar dados:</p>
<pre><code class="language-python">import boto3
import json
from datetime import datetime
Cliente S3
s3_client = boto3.client('s3')
BUCKET_NAME = 'meu-app-bucket-1234567890'
def upload_log(app_name, log_data):
"""
Fazer upload de log estruturado para S3.
A instância EC2 com a Role adequada faz isso automaticamente.
"""
key = f"logs/{app_name}/{datetime.utcnow().isoformat()}.json"
try:
s3_client.put_object(
Bucket=BUCKET_NAME,
Key=key,
Body=json.dumps(log_data),
ContentType='application/json'
)
print(f"Log salvo em s3://{BUCKET_NAME}/{key}")
return True
except Exception as e:
print(f"Erro ao fazer upload: {e}")
return False
def list_logs(app_name):
"""Listar todos os logs de uma aplicação."""
prefix = f"logs/{app_name}/"
try:
response = s3_client.list_objects_v2(
Bucket=BUCKET_NAME,
Prefix=prefix,
MaxKeys=10
)
if 'Contents' in response:
for obj in response['Contents']:
print(f" {obj['Key']} ({obj['Size']} bytes, {obj['LastModified']})")
else:
print("Nenhum log encontrado.")
except Exception as e:
print(f"Erro ao listar: {e}")
def get_log(key):
"""Baixar e parsear um log específico."""
try:
response = s3_client.get_object(Bucket=BUCKET_NAME, Key=key)
body = response['Body'].read().decode('utf-8')
return json.loads(body)
except Exception as e:
print(f"Erro ao baixar: {e}")
return None
Exemplo de uso
if __name__ == "__main__":
log_entry = {
"level": "INFO",
"message": "Aplicação iniciada",
"timestamp": datetime.utcnow().isoformat()
}
upload_log("my-app", log_entry)
list_logs("my-app")</code></pre>
<p>Execute isso dentro de uma instância EC2 com a Role <code>app-server-role</code> (que você criou na seção de IAM) e funcionará seamlessly — nenhuma credencial hardcoded necessária. O SDK boto3 detecta automaticamente as credenciais via metadados da instância.</p>
<h3>Hosting de Conteúdo Estático</h3>
<p>S3 pode servir websites estáticos diretamente. Vamos configurar um site:</p>
<pre><code class="language-bash"># Criar bucket para website
WEBSITE_BUCKET="meu-site-$(date +%s)"
aws s3 mb s3://$WEBSITE_BUCKET
Criar arquivo index.html
cat > index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Meu Site</title>
</head>
<body>
<h1>Site hospedado no S3</h1>
<p>Sem servidores, sem pagar por EC2!</p>
</body>
</html>
EOF
Upload
aws s3 cp index.html s3://$WEBSITE_BUCKET/
Habilitar website estático
aws s3api put-bucket-website --bucket $WEBSITE_BUCKET --website-configuration '{
"IndexDocument": {
"Suffix": "index.html"
},
"ErrorDocument": {
"Key": "error.html"
}
}'
Tornar público (cuidado! Só faça se quiser que seja público)
aws s3api put-bucket-policy --bucket $WEBSITE_BUCKET --policy '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicRead",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::'"$WEBSITE_BUCKET"'/*"
}
]
}'
URL do website
echo "Site disponível em: http://$WEBSITE_BUCKET.s3-website-us-east-1.amazonaws.com"</code></pre>
<p>O site agora está rodando. Para melhorar performance, você adicionar CloudFront (CDN) na frente, mas isso está fora do escopo deste artigo.</p>
<p>---</p>
<h2>Conclusão</h2>
<p>Ao longo deste artigo, você aprendeu os quatro pilares de uma infraestrutura AWS funcional em DevOps:</p>
<ol>
<li><strong>IAM garante segurança via princípio do menor privilégio</strong>: Você cria usuários, grupos e roles com permissões granulares. Roles são essenciais para aplicações — evite credenciais hardcoded. Sempre use políticas JSON bem estruturadas e revise regularmente quem tem acesso a quê.</li>
</ol>
<ol>
<li><strong>VPC fornece isolamento de rede e controle de fluxo</strong>: Uma VPC bem desenhada possui subnets públicas (com internet) e privadas (isoladas), Security Groups como firewall de aplicação, e NACLs para controle mais fino. Em produção, você terá VPCs separadas por ambiente. Debugar conectividade é comum — entenda Security Groups e tabelas de rotas.</li>
</ol>
<ol>
<li><strong>EC2 é compute sob demanda</strong>: Lance instâncias com user data para automação, use Roles IAM para evitar credenciais, e integre com Auto Scaling para escalabilidade. Sempre use AMIs versionadas ou buildadas por você para reprodutibilidade. Em DevOps, você automatixa provisionamento via scripts, Terraform ou ferramentas de orquestração.</li>
</ol>
<ol>
<li><strong>S3 é armazenamento universal</strong>: Use para backups, logs, artefatos de build e até websites estáticos. Configure versionamento, encryption e lifecycle policies automaticamente. Integrações com SDK são simples quando você tem Roles IAM corretas. S3 é barato em escala — é sua ferramenta de primeira escolha para persistência.</li>
</ol>
<p>Estes quatro serviços compõem a base de praticamente toda arquitetura AWS moderna. Combine-os: EC2 em VPCs roda aplicações que acessam S3 e são gerenciadas via IAM. Pratique com este artigo, crie ambientes de teste, break things — é assim que você desenvolve intuição real.</p>
<p>---</p>
<h2>Referências</h2>
<ul>
<li><a href="https://docs.aws.amazon.com/iam/" target="_blank" rel="noopener noreferrer">AWS IAM Documentation</a></li>
<li><a href="https://docs.aws.amazon.com/vpc/" target="_blank" rel="noopener noreferrer">AWS VPC User Guide</a></li>
<li><a href="https://docs.aws.amazon.com/ec2/" target="_blank" rel="noopener noreferrer">AWS EC2 User Guide</a></li>
<li><a href="https://docs.aws.amazon.com/s3/" target="_blank" rel="noopener noreferrer">AWS S3 User Guide</a></li>
<li><a href="https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html" target="_blank" rel="noopener noreferrer">AWS Well-Architected Framework - Security Pillar</a></li>
</ul>
<p><!-- FIM --></p>