Introdução

Este curso Princípios básicos da AWS foi desenvolvido para que você conheça os principais conceitos necessários para um trabalho eficaz na AWS.

No início, a AWS pode parecer excessiva. Um paradigma nativo da nuvem para criar infraestrutura pode ser um ponto de partida radical comparado ao uso tradicional de recursos no local. E independentemente de ser seu primeiro trabalho com infraestrutura ou de você ter usado o kernel Linux na última década, pode ser difícil saber por onde começar com a seleção de mais de 175 serviços da AWS.

O curso Princípios básicos da AWS foi projetado para ajudar você a começar com a AWS, seja qual for seu nível de experiência. Neste curso, você conhecerá os cinco pilares da AWS, os modelos mentais a serem usados para pensar sobre a nuvem e os principais conceitos que serão aplicáveis a qualquer serviço usado.

 

Estrutura

O curso Princípios básicos da AWS será dividido em cinco módulos. Cada módulo terá o seguinte formato:

  • Introdução: uma descrição rápida do pilar em foco
  • Modelo mental: um modelo mental orientador para ajudá-lo a entender os conceitos apresentados em cada pilar
  • Conceitos: principais conceitos que cobrem tópicos básicos e amplos de cada pilar
  • Conclusão: resumo do que foi abordado
  • Leituras complementares: links e recursos adicionais
 

Os cinco pilares

Os cinco pilares abordados no curso Princípios básicos da AWS têm origem no AWS Well-Architected Framework. Well-Architected Framework é a destilação de mais de uma década de experiência com a criação de aplicações escaláveis na nuvem.

Os cinco pilares consistem nas seguintes áreas:

  1. Segurança
  2. Eficiência de performance
  3. Confiabilidade
  4. Excelência operacional
  5. Otimização de custos
 

Segurança

O pilar Segurança enfoca a maneira como você protege a infraestrutura na nuvem. Segurança e conformidade constituem uma responsabilidade compartilhada entre a AWS e o cliente. Neste modelo de responsabilidade compartilhada, a AWS é responsável pela segurança da nuvem. Isso inclui a infraestrutura física, o software e os recursos de rede dos serviços de nuvem AWS. O cliente é responsável pela segurança na nuvem. Isso inclui a configuração de serviços de nuvem específicos, o software de aplicação e o gerenciamento de dados confidenciais.

Caso suas cargas de trabalho tenham que atender à FedRAMP, DoD SRG, ITAR, CJIS ou outros requisitos de conformidade estrita, ou contenham dados classificados como Controlled Unclassified Information (CUI – Informações controladas não classificadas), consulte a seção AWS GovCloud (EUA) do curso.

 

Modelo mental

Quando se pensa em segurança na nuvem, é recomendável seguir o modelo de confiança zero.

Nesse modelo, todos os componentes e serviços da aplicação são considerados entidades distintas e potencialmente maliciosas. Entre essas entidades estão a malha de rede subjacente, todos os agentes que têm acesso aos recursos e o software executado no serviço.

 

Conceitos

A segurança em termos de confiança zero requer a aplicação de medidas de segurança em todos os níveis do sistema. Estes são três conceitos importantes envolvidos na proteção de sistemas com confiança zero na nuvem:

  1. Identity and Access Management (IAM)
  2. Segurança da rede
  3. Criptografia de dados

 

  • Identity and Access Management (IAM)

    IAM é o serviço responsável por monitorar identidades e acessos no sistema. Esse monitoramento é gerenciado na AWS com o serviço chamado IAM, ou seja, gerenciamento de identidades e acessos. O acesso é gerenciado com políticas do IAM que estipulam limites para o acesso dos agentes na AWS. Há três componentes fundamentais em uma política do IAM:

    • PRINCIPAL especifica QUEM recebe permissões
    • AÇÃO especifica O QUÊ está sendo executado
    • RECURSO especifica QUAIS propriedades estão sendo acessadas

    Aplicar o modelo de confiança zero ao IAM significa adotar o princípio do privilégio mínimo. Isso quer dizer que todo agente deve ter somente as permissões mínimas necessárias para o desempenho de sua função.

    Uma política do IAM pode ser aplicada a um elemento principal ou a um recurso da AWS. As políticas associadas a um elemento principal são conhecidas como políticas baseadas em identidade. As políticas associadas a um recurso são conhecidas como políticas baseadas em recurso. Note que somente alguns serviços (por exemplo, S3, KMS, SES) têm políticas baseadas em recurso.

    Um elemento principal só poderá executar uma ação para determinado recurso se a política baseada em identidade permitir e se a política baseada em recursos (se houver) não proibir.

    É importante frisar que essa é uma grande simplificação do modelo de permissões do IAM. Há muitos outros tipos de política que afetam a concessão do acesso. Entre eles estão limites de permissão, políticas de controle de serviços da organização, listas de controle de acesso e políticas de sessão. Esses tipos de políticas adicionais estão fora do escopo deste curso. Há mais detalhes sobre isso na seção Leituras complementares deste módulo.

    Conclusões

    • As políticas do IAM determinam os limites de acesso das entidades na AWS
    • As políticas do IAM consistem em PRINCIPAIS, AÇÕES e RECURSOS
    • As políticas do IAM podem ser usadas para aplicar o princípio de privilégio mínimo
    • O IAM tem vários tipos de política. As políticas baseadas em identidade e as políticas baseadas em recurso são dois exemplos
    • O IAM avalia o acesso de acordo com todos os tipos de política que se aplicam a determinado recurso
     

    Leituras complementares

  • Segurança da rede

    Segurança da rede envolve qualquer sistema, configuração ou sistema que proteja o acesso e a utilização da rede e dos recursos que podem ser acessados na rede. A AWS fornece uma grande variedade de recursos de proteção, tanto no nível da rede quanto no nível do recurso.

    Uma abordagem de confiança zero à segurança da rede envolve a defesa profunda, que aplica controles de segurança a todas as camadas da rede (e não apenas à camada mais externa).

    Segurança no nível da rede

    O elemento fundamental e primitivo no nível da rede na AWS é a Amazon Virtual Private Cloud (VPC). Essa é uma rede lógica que você define e na qual pode provisionar recursos.

    Estes são alguns componentes da VPC:

    • Sub-redes: um intervalo de endereços IP na VPC
    • Tabelas de rotas: um conjunto de regras que determinam para onde o tráfego é direcionado
    • Gateway da Internet: um componente que possibilita a comunicação entre recursos na VPC e na Internet

    Para proteger o tráfego na VPC, é possível dividir os recursos em voltados para o público e internos. Para reduzir a superfície de ataque, você pode usar um serviço proxy, como o Application Load Balancer (ALB), para processar todo o tráfego na Internet. Todos os serviços internos, como servidores e bancos de dados, podem então ser provisionados nas sub-redes internas que são isoladas do acesso direto e público à Internet.

    Além das VPCs, você também pode usar o AWS Web Application Firewall (WAF) para restringir ainda mais o tráfego na rede.

    Segurança no nível do recurso

    Recursos específicos da AWS também têm controles de segurança de rede que você pode configurar. O controle mais comum chama-se grupo de segurança. Os grupos de segurança são firewalls virtuais que podem ser usados para forçar o fluxo do tráfego de entrada e saída no recurso. Use grupos de segurança para permitir que o tráfego proveniente de portas específicas e fontes confiáveis chegue à instância. Você pode anexar grupos de segurança a recursos, como instâncias do EC2, instâncias do RDS e Lambda.

    Conclusões

    • Segurança da rede envolve os mecanismos desenvolvidos para proteger o acesso e a utilização da rede e dos recursos que podem ser acessados na rede
    • Uma abordagem de confiança zero à segurança da rede envolve a implementação de uma defesa profunda em todas as camadas da rede
    • VPCs e WAFs permitem a aplicação de medidas de segurança no nível da rede
    • Grupos de segurança permitem a aplicação de medidas de segurança no nível do recurso

    Leituras complementares

  • Criptografia de dados

    Criptografia de dados é o processo de codificar as informações para que se tornem ininteligíveis a terceiros que não têm a chave necessária para descriptografar os dados.

    Adotar o modelo de confiança zero para os dados significa criptografar os dados em todos os locais, tanto os dados em trânsito quanto os dados em repouso.

    Criptografia de dados em trânsito

    A criptografia de dados em trânsito envolve criptografar os dados durante sua travessia pelos sistemas. Todos os serviços de armazenamento e banco de dados na AWS fornecem endpoints HTTPS que dão suporte à criptografia dos dados em trânsito. Além disso, a AWS oferece serviços de rede que podem ajudá-lo a aplicar a criptografia em trânsito aos seus próprios serviços. Por exemplo, você pode usar o Application Load Balancer (ALB) para aplicar uma conexão por HTTPS aos endpoints.

    Criptografia de dados em repouso

    A criptografia de dados em repouso envolve criptografar os dados que estão contidos nos sistemas. Todos os serviços de armazenamento e banco de dados da AWS aceitam a criptografia de dados em repouso. A maioria desses serviços têm o recurso de criptografia ativado por padrão. Não há cobrança adicional pela criptografia e carga insignificante da performance da criptografia dos dados.

    A maioria dos serviços de armazenamento e banco de dados também se integram diretamente com o Amazon Key Management Service (KMS). Esse é um importante serviço de gerenciamento de chaves que possibilita criar Customer Managed Keys, CMKs (chaves gerenciadas do cliente) para criptografar os dados.

    Com o CMK, você ganha funções que vão além da criptografia. São funções que incluem a possibilidade de usar seu próprio repositório de chaves personalizadas, de criar uma trilha de auditoria para o recurso criptografado por meio de integrações com o AWS CloudTrail e de aplicar o rodízio automático de chaves.

    Conclusões

    • Criptografia é o processo de criptografar informações de modo que somente as partes com a chave correta possam descriptografar as informações
    • Use a criptografia para proteger dados em trânsito e dados em repouso
    • Todos os serviços de armazenamento e banco de dados na AWS fornecem criptografia para dados em trânsito e dados ociosos
    • Você pode usar os serviços de rede da AWS, como o ALB, para aplicar a criptografia aos dados trânsito em seus próprios serviços
    • Você pode usar o CMK para liberar funções avançadas, como criação de trilhas de auditoria, uso das próprias chaves personalizadas e rodízio automático de chaves

    Leituras complementares

    Recursos

     

    Serviços

     

    Referências

     

     

Conclusão

Neste módulo, você aprendeu sobre o pilar Segurança da AWS. Você aprendeu sobre o modelo mental de confiança zero. Você aprendeu sobre o IAM e o princípio do privilégio mínimo. Você aprendeu sobre a segurança de rede da AWS e o princípio de defesa em profundidade. Você aprendeu sobre a criptografia de dados e sua aplicação a dados em trânsito e em repouso.

 

Leituras complementares

Eficiência de performance

O pilar Eficiência de performance destaca como é possível executar serviços com eficiência e escalabilidade na nuvem. Embora a nuvem ofereça os meios de lidar com qualquer volume de tráfego, é preciso escolher e configurar os serviços considerando a escala.

 

Modelo mental

Ao pensar sobre a eficiência de performance na nuvem, é útil considerar seus serviços como gado, não animais de estimação.

No modelo no local de fazer as coisas, os servidores eram caros e geralmente implantados e configurados manualmente. Poderia levar semanas até que um servidor fosse realmente entregue e fisicamente conectado ao datacenter. Por isso os servidores eram tratados como animais de estimação: cada um era único e exigia muita manutenção. Alguns deles até tinham nomes.

Na nuvem, pensamos nos servidores como gado. Os servidores são recursos econômicos que podem ser provisionados automaticamente em segundos. Nenhum único servidor seria essencial à operação do serviço.

 

Conceitos

Considerar os servidores como gado nos proporciona muitos benefícios relacionados à performance. No “modelo animal de estimação” de gerenciar servidores, é muito comum usar o mesmo tipo de servidor, ou até o mesmo servidor, para várias cargas de trabalho. Era muito trabalhoso encomendar e provisionar diferentes máquinas. No “modelo gado”, o provisionamento é barato e rápido. Isso nos oferece a liberdade de selecionar o tipo de servidor que melhor corresponde à nossa carga de trabalho.

O “modelo gado” também facilita o dimensionamento do nosso serviço. Como todo servidor é intercambiável e pode ser implantado rapidamente, podemos dimensionar nossa capacidade com agilidade adicionando mais servidores.

Nos concentraremos nestes dois conceitos em relação à eficiência de performance:

  1. Seleção
  2. Dimensionamento
 
  • Seleção

    Na AWS, a seleção é a capacidade de escolher o serviço mais adequado à sua carga de trabalho. A AWS tem a maior seleção de serviços, com mais de 175 serviços distribuídos em mais de duas dúzias de categorias. Alcançar a performance por meio da seleção significa ser capaz de escolher a ferramenta certa para o trabalho.

    Normalmente, a carga de trabalho típica exige a seleção de uma ou mais das quatro categorias de serviço principais na AWS: computação, armazenamento, banco de dados e rede.

    • A computação lida com o serviço que fará o processamento de seus dados (por exemplo, máquina virtual)
    • O armazenamento se trata do armazenamento estático de dados (por exemplo, armazenamento de objetos)
    • O banco de dados se refere ao armazenamento organizado de dados (por exemplo, banco de dados relacional)
    • A rede diz respeito a como seus dados são movimentados (por exemplo, rede de distribuição de conteúdo)

    Neste módulo, analisaremos como fazer a seleção correta nas três primeiras categorias. Consulte a seção Leituras complementares para ver os guias sobre como escolher entre diferentes opções de rede.

    Independentemente da categoria de serviço que você está escolhendo, há três coisas que você precisa considerar.

    1. Tipo de serviço
    2. Grau de gerenciamento
    3. Configuração

    Tipo de serviço

    Ao fazer uma seleção em uma categoria, a AWS oferece várias opções referentes ao tipo de serviço que você pode usar. O tipo é exclusivo de cada categoria.

    Ao selecionar um serviço de computação, decida se quer computação baseada em VM, em contêiner ou na tecnologia sem servidor.

    • A computação baseada em VM tem o modelo mental mais familiar para a maioria das pessoas, mas pode ser mais cara e exigir mais manutenção
    • A computação baseada em contêiner permite habilitar uma divisão mais detalhada da sua carga de trabalho e pode ser dimensionada rapidamente, mas traz uma complexidade adicional na configuração e orquestração
    • A computação baseada na tecnologia sem servidor afasta a maioria das complexidades de gerenciamento e dimensionamento, mas tem limitações rígidas de sistema e exige a adoção de novas cadeias de ferramentas e processos

    Ao selecionar um serviço de armazenamento, decida se precisa de um armazenamento de arquivos, de blocos, de objetos ou de arquivos mortos.

    • Os serviços de armazenamento de blocos, como o EBS, são ótimos para dados persistentes provenientes de uma única instância do EC2
    • Os sistemas de arquivos, como o EFS, são ótimos para oferecer a vários clientes o acesso aos mesmos dados
    • Os armazenamentos de objetos, como o S3, são excelentes para grandes blobs de dados que precisam ser acessados por qualquer quantidade de clientes
    • O armazenamento de arquivos mortos, como o S3 Glacier, são ideais para grandes quantidades de dados que precisam ser acessados com pouca frequência

    Ao selecionar um serviço de banco de dados, determine se precisa de um banco de dados relaciona, um banco de dados não relacional, uma solução de data warehouse ou uma solução de indexação e pesquisa de dados.

    • Os bancos de dados relacionais permitem que você tenha uniões e propriedades ACID, mas têm um limite máximo de performance e armazenamento de dados
    • Os bancos de dados não relacionais têm esquemas mais flexíveis e podem ser dimensionados para limites muito superiores do que suas contrapartes relacionais, mas geralmente carecem de uniões e recursos ACID completos
    • As soluções de data warehouse permitem estudos analíticos em grande escala por meio do rápido acesso a petabytes de dados estruturados
    • As soluções de indexação e pesquisa de dados permitem indexar e pesquisar dados obtidos de várias fontes
     

    Grau de gerenciamento

    Depois de decidir sobre o tipo do serviço, é necessário detalhar ainda mais para encontrar um serviço específico. Algumas vezes, a AWS dispõe de várias ofertas em tipos específicos de serviços. A principal diferença entre os vários serviços da AWS do mesmo tipo pode ser encontrada no grau de gerenciamento.

    Quando você está usando serviços de computação e decide sobre o tipo de VM, precisa decidir entre o EC2, o Lightsail e o Elastic Beanstalk. Usar o EC2 diretamente permite ter o máximo controle, porém com o mínimo de gerenciamento, enquanto a escolha do Lightsail traz alguma personalização para uma experiência muito mais gerenciada. O Elastic Beanstalk está entre as duas opções acima. Ele oferece uma estrutura de trabalho opinativa para sua arquitetura de serviço, mas permite personalizar por meio da configuração.

    Quando você estiver usando os serviços de armazenamento, selecionar um serviço é mais fácil já que existe a tendência de haver apenas um serviço para qualquer dos tipos (por exemplo, S3 para armazenamento de objetos, EFS para armazenamento de arquivos).

    Quando você estiver usando serviços de banco de dados e decidir sobre o tipo relacional, é necessário escolher entre o RDS e o Aurora. O RDS oferece a você mais controle sobre o banco de dados adjacente e está disponível para a maioria dos bancos de dados relacionais. O Aurora funciona somente com algumas versões do MySQL e do PostgreSQL, mas cuida do gerenciamento do armazenamento subjacente e tem suporte integrado ao uso de clusters.

    No final do dia, a opção por um serviço específico depende amplamente da sua familiaridade com a tecnologia subjacente e sua preferência por uma experiência mais ou menos gerenciada.

     

    Configuração

    Depois de ter decidido sobre um serviço, você precisará decidir ainda sobre como quer configurá-lo. A configuração depende das características específicas de performance que você almeja alcançar e são diferentes para cada categoria de serviço.

    Ao avaliar a característica de performance dos serviços de computação, um bom lugar para começar é observando seus requisitos de memória e computação:

    • Se você estiver usando computação baseada em VM, a memória e a CPU serão afetadas pelo tamanho de sua instância (por exemplo, t3.small vs. t3.xlarge) e pela família de instâncias (por exemplo, r3.small vs. c5.small)
    • Se você estiver usando computação baseada em contêiner, a memória e a CPU podem ser definidas individualmente
    • Se você estiver usando computação baseada na tecnologia sem servidor, somente a memória pode ser definida diretamente. O valor da computação e de outros recursos do sistema aumenta linearmente de acordo com a quantidade de memória disponível

    Observe que, dependendo de sua carga de trabalho, há outras limitações de recursos com que você pode se preocupar, como a capacidade de rede e a disponibilidade de alguns recursos, como o armazenamento de instâncias.

    Ao avaliar a característica de performance para serviços de armazenamento, considere seus requisitos de latência, throughput e IOPS:

    • Se você estiver usando um serviço de armazenamento de blocos
      • A latência será afetada pela seleção do tipo de volume (por exemplo, unidade de estado sólido vs. unidade de disco rígido)
      • O throughput será proporcional ao tamanho do volume para a maioria dos tipos de volumes
      • A capacidade de IOPS será proporcional ao tamanho do volume para a maioria dos tipos de volumes
    • Se você estiver usando um serviço de sistema
      • A latência e o IOPS serão afetados por sua escolha dos modos de performance
      • O throughput será afetado por sua opção de usar o throughput provisionado
    • Se você estiver usando um armazenamento de objetos
      • A latência será afetada pela distância geográfica até o endpoint do bucket
      • O throughput será afetado pelo uso de APIs otimizadas para throughput, como o upload em várias partes
      • O IOPS não é configurável
    • Se você estiver usando um armazenamento de arquivos mortos
      • A latência será afetada pela distância geográfica até o endpoint do bucket e pela opção de método de recuperação
      • O throughput será afetado pelo uso de APIs otimizadas para throughput, como o upload em várias partes
      • O IOPS não é configurável

    Ao avaliar a característica de performance para serviço de banco de dados, considere os requisitos de recursos (por exemplo, memória, armazenamento etc.):

    • Se você estiver usando um banco de dados relacional
      • As características do recurso serão determinadas por sua opção de instância do EC2
    • Se você estiver usando um banco de dados não relacional como o DynamoDB
      • As características do recurso serão determinadas pelas opções de configuração, como a capacidade provisionada
    • Se você estiver usando uma solução de data warehouse como o Redshift
      • As características do recurso serão determinadas por sua opção de instância do EC2 subjacente
    • Se você estiver usando uma solução de indexação como o Elasticsearch Service
      • As características do recurso serão determinadas por sua opção de instância do EC2

     

    Conclusões

    • A AWS tem vários serviços e muitas maneiras de alcançar seu resultado
    • A implementação de uma carga de trabalho na AWS envolve a seleção de serviços nas categorias de computação, armazenamento, banco de dados e rede
    • Dentro de cada categoria, é possível selecionar o tipo certo de serviço com base em seu caso de uso
    • Dentro de cada tipo, é possível selecionar o serviço específico com base no grau desejado de gerenciamento
    • Dentro de cada serviço, é possível selecionar a configuração específica com base nas características de performance específicas que você deseja alcançar
     

    Leituras complementares

  • Dimensionamento

    Se, por um lado, a escolha do serviço certo é essencial para começar a usar, escolher como dimensionar esse serviço é importante para a performance contínua.

    A AWS tem dois meios principais de dimensionamento:

    1. Dimensionamento vertical
    2. Dimensionamento horizontal


    Dimensionamento vertical

    O dimensionamento vertical envolve fazer upgrade de sua computação subjacente para um tipo de instância maior. Por exemplo, digamos que você está executando uma instância t3.small. Dimensionar essa instância verticalmente seria fazer o upgrade dela para t3.large.

    Normalmente, o dimensionamento vertical é mais fácil de implementar já que você pode fazer isso sem ter que dividir seu serviço em clusters. A desvantagem é que você vai de encontro a um limite máximo muito inferior, igual ao tamanho máximo de sua instância de computação, em comparação com o dimensionamento horizontal. Isso também representa um ponto único de falha porque a interrupção em sua instância pode resultar na total indisponibilidade do seu serviço.

     

    Dimensionamento horizontal

    O dimensionamento horizontal envolve o aumento do número de instâncias subjacentes. Por exemplo, digamos que você está executando uma instância t3.small. Dimensionar essa instância horizontalmente envolveria o provisionamento de mais duas instâncias t3.small.

    O dimensionamento horizontal envolve mais sobrecarga no lado da implementação. Isso ocorre porque você precisa de um serviço de proxy para rotear o tráfego até sua frota de serviços. Você também precisa executar verificações de integridade para remover as instâncias inválidas do grupo de roteamento, bem como escolher um algoritmo de roteamento específico que seja ideal para sua carga de trabalho. Em troca, você termina com um serviço muito mais resiliente e pode dimensionar para limites muito mais altos do que a contraparte dimensionada verticalmente.


    Conclusões

    • Do ponto de vista operacional, o dimensionamento vertical é muito mais simples, mas representa um risco de disponibilidade e tem limites menores
    • O dimensionamento horizontal exige mais sobrecarga, mas oferece melhor confiabilidade e limites muito superiores
     

    Leituras complementares

Conclusão

Neste módulo, você aprendeu sobre o pilar Eficiência de performance da AWS. Você aprendeu sobre o modelo mental de tratar seus servidores como gado e não como animais de estimação. Você aprendeu como escolher o serviço certo e a respectiva configuração com base em suas metas de performance. Você aprendeu sobre o dimensionamento de serviços e as vantagens e desvantagens dos dimensionamentos vertical e horizontal.

 

Leituras complementares

Confiabilidade

O pilar Confiabilidade aborda como você pode criar serviços que são resilientes a interrupções de serviços e infraestrutura. Muito semelhante à Eficiência de performance, embora a nuvem forneça os meios para a criação de serviços resilientes que resistem a interrupções, ele requer que você projete seus serviços com o quesito confiabilidade em mente.


Modelo mental

Ao considerar a confiabilidade na nuvem, é útil pensar nela em termos de raio de alcance. Você pode considerar o raio de alcance como o impacto máximo ao qual será necessário resistir em caso de falha do sistema. Para criar sistemas confiáveis, sua meta será minimizar o raio de alcance de qualquer componente individual.

 

Conceitos

Quando você pensa em termos de raio de alcance, a questão da falha não é mais uma questão de se, mas uma questão de quando. Para lidar com a falha quando ela ocorre, as seguintes técnicas podem ser usadas para limitar o raio de alcance:

  1. Isolamento de falhas
  2. Limites


  • Isolamento de falhas

    O isolamento de falhas limita o raio de alcance de um incidente usando componentes independentes redundantes separados por meio de zonas de isolamento de falhas. As zonas de isolamento de falhas contêm o impacto de quaisquer falhas à área dentro da zona.

    A AWS tem zonas de isolamento de falhas em três níveis:

    1. Recurso e solicitação
    2. Zona de disponibilidade
    3. Região

     

    Recurso e solicitação

    Os serviços da AWS particionam todos os recursos e as solicitações em determinada dimensão, como o ID do recurso. Essas partições são conhecidas como células. As células são projetadas para serem independentes e conter falhas dentro de uma única célula. Nos bastidores, a AWS usa técnicas como fragmentação aleatória para limitar o raio de alcance. Tudo isso ocorre de maneira transparente sempre que você faz uma solicitação ou cria um recurso e não exige nenhuma ação adicional da sua parte.


    Zona de disponibilidade

    Uma Availability Zone (AZ – Zona de disponibilidade) da AWS é uma instalação completamente independente com recursos de energia, serviços e rede dedicados. Elas se situam geograficamente distantes de outras AZs para evitar falhas correlacionadas derivadas de riscos ambientais, como incêndios e inundações.

    O isolamento de falhas é conseguido em nível de AZ com a implantação de instâncias redundantes do seu serviço distribuídas por várias AZs. Fazer isso significa que um evento de energia em uma AZ não afetará seu tráfego em outra AZ.

    Uma observação a respeito da latência: apesar de geograficamente separadas, as AZs estão localizadas próximas o suficiente umas das outras para que a latência de rede entre elas seja mínima. Isso torna possível que determinados recursos, como a replicação síncrona de dados, funcione entre as AZs.


    Região

    Uma região da AWS fornece o isolamento definitivo. Cada região é um datacenter totalmente autônomo, composto por duas ou mais AZs. O isolamento de falhas é conseguido em nível de região com a implantação de cópias redundantes de seus serviços em diferentes regiões da AWS (é exatamente o que a AWS faz com os próprios serviços).

    Avalie a possibilidade de implantar em várias regiões se precisar de níveis muito altos de disponibilidade. Observe que a operação de um serviço entre várias regiões representa uma sobrecarga significativa em função a ausência de infraestrutura compartilhada entre as regiões. Há serviços e recursos que podem ajudá-lo com construções multirregionais. Por exemplo, você pode usar o Route 53, um serviço de DNS dimensionável da AWS, para rotear o tráfego entre diferentes regiões. Também pode usar recursos como as tabelas globais do DynamoDB e a S3 Cross-Region Replication para replicar seus dados entre as regiões.


    Conclusões

    • Use zonas de isolamento de falhas para limitar o raio de alcance das interrupções de serviço ou infraestrutura
    • O isolamento de falhas no nível de recurso e solicitação é integrado ao projeto de todo serviço da AWS. Não há exigência de ações adicionais da sua parte
    • O isolamento de falhas no nível de AZ é conseguido com a implantação de seus serviços em várias AZs. Isso pode ser feito com mínimo impacto na latência
    • O isolamento de falhas no nível de região é conseguido com a implantação de seus serviços em várias regiões. Isso exige sobrecarga operacional significativa


    Leituras complementares

  • Limites

    Os limites são restrições que podem ser aplicadas para proteger seus serviços contra carga excessiva. Eles são um meio eficaz de limitar o raio de alcance, tanto de incidentes externos (ex.: ataque DDoS) quanto internos (ex.: configuração incorreta do software).

    Os serviços da AWS têm limites específicos do serviço que variam por conta e por região. Esses limites também são conhecidos como cotas de serviço. São os valores máximos para determinados recursos, ações e itens em sua conta da AWS.

    Existem dois tipos de limites:

    • Limites flexíveis, que podem ser aumentados mediante solicitação de aumento dirigida à AWS
    • Limites rígidos que não são possíveis de aumentar

    Cada serviço tem diferentes limites. Para acompanhar os aumentos de seus limites e suas cotas, você pode usar o serviço Cotas de serviço.

    É importante monitorar os limites de serviço e saber quando está se aproximando deles para evitar interrupção do serviço. Em relação a alguns recursos, como execuções simultâneas do Lambda, é possível acompanhar pelo CloudWatch. Outros recursos, como o número de instâncias do EC2, precisam ser monitorados manualmente ou por meio de scripts. Você pode usar o serviço AWS Trusted Advisor para acompanhar seus limites se tiver um plano Business Support ou Enterprise Support. As ferramentas de código aberto, como o awslimitchecker, também podem ser usadas para automatizar o processo.


    Conclusões

    • Os limites são restrições que podem ser aplicadas para proteger um serviço contra carga excessiva
    • Os limites de serviço da AWS podem ser monitorados e gerenciados usando o serviço Cotas de serviço
    • Há limites flexíveis que podem ser aumentados e limites rígidos que não podem
    • Monitore os limites dos serviços que você está usando e planeje seus aumentos de limites da maneira adequada para evitar interrupção do serviço


    Leituras complementares

Conclusão

Neste módulo, você aprendeu sobre o pilar Confiabilidade da AWS. Você aprendeu sobre o modelo mental de pensar em termos de raio de alcance. Você aprendeu sobre o uso de zonas de isolamento de falhas para limitar o raio de alcance. Você aprendeu sobre limites de serviço e como aumentar os seus para evitar interrupção do serviço.

 

Leituras complementares

Excelência operacional

O pilar Excelência operacional prioriza meios de melhorar continuamente a capacidade de executar sistemas, criar melhores procedimentos e obter insights.


Modelo mental

Ao pensar a respeito da excelência operacional na nuvem, é útil pensar nela em termos de automação.

O erro humano é a principal causa de defeitos e incidentes operacionais. Quanto mais operações puderem ser automatizadas, menos chance de haver erro humano.

Além de evitar erros, a automação ajuda a melhorar continuamente seus processos internos. Ela promove um conjunto de melhores práticas que podem ser repetidas e aplicadas em toda a sua organização.


Conceitos

Quando você pensa nas operações como automação, você concentra seus esforços nas áreas que atualmente exigem o máximo de trabalho manual e podem ter a maior consequência em função dos erros. Você também terá um processo ativo para acompanhar, analisar e melhorar seus esforços operacionais.

Nos concentraremos nestes dois conceitos em relação à excelência operacional:

  1. Infraestrutura como código
  2. Observabilidade


  • Infraestrutura como código

    Infrastructure as code (IaC – Infraestrutura como código) é o processo de gerenciar sua infraestrutura por meio de arquivos de configuração legíveis por máquina. A IaC é a base que permite a automação de sua infraestrutura.

    Em vez de provisionar serviços manualmente, você cria modelos que descrevem os recursos que você quer. Em seguida, a plataforma de IaC assume o provisionamento e a configuração dos recursos em seu nome.

    A IaC oferece uma maneira declarativa e automatizada de provisionar a infraestrutura. Ela permite aplicar as mesmas ferramentas (ex.: git) e processos (ex.: revisão de código) na sua infraestrutura que você já aplica em seu código.

    A IaC na AWS é implementada tradicionalmente com o uso do serviço CloudFormation. O CloudFormation exige a declaração de seus recursos usando JSON ou YAML. Se essas linguagens de configuração não forem a sua praia, a AWS também fornece o Cloud Development Kit (CDK), que permite criar os modelos do CloudFormation usando linguagens de programação nativas, como JavaScript, Python e Java.

     

    Conclusões

    • IaC é o processo de gerenciar a infraestrutura por meio de arquivos de configuração legíveis por máquina
    • A IaC é uma maneira declarativa e automatizada de provisionar a infraestrutura
    • Você pode aplicar as mesmas ferramentas e processos em sua infraestrutura que já aplica em seu código
    • Use serviços como o CloudFormation e o CDK para implementar a IaC na AWS
     

    Leituras complementares

  • Observabilidade

    A observabilidade é o processo de medir o estado interno do seu sistema. Normalmente, isso é feito para otimizá-lo para algum estado final desejado.

    No que se refere à excelência operacional, não é possível melhorar o que você não mede. Criar uma sólida base de observabilidade permite acompanhar o impacto de sua automação e melhorá-la continuamente.

    A implementação da observabilidade envolve estas etapas:

    1. Coleta
    2. Estudo analítico
    3. Ação


    Coleta

    A coleta é o processo de agregar todas as métricas necessárias ao avaliar o estado do seu sistema.

    Essas métricas podem se enquadrar nas seguintes categorias:

    • Métricas em nível de infraestrutura
      • Essas métricas são emitidas automaticamente pelos serviços da AWS e coletadas pelo serviço CloudWatch
      • Alguns serviços também emitem logs estruturados que podem ser habilitados e coletados por meio do CloudWatch Logs
    • Métricas em nível de aplicação
      • Essas métricas são geradas pelo seu software e podem ser coletadas pelo CloudWatch Custom Metrics
      • Os logs de software podem ser armazenados usando o CloudWatch Logs ou enviados ao S3 por upload
    • Métricas em nível de conta
      • Essas métricas são registradas em log por sua conta da AWS e podem ser coletadas pelo serviço CloudTrail


    Estudo analítico

    Para analisar as métricas coletadas, você pode usar uma das muitas soluções de banco de dados e estudo analítico fornecidas pela AWS.

    Escolher a solução certa depende do seu caso de uso:

    • Para analisar logs armazenados no CloudWatch Logs, avalie a possibilidade de usar o CloudWatch Logs Insight, um serviço que permite pesquisar e analisar interativamente os dados em logs do CloudWatch
    • Para analisar os logs armazenados no S3, avalie a possibilidade de usar o Athena, um serviço de consultas sem servidor
    • Para analisar dados estruturados, considere o uso do RDS, um serviço de banco de dados relacional gerenciado
    • Para analisar grandes quantidades de dados estruturados, considere o uso do Redshift, um serviço de data warehouse gerenciado em escala de petabytes
    • Para analisar dados baseado em logs, avalie a possibilidade de usar o Elasticsearch Service, uma versão gerenciada do Elasticsearch, o conhecido mecanismo de estudo analítico de código aberto

     

    Ação

    Depois de ter coletado e analisado suas métricas, você poderá usá-las para alcançar um resultado ou processo específico.

    Veja estes exemplos de resultados e processos:

    • Monitoramento e alarmes
      • Você pode usar o CloudWatch Alarms para notificá-lo quando um sistema violar o limite de segurança de determinada métrica
      • Esse alarme pode acionar uma mitigação manual ou automatizada.
    • Painéis
      • Você pode criar painéis com suas métricas usando o CloudWatch Dashboards
      • Esses painéis podem ser usados para acompanhar e melhorar a performance do serviço no decorrer do tempo
    • Decisões impulsionadas por dados
      • Você pode acompanhar os KPIs de performance e empresariais para tomar decisões sobre produtos impulsionadas por dados

     

    Conclusões

    • A observabilidade é o processo de medir o estado interno do seu sistema para alcançar algum estado final desejado
    • A observabilidade consiste na coleta e análise de métricas, bem como na execução de ações com base nelas
    • Você pode coletar métricas em nível de serviço, aplicação e conta
    • Você pode analisar as métricas por meio de serviços como CloudWatch Log Insight, Athena, Elasticsearch Service, RDS e Redshift
    • Você pode agir com base em suas métricas criando monitoramento, alarmes e painéis para acompanhar os KPIs de performance e empresariais

     

    Leituras complementares

Conclusão

Neste módulo, você aprendeu sobre o pilar Excelência operacional. Você aprendeu sobre o modelo mental de pensar em nas operações como automação. Você aprendeu sobre a IaC e como ela pode ser usada para provisionar seus serviços automaticamente usando as mesmas ferramentas e processo que usa atualmente no código. Você aprendeu sobre a observabilidade e como coletar, analisar e agir com base em métricas para melhorar continuamente seus esforços operacionais.

 

Leituras complementares

Otimização de custos

O pilar Otimização de custos ajuda você a alcançar os resultados de negócios e minimizar os custos.


Modelo mental

Quando se trata de otimização de custos na nuvem, é interessante pensar nos gastos com a nuvem em termos de OpEx em vez de CapEx. OpEx é um modelo contínuo de pagamento conforme o uso, ao passo que CapEx é um modelo de compra único.

Os custos de TI tradicionais nos datacenters no local têm sido majoritariamente CapEx. Você paga antecipadamente por toda a capacidade, independentemente de usá-la ou não. A aquisição de novos servidores podia ser um processo demorado que exigia a aprovação de várias partes. Isso porque as despesas de CapEx eram geralmente altas, e os erros custavam caro. Depois de você efetuar uma compra, os servidores reais podiam ainda levar semanas para serem ativados.

Na AWS, seus custos são OpEx. Você paga continuamente pela capacidade que utiliza. O provisionamento de novos servidores pode ser feito em tempo real pela equipe de engenharia, sem necessidade de um processo de aprovação demorado. Isso ocorre porque os custos de OpEx são bem menores e podem ser revertidos se os requisitos mudarem. Como você paga somente pelo que usa, toda capacidade excedente pode ser simplesmente interrompida e encerrada. Quando você decide usar um serviço, o provisionamento pode ser realizado em questão de segundos e minutos.


Conceitos

Passar de um modelo CapEx para um modelo OpEx muda basicamente sua abordagem de custo da infraestrutura. Você troca altos custos fixos antecipados por pequenos gastos variáveis contínuos.

Esse modelo de pagamento conforme o uso introduz as seguintes mudanças no processo de otimização de custos:

  1. Pagamento pelo uso
  2. Ciclo de vida da otimização de custos


  • Pagamento pelo uso

    Os serviços da AWS têm um modelo de pagamento pelo uso, no qual você paga somente pela capacidade que utiliza. Estas são quatro maneiras comuns de otimizar seus gastos na nuvem com o modelo de pagamento pelo uso:

    1. Tamanho certo
    2. Sem servidor
    3. Reservas
    4. Instâncias spot


    Tamanho certo

    Tamanho certo refere-se à correspondência entre o provisionamento do serviço e a configuração da carga de trabalho. Para os serviços baseados em EC2, isso significa escolher a família e o tamanho certos de instância. Se a maioria dos seus recursos computacionais está ociosa, considere usar uma instância do EC2 menor. Se a carga de trabalho requer muitos recursos específicos do sistema, considere mudar para uma família de instâncias otimizada para esse recurso.

    Para ajudar nesse processo, você pode usar o AWS Compute Optimizer para obter sugestões do tamanho ideal do EC2, com base em métricas do sistema anteriores.


    Sem servidor

    Ao usar tecnologias sem servidor como o Lambda, você paga apenas pelo que usa. Se o Lambda não estiver em execução, você não será cobrado. O uso de tecnologias sem servidor é o verdadeiro exemplo de pagamento pelo uso. Quando o caso de uso permitir, a opção sem servidor pode ser a mais econômica para a criação do seu serviço.


    Reservas

    A solicitação de reservas significa um comprometimento com o pagamento de certo volume de capacidade em troca de um desconto significativo. Para o EC2, isso pode resultar em até 72% de desconto na computação.

    Para fazer reservas de computação, você pode usar Savings Plans. Você pode se registrar para um período de um ou três anos e assumir um compromisso de usar determinado volume de computação para economizar com o EC2, o Fargate e o Lambda.

    Note que as reservas não são exclusivas ao EC2 e que também não é possível solicitar outros serviços, como RDS, DynamoDB e CloudFront.


    Instâncias spot

    Instâncias spot do EC2 possibilitam usar capacidade do EC2 não utilizada para executar instâncias com um desconto de até 90% em relação ao preço das instâncias sob demanda. Isso pode resultar em uma imensa economia para cargas de trabalho tolerantes a falhas.

    A vantagem de usar uma instância spot é que o EC2 pode recuperar a capacidade a qualquer momento. Sua aplicação receberá um aviso de que o encerramento ocorrerá em dois minutos.


    Conclusões

    • Os serviços da AWS são pagos conforme o uso. Ou seja, você é cobrado pela capacidade que utiliza
    • Você pode ajustar o tamanho certo das instâncias para economizar nos serviços que não corresponderem à sua carga de trabalho
    • Você pode usar tecnologias sem servidor para pagar somente quando os clientes utilizarem o seu serviço
    • Você pode usar reservas para ganhar descontos em troca de um compromisso antecipado
    • Você pode usar instâncias spot para ganhar descontos na execução de cargas de trabalho tolerantes a falhas


    Leituras complementares

  • Ciclo de vida da otimização de custos

    Ciclo de vida da otimização de custos é o processo contínuo de aprimorar seus gastos na nuvem com o tempo.

    Ele envolve o seguinte fluxo de trabalho em três etapas:

    1. Analisar
    2. Monitorar
    3. Otimizar


    Analisar

    Para otimizar seus gastos na nuvem, primeiramente é preciso conhecer a origem desses gastos.

    O AWS Cost Explorer ajuda você a visualizar e analisar seus gastos na nuvem ao longo do tempo. Você pode desmembrar os gastos em diferentes aspectos, como serviço e categoria. Use o Cost Explorer para ter uma visão geral e também os relatórios detalhados de sua fatura.

    Se precisar de dados mais minuciosos, você pode ter acesso a itens de linha por hora usando o Relatório de custos e uso da AWS.


    Monitorar

    Quando você tiver uma visão geral dos seus gastos na nuvem, poderá começar a agrupá-los nas dimensões de seu interesse. Para isso, use o recurso de Tags de alocação de custos. Ele precisa ser ativado para cada tag a ser monitorada.

    Estes são exemplos comuns de categorias de tags:

    • ID da aplicação – Identifica os recursos que estão relacionados a determinada aplicação para facilitar o monitoramento de mudanças nos gastos e desativação no fim dos projetos.
    • Com/sem automação – Indica se um recurso deve ser incluído em uma atividade automatizada, como iniciar, interromper ou redimensionar instâncias.
    • Centro de custos/Unidade de negócios – Identifica o centro de custos ou a unidade de negócios associado a um recurso, normalmente para alocação e monitoramento de custos.
    • Proprietário – Identifica quem é responsável pelo recurso. Normalmente é o proprietário técnico. Se necessário, você poderá adicionar uma tag separada do proprietário dos negócios. Você pode especificar o proprietário como um endereço de e-mail. O uso de um endereço de e-mail aceita notificações automáticas para os proprietários técnicos e dos negócios, conforme o necessário. Por exemplo, se o recurso precisará de elasticidade ou tamanho certo.

    Além das tags, você pode usar Orçamentos da AWS para criar metas orçamentárias. Usando os Orçamentos, é possível monitorar seus gastos nas dimensões de seu interesse. Os Orçamentos monitoram e criam previsões dos seus atuais gastos da AWS de acordo com os filtros definidos.


    Otimizar

    Depois de analisar e monitorar seus gastos, você poderá otimizá-los. A otimização dos gastos envolve a implementação das técnicas abordadas em Pagamento pelo uso. Essa otimização normalmente integra uma meta orçamentária abrangente.

    Estes são exemplos de metas de otimização:

    • Porcentagem de instâncias do EC2 que são cobertas por um plano de redução de custos: sua organização deseja alcançar uma cobertura de 80% a 90%
    • Porcentagem de recursos ociosos: a definição da porcentagem exata e dos recursos ociosos varia de acordo com os negócios


    Conclusões

    • O ciclo de vida da otimização de custos é um processo contínuo de melhoria dos gastos na nuvem ao longo do tempo
    • O ciclo de vida da otimização de custos consiste em analisar, monitorar e otimizar os gastos
    • A análise dos gastos envolve o uso de ferramentas como o Cost Explorer e o relatório de custos e uso para entendimento dos gastos
    • O monitoramento dos gastos envolve tags de alocação de custos e orçamentos para filtrar os dados nas dimensões relevantes aos seus negócios
    • A otimização dos gastos envolve o uso das técnicas apresentadas na seção anterior, como parte de uma meta orçamentária abrangente


    Leituras complementares

Conclusão

Neste módulo, você aprendeu sobre o pilar Otimização de custos. Você aprendeu a aplicar um modelo OpEx a seus gastos de nuvem. Você aprendeu sobre as técnicas de otimização de custos, como tamanho certo, sem servidor, reservas e instâncias spot. Você aprendeu a analisar, monitorar e otimizar seu orçamento usando serviços, como Cost Explorer, tags e orçamentos.

 

Leituras complementares

AWS GovCloud (EUA)

Esta seção se refere às cargas de trabalho que devem atender à FedRAMP, DoD SRG, ITAR, CJIS ou outros requisitos de conformidade estrita, ou contenham dados classificados como Controlled Unclassified Information (CUI – Informações controladas não classificadas).

A AWS GovCloud (EUA) ajuda a lidar com a conformidade específica e as necessidades normativas dos órgãos governamentais norte-americanos nos níveis federal, estadual e local, bem como de organizações comerciais norte-americanas nos setores aeroespacial, de fabricação de defesas, de aplicação da lei, de saúde, de serviços financeiros, de energia e em outros setores altamente regulados. Criadas para hospedar dados confidenciais e cargas de trabalho reguladas na nuvem, as regiões AWS GovCloud (EUA) são regiões da AWS isoladas operadas por funcionários que são cidadãos norte-americanos em solo norte-americano.

As regiões AWS GovCloud (EUA) proporcionam aos clientes governamentais e seus parceiros a flexibilidade de arquitetar soluções seguras na nuvem que estejam em conformidade com o alto nível de referência da FedRAMP, a política de segurança dos Criminal Justice Information Systems (CJIS – Sistemas de informações da Justiça Criminal), os International Traffic in Arms Regulations (ITAR – Regulamentos do tráfego internacional de armas), os Export Administration Regulations (EAR – Regulamentos da administração de exportações), o Security Requirements Guide (SRG – Guia de requisitos de segurança) da computação em nuvem do Department of Defense (DoD – Departamento de Defesa) para Impacto nos níveis 2, 4 e 5, a FIPS 140-2, a IRS-1075 e outros regimes de conformidade.

Desde Controlled Unclassified Information (CUI – Informações controladas não classificadas), Personally Identifiable Information (PII – Informações de identificação pessoal), registros médicos confidenciais de pacientes e dados financeiros a dados de aplicação da lei, dados de exportação controlados e outras formas de CUI, as regiões AWS GovCloud (EUA) podem ajudar os clientes a lidar com a conformidade em todas as etapas de sua jornada para a nuvem.

 

Leituras complementares

Parabéns!

Você concluiu o curso Princípios básicos da AWS. Neste curso, você aprendeu o seguinte:

  • Os cinco pilares do AWS Well-Architected Framework
  • Modelos mentais importantes que representam uma maneira nativa da nuvem de pensar sobre os cinco pilares
  • Principais conceitos em cada um dos cinco pilares

Você aprendeu os princípios básicos da criação de serviços seguros, eficientes, confiáveis, operacionalmente excelentes e econômicos na nuvem. Apesar dessa visão superficial das questões importantes, você agora tem um ponto de partida sólido para continuar sua jornada na AWS. Depois de ter concluído o curso Princípios básicos da AWS, vá em frente e aplique o que aprendeu para criar o seu próximo excelente serviço na AWS.