DEV Community: Giovana Costa

Como foi minha preparação para a AWS Certified Developer – Associate

Giovana Costa — Thu, 02 Jul 2026 19:56:43 +0000

Fala pessoal!

Na última segunda-feira (29/06) conquistei a certificação AWS Certified Developer – Associate (DVA-C02)! 🎉

AWS Certified Developer – Associate - Credly

Earners of this certification have a comprehensive understanding of application life-cycle management. They demonstrated proficiency in writing applications with AWS service APIs, AWS CLI, and SDKs; using containers; and deploying with a CI/CD pipeline. Badge owners are able to develop, deploy, and debug cloud-based applications that follow AWS best practices.

credly.com

Mais do que compartilhar a aprovação, gostaria de contar um pouco sobre como foi minha preparação, quais estratégias funcionaram para mim e o que senti de diferente nesta certificação em comparação às que já conquistei anteriormente.

Espero que esse relato possa ajudar quem está pensando em tirar essa certificação.

Um desafio particular

Mesmo trabalhando diariamente com AWS, quando eu comecei a ler o guia oficial da certificação me deparei com alguns serviços que estavam fora da minha rotina de atuação e outros que estavam completamente fora da minha zona de conforto.

Foi aí que eu percebi que essa certificação seria diferente das anteriores. A partir disso compreendi também que além de entender a parte teórica do exame, precisaria buscar também aplicar laboratórios que me ajudassem a entender qual problema cada serviço resolvia e em quais cenários fazia sentido utilizá-lo. Essa abordagem mudou completamente minha forma de estudar e fez com que vários conceitos passassem a fazer muito mais sentido.

Como organizei meus estudos

Minha preparação foi baseada em quatro pilares:

📚 Estudo da documentação oficial da AWS e cursos
📝 Simulados
🧪 Laboratórios práticos
🤔 Entender o motivo de cada resposta

Sempre que eu errava uma questão, tentava responder perguntas como:

Por que essa alternativa é a correta?
Em qual cenário eu realmente utilizaria esse serviço?
Qual problema esse recurso resolve?
Quais são as limitações?

Essa mudança de mentalidade fez muita diferença.

O que mais foquei em estudar

Os serviços que mais revisei durante a preparação foram:

Lambda
API Gateway
DynamoDB
AWS SAM
Estratégias de deployment (Blue/Green, Canary, Linear e In-Place)
CloudFormation
Cognito

Mas o mais importante não foi decorar funcionalidades, e sim entender quando utilizar cada um e o que cada um deles resolve.

O que achei da prova

Sem entrar em detalhes específicos das questões, minha percepção foi que a prova avalia muito mais a capacidade de tomar decisões do que decorar comandos.

Em muitos momentos eu precisava responder perguntas como:

Qual solução exige menos esforço operacional?
Qual serviço foi criado exatamente para resolver esse problema?
Qual alternativa segue as boas práticas da AWS?

Outro ponto que achei interessante é que diversas questões envolvem integração entre serviços, e não apenas conhecimento isolado de um único serviço.

Algumas dicas para quem vai fazer a certificação

✅ Não tente decorar respostas.

✅ Entenda o propósito de cada serviço.

✅ Faça muitos simulados.

✅ Revise os erros até entender o motivo da resposta correta.

✅ Estude comparando serviços parecidos.

Por exemplo:

SQS × SNS × EventBridge
Parameter Store × Secrets Manager
CloudFormation × SAM
Cognito User Pool × Identity Pool
Redis × Memcached
Blue/Green × In-place Deployment

Essas comparações ajudam a entender não apenas como utilizar um serviço, mas principalmente quando utilizá-lo.

Materiais que me ajudaram

Ao longo da preparação, alguns materiais contribuíram bastante para o meu aprendizado. Vou deixar abaixo os que mais utilizei e recomendo:

1°. Guia oficial da certificação

Na minha opinião, este é o primeiro e o principal material que qualquer pessoa deveria consultar antes de iniciar a preparação. O guia oficial da AWS apresenta os domínios cobrados na prova, as competências esperadas e o escopo do exame, ajudando a direcionar os estudos para os assuntos que realmente importam.

https://aws.amazon.com/certification/certified-developer-associate/

2. Ultimate AWS Certified Developer Associate 2026 DVA-C02 (Udemy)

O curso do Stephane Maarek foi um dos principais guias da minha preparação. Além da excelente didática para explicar os conceitos, um dos pontos que mais gostei foi a quantidade de laboratórios práticos (hands-on). Eles me permitiram recriar os mesmos cenários no meu próprio sandbox AWS, fazendo com que eu pudesse aplicar os conhecimentos daquela sessão.

https://www.udemy.com/course/aws-certified-developer-associate-dva-c01/?couponCode=UDEAFFHP22025

3. Simulados (Udemy)

Os simulados foram fundamentais para avaliar minha evolução ao longo da preparação. Cada revisão de questão e explicação das alternativas corretas e incorretas contribuiu para o meu aprendizado aquele ditado: "É errando que se aprende". Fez bastante sentido durante essa jornada 😄.

Além disso, os simulados me ajudaram a treinar o gerenciamento do tempo, a manter o ritmo durante uma prova longa e a me familiarizar com o estilo das questões.

https://www.udemy.com/course/aws-certified-developer-associate-practice-tests-dva-c01/?couponCode=UDEAFFHP22025

Além disso, algo novo que fez bastante diferença na minha preparação foi utilizar ferramentas de IA como um parceiro de estudos. Eu as utilizava para esclarecer dúvidas, comparar serviços, revisar conceitos e testar meus conhecimentos com perguntas e cenários práticos. Isso acelerou bastante meu aprendizado e me ajudou a consolidar o conteúdo.

Próximos passos

Essa certificação representa um marco importante na minha jornada, como comentei no início, foi um desafio que exigiu muita dedicação e consistência. No final, todo o esforço valeu a pena, principalmente por ter me tirado da minha zona de conforto.

Que venham os próximos desafios!

Obrigado a todos que, de alguma forma, fizeram parte dessa jornada.

Agradeço você que leu até aqui! Espero que minha experiência possa, de alguma forma, ajudar na sua preparação.

Se você está se preparando para a DVA-C02, desejo uma excelente prova e boa sorte no processo! 🚀

PrivateLink na prática: como acessar serviços privados em outra VPC sem VPC Peering

Giovana Costa — Tue, 30 Jun 2026 02:38:42 +0000

Quando começamos a trabalhar com conectividade na AWS, é comum pensar em soluções como VPC Peering, Transit Gateway ou até exposição pública via Load Balancer. Mas nem sempre o objetivo é conectar redes inteiras.

Às vezes, o que precisamos é muito mais específico: permitir que uma aplicação em uma VPC consuma um serviço privado que está em outra VPC, sem expor esse serviço na internet e sem criar roteamento amplo entre os ambientes.

É exatamente nesse cenário que o AWS PrivateLink se encaixa muito bem.

Neste artigo, vamos entender o conceito e montar um lab simples para acessar uma aplicação privada em uma VPC Provider a partir de uma VPC Consumer usando PrivateLink.

Para esse laboratório imagine o seguinte cenário:

uma aplicação interna (nginx) roda em uma VPC;
outra VPC precisa consumir essa aplicação;
você não quer expor a aplicação na internet;
você também não quer conectar as duas VPCs inteiras com Peering ou Transit Gateway.

Uma forma comum de resolver isso seria criar conectividade entre as VPCs, ajustar rotas, Security Groups e garantir que os CIDRs não tenham sobreposição.

Mas e se o objetivo for expor apenas um serviço específico?

Nesse caso, o AWS PrivateLink pode ser uma opção mais segura e controlada.

O que é AWS PrivateLink?

O AWS PrivateLink permite criar conectividade privada entre um consumidor e um serviço usando endpoints privados dentro da VPC.

Na prática, ele permite que uma VPC acesse um serviço publicado em outra VPC sem precisar expor isso publicamente.

Um ponto importante é que o PrivateLink não conecta duas redes inteiras. Ele conecta um consumidor a um serviço específico.

PrivateLink é ideal quando você quer compartilhar um serviço, não uma rede inteira.

Quando usar PrivateLink?

Você pode considerar o uso de PrivateLink quando precisar:

expor uma API interna para outra VPC;
consumir um serviço privado de outra conta AWS;
evitar exposição pública via internet;
evitar VPC Peering apenas para acessar um serviço;
não compartilhar rotas entre redes;
criar um modelo provider/consumer entre times, contas ou ambientes.

Arquitetura do lab

Neste lab, teremos duas VPCs:

VPC Provider: onde a aplicação privada estará rodando;
VPC Consumer: de onde vamos consumir a aplicação privada.

A arquitetura será a seguinte:

Fluxo da comunicação:


EC2 Consumer -> Interface Endpoint -> AWS PrivateLink -> NLB interno -> EC2 Provider com Nginx

O objetivo é provar que a EC2 da VPC Consumer consegue acessar uma aplicação privada na VPC Provider sem internet pública e sem peering entre as VPCs.

Componentes do lab

Vamos criar os seguintes recursos:

VPC Provider

VPC 10.10.0.0/16
Subnet privada 10.10.1.0/24
EC2 com Nginx
Network Load Balancer interno
Endpoint Service

VPC Consumer

VPC 10.20.0.0/16
Subnet privada 10.20.1.0/24
EC2 cliente para teste
Interface Endpoint

Passo 1: Criar a VPC Provider

Crie uma VPC para o lado provider, por exemplo:

VPC Provider: 10.10.0.0/16
Subnet privada: 10.10.1.0/24

Essa será a VPC onde a aplicação privada estará rodando.

Passo 2: Criar uma EC2 com Nginx

Na VPC Provider, crie uma EC2 Linux e instale o Nginx.

Depois que a instância subir, valide localmente se o Nginx está funcionando.

Exemplo:

curl http://localhost

Resultado esperado:

Hello from Provider VPC via PrivateLink

Passo 3: Criar o Security Group da EC2 Provider

A EC2 Provider precisa permitir tráfego HTTP na porta 80.

Para um lab simples, você pode liberar a porta 80 a partir do CIDR da VPC Provider ou do Security Group/NLB usado no teste.

Exemplo:

Inbound:
TCP 80 vindo da VPC Provider ou do tráfego encaminhado pelo NLB

Em ambientes reais, evite liberações amplas e restrinja a origem sempre que possível.

Passo 4: Criar um Network Load Balancer interno

Agora crie um Network Load Balancer interno na VPC Provider.

Configuração sugerida:

Scheme: internal
Listener: TCP 80
Target Group: instance ou IP
Porta do Target: 80
Health Check: TCP ou HTTP na porta 80

Security Group do NLB Provider

Inbound:
TCP 80
Source: CIDR da VPC Consumer
Exemplo: 10.20.0.0/16

Adicione a EC2 Provider como target do Target Group.

Depois, valide se o target ficou como healthy.

Passo 5: Criar o Endpoint Service

Com o NLB interno criado, agora podemos criar o Endpoint Service.

O Endpoint Service é o serviço que será publicado para ser consumido via PrivateLink.

Configuração:

Load balancer type: Network
Load balancer: NLB interno criado anteriormente
Acceptance required: enabled

Para fins de lab, é interessante deixar Acceptance required habilitado para visualizar o fluxo de aprovação da conexão.

Após criar o Endpoint Service, copie o nome do serviço. Ele será usado na VPC Consumer para criar o Interface Endpoint.

Passo 6: Criar a VPC Consumer

Agora crie uma segunda VPC, que será o lado consumidor.

Exemplo:

VPC Consumer: 10.20.0.0/16
Subnet privada: 10.20.1.0/24

Nessa VPC, crie uma EC2 cliente para realizar os testes de conectividade.

IP da EC2: 10.20.1.55

Passo 7: Criar o Security Group do Interface Endpoint

O Interface Endpoint terá uma ENI dentro da VPC Consumer.

Crie um Security Group permitindo tráfego HTTP vindo da EC2 Consumer.

Exemplo:

Inbound:
TCP 80 vindo do Security Group da EC2 Consumer

Esse Security Group será associado ao Interface Endpoint.

Passo 8: Criar o Interface Endpoint

Na VPC Consumer, crie um Interface Endpoint apontando para o Service Name do Endpoint Service criado na VPC Provider.

Ex: com.amazonaws.vpce.us-west-2.vpce-svc-0bcea6xxxxxxx

Configuração:

Service category: Other endpoint services
Service name: nome do Endpoint Service da VPC Provider
VPC: VPC Consumer
Subnet: subnet da VPC Consumer
Security Group: SG criado para o Interface Endpoint

Após criar o endpoint, se o Endpoint Service estiver com aprovação manual habilitada, será necessário aprovar a solicitação no lado Provider.

VPC -> Endpoint Services -> Selecione o seu Endpoint Service -> Endpoint connections -> selecione a conexão pendente -> Actions -> Accept endpoint connection request

Passo 9: Aprovar a conexão no Endpoint Service

Volte para o Endpoint Service na VPC Provider e aprove a solicitação de conexão criada pela VPC Consumer.

Depois da aprovação, aguarde até o Interface Endpoint ficar disponível.

Passo 10: Testar o acesso

Na EC2 Consumer, execute o curl usando o DNS do Interface Endpoint:

curl http://<dns-do-interface-endpoint>

Resultado esperado:

Hello from Provider VPC via PrivateLink

Se essa mensagem aparecer, significa que a aplicação na VPC Provider foi acessada com sucesso a partir da VPC Consumer usando AWS PrivateLink.

O ponto mais importante do lab

O mais interessante desse lab é que a VPC Consumer não precisa ter rota para o CIDR da VPC Provider.

Ou seja, a VPC Consumer não precisa conhecer a rede 10.10.0.0/16.

Da mesma forma, a VPC Provider não precisa ter rota para o CIDR da VPC Consumer.

Isso é diferente de soluções como VPC Peering ou Transit Gateway, onde existe roteamento entre redes.

Com PrivateLink, o consumidor acessa uma ENI local dentro da própria VPC. A AWS encaminha esse tráfego internamente até o serviço publicado atrás do NLB.

Por isso, o PrivateLink é uma ótima solução quando queremos expor apenas um serviço privado, sem conectar redes inteiras.

PrivateLink vs VPC Peering vs Transit Gateway

Serviço	Melhor uso	Escopo
VPC Peering	Conectar duas VPCs diretamente	Rede com rede
Transit Gateway	Centralizar conectividade entre várias VPCs, VPNs e Direct Connect	Hub de redes
PrivateLink	Expor ou consumir um serviço privado	Serviço específico

Resumo prático:

VPC Peering conecta VPCs.
Transit Gateway conecta várias redes.
PrivateLink conecta consumidores a serviços privados.

Boas práticas

Alguns pontos importantes para ambientes reais:

use Security Groups restritivos;
evite expor serviços desnecessários;
monitore conexões e métricas do NLB;
avalie o uso entre contas AWS para separar provider e consumer;
documente quem consome o serviço publicado;
use DNS privado quando quiser simplificar o acesso ao serviço;
valide custos de Interface Endpoints e tráfego processado.

Conclusão

O AWS PrivateLink é uma solução muito útil quando precisamos expor uma aplicação privada para outra VPC, outra conta ou outro time sem abrir o serviço para a internet e sem criar conectividade ampla entre redes.

Neste lab, vimos como criar uma arquitetura simples com:

uma VPC Provider;
uma aplicação Nginx privada;
um Network Load Balancer interno;
um Endpoint Service;
uma VPC Consumer;
um Interface Endpoint.

O principal aprendizado é que o PrivateLink não conecta redes inteiras. Ele conecta consumidores a um serviço específico.

Essa diferença é essencial para desenhar arquiteturas mais seguras, controladas e escaláveis na AWS.

DEV Community: Giovana Costa

Como foi minha preparação para a AWS Certified Developer – Associate

AWS Certified Developer – Associate - Credly

Um desafio particular

Como organizei meus estudos

O que mais foquei em estudar

O que achei da prova

Algumas dicas para quem vai fazer a certificação

Materiais que me ajudaram

1°. Guia oficial da certificação

2. Ultimate AWS Certified Developer Associate 2026 DVA-C02 (Udemy)

3. Simulados (Udemy)

Próximos passos

PrivateLink na prática: como acessar serviços privados em outra VPC sem VPC Peering

O que é AWS PrivateLink?

Quando usar PrivateLink?

Arquitetura do lab

Componentes do lab

VPC Provider

VPC Consumer

Passo 1: Criar a VPC Provider

Passo 2: Criar uma EC2 com Nginx

Passo 3: Criar o Security Group da EC2 Provider

Passo 4: Criar um Network Load Balancer interno

Passo 5: Criar o Endpoint Service

Passo 6: Criar a VPC Consumer

Passo 7: Criar o Security Group do Interface Endpoint

Passo 8: Criar o Interface Endpoint

Passo 9: Aprovar a conexão no Endpoint Service

Passo 10: Testar o acesso

O ponto mais importante do lab

PrivateLink vs VPC Peering vs Transit Gateway

Boas práticas

Conclusão

Referências