As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Processo de adoção da nuvem híbrida
As seções a seguir discutem arquiteturas e detalhes de design para cada pilar da nuvem AWS híbrida:
+ [Rede na periferia](networking.md)
+ [Segurança na borda](security.md)
+ [Resiliência na borda](resiliency.md)
+ [Planejamento de capacidade na borda](capacity-planning.md)
+ [Gerenciamento de infraestrutura de ponta](infrastructure-mgmt.md)
# Rede na borda
Ao projetar soluções que usam infraestrutura de AWS borda, como AWS Outposts Zonas Locais, você deve considerar cuidadosamente o design da rede. A rede forma a base da conectividade para alcançar cargas de trabalho implantadas nesses locais periféricos e é fundamental para garantir baixa latência. Esta seção descreve vários aspectos da conectividade de borda híbrida.
## Arquitetura VPC
Uma nuvem privada virtual (VPC) abrange todas as zonas de disponibilidade em sua. Região da AWS Você pode estender facilmente qualquer VPC na região para Outposts ou Zonas Locais AWS usando o console ou AWS CLI o () para adicionar uma sub-rede Outpost AWS Command Line Interface ou Zona Local. Os exemplos a seguir mostram como criar sub-redes em Zonas AWS Outposts Locais usando o: AWS CLI
+ **AWS Outposts**: Para adicionar uma sub-rede Outpost a uma VPC, especifique o Amazon Resource Name (ARN) do Outpost.
```
aws ec2 create-subnet --vpc-id vpc-081ec835f3EXAMPLE \
--cidr-block 10.0.0.0/24 \
--outpost-arn arn:aws:outposts:us-west-2:11111111111:outpost/op-0e32example1 \
--tag-specifications ResourceType=subnet,Tags=[{Key=Name,Value=my-ipv4-only-subnet}]
```
Para obter mais informações, consulte a [documentação do AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/launch-instance.html#create-subnet).
+ **Zonas locais**: para adicionar uma sub-rede de zona local a uma VPC, siga o mesmo procedimento usado com as zonas de disponibilidade, mas especifique a ID da zona local `` (no exemplo a seguir).
```
aws ec2 create-subnet --vpc-id vpc-081ec835f3EXAMPLE \
--cidr-block 10.0.1.0/24 \
--availability-zone \
--tag-specifications ResourceType=subnet,Tags=[{Key=Name,Value=my-ipv4-only-subnet}]
```
Para obter mais informações, consulte a [documentação de Locais Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet).
O diagrama a seguir mostra uma AWS arquitetura que inclui sub-redes Outpost e Local Zone.
![\[AWS arquitetura com sub-redes Outpost e:Local Zone.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/architecture-lz-outpost.png)
## Tráfego de borda para região
Ao projetar uma arquitetura híbrida usando serviços como Locais Zones e AWS Outposts, considere tanto os fluxos de controle quanto os fluxos de tráfego de dados entre as infraestruturas de borda e. Regiões da AWS Dependendo do tipo de infraestrutura de borda, sua responsabilidade pode variar: algumas infraestruturas exigem que você gerencie a conexão com a região principal, enquanto outras lidam com isso por meio da infraestrutura AWS global. Esta seção explora as implicações da conectividade do plano de controle e do plano de dados para Zonas Locais e. AWS Outposts
### AWS Outposts plano de controle
AWS Outposts fornece uma construção de rede chamada *link de serviço*. O link de serviço é uma conexão obrigatória AWS Outposts entre a região selecionada Região da AWS ou principal (também chamada de *região de origem*). Ele permite o gerenciamento do Posto Avançado e a troca de tráfego entre o Posto Avançado e. Região da AWS O link do serviço usa um conjunto criptografado de conexões VPN para se comunicar com a região de origem. Você deve fornecer conectividade entre AWS Outposts e por meio de um link de internet ou de uma interface virtual Direct Connect pública (VIF pública) ou por meio de uma interface virtual Direct Connect privada (VIF privada). Região da AWS Para uma experiência e resiliência ideais, AWS recomenda que você use conectividade redundante de pelo menos 500 Mbps (1 Gbps é melhor) para a conexão do link de serviço com o. Região da AWS A conexão mínima de 500 Mbps do link de serviço permite que você inicie EC2 instâncias da Amazon, anexe volumes do Amazon EBS e Serviços da AWS acesse métricas como Amazon EKS, Amazon EMR e Amazon. CloudWatch A rede deve suportar uma unidade de transmissão máxima (MTU) de 1.500 bytes entre o Outpost e os endpoints do link de serviço no terminal principal. Região da AWS[Para obter mais informações, consulte [AWS Outposts conectividade com Regiões da AWS](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) na documentação do Outposts.](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html)
![\[Link de serviço para Outposts usando Direct Connect (VIF privado) e conectividade privada.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/dc-service-link.png)
Para obter informações sobre a criação de arquiteturas resilientes para links de serviços que usam a Internet pública, consulte a seção [Conectividade Anchor](https://docs.aws.amazon.com/whitepapers/latest/aws-outposts-high-availability-design/anchor-connectivity.html) no AWS whitepaper Considerações sobre design Direct Connect e arquitetura de *AWS Outposts alta disponibilidade*.
### AWS Outposts plano de dados
O plano de dados entre AWS Outposts e o Região da AWS é suportado pela mesma arquitetura de link de serviço usada pelo plano de controle. A largura de banda do link de serviço do plano de dados entre AWS Outposts e o Região da AWS deve se correlacionar com a quantidade de dados que devem ser trocados: quanto maior a dependência de dados, maior deve ser a largura de banda do link.
Os requisitos de largura de banda variam de acordo com as seguintes características:
+ O número de AWS Outposts racks e configurações de capacidade
+ Características da carga de trabalho, como tamanho da AMI, elasticidade do aplicativo e necessidades de velocidade de pico
+ Tráfego de VPC para a região
O tráfego entre EC2 instâncias em AWS Outposts e EC2 instâncias no Região da AWS tem uma MTU de 1.300 bytes. Recomendamos que você discuta esses requisitos com um especialista em nuvem AWS híbrida antes de propor uma arquitetura que tenha co-dependências entre a região e. AWS Outposts
### Plano de dados de Locais Zones
O plano de dados entre Locais Zones e o Região da AWS é suportado pela infraestrutura AWS global. O plano de dados é estendido por meio de uma VPC de Região da AWS até uma zona local. As Zonas Locais também fornecem uma conexão segura e de alta largura de banda com o Região da AWS e permitem que você se conecte perfeitamente a toda a gama de serviços regionais por meio dos mesmos APIs conjuntos de ferramentas.
A tabela a seguir mostra as opções de conexão e as associadas MTUs.
| **De** | **Para** | **MTU** |
| --- | --- | --- |
| Amazon EC2 na região | Amazon EC2 em Zonas Locais | 1.300 bytes |
| Direct Connect | Zonas Locais | 1.468 bytes |
| Gateway da Internet | Zonas Locais | 1.500 bytes |
| Amazon EC2 em Zonas Locais | Amazon EC2 em Zonas Locais | 9.001 bytes |
Locais Zones usam a infraestrutura AWS global com a qual se conectar Regiões da AWS. A infraestrutura é totalmente gerenciada por AWS, então você não precisa configurar essa conectividade. Recomendamos que você discuta seus requisitos e considerações sobre Zonas Locais com um especialista em nuvem AWS híbrida antes de projetar qualquer arquitetura que tenha co-dependências entre a Região e as Zonas Locais.
## Da borda ao tráfego local
AWS os serviços de nuvem híbrida são projetados para lidar com casos de uso que exigem baixa latência, processamento local de dados ou conformidade com a residência de dados. A arquitetura de rede para acessar esses dados é importante e depende se sua carga de trabalho está sendo executada em AWS Outposts ou em Zonas Locais. A conectividade local também requer um escopo bem definido, conforme discutido nas seções a seguir.
### AWS Outposts gateway local
O gateway local (LGW) é um componente central da AWS Outposts arquitetura. O gateway local permite a conectividade entre suas sub-redes Outpost e sua rede on-premises própria. A função principal de um LGW é fornecer conectividade de um Posto Avançado à sua rede local local. Ele também fornece conectividade com a Internet por meio de sua rede local por meio de roteamento [direto de VPC](https://docs.aws.amazon.com/outposts/latest/userguide/routing.html#direct-vpc-routing) [ou](https://docs.aws.amazon.com/outposts/latest/userguide/routing.html#ip-addressing) endereços IP de propriedade do cliente.
+ O **roteamento direto de VPC** usa o endereço IP privado das instâncias em sua VPC para facilitar a comunicação com sua rede local. Esses endereços são anunciados em sua rede local com o Border Gateway Protocol (BGP). O anúncio para o BGP é apenas para os endereços IP privados que pertencem às sub-redes em seu rack Outpost. Esse tipo de roteamento é o modo padrão para AWS Outposts. Nesse modo, o gateway local não executa NAT para instâncias e você não precisa atribuir endereços IP elásticos às suas EC2 instâncias. O diagrama a seguir mostra um gateway AWS Outposts local que usa roteamento direto de VPC.
![\[Gateway local Outposts com modo VPC direto.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/outpost-lgw-direct-vpc.png)
+ Com endereços **IP de propriedade do cliente**, você pode fornecer um intervalo de endereços, conhecido como *pool de endereços IP de propriedade do cliente (CoIP)*, que suporta intervalos CIDR sobrepostos e outras topologias de rede. Ao escolher um CoIP, você deve criar um pool de endereços, atribuí-lo à tabela de rotas do gateway local e anunciar esses endereços de volta à sua rede por meio do BGP. Os endereços CoIP fornecem conectividade local ou externa aos recursos em sua rede local. Você pode atribuir esses endereços IP a recursos em seu Outpost, como EC2 instâncias, alocando um novo endereço IP elástico do CoIP e, em seguida, atribuindo-o ao seu recurso. O diagrama a seguir mostra um gateway AWS Outposts local que usa o modo CoIP.
![\[Gateway local Outposts com modo COIP.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/outpost-lgw-coip.png)
A conectividade local de AWS Outposts uma rede local requer algumas configurações de parâmetros, como ativar o protocolo de roteamento BGP e anunciar prefixos entre os pares do BGP. A MTU que pode ser suportada entre seu Outpost e o gateway local é de 1.500 bytes. Para obter mais informações, entre em contato com um especialista em nuvem AWS híbrida ou revise a [AWS Outposts documentação](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html).
### Locais Zones e a internet
Os setores que exigem baixa latência ou residência local de dados (exemplos incluem jogos, transmissão ao vivo, serviços financeiros e o governo) podem usar o Local Zones para implantar e fornecer seus aplicativos aos usuários finais pela Internet. Durante a implantação de uma zona local, você deve alocar endereços IP públicos para uso em uma zona local. Ao alocar endereços IP elásticos, você pode especificar o local a partir do qual o endereço IP é anunciado. Esse local é chamado de *grupo de borda de rede*. Um grupo de borda de rede é uma coleção de Zonas de Disponibilidade, Zonas Locais ou AWS Wavelength Zonas a partir das quais AWS anuncia um endereço IP público. Isso ajuda a garantir latência mínima ou distância física entre a AWS rede e os usuários que acessam os recursos nessas zonas. Para ver todos os grupos de bordas de rede para Zonas Locais, consulte [Zonas Locais Disponíveis](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) na documentação de Zonas Locais.
Para expor à Internet uma carga EC2 de trabalho hospedada pela Amazon em uma zona local, você pode ativar a opção de **atribuição automática de IP público** ao iniciar a instância. EC2 Se você usa um Application Load Balancer, pode defini-lo como voltado para a Internet para que os endereços IP públicos atribuídos à zona local possam ser propagados pela rede de fronteira associada à zona local. Além disso, ao usar endereços IP elásticos, você pode associar um desses recursos a uma EC2 instância após sua execução. Quando você envia tráfego por meio de um gateway de Internet em Zonas Locais, as mesmas especificações de [largura de banda da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) usadas pela Região são aplicadas. O tráfego de rede da zona local vai diretamente para a Internet ou para os pontos de presença (PoPs) sem atravessar a região principal da zona local, para permitir o acesso à computação de baixa latência.
As Zonas Locais oferecem as seguintes opções de conectividade pela Internet:
+ Acesso público: conecta cargas de trabalho ou dispositivos virtuais à Internet usando endereços IP elásticos por meio de um gateway de internet.
+ Acesso externo à Internet: permite que os recursos alcancem endpoints públicos por meio de instâncias de conversão de endereços de rede (NAT) ou dispositivos virtuais com endereços IP elásticos associados, sem exposição direta à Internet.
+ Conectividade VPN: estabelece conexões privadas usando o Internet Protocol Security (IPsec) VPN por meio de dispositivos virtuais com endereços IP elásticos associados.
Para obter mais informações, consulte [Opções de conectividade para Zonas Locais](https://docs.aws.amazon.com/local-zones/latest/ug/local-zones-connectivity.html) na documentação de Zonas Locais.
### Zonas Locais e Direct Connect
Também há suporte para Locais Zones Direct Connect, o que permite rotear seu tráfego por meio de uma conexão de rede privada. Para obter mais informações, consulte [Direct Connect in Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/local-zones-connectivity-direct-connect.html) na documentação de Locais Zones.
### Zonas Locais e gateways de trânsito
AWS Transit Gateway não oferece suporte a anexos diretos de VPC às sub-redes da zona local. No entanto, você pode se conectar às cargas de trabalho da Zona Local criando anexos do Transit Gateway nas sub-redes principais da Zona de Disponibilidade da mesma VPC. Essa configuração permite a interconectividade entre várias cargas de trabalho VPCs e suas da Zona Local. Para obter mais informações, consulte [Conexão do Transit Gateway entre Zonas Locais](https://docs.aws.amazon.com/local-zones/latest/ug/local-zones-connectivity-transit-gateway-lzs.html) na documentação de Zonas Locais.
### Zonas locais e emparelhamento de VPC
Você pode estender qualquer VPC de uma região principal para uma zona local criando uma nova sub-rede e atribuindo-a à zona local. O emparelhamento de VPC pode ser estabelecido entre aqueles estendidos VPCs às Zonas Locais. Quando os pares VPCs estão na mesma zona local, o tráfego permanece dentro da zona local e não passa pela região principal.
# Segurança na borda
No Nuvem AWS, a segurança é a principal prioridade. À medida que as organizações adotam a escalabilidade e a flexibilidade da nuvem, AWS ajuda-as a adotar segurança, identidade e conformidade como fatores-chave de negócios. AWS integra a segurança em sua infraestrutura principal e oferece serviços para ajudá-lo a atender aos seus requisitos exclusivos de segurança na nuvem. Quando você expande o escopo de sua arquitetura para o Nuvem AWS, você se beneficia da integração de infraestruturas como Locais Zones e Outposts no Regiões da AWS. Essa integração permite AWS estender um grupo seleto dos principais serviços de segurança até a borda.
A segurança é uma responsabilidade compartilhada entre você AWS e você. O [modelo de responsabilidade AWS compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) diferencia entre a segurança *da* nuvem e a segurança *na* nuvem:
+ **Segurança da nuvem** — AWS é responsável por proteger a infraestrutura que é executada Serviços da AWS no Nuvem AWS. AWS também fornece serviços que você pode usar com segurança. Auditores terceirizados testam e verificam regularmente a eficácia da AWS segurança como parte dos [programas de AWS conformidade](https://aws.amazon.com/compliance/programs/).
+ **Segurança na nuvem** — Sua responsabilidade é determinada pelo AWS service (Serviço da AWS) que você usa. Você também é responsável por outros fatores, incluindo a confidencialidade dos dados, os requisitos da empresa e as leis e regulamentos aplicáveis.
## Proteção de dados
O modelo de responsabilidade AWS compartilhada se aplica à proteção de dados em AWS Outposts Zonas locais da AWS e. Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa a Nuvem AWS (*segurança da nuvem*). Você é responsável por manter o controle sobre o conteúdo hospedado nessa infraestrutura (*segurança na nuvem*). Esse conteúdo inclui as tarefas de configuração e gerenciamento de segurança do Serviços da AWS que você usa.
Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) ou [Centro de Identidade do AWS IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). Isso concede a cada usuário apenas as permissões necessárias para cumprir suas tarefas.
### Criptografia em repouso
#### Criptografia em volumes do EBS
Com isso AWS Outposts, todos os dados são criptografados em repouso. O material da chave é embalado com uma chave externa, a Nitro Security Key (NSK), que é armazenada em um dispositivo removível. O NSK é necessário para descriptografar os dados em seu rack Outpost. Você pode usar a criptografia do Amazon EBS para volumes do EBS e snapshots. A criptografia do Amazon EBS usa [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) e chaves KMS.
No caso de Zonas Locais,**** todos os volumes do EBS são criptografados por padrão em todas as Zonas Locais, exceto na lista documentada nas [Zonas locais da AWS Perguntas Frequentes](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/#:~:text=What%E2%80%99s%20the%20default%20encryption%20behavior%20of%20EBS%20volumes%20in%20Local%20Zones%3F) (consulte a pergunta: *Qual é o comportamento padrão de criptografia dos volumes do EBS nas Zonas Locais*? ), a menos que a criptografia esteja habilitada para a conta.
#### Criptografia no Amazon S3 em Outposts
Por padrão, todos os dados armazenados no Amazon S3 on Outposts são criptografados usando criptografia no lado do servidor com chaves de criptografia gerenciadas pelo Amazon S3 (SSE-S3). Você também pode optar por usar a criptografia no lado do servidor com chaves de criptografia fornecidas pelo cliente (SSE-C). Para usar o SSE-C, especifique uma chave de criptografia como parte das solicitações da API de objeto. A criptografia no lado do servidor criptografa somente os dados de objeto, não os metadados de objeto.
**nota**
O Amazon S3 on Outposts não oferece suporte à criptografia do lado do servidor com chaves KMS (SSE-KMS).
### Criptografia em trânsito
Pois AWS Outposts, o link de serviço é uma conexão necessária entre o servidor do Outposts e a região escolhida Região da AWS (ou de origem) e permite o gerenciamento do Outpost e a troca de tráfego de e para o. Região da AWS O link do serviço usa uma VPN AWS gerenciada para se comunicar com a região de origem. Cada host interno AWS Outposts cria um conjunto de túneis VPN para dividir o tráfego do plano de controle e o tráfego de VPC. Dependendo da conectividade do link de serviço (internet ou Direct Connect) AWS Outposts, esses túneis exigem que portas de firewall sejam abertas para que o link de serviço crie a sobreposição sobre ele. Para obter informações técnicas detalhadas sobre a segurança AWS Outposts e o link do serviço, consulte [Conectividade por meio do link de serviço](https://docs.aws.amazon.com/outposts/latest/userguide/service-links.html) e [Segurança da infraestrutura AWS Outposts na](https://docs.aws.amazon.com/outposts/latest/server-userguide/infrastructure-security.html) AWS Outposts documentação.
O link AWS Outposts de serviço cria túneis criptografados que estabelecem a conectividade do plano de controle e do plano de dados com o pai Região da AWS, conforme ilustrado no diagrama a seguir.
![\[Considerações sobre VPC do Anchor.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/anchor-vpc.png)
Cada AWS Outposts host (computação e armazenamento) requer esses túneis criptografados em portas TCP e UDP conhecidas para se comunicar com sua região principal. A tabela a seguir mostra as portas e endereços de origem e destino dos protocolos UDP e TCP.
| **Protocolo** | **Porta de origem** | **Endereço de origem** | **Porta de destino** | **Endereço de destino** |
| --- | --- | --- | --- | --- |
| UDP | 443 | AWS Outposts link de serviço /26 | 443 | AWS Outposts Rotas públicas da região ou VPC CIDR âncora |
| TCP | 1025-65535 | AWS Outposts link de serviço /26 | 443 | AWS Outposts Rotas públicas da região ou VPC CIDR âncora |
As Zonas Locais também são conectadas à região principal por meio do backbone privado global redundante e de altíssima largura de banda da Amazon. Essa conexão fornece aos aplicativos que estão sendo executados em Zonas Locais acesso rápido, seguro e contínuo a outros Serviços da AWS. Desde que as Zonas Locais façam parte da infraestrutura AWS global, todos os dados que fluem pela rede AWS global são criptografados automaticamente na camada física antes de saírem das instalações AWS protegidas. Se você tiver requisitos específicos para criptografar os dados em trânsito entre seus locais locais e Direct Connect PoPs acessar uma zona local, você pode habilitar a Segurança MAC (MACsec) entre seu roteador ou switch local e o endpoint. Direct Connect Para obter mais informações, consulte a postagem do AWS blog [Adicionar MACsec segurança às Direct Connect conexões](https://aws.amazon.com/blogs/networking-and-content-delivery/adding-macsec-security-to-aws-direct-connect-connections/).
### Exclusão de dados
Quando você interrompe ou encerra uma instância do EC2 AWS Outposts, a memória alocada para ela é limpa (definida como zero) pelo hipervisor antes de ser alocada para uma nova instância, e cada bloco de armazenamento é redefinido. A exclusão de dados do hardware do Outpost envolve o uso de hardware especializado. O NSK é um pequeno dispositivo, ilustrado na fotografia a seguir, que se conecta à frente de cada unidade de computação ou armazenamento em um Posto Avançado. Ele foi projetado para fornecer um mecanismo para evitar que seus dados sejam expostos do seu data center ou site de colocation. Os dados no dispositivo Outpost são protegidos embalando o material de chaveamento usado para criptografar o dispositivo e armazenando o material embalado no NSK. Ao retornar um host do Outpost, você destrói o NSK girando um pequeno parafuso no chip que esmaga o NSK e destrói fisicamente o chip. Destruir o NSK destrói os dados criptograficamente em seu Posto Avançado.
![\[Dispositivo NSK em Outposts.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/nsk.jpg)
## Gerenciamento de identidade e acesso
AWS Identity and Access Management (IAM) é uma ferramenta AWS service (Serviço da AWS) que ajuda o administrador a controlar com segurança o acesso aos AWS recursos. Os administradores do IAM controlam quem pode ser autenticado (conectado) e autorizado (tem permissões) a usar AWS Outposts os recursos. Se você tiver um Conta da AWS, poderá usar o IAM sem custo adicional.
A tabela a seguir lista os recursos do IAM com os quais você pode usar AWS Outposts.
| **Recurso do IAM** | **AWS Outposts apoio** |
| --- | --- |
| Políticas baseadas em identidade | Sim |
| Políticas baseadas em recurso | Sim\$1 |
| Ações de políticas | Sim |
| Recursos de políticas | Sim |
| Chaves de condição de política (específicas do serviço) | Sim |
| Listas de controle de acesso (ACLs) | Não |
| Controle de acesso baseado em atributos (ABAC) (tags em políticas) | Sim |
| Credenciais temporárias | Sim |
| Permissões de entidade principal | Sim |
| Perfis de serviço | Não |
| Perfis vinculados ao serviço | Sim |
**\$1** Além das políticas baseadas em identidade do IAM, o Amazon S3 on Outposts oferece suporte a políticas de bucket e de ponto de acesso. Essas são [políticas baseadas em recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) anexadas ao recurso Amazon S3 on Outposts.
Para obter mais informações sobre como esses recursos são suportados no AWS Outposts, consulte o [guia AWS Outposts do usuário](https://docs.aws.amazon.com/outposts/latest/userguide/security_iam_service-with-iam.html).
## Segurança da infraestrutura
A proteção da infraestrutura é elemento essencial de um programa de segurança da informação. Ele garante que os sistemas e serviços de carga de trabalho estejam protegidos contra acesso não intencional e não autorizado e possíveis vulnerabilidades. Por exemplo, você define limites de confiança (por exemplo, limites de rede e conta), configuração e manutenção da segurança do sistema (por exemplo, fortalecimento, minimização e aplicação de patches), autenticação e autorizações do sistema operacional (por exemplo, usuários, chaves e níveis de acesso) e outros pontos apropriados de aplicação de políticas (por exemplo, firewalls de aplicativos web ou gateways de API).
AWS fornece várias abordagens para a proteção da infraestrutura, conforme discutido nas seções a seguir.
### Proteção de redes
Seus usuários podem fazer parte de sua força de trabalho ou de seus clientes e podem estar localizados em qualquer lugar. Por esse motivo, você não pode confiar em todos que têm acesso à sua rede. Ao seguir o princípio de aplicar segurança em todas as camadas, você emprega uma abordagem de [confiança zero](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/). No modelo de segurança de confiança zero, os componentes ou microsserviços do aplicativo são considerados discretos, e nenhum componente ou microsserviço confia em nenhum outro componente ou microsserviço. Para obter segurança de confiança zero, siga estas recomendações:
+ [Crie camadas de rede](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_network_protection_create_layers.html). As redes em camadas ajudam a agrupar logicamente componentes de rede semelhantes. Eles também reduzem o escopo potencial de impacto do acesso não autorizado à rede.
+ [Controle as camadas de tráfego](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_network_protection_layered.html). Aplique vários controles com uma defense-in-depth abordagem para tráfego de entrada e saída. Isso inclui o uso de grupos de segurança (firewalls de inspeção de estado), rede ACLs, sub-redes e tabelas de rotas.
+ [Implemente inspeção e proteção](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_network_protection_inspection.html). Inspecione e filtre seu tráfego em cada camada. [Você pode inspecionar suas configurações de VPC em busca de possíveis acessos não intencionais usando o Network Access Analyzer.](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html) Você pode especificar seus requisitos de acesso à rede e identificar possíveis caminhos de rede que não os atendam.
### Protegendo os recursos computacionais
Os recursos computacionais incluem instâncias do EC2, contêineres, AWS Lambda funções, serviços de banco de dados, dispositivos de IoT e muito mais. Cada tipo de recurso computacional exige uma abordagem diferente de segurança. No entanto, esses recursos compartilham estratégias comuns que você precisa considerar: *defesa em profundidade*, *gerenciamento de vulnerabilidades*, *redução na superfície de ataque*, *automação da configuração e operação* e *execução de ações à distância*.
Aqui estão as orientações gerais para proteger seus recursos computacionais para os principais serviços:
+ [Crie e mantenha um programa de gerenciamento de vulnerabilidades](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_compute_vulnerability_management.html). Examine e corrija regularmente recursos como instâncias do EC2, contêineres do Amazon Elastic Container Service (Amazon ECS) e cargas de trabalho do Amazon Elastic Kubernetes Service (Amazon EKS).
+ [Automatize a proteção computacional.](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_compute_auto_protection.html) Automatize seus mecanismos de proteção computacional, incluindo gerenciamento de vulnerabilidades, redução na superfície de ataque e gerenciamento de recursos. Essa automação libera tempo que você pode usar para proteger outros aspectos da sua carga de trabalho e ajuda a reduzir o risco de erro humano.
+ [Reduza a superfície de ataque](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_protect_compute_reduce_surface.html). Reduza sua exposição ao acesso não intencional fortalecendo seus sistemas operacionais e minimizando os componentes, bibliotecas e serviços consumíveis externos que você usa.
Além disso, para cada um AWS service (Serviço da AWS) que você usa, verifique as recomendações de segurança específicas na [documentação do serviço](https://docs.aws.amazon.com/).
## Acesso à Internet
AWS Outposts Tanto as Zonas Locais quanto as Zonas Locais fornecem padrões de arquitetura que dão às suas cargas de trabalho acesso de e para a Internet. Ao usar esses padrões, considere o consumo de internet da região uma opção viável somente se você usá-lo para corrigir, atualizar, acessar repositórios Git externos e cenários semelhantes. AWS Para esse padrão arquitetônico, os conceitos de [inspeção de entrada centralizada e saída](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-inbound-inspection.html) [centralizada da Internet](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html) se aplicam. Esses padrões de acesso usam AWS Transit Gateway gateways NAT, firewalls de rede e outros componentes que residem Regiões da AWS, mas estão conectados às AWS Outposts Zonas Locais por meio do caminho de dados entre a Região e a borda.
Local Zones adota uma construção de rede chamada *grupo de borda de rede*, que é usada em Regiões da AWS. AWS anuncia endereços IP públicos desses grupos exclusivos. Um grupo de bordas de rede consiste em Zonas de Disponibilidade, Zonas Locais ou Zonas de Wavelength. Você pode alocar explicitamente um pool de endereços IP públicos para uso em um grupo de borda de rede. Você pode usar um grupo de borda de rede para estender o gateway da Internet às Zonas Locais, permitindo que endereços IP elásticos sejam atendidos pelo grupo. Essa opção exige que você implante outros componentes para complementar os principais serviços disponíveis em Locais Zones. Esses componentes podem vir ISVs e ajudá-lo a criar camadas de inspeção em sua zona local, conforme descrito na postagem do AWS blog [Arquiteturas de inspeção híbridas com Zonas locais da AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/hybrid-inspection-architectures-with-aws-local-zone/).
Em AWS Outposts, se você quiser usar o gateway local (LGW) para acessar a Internet a partir da sua rede, deverá modificar a tabela de rotas personalizada associada à AWS Outposts sub-rede. A tabela de rotas deve ter uma entrada de rota padrão (0.0.0.0/0) que use o LGW como o próximo salto. Você é responsável por implementar os controles de segurança restantes em sua rede local, incluindo defesas perimetrais, como firewalls e sistemas de prevenção de intrusões ou sistemas de detecção de intrusões (IPS/IDS). Isso se alinha ao modelo de responsabilidade compartilhada, que divide as tarefas de segurança entre você e o provedor de nuvem.
### Acesso à Internet através dos pais Região da AWS
Nessa opção, as cargas de trabalho no Outpost acessam a Internet por meio do [link de serviço](https://docs.aws.amazon.com/outposts/latest/userguide/service-links.html) e do gateway de Internet no principal. Região da AWS O tráfego de saída para a Internet pode ser roteado por meio do gateway NAT que é instanciado em sua VPC. Para obter segurança adicional para seu tráfego de entrada e saída, você pode usar serviços AWS de segurança como AWS WAF, AWS Shield, e Amazon CloudFront no. Região da AWS
O diagrama a seguir mostra o tráfego entre a carga de trabalho na AWS Outposts instância e a Internet passando pela principal Região da AWS.
![\[Cargas de trabalho no Outpost acessando a Internet por meio dos pais. Região da AWS\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/internet-access-through-parent-region.png)
### Acesso à internet por meio da rede do data center local
Nessa opção, as cargas de trabalho no Outpost acessam a internet por meio de seu data center local. O tráfego da carga de trabalho que acessa a Internet atravessa seu ponto de presença na Internet local e sai localmente. Nesse caso, a infraestrutura de segurança de rede do seu data center local é responsável por proteger o tráfego da AWS Outposts carga de trabalho.
A imagem a seguir mostra o tráfego entre uma carga de trabalho na AWS Outposts sub-rede e a Internet passando por um data center.
![\[Cargas de trabalho no Outpost acessando a internet por meio de uma rede local.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/internet-access-through-local-network.png)
## Governança da infraestrutura
Independentemente de suas cargas de trabalho serem implantadas em uma Região da AWS zona local ou em um posto avançado, você pode usá-las AWS Control Tower para governança da infraestrutura. AWS Control Tower oferece uma maneira simples de configurar e administrar um ambiente com AWS várias contas, seguindo as melhores práticas prescritivas. AWS Control Tower orquestra os recursos de vários outros Serviços da AWS, inclusive AWS Organizations AWS Service Catalog, e do IAM Identity Center (veja [todos os serviços integrados](https://docs.aws.amazon.com/controltower/latest/userguide/integrated-services.html)) para criar uma landing zone em menos de uma hora. Os recursos são configurados e gerenciados em seu nome.
AWS Control Tower fornece governança unificada em todos os AWS ambientes, incluindo Regiões, Zonas Locais (extensões de baixa latência) e Outposts (infraestrutura local). Isso ajuda a garantir segurança e conformidade consistentes em toda a sua arquitetura de nuvem híbrida. Para obter mais informações, consulte a [documentação do AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html).
Você pode configurar AWS Control Tower recursos, como grades de proteção, para atender aos requisitos de residência de dados em governos e setores regulamentados, como instituições de serviços financeiros (). FSIs Para entender como implantar grades de proteção para residência de dados na borda, veja o seguinte:
+ [Melhores práticas para gerenciar a residência de dados Zonas locais da AWS usando controles de landing zone](https://aws.amazon.com/blogs/compute/best-practices-for-managing-data-residency-in-aws-local-zones-using-landing-zone-controls/) (postagem AWS no blog)
+ [Arquitetura para residência de dados com grades de proteção em AWS Outposts rack e landing zone (postagem no blog](https://aws.amazon.com/blogs/compute/architecting-for-data-residency-with-aws-outposts-rack-and-landing-zone-guardrails/))AWS
+ [Residência de dados com o Hybrid Cloud Services Lens](https://docs.aws.amazon.com/wellarchitected/latest/data-residency-hybrid-cloud-services-lens/data-residency-with-hybrid-cloud-services-lens.html) (documentação do AWS Well-Architected Framework)
### Compartilhando recursos do Outposts
Como um Posto Avançado é uma infraestrutura finita que reside em seu data center ou em um espaço de co-localização, para uma governança centralizada AWS Outposts, você precisa controlar centralmente com quais contas AWS Outposts os recursos são compartilhados.
Com o compartilhamento do Outpost, os proprietários do Outpost podem compartilhar seus Postos Avançados e recursos do Outpost, incluindo sites e sub-redes do Outpost, com outros Contas da AWS que estão na mesma organização em. AWS Organizations Como proprietário do Outpost, você pode criar e gerenciar recursos do Outpost a partir de um local central e compartilhar os recursos entre vários membros da sua Contas da AWS AWS organização. Isso permite que outros consumidores usem sites do Outpost, configurem VPCs, iniciem e executem instâncias no Outpost compartilhado.
Os recursos compartilháveis em AWS Outposts são:
+ Hosts dedicados alocados
+ Reservas de capacidade
+ Pools de endereços IP (CoIP) de propriedade do cliente
+ Tabelas de rotas de gateway local
+ Outposts
+ Amazon S3 on Outposts
+ Sites
+ Sub-redes
Para seguir as melhores práticas para compartilhar recursos do Outposts em um ambiente com várias contas, consulte as seguintes AWS postagens no blog:
+ [Compartilhamento AWS Outposts em um AWS ambiente com várias contas: Parte 1](https://aws.amazon.com/blogs/mt/best-practices-aws-outposts-in-a-multi-account-aws-environment-part-1/)
+ [Compartilhamento AWS Outposts em um AWS ambiente com várias contas: Parte 2](https://aws.amazon.com/blogs/mt/best-practices-aws-outposts-in-a-multi-account-aws-environment-part-2/)
# Resiliência na borda
O pilar de confiabilidade engloba a capacidade de uma carga de trabalho realizar a função pretendida de forma correta e consistente quando se espera que isso aconteça. Isso inclui a capacidade de operar e testar a carga de trabalho durante seu ciclo de vida. Nesse sentido, ao projetar uma arquitetura resiliente na borda, você deve primeiro considerar quais infraestruturas você usará para implantar essa arquitetura. Há três combinações possíveis de implementar usando Zonas locais da AWS e AWS Outposts: posto avançado *para posto avançado, posto avançado para* zona local e *zona local para* *zona local*, conforme ilustrado no diagrama a seguir. Embora existam outras possibilidades para arquiteturas resilientes, como combinar serviços de AWS ponta com a infraestrutura local tradicional Regiões da AWS, ou, este guia se concentra nessas três combinações que se aplicam ao design de serviços de nuvem híbrida
![\[Implementando resiliência na borda com Locais Zones and Outposts.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/resiliency-at-edge-options.png)
## Considerações sobre infraestrutura
Em AWS, um dos princípios fundamentais do design de serviços é evitar pontos únicos de falha na infraestrutura física subjacente. Por causa desse princípio, o AWS software e os sistemas usam várias zonas de disponibilidade e são resilientes às falhas de uma única zona. Na borda, AWS oferece infraestruturas baseadas em Locais Zones e Outposts. Portanto, um fator crítico para garantir a resiliência no design da infraestrutura é definir onde os recursos de um aplicativo são implantados.
### Zonas Locais
As Zonas Locais agem de forma semelhante às Zonas de Disponibilidade dentro delas Região da AWS, pois podem ser selecionadas como um local de posicionamento para AWS recursos zonais, como sub-redes e instâncias EC2. No entanto, eles não estão localizados em um Região da AWS, mas perto de grandes centros populacionais, industriais e de TI onde não Região da AWS existem atualmente. Apesar disso, eles ainda mantêm conexões seguras e de alta largura de banda entre as cargas de trabalho locais na zona local e as cargas de trabalho em execução na. Região da AWS Portanto, você deve usar as Zonas Locais para implantar cargas de trabalho mais próximas de seus usuários para requisitos de baixa latência.
### Outposts
AWS Outposts é um serviço totalmente gerenciado que estende a AWS infraestrutura Serviços da AWS, APIs, e as ferramentas para seu data center. A mesma infraestrutura de hardware usada no Nuvem AWS está instalada em seu data center. Outposts são então conectados ao mais próximo. Região da AWS Você pode usar o Outposts para suportar suas cargas de trabalho com baixa latência ou requisitos locais de processamento de dados.
#### Zonas de disponibilidade para pais
Cada zona local ou posto avançado tem uma região principal (também chamada de *região de origem*). A região principal é onde o plano de controle da infraestrutura de AWS ponta (posto avançado ou zona local) está ancorado. No caso de Zonas Locais, a Região principal é um componente arquitetônico fundamental de uma Zona Local e não pode ser modificada pelos clientes. AWS Outposts estende o Nuvem AWS para seu ambiente local, portanto, você deve selecionar uma região e uma zona de disponibilidade específicas durante o processo de pedido. Essa seleção ancora o plano de controle da implantação do Outposts na AWS infraestrutura escolhida.
Quando você desenvolve arquiteturas de alta disponibilidade na borda, a região principal dessas infraestruturas, como Outposts ou Locais Zones, deve ser a mesma, para que uma VPC possa ser estendida entre elas. Essa VPC estendida é a base para a criação dessas arquiteturas de alta disponibilidade. Ao definir uma arquitetura altamente resiliente, é por isso que você deve validar a região principal e a zona de disponibilidade da região em que o serviço será (ou está) ancorado. Conforme ilustrado no diagrama a seguir, se você quiser implantar uma solução de alta disponibilidade entre dois Postos Avançados, deverá escolher duas Zonas de Disponibilidade diferentes para ancorar os Postos Avançados. Isso permite uma arquitetura Multi-AZ do ponto de vista do plano de controle. Se você quiser implantar uma solução altamente disponível que inclua uma ou mais Zonas Locais, você deve primeiro validar a Zona de Disponibilidade principal na qual a infraestrutura está ancorada. Para isso, use o seguinte AWS CLI comando:
```
aws ec2 describe-availability-zones --zone-ids use1-mia1-az1
```
Saída do comando anterior:
```
{ "AvailabilityZones": [
{
"State": "available",
"OptInStatus": "opted-in",
"Messages": [],
"RegionName": "us-east-1",
"ZoneName": "us-east-1-mia-1a",
"ZoneId": "use1-mia1-az1",
"GroupName": "us-east-1-mia-1",
"NetworkBorderGroup": "us-east-1-mia-1",
"ZoneType": "local-zone",
"ParentZoneName": "us-east-1d",
"ParentZoneId": "use1-az2"
}
]
}
```
Neste exemplo, a Zona Local de Miami (`us-east-1d-mia-1a1`) está ancorada na Zona de `us-east-1d-az2`**** Disponibilidade. **Portanto, se você precisar criar uma arquitetura resiliente na borda, deverá garantir que a infraestrutura secundária (Outposts ou Zonas Locais) esteja ancorada em uma Zona de Disponibilidade diferente de. `us-east-1d-az2`** Por exemplo, `us-east-1d-az1` seria válido.
O diagrama a seguir fornece exemplos de infraestruturas de ponta altamente disponíveis.
![\[Arquiteturas de ponta altamente disponíveis.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/ha-edge-architectures.png)
## Considerações sobre redes
Esta seção discute as considerações iniciais sobre redes na borda, principalmente para conexões para acessar a infraestrutura de borda. Ele analisa arquiteturas válidas que fornecem uma rede resiliente para o link de serviço.
### Rede de resiliência para Zonas Locais
As Zonas Locais são conectadas à região principal com vários links redundantes, seguros e de alta velocidade que permitem que você consuma qualquer serviço regional, como Amazon S3 e Amazon RDS, sem problemas. Você é responsável por fornecer conectividade do seu ambiente local ou dos usuários à Zona Local. Independentemente da arquitetura de conectividade escolhida (por exemplo, VPN ou Direct Connect), a latência que deve ser alcançada por meio dos links de rede deve ser equivalente para evitar qualquer impacto no desempenho do aplicativo no caso de uma falha no link principal. Se você estiver usando Direct Connect, as arquiteturas de resiliência aplicáveis são as mesmas para acessar um Região da AWS, conforme documentado nas recomendações de [Direct Connect resiliência](https://aws.amazon.com/directconnect/resiliency-recommendation/). No entanto, existem cenários que se aplicam principalmente às Zonas Locais internacionais. No país em que a Zona Local está habilitada, ter apenas um único Direct Connect PoP impossibilita a criação das arquiteturas recomendadas para Direct Connect resiliência. Se você tiver acesso a apenas um único Direct Connect local ou precisar de resiliência além de uma única conexão, poderá criar um dispositivo VPN no Amazon EC2 Direct Connect e, conforme ilustrado e discutido na [postagem AWS do blog, habilitar a conectividade altamente disponível](https://aws.amazon.com/blogs/compute/enabling-highly-available-connectivity-from-on-premises-to-aws-local-zones/) do local para o. Zonas locais da AWS
### Rede de resiliência para Outposts
Em contraste com as Zonas Locais, os Outposts têm conectividade redundante para acessar cargas de trabalho implantadas nos Outposts a partir de sua rede local. Essa redundância é obtida por meio de dois dispositivos de rede Outposts (). ONDs Cada OND requer pelo menos duas conexões de fibra de 1 Gbps, 10 Gbps, 40 Gbps ou 100 Gbps para sua rede local. Essas conexões devem ser configuradas como um grupo de agregação de links (LAG) para permitir a adição escalável de mais links.
| Velocidade do uplink | Número de uplinks |
| --- | --- |
| 1 Gbps | 1, 2, 4, 6, ou 8 |
| 10 Gbps | 1, 2, 4, 8, 12, ou 16 |
| 40 ou 100 Gbps | 1, 2, ou 4 |
![\[Rede de resiliência para Outposts\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/outpost-resiliency-networking.png)
Para obter mais informações sobre essa conectividade, consulte [Conectividade de rede local para Outposts Racks na documentação](https://docs.aws.amazon.com/outposts/latest/userguide/local-rack.html). AWS Outposts
Para uma experiência e resiliência ideais, AWS recomenda que você use conectividade redundante de pelo menos 500 Mbps (1 Gbps é melhor) para a conexão do link de serviço com o. Região da AWS Você pode usar Direct Connect ou uma conexão com a Internet para o link do serviço. Esse mínimo permite que você execute instâncias do EC2, anexe volumes e acesse o EBS Serviços da AWS, como Amazon EKS, Amazon EMR e métricas. CloudWatch
O diagrama a seguir ilustra essa arquitetura para uma conexão privada altamente disponível.
![\[Arquitetura de resiliência para uma conexão privada altamente disponível.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/ha-private-connection.png)
O diagrama a seguir ilustra essa arquitetura para uma conexão pública altamente disponível.
![\[Arquitetura de resiliência para uma conexão pública altamente disponível.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/ha-public-connection.png)
### Dimensionando as implantações de rack do Outposts com racks ACE
O rack Aggregation, Core, Edge (ACE) serve como um ponto de agregação crítico para implantações de AWS Outposts vários racks e é recomendado principalmente para instalações que excedam três racks ou para planejar futuras expansões. Cada rack ACE possui quatro roteadores que suportam conexões de 10 Gbps, 40 Gbps e 100 Gbps (100 Gbps é o ideal). Cada rack pode se conectar a até quatro dispositivos upstream do cliente para obter redundância máxima. Os racks ACE consomem até 10 kVA de energia e pesam até 705 libras. Os principais benefícios incluem requisitos reduzidos de rede física, menos uplinks de cabeamento de fibra e menos interfaces virtuais de VLAN. AWS monitora esses racks por meio de dados de telemetria por meio de túneis VPN e trabalha em estreita colaboração com os clientes durante a instalação para garantir a disponibilidade adequada de energia, a configuração da rede e o posicionamento ideal. A arquitetura de rack ACE fornece valor crescente à medida que as implantações se expandem e simplifica efetivamente a conectividade, ao mesmo tempo em que reduz a complexidade e os requisitos de portas físicas em instalações maiores. Para obter mais informações, consulte a postagem do AWS blog [Dimensionando implantações de AWS Outposts rack com ACE](https://aws.amazon.com/blogs/compute/scaling-aws-outposts-rack-deployments-with-ace-racks/) Rack.
## Distribuindo instâncias em Outposts e Zonas Locais
Outposts e Locais Zones têm um número finito de servidores computacionais. Se seu aplicativo implantar várias instâncias relacionadas, essas instâncias poderão ser implantadas no mesmo servidor ou em servidores no mesmo rack, a menos que estejam configuradas de forma diferente. Além das opções padrão, você pode distribuir instâncias entre servidores para reduzir o risco de executar instâncias relacionadas na mesma infraestrutura. Você também pode distribuir instâncias em vários racks usando grupos de posicionamento de partições. Isso é chamado de modelo de distribuição de *spread rack*. Use a distribuição automática para distribuir instâncias entre as partições do grupo ou implante instâncias em partições de destino selecionadas. Ao implantar instâncias nas partições de destino, você pode implantar recursos selecionados no mesmo rack enquanto distribui outros recursos entre os racks. Outposts também fornece outra opção chamada *spread host*, que permite distribuir sua carga de trabalho no nível do host. O diagrama a seguir mostra as opções de distribuição do spread rack e do spread host.
![\[Opções de distribuição de Spread Rack e Spread Host para Outposts e Locais Zones.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/spread-rack-host-distribution.png)
## Amazon RDS Multi-AZ em AWS Outposts
Quando você usa implantações de instâncias Multi-AZ em Outposts, o Amazon RDS cria duas instâncias de banco de dados em dois Outposts. Cada posto avançado funciona em sua própria infraestrutura física e se conecta a diferentes zonas de disponibilidade em uma região para obter alta disponibilidade. Quando dois Outposts são conectados por meio de uma conexão local gerenciada pelo cliente, o Amazon RDS gerencia a replicação síncrona entre as instâncias de banco de dados primária e em espera. No caso de uma falha de software ou infraestrutura, o Amazon RDS promove automaticamente a instância em espera para a função principal e atualiza o registro DNS para apontar para a nova instância primária. No caso de implantações multi-AZ, o Amazon RDS cria uma instância de banco de dados primário em um Outpost e replica de forma síncrona os dados em uma instância de banco de dados em espera em outro Outpost. As implantações Multi-AZ em Outposts operam como implantações Multi-AZ em Regiões da AWS, com as seguintes diferenças:
+ Elas exigem uma conexão local entre dois ou mais Outposts.
+ Eles exigem pools de endereços IP de propriedade do cliente (CoIP). Para obter mais informações, consulte [Endereços IP de propriedade do cliente para o Amazon RDS na documentação AWS Outposts](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-on-outposts.coip.html) do Amazon RDS.
+ A replicação é realizada na sua rede local.
As implantações Multi-AZ estão disponíveis para todas as versões compatíveis do MySQL e do PostgreSQL no Amazon RDS on Outposts. Os backups locais não são compatíveis com implantações Multi-AZ.
O diagrama a seguir mostra a arquitetura do Amazon RDS nas configurações Multi-AZ do Outposts.
![\[Configurações Multi-AZ para Amazon RDS em Outposts.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/rds-outposts-multi-az.png)
## Mecanismos de failover
### Balanceamento de carga e escalabilidade automática
O Elastic Load Balancing (ELB) distribui automaticamente o tráfego de entrada do aplicativo em todas as instâncias do EC2 que você está executando. O ELB ajuda a gerenciar as solicitações recebidas roteando o tráfego de forma otimizada para que nenhuma instância fique sobrecarregada. Para usar o ELB com seu grupo Amazon EC2 Auto Scaling, conecte o balanceador de carga ao seu grupo Auto Scaling. Isso registra o grupo com o balanceador de carga, que atua como um único ponto de contato para todo o tráfego de entrada da web em seu grupo. Quando você usa o ELB com seu grupo de Auto Scaling, não é necessário registrar instâncias individuais do EC2 com o balanceador de carga. As instâncias iniciadas pelo grupo do Auto Scaling serão automaticamente registradas no balanceador de carga. Da mesma forma, as instâncias que são encerradas pelo seu grupo de Auto Scaling são automaticamente canceladas do balanceador de carga. Depois de conectar um balanceador de carga ao seu grupo do Auto Scaling, você pode configurar seu grupo para usar métricas do ELB (como a contagem de solicitações do Application Load Balancer por destino) para escalar o número de instâncias no grupo conforme a demanda flutua. Opcionalmente, você pode adicionar verificações de saúde do ELB ao seu grupo de Auto Scaling para que o Amazon EC2 Auto Scaling possa identificar e substituir instâncias não íntegras com base nessas verificações de saúde. Você também pode criar um CloudWatch alarme da Amazon que o notifique se a contagem saudável de anfitriões do grupo-alvo estiver abaixo do permitido.
O diagrama a seguir ilustra como um Application Load Balancer gerencia cargas de trabalho no Amazon EC2 em. AWS Outposts
![\[Balanceamento de carga para cargas de trabalho do Amazon EC2 em Outposts.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/alb-in-outposts.png)
O diagrama a seguir ilustra uma arquitetura similar para o Amazon EC2 em Locais Zones.
![\[Balanceamento de carga para cargas de trabalho do Amazon EC2 em Zonas Locais.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/alb-in-local-zones.png)
**nota**
Os Application Load Balancers estão disponíveis em ambas as Zonas AWS Outposts e em Locais. No entanto, para usar um Application Load Balancer em AWS Outposts, você precisa dimensionar a capacidade do Amazon EC2 para fornecer a escalabilidade que o balanceador de carga exige. Para obter mais informações sobre o dimensionamento de um balanceador de carga em AWS Outposts, consulte a postagem do AWS blog [Configurando um Application Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-an-application-load-balancer-on-aws-outposts/) em. AWS Outposts
### Amazon Route 53 para failover de DNS
Quando você tem mais de um recurso executando a mesma função, por exemplo, vários servidores HTTP ou de e-mail, você pode configurar o [Amazon Route](https://aws.amazon.com/route53/) 53 para verificar a integridade dos seus recursos e responder às consultas de DNS usando somente os recursos íntegros. Por exemplo, vamos supor que seu site,`example.com`, esteja hospedado em dois servidores. Um servidor está em uma zona local e o outro em um posto avançado. Você pode configurar o Route 53 para verificar a integridade desses servidores e responder às consultas de DNS `example.com` usando somente os servidores que estão íntegros no momento. Se você estiver usando registros de alias para rotear o tráfego para AWS recursos selecionados, como balanceadores de carga do ELB, você pode configurar o Route 53 para avaliar a integridade do recurso e rotear o tráfego somente para recursos que estejam íntegros. Ao configurar um registro de alias para avaliar a integridade de um recurso, você não precisa criar uma verificação de saúde para esse recurso.
O diagrama a seguir ilustra os mecanismos de failover do Route 53.
![\[Mecanismos de failover do Route 53 para Outposts e Locais Zones.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/hybrid-cloud-best-practices/images/route-53-failover.png)
**Observações**
Se você estiver criando registros de failover em uma zona hospedada privada, poderá criar uma CloudWatch métrica, associar um alarme à métrica e, em seguida, criar uma verificação de integridade com base no fluxo de dados do alarme.
Para tornar um aplicativo acessível publicamente AWS Outposts usando um Application Load Balancer, defina configurações de rede que habilitem a Tradução de Endereços de Rede de Destino (DNAT) do público IPs para o nome de domínio totalmente qualificado (FQDN) do balanceador de carga e crie uma regra de failover do Route 53 com verificações de integridade que apontem para o IP público exposto. Essa combinação garante acesso público confiável ao seu aplicativo hospedado no Outposts.
### Amazon Route 53 Resolver em AWS Outposts
[Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)está disponível nos racks Outposts. Ele fornece aos seus serviços e aplicativos locais resolução de DNS local diretamente do Outposts. Os endpoints locais do Route 53 Resolver também permitem a resolução de DNS entre Outposts e seu servidor DNS local. O Route 53 Resolver on Outposts ajuda a melhorar a disponibilidade e o desempenho de seus aplicativos locais.
Um dos casos de uso típicos do Outposts é implantar aplicativos que exigem acesso de baixa latência a sistemas locais, como equipamentos de fábrica, aplicativos comerciais de alta frequência e sistemas de diagnóstico médico.
Quando você opta por usar resolvedores locais do Route 53 em Outposts, os aplicativos e serviços continuarão se beneficiando da resolução de DNS local para descobrir outros serviços, mesmo que a conectividade com um Região da AWS dos pais seja perdida. Os resolvedores locais também ajudam a reduzir a latência das resoluções de DNS porque os resultados das consultas são armazenados em cache e veiculados localmente a partir dos Outposts, o que elimina viagens de ida e volta desnecessárias ao pai. Região da AWS Todas as resoluções de DNS para aplicativos em Outposts VPCs que usam [DNS privado](https://docs.aws.amazon.com/managedservices/latest/userguide/set-dns.html) são servidas localmente.
Além de habilitar resolvedores locais, esse lançamento também habilita endpoints locais do Resolver. Os endpoints de saída do Route 53 Resolver permitem que os resolvedores do Route 53 encaminhem consultas de DNS para os resolvedores de DNS que você gerencia, por exemplo, em sua rede local. Por outro lado, os endpoints de entrada do Route 53 Resolver encaminham as consultas de DNS que recebem de fora da VPC para o Resolver que está sendo executado nos Outposts. Ele permite que você envie consultas de DNS para serviços implantados em uma VPC privada do Outposts de fora dessa VPC. Para obter mais informações sobre endpoints de entrada e saída, consulte [Resolvendo consultas de DNS entre VPCs e sua rede](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) na documentação do Route 53.
# Planejamento de capacidade na periferia
A fase de planejamento da capacidade envolve a coleta dos requisitos de vCPU, memória e armazenamento para implantar sua arquitetura. No pilar de otimização de custos do [AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html) Framework, o dimensionamento correto é um processo contínuo que começa com o planejamento. Você pode usar AWS ferramentas para definir otimizações com base no consumo de recursos no interior. AWS
O planejamento da capacidade periférica em Locais Zonas é o mesmo que em Regiões da AWS. Você deve verificar se suas instâncias estão disponíveis em cada zona local, pois alguns tipos de instância podem ser diferentes dos tipos em Regiões da AWS. Para Outposts, você deve planejar a capacidade com base em seus requisitos de carga de trabalho. Outposts são distribuídos com números fixos de instâncias por host e podem ser redistribuídos conforme necessário. Se suas cargas de trabalho exigirem capacidade ociosa, leve isso em consideração ao planejar suas necessidades de capacidade.
## Planejamento de capacidade em Outposts
AWS Outposts o planejamento de capacidade requer insumos específicos para o dimensionamento regional correto, além de fatores específicos que afetam a disponibilidade, o desempenho e o crescimento dos aplicativos. Para obter orientação detalhada, consulte [Planejamento de capacidade](https://docs.aws.amazon.com/whitepapers/latest/aws-outposts-high-availability-design/capacity-planning.html) no AWS whitepaper Considerações sobre *design e arquitetura de AWS Outposts alta disponibilidade*.
## Planejamento de capacidade para Zonas Locais
Uma zona local é uma extensão de uma Região da AWS que está geograficamente próxima aos seus usuários. Os recursos criados em uma zona local podem atender usuários locais com comunicações de latência muito baixa. Para habilitar uma zona local em sua Conta da AWS, [consulte Introdução Zonas locais da AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) na AWS documentação. Cada zona local tem um slot diferente disponível para famílias de EC2 instâncias. Valide as [instâncias disponíveis em cada zona local](https://aws.amazon.com/about-aws/global-infrastructure/localzones/locations/) antes de usá-las. Para confirmar as EC2 instâncias disponíveis, execute o seguinte AWS CLI comando:
```
aws ec2 describe-instance-type-offerings \
--location-type "availability-zone" \
--filters Name=location,Values=
```
Saída esperada:
```
{
"InstanceTypeOfferings": [
{
"InstanceType": "m5.2xlarge",
"LocationType": "availability-zone",
"Location": ""
},
{
"InstanceType": "t3.micro",
"LocationType": "availability-zone",
"Location": "local.zone-name"
},
...
]
}
```
# Gerenciamento de infraestrutura de ponta
AWS fornece serviços totalmente gerenciados que ampliam a AWS infraestrutura APIs, os serviços e as ferramentas para mais perto de seus usuários finais e data centers. Os serviços que estão disponíveis em Outposts e Locais Zones são os mesmos que estão disponíveis em Regiões da AWS, então você pode gerenciar esses serviços usando o mesmo AWS console, AWS CLI, ou. AWS APIs Para ver os serviços compatíveis, consulte a AWS Outposts tabela de [comparação](https://aws.amazon.com/outposts/) de [Zonas locais da AWS recursos e os recursos](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/).
## Implantação de serviços na borda
Você pode configurar os serviços disponíveis em Locais Zones e Outposts da mesma forma que os configura em Regiões da AWS: usando o AWS console, AWS CLI, ou. AWS APIs A principal diferença entre implantações regionais e periféricas são as sub-redes nas quais os recursos serão provisionados. A seção [Rede na borda](networking.md) descreveu como as sub-redes são implantadas em Outposts e Locais Zones. Depois de identificar as sub-redes de borda, você usa a ID da sub-rede de borda como um parâmetro para implantar o serviço em Outposts ou Locais Zones. As seções a seguir fornecem exemplos de implantação de serviços de borda.
### Amazon EC2 no limite
O `run-instances` exemplo a seguir inicia uma única instância do tipo `m5.2xlarge` na sub-rede de borda da região atual. O key pair é opcional se você não planeja se conectar à sua instância usando SSH no Linux ou protocolo de desktop remoto (RDP) no Windows.
```
aws ec2 run-instances \
--image-id ami-id \
--instance-type m5.2xlarge \
--subnet-id \
--key-name MyKeyPair
```
### Balanceadores de carga de aplicativos na borda
O `create-load-balancer` exemplo a seguir cria um Application Load Balancer interno e ativa as Locais Zones ou Outposts para as sub-redes especificadas.
```
aws elbv2 create-load-balancer \
--name my-internal-load-balancer \
--scheme internal \
--subnets
```
Para implantar um Application Load Balancer voltado para a Internet em uma sub-rede em um Outpost, você define `internet-facing` o sinalizador na opção e fornece [um `--scheme` ID do pool CoIP](https://docs.aws.amazon.com/outposts/latest/userguide/local-rack.html#local-gateway-subnet), conforme mostrado neste exemplo:
```
aws elbv2 create-load-balancer \
--name my-internal-load-balancer \
--scheme internet-facing \
--customer-owned-ipv4-pool
--subnets
```
Para obter informações sobre a implantação de outros serviços na borda, siga estes links:
| **Serviço** | **AWS Outposts** | **Zonas locais da AWS** |
| --- | --- | --- |
| Amazon EKS | [Implante o Amazon EKS localmente com AWS Outposts](https://docs.aws.amazon.com/eks/latest/userguide/eks-outposts.html) | [Inicie clusters EKS de baixa latência com Zonas locais da AWS](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html) |
| Amazon ECS | [Amazon ECS em AWS Outposts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-on-outposts.html) | [Aplicativos do Amazon ECS em sub-redes compartilhadas, Zonas Locais e Zonas de Wavelength](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-regions-zones.html) |
| Amazon RDS | [Amazon RDS ativado AWS Outposts](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-on-outposts.html) | Selecione a sub-rede da zona local |
| Amazon S3 | [Começando a usar o Amazon S3 no Outposts](https://docs.aws.amazon.com/AmazonS3/latest/s3-outposts/S3OutpostsGS.html) | Não disponível |
| Amazon ElastiCache | [Usando Outposts com ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/ElastiCache-Outposts.html) | [Usando Locais Zones com ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Local_zones.html) |
| Amazon EMR | [Clusters EMR em AWS Outposts](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-outposts.html) | [Clusters EMR em Zonas locais da AWS](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-localzones.html) |
| Amazon FSx | Não disponível | Selecione a sub-rede da zona local |
| AWS Elastic Disaster Recovery | [Trabalhando com AWS Elastic Disaster Recovery e AWS Outposts](https://docs.aws.amazon.com/drs/latest/userguide/outposts.html) | Não disponível |
| AWS Application Migration Service | Não disponível | Selecione a sub-rede Local Zone como sub-rede de teste |
## CLI e SDK específicos do Outposts
AWS Outposts tem dois grupos de comandos e APIs para criar uma ordem de serviço ou manipular as tabelas de roteamento entre o gateway local e sua rede local.
### Processo de pedido do Outposts
Você pode usar o [AWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/outposts/index.html)ou os [Outposts APIs](https://docs.aws.amazon.com/outposts/latest/APIReference/API_Operations.html) para criar um site de Outposts, criar um Outposts e criar uma ordem de Outposts. Recomendamos que você trabalhe com um especialista em nuvem híbrida durante o processo de AWS Outposts pedido para garantir a seleção adequada do recurso IDs e a configuração ideal para suas necessidades de implementação. Para obter uma lista completa de IDs de recursos, consulte a página de [preços AWS Outposts dos racks](https://aws.amazon.com/outposts/rack/pricing/).
### Gerenciamento de gateway local
O gerenciamento e a operação do gateway local (LGW) no Outposts exigem conhecimento dos comandos e AWS CLI do SDK disponíveis para essa tarefa. Você pode usar o AWS CLI e AWS SDKs para criar e modificar rotas LGW, entre outras tarefas. Para obter mais informações sobre o gerenciamento do LGW, consulte estes recursos:
+ [AWS CLI para Amazon EC2](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/index.html)
+ EC2.Client no [AWS SDK para Python (Boto)](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html)
+ Ec2Client no [AWS SDK para Java](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/services/ec2/Ec2Client.html)
### CloudWatch métricas e registros
Por Serviços da AWS estarem disponíveis tanto nos Outposts quanto nas Zonas Locais, as métricas e os registros são gerenciados da mesma forma que nas Regiões. CloudWatch A Amazon fornece métricas dedicadas ao monitoramento de Outposts nas seguintes dimensões:
| **Dimensão** | **Descrição** |
| --- | --- |
| `Account` | A conta ou serviço usando a capacidade |
| `InstanceFamily` | A família de instâncias |
| `InstanceType` | O tipo de instância |
| `OutpostId` | O ID do Posto Avançado |
| `VolumeType` | O tipo de volume do EBS |
| `VirtualInterfaceId` | O ID do gateway local ou da interface virtual do link de serviço (VIF) |
| `VirtualInterfaceGroupId` | O ID do grupo VIF para o gateway local VIF |
Para obter mais informações, consulte [CloudWatch as métricas dos racks do Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html) na documentação do Outposts.