Alta latência de ELB usando NAT e sub-redes públicas / privadas

Question

Eu comecei com uma configuração VPC padrão para nosso aplicativo, mas ficou um pouco mais complexo recentemente. Então, basicamente, estamos usando um cluster do ECS com 1 instância do EC2. 1 ELB que está ligado ao serviço do ECS.

Recentemente, tivemos que implementar o SQS com o Lambda e encarar o fato de termos que usar o NAT para para a função lambda para acessar a fila do SQS. Desde que adicionamos esse NAT, tudo deu errado.

Portanto, em termos de configuração de rede, é o padrão:

- 1 VPC (172.31.0.0/16)
- 2 Public subnets: 
  - pubsub1 - CIDR: 172.31.48.0/20
  - pubsub2 - CIDR: 172.31.0.0/20
- 2 Private subnets:
  - privsub1 - CIDR: 172.31.16.0/20
  - privsub2 - CIDR: 172.31.32.0/20

- 1 Main route table (not explicitelly assign to any subnets):
  - 172.31.0.0/16 -> local
  - 0.0.0.0/0 -> igw
- 1 Public route table (pubsub1 and pubsub2):
  - 172.31.0.0/16 -> local
  - 0.0.0.0/0 -> igw
- 1 Private route table (privsub1 and privsub2):
  - 172.31.0.0/16 -> local
  - 0.0.0.0/0 -> NAT

• RDS usando o grupo de sub-redes padrão ( pubsub1 , pubsub2 , privsub1 e privsub2 )
• EC2 (parte do cluster do ECS) usando a sub-rede privsub1
• ELB usando sub-redes pubsub1 e pubsub2
• Lambda usando subnets privsub1 e privsub2

O ELB está relatando que o healthcheck está falhando e remove minha instância do EC2 do pool. no entanto, se eu ssh a caixa EC2 (usando um intermediário ec2 servidor em sub-rede pública), e tente enrolar localhost: 80 / healthcheck.html (que é a configuração do healthbeck do ELB) está respondendo corretamente.

Eu também verifico os grupos de segurança:

- 1 security group for the ELB allowing HTTP and HTTPS to ALL inbound source and allowing ALL outbound traffic
- 1 security group for the EC2 server allowing HTTP inbound from the elb-security-group (I also tried from all source)
- 1 security group for the RDS allowing TCP connection on database from ec2-security-group

Se eu adicionar o ELB às duas sub-redes privadas, o healthcheck estará funcionando. No entanto, executando uma solicitação de onda, posso ver alta latência:

HTTPCode=200 TotalTime=1.401
HTTPCode=200 TotalTime=1.660
HTTPCode=200 TotalTime=1.537
HTTPCode=200 TotalTime=1.529
HTTPCode=200 TotalTime=1.519

Neste momento, estou um pouco perdido e não tenho ideia do que fazer. Tenho certeza que é um problema de rede, mas não posso isolá-lo.

Aqui está uma das temporizações de solicitações do Chrome:

eumpedidoidênticosubsequente:

TambémposteinofórumdaAWS: link

UPDATE1

Eu habilitei o balanceamento de carga entre zonas no meu ELB para corrigir meu problema de verificação de integridade (o ELB está em sub-redes públicas e o EC2 em particular). A ACL da rede é a padrão e permite tudo.

1. A latência do ELB ainda é a mesma (1 a 2 segundos)

   • Movendo o EC2 em sub-rede pública e atingindo a caixa diretamente, o tempo de resposta é reduzido para 400 ms

2. A instância do RDS que está em sub-redes públicas e sub-redes privadas não está acessível em nosso escritório (fora do mundo) desde que adicionamos o NAT.

UPDATE2

Corrigi o problema que tivemos com o RDS não acessível em nosso escritório. Eu acho que o fato de que nós habilitamos o NAT e que o RDS estava usando as 4 sub-redes (2 públicas e 2 privadas) causou o problema.
O RDS precisava APENAS usar as sub-redes públicas . No entanto, modificar o grupo de sub-redes para o RDS não é suficiente. Embora os detalhes das informações do RDS mostrem que a sub-rede foi alterada, ela não está levando isso em consideração.

A partir do Perguntas frequentes da AWS :

Q: Can I change the DB Subnet Group of my DB Instance?

[...] At the present time, updating an existing DB Subnet Group does not change the current subnet of the deployed DB instance; an instance-type scale operation is required. Explicitly changing the DB Subnet Group of a deployed DB instance is not currently allowed.

Portanto, a única maneira é alterar o tamanho da instância do RDS ou implantar uma nova instância a partir de um instantâneo do banco de dados, especificando o novo grupo de sub-redes (que é APENAS usando sub-redes públicas). Certifique-se de que o grupo de segurança também seja o correto, porque ele está selecionando o padrão por padrão.

Ainda estou investigando a latência do ELB ...