Freigeben über

Netzwerk für SaaS-Workloads in Azure

Ihr Netzwerk bietet das Backbone für den Zugriff von Kunden auf Ihre Software as a Service (SaaS)-Anwendung und ermöglicht die Kommunikation zwischen den Komponenten Ihrer Lösung. Die Art und Weise, wie Sie Ihr Netzwerk entwerfen, wirkt sich direkt auf die Sicherheit, Vorgänge, Kosten, Leistung und Zuverlässigkeit Ihrer Lösung aus. Ein strukturierter Ansatz für Ihre Netzwerkstrategie wird noch wichtiger, wenn Ihre Cloudumgebung wächst.

Festlegen einer Netzwerkbereitstellungsstrategie und -topologie

SaaS-Lösungen haben einzigartige Netzwerkanforderungen. Wenn Sie mehr Kunden integrieren und ihre Nutzung steigt, ändern sich die Netzwerkanforderungen. Der Umgang mit Wachstum kann aufgrund begrenzter Ressourcen, wie zum Beispiel IP-Adressbereichen, schwierig sein. Ihr Netzwerkdesign wirkt sich auf die Sicherheit und Kundenisolation aus. Planen Sie Ihre Netzwerkstrategie, um Wachstum zu verwalten, die Sicherheit zu verbessern und die betriebstechnische Komplexität zu reduzieren.

Überlegungen zum Entwurf

  • Planen Sie Ihre Netzwerkbereitstellungsstrategie basierend auf Ihrem Mandantenmodell. Entscheiden Sie, ob Sie Netzwerkressourcen für Kunden freigeben, Ressourcen einem einzelnen Kunden oder einer Kombination dieser Optionen zuordnen möchten. Diese Auswahl wirkt sich auf die Funktionalität, Sicherheit und Kundenisolation Ihrer Anwendung aus.

    Es ist üblich, Netzwerkressourcen wie virtuelle Netzwerke und Azure Front Door-Profile für mehrere Kunden gemeinsam zu nutzen. Dieser Ansatz reduziert Kosten und Betriebsaufwand. Außerdem wird die Konnektivität vereinfacht. Sie können die Ressourcen eines Kunden ganz einfach mit freigegebenen Ressourcen verbinden, z. B. freigegebene Speicherkonten oder eine Kontrollebene.

    Es kann jedoch erforderlich sein, dedizierte Netzwerkressourcen für jeden Kunden zu erstellen, um hohe Sicherheit und Compliance herzustellen. Um beispielsweise ein hohes Maß an Netzwerksegmentierung zwischen Kunden zu unterstützen, können Sie virtuelle Netzwerke als Grenze verwenden. Dedizierte Ressourcen können erforderlich sein, wenn die Anzahl der Netzwerkressourcen für alle Kunden die Kapazität eines einzelnen freigegebenen Netzwerks überschreitet.

    Planen Sie die Anzahl der Netzwerkressourcen, die jeder Kunde benötigt, indem Sie sofortige und zukünftige Anforderungen berücksichtigen. Kundenanforderungen und Azure-Ressourcenbeschränkungen können bestimmte Ergebnisse erzwingen. Verschiedene Ressourcen erfordern möglicherweise unterschiedliche Bereitstellungsstrategien, z. B. die Verwendung separater Netzwerke für virtuelle Netzwerk-Peering mit virtuellen Azure-Netzwerken im Besitz von Kunden.

    Weitere Informationen zum Freigeben von Ressourcen in einer SaaS-Lösung finden Sie in der Ressourcenorganisation für SaaS-Workloads.

  • Grundlegendes zu Netzwerktopologien. Netzwerktopologien sind in der Regel in drei Kategorien unterteilt:

    • Flaches Netzwerk: Ein einzelnes, isoliertes Netzwerk mit Subnetzen für die Segmentierung. Verwenden Sie eine Flachnetzwerktopologie, wenn Sie über eine einzelne Mehrinstanzenanwendung mit einem einfachen Netzwerklayout verfügen. Flache Netzwerke können Ressourcenlimits erreichen und mehr Netzwerke benötigen, während Sie skalieren, wodurch Mehraufwand und Kosten erhöht werden. Wenn Sie beabsichtigen, mehrere Anwendungen zu hosten oder dedizierte Bereitstellungsstempel innerhalb desselben virtuellen Netzwerks zu verwenden, benötigen Sie möglicherweise ein komplexes Netzwerklayout.

    • Hub und Spoke: Ein zentrales Hub-Netzwerk, das sich mit isolierten Spoke-Netzwerken verbindet. Verwenden Sie eine Hub-and-Spoke-Topologie für hohe Skalierbarkeit und Kundenisolation, da jeder Kunde oder jede Anwendung über eine eigene Speichen verfügt und nur mit dem Hub kommuniziert. Sie können bei Bedarf schnell weitere Speichen bereitstellen, damit alle Speichen Ressourcen im Hub verwenden können. Die transitive oder gesprochene Kommunikation über den Hub ist standardmäßig deaktiviert, was dazu beiträgt, die Kundenisolation in SaaS-Lösungen aufrechtzuerhalten.

    • Kein Netzwerk: Verwenden Sie eine No-Network-Topologie für Azure-Plattform as a Service (PaaS)-Lösungen, bei denen Sie komplexe Workloads hosten können, ohne virtuelle Netzwerke bereitzustellen. Beispielsweise ermöglicht Azure-App Service die direkte Integration mit anderen PaaS-Diensten über das Azure-Backbone-Netzwerk. Obwohl dieser Ansatz die Verwaltung vereinfacht, beschränkt sie die Flexibilität bei der Bereitstellung von Sicherheitskontrollen und der Möglichkeit, die Leistung zu optimieren. Dieser Ansatz kann gut für cloudeigene Anwendungen funktionieren. Da sich Ihre Lösung weiterentwickelt, erwarten Sie, dass Sie im Laufe der Zeit zu einer Hub-and-Spoke-Topologie wechseln.

      Kompromiss: Komplexität und Sicherheit. Das Starten ohne eine definierte Netzwerkgrenze kann die Betriebliche Belastung für die Verwaltung von Netzwerkkomponenten wie Sicherheitsgruppen, IP-Adressraum und Firewalls verringern. Ein Netzwerkperimeter ist jedoch für die meisten Workloads unerlässlich. Verlassen Sie sich in Abwesenheit von Netzwerksicherheitskontrollen auf eine starke Identitäts- und Zugriffsverwaltung, um Ihre Workload vor böswilligem Datenverkehr zu schützen.

  • Verstehen, wie sich Architekturen mit mehreren Regionen auf Netzwerktopologien auswirken. In einer Mehrregionenarchitektur, die virtuelle Netzwerke verwendet, werden die meisten Netzwerkressourcen in jeder Region separat bereitgestellt, da Firewalls, Gateways für virtuelle Netzwerke und Netzwerksicherheitsgruppen nicht zwischen Regionen gemeinsam genutzt werden können.

Entwurfsempfehlungen

Empfehlung Vorteil
Entscheiden Sie, welche Netzwerkkomponenten gemeinsam genutzt werden und welche Komponenten dem Kunden zugeordnet sind.

Teilen Sie Ressourcen, die pro Instanz in Rechnung gestellt werden, z. B. Azure Firewall, Azure Bastion und Azure Front Door.		 Wägen Sie die Unterstützung zwischen Ihren Sicherheits- und Isolationsanforderungen, während Sie Ihre Kosten und Ihre Betriebskosten reduzieren.
Beginnen Sie mit einer flachen Topologie oder einem Ansatz ohne Netzwerk.

Überprüfen Sie Ihre Sicherheitsanforderungen immer zuerst, da diese Ansätze eine eingeschränkte Isolierung und Netzwerkkontrollen bieten.		 Sie können die Komplexität und die Kosten Ihrer Lösung reduzieren, indem Sie einfachere Netzwerktopologien verwenden.
Erwägen Sie Hub-and-Spoke-Topologien für komplexe Anforderungen oder wenn Sie dedizierte virtuelle Netzwerke für jeden Kunden bereitstellen. Verwenden Sie den Hub, um gemeinsam genutzte Netzwerkressourcen in Kundennetzwerken zu hosten. Sie können Ihre Kosteneffizienz einfacher skalieren und verbessern, indem Sie Ressourcen über Ihr Hubnetzwerk freigeben.

Entwerfen eines hochsicheren Netzwerkperimeters

Ihr Netzwerkperimeter richtet die Sicherheitsgrenze zwischen Ihrer Anwendung und anderen Netzwerken ein, einschließlich des Internets. Durch die Dokumentation Ihres Netzwerkperimeters können Sie zwischen den folgenden Arten von Datenverkehrsflüssen unterscheiden:

  • Eingehender Datenverkehr, der aus einer externen Quelle in das Netzwerk eingeht.
  • Interner Datenverkehr, der zwischen Komponenten innerhalb Ihres Netzwerks verläuft.
  • Ausgehender Datenverkehr, der das Netzwerk verlässt.

Jeder Fluss umfasst unterschiedliche Risiken und Kontrollen. Zum Beispiel benötigen Sie mehrere Sicherheitsmaßnahmen, um eingehenden Datenverkehr zu prüfen und zu verarbeiten.

Wichtig

Als allgemeine bewährte Methode sollten Sie immer einen Zero Trust-Ansatz befolgen. Stellen Sie sicher, dass der gesamte Datenverkehr kontrolliert und überprüft wird, einschließlich des internen Datenverkehrs.

Ihre Kunden haben möglicherweise auch bestimmte Complianceanforderungen, die Ihre Architektur beeinflussen. Wenn sie beispielsweise SOC 2-Compliance benötigen, müssen sie verschiedene Netzwerksteuerelemente implementieren, darunter eine Firewall, eine Webanwendungsfirewall (WAF) und Netzwerksicherheitsgruppen, um die Sicherheitsanforderungen zu erfüllen. Auch wenn Sie diese Erweiterbarkeitsfaktoren nicht sofort einhalten müssen, sollten Sie diese Erweiterungsfaktoren berücksichtigen, wenn Sie Ihre Architektur entwerfen.

Weitere Informationen finden Sie unter SE:06 Empfehlungen für Netzwerk und Konnektivität.

Überlegungen zum Entwurf

  • Schützen und Verwalten des Eingehenden Datenverkehrs. Überprüfen Sie diesen Datenverkehr auf eingehende Bedrohungen.

    Firewalls ermöglichen es Ihnen, böswillige IP-Adressen zu blockieren und erweiterte Analysen durchzuführen, um vor Angriffsversuchen zu schützen. Firewalls können jedoch kostspielig sein. Bewerten Sie Ihre Sicherheitsanforderungen, um festzustellen, ob eine Firewall erforderlich ist.

    Webanwendungen sind anfällig für häufige Angriffe, z. B. SQL-Einfügung, websiteübergreifendes Skripting und andere OWASP top 10 Sicherheitsanfälligkeiten. Das Azure-Webanwendungsfirewall-Feature schützt vor diesen Angriffen und lässt sich in Azure-Anwendungsgateway und Azure Front Door integrieren. Überprüfen Sie die Ebenen für diese Dienste, um zu verstehen, welche WAF-Funktionen in welchen Produkten enthalten sind.

    Verteilte Denial-of-Service -Angriffe (DDoS) sind ein Risiko für Internetanwendungen. Azure bietet ein grundlegendes Schutzniveau ohne Kosten. Azure DDoS Protection bietet erweiterten Schutz, indem Ihre Datenverkehrsmuster erlernt und der Schutz entsprechend angepasst wird, aber diese Funktionen sind mit Kosten verbunden. Wenn Sie Azure Front Door verwenden, nutzen Sie die integrierten DDoS-Funktionen.

    Über die Sicherheit hinaus können Sie den Eingehenden Datenverkehr auch bearbeiten, um die Leistung Ihrer Anwendung durch Zwischenspeichern und Lastenausgleich zu verbessern.

    Erwägen Sie die Verwendung eines Reverseproxydiensts wie Azure Front Door für die globale HTTP- und HTTPS-Datenverkehrsverwaltung. Alternativ können Sie anwendungsgateway oder andere Azure-Dienste für die Steuerung des eingehenden Datenverkehrs verwenden. Weitere Informationen finden Sie unter Optionen für den Lastenausgleich.

  • Schützen Des internen Datenverkehrs. Stellen Sie sicher, dass der Datenverkehr zwischen Ihrer Anwendung und ihren Komponenten sicher ist, um böswilligen Zugriff zu verhindern. Schützen Sie diese Ressourcen und verbessern Sie die Leistung, indem Sie internen Datenverkehr anstelle des Routings über das Internet verwenden. Azure Private Link wird häufig verwendet, um über eine interne IP-Adresse in Ihrem Netzwerk eine Verbindung mit Azure-Ressourcen herzustellen. Bei einigen Ressourcentypen können Dienstendpunkte eine kostengünstigere Alternative sein.

    Wenn Sie die öffentliche Internetverbindung für Ihre Ressourcen aktivieren, verstehen Sie, wie Sie den Datenverkehr mithilfe von IP-Adressen und Anwendungsidentitäten einschränken, z. B. verwaltete Identitäten.

  • Schützen des Ausgangsverkehrs. Prüfen Sie in einigen Lösungen ausgehenden Datenverkehr, um Datenexfiltration zu verhindern, insbesondere für behördliche Compliance- und Unternehmenskunden. Verwenden Sie Firewalls, um den ausgehenden Datenverkehr zu steuern und zu überprüfen, indem Verbindungen zu nicht autorisierten Zielen blockiert werden.

  • Planen Sie, wie Sie ausgehende Verbindungen und SNAT skalieren. Die SNAT-Portausschöpfung (Source Network Address Translation, Quellnetzwerkadressenübersetzung) kann sich auf multitenantische Anwendungen auswirken. Diese Anwendungen benötigen häufig unterschiedliche Netzwerkverbindungen für jeden Mandanten, und das Teilen von Ressourcen zwischen Kunden erhöht das Risiko der SNAT-Erschöpfung, wenn Ihre Kundenbasis wächst.

    Sie können die SNAT-Erschöpfung verringern, indem Sie Azure NAT-Gateway, Firewalls wie Azure Firewall oder eine Kombination der beiden Ansätze verwenden.

Entwurfsempfehlungen

Empfehlung Vorteil
Verwalten Sie einen Katalog der Netzwerkendpunkte, die für das Internet verfügbar gemacht werden. Erfassen Sie Details wie die IP-Adresse (wenn sie statisch ist), Hostname, Ports, Protokolle, die die Endpunkte verwenden, und die Begründung für Verbindungen.

Dokumentieren Sie, wie Sie jeden Endpunkt schützen möchten.		 Diese Liste bildet die Grundlage Ihrer Perimeterdefinition, sodass Sie explizite Entscheidungen darüber treffen können, wie Sie den Datenverkehr über Ihre Lösung verwalten.
Verstehen sie die Azure-Dienstfunktionen, um den Zugriff einzuschränken und den Schutz zu verbessern.

Beispielsweise benötigen Sie weitere Steuerelemente, um Kunden Speicherkontoendpunkte zur Verfügung zu stellen. Zu diesen Steuerelementen gehören freigegebene Zugriffssignaturen, Speicherkontofirewalls und separate Speicherkonten für die interne und externe Verwendung.		 Sie können Steuerelemente auswählen, die Ihren Sicherheits-, Kosten- und Leistungsanforderungen entsprechen.
Verwenden Sie für HTTP- und HTTPS-basierte Anwendungen einen Reverseproxy, z. B. Azure Front Door oder Anwendungsgateway. Reverseproxys bieten eine breite Palette von Funktionen für Leistungsverbesserungen, Resilienz und Sicherheit. Sie tragen auch dazu bei, die Betriebskomplexität zu reduzieren.
Inspizieren Sie eingehenden Datenverkehr mithilfe einer WAF.

Vermeiden Sie, webbasierte Ressourcen wie App Service oder Azure Kubernetes Service (AKS) direkt im Internet verfügbar zu machen.		 Sie können Ihre Webanwendungen effektiver vor häufigen Bedrohungen schützen und die Gesamtbelastung Ihrer Lösung reduzieren.
Schützen Sie Ihre Anwendung vor DDoS-Angriffen.

Verwenden Sie Azure Front Door oder DDoS Protection abhängig von den Protokollen, die Ihre öffentlichen Endpunkte verwenden.		 Schützen Sie Ihre Lösung vor einem gängigen Angriffstyp.
Wenn für Ihre Anwendung die Konnektivität in großem Umfang erforderlich ist, verwenden Sie ein NAT-Gateway oder eine Firewall, um zusätzliche SNAT-Ports bereitzustellen. Sie können höhere Skalierungsebenen unterstützen.

Netzwerkübergreifende Verbindungen

Für einige Szenarien müssen Sie möglicherweise eine Verbindung mit Ressourcen herstellen, die sich außerhalb von Azure befinden. Zu diesen Ressourcen gehören Daten innerhalb des privaten Netzwerks oder der Ressourcen eines Kunden in einem anderen Cloudanbieter in einem Multicloud-Setup. Diese Anforderungen können Ihr Netzwerkdesign erschweren, da sie verschiedene Ansätze erfordern, um netzwerkübergreifende Konnektivität basierend auf Ihren spezifischen Anforderungen zu implementieren.

Überlegungen zum Entwurf

  • Identifizieren Sie die Endpunkte, mit denen die Anwendung eine Verbindung herstellen muss. Die Anwendung muss möglicherweise mit anderen Diensten kommunizieren, z. B. Speicherdienste und Datenbanken. Dokumentieren Sie den Besitzer, den Standort und den Verbindungstyp. Anschließend können Sie die entsprechende Methode auswählen, um eine Verbindung mit diesen Endpunkten herzustellen. In der folgenden Tabelle werden allgemeine Ansätze beschrieben.

    Ressourcenspeicherort Besitzer Zu berücksichtigende Konnektivitätsoptionen
    Azure Kreditor
    • Privater Endpunkt (über Microsoft Entra-Mandanten hinweg)
    • Virtuelles Netzwerk-Peering (über Microsoft Entra-Mandanten hinweg)
    • Dienstendpunkt (über Microsoft Entra-Mandanten hinweg)
    Anderer Cloudanbieter ISV oder Kunde
    • Site-to-Site-VPN-Verbindung
    • Azure ExpressRoute
    • Internet
    Lokal ISV oder Kunde
    • Site-to-Site-VPN-Verbindung
    • ExpressRoute
    • Internet

    • Private Link und private Endpunkte bieten sichere Konnektivität zu verschiedenen Azure-Ressourcen, einschließlich interner Lastenausgleichsgeräte für virtuelle Computer. Sie ermöglichen den privaten Zugriff auf Ihre SaaS-Lösung für Kunden, kommen aber mit Kostenüberlegungen.

      Kompromiss: Sicherheit und Kosten. Mit privatem Link können Sie sicherstellen, dass Ihr Datenverkehr in Ihrem privaten Netzwerk verbleibt. Wir empfehlen Private Link für die Netzwerkkonnektivität zwischen Microsoft Entra-Mandanten. Jeder private Endpunkt verursacht jedoch Kosten, die je nach Ihren Sicherheitsanforderungen addiert werden können. Dienstendpunkte können eine kostengünstige Alternative sein. Sie behalten den Datenverkehr im Microsoft-Backbone-Netzwerk bei und bieten gleichzeitig eine private Konnektivität.

    • Dienstendpunkte leiten den Datenverkehr über das Microsoft-Backbone-Netzwerk an PaaS-Ressourcen weiter, das die Dienst-zu-Dienst-Kommunikation sichert. Dienstendpunkte können für Anwendungen mit hoher Bandbreite kosteneffizient sein, sie müssen jedoch Zugriffssteuerungslisten für Sicherheit konfigurieren und verwalten. Die Unterstützung für Dienstendpunkte in Microsoft Entra-Mandanten variiert je nach Azure-Dienst. Überprüfen Sie die Produktdokumentation für jeden dienst, den Sie verwenden.

    • Virtuelles Netzwerk-Peering verbindet zwei virtuelle Netzwerke und ermöglicht Ressourcen in einem Netzwerk den Zugriff auf IP-Adressen in der anderen. Es erleichtert die Konnektivität mit privaten Ressourcen in einem virtuellen Azure-Netzwerk. Sie können den Zugriff mithilfe von Netzwerksicherheitsgruppen verwalten, das Erzwingen der Isolation kann jedoch eine Herausforderung darstellen. Daher ist es wichtig, Ihre Netzwerktopologie basierend auf bestimmten Kundenanforderungen zu planen.

    • Virtuelle private Netzwerke (VPNs) erstellen einen sicheren Tunnel über das Internet zwischen zwei Netzwerken, einschließlich über Cloudanbieter und lokale Standorte. Standort-zu-Standort-VPNs verwenden Netzwerkgeräte in jedem Netzwerk für die Konfiguration. Sie bieten eine kostengünstige Konnektivitätsoption, erfordern jedoch eine Einrichtung und garantieren keinen vorhersehbaren Durchsatz.

    • ExpressRoute bietet eine dedizierte, leistungsstarke, private Verbindung zwischen Azure und anderen Cloudanbietern oder lokalen Netzwerken. Dadurch wird eine vorhersehbare Leistung gewährleistet und der Internetdatenverkehr umgangen, es ist jedoch mit höheren Kosten verbunden und erfordert eine komplexere Konfiguration.

  • Planen Sie basierend auf dem Ziel. Möglicherweise müssen Sie eine Verbindung mit Ressourcen in verschiedenen Microsoft Entra-Mandanten herstellen, insbesondere, wenn sich die Zielressource im Azure-Abonnement eines Kunden befindet. Erwägen Sie die Verwendung privater Endpunkte, eines Standort-zu-Standort-VPN oder gepaarter virtueller Netzwerke. Weitere Informationen finden Sie unter Erstellen eines virtuellen Netzwerk-Peerings zwischen verschiedenen Abonnements.

    Um eine Verbindung mit Ressourcen herzustellen, die von einem anderen Cloudanbieter gehostet werden, ist es üblich, öffentliche Internetverbindung, ein Standort-zu-Standort-VPN oder ExpressRoute zu verwenden. Weitere Informationen finden Sie unter Konnektivität mit anderen Cloudanbietern

  • Verstehen der Auswirkungen der Konnektivität auf Ihre Netzwerktopologie. Ein virtuelles Azure-Netzwerk kann nur über ein virtuelles Netzwerkgateway verfügen, das über ein Standort-zu-Standort-VPN oder ExpressRoute eine Verbindung mit mehreren Standorten herstellen kann. Es gibt jedoch Grenzwerte für die Anzahl der Verbindungen, die Sie über ein Gateway herstellen können, und das Isolieren des Kundendatenverkehrs kann eine Herausforderung darstellen. Planen Sie für mehrere Verbindungen mit verschiedenen Standorten die Netzwerktopologie entsprechend, indem Sie möglicherweise ein separates virtuelles Netzwerk für jeden Kunden bereitstellen.

  • Verstehen Sie die Auswirkungen auf die IP-Adressplanung. Bei einigen Verbindungsansätzen wird automatisch die Netzwerkadressenübersetzung (NETWORK Address Translation, NAT) bereitgestellt, wodurch Sie die Probleme vermeiden können, die sich überlappende IP-Adressen verursachen. Virtuelle Netzwerk-Peering und ExpressRoute führen jedoch keine NAT aus. Wenn Sie diese Methoden verwenden, planen Sie Ihre Netzwerkressourcen und IP-Adresszuordnungen sorgfältig, um überlappende IP-Adressbereiche zu vermeiden und ein zukünftiges Wachstum sicherzustellen. Die IP-Adressplanung kann komplex sein, insbesondere wenn Sie eine Verbindung mit externen Quellen wie Kunden herstellen, daher sollten Sie potenzielle Konflikte mit ihren IP-Adressbereichen in Betracht ziehen.

  • Grundlegendes zur Abrechnung des Netzwerkausgangs. Azure berechnet in der Regel ausgehenden Netzwerkdatenverkehr, wenn es das Microsoft-Netzwerk verlässt oder zwischen Azure-Regionen wechselt. Beim Entwerfen von Multi-Region- oder Multicloud-Lösungen ist es wichtig, die Kostenauswirkungen zu verstehen. Architekturentscheidungen, z. B. die Verwendung von Azure Front Door oder ExpressRoute, können sich darauf auswirken, wie Sie für den Netzwerkdatenverkehr in Rechnung gestellt werden.

Entwurfsempfehlungen

Empfehlung Vorteil
Wählen Sie private Netzwerkansätze für die Verbindung zwischen Netzwerken aus, um die Sicherheit zu priorisieren.

Ziehen Sie nur das Routing über das Internet in Betracht, nachdem Sie die zugehörigen Sicherheits- und Leistungsauswirkungen ausgewertet haben.		 Privater Datenverkehr durchläuft einen gesicherten Netzwerkpfad, der dazu beiträgt, viele Arten von Sicherheitsrisiken zu reduzieren.
Wenn Sie eine Verbindung mit Ressourcen herstellen, die die Azure-Umgebungen von Kunden hosten, verwenden Sie private Verknüpfungen, Dienstendpunkte oder virtuelle Netzwerk-Peerings. Sie können den Datenverkehr im Microsoft-Netzwerk beibehalten, wodurch kosten- und betriebstechnische Komplexität im Vergleich zu anderen Ansätzen reduziert werden kann.
Wenn Sie eine Verbindung zwischen Cloudanbietern oder lokalen Netzwerken herstellen, verwenden Sie Standort-zu-Standort-VPNs oder ExpressRoute. Diese Technologien bieten sichere Verbindungen zwischen Anbietern.

Bereitstellen in den Umgebungen Ihrer Kunden

Ihr Geschäftsmodell erfordert möglicherweise, dass Sie die Anwendung oder die zugehörigen Komponenten in der Azure-Umgebung eines Kunden hosten. Der Kunde verwaltet sein eigenes Azure-Abonnement und zahlt direkt die Kosten für ressourcen, die zum Ausführen der Anwendung erforderlich sind. Als Lösungsanbieter sind Sie für die Verwaltung der Lösung verantwortlich, einschließlich der anfänglichen Bereitstellung, anwenden der Konfiguration und Bereitstellen von Updates für die Anwendung.

In solchen Situationen bringen Kunden häufig ihr eigenes Netzwerk mit und stellen Ihre Anwendung in einem von ihnen definierten Netzwerkbereich bereit. Azure Managed Applications bieten Funktionen, um diesen Prozess zu erleichtern. Weitere Informationen finden Sie unter Verwenden eines vorhandenen virtuellen Netzwerks mit azure Managed Applications.

Überlegungen zum Entwurf

  • Bereiten Sie sich auf verschiedene IP-Adressbereiche und Konflikte vor. Wenn Kunden virtuelle Netzwerke bereitstellen und verwalten, sind sie für die Behandlung von Netzwerkkonflikten und der Skalierung verantwortlich. Sie sollten jedoch unterschiedliche Szenarien für die Kundennutzung antizipieren. Planen Sie Bereitstellungen in Umgebungen mit minimalem IP-Adressraum, indem Sie IP-Adressen effizient verwenden. Vermeiden Sie hartcodierende IP-Adressbereiche, um Überschneidungen mit Kundenbereichen zu verhindern.

    Alternativ können Sie ein dediziertes virtuelles Netzwerk für Ihre Lösung bereitstellen. Sie können Private Link- oder virtuelles Netzwerk-Peering verwenden, um Kunden die Verbindung mit den Ressourcen herzustellen. Weitere Informationen finden Sie unter Netzwerkübergreifende Konnektivität. Wenn Sie Eintritts- und Austrittspunkte definiert haben, ziehen Sie NAT in Betracht, um Probleme mit IP-Adressüberschneidungen zu beseitigen.

  • Bereitstellen des Netzwerkzugriffs für Verwaltungszwecke. Überprüfen Sie die Ressourcen, die Sie in Kundenumgebungen bereitstellen, und planen Sie, wie Sie darauf zugreifen können, um sie zu überwachen, zu verwalten oder neu zu konfigurieren. Wenn Sie Ressourcen mit privaten IP-Adressen in einer kundeneigenen Umgebung bereitstellen, stellen Sie sicher, dass Sie über einen Netzwerkpfad verfügen, um sie aus Ihrem eigenen Netzwerk zu erreichen. Überlegen Sie, wie Sie Sowohl Anwendungs- als auch Ressourcenänderungen vereinfachen, z. B. eine neue Version der Anwendung übertragen oder eine Azure-Ressourcenkonfiguration aktualisieren.

    In einigen Lösungen können Sie Funktionen verwenden, die von Azure Managed Applications bereitgestellt werden, z. B. Just-in-Time-Zugriff und Bereitstellung von Updates für Anwendungen. Wenn Sie mehr Kontrolle benötigen, können Sie einen Endpunkt im Netzwerk des Kunden hosten, mit dem Ihre Steuerebene eine Verbindung herstellen kann. Dieser Ansatz bietet Ihnen Zugriff auf Ihre Ressourcen. Diese Methode erfordert mehr Azure-Ressourcen und -Entwicklung, um Sicherheits-, Betriebs- und Leistungsanforderungen zu erfüllen. Ein Beispiel für die Implementierung dieses Ansatzes finden Sie im Beispiel zum Aktualisieren von Azure Managed Applications.

Entwurfsempfehlungen

Empfehlung Vorteil
Verwenden Sie azure Managed Applications, um vom Kunden bereitgestellte Ressourcen bereitzustellen und zu verwalten. Azure Managed Applications bieten eine Reihe von Funktionen, mit denen Sie Ressourcen innerhalb des Azure-Abonnements eines Kunden bereitstellen und verwalten können.
Minimieren Sie die Anzahl der IP-Adressen, die Sie innerhalb des virtuellen Netzwerkraums des Kunden nutzen. Kunden haben häufig eingeschränkte IP-Adressverfügbarkeit. Indem Sie Ihren Speicherbedarf minimieren und Ihre Skalierung von der IP-Adressnutzung entkoppeln, können Sie die Anzahl der Kunden erweitern, die Ihre Lösung verwenden und ein höheres Wachstumsniveau ermöglichen.
Planen Sie, wie Sie Netzwerkzugriff auf ressourcen in Kundenumgebungen erhalten, damit Sie Überwachungs-, Ressourcenkonfigurationsänderungen und Anwendungsupdates durchführen können. Sie können die von Ihnen verwalteten Ressourcen direkt konfigurieren.
Entscheiden Sie, ob Sie ein dediziertes virtuelles Netzwerk bereitstellen oder in das vorhandene virtuelle Netzwerk eines Kunden integrieren möchten. Indem Sie entscheiden, welches virtuelle Netzwerk sie vorab verwenden soll, können Sie sicherstellen, dass Sie die Anforderungen Ihrer Kunden an Isolation, Sicherheit und Integration in ihre anderen Systeme erfüllen können.
Standardmäßig den öffentlichen Zugriff auf Azure-Ressourcen deaktivieren. ** Wenn möglich, wählen Sie privaten Ingress. Sie reduzieren den Umfang der Netzwerkressourcen, die Sie und Ihre Kunden schützen müssen.

Zusätzliche Ressourcen

Multitenancy ist eine Kern-Geschäftsmethodik für das Entwerfen von SaaS-Workloads. Diese Artikel enthalten weitere Informationen zum Netzwerkdesign:

Nächster Schritt

Erfahren Sie mehr über die Überlegungen zur Datenplattform zur Datenintegrität und -leistung für SaaS-Workloads in Azure.

Entwurfsbereich: Daten für SaaS-Workloads in Azure

  • Last updated on