AWS VPC: perché avere una sottorete privata?

8

In Amazon VPC, la procedura guidata di creazione VPC consente di creare una singola "sottorete pubblica" o di creare una "sottorete pubblica" e una "sottorete privata". Inizialmente, l'opzione della sottorete pubblica e privata sembrava buona per motivi di sicurezza, consentendo ai server Web di essere inseriti nella sottorete pubblica e i server di database per passare alla sottorete privata.

Ma da allora ho imparato che le istanze EC2 nella sottorete pubblica non sono raggiungibili da Internet a meno che tu non associ un Amazon ElasticIP all'istanza EC2. Così sembra con una sola configurazione di sottorete pubblica, si potrebbe semplicemente scegliere di non associare un ElasticIP ai server di database e finire con lo stesso tipo di sicurezza.

Qualcuno può spiegare i vantaggi di una configurazione di sottorete pubblica + privata? I vantaggi di questa configurazione hanno più a che fare con il ridimensionamento automatico o è in realtà meno sicuro avere un'unica sottorete pubblica?

amazon-web-services amazon-vpc

— JKim
fonte

Per quello che vale, le istanze EC2 nella sottorete pubica possono essere raggiunte da Internet, anche senza un ElasticIP: ottengono comunque un indirizzo IP pubblico. La differenza tra questo indirizzo IP pubblico e un ElasticIP è semplicemente che l'indirizzo IP pubblico può cambiare quando riavvii l'istanza, mentre un ElasticIP rimane attivo per tutto il tempo che desideri.

— entro il

4

È un limite di sicurezza avere una sottorete privata che è possibile controllare con diversi gruppi di sicurezza dalla sottorete pubblica. Se una delle tue istanze nella sottorete pubblica è stata hackerata, sarà molto più difficile hackerare le istanze nella sottorete privata se non sei troppo liberale nelle tue politiche di accesso.

— generalnetworkerror
fonte

1

Grazie. VPC con sottorete pubica + privata sembra la strada da percorrere se AWS lanciasse un'istanza NAT gratuitamente. Sto pensando a piccole distribuzioni e stavo cercando di capire se il costo di un'istanza NAT ogni mese valesse i vantaggi della configurazione della 2 sottorete.

— JKim

2

@jkim È considerevolmente più conveniente ora che finalmente supportano t1.microin un VPC.

— Jeffrey Hantin,

2

Oltre alle implicazioni per la sicurezza, c'è anche un altro aspetto che entra in gioco: se si desidera consentire alle istanze senza IP elastici di accedere a Internet, potrebbero essere necessarie 2 (o più) sottoreti diverse.

Parafrasando la documentazione di AWS , all'interno di un VPC esistono tre modi per consentire alle istanze l'accesso a Internet:

IP elastici - ma penso che tu ne abbia solo 5 di default, e poi devi pagare di più
Instradare il traffico attraverso un Virtual Private Gateway: è necessario disporre di una connessione VPN hardware alla rete aziendale (o domestica)
Configurare un'istanza NAT e instradare tutto il traffico in uscita tramite NAT

La terza opzione è quella interessante in quanto l'istanza NAT deve trovarsi all'interno di una sottorete "pubblica" in cui tutto il traffico in uscita viene indirizzato a un gateway Internet, ma tutte le altre istanze devono trovarsi in una sottorete "privata" in cui tutto il traffico in uscita è instradato all'istanza NAT.

In breve, se hai intenzione di utilizzare un NAT, hai bisogno di almeno 2 sottoreti.

— Tom Poulton
fonte

Grazie Tom. Penso che sia anche possibile avere 1 sottorete pubblica ma assegnare solo un ElasticIP all'istanza NAT. Le altre istanze della sottorete pubblica avranno accesso a Internet in uscita tramite Internet Gateway e l'accesso in entrata potrebbe essere configurato tramite port forwarding sull'istanza NAT. Ho avuto la sensazione che 2 sottoreti siano il modo "corretto", ma non vedevo una ragione chiara per questo.

— JKim,