Principais serviços da AWS

O EC2 é o Amazon Elastic Compute Cloud, que fornece capacidade computacional redimensionável — ou seja, servidores virtuais (仮想サーバー). O S3 é o Amazon Simple Storage Service, que armazena qualquer quantidade de dados como objetos (オブジェクト). Trocar esses dois é uma confusão comum há muito tempo, por isso ajuda lembrar a função a partir do nome por extenso. Executar código de funções é a função do Lambda, e compartilhar arquivos é a função do EFS.

O Lambda permite executar código sem provisionar (プロビジョニング) nem gerenciar servidores, e você é cobrado (課金) apenas pelo tempo de computação que consumir. Não há cobrança enquanto o código não está em execução — essa é a grande diferença em relação ao EC2, em que há custo enquanto a instância continuar em execução. O número de funções ou o tamanho do código enviado, em si, não é a unidade de cobrança.

Sem servidor (サーバーレス) não significa que não exista servidor físico; significa que o cliente não precisa provisionar, configurar nem escalar servidores. O Lambda é descrito como algo que permite "executar código sem provisionar nem gerenciar servidores", e o Fargate como algo que elimina a necessidade de "provisionar, configurar ou escalar servidores ou clusters". O servidor físico existe do lado da AWS, e decidir o tipo de SO ou a política de patches é característico de uma forma como o EC2.

O Fargate é um mecanismo de computação sem servidor para contêineres, com pagamento conforme o uso (従量課金), que elimina a necessidade de provisionar, configurar ou escalar servidores ou clusters, e é usado como tipo de inicialização do ECS ou do EKS. A operação gerenciada de Kubernetes é o EKS; escolher você mesmo o tipo e a quantidade de instâncias é o tipo de inicialização EC2; e definir etapas como fluxo de trabalho é o Step Functions.

As opções básicas de capacidade (キャパシティ) do ECS são o Fargate, que é sem servidor e em que a AWS gerencia a infraestrutura de computação, e o EC2, em que o cliente escolhe e gerencia o tipo e a quantidade de instâncias. Há também o ECS Managed Instances e, para ambientes on-premises, o ECS Anywhere. Qualquer que seja a escolha, o ECS é o serviço que posiciona e escala os contêineres; o que muda é apenas quem cuida da infraestrutura de computação.

O EKS é o Amazon Elastic Kubernetes Service, um serviço gerenciado (マネージドサービス) que permite executar o Kubernetes na AWS sem instalar nem operar um cluster Kubernetes por conta própria, e é certificado como compatível com o Kubernetes. Automatizar a operação de bancos de dados é a função do RDS, entregar conteúdo a partir de um local próximo é a função do CloudFront, e distribuir o tráfego é a função do Elastic Load Balancing.

O Lambda permite executar código sem gerenciar servidores, com cobrança apenas pelo tempo de computação consumido e sem cobrança enquanto não está em execução. Por isso, para um processamento acionado de forma esparsa, o Lambda é vantajoso, porque não há custo durante o tempo ocioso de espera. Configurações que mantêm uma instância EC2 ou um cluster EKS em execução contínua geram custo durante os longos períodos em que nenhum processamento está ocorrendo.

O EC2 é oficialmente descrito como um serviço que fornece capacidade computacional segura e redimensionável na nuvem, em que você paga apenas pelo que usar e tem controle total sobre o recurso de computação (コンピューティングリソース). Ser cobrado apenas pelo tempo de execução e nunca mexer no SO descreve o Lambda; armazenar dados como objetos descreve o S3; e definir um fluxo de trabalho como estados descreve o Step Functions. A contrapartida desse controle amplo é que o gerenciamento do SO continua com o cliente, o que vale a pena ter em mente junto com isso.

O ECS é o Amazon Elastic Container Service, um serviço de orquestração de contêineres (コンテナオーケストレーション) totalmente gerenciado que facilita implantar, gerenciar e escalar aplicações em contêineres. Fornecer um cluster compatível com o Kubernetes é a função do EKS, iniciar instâncias de servidores virtuais é a função do EC2, e executar código em resposta a eventos é a função do Lambda. O ECS e o EKS agrupam contêineres, mas diferem quanto ao uso ou não do Kubernetes.

O EKS é um serviço gerenciado que permite executar o Kubernetes na AWS sem instalar nem operar um cluster Kubernetes por conta própria, e é certificado como compatível com o Kubernetes (Kubernetes 準拠). O ECS, por outro lado, é o serviço de orquestração de contêineres totalmente gerenciado da própria AWS, que não pressupõe o Kubernetes. Ambos são serviços que lidam com contêineres, e não serviços limitados a imagens de servidores virtuais. Como destino de execução, ambos também podem usar o Fargate.

O EBS é um volume de armazenamento em blocos (ブロックストレージ) persistente para uso com instâncias EC2, replicado automaticamente dentro de uma Zona de Disponibilidade (アベイラビリティゾーン) e, em princípio, anexado a uma única instância e usado por ela. O EFS é um sistema de arquivos para cargas de trabalho Linux que aumenta e diminui automaticamente e oferece acesso compartilhado paralelo a partir de milhares de instâncias EC2. O compartilhamento é uma capacidade do EFS; não é verdade que ambos sejam para compartilhamento, nem que ambos sejam exclusivamente para uma única conexão.

O S3 é o Amazon Simple Storage Service, um armazenamento de objetos (オブジェクトストレージ) com excelente escalabilidade e disponibilidade, capaz de armazenar e proteger qualquer quantidade de dados. O armazenamento em blocos é o EBS, o sistema de arquivos compartilhado para Linux é o EFS, e o cache em memória é o ElastiCache. A distinção entre essas três formas de guardar dados — objeto, bloco e arquivo — é o ponto de partida para escolher o armazenamento na AWS.

O EFS é um armazenamento de arquivos cuja capacidade aumenta e diminui automaticamente conforme o número de arquivos e que oferece acesso compartilhado paralelo a partir de milhares de instâncias EC2, por isso se encaixa no caso de uso de montar o mesmo diretório a partir de muitas instâncias ao mesmo tempo. O EBS é um armazenamento em blocos dentro de uma Zona de Disponibilidade (アベイラビリティゾーン) que, em princípio, é anexado a uma única instância, dando a cada instância uma área separada. O Glacier Deep Archive é uma classe de arquivamento projetada para recuperação lenta, e o ElastiCache é um cache em memória, e não um sistema de arquivos.

O EBS é um armazenamento em blocos persistente para instâncias EC2, replicado automaticamente dentro de uma Zona de Disponibilidade (アベイラビリティゾーン), que oferece desempenho consistente e de baixa latência (レイテンシ). Por causa dessa propriedade de AZ única, é necessário outro mecanismo se for exigida disponibilidade entre AZs. Replicar entre Regiões ou entregar a partir de localizações de borda não é a função do EBS.

O S3 Glacier é um grupo de classes de armazenamento (ストレージクラス) para arquivamento: o S3 Glacier Instant Retrieval, para dados que precisam de recuperação imediata; o S3 Glacier Flexible Retrieval, para dados de longo prazo raramente acessados; e o S3 Glacier Deep Archive, que recupera ao menor custo ao longo de algumas horas. O projeto permite escolher a classe com base no equilíbrio entre velocidade de recuperação e custo, por isso o tempo de recuperação não é uniforme. Não há restrição quanto ao tipo de dado que pode ser armazenado, e ele não é usado anexando-o como armazenamento em blocos.

O S3 é um armazenamento de objetos (オブジェクトストレージ), o EBS é um armazenamento em blocos (ブロックストレージ) anexado ao EC2, e o EFS é um armazenamento de arquivos para cargas de trabalho Linux. Ajuda pensar nos objetos como coisas que entram e saem inteiras por meio de uma API, nos blocos como algo que o SO enxerga como um disco, e nos arquivos como algo que pode ser montado e compartilhado por vários hosts — essa forma de organizar facilita escolher com segurança com base nos requisitos.

O EBS é um armazenamento em blocos (ブロックストレージ) persistente para uso com instâncias EC2 que oferece desempenho consistente e de baixa latência, o que o torna adequado para uso como disco do SO ou de banco de dados. O S3 é um armazenamento de objetos e não anexa um bucket como dispositivo de blocos. O Glacier é uma classe de arquivamento projetada para recuperação lenta, e o CloudFront é uma CDN para acelerar a entrega.

O S3 é um armazenamento de objetos (オブジェクトストレージ) capaz de armazenar e proteger qualquer quantidade de dados, com excelente escalabilidade, disponibilidade, segurança e desempenho, e a AWS lista oficialmente casos de uso como web, dispositivos móveis, backup, arquivamento, IoT e análise de big data. Ser visto pelo SO como um disco é uma propriedade do EBS, estar restrito em princípio à conexão com uma única instância também é uma propriedade do EBS, e manter os dados na memória é uma propriedade do ElastiCache.

O EFS é um sistema de arquivos simples, escalável e elástico (エラスティック), cuja capacidade aumenta e diminui automaticamente à medida que arquivos são adicionados e removidos, eliminando a necessidade de planejar a capacidade com antecedência. Fixar antecipadamente uma capacidade definida, ou reconstruir para ampliá-la, reflete a lógica do armazenamento em blocos, e o tamanho da memória da instância conectada também não determina a capacidade. É essa elasticidade que torna o EFS fácil de usar como área de trabalho compartilhada.

O S3 Glacier Deep Archive armazena dados raramente acessados ao menor custo, com recuperação que leva algumas horas, por isso atende a essa condição. O EBS e o EFS são projetados para preservar a velocidade de recuperação e tendem a sair caros como local para dados que ficam inativos por muito tempo. O ElastiCache é um cache em memória (インメモリキャッシュ) e, para começar, não é um mecanismo de armazenamento de longo prazo. Decidir antes quanto tempo de espera pela recuperação é aceitável é a lógica que orienta a escolha da classe de armazenamento.

O RDS é um serviço gerenciado (マネージドサービス) que facilita configurar, operar e escalar um banco de dados relacional na nuvem, automatizando tarefas de gerenciamento como o provisionamento (プロビジョニング) de hardware, a configuração do banco de dados, a aplicação de patches e os backups. Projetar tabelas e colunas, decidir sobre índices, construir a aplicação e validar a correção do conteúdo dos dados continuam sendo trabalho do cliente. "Gerenciado" significa que o trabalho operacional é delegado, e não que o projeto também seja delegado.

O Aurora faz parte do Amazon RDS, o serviço gerenciado de banco de dados, e usa o mesmo console de gerenciamento, a mesma CLI e as mesmas operações de API para provisionamento, aplicação de patches, backup, recuperação e detecção de falhas. A diferença está na unidade de gerenciamento: o RDS padrão gerencia instâncias de banco de dados individuais, enquanto o Aurora gerencia um cluster (クラスター) inteiro de servidores de banco de dados mantidos em sincronia por replicação. O Aurora é um banco de dados relacional compatível com MySQL e PostgreSQL, e não um banco de dados do tipo chave-valor.

O DynamoDB é um banco de dados NoSQL de chave-valor (キーバリュー型) e de documentos (ドキュメント型), totalmente gerenciado e multirregional, que oferece desempenho de milissegundos de um dígito em qualquer escala. O data warehouse é o Redshift, o banco de dados relacional compatível com MySQL e PostgreSQL é o Aurora, e a leitura e gravação em memória é o ElastiCache.

O Redshift é um serviço de data warehouse (データウェアハウス) totalmente gerenciado, em escala de petabytes, na nuvem, que oferece consultas rápidas a partir de ferramentas existentes baseadas em SQL ou de aplicações de BI, independentemente do tamanho do conjunto de dados. O ElastiCache é um cache em memória, o EFS é um sistema de arquivos compartilhado e o SQS é uma fila de mensagens — nenhum deles é uma plataforma para agregar e analisar grandes volumes de dados.

O ElastiCache é um serviço que facilita implantar, operar e escalar um cache em memória (インメモリキャッシュ) na nuvem, melhorando o desempenho de aplicações web ao recuperar informações de um cache em memória rápido em vez de depender de um banco de dados baseado em disco. Acelerar consultas analíticas é trabalho do Redshift, reduzir o custo de armazenamento de longo prazo é trabalho das classes do S3 Glacier, e compartilhar um diretório é trabalho do EFS.

O Aurora é um mecanismo de banco de dados relacional totalmente gerenciado, compatível com MySQL e PostgreSQL, com um subsistema de armazenamento distribuído e compartilhado (分散共有ストレージ) de alto desempenho, e seu armazenamento se expande automaticamente conforme a necessidade. Não é preciso definir a capacidade antecipadamente e ampliá-la manualmente. Armazenar dados como pares chave-valor é o DynamoDB, e manter o armazenamento barato em troca de uma recuperação demorada é uma classe de arquivamento do S3 Glacier.

O Redshift é um serviço de data warehouse (データウェアハウス) totalmente gerenciado, em escala de petabytes, adequado para agregar e analisar grandes volumes de dados a partir de ferramentas baseadas em SQL ou de aplicações de BI. O RDS é um serviço que facilita configurar, operar e escalar um banco de dados relacional, adequado para um sistema de negócios que lê e grava as transações do dia a dia. Ambos são consultados com SQL, o que pode fazê-los parecer semelhantes, mas nenhum deles é NoSQL, e a diferença não é apenas de volume de dados.

O DynamoDB é um banco de dados NoSQL de chave-valor (キーバリュー型) e de documentos, descrito oficialmente como capaz de oferecer desempenho de milissegundos de um dígito em qualquer escala. O Redshift é um data warehouse adequado para agregar e analisar grandes volumes de dados, o RDS é um serviço para leitura e gravação no modelo relacional e o EFS é um armazenamento para compartilhar arquivos — nenhum deles tem esse requisito como objetivo principal.

O RDS é o Amazon Relational Database Service, um serviço gerenciado (マネージドサービス) que facilita configurar, operar e escalar um banco de dados relacional (リレーショナルデータベース) na nuvem. Armazenar dados como pares chave-valor é o DynamoDB, o cache em memória é o ElastiCache, e agregar grandes volumes de dados é trabalho do data warehouse Redshift. Observe que o Aurora é um mecanismo oferecido como parte do RDS.

O Aurora é oferecido como parte do RDS, e o provisionamento, a aplicação de patches, o backup, a recuperação e a detecção de falhas podem ser feitos com o mesmo console de gerenciamento (マネジメントコンソール), a mesma CLI e as mesmas operações de API. Não é preciso criar uma instância de gerenciamento separada, nem o cliente precisa construir esses procedimentos por conta própria. A diferença em relação ao RDS padrão, que gerencia instâncias de banco de dados individuais, é que o Aurora trata o cluster inteiro como unidade de gerenciamento.

O SQS é um serviço ponto a ponto (ポイントツーポイント) que retém mensagens em uma fila (キュー), normalmente retiradas por um único consumidor que a consulta periodicamente (polling). O SNS é um serviço pub/sub (パブサブ) em que os publicadores enviam mensagens a um tópico (トピック), que são enviadas por push simultaneamente a vários assinantes. Trocar os dois é uma confusão clássica, e não é verdade que ambos entregam da mesma forma. Ajuda lembrar a direção: a fila é um lugar onde o receptor vai buscar, e o tópico é um distribuidor que o remetente usa para empurrar as mensagens.

O SQS tem filas padrão (標準キュー) e filas FIFO (FIFO キュー). As filas padrão oferecem entrega at-least-once (pelo menos uma vez), então a mesma mensagem pode chegar mais de uma vez. As filas FIFO oferecem processamento exactly-once (exatamente uma vez) e preservação da ordem, de modo que a ordem de envio é mantida e cada mensagem é processada exatamente uma vez. Para fluxos de trabalho em que a ordem e a prevenção de perdas são importantes, a escolha é uma fila FIFO.

O SNS envia por push uma mensagem enviada a um tópico simultaneamente a vários assinantes (サブスクライバー), e uma fila do SQS pode ser especificada como assinante. Esse formato, de um tópico do SNS para várias filas do SQS, é o padrão fan-out (ファンアウトパターン) apresentado oficialmente como a abordagem padrão. A fila é o lado receptor, e não uma origem de entrega, por isso a direção nunca vai da fila para o tópico.

Os tipos de assinante (サブスクライバー) do SNS se organizam em dois grupos: A2A, que significa destinos de aplicação para aplicação, como SQS, Lambda, HTTP(S) e Data Firehose; e A2P, que significa destinos de aplicação para pessoa, como e-mail, push para dispositivos móveis e SMS. Não fica limitado a um dos dois, nem é um mecanismo restrito a instâncias EC2 como destino. Essa amplitude é o motivo pelo qual o SNS é usado tanto para notificar pessoas quanto para conectar aplicações.

O Step Functions é um serviço que permite criar fluxos de trabalho (ワークフロー), ou seja, máquinas de estados (ステートマシン), possibilitando a construção de aplicações distribuídas, a automação de processos, a orquestração de microsserviços e a criação de pipelines de dados ou de aprendizado de máquina. Cada etapa é chamada de state (estado), e uma instância em execução é chamada de execution (execução). Distribuir o tráfego é trabalho do Elastic Load Balancing, armazenar objetos é trabalho do S3, e o cache de pares chave-valor é domínio do ElastiCache.

O API Gateway é um serviço para criar, publicar, manter, monitorar e proteger APIs REST, HTTP e WebSocket em qualquer escala, funcionando como a porta de entrada (フロントドア) para o acesso a backends como cargas de trabalho no EC2, o Lambda ou qualquer aplicação web. Executar o processamento em si é trabalho do backend, aplicar regras de proteção de forma centralizada entre contas é trabalho do AWS Firewall Manager, e o cache na borda é função do CloudFront.

O EventBridge é um serviço sem servidor (サーバーレス) que conecta os componentes de uma aplicação por meio de eventos, cuidando da ingestão, filtragem, transformação e entrega de eventos. Um barramento de eventos (イベントバス) é um roteador que encaminha eventos de muitas origens para muitos destinos. A fila descreve o SQS, a máquina de estados descreve o Step Functions, e a porta de entrada descreve o API Gateway.

O EventBridge Scheduler é um mecanismo para gerenciar invocações recorrentes e únicas usando expressões cron (cron 式) ou expressões rate (rate 式), por isso a invocação agendada em horários fixos é tratada aqui. O SQS é uma fila que retém mensagens para que um receptor as retire, o SNS é a entrega pub/sub aos assinantes, e o API Gateway é um serviço para publicar e repassar APIs — nenhum deles se destina à invocação baseada em horário.

O SQS é um serviço de filas hospedado, seguro, durável e altamente disponível, que permite integrar e desacoplar (疎結合化) sistemas e componentes de software distribuídos. O lado do recebimento pode responder assim que coloca uma mensagem na fila, e o processamento posterior pode retirá-la e prosseguir em seu próprio ritmo, de modo que um atraso em um lado dificilmente paralisa o outro. Em uma configuração de chamada direta ou de programa único, um atraso no processamento posterior se transforma em tempo de espera para o lado do recebimento.

O SNS envia por push uma mensagem enviada a um tópico simultaneamente a vários assinantes, e uma fila do SQS pode ser especificada como assinante, por isso entregar um evento a três processamentos exige o padrão fan-out (ファンアウトパターン) de um tópico do SNS com várias filas do SQS. Se três processamentos compartilharem uma fila, normalmente, assim que um deles retira um item, os outros não conseguem recebê-lo. Fazer a origem enviar três vezes, ou fazer o processamento receptor encaminhar a mensagem, significa que o remetente precisa ser modificado toda vez que um destino é adicionado, o que não é baixo acoplamento.