AWS Germany – Amazon Web Services in Deutschland
AWS-Ressourcen sicher über VPC- und Kontogrenzen hinweg mit PrivateLink, VPC Lattice, EventBridge und Step Functions teilen
von Jeff Barr übersetzt durch Desiree Brunner
An einem gewissen Punkt, sagt mir jeder AWS-Kunde, dass er den Wunsch hat, so schnell wie möglich in die Zukunft zu reisen. Sie möchten ihre Modernisierungsbemühungen vereinfachen, Wachstum vorantreiben und sich an die Cloud anpassen, während sie gleichzeitig die Kosten reduzieren. Diese Kunden verfügen typischerweise über eine große Anzahl von Legacy-Anwendungen, möglicherweise On-Premises, die auf verschiedenen Technologie-Stacks laufen und von unterschiedlichen Teilen der Organisation verwaltet werden. Um die Sache noch herausfordernder zu gestalten, müssen diese Organisationen oft strenge Sicherheits- und Compliance-Anforderungen erfüllen.
Vorbereitung zum Teilen
Sie können jetzt AWS-Ressourcen wie Amazon Elastic Compute Cloud (Amazon EC2)-Instanzen, Amazon Elastic Container Service (Amazon ECS) und Amazon Elastic Kubernetes Service (Amazon EKS)-Container-Dienste sowie Ihre eigenen HTTPS-Dienste über Amazon Virtual Private Cloud (Amazon VPC) und AWS-Konto Begrenzungen hinweg teilen. Diese Ressourcen können sie zum Aufbau ereignisgesteuerter Apps über Amazon EventBridge und zur Orchestrierung von Workflows mit AWS Step Functions verwenden. Ihre bestehenden Workloads können sie aktualisieren und Ihre modernen Cloud-nativen Apps mit On-Premises-Legacy-Systemen verbinden, wobei die gesamte Kommunikation über private Endpunkte und Netzwerke geleitet wird.
Diese neuen Funktionen bauen auf Amazon VPC Lattice und AWS PrivateLink auf und bieten Ihnen viele neue Möglichkeiten, sowie einige coole neue Wege zur Integration und Orchestrierung über all Ihre Technologie-Stacks hinweg, um Ihr Netzwerk zu gestalten und zu kontrollieren. Sie können beispielsweise hybride ereignisgesteuerte Architekturen aufbauen, die Ihre bestehenden On-Premises-Anwendungen verwenden.
Heutzutage nutzen einige Kunden AWS Lambda-Funktionen oder Amazon Simple Queue Service (Amazon SQS)-Warteschlangen, um Daten in VPCs zu übertragen. Dieses “undifferentiated heavy lifting” kann nun durch eine einfachere und effizientere Lösung ersetzt werden.
Wenn man all dies zusammenbringt, erhält man eine Reihe von Diensten, die Ihnen helfen, Ihre Modernisierungsbemühungen zu beschleunigen und die Integration zwischen Ihren Anwendungen zu vereinfachen, unabhängig davon, wo sie sich befinden. EventBridge und Step Functions arbeiten Hand in Hand mit PrivateLink und VPC Lattice, um die Integration von öffentlichen und privaten HTTPS-basierten Anwendungen in Ihre ereignisgesteuerten Architekturen und Workflows zu ermöglichen.
Hier sind die wesentlichen Begriffe und Konzepte:
“Resource Owner VPC” (in Deutsch: Ressourcen-Besitzer VPC)– Ein VPC, das zu teilende Ressourcen enthält. Der Besitzer dieses VPC erstellt ein “Resource Gateway” mit einer oder mehreren zugehörigen “Resource Configurations” (in Deutsch: Ressourcenkonfiguration) und verwendet dann AWS Resource Access Manager (RAM), um die “Resource Configuration” mit dem “Resource Consumer” (in Deutsch: Ressourcenkonsument) zu teilen, wie z.B. einem anderen AWS-Konto oder einem Entwickler, der ereignisgesteuerte Architekturen und Workflows mit EventBridge und Step Functions erstellt. Lassen Sie uns den “Resource Owner” als die Person (vielleicht Sie) in Ihrer Organisation definieren, die für die Pflege und Wartung dieses VPC verantwortlich ist.
“Resource Gateway” – Bietet einen Eingangspunkt zu einem VPC, damit Clients auf Ressourcen im “Resource Owner VPC” zugreifen können, wie durch die mit dem Gateway verbundenen “Resource Configurations” angezeigt. Ein “Resource Gateway” kann mehrere Ressourcen verfügbar machen.
“Resource” – Dies kann ein HTTPS-Endpunkt, eine Datenbank, ein Datenbank-Cluster, eine EC2-Instanz, ein “Application Load Balancer” vor mehreren EC2-Instanzen, ein über AWS Cloud Map auffindbarer ECS-Dienst, ein Amazon Elastic Kubernetes Service (Amazon EKS)-Dienst hinter einem “Network Load Balancer”, ein Legacy-Dienst, der im “Resource Owner VPC” läuft, oder On-Premises über AWS Site-to-Site VPN oder AWS Direct Connect sein.
“Resource Configuration” – Definiert eine Reihe von Ressourcen, auf die über ein bestimmtes “Resource Gateway” zugegriffen werden kann. Die Ressourcen können über IP-Adresse, DNS-Name oder (für AWS-Ressourcen) einen Amazon Ressourcen Name (ARN) referenziert werden.
“Resource Consumer” – Die Person in Ihrer Organisation, die für den Aufbau von Anwendungen verantwortlich ist, die sich mit Diensten verbinden und diese nutzen, die von Ressourcen in einem “Resource Owner VPC” bereitgestellt werden.
Ressourcen teilen
Sie können all diese Leistung auf viele verschiedene Arten nutzen; ich werde mich in diesem Beitrag auf eine konzentrieren.
Zunächst werde ich die Rolle des “Resource Owner” übernehmen. Ich klicke in der VPC Konsole auf “Resource gateways”, sehe, dass ich kein Gateway habe, und klicke auf “Create resource gateway” (in Deutsch: Resource Gateway erstellen), um zu beginnen:
Ich weise einen Namen zu (main-rg) und einen IP-Adresstyp, wähle dann das VPC und die privaten Subnetze aus, in denen das Gateway präsent sein wird (dies ist eine einmalige Auswahl, die nicht geändert werden kann ohne ein neues Resource Gateway zu erstellen). Ich wähle bis zu fünf Sicherheitsgruppen aus, um den eingehenden Datenverkehr zu kontrollieren:
Ich scrolle nach unten, weise gewünschte “Tags” (in Deutsch: Schlüssel-Wert-Paar) zu und klicke auf “Create resource gateway”, um fortzufahren:
Mein neues Gateway ist innerhalb von Sekunden aktiv; ich klicke auf “Create resource configuration” (in Deutsch: Ressourcenkonfiguration erstellen), um fortzufahren:
Jetzt muss ich meine erste Ressourcenkonfiguration erstellen. Nehmen wir an, ich habe einen HTTPS-Dienst, der auf einer EC2-Instanz in einem privaten Subnetz in meinem “Resource Owner VPC” läuft. Ich weise dem Dienst einen DNS-Namen zu und verwende einen Amazon Route 53 Alias-Eintrag, der die IP-Adresse der Instanz zurückgibt:
In diesem Beispiel verwende ich eine öffentliche gehostete Zone. Wir arbeiten bereits an der Unterstützung für private gehostete Zonen.
Nachdem DNS eingerichtet ist, klicke ich auf “Create resource configuration”, um fortzufahren. Ich gebe einen Namen ein (rc-service1), wähle “Resource” als Typ und wähle das “Resource Gateway” aus, das ich zuvor erstellt habe:
Ich scrolle nach unten und definiere meine EC2-Instanz als Ressource, gebe den DNS-Namen ein und richte die Freigabe für die Ports 80 und 443 ein:
Jetzt mache ich einen kurzen Abstecher und springe zur RAM Konsole, um eine “Resource Share” (in Deutsch: Ressourcenfreigabe) zu erstellen, damit andere AWS-Konten auf die Ressourcen zugreifen können (dies ist optional und nur für kontoübergreifende Szenarien relevant). Ich könnte für jeden Dienst eine solche Ressourcenfreigabe erstellen, aber in den meisten Fällen würde ich nur eine Freigabe erstellen und sie verwenden, um eine Sammlung verwandter Dienste zu bündeln. Das werde ich tun und sie “shared-services” nennen:
Nach meinem kurzen Abstecher aktualisiere ich die Liste der Ressourcenfreigaben, wähle die von mir erstellte aus und klicke auf “Create resource configuration”:
Die Ressourcenkonfiguration ist innerhalb von Sekunden bereit.
Zusammenfassung und Planungszeit
Bevor wir weitermachen, lassen Sie uns eine kurze Zusammenfassung machen und einige Pläne schmieden. Hier ist, was ich (in der Rolle des Ressourcenanbieters) bisher habe:
- MainVPC – Mein “Resource Owner VPC”.
- main-rg – Ein “Resource Gateway” in “MainVPC”.
- rc-service1 – Die Ressourcenkonfiguration für “main-rg”.
- service1 – Ein HTTPS-Dienst, der auf einer EC2-Instanz in einem privaten Subnetz von “MainVPC” mit einer festen IP-Adresse gehostet wird.
Okay, was kommt als Nächstes?
Teilen – Dies ist der erste und offensichtlichste Anwendungsfall. Ich kann AWS Resource Access Manager (RAM) verwenden, um die Ressourcenkonfiguration mit einem anderen AWS-Konten zu teilen und von einem anderen VPC aus auf den Dienst zuzugreifen. Auf der anderen Seite (als Ressourcenkonsument) führe ich ein paar schnelle Schritte durch, um eine Verbindung zu dem Dienst herzustellen, der mit mir geteilt wurde:
- Dienstnetzwerk – Ich kann ein Dienstnetzwerk erstellen, die Ressourcenkonfiguration zum Dienstnetzwerk hinzufügen und einen VPC-Endpunkt in einem VPC erstellen, um eine Verbindung zum Dienstnetzwerk herzustellen.
- Endpunkt – Ich kann einen VPC-Endpunkt in einem VPC erstellen und über den Endpunkt auf die freigegebene Ressource zugreifen.
Modernisieren – Ich kann meine veraltete Lambda- oder SQS-Integration entfernen, um “undifferentiated heavy lifting” loszuwerden.
Aufbauen – Ich kann EventBridge und Step Functions verwenden, um ereignisgesteuerte Architekturen aufzubauen und Anwendungen zu orchestrieren. Ich werde diese Option wählen!
Zugriff auf private Ressourcen mit EventBridge und Step Functions
EventBridge und Step Functions machen es bereits einfach, auf öffentliche HTTPS-Endpunkte wie die von SaaS-Anbietern wie Slack, Salesforce und Adobe zuzugreifen. Mit dem heutigen Launch ist der Konsum privater HTTPS-Dienste genauso einfach.
Als Ressourcenkonsument erstelle ich einfach eine EventBridge-Verbindung, verweise auf eine Ressourcenkonfiguration, die mit mir geteilt wurde, und rufe den Dienst von meiner ereignisgesteuerten Anwendung aus auf. Alles, was ich bereits weiß, gilt weiterhin, und ich habe jetzt die neu gewonnene Fähigkeit, auf private Dienste zuzugreifen.
Um die EventBridge-Verbindung zu erstellen, öffne ich die EventBridge Konsole und klicke im Menü Integration auf “Connections” (in Deutsch: Verbindungen):
Ich überprüfe meine bestehenden Verbindungen (bisher keine) und klicke dann auf “Create connection” (in Deutsch: Verbindung erstellen), um fortzufahren:
Ich gebe einen Namen (MyService1) und eine Beschreibung für meine Verbindung ein, wähle “Private” als “API type” und wähle die Ressourcenkonfiguration aus, die ich zuvor erstellt habe:
Beim Scrollen nach unten muss ich die Autorisierung für den Dienst konfigurieren, mit dem ich mich verbinde. Ich wähle “Custom configuration” (in Deutsch: Benutzerdefinierte Konfiguration) und “Basic authorization” (in Deutsch: Basisautorisierung) aus und gebe den “Username” und das “Password” für meinen Dienst ein. Ich füge auch “Action=Forecast” (in Deutsch: Aktion = Vorhersage) zur Abfragezeichenfolge hinzu (wie Sie sehen können, gibt es viele Optionen für die Autorisierung) und klicke auf “Create” (in Deutsch: Erstellen):
Die Verbindung wird innerhalb von Minuten erstellt und ist einsatzbereit. Dann verwende ich sie in meinen Step Functions-Workflows, indem ich die HTTP-Aufgabe [EN] nutze, die Verbindung auswähle, die URL meines API-Endpunkts eingebe und eine HTTP-Methode auswähle:
Und das ist alles: Ihre Step Functions-Workflows können jetzt private Ressourcen nutzen!
Ich kann diese Verbindung auch als EventBridge-API-Ziel in “Event Buses” und “Event Pipes” verwenden.
Wissenswerte Punkte
Hier ein paar Dinge, die Sie über diese coolen neuen Funktionen wissen sollten:
Preise – Die bestehende Preise für Step Functions, EventBridge, PrivateLink und VPC Lattice gelten einschließlich der Gebühr pro GB für den Datentransfer in das VPC.
Regionen – Sie können “Resource Gateways” und “Resource Configurations” in 21 AWS-Regionen erstellen und nutzen: US East (Ohio, N. Virginia), US West (N. California, Oregon), Afrika (Kapstadt), Asien-Pazifik (Hongkong, Mumbai, Osaka, Seoul, Singapur, Sydney, Tokio), Kanada (Central), Europa (Frankfurt, Irland, London, Mailand, Paris, Stockholm), Naher Osten (Bahrain) und Südamerika (São Paulo).
In Arbeit – Wie ich bereits erwähnt habe, arbeiten wir bereits an der Unterstützung für private gehostete Zonen. Wir planen auch, den Zugriff auf andere Arten von AWS-Ressourcen über EventBridge und Step Functions zu unterstützen.
Jeff Barr ist Chief Evangelist für AWS. Er startete diesen Blog im Jahr 2004 und schreibt seitdem nahezu ununterbrochen Beiträge. |