Conceitos de nuvem e responsabilidade compartilhada

A computação em nuvem (クラウドコンピューティング) é um modelo de uso em que os recursos de TI não são possuídos, mas alugados apenas quando necessário, na quantidade necessária, e pagos conforme o uso. O tempo entre a solicitação e a disponibilidade é curto, e a cobrança para no momento em que os recursos são devolvidos. Definir a quantidade necessária antes da implantação e comprar equipamentos, assim como gerenciar internamente até a energia e o ar-condicionado, são abordagens do modelo on-premises (オンプレミス) e, como a quantidade precisa ser decidida com antecedência, levam ao sobreprovisionamento (過剰プロビジョニング) ou à falta de capacidade. A descrição de que a quantidade não pode ser alterada durante o período do contrato é o oposto da premissa da nuvem de que ela pode ser aumentada ou reduzida depois.

O Pay-as-you-go (従量課金) é o princípio de pagar apenas pelo que você realmente usa, sem pagamento antecipado e sem compromisso de longo prazo. Como é possível escalar de acordo com a demanda real, e não com uma previsão, ele reduz o risco de sobreprovisionamento (過剰プロビジョニング). Reduzir o preço unitário em troca do compromisso com um nível de uso por um prazo definido é o Save when you commit; a queda do preço unitário à medida que o uso aumenta é o Pay less by using more; e agrupar em um valor mensal fixo sem cobranças excedentes é o Flat rate — todos se referem a princípios diferentes.

O Pay less by using more (使うほど安くなる) é o princípio de que uma estrutura de preços escalonada é aplicada a itens como o S3 e a transferência de dados, de modo que o preço unitário por GB cai à medida que o uso aumenta. Reduzir o preço unitário em troca do compromisso com um nível de uso por um prazo definido é o Save when you commit, exemplificado pelos Savings Plans. Pagar, a cada vez, apenas pelo que foi realmente usado é o Pay-as-you-go, e agrupar em um valor mensal fixo sem cobranças excedentes é o Flat rate. Os quatro princípios têm finalidades diferentes, portanto não se excluem e são usados em combinação.

O Save when you commit (コミットして節約) é o princípio segundo o qual, como nos Savings Plans, os preços de serviços de computação ou de aprendizado de máquina recebem desconto em troca do compromisso com um nível de uso específico por um prazo de 1 ano ou 3 anos. Fixar o valor mensal para que não ocorram cobranças excedentes, sem mecanismo de transferência para o mês seguinte, é o Flat rate. Uma estrutura escalonada em que o preço unitário cai à medida que o uso aumenta é o Pay less by using more. Poder parar a qualquer momento sem compromisso é uma propriedade do Pay-as-you-go, cuja premissa é o oposto deste princípio baseado em compromisso.

Em agosto de 2026, a lista oficial de guias de exame (試験ガイド) coloca duas certificações no nível Foundational: AWS Certified Cloud Practitioner (CLF-C02) e AWS Certified AI Practitioner (AIF-C01). Developer - Associate (DVA-C02) e Data Engineer - Associate (DEA-C01) são ambas Associate, e Advanced Networking - Specialty (ANS-C01) é Specialty. Para as certificações cujo nome termina com o nome do nível, isso é uma pista útil, mas Cloud Practitioner e AI Practitioner não têm nome de nível, então memorize que essas duas são as de nível Foundational.

CLF-C02 é o código de exame (試験コード) da AWS Certified Cloud Practitioner. CLF significa Cloud Practitioner, e o C02 final indica a geração da revisão. O código da AWS Certified AI Practitioner é AIF-C01, o da AWS Certified Developer - Associate é DVA-C02 e o da AWS Certified Data Engineer - Associate é DEA-C01. Os nomes das certificações às vezes mudam, mas o código de exame não muda até que o exame seja revisado, por isso verificar o código é uma maneira confiável de confirmar se o material de estudo está atualizado.

O código de exame (試験コード) da AWS Certified Solutions Architect - Professional é SAP-C02. SAA-C03 é o nível Associate da mesma trilha Solutions Architect, SOA-C03 é o CloudOps Engineer - Associate e SCS-C03 é o Security - Specialty. As três primeiras letras são parecidas e podem confundir, mas ajuda lembrar que SAA corresponde a Associate e SAP a Professional.

O Exam Guide do CLF-C02 define Cloud Concepts com 24 por cento, Security and Compliance com 30 por cento, Cloud Technology and Services com 34 por cento e Billing, Pricing, and Support com 12 por cento. Portanto, o maior é Cloud Technology and Services e o menor é Billing, Pricing, and Support. Por ser uma certificação de nível inicial, pode-se supor que os conceitos tenham o maior peso, mas na verdade o domínio (ドメイン) que avalia o conhecimento dos serviços é o maior, seguido pela segurança. A distribuição do tempo de estudo deve seguir essa mesma proporção.

O Exam Guide do SAA-C03 define Design Secure Architectures com 30 por cento, Design Resilient Architectures com 26 por cento, Design High-Performing Architectures com 24 por cento e Design Cost-Optimized Architectures com 20 por cento. O maior é o projeto de arquiteturas seguras. É fácil memorizar os quatro nomes de domínio associando-os aos pilares do Well-Architected (Well-Architected の柱), o que mostra que estão ordenados como segurança, confiabilidade, eficiência de performance e otimização de custos.

A certificação Associate voltada para operações teve o nome alterado de SysOps Administrator para CloudOps Engineer, e seu código de exame (試験コード) também mudou de SOA-C02 para SOA-C03. O último dia para fazer o exame com o código antigo foi 29 de setembro de 2025, e o novo código começou em 30 de setembro de 2025. Data Engineer - Associate e Machine Learning Engineer - Associate não são sucessoras da trilha de operações; são certificações distintas, criadas recentemente nas áreas de dados e de ML, respectivamente. DevOps Engineer - Professional é uma certificação de nível Professional que já existia, em um nível diferente.

A AWS chama oficialmente sua própria responsabilidade de "Security of the Cloud", definida como a proteção da infraestrutura que executa todos os serviços oferecidos na Nuvem AWS — ou seja, o hardware, o software, a rede e as instalações. Corrigir vulnerabilidades em uma aplicação instalada em uma instância é responsabilidade do cliente quando se escolhe o EC2. Escolher as opções de criptografia de dados e conceder permissões pelo IAM continuam sendo tarefas do cliente, qualquer que seja o serviço escolhido, e ambas pertencem ao lado da "Security in the Cloud".

A AWS declara explicitamente que "a responsabilidade do cliente será determinada pelos serviços da Nuvem AWS que o cliente selecionar". Isso significa que a quantidade de trabalho de configuração que o cliente precisa realizar, como parte de sua responsabilidade de segurança, varia conforme o serviço escolhido. Um plano de suporte (サポートプラン) determina como a assistência técnica é recebida e não move a linha de responsabilidade. A Região (リージョン) e a Zona de Disponibilidade (アベイラビリティゾーン) dizem respeito ao posicionamento, e a duração do uso ou o gasto dizem respeito à cobrança — nenhum deles determina a amplitude da responsabilidade.

A AWS declara oficialmente que, em serviços que exigem configuração, como o EC2, o cliente gerencia "o sistema operacional convidado (ゲストOS) (incluindo atualizações e patches de segurança), qualquer software de aplicação ou utilitário instalado nas instâncias e a configuração dos grupos de segurança". Portanto, aplicar patches ao sistema operacional é responsabilidade do cliente. No EC2, o que a AWS opera vai apenas até a infraestrutura física e a camada de virtualização (仮想化レイヤー), não o sistema operacional dentro da instância. Um plano de suporte é um contrato para receber assistência técnica e não muda a quem cabe a responsabilidade.

Para serviços abstratos ou gerenciados (マネージドサービス), a AWS afirma que "a AWS opera a camada de infraestrutura, o sistema operacional e as plataformas, e os clientes acessam os endpoints para armazenar e recuperar dados". O que fica com o cliente é gerenciar seus próprios dados (incluindo as opções de criptografia), classificar os ativos e aplicar as permissões adequadas usando as ferramentas do IAM. O cliente não realiza atualizações do sistema operacional nem opera a plataforma, mas a classificação dos dados e as configurações de permissão nunca saem das mãos do cliente, qualquer que seja o serviço.

A linha do modelo de responsabilidade compartilhada (責任共有モデル) não é fixa; ela se move conforme o serviço escolhido. Em um serviço como o EC2, em que o cliente gerencia o sistema operacional convidado (ゲストOS), a aplicação de patches é responsabilidade do cliente, mas em um serviço como o S3 ou o DynamoDB, em que a AWS opera tudo até o sistema operacional e a plataforma, ela passa a ser responsabilidade da AWS. Portanto, nem "sempre da AWS" nem "sempre do cliente" está correto. A Região é uma escolha de posicionamento e não altera a divisão de responsabilidades. Tendo esse ponto em mente, você consegue estimar a linha de um serviço desconhecido apenas perguntando se ele se aproxima mais do EC2 ou do S3.

As instalações estão explicitamente listadas na "Security of the Cloud" como parte da infraestrutura que executa os serviços da Nuvem AWS, portanto são sempre responsabilidade da AWS, qualquer que seja o serviço usado. Os clientes não podem auditar essa área por conta própria nem entrar nas instalações para inspecioná-las; em vez disso, confirmam isso por meio das certificações de terceiros e dos relatórios de auditoria que a AWS publica. Isso corresponde à categoria chamada Inherited Controls (継承されるコントロール) entre as três classificações de controles — a parte que os clientes herdam integralmente da AWS. O que se move conforme o serviço escolhido é a camada do sistema operacional e do middleware, não a camada física.

A AWS declara explicitamente que gerenciar os próprios dados (incluindo as opções de criptografia), classificar os ativos e aplicar as permissões adequadas usando as ferramentas do IAM continuam com o cliente mesmo ao usar serviços abstratos. Como isso nunca deixa o cliente, qualquer que seja o serviço escolhido, serve como ponto fixo ao pensar em onde fica a linha. Substituir um servidor físico e proteger a rede backbone (バックボーンネットワーク) são questões de instalações e hardware, e ficam sempre do lado da AWS. O sistema operacional subjacente a um serviço gerenciado (マネージドサービス) é operado pela AWS, então aplicar patches a ele não é tarefa do cliente.

Os Inherited Controls (継承されるコントロール) são definidos oficialmente como controles que o cliente herda integralmente da AWS, e os controles físicos e ambientais se enquadram nessa categoria. Os controles aplicados separadamente tanto na camada de infraestrutura quanto na camada do cliente são os Shared Controls (共有コントロール), e os controles que são inteiramente responsabilidade do cliente, como a segurança de serviços e de zonas, são os Customer Specific Controls (顧客固有のコントロール). A herança flui em uma única direção, da AWS para o cliente; não é uma relação em que a AWS mantém as configurações do próprio cliente.

A AWS cita Patch Management (パッチ管理), Configuration Management (構成管理) e Awareness & Training (意識向上とトレーニング) como seus três exemplos de Shared Controls (共有コントロール). O que eles têm em comum é que a mesma atividade é realizada em paralelo tanto na camada de infraestrutura quanto na camada do cliente — no gerenciamento de patches, por exemplo, a AWS aplica patches à sua própria infraestrutura, enquanto o cliente os aplica separadamente ao sistema operacional convidado e às aplicações. O controle de entrada e saída, a redundância de energia e a aquisição e o descarte de hardware são controles físicos e ambientais, que o cliente herda da AWS. A segurança de serviços e de zonas é um exemplo de Customer Specific Controls.

O DynamoDB é um serviço abstrato, portanto a AWS opera tudo, da camada de infraestrutura ao sistema operacional e à plataforma. A aplicação de patches ao sistema operacional convidado (ゲストOS), que o cliente realizava no EC2, passa a ser tarefa da AWS após a migração. Por outro lado, classificar os dados, escolher as opções de criptografia e conceder permissões pelo IAM continuam com o cliente, qualquer que seja o serviço escolhido. A proteção da instalação física já é sempre responsabilidade da AWS, então nunca passa para o cliente por causa de uma migração. Ajuda organizar assim: o que se move é a camada do sistema operacional/plataforma, e o que não se move são os dados e as permissões.

Os pilares atuais são seis: Excelência operacional (運用上の優秀性), Segurança (セキュリティ), Confiabilidade (信頼性), Eficiência de performance (パフォーマンス効率), Otimização de custos (コスト最適化) e Sustentabilidade (持続可能性). A Sustentabilidade foi adicionada como o sexto pilar em 2021, portanto uma lista com apenas cinco pilares, sem ela, reflete informações desatualizadas de antes dessa inclusão. Interoperabilidade (相互運用性) e Portabilidade (可搬性) não são listadas como pilares do framework; nenhuma delas aparece na lista oficial. Uma explicação com um número desatualizado de pilares provavelmente também tem nomes de serviços ou códigos de exame desatualizados, por isso isso pode servir como indicador de quão atual é um material de estudo.

A Excelência operacional (運用上の優秀性) é o pilar que se concentra em executar e monitorar sistemas e em melhorar continuamente processos e procedimentos. Isso inclui automatizar implantações, atualizar procedimentos com base em revisões pós-incidente e fazer mudanças em etapas pequenas e frequentes. Proteger informações e sistemas é Segurança; otimizar a alocação de recursos e selecionar tipos de recursos é Eficiência de performance; e eliminar gastos desnecessários e dimensionar corretamente os recursos é Otimização de custos — todos esses apontam para pilares diferentes.

O pilar Segurança (セキュリティ) concentra-se em proteger informações e sistemas, com foco na integridade dos dados e no controle de acesso. A criptografia e o controle de acesso com base no menor privilégio (最小権限) se enquadram diretamente nele. Parar recursos não utilizados e dimensionar corretamente as instâncias é Otimização de custos; automatizar a implantação e atualizar os runbooks após revisões de incidentes é Excelência operacional; e medir e reduzir o impacto ambiental é Sustentabilidade. A maior parte do que continua sendo responsabilidade do cliente no modelo de responsabilidade compartilhada é tratada dentro desse pilar Segurança.

A Confiabilidade (信頼性) é o pilar que se concentra em uma carga de trabalho (ワークロード) cumprir a função pretendida e na rapidez com que ela se recupera de falhas. A distribuição entre várias Zonas de Disponibilidade, a recuperação automática e a verificação dos procedimentos de backup e recuperação se enquadram aqui. Sua característica distintiva é que abrange não apenas evitar que algo quebre, mas também recuperar rapidamente depois que algo quebrou. Otimizar a alocação de recursos é Eficiência de performance; executar, monitorar e melhorar continuamente os procedimentos é Excelência operacional; e minimizar o impacto ambiental é Sustentabilidade.

A Eficiência de performance (パフォーマンス効率) é o pilar que se concentra em otimizar a alocação dos recursos de TI e em selecionar o tipo de recurso adequado às necessidades da carga de trabalho. Selecionar novamente um tipo de recurso para atender a um requisito se enquadra diretamente nele. A Otimização de custos pode parecer uma atividade semelhante, mas seu objetivo é eliminar gastos desnecessários, enquanto aqui a motivação é atender a um requisito de latência (レイテンシ), então o foco é diferente. A Confiabilidade observa a resiliência a falhas e a Excelência operacional observa a melhoria dos procedimentos — nenhuma delas é a preocupação principal aqui.

A Otimização de custos (コスト最適化) é o pilar que se concentra em eliminar gastos desnecessários e dimensionar corretamente os recursos de acordo com os requisitos do negócio. Decisões como parar recursos não utilizados, corrigir instâncias superdimensionadas e escolher modelos de preços adequados se enquadram aqui. O ponto não é simplesmente minimizar o custo, mas perguntar se está sendo obtido um valor proporcional ao gasto. Proteger informações e sistemas é Segurança; cumprir a função pretendida e se recuperar é Confiabilidade; e minimizar o impacto ambiental é Sustentabilidade.

A Sustentabilidade (持続可能性) é o pilar que se concentra em minimizar o impacto ambiental da execução de uma carga de trabalho na nuvem. É o pilar mais recente, adicionado como o sexto em 2021, e sua presença ou ausência marca a linha entre material de estudo atual e desatualizado. Otimizar a alocação de recursos e selecionar tipos de recursos é Eficiência de performance; executar, monitorar e melhorar continuamente os procedimentos é Excelência operacional; e cumprir a função pretendida e se recuperar de falhas é Confiabilidade — todos esses apontam para pilares diferentes.

O que está faltando é a Sustentabilidade (持続可能性), o pilar que trata de minimizar o impacto ambiental da execução de uma carga de trabalho na nuvem. Como ela foi adicionada como o sexto pilar em 2021, os artigos escritos antes disso ainda listam apenas cinco. Excelência operacional, Eficiência de performance e Confiabilidade já existiam antes dessa inclusão, por isso aparecem mesmo em um artigo que lista cinco pilares. Quando um fato básico como o número de pilares está desatualizado em um artigo, é provável que o restante do conteúdo também esteja desatualizado.

Os pilares atuais são seis: Excelência operacional, Segurança, Confiabilidade, Eficiência de performance, Otimização de custos e Sustentabilidade, e a Interoperabilidade (相互運用性) não está incluída nessa lista. A capacidade de sistemas diferentes se conectarem entre si é uma preocupação importante de projeto, mas o Well-Architected Framework não a estabelece como um pilar independente. Otimização de custos, Excelência operacional e Eficiência de performance são todos membros legítimos dos seis. Memorizar um termo que não está no framework como se fosse um pilar causa confusão na hora de eliminar alternativas.

Eliminar gastos desnecessários e dimensionar corretamente os recursos de acordo com os requisitos do negócio é o foco da Otimização de custos (コスト最適化), não da Confiabilidade (信頼性). A Confiabilidade é o pilar que se concentra em uma carga de trabalho cumprir a função pretendida e na rapidez com que ela se recupera de falhas. Os outros três pares correspondem às descrições oficiais. Como os nomes dos pilares soam parecidos com palavras do dia a dia, associá-los apenas pela impressão leva a erros; memorizá-los junto com a descrição de uma frase do seu foco evita tropeçar nesse tipo de questão.

Uma Região (リージョン) é um local físico no mundo onde a AWS tem várias Zonas de Disponibilidade (アベイラビリティゾーン). As Regiões têm nomes como us-east-1 ou ap-northeast-1 e são escolhidas com base na residência dos dados e nos requisitos regulatórios, na distância até os usuários e nos preços. Uma unidade para isolar falhas composta por um ou mais data centers distintos é a descrição de uma Zona de Disponibilidade. Um local onde o CloudFront armazena em cache e entrega conteúdo é uma localização de borda (エッジロケーション), e uma zona instalada dentro da rede de uma operadora de telecomunicações é uma Wavelength Zone.

Uma Zona de Disponibilidade (アベイラビリティゾーン) é definida como composta por um ou mais data centers distintos, cada um com energia, rede e conectividade redundantes, e abrigados em instalações separadas. Os pontos-chave são que ela não é o mesmo que um único prédio de data center, mas sim um agrupamento, e que fica em um prédio diferente das outras zonas. Uma camada intermediária entre uma localização de borda e a origem é um cache de borda regional (リージョナルエッジキャッシュ), e um local próximo à cidade do usuário para executar aplicações descreve as Local Zones — ambos se referem a mecanismos diferentes.

A AWS declara oficialmente que cada Região (リージョン) é composta por "no mínimo três Zonas de Disponibilidade isoladas e fisicamente separadas". Como o número total de Regiões e de zonas não para de crescer, memorizar esses totais tem pouco valor, mas a regra de quantas zonas uma única Região tem no mínimo é estável e pode ser usada diretamente como premissa de projeto. Estar localizada dentro da mesma instalação contradiz a definição de estar abrigada em instalações separadas. As zonas não são algo que os clientes solicitam para aumentar, nem existe apenas uma por Região.

As localizações de borda (エッジロケーション) são a rede mundial de data centers por meio da qual o CloudFront entrega conteúdo. As solicitações são roteadas para a localização de borda com a menor latência (レイテンシ), e a entrega é feita a partir dali. O ponto-chave é que ela não é uma unidade de redundância para aumentar a disponibilidade, mas um local de cache para reentregar o conteúdo mais perto do usuário. Isolar falhas é o papel de uma Zona de Disponibilidade, dividir intervalos de endereços IP é o papel de uma sub-rede (サブネット) e executar aplicações dentro das instalações de uma operadora é o papel das Wavelength Zones.

Uma solicitação é roteada para a localização de borda (エッジロケーション) com a menor latência e, se o conteúdo já estiver lá, é entregue imediatamente. Caso contrário, ele é buscado em uma origem (オリジン) — como um bucket do S3 ou um servidor HTTP —, entregue e também armazenado no cache. É por isso que as solicitações seguintes podem ser respondidas diretamente a partir do local próximo. A ausência de uma entrada no cache não se transforma em erro, nem deixa o usuário esperando. O encaminhamento para uma Zona de Disponibilidade é um mecanismo de isolamento de falhas e não tem relação com o fluxo de entrega de conteúdo.

Um cache de borda regional (リージョナルエッジキャッシュ) é uma camada de cache posicionada entre uma localização de borda e a origem (オリジン). Seu papel é reduzir o número de vezes que uma solicitação precisa voltar até a origem quando não é encontrada na borda. Uma unidade de gerenciamento que agrupa Zonas de Disponibilidade é uma Região, e as zonas instaladas dentro da rede de uma operadora de telecomunicações são as Wavelength Zones — ambos são conceitos diferentes. O cache no próprio dispositivo do usuário não é um mecanismo da AWS, mas um recurso do navegador ou do sistema operacional.

Uma Zona de Disponibilidade (アベイラビリティゾーン) é uma unidade de isolamento de falhas abrigada em uma instalação separada, com energia e rede redundantes. Colocar recursos com a mesma função em várias zonas significa que, mesmo que uma zona caia por completo, as demais podem continuar o processamento. Essa é uma configuração Multi-AZ (マルチAZ構成) e é o ponto de partida do projeto de disponibilidade. Entregar a partir do local mais próximo é o papel de uma localização de borda; a residência dos dados é um fator na escolha de uma Região; e reduzir o preço unitário por meio de um compromisso de uso é uma questão de preços — nenhum deles é a motivação para dividir entre zonas.

As Local Zones são um mecanismo que permite executar aplicações na infraestrutura da AWS mais perto dos usuários finais ou das cargas de trabalho, instaladas em cidades distantes de uma Região. Elas se parecem com as localizações de borda (エッジロケーション) por lidarem com o "perto", mas a diferença é que executam a própria aplicação, em vez de servirem como cache de entrega de conteúdo. Isolar falhas dentro de uma Região é uma Zona de Disponibilidade, um local exclusivo de entrega é uma localização de borda, e um cache intermediário na frente da origem é um cache de borda regional (リージョナルエッジキャッシュ).

As Wavelength Zones são zonas instaladas dentro da rede de uma operadora de telecomunicações (通信キャリア). Assim como as Local Zones, são um mecanismo para executar a própria aplicação perto dos usuários, o que difere em finalidade de uma localização de borda, que é um ponto de entrega de cache de conteúdo. O que fica entre uma localização de borda e a origem é um cache de borda regional; uma unidade de isolamento de falhas dentro de uma Região é uma Zona de Disponibilidade; e dividir o intervalo de endereços IP de uma VPC é uma sub-rede (サブネット).

Uma Zona de Disponibilidade (アベイラビリティゾーン) é uma unidade de isolamento de falhas abrigada em uma instalação separada, portanto, para se preparar para a queda de uma zona inteira, é preciso distribuir os recursos entre zonas. Como cada Região é composta por pelo menos três zonas isoladas, é possível distribuir entre várias zonas dentro da mesma Região. Adicionar mais servidores dentro da mesma zona não atende ao requisito, pois, se essa zona cair, todos caem juntos. O CloudFront acelera a entrega, mas, se a origem parar, o processamento dinâmico não pode continuar. Mudar o plano de preços é uma questão de custo, sem relação com a disponibilidade (可用性).