O número máximo de layers que pode ser aplicado a uma AWS Lambda é de 10 layers.

O número máximo de layers que pode ser aplicado a uma AWS Lambda é de 5 layers.

O tamanho máximo em megabytes de uma AWS Lambda compactada, incluindo os layers e runtimes customizados é de 250 MB.

O tamanho máximo em megabytes de uma AWS Lambda descompactada, incluindo os layers e runtimes customizados é de 250 MB.

Quando é criada uma AWS Lambda, uma nova versão também é criada, seu número é incremental e gera um único Amazon Resouce Name ARN.

Quando é publicada uma AWS Lambda, uma nova versão também é criada, seu número é incremental e gera um único Amazon Resouce Name ARN.

O Lambda aliás é um apontador para uma versão específica da AWS Lambda, e pode ser utilizado no API Gateway como uma forma de evitar o vínculo com uma versão específica da função.

O Lambda aliás é um apontador para uma versão específica da AWS Lambda, e pode ser criado no API Gateway como uma forma de evitar o vínculo com uma versão específica da função.

O primeiro processo do cold start, é o download do código da função e de seus layers para o ambiente de execução.

O segundo processo do cold start, é a inicialização do ambiente onde o código é carregado para a memória e colocado em execução. Esse processo ocorre em todas as invocações da AWS Lambda.

O primeiro processo no warm start, é a invocação onde ocorre a inicialização do Runtime da linguagem de programação e a execução da função handler.

O último processo é o shutdown, que é a finalização do ambiente de execução da AWS Lambda e ocorre quando ela detecta que não há novas invocações para processar

Para fazer a criação de uma imagem de container Docker é necessário criar um arquivo Dockerfile contendo os passos para o build da imagem e utilizar o Amazon ECR para realizar o build da imagem.

Para fazer a criação de uma imagem de container Docker é necessário criar um arquivo Dockerfile contendo os passos para o build da imagem, utilizar o comando docker build e então utilizar o comando docker push a imagem para o Amazon ECR.

É possível utilizar uma imagem armazenada no Amazon ECS como imagem base para build de uma nova imagem docker.

É possível utilizar uma imagem armazenada no Amazon ECR como imagem base para build de uma nova imagem docker.

É um serviço gerenciado que oferece um repositório no padrão Git, que possui um mecanismo de versionamento similar ao oferecido pelo AWS S3.

É um serviço gerenciado que oferece um repositório no padrão Git, e também compatível com o padrão Subversion.

É um serviço gerenciado que oferece um repositório no padrão Git, e que armazena os arquivos criptografados utilizando o AWS Key Management Service (KMS).

É um serviço gerenciado que oferece um repositório no padrão Git, capaz de armazenar imagens de containers Docker.

Stage permite a configuração de controle e gerenciamento de acesso.

Stage permite referenciar com um nome uma versão publicada de uma API, habilitando a configuração de caching, logging e a definição de variáveis de staging.

Stage permite a geração de SDK em diversas linguagens para acelerar a integração de aplicações com suas APIs

Stage permite realizar a transformação do formato dos dados que são enviados pelos clientes da API.

Uma versão canary é uma estratégia de desenvolvimento de software na qual uma nova versão de uma API ou outro software é lançada lentamente como uma versão nova (ou de teste) de um aplicativo existente.

Uma versão canary é uma estratégia de desenvolvimento de software na qual uma nova versão de uma API ou outro software é lançada rapidamente como uma versão nova (ou de teste) de um aplicativo existente.

A opção de Canary release não deve ser habilitada no stage onde está a versão antiga da API.

A opção de Canary release deve ser habilitada no stage onde está a versão nova da API.

A estratégica canary mantém a versão atual do software em execução e destina um percentual das requisições para a nova versão, visando validade seu funcionamento.

A estratégia in-place, atualiza o software em cada uma das instâncias EC2 realizando o scale out.

A estratégia in-place, atualiza o software em cada uma das instâncias EC2 sem realizar o scale out.

A estratégia blue/green, realiza o scale out para provisionar novas instâncias EC2 com a nova versão do sistema e depois da verificação de health check, termina as instâncias antigas.

O AWS SAM é composto de dois componentes: uma especificação de template onde o desenvolvedor define todos os componentes e recursos da sua aplicação serverless, e o AWS SAM CLI que é uma ferramenta utilizada para criar, testar e publicar aplicações utilizando os templates.

Para testar uma aplicação desenvolvida com o AWS SAM você deve realizar a publicação dos recursos e da aplicação na AWS.

Os recursos definidos no template do SAM são traduzidos para um template no formato do CloudFormation que fica responsável por criar e atualizar as pilhas de recurso na AWS.

No AWS SAM, você pode usar apenas as linguagens de programação: Node.js, Java, Python e Go.