Redes - ribeiry/AWS-Professional-Study GitHub Wiki

VPC

Route Table

• Associada por default a uma VPC,
• Não tem por padrão saída para internet

Principal conceitos de Route Table

• Principal Route Table - O Route Table que vem com a sua VPC. O seu controle roteia para todas as subnets que não são explicitamente associadas com outra route table.

• Route Table custom - Um Route Table que é criado para a sua VPC

• Destino - O range do endereço IP aonde voce queira que seu trafego irá (destino CIDR. Por exemplo, uma corporação de rede externa com CIDR 172.16.0.0/12

• Alvo - O gateway, network interface ou conexões através com o envio do trafego de destino, por exemplo um internet gateway.

• Associação de Route Table - A associação entre um route table e um subnet, internet gateway ou virtual private gateway.

• Subnet Route Table - Um Route Table que é associada a sua subnet.

• Local Route - Um padrão de rota para comunicação com a VPC.

• Propagação - Propagação de rota que permite um virtual private gateway para propagar a rota automaticamente no route table. Isso significa que você não precisa inserir manualmente rotas de VPN para a sua route table.

• Gateway Route Table - Uma Route Table que é associada com um internet gateway ou virtual private gateway;

• Edge Associação - Um Route Table que voce usa para uma rota de entrada de trafego da sua VPC para um aparelho. Voce associa uma tabela de rota com o internet gateway ou virtual private gateway, e especifica o network interface de seu aparelho como target para o trafego da sua VPC.

• Transit gateway Route Table - Um Route Table que é associado com um transit gateway.

• Local Gateway Route Table - Um Route Table que é associado associado a um gateway local Outposts

Subnet Route Table

Sua VPC tem uma routa implicita, e voce usa o controle de route table aonde o trafego de rede é direcionado. Cada subnete em sua VPC deve ser associado com uma route table, com controles de routa para a subnete(sunete route table). Voce pode explicitar associada a um subnete com uma route table particular. Por outro lado, a subnete é implicitamente associada com uma tabela de rota principal. A subnete pode somente ser associada como uma route table até o momento, mas voce pode associar multiplas subnetes com a mesma route table. Subnets que são associadas na VPC com Outposts que pode adicionalmente como tipo de target de um gateway local. Isso é somente em routa diferente para uma não Subnete Outposts.

NAT Gateway e NAT Instance

• são utilizadas a nível de subnet, e serve primariamente para dar acesso a uma ou mais instancias EC2 da sua subnete privada para a internet ou outros serviços AWS, mas evita que a haja conexão da internet com todas as instancias da sua subnet privada.

• Necessário Internet Gateway anexado à VPC para que hava saída para internet através do NAT Instance ou NAT Gateway.

• Trobleshoot steps para resolver problema de falta de conectividade entre uma NAT Instance e a Internet (Desabilitar o Source Destination]

    	+------------------------+--------------------------------------+--------------------------------------------------------------+
    	|                        | NAT GATEWAY                          |     NAT INSTANCES                                            |
    	+------------------------------------------------------------------------------------------------------------------------------+
    	|Gerenciamento           |Gerenciado pela AWS                   |Gerenciado por você                                           |
    	|Disponibilidade         |Altamente disponivel dentro de uma AZ |Não está altamente disponivel(requer script)                  |
    	|Largura da Banda        |Maior para 45 Gbps                    |Dempende da largurada da banda de sua EC2 do tipo selecionado |
    	|Manutenção              |Mantido pela AWS                      |Gerenciado por você                                           |
    	|Performance             |Otimizado pelo NAT                    |AMI configurado para performance NAT                          |
    	|IP Publico              |Elastico IP não pode ser desanexado   |Elastico IP que pode ser desanexado                           |
    	|Security Groups         |Não pode associar com um Security Grou|Pode associar com um Security Group                           |
    	|Bastion Host            |Não Suportado                         |Pode ser usado como um bastion Host                           |
    	|Encaminhamento de porta |Não Suportado                         |Suporta                                                       |
    	+------------------------------------------------------------------------------------------------------------------------------+
  

VPC Endpoint (PrivateLink)

• Útil para um serviço acessar outro serviço ou recurso na AWS e não tenha que sair para internet, e a conexão fique dentro da rede interna da AWS.
• VPC Gateway Endpoint -> S3 e DynamoDB
• VPC Interface Endpoint -> Para todo o restante.
  • Para uso de VPC Endpoint entre diferentes regiões é necessário o VPC Peering
  • O EC2 não consegue resolver o DNS Name atrelado a um Interface endpoint, pois ele usa Domain Controller e DCs não tem registro para o interface endpoint. Neste cenário uma solução pode ser alterar o DC para encaminhar consultas não autoritativas para o VPC Resolver, ou modificar o DHCP das as instancias EC2 para usar os servidores de DNS oferecidos pela AWS
• Um Gateway Load Balancer endpoint é um elastic network interface que com um endereço de IP privado de um range de endereço de IP privado na sua subnet. Esse servidores são um entry point para intecerptar um trafico e routa é um rede ou serviço de segurança que voce configurou usando um gateway load balancer. Voce especifica um gateway load balancer endpoint como um alvo para uma tabela de rota. Gateway load balancer endpoint são suportados somente para endpoint de serviços que são configurados usando um gateway load balancer.

VPC Endpoint Service

• VPC endpoint services for interface endpoints

• VPC endpoint services for Gateway Load Balancer endpoints

Quando voce cria uma VPC endpoint service, nos geramos um endpoint DNS hostnames que voce pode usar para comunicar com esse service. Estes nomes incluem o VPC endpoint ID, o Availability Zone nome e Região Name. Por default, seu consumidores podem acessar os serviços com que o DNS name e usualmente precisa para modificar a configuração aplicação. Se um endpoint service é um serviço para um AWS Service, ou a serviço disponivel no AWS Marketplace, aonde por default DNS name. Para outro serviços, o serviço provider pode configurar um private DNS name para consumidores poder acessar esses serviços usando um existente DNS name sem fazer mudanças da sua aplicações. Servicos providers pode especificar um private DNS name para um novo endpoint service, ou um existente endpoint service. Para usar um private DNS name, habilitar a feature, e especificar um private DNS name. Antes consumidores pode usar um private DNS name, voce deve verificar que voce pode controle de dominio/subdominio. voce pode iniciar um domino propriedade de verificação usando o Amazon VPC console ou API. Depois do dominio de propriedade verificação completa, consumidores pode acessar o endpoint usando o private DNS name.

Tipos de Endpoints Services

Você pode usar dois tipos de endpoint da VPC para acessar o Amazon S3: endpoints de gateway e endpoints de interface (com o uso do AWS PrivateLink). Um endpoint de gateway é um gateway que você especifica em sua tabela de rotas para acessar o Amazon S3 da sua VPC pela rede da AWS. Os endpoints de interface estendem a funcionalidade dos endpoints de gateway usando endereços IP privados para rotear solicitações para o Amazon S3 de dentro da sua VPC on-premises ou de uma PVC em outra Região da AWS usando emparelhamento da VPC ou o AWS Transit Gateway. Os endpoints de interface são compatíveis com os endpoints de gateway. Se você tiver um endpoint de gateway existente na VPC, poderá usar ambos os tipos de endpoints na mesma VPC.

Endpoints gateway para o S3	Endpoints de interface para o S3
Em ambos os casos, o tráfego de rede permanece na rede AWS.
Usar endereços IP públicos do Amazon S3	Usar endereços IP privados da VPC para acessar o Amazon S3
Usar os mesmos nomes DNS do Amazon S3	Exigir nomes DNS do Amazon S3 específicos do endpoint
Não permite o acesso a partir do local	Permitir acesso desde on-premises
Não permitir o acesso usando outra Região da AWS	Permitir acesso de uma VPC em outra Região da AWS usando emparelhamento da VPC ou AWS Transit Gateway
Não faturado	Faturado

VPC Peering

• É a conexão entre duas VPC
• Não é possível configurar uma conexão de peering de VPC com outra VPC se houver intervalos de endereços IP sobrepostos. Esse fato é verdade mesmo se você adicionar intervalos de endereços IP (CIDR) adicionais.
• VPC Peering não suporta rota EDGE-TO-EDGE

VPC Share with RAM (Resource Access Manager)

• O compartilhamento de VPC permite que várias contas da AWS criem os próprios recursos de aplicações, como instâncias do Amazon EC2, bancos de dados do Amazon Relational Database Service (RDS), clusters do Amazon Redshift e funções do AWS Lambda, em Amazon Virtual Private Clouds (VPCs) compartilhadas e gerenciadas centralmente. Nesse modelo, a conta que possui a VPC (proprietária) compartilha uma ou mais sub-redes com outras contas (participantes) que pertencem à mesma organização no AWS Organizations. Quando uma sub-rede é compartilhada, os participantes podem visualizar, criar, modificar e excluir os recursos de seus aplicativos nas sub-redes compartilhadas com eles. Os participantes não poderão visualizar, modificar ou excluir recursos que pertencerem a outros participantes ou proprietários da VPC.

• Também é possível compartilhar suas VPCs para aproveitar o roteamento implícito em uma VPC para aplicações que exijam um alto grau de interconectividade e que estão dentro dos mesmos limites de confiança. Isso reduz o número de VPCs que você cria e gerencia, enquanto ainda usa contas separadas para faturamento e controle de acesso. Os clientes podem simplificar as topologias de rede interconectando Amazon VPCs compartilhadas por meio de recursos de conectividade, como AWS PrivateLink, gateways de trânsito e emparelhamento de VPCs. Para obter mais informações sobre os benefícios de compartilhamento de VPC

Transit Gateway

• O AWS Transit Gateway conecta VPCs e suas redes locais por meio de um hub central simplificando a dificuldade no emparelhamento a medida que sua rede cresce. Ele atua como um roteador de nuvem e cada nova conexão só é feita uma vez. À medida que você se expande globalmente, o emparelhamento entre regiões conecta os AWS Transit Gateways usando a rede global da AWS. Seus dados são automaticamente criptografados e nunca trafegam pela Internet pública.
• Suporta Multicast

Multicast ou broadcast internet

• VPC não suporta multicast ou broadcast, para isso deve ser criado um virtual overlay network running on the OS level of the instance.

Internet Gateway

• Egress-Only (Somente saída) - IG somente saída é um componente da VPC horizontalmente escalado, redundante e altamente disponível que permite a comunicação de saída pela IPv6 das instancias na VPC para internet e impede a Internet de iniciar uma conexão IPv6 com suas instancias.
• Obs.: Para habilitar a comunicação Egress-Only (somente saída pela IPv4), use um NAT gatway

VPC Egress Only

• Para centralizar, criamos uma VPC de saída na conta de serviços de rede e roteamos todo o tráfego de saída das VPCs spoke por meio de um NAT Gateway localizado nessa VPC, aproveitando o Transit Gateway

• Obs.:

• O Transit Gateway não é um balanceador de carga e não distribuirá seu tráfego uniformemente entre instâncias em duas AZs. O tráfego no Transit Gateway permanecerá dentro de uma AZ, se possível. Você está limitado pelos recursos de largura de banda de uma única instância do EC2. Você pode dimensionar verticalmente essa instância do EC2 à medida que o uso aumenta.

• Se o fornecedor escolhido para inspeção de tráfego de saída não oferecer suporte à automação para detecção de falhas ou se você precisar de dimensionamento horizontal, poderá usar um design alternativo. Não criamos um anexo de VPC no gateway de trânsito para VPC de saída, em vez disso, criamos um anexo de VPN IPsec e criamos uma VPN IPsec do Transit Gateway para as instâncias do EC2, aproveitando o BGP para rotas de troca e balanceamento.

• Vantagens:

  • Detecção de falhas e reencaminhamento de tráfego tratado pelo BGP. Nenhuma automação de tabela de rotas de sub-rede VPC é necessária.
  • O BGP ECMP pode ser usado para balancear a carga do tráfego em várias instâncias do EC2 — é possível dimensionar horizontalmente.

VPC Flow Logs

• Útil para diagnóstico de restrição de Security Groups, identificar trafego de entrada e saída, O VPC Flow Logs é um recurso Aplicável ao nível de Interface de Rede, Subnet ou VPC. Seus logs podem ser enviados para o S3 ou CloudWatch para posterior análise

Publicando em um CloudWatch Logs

Você pode publicar para um CloudWatch Logs, flow log o dado é publicado para um log group, e cada interface de rede tem um unico log stream que esta em log group. Log Stream contém gravações de flow log. Voce pode criar multiplos flow log que publica um dado para o mesmo log group. Se a mesma network interface é presente em um ou mais flow logs no mesmo log group, e tem um combinado de log strea. Se voce especifica um flow loga deve capturar trafegos rejeitados, e o outro flow log deve capturar o trafego aceitados, quando combinado a captura de log stream para todos os trafegos.

As cobranças de ingestão de dados e arquivamento para logs vendidos se aplicam quando você publica logs de fluxo no CloudWatch Logs.

No CloudWatch Logs, o campo timestamp corresponde o inicio da hora que é capturado na gravação do flow log. A ingestão do campo Time indica a data e hora quando a gravação do flow logs é recebidos pelo CloudWatch Logs. Esse timestamp é posterior à hora de término capturada no registro do log de fluxo.

Publicando em um Bucket S3

Quando você publica em um S3, dado flow log é publicado para um bucket existente que voce especifica. Flow log grava todos os dados da network interface monitorada são publicadas em uma serie de logs de arquivos para uma serie de log de arquivos que são armazenados em um bucket. Se o flow log captura o dado para um VPC, o flow log publica o flow log e grava todas as network interface na VPC selecionada.

Arquivos de Flow log

VPC Flow logs coleta e grava, consolidados então dentro do arquivo de log, e então publica o arquivo de log em um S3 bucket com intervalos de cada 5 minutos. Cada arquivo de log contem informações para o trafego de IP nos cinco minutos anteriores.

O tamanho maximo de um arquivo de log é de 75 MB. Se um arquivo de log alcança o tamanho limite com o periodo de 5 minutos, o flow log para de adicionar dados nele. Então ele publica o flow log no S3 bucket e cria um novo arquivo de log.

Em um S3 bucket, o ultimo campo modificado para o arquivo flow log indica que a data e hora no momento que o arquivo foi atualizado para o S3 bucket. Depois o timestamp no nome do arquivo, e dferencia a quantidade de horas para se subir o arquivo no bucket.

Formato do arquivo de Log

Voce pode especificar um dos seguintes formatos de arquivo de logs. Cada arquivo é comprimido dentro de um unico arquivo de GZIP.

• Text - Plain text. Este é o formato padrão;
• Parquest - Apache Parquet é um formato de dados colunar. Queries de dados em formato Parquet são 10 até 100 vezes mais rapido comparando uma querie em um arquivo de texto. Dados em formato Parquet com comprimido no formato GZIP leva 20% menor de armazenamento de espaço comparado ao GZIP de um arquivo texto.

Opções de arquivos de Log

Voce pode optar especificamente seguindo as opções.

• Prefixo S3 compativel com HIVE- Habilita a compatibilidade com HIVe prefixos ao inves de importar partições dentro do seu HIVE. Antes de voce rodar queries use o comando MSCK REPAIR TABLE.

• Partições por hora- Se você tem um grande volume de logs e tipicamente alvos queries para uma especifica hora, voce pode ter um resultado mais rapido e economizando particionando o seus logs por hora.

Log file S3 bucket structure

Arquivos de logs são salvos no S3 bucket usando uma estrutura de pasta que é baseada em flow log's ID, Região, data de criação e opção de destinação.

CIDR

• Uma VPC suporta entre um range de IPs entre /16 e /28
• Um novo bloco de CIDR pode ser adicionado para expandir a VPC, caso a quantidade de IPs disponíveis tenha acabado

Subnets

• Subnet Publica : É acessível através da internet
• Subnet Privada : Por default, não é acessível através da internet
• DB Subnet Group : Grupo de subnets (tipicamente privadas) que vc destina a sua instancia de DB, e não tem acesso através da internet, mesmo que o grupo seja de subnets publicas.

IPAM ( IP Address Manager)

Amazon VPC IP Address Manager (IPAM) é uma feature de VPC que habilita facilmente para voce planejar, rastrear e monitorar o endereço de IP para o seu workload. Voce pode usar IPAM para automatizar com mais eficiencia o seu gerenciamento de IP. Voce pode usar o IPA da seguinte formas:

• Organizando o seu endereço de IP dentro da rota e dominio de segurança;
• Monitorando o endereço de IP que usa e monitora os recursos que são usados no espaço contra a regra de negocios;
• Visualizar a historia do endereço de IP para assinar em sua organização;
• Alocação automatica de CIDR's para VPC usando regras de negocios especificas;
• Troubleshoot de conectividade de redes;
• Habilitar cross-region e cross-account compartilhando o seu endereço de ip através Bring Your Own IP (BYOIP)

Seguindo o diagrama abaixo mostra como o pool de um IPAM hierarquico para multiplas regiões AWS com um topo de nivel de IPAM pool. Cada pool de região tem dois IPAM desenvolvido com um pool para pré-produção e um pool para recursos de produção.

Para usar VPC IP Address Manager, voce primeiro cria um IPAM.

Quando voce criar um IPAM, você escolhe qual região voce irá criar-lo. Quando você criar um IPAM, AWS VPC IPAM automaticamente cria dois scopes para um IPAM. O escopo, junto com pools e alocações, são chaves de componentes do seu IPAM.

Um escopo é container de auto nivel contendo um IPAM. Um IPAM contain por padrão dois escopos. Cada escopo representa um espaço de IP para uma unica rede. O escopo privado é intencionada para todos os space privado. O escopo publico é intencionado para espaço publico. Escopo habilita o seu reuso de endereço de IP através multiplas redes não conectadas sem causar o overlap de IP ou conflitos de IP. Com um escopo, voce pode criar um pool de IPAM.

Um pool é uma coleção de endereço de IP continuo e range( ou CIDRS). IPAM pool habilita voce organizar o seu endereço de IP de acordo com a sua rota e segurança necessária.Voce pode ter multiplos pools com um nivel-top de pool.Por exemplo, se voce separar a sua routa e sua segurança necessária para o desenvolvimento e produção de aplicações, voce pode criar um pool para cada um. Com um pool IPAM, voce pode alocar CIDRS para um recurso.

Uma alocação é um CIDR assinado de um pool IPAM para um outro recurso ou para pool IPAM. Quando voce cria uma VPC e escolhe um IPAM pool para a VPC's CIDR, o CIDR é alocado para um CIDR provisonad para um pool IPAM. Voce pode monitorar e gerenciar e alocar com IPAM.

IPAM pode gerenciar e monitorar o seu CIDR IPv4 privado e publico IPv4/IPv6 CIDR do qual voce é o dono. IPAM voce pode somente monitorar (não gerenciar) Amazon com o seu espaço de IP publico.

VPN

• Custumer Gateway : É criado dentro da AWS, mas contém informações sobre o site de terceiros, por exemplo, o endereço IP externo e o tipo de roteamento
• Vitual Private Gateway : Tem as informações sobre o lado AWS da VPN e conecta um VPC especificado à VPN.
• Hardware VPN: É o hardware utilizado dentro do ambiente On-premise para estabelecer conexão com a AWS.
• Velocidade da VPN que é de 1.25 GBps
• Não é recomendado a utilização de VPN como backup de um direct connect com velocidade maior 1GBPs

Direct Connect

• Cada Direct Connect pode ser configurado um ou mais virtual Interface (VIF's)
• Um publico VIF pode permitir voce acessar servicos como S3,EC2 ou DynamoDB
• Um privado VIF pode permitir voce acessar as VPCs
• Necessário utilizar o public VIF quando usado IPSec VPN sobre Direct Connect
• Deve ser usado um IP Publico para um VIF publico e um IP Privado para um VIF privado
• Necessário implementar o Virtual Private Gateway: https://www.youtube.com/watch?v=dhpTTT6V1So
• Um VPG é usado para configurar um AWS VPN que você pode usar em combinação com Direct Connect para criptografar todos os dados que atravessam o link Direct Connect. Essa combinação fornece uma conexão privada criptografada por IPsec que também reduz os custos de rede, aumenta a taxa de transferência da largura de banda e fornece uma experiência de rede mais consistente do que as conexões VPN baseadas na Internet.
• O VPG é anexado a VPC que voce se deseja se conectar o Direct Connect.
• Você pode escolher o local fisico do Direct Connect
• Voce tem apenas duas opções para escolher de velocidade no direct Connect
  • 1 Gbps
  • 10Gbps
  • 100Gbps
• Direct Connect Locations : A AWS recomenda conectar a partir de vários data centers para redundância de localização física. Ao projetar conexões remotas, considere o uso de fornecedores redundantes de hardware e telecomunicações. Além disso, é uma prática recomendada usar conexões ativas / ativas roteadas dinamicamente para balanceamento de carga automático e failover em conexões de rede redundantes. Provisione capacidade de rede suficiente para garantir que a falha de uma conexão de rede não sobrecarregue e prejudique as conexões redundantes.
• Como solução de custo mais efetivo para backup ou failover, uma VPN pode ser utilizada com prioridade mais alta no mesmo BGP (Border Gateway Protocol), o Direct Conection sempre terá preferência, a menos que não esteja disponível.
• Um Direct Conect é permitido apenas para um Data Center, não é possivel ter mais de um Data Center atrelado a um Direct Connect.

LAG

Você pode usar várias conexões para aumentar a largura de banda disponível. LAG é uma interface lógica que usa o protocolo Link Aggregation Control Protocol (LACP) para agregar várias conexões a um único endpoint do AWS Direct Connect, o que permite tratá-las como uma única conexão gerenciada. Os LAGs simplificam a configuração porque a configuração LAG se aplica a todas as conexões do grupo.

nota O LAG multi-chassis (MLAG) não é suportado porAWS.

No diagrama a seguir, você tem quatro conexões, com duas conexões para cada local. Você pode criar um LAG para as conexões que são encerradas no mesmo local e, depois, usar os dois LAGs em vez das quatro conexões para configuração e gerenciamento.

Você pode criar um LAG com base em conexões existentes ou provisionar conexões novas. Depois que tiver criado o LAG, você poderá associar conexões existentes (independentes ou parte de outro LAG) ao LAG.

As seguintes regras se aplicam:

• Todas as conexões devem ser conexões dedicadas e ter uma velocidade de porta de 1 Gbps, 10 Gbps ou 100 Gbps.
• Todas as conexões no LAG devem usar a mesma largura de banda.
• Você pode ter no máximo duas conexões 100G ou quatro conexões com uma velocidade de porta inferior a 100G em um LAG. Cada conexão no LAG é contabilizada no limite geral de conexões para a Região.
• Todas as conexões no LAG devem ser encerradas no mesmo endpoint do AWS Direct Connect.

Direct Connect Gateway

A sua conexão é feita apartir de um Direct Connect comum, o que permite a conexão entre VPCs, em multiplas regiões, sobre um dos seguintes gateways :

• Virtual Private Gateway
• Transit Gateway

Diferença entre Direct Connect Gateway e Transit Gateway

Link

Virtual Private Gateway

Private Gateway

Transit Gateway

CloudFront

• Entrega de conteúdo dinâmico e estático o Edge Location é onde os usuários finais acessam os serviços localizados na AWS.
• Eles estão localizados na maioria das principais cidades do mundo e são usados ​​especificamente pelo CloudFront (CDN) para distribuir conteúdo ao usuário final e reduzir a latência.
• Cache controlado por TTL de 0 segundos até 1 ano
• Embora não seja o seu propósito, ele também ajuda a evitar ataque DDoS
• Origem do conteúdo distribuído pode ser um S3, Instancias EC2, ELB ou Route 53
• É possivel efetuar bloqueios de conteudos por pais de origem da requisição, o CloudFront tem a opção de bloqueio geografico, adicionando os paises que não deseja exibir o conteudo em uma black-List;
  • Uma requisição de origem de um pais que esteja no black-List irá retornar o erro 403(Forbiden), este erro pode ser customizado..
• Distribution : É o nome dado ao CDN, que consiste em uma coleção de Edge Location, são dois os tipos :
  • Web Distribution : Tipicamente usado para websites
  • RTMP : Usado para streaming de mídia, cuja a origem seja um bucket do S3. (não suportado para URL Assinada)
• OAI previne que os usuarios possam visualizar os seus arquivos no S3 por está usando simplesmente uma URL direta para o arquivo. Ao invés de acessar via CloudFront

URL Assinada vs Cookies

• Uma signed URL é para um arquivo individual, (1 URL Assinada = 1 Arquivo), ex.: Um documento, um vídeo, ou um arquivo específico.
• Um signed cookie é para multiplos arquivos, (1 Cookie assinado = multiplos arquivos), ex.: Uma plataforma que contém diversos vídeos, tutoriais etc

CloudFront Signed URL vs S3 Pre-Signed URL

• CloudFront Signed URL:
  • Permite acesso para um path, independente da origem
  • Par de chaves de toda a conta apenas o root pode gerenciar
  • Pode filtrar por IP, Path, data de expiração
  • Pode permitir uma feature de caching
• S3 Pre-Signed URL:
  • Permite a requisição como a própria pessoa que pré-assinou a URL
  • Usa a chave IAM da assinatura do IAM Principal
  • Tempo de vida limitado

Headers e distribuição - Overview

Por padrão, CloudFront não considera headers quando cachea seus objetos em edge locations. Se sua origin retorna dois objetos e eles são somente diferentes por valores na requisição dos headers, CloudFront cacheia somente uma versão do objeto. Voce pode configurar CloudFront encaminhar dois headers para origin, quais causas CloudFront para cachear multiplas versões de um objeto baseado em valores de um ou mais requisição do header. Para configurar CloudFront para cachear objetos baseados no valores especificos headers, voce especifica cache atras das configurações para a sua distribuição. Por exemplo, suponhamos que uma visão de requisição para uma imagem "logo.jpg" contai um produto customizado no header que o valor qualquer "Acme" ou "Apex". Quando sua configuração CloudFront para cachear seus objetos baseado no valor de um Product Header, CloudFront encaminha sua requisição para qual o valor do Product header é "Acme" e uma vez para a requisição para o valor "Apex"

Voce pode configurar cada cache por comportamento de distribuição para um desse seguintes itens:

• Encaminhamento de todos os headers para a sua origem

Importante Se sua configuração de CloudFront encaminhar todos os headers para a sua origem, CloudFront não cacheia os objetos associados com esse comportamento de cache. Ao inves disso, ele envia sempre a requisição para a origem.

• Encaminhamento de uma lista de headers que voce especifica. CloudFront cacheia seus objetos no valor com todos os especificos headers. CloudFront também encaminha headers por default, mas esse cache de seus objetos são baseados somente nos headers que voce especificar.

• Encaminhamento somente headers default. Nessa configuração, CloudFront não cacheia seu objeto baseado em valores na requisição do seu header.

Para atual numero de cotas de headers que voce pode encaminhar em cada comportamento de cache por requisição de uma cota mais alta.

Selecionando Headers para ser cacheados

O Header que voce pode encaminhar para a origem e que o CloudFront baseia o cacheamento na dempedencia de sua origem é um bucket ou uma origem customizada.

• Amazon S3 - Voce pode configurar o CloudFront para encaminhar e cachear o seus objetos baseados em um numero especifico de headers. Entretanto, nós recomendamos que voce evite encaminhamento de headers com um Amazon S3 origem a menos que voce precise implementar um CORS ou voce queira personalizar um conteudo usando um Lambda@Edge em usa origin-facing events.

  • Para configurar CORS, voce deve encaminhar headers que permite CloudFront distribuir o conteudo para websites que são habilitados para CORS.
  • Para personalizar conteudo usando headers que voce encaminha para o seu Amazon S3 origem, voce deve escrever e adicionar um Lambda@Edge function e associar-la então a uma distribuição de CloudFront que será gatilhado por uma origin-facing event. Nós recomendamos que voce evite encaminhamento de headers que não são usados para personalizar conteudos por que encaminhamento de headers extra pode reduzir o cache hit ratio. Isso causará que o CloudFront não poderá servir muitas requisições de um edge cache, as proporções para todas requisições

• Origem Customizada - Voce pode configurar CloudFront para cachear baseado no valor de muitas requisições do header exceto para as seguintes:

  • Connection

  • Cookies – Se voce quer encaminhar e cachear baseado em cookies, voce usa um separador na configuração de sua distribuição.

  • Host (for Amazon S3 origins)

  • Proxy-Authorization

  • TE

  • Upgrade

Voce pode configurar CloudFront para cachear objetos baseado em valores em Date e User-Agent headers, mas nós não recomendamos isso. Esses headers tem numeros possiveis de valores, e cacheia baseado em seus valores que pode causar CloudFront para encaminhar requisições significativas para sua origem.

• Os paramentros Cache-Control e Expires para controlar o quanto tempo os objetos fica no CloudFront no cache.

CloudFront com S3

Depois de voce criar um S3 bucket, voce precisa de 24 horas passafas antes que o bucket name propage através de todas as regiões da AWS. Durante esse tempo voce deve receber erro http 307 Temporary Redirect para as suas requisições para um regional endpoint que não estão na mesma região do seu bucket. Para evitar a resposta 307 de suas requisições somente o Regional endpoint na mesma região que o seu S3 bucket. Se voce estiver usando uma distribuição de CloudFront com uma origem de S3, CloudFront encaminha a requisição default para o S3 endpoint(s3.amazonaws.com). O default endpoint do S3 é na região us-east-1. Se voce precisar acessar o S3 na primeira 24 horas de criação do bucket, voce pode mudar a origem do dominio do nome de sua distribuição; O nome do dominio deve incluir a Região do endpoint do bucket. Por exemplo: Se seu bucket é na região us-west-2, voce pode mudar a origem do dominio nome para awsexamplebucketname.s3.amazonaws.com para awsexamplebucket.s3.us-west-2.amazon.com

API Gateway

• Características do serviço :
  • Não suporta GraphQL
  • por default já expoem protocolo HTTPS
  • Tipos de Endpoints :
    • Endpoint de API otimizado para bordas - Melhor para clientes distribuídos geograficamente, as solicitações são direcionadas para o ponto de presença (PoP) mais próximo do Cloud Front (É o tipo padrão para API Rest do API Gateway)
    • Endpoints de API regionais - Endpoint destinado normalmente a atender uma região especifica, para um pequeno número de clientes e com alta demanda
    • Endpoints privados de API - Acesso dentro da mesma VPC usando um intarface endpoint,

Logs

• Access Log :

  • Logs de acesso contain detalhes sobre quem acessa sua API e como ela é acessada, você pode usar para troubleshooting.

• Execution Log :

  • Logs de execução contain informações úteis que você pode usar para identificar e corrigir erros com a sua API

API Gateway - WebSocket

In API Gateway you can create a WebSocket API as a stateful frontend for an AWS service (such as Lambda or DynamoDB) or for an HTTP endpoint. The WebSocket API invokes your backend based on the content of the messages it receives from client apps.

Unlike a REST API, which receives and responds to requests, a WebSocket API supports two-way communication between client apps and your backend. The backend can send callback messages to connected clients.

In your WebSocket API, incoming JSON messages are directed to backend integrations based on routes that you configure. (Non-JSON messages are directed to a $default route that you configure.)

Network Access Control List (NACL)

Ephemeral ports

O client que inicia a requisição escolhe o range de porta ephemeral. O range varia dependendo do Sistema Operacional do client :

• Many Linux kernels (including the Amazon Linux kernel) use ports 32768-61000.

• Requests originating from Elastic Load Balancing use ports 1024-65535.

• Windows operating systems through Windows Server 2003 use ports 1025-5000.

• Windows Server 2008 and later versions use ports 49152-65535.

• A NAT gateway uses ports 1024-65535.

• AWS Lambda functions use ports 1024-65535.

Global Accelarator

• Serviço de rede que envia o tráfego do seu usuário por meio da infraestrutura de rede global do Amazon Web Service, melhorando o desempenho do usuário da Internet em até 60%.
• Não é utilizado para HTTP. É mais apropriado para usos como gaming (UDP), IoT (MQTT), or Voice over IP. E não existe uma forma de integra-lo diretamente ao S3. Para HTTP use o CloudFront
• Para mitigar a falha do endpoint, o Global Accelerator redireciona automaticamente seu tráfego para o endpoint disponível mais próximo utilizando edge location
• Permite a migração de endereço de IPs existentes
• AWS Global Accelerator, permite mudar o tráfego gradualmente ou de uma só vez entre o ambiente blue e green e vice-versa sem estar sujeito ao cache de DNS em dispositivos clientes (isso porque são criados dois ip's státicos que nunca mudam) e resolvedores de internet, as alterações de discagem de tráfego e weight de endpoint são efetivadas em segundos.

Custom Routing Accelarator

Os Custom Routing Accelarator são um novo tipo de accelarator no AWS Global Accelerator. Este novo accelarator permite usar sua própria lógica de aplicação para rotear o tráfego do usuário para um destino de instância específico do Amazon EC2 em uma ou várias regiões da AWS. Como o tráfego é roteado pela rede global AWS, você obtém todas as melhorias de performance ao passar pelo Global Accelerator. Um Custom Rourting Accelarator é uma alternativa ao accelarator padrão, que roteia automaticamente o tráfego para um endpoint íntegro mais próximo dos usuários. Como os aceleradores padrão são projetados para balancear a carga do tráfego, você não pode usá-los para direcionar os usuários a um destino de instância do EC2 específico atrás do seu accelarator. Ser capaz de rotear o tráfego de forma determinística é necessário para algumas aplicações interativas, como jogos multijogador, EdTech, mídia social e comunicações em tempo real.

Com um Custom Rourting Accelarator, você direciona vários usuários a uma porta exclusiva em seu accelarator. O accelarator mapeia cada porta em seu accelarator para um destino específico, um endereço IP privado de instância do EC2 e porta, para que possa rotear o tráfego para lá. Esse mapeamento facilita a integração do Global Accelerator à lógica da aplicação, como servidores de matchmaking ou controladores de borda de sessão (elementos de rede que protegem e regulam os fluxos de tráfego IP para fluxos de trabalho de comunicação em tempo real). Com Custom Rourting Accelarator, você pode aproveitar o Global Accelerator como o único ponto de entrada para sua aplicação, ao mesmo tempo que envia o tráfego do usuário de forma determinística para destinos específicos do EC2 em qualquer região da AWS.

CloudHub

Caso haja várias conexões AWS Site-to-Site VPN, garanta a segurança da comunicação entre os sites, usando o AWS VPN CloudHub. Isso permite que os sites remotos comuniquem-se entre si e, não somente, com a VPC. O VPN CloudHub opera em um modelo simples de hub e spoke que pode ser usado com ou sem uma VPN.

ENI

É a interface de rede anexada a uma instancia EC2, ela responsavel a dar o IP para a instancia, exitem 3 tipos de ENI :

• ENI - Redes Basica
• ENA - Permite um aumento de banda (Auto Throuput) (10GBs a 100GBs), baixa latencia entre instancias, mas não oferece suporte aos recursos de um aplicativo fortemente acoplado
• EFA - Auto poder computacional utilizado para Machine Learn (> 100GBs), permite que você aplique a escala, a flexibilidade e a elasticidade da Nuvem AWS a aplicativos HPC fortemente acoplados. É ideal para aplicativos fortemente acoplados, pois usa a Interface de passagem de mensagem (MPI).

Obs.: Interface de Rede só podem ser anexadas em uma instancia stoped

Uma elastic network interface é um componente de rede lógico em uma VPC que representa um virtual network card. Uma ENI pode existir somente em uma única subnet. Voce não pode anexar uma ENI provisionada para instancia EC2 em uma nova subnete.