Topologia di rete e connettività per l'acceleratore di zona di destinazione di Azure Spring Apps

Questo articolo descrive considerazioni sulla progettazione e raccomandazioni per la rete in cui viene inserito il carico di lavoro Spring Boot. La progettazione di destinazione dipende dai requisiti del carico di lavoro e dai requisiti di sicurezza e conformità dell'organizzazione.

Il team centralizzato della piattaforma e il team dell'applicazione condividono la responsabilità dell'area di progettazione di rete. Il team della piattaforma seleziona la topologia di rete, che può essere un modello hub-spoke tradizionale o rete WAN virtuale topologia di rete (gestita da Microsoft). Il team dell'applicazione è responsabile delle scelte di progettazione della rete spoke. Il carico di lavoro deve avere dipendenze dai servizi condivisi gestiti dalla piattaforma. Il team dell'applicazione deve comprendere le implicazioni di tali dipendenze e comunicare i propri requisiti in modo che vengano soddisfatti gli obiettivi generali del carico di lavoro.

Per altre informazioni sulla progettazione della piattaforma, vedere Topologia di rete e connettività.

Seguire queste considerazioni di progettazione e raccomandazioni come procedure consigliate per la subnet, l'ingresso e i controlli in uscita.

Considerazioni relative alla progettazione

• Isolamento. Il team centrale può fornire una rete virtuale per il team dell'applicazione per eseguire i carichi di lavoro. Se il carico di lavoro Spring Boot ha una separazione delle preoccupazioni da altri carichi di lavoro, prendere in considerazione il provisioning della propria rete virtuale per il runtime del servizio Spring App e l'applicazione.

• Subnet. Valutare la scalabilità dell'applicazione quando si sceglie la dimensione della subnet e il numero di applicazioni.

  Se si usano subnet esistenti o si usano tabelle di route personalizzate, sono disponibili criteri per assicurarsi che le regole aggiunte da Azure Spring Apps non vengano aggiornate o eliminate.

  Un altro aspetto è la sicurezza. Prendere in considerazione le regole che consentono o negano il traffico nella subnet.

• Traffico in uscita (in uscita). Il traffico che passa dalla rete virtuale deve essere instradato attraverso Firewall di Azure o appliance virtuale di rete.

  Prendere in considerazione le limitazioni del servizio di bilanciamento del carico predefinito fornito da Azure Spring Apps. In base ai requisiti, potrebbe essere necessario personalizzare i percorsi in uscita usando il routing definito dall'utente,ad esempio per instradare tutto il traffico tramite un'applicazione di rete virtuale di rete.

• Traffico in ingresso (in ingresso). È consigliabile usare un proxy inverso per il traffico che passa ad Azure Spring Apps. In base ai requisiti, scegliere opzioni native, ad esempio gateway applicazione di Azure e Frontdoor o servizi regionali, ad esempio Gestione API (APIM). Se queste opzioni non soddisfano le esigenze del carico di lavoro, è possibile considerare i servizi non di Azure.

Suggerimenti per la progettazione

Queste raccomandazioni forniscono indicazioni prescrittive per il set precedente di considerazioni.

Rete virtuale e subnet

• Azure Spring Apps richiede l'autorizzazione proprietario per la rete virtuale. Questo ruolo è necessario per concedere un'entità servizio dedicata e dinamica per la distribuzione e la manutenzione. Per altre informazioni, vedere Distribuire Azure Spring Apps in una rete virtuale.

• Azure Spring Apps distribuito in una rete privata fornisce un nome di dominio completo (FQDN) accessibile solo all'interno della rete privata. Creare una zona DNS privata di Azure per l'indirizzo IP dell'app Spring. Collegare il DNS privato alla rete virtuale assegnando un nome di dominio completo privato in Azure Spring Apps. Per istruzioni dettagliate, vedere Accedere all'applicazione in una rete privata.

• Azure Spring Apps richiede due subnet dedicate. Una subnet ha il runtime del servizio e l'altra subnet è per le applicazioni Spring Boot.

  La dimensione minima del blocco CIDR di ognuna di queste subnet è /28. La subnet di runtime e la subnet dell'applicazione necessitano di uno spazio di indirizzi minimo di /28. Tuttavia, il numero di app Spring che è possibile distribuire influisce sulle dimensioni della subnet. Per informazioni sulle istanze massime dell'app in base all'intervallo di subnet, vedere Uso di intervalli di subnet più piccoli.

• Se si usa gateway applicazione di Azure come proxy inverso davanti ad Azure Spring Apps, è necessaria un'altra subnet per tale istanza. Per altre informazioni, vedere Uso di gateway applicazione come proxy inverso.

• Usare gruppi di sicurezza di rete nelle subnet per filtrare il traffico est-ovest per limitare il traffico alla subnet di runtime del servizio.

• I gruppi di risorse e le subnet gestite dalla distribuzione di Azure Spring Apps non devono essere modificati.

Traffico in uscita

• Per impostazione predefinita, Azure Spring Apps ha accesso Internet in uscita senza restrizioni. Usare un'interfaccia virtuale di rete, ad esempio Firewall di Azure per filtrare il traffico nord-sud. Sfruttare Firewall di Azure nella rete hub centralizzata per ridurre il sovraccarico di gestione.

  Nota

  Il traffico in uscita ai componenti di Azure Spring è necessario per supportare le istanze del servizio. Per informazioni su endpoint e porte specifici, vedere Requisiti di rete di Azure Spring Apps.

• Azure Spring Apps fornisce un tipo di route definito dall'utente (UDR) per controllare completamente il percorso del traffico in uscita. OutboundType deve essere definito quando viene creata una nuova istanza del servizio Azure Spring Apps. Non può essere aggiornato in seguito. OutboundType può essere configurato solo con una rete virtuale. Per altre informazioni, vedere Personalizzare l'uscita di Azure Spring Apps con una route definita dall'utente.

• L'applicazione deve comunicare con altri servizi di Azure nella soluzione. Usare collegamento privato di Azure per i servizi supportati se le applicazioni richiedono connettività privata.

Traffico in ingresso

• Usare un proxy inverso per assicurarsi che gli utenti malintenzionati non siano autorizzati a ignorare il web application firewall (WAF) o a aggirare i limiti di limitazione. è consigliabile gateway applicazione di Azure con WAF integrato.

  Se si usa il livello Enterprise, usare l'endpoint assegnato dell'app Spring Cloud Gateway come pool back-end del gateway applicazione. Questo endpoint viene risolto in un indirizzo IP privato nella subnet di runtime del servizio Azure Spring Apps.

  Aggiungere un gruppo di sicurezza di rete nella subnet di runtime del servizio che consente il traffico solo dalla subnet gateway applicazione, dalla subnet di Azure Spring Apps e Azure Load Balancer.

  Nota

  È possibile scegliere un'alternativa per il proxy inverso, ad esempio Frontdoor di Azure o servizi non di Azure. Per informazioni sulle opzioni di configurazione, vedere Esporre Azure Spring Apps tramite un proxy inverso.

• Azure Spring Apps può essere distribuito in una rete virtuale tramite l'inserimento di reti virtuali o all'esterno della rete. Per altre informazioni, vedere Riepilogo della configurazione.

Passaggi successivi

Considerazioni sulla sicurezza per l'acceleratore di zona di destinazione di Azure Spring Apps