Networking per l'implementazione di applicazioni rivolte a internet: architetture di riferimento
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Last reviewed 2025-01-13 UTC
Questo documento fa parte di una serie che descrive le architetture di rete e sicurezza per le aziende che eseguono la migrazione dei carichi di lavoro del data center aGoogle Cloud.
Google offre una serie di prodotti e funzionalità che consentono di proteggere
e scalare le tue applicazioni più critiche rivolte a internet. La Figura 1 mostra un'architettura che utilizza i servizi Google Cloud per eseguire il deployment di un'applicazione web con più livelli.
Figura 1. Tipica applicazione web multilivello di cui è stato eseguito il deployment su Google Cloud.
Architettura lift and shift
Man mano che le applicazioni rivolte a internet vengono spostate nel cloud, devono essere scalabili
e devono disporre di controlli di sicurezza e visibilità equivalenti a quelli
dell'ambiente on-premise. Puoi fornire questi controlli utilizzando
le appliance virtuali di rete disponibili nel marketplace.
Figura 2. Applicazione di cui è stato eseguito il deployment con un bilanciatore del carico esterno basato su appliance.
Questi appliance virtuali forniscono funzionalità e visibilità coerenti con i tuoi ambienti on-premise. Quando utilizzi un'appliance virtuale di rete, esegui il deployment dell'immagine dell'appliance software utilizzando gruppi di istanze gestite con scalabilità automatica. Spetta a te monitorare e gestire l'integrità delle istanze VM che eseguono l'appliance, nonché gestire gli aggiornamenti software dell'appliance.
Dopo aver eseguito lo spostamento iniziale, potresti voler
eseguire la transizione dalle appliance virtuali di rete autogestite ai servizi gestiti.
Google Cloud offre una serie di servizi gestiti per
distribuire applicazioni su larga scala.
La Figura 2 mostra un'appliance virtuale di rete configurata come frontend
di un'applicazione di livello web. Per un elenco di soluzioni dell'ecosistema di partner, consulta la pagina
Google Cloud Marketplace
nella console Google Cloud .
Architettura dei servizi ibridi
Google Cloud offre i seguenti approcci per gestire
le applicazioni rivolte a internet su larga scala:
Utilizza la rete globale di server dei nomi DNS Anycast di Google che forniscono
alta disponibilità e bassa latenza per convertire le richieste di nomi di dominio
in indirizzi IP.
Utilizza la flotta globale di bilanciatori del carico delle applicazioni esterni di Google per instradare il traffico a un'applicazione ospitata all'interno di Google Cloud, ospitata on-premise o ospitata su un altro cloud pubblico. Questi bilanciatori del carico vengono scalati automaticamente in base al traffico e garantiscono che ogni richiesta venga indirizzata a un backend integro. Configurando i
gruppi di endpoint di rete con connettività ibrida,
puoi sfruttare i vantaggi delle funzionalità di networking del bilanciatore del carico delle applicazioni esterno
per i servizi in esecuzione sulla tua infrastruttura esistente
al di fuori di Google Cloud. Le reti on-premise o le altre reti cloud pubbliche sono connesse privatamente alla tua rete Google Cloud tramite un tunnel VPN o Cloud Interconnect.
Utilizza altri servizi di rete perimetrale come Cloud CDN per distribuire i contenuti, Google Cloud Armor per proteggerli e Identity-Aware Proxy (IAP) per controllare l'accesso ai tuoi servizi.
La Figura 3 mostra la connettività ibrida che utilizza il bilanciatore del carico delle applicazioni esterno.
Figura 3. Configurazione della connettività ibrida utilizzando il bilanciatore del carico delle applicazioni esterno e
i servizi di rete perimetrale.
La Figura 4 mostra un'opzione di connettività diversa: l'utilizzo di gruppi di endpoint di rete con connettività ibrida.
Figura 4. Configurazione del bilanciatore del carico delle applicazioni esterno utilizzando gruppi di endpoint di rete con connettività ibrida.
Utilizza un bilanciatore del carico delle applicazioni (HTTP/HTTPS) per instradare le richieste in base ai loro attributi, ad esempio l'URI (Uniform Resource Identifier) HTTP.
Utilizza un bilanciatore del carico di rete proxy per implementare l'offload TLS, il proxy TCP o il supporto per il bilanciamento del carico esterno verso backend in più regioni.
Utilizza un bilanciatore del carico di rete passthrough per preservare gli indirizzi IP di origine dei client, evitare l'overhead dei proxy e supportare protocolli aggiuntivi come UDP, ESP e ICMP.
Proteggi il tuo servizio con
Cloud Armor.
Questo prodotto è un servizio di difesa DDoS perimetrale e di sicurezza WAF
disponibile per tutti i servizi a cui si accede tramite i bilanciatori del carico.
Utilizza
certificati SSL gestiti da Google.
Puoi riutilizzare i certificati e le chiavi private che utilizzi già per altri
prodottiGoogle Cloud . In questo modo non è più necessario gestire certificati separati.
Abilita la memorizzazione nella cache nella tua applicazione per sfruttare l'impronta di distribuzione delle applicazioni distribuita di Cloud CDN.
Utilizza Cloud IDS per rilevare le minacce nel traffico nord-sud, come
mostrato nella figura 6.
Figura 6. Configurazione di Cloud IDS per eseguire il mirroring e l'ispezione
di tutto il traffico internet e interno.
Architettura distribuita Zero Trust
Puoi espandere l'architettura distribuita Zero Trust per includere la distribuzione delle applicazioni da internet. In questo modello, il bilanciatore del carico delle applicazioni esterno Google fornisce
il bilanciamento del carico globale tra i cluster GKE che hanno
mesh Cloud Service Mesh in cluster distinti. Per questo scenario, adotti un
modello di ingresso composito. Il bilanciatore del carico di primo livello fornisce la selezione del cluster, mentre un gateway in entrata gestito da Cloud Service Mesh fornisce il bilanciamento del carico e la sicurezza in entrata specifici del cluster. Un esempio di questo
traffico in entrata multicluster è
l'architettura di riferimento di Cymbal Bank
descritta nel progetto dell'applicazione aziendale. Per saperne di più sull'ingresso perimetrale di Cloud Service Mesh, vedi Da dispositivi periferici a mesh: esposizione delle applicazioni di mesh di servizi mediante GKE Ingress.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-01-13 UTC."],[[["\u003cp\u003eThis document focuses on networking architectures for delivering internet-facing applications in Google Cloud, covering migration from on-premises environments.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Cloud offers managed services like external Application Load Balancers, Cloud CDN, and Cloud Armor to scale and secure internet-facing applications, replacing self-managed network virtual appliances.\u003c/p\u003e\n"],["\u003cp\u003eHybrid services architectures can be implemented, allowing the use of Google's global network for DNS and load balancing while connecting to services hosted on-premises or in other clouds.\u003c/p\u003e\n"],["\u003cp\u003eThe document covers various approaches to load balancing, including HTTP/HTTPS Application Load Balancers, proxy Network Load Balancers, and passthrough Network Load Balancers, each with specific use cases.\u003c/p\u003e\n"],["\u003cp\u003eZero Trust Distributed Architecture is discussed, detailing how external Application Load Balancers can integrate with Cloud Service Mesh for secure, multi-cluster application delivery.\u003c/p\u003e\n"]]],[],null,["# Networking for internet-facing application delivery: Reference architectures\n\nThis document is part of a series that describes networking and security\narchitectures for enterprises that are migrating data center workloads to\nGoogle Cloud.\n\nThe series consists of the following documents:\n\n- [Designing networks for migrating enterprise workloads: Architectural approaches](/architecture/network-architecture)\n- [Networking for secure intra-cloud access: Reference architectures](/architecture/network-secure-intra-cloud-access)\n- Networking for internet-facing application delivery: Reference architectures (this document)\n- [Networking for hybrid and multi-cloud workloads: Reference architectures](/architecture/network-hybrid-multicloud)\n\nGoogle offers a set of products and capabilities that help secure\nand scale your most critical internet-facing applications. Figure 1 shows an\narchitecture that uses Google Cloud services to deploy a web application\nwith multiple tiers.\n\n**Figure 1**. Typical multi-tier web application deployed on Google Cloud.\n| **Note:** You need to consider limitations of using Application Load Balancers. For more information, see the [Limitations](/load-balancing/docs/https#limitations) section in the \"External Application Load Balancer overview\" documentation.\n\nLift-and-shift architecture\n---------------------------\n\nAs internet-facing applications move to the cloud, they must be able to scale,\nand they must have security controls and visibility that are equivalent to those\ncontrols in the on-premises environment. You can provide these controls by using\nnetwork virtual appliances that are available in the marketplace.\n\n**Figure 2**. Application deployed with an appliance-based external load\nbalancer.\n\nThese virtual appliances provide functionality and visibility that is\nconsistent with your on-premises environments. When you use a network virtual\nappliance, you deploy the software appliance image by using autoscaled managed\ninstance groups. It's up to you to monitor and manage the health of the VM\ninstances that run the appliance, and you also maintain software updates for the\nappliance.\n\nAfter you perform your initial shift, you might want to\ntransition from self-managed network virtual appliances to managed services.\nGoogle Cloud offers a number of managed services to\ndeliver applications at scale.\n\nFigure 2 shows a network virtual appliance configured as the frontend\nof a web tier application. For a list of partner ecosystem solutions, see the\n[Google Cloud Marketplace](https://console.cloud.google.com/marketplace/browse?filter=category:networking)\npage in the Google Cloud console.\n\nHybrid services architecture\n----------------------------\n\nGoogle Cloud offers the following approaches to manage\ninternet-facing applications at scale:\n\n- Use Google's global network of anycast DNS name servers that provide high availability and low latency to translate requests for domain names into IP addresses.\n- Use Google's global fleet of external Application Load Balancers to route traffic to an application that's hosted inside Google Cloud, hosted on-premises, or hosted on another public cloud. These load balancers scale automatically with your traffic and ensure that each request is directed to a healthy backend. By setting up [hybrid connectivity network endpoint groups](/load-balancing/docs/negs/hybrid-neg-concepts), you can bring the benefits of external Application Load Balancer networking capabilities to services that are running on your existing infrastructure outside of Google Cloud. The on-premises network or the other public cloud networks are privately connected to your Google Cloud network through a VPN tunnel or through Cloud Interconnect.\n- Use other network edge services such as Cloud CDN to distribute\n content, Google Cloud Armor to protect your content, and\n Identity-Aware Proxy (IAP) to control access to your services.\n\n Figure 3 shows hybrid connectivity that uses external Application Load Balancer.\n\n **Figure 3**. Hybrid connectivity configuration using external Application Load Balancer and\n network edge services.\n\n Figure 4 shows a different connectivity option---using hybrid\n connectivity network endpoint groups.\n\n **Figure 4**. External Application Load Balancer configuration using hybrid\n connectivity network endpoint groups.\n- Use a Application Load Balancer (HTTP/HTTPS) to route requests based on\n their attributes, such as the HTTP uniform resource identifier (URI).\n Use a proxy Network Load Balancer to implement TLS offload, TCP proxy, or support for\n external load balancing to backends in multiple [regions](/docs/geography-and-regions#regions_and_zones).\n Use a passthrough Network Load Balancer to preserve client source IP addresses, avoid the\n overhead of proxies, and to support additional protocols like UDP, ESP, and\n ICMP.\n\n- Protect your service with\n [Cloud Armor](/armor).\n This product is an edge DDoS defense and WAF security product that's\n available to all services that are accessed through load balancers.\n\n- Use\n [Google-managed SSL certificates](/load-balancing/docs/ssl-certificates/google-managed-certs).\n You can reuse certificates and private keys that you already use for other\n Google Cloud products. This eliminates the need to manage separate\n certificates.\n\n- Enable caching on your application to take advantage of the distributed\n application delivery footprint of Cloud CDN.\n\n- Use [Cloud Next Generation Firewall](/vpc/docs/firewalls) to inspect and filter traffic in your VPC networks.\n\n- Use Cloud IDS to detect threats in north-south traffic, as\n shown in figure 6.\n\n **Figure 6**. Cloud IDS configuration to mirror and inspect\n all internet and internal traffic.\n\nZero Trust Distributed Architecture\n-----------------------------------\n\nYou can expand Zero Trust Distributed Architecture to include application\ndelivery from the internet. In this model, the Google external Application Load Balancer provides\nglobal load balancing across GKE clusters that have\nCloud Service Mesh meshes in distinct clusters. For this scenario, you adopt a\ncomposite ingress model. The first-tier load balancer provides cluster\nselection, and then a Cloud Service Mesh-managed ingress gateway provides\ncluster-specific load balancing and ingress security. An example of this\nmulti-cluster ingress is the\n[Cymbal Bank reference architecture](/architecture/blueprints/enterprise-application-blueprint/cymbal-bank)\nas described in the enterprise application blueprint. For more information about\nCloud Service Mesh edge ingress, see\n[From edge to mesh: Exposing service mesh applications through GKE Ingress](/architecture/exposing-service-mesh-apps-through-gke-ingress).\n\nFigure 7 shows a configuration in which a external Application Load Balancer directs\ntraffic from\nthe [internet to the service mesh](/architecture/exposing-service-mesh-apps-through-gke-ingress)\nthrough an\n[ingress gateway](/architecture/exposing-service-mesh-apps-through-gke-ingress).\nThe gateway is a dedicated proxy in the service mesh.\n\n**Figure 7**. Application delivery in a zero-trust microservices environment.\n\nWhat's next\n-----------\n\n- [Networking for secure intra-cloud access: Reference architectures](/architecture/network-secure-intra-cloud-access).\n- [Networking for hybrid and multi-cloud workloads: Reference architectures](/architecture/network-hybrid-multicloud).\n- [Use Cloud Armor, load balancing, and Cloud CDN to deploy programmable global front ends](/architecture/deploy-programmable-gfe-cloud-armor-lb-cdn)\n- [Migration to Google Cloud](/solutions/migration-to-gcp-getting-started) can help you to plan, design, and implement the process of migrating your workloads to Google Cloud.\n- [Landing zone design in Google Cloud](/architecture/landing-zones) has guidance for creating a landing zone network.\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture)."]]