AWS básico: Region, IAM e serviços principais

1. Visão geral

Este artigo ajuda você a dominar rapidamente os três pilares mais importantes quando está começando com AWS: region (escolher onde a infraestrutura fica), IAM (quem pode fazer o quê) e os serviços principais (EC2, S3, RDS, Lambda, VPC…). Depois de ler, você vai entender como organizar uma conta AWS com segurança, saber criar IAM role para sua aplicação e escrever código Java que chama S3 usando AWS SDK v2.

2. Region e Availability Zone

AWS divide a infraestrutura em regions (áreas geográficas, por exemplo ap-southeast-1 em Singapura) e cada region possui múltiplas Availability Zones (AZ) — data centers independentes em termos de energia e rede, localizados perto uns dos outros para baixa latência mas ainda isolados em caso de falhas.

aws ec2 describe-availability-zones --region ap-southeast-1

Este comando lista as AZ na região de Singapura. O resultado geralmente tem o seguinte formato:

ZoneName: ap-southeast-1a
ZoneName: ap-southeast-1b
ZoneName: ap-southeast-1c

Ao projetar um sistema, você deve implantar em pelo menos 2 AZ para tolerância a falhas (alta disponibilidade). Por exemplo, um Auto Scaling Group ou uma instância RDS Multi-AZ seguem esse princípio.

Observação: Alguns serviços são globais (não ligados a uma region específica) como IAM, Route 53 e CloudFront. A maioria dos outros serviços (EC2, S3, RDS…) são regionais — os dados não se replicam automaticamente para outras regions a menos que você configure.

2.1. Como escolher uma region

Três critérios principais: latência (estar perto dos usuários), compliance (requisitos de manter dados no país) e custo (o preço dos serviços varia entre regions). Para usuários no Vietnã, ap-southeast-1 (Singapura) costuma ser a escolha padrão por baixa latência e serviços completos.

3. IAM: User, Group, Role, Policy

IAM (Identity and Access Management) controla quem pode acessar quais recursos. Quatro conceitos essenciais:

• User: uma identidade específica (pessoa ou serviço) com credenciais próprias.
• Group: conjunto de usuários, com policies comuns anexadas para facilitar a gestão.
• Role: conjunto de permissões temporárias, sem credenciais fixas — usado para EC2, Lambda ou acesso entre contas.
• Policy: documento JSON que descreve permissões (allow/deny) em ações e recursos.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::order-invoices-bucket/*"
    }
  ]
}

Esta policy permite ler/escrever objetos no bucket order-invoices-bucket. Anexe a policy a uma role e depois associe essa role à instância EC2 ou função Lambda que roda o serviço InvoiceStorageService — a aplicação terá automaticamente as permissões sem precisar hard-code de access key/secret key.

aws iam create-role \
  --role-name InvoiceServiceRole \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name InvoiceServiceRole \
  --policy-arn arn:aws:iam::123456789012:policy/InvoiceBucketAccess

O primeiro comando cria a role com trust-policy.json definindo quem pode “assumir” essa role (por exemplo, o serviço EC2). O segundo comando anexa a policy de permissões específicas à role.

Observação: Nunca coloque access key/secret key direto no código ou commit no Git. Use IAM Role (para recursos rodando na AWS) ou IAM Identity Center/SSO (para usuários).

3.1. Princípio do menor privilégio

Conceda apenas as permissões necessárias, não use AdministratorAccess para contas de serviço. Por exemplo, uma Lambda que apenas lê um bucket não deve receber s3:* em toda a conta.

{
  "Effect": "Deny",
  "Action": "s3:DeleteBucket",
  "Resource": "*"
}

Uma statement Deny sempre tem prioridade sobre Allow em caso de conflito — é uma forma de adicionar uma “rede de segurança” contra exclusão acidental de buckets importantes.

4. Serviços principais

4.1. Compute

• EC2: máquina virtual alugada por hora/segundo, você gerencia o SO.
• Lambda: executa código por evento (event-driven), sem gerenciar servidor, cobrança por invocações e tempo de execução.
• ECS/EKS: executa containers (Docker) com orchestration.

aws lambda invoke \
  --function-name CalculateOrderTotal \
  --payload '{"orderId":"ORD-1001"}' \
  response.json

Este comando invoca a função CalculateOrderTotal com payload JSON, o resultado é escrito em response.json.

4.2. Storage

• S3: object storage, armazena qualquer arquivo (imagens, logs, backups), durabilidade de 99.999999999%.
• EBS: disco em bloco anexado à EC2.
• EFS: sistema de arquivos compartilhado que pode ser montado por múltiplas EC2.

4.3. Database

• RDS: banco de dados relacional gerenciado (MySQL, PostgreSQL…), backup automático, patching.
• DynamoDB: NoSQL, dimensionamento horizontal automático, latência em poucos milissegundos.

4.4. Network

• VPC: rede virtual privada, você define subnets, route tables, security groups.
• Security Group: firewall stateful no nível da instância.

Resources:
  OrderServiceSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow HTTPS inbound
      VpcId: vpc-0123456789abcdef0
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0

Este trecho CloudFormation cria um Security Group chamado OrderServiceSG, abrindo apenas a porta 443 (HTTPS) para qualquer IP — as demais regras inbound são negadas por padrão.

5. Chamando S3 de uma aplicação Java

Esta seção mostra como um serviço Spring Boot faz upload de arquivo para S3 usando AWS SDK for Java v2.

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>s3</artifactId>
    <version>2.25.16</version>
</dependency>

public class InvoiceStorageService {

    private final S3Client s3Client;
    private final String bucketName;

    public InvoiceStorageService(S3Client s3Client, String bucketName) {
        this.s3Client = s3Client;
        this.bucketName = bucketName;
    }

    public void uploadInvoice(String orderId, byte[] content) {
        PutObjectRequest request = PutObjectRequest.builder()
                .bucket(bucketName)
                .key("invoices/" + orderId + ".pdf")
                .build();

        s3Client.putObject(request, RequestBody.fromBytes(content));
    }
}

S3Client é injetado no construtor (pega credenciais automaticamente da IAM Role se rodando em EC2/Lambda, sem precisar hard-code). O método uploadInvoice cria um PutObjectRequest com key sendo o caminho do objeto no bucket, então chama putObject para enviar o conteúdo para S3.

Configuração do bean S3Client:

@Bean
public S3Client s3Client() {
    return S3Client.builder()
            .region(Region.AP_SOUTHEAST_1)
            .build();
}

Não é preciso passar credentialsProvider explicitamente — o SDK usa a Default Credentials Provider Chain: procura por ordem em variáveis de ambiente, arquivo ~/.aws/credentials, depois IAM Role anexada à EC2/ECS/Lambda.

5.1. Testando com mock S3Client

@Test
void shouldCallPutObjectWithCorrectKey() {
    S3Client mockS3 = mock(S3Client.class);
    InvoiceStorageService service = new InvoiceStorageService(mockS3, "order-invoices-bucket");

    service.uploadInvoice("ORD-1001", "conteúdo da nota fiscal".getBytes());

    ArgumentCaptor<PutObjectRequest> captor = ArgumentCaptor.forClass(PutObjectRequest.class);
    verify(mockS3).putObject(captor.capture(), any(RequestBody.class));

    assertThat(captor.getValue().bucket()).isEqualTo("order-invoices-bucket");
    assertThat(captor.getValue().key()).isEqualTo("invoices/ORD-1001.pdf");
}

O teste faz mock de S3Client (usando Mockito) para evitar chamar a AWS real durante CI. ArgumentCaptor captura o PutObjectRequest que foi realmente enviado, depois AssertJ verifica se bucket e key estão corretos — garante que a lógica de construir a request não está errada sem gastar largura de banda ou risco de dados.

Observação: Para testes de integração real com S3, use bibliotecas como LocalStack ou Testcontainers em vez de chamar um bucket real em produção — evita custos de rede e riscos aos dados.

6. Erros comuns

• Deixar bucket S3 público por acidente: sempre ative “Block Public Access” no nível da conta a menos que realmente precise de um bucket público (por exemplo, website estático).
• Anexar policy muito ampla ("Action": "*", "Resource": "*") para uma role de teste e esquecer de remover quando vai para produção.
• Não ativar MFA para a conta root: a conta root tem permissão total, perder acesso à root é o risco mais sério.
• Hard-code access key no código: use IAM Role, Secrets Manager ou variáveis de ambiente via secret do CI/CD.
• Escolher region errada causando alta latência para usuários finais ou violando requisitos de residência de dados.

7. Conclusão

Region ajuda você a escolher o local correto da infraestrutura equilibrando latência, custo e conformidade. IAM é a primeira e mais importante camada de proteção — sempre aplique o menor privilégio e prefira Role em vez de access key estática. Dominar o conjunto de serviços principais (EC2, S3, RDS, Lambda, VPC) junto com como integrá-los via AWS SDK é conhecimento suficiente para você começar a implantar um sistema real na AWS.