Temos um servidor de banco de dados de produção que, no momento, não é acessível publicamente, não tem endereço IP público e fica em uma sub-rede VPC privada.
No momento, só é acessível a partir de aplicativos que estão sendo executados no EC2 na mesma VPC.
Agora temos a necessidade de permitir acesso remoto limitado a esse banco de dados a outro fornecedor, fora da nossa conta da Amazon e da VPC.
Eu tenho uma lista pré-definida de endereços IP que precisam de acesso.
Estou tentando descobrir a melhor maneira de fazer isso, com o mínimo de interrupção para qualquer um dos nossos outros aplicativos sendo executados em nosso VPC.
Eu poderia alterar as instâncias do banco de dados para usar IPs públicos, mas, depois de testar isso em um banco de dados de teste, vejo que o EC2 começa a resolver o terminal da instância para o endereço público. Eu estou supondo que isso vai bagunçar nossas regras de roteamento VPC e grupos de segurança, e potencialmente quebrar o acesso para nossos aplicativos.
O que eu gostaria, é que nossos aplicativos internos continuem acessando o banco de dados exatamente como sempre, através dos endereços IP privados, mas de alguma forma dê ao aplicativo remover um endereço público no qual ele possa acessar o banco de dados.
Aparentemente, o aplicativo de terceiros não pode usar um túnel SSH ou VPN. Ele precisa de uma conexão TCP direta com um endereço IP público.
Não consegui encontrar nenhuma documentação na Amazon para esse tipo de configuração.
Se você não tiver concessões ou ACL com base no endereço IP de origem em mysqld , nesse caso apenas criar uma instância micro aws e configurar o encaminhador de porta, como rinetd , para encaminhar conexões de entrada destinadas para a porta mysqld de endereços IP na lista de permissões para sua instância do RDS.
Apenas no caso de ser útil para qualquer outra pessoa. Foi assim que acabei fazendo isso ...
1) Lançou um pequeno EC2 na minha sub-rede privada.
2) Configurou uma instância mínima de nginx.
A versão do pacote não tem o módulo de streaming incluído, então eu criei um assim ...
./configure --with-stream --without-http_rewrite_module
Esta instância só será usada para este propósito específico, então eu não precisei de nenhum outro módulo nginx.
3) Eu configurei meu nginx.conf assim ...
events {
worker_connections 1024;
}
stream {
upstream rds_db_1 {
server [aurora_endpoint_1]:3306;
}
upstream rds_db_1 {
server [aurora_endpoint_2]:3306;
}
...
server {
listen 33061;
proxy_pass rds_db_1;
}
server {
listen 33062;
proxy_pass rds_db_2;
}
...
}
No meu caso, eu tinha várias conexões com proxy, então usei números de porta alta personalizados para distinguir cada conexão (33061, 33062, ...). Essas portas são totalmente arbitrárias.
Se você está apenas fazendo uma conexão, então você pode apenas ter o nginx escutando no número normal da porta do mysql.
4) Configure um balanceador de carga de rede NLB em uma sub-rede pública, para encaminhar solicitações para a instância.
Eu também poderia ter colocado a instância do proxy na sub-rede pública e pulado o balanceador de carga, mas isso parecia ser uma maneira mais segura de fazê-lo.
Em seguida, configurei o grupo de segurança para a instância para permitir solicitações do VPC CIDR (para a verificação de integridade da instância NLB- >) e dos IPs externos do fornecedor.
Os balanceadores de carga de rede não podem ser configurados diretamente com grupos de segurança, portanto, as regras de segurança precisam ser configuradas diretamente na instância de destino.
5) Eu criei usuários customizados do mysql especificamente para o fornecedor.
6) Finalmente eu configurei um registro DNS amigável para apontar para o meu NLB.
Tags amazon-rds