AWS Transfer Family – häufig gestellte Fragen

Ja. Sie können Ihren Transfer-Family-Server so konfigurieren, dass er Ihren Benutzern benutzerdefinierte Banner wie Organisationsrichtlinien oder Geschäftsbedingungen anzeigt. Sie können auch benutzerdefinierte MOTDs (Message of the Day) für Benutzer anzeigen, die sich erfolgreich authentifiziert haben. Weitere Informationen finden Sie in der Dokumentation.

Ja. Der Service stellt standardmäßig einen Domainnamen für den Zugriff auf Ihren Endpunkt bereit. Wenn Sie bereits einen Domainnamen haben, können Sie Amazon Route 53 oder einen beliebigen DNS-Service verwenden, um den Datenverkehr Ihrer Benutzer von Ihrer registrierten Domain zum Serverendpunkt in AWS umzuleiten. Lesen Sie in der Dokumentation nach, wie AWS Transfer Family Amazon Route 53 für benutzerdefinierte Domainnamen verwendet (gilt nur für internetorientierte Endpunkte).

Ja. Wenn Sie einen Server erstellen oder einen bestehenden aktualisieren, haben Sie die Möglichkeit, festzulegen, ob der Endpunkt über das öffentliche Internet zugänglich sein oder innerhalb Ihrer VPC gehostet werden soll. Die Verwendung eines gehosteten VPC-Endpunkts für Ihren Server macht ihn nur für Clients innerhalb derselben VPC, anderer VPCs, die Sie angeben, oder in lokalen Umgebungen zugänglich, die Netzwerktechnologien verwenden, welche Ihre VPC erweitern, wie beispielsweise AWS Direct Connect, AWS VPN oder VPC-Peering. Sie können den Zugriff auf Ressourcen in bestimmten Subnetzen innerhalb Ihrer VPC mithilfe von Subnetzzugriffssteuerungslisten (Network Access Control Lists, NACLs) oder Sicherheitsgruppen weiter einschränken. Weitere Informationen finden Sie in der Dokumentation zur Erstellung Ihres Server-Endpunkts innerhalb Ihrer VPC mit AWS PrivateLink.

Nein, wenn Sie FTP aktivieren, können Sie nur die interne Zugriffsoption des VPC-gehosteten Endpunkts verwenden, weil FTP Daten im Klartext überträgt. Wenn der Datenverkehr das öffentliche Netzwerk durchqueren muss, sollten Sie sichere Protokolle wie SFTP oder FTPS verwenden.

Nein. Eine VPC ist zum Hosten von FTP-Serverendpunkten erforderlich. Informationen zum Automatisieren der Erstellung von VPC-Ressourcen zum Hosten des Endpunkts während der Servererstellung finden Sie in der Dokumentation zu CloudFormation-Vorlagen.

Ja. Sie können feste IPs für Ihren Serverendpunkt aktivieren, indem Sie den von der VPC gehosteten Endpunkt für Ihren Server und die Option für die Internetverbindung auswählen. Auf diese Weise können Sie elastische IPs (einschließlich BYO-IPs) direkt an den Endpunkt anfügen, der als IP-Adresse des Endpunkts zugewiesen ist. Weitere Informationen finden Sie im Abschnitt zum Erstellen eines mit dem Internet verbundenen Endpunkts in der Dokumentation Erstellen des Server-Endpunkts in Ihrer VPC.

Ja. Sie haben drei Möglichkeiten, den eingehenden Datenverkehr nach der Quell-IP-Adresse der Benutzer zu beschränken. Wenn Sie Ihren Server-Endpunkt in einer VPC hosten, lesen Sie diesen Blog-Beitrag über die Verwendung von Sicherheitsgruppen, um die Quell-IP-Adresse der Liste zuzulassen, oder verwenden Sie den Service AWS Network Firewall. Wenn Sie einen öffentlichen EndpointType-Transferserver und ein API-Gateway für die Integration Ihres Identitätsmanagementsystems verwenden, können Sie auch AWS WAF nutzen, um den Zugriff nach der Quell-IP-Adresse Ihrer Endbenutzer zuzulassen, zu blockieren oder zu begrenzen.

Ja. Sie können Ihren Server-Endpunkt mit gemeinsam genutzten VPC-Umgebungen bereitstellen, die typischerweise bei der Segmentierung Ihrer AWS-Umgebung mit Tools wie AWS Landing Zone für Sicherheit, Kostenüberwachung und Skalierbarkeit verwendet werden. Lesen Sie diesen Blog-Beitrag über die Verwendung von VPC-gehosteten Endpunkten in gemeinsam genutzten VPC-Umgebungen mit AWS Transfer Family.

Sie können AWS Global Accelerator mit Ihrem Übertragungsserver-Endpunkt verwenden, um den File-Transfer-Durchsatz und die Round-Trip-Zeit zu verbessern. Weitere Informationen finden Sie in diesem Blog-Beitrag.

Ja. Basierend auf Ihren Sicherheits- und Compliance-Anforderungen können Sie eine unserer verfügbaren serviceverwalteten Sicherheitsrichtlinien auswählen, um die kryptografischen Algorithmen zu kontrollieren, die von Ihren Serverendpunkten angekündigt werden. Wenn die Dateiübertragungs-Clients Ihrer Endbenutzer versuchen, eine Verbindung zu Ihrem Server herzustellen, werden nur die in der Richtlinie angegebenen Algorithmen verwendet, um die Verbindung auszuhandeln. Lesen Sie die Dokumentation zu vordefinierten Sicherheitsrichtlinien.

Ja. AWS Transfer Family unterstützt den quantensicheren Austausch öffentlicher Schlüssel für SFTP-Dateiübertragungen. Sie können Ihrem SFTP-Server eine der vordefinierten hybriden PQ-Sicherheitsrichtlinien zuordnen und so einen quantensicheren Schlüsselaustausch mit Clients ermöglichen, die PQ-Verschlüsselungsalgorithmen unterstützen.

Nein. Feste IP-Adressen, die normalerweise für Firewall-Whitelisting-Zwecke verwendet werden, werden derzeit vom Typ PUBLIC-Endpunkt nicht unterstützt. Verwenden Sie VPC-gehostete Endpunkte, um statische IP-Adressen für Ihren Endpunkt zuzuweisen.

Wenn Sie den Endpunkttyp PUBLIC verwenden, müssen Ihre Benutzer die Liste der hier veröffentlichten AWS-IP-Adressbereiche zulassen. Informationen dazu, wie Sie auf dem neuesten Stand hinsichtlich AWS-IP-Adressbereiche bleiben können, finden Sie in der Dokumentation.

Nein. Der Hostschlüssel des Servers, der bei der Erstellung des Servers zugewiesen wird, bleibt unverändert, es sei denn, Sie fügen einen neuen Hostschlüssel hinzu und löschen den ursprünglichen manuell.

Für SFTP-Server-Hostschlüssel werden die Schlüsseltypen RSA, ED25519 und ECDSA unterstützt.

Ja. Sie können einen Hostschlüssel importieren, wenn Sie einen Server erstellen, oder mehrfache Hostschlüssel importieren, wenn Sie einen Server aktualisieren. Weitere Informationen finden Sie in der Dokumentation zur Verwaltung von Hostschlüsseln für Ihren SFTP-fähigen Server.

Ja. Der älteste Hostschlüssel jedes Schlüsseltyps kann zur Überprüfung der Authentizität eines SFTP-Servers verwendet werden. Durch Hinzufügen von RSA-, ED25519- und ECDSA-Hostschlüsseln können 3 separate Hostschlüssel verwendet werden, um Ihren SFTP-Server zu identifizieren.

Der älteste Hostschlüssel jedes Schlüsseltyps wird verwendet, um die Authentizität Ihres SFTP-Servers zu überprüfen.

Ja. Sie können Ihre SFTP-Server-Hostschlüssel jederzeit drehen, indem Sie Hostschlüssel hinzufügen und entfernen. Weitere Informationen finden Sie in der Dokumentation zur Verwaltung von Hostschlüsseln für Ihren SFTP-fähigen Server.

Wenn Sie den FTPS-Zugriff aktivieren, müssen Sie ein Zertifikat von Amazon Certificate Manager (ACM) bereitstellen. Dieses Zertifikat wird von den Clients Ihrer Endbenutzer verwendet, um die Identität Ihres FTPS-Servers zu verifizieren. Informationen finden Sie in den ACM-Dokumentationen zum Anfordern neuer Zertifikate oder Importieren vorhandener Zertifikate in ACM.

Wir unterstützen nur den passiven Modus, der es den Clients Ihrer Endbenutzer ermöglicht, Verbindungen zu Ihrem Server herzustellen. Für den passiven Modus müssen auf der Clientseite weniger Ports geöffnet werden, sodass Ihr Serverendpunkt kompatibler mit Endbenutzern hinter geschützten Firewalls ist.

Wir unterstützen nur den expliziten FTPS-Modus.

Ja. Dateiübertragungen, die eine Firewall oder einen Router durchqueren, werden standardmäßig im erweiterten passiven Verbindungsmodus (EPSV) unterstützt. Wenn Sie einen FTPS/FTP-Client verwenden, der den EPSV-Modus nicht unterstützt, lesen Sie diesen Blog-Beitrag, um Ihren Server im PASV-Modus zu konfigurieren und so die Kompatibilität Ihres Servers mit einer breiten Palette von Clients zu erweitern.

Ja. Zusätzlich zum Standard-Port 22 unterstützt AWS Transfer Family auch den alternativen Port 2222. Standardmäßig ist Port 22 standardmäßig für Ihre SFTP-Server konfiguriert. Um die Sicherheit Ihres Servers zu erhöhen, können Sie den SSH-Verkehr so konfigurieren, dass er Port 22, 2222 oder beides verwendet. Lesen Sie hier unsere Dokumentation.

Sie können Verbindungen zu Remote-Servern entweder mit SSH-Schlüsselpaaren oder mit einem Passwort oder mit beidem authentifizieren, je nach den Anforderungen des Remote-Servers. Speichern Sie Ihren Benutzernamen und Ihren privaten SSH-Schlüssel und/oder Ihr Passwort, um sich bei den Remote-Servern in Ihrem AWS-Secrets-Manager-Konto anzumelden. Weitere Informationen zum Speichern und Verwalten der Authentifizierungs-Anmeldeinformationen Ihres Konnektors finden Sie in der Dokumentation.  

Wir unterstützen RSA- und ECDSA-Hostschlüsselalgorithmen. Weitere Informationen zu den unterstützten Schlüsseltypen finden Sie in der Dokumentation hier.  

Mit SFTP-Konnektoren können Sie Dateien zu oder von Amazon S3 auf entfernte SFTP-Server übertragen.

Ja. Sie können Ihre Amazon-S3-Buckets und SFTP-Connector-Ressourcen in verschiedenen AWS-Konten bereitstellen.

Ja. Sie können einen SFTP-Connector in einem AWS-Konto erstellen und ihn verwenden, um Dateien von einem anderen Konto zu übertragen, indem Sie die entsprechenden Zugriffsberechtigungen in der Ihrem Connector zugewiesenen IAM-Rolle bereitstellen.

Der Konnektor verwendet den Host-Fingerprint, um die Identität des Remote-Servers zu überprüfen. Wenn der vom Remote-Server bereitgestellte Fingerabdruck nicht mit dem in die Connector-Konfiguration hochgeladenen Fingerabdruck übereinstimmt, schlägt die Verbindung fehl und die Fehlerdetails werden in CloudWatch protokolliert. Wie Sie den öffentlichen Teil des SSH-Schlüssels eines Remote-Servers zur Identifizierung hochladen können, erfahren Sie in der Dokumentation zu den SFTP-Konnektoren hier .

Sie können die Konnektivität zum Remote-Server mit der AWS-Managementkonsole oder dem API-/CLI-/CDK-Befehl TestConnection testen. Wir empfehlen Ihnen, die Konnektivität zum Remoteserver zu testen, sobald Sie Ihren Connector erstellt haben, um sicherzustellen, dass er korrekt konfiguriert ist. Stellen Sie sicher, dass die statischen IP-Adressen, die Ihren Connectors zugeordnet sind, bei Bedarf in der Firewall des Remote-Servers zugelassen sind. Weitere Informationen finden Sie in der Dokumentation zu SFTP-Connectors.

Sie können SFTP-Konnektoren verwenden, um Dateien von Amazon S3 an ein Verzeichnis auf einem entfernten SFTP-Server zu senden oder um Dateien aus einem Verzeichnis auf einem entfernten SFTP-Server in Amazon S3 abzurufen. Weitere Informationen zum Initiieren von Dateiübertragungsvorgängen mithilfe der StartFileTransfer-API finden Sie in der Dokumentation zu SFTP-Connectors.

Sie können Ihre Amazon Cloudwatch Logs zum Status Ihrer File Transfers überwachen. Sie können verfolgen, ob die Dateiübertragung abgeschlossen wurde oder fehlgeschlagen ist, zusammen mit zusätzlichen Details wie Vorgang (Senden oder Abrufen), Zeitstempel, Dateipfad und Fehlerbeschreibung (falls vorhanden), um die Datenherkunft aufrechtzuerhalten.

Ja. Sie können Dateiübertragungen mit Amazon EventBridge Scheduler planen. Erstellen Sie mit dem Scheduler von EventBridge einen Zeitplan, der den Anforderungen Ihres Unternehmens entspricht, und geben Sie die StartFileTransfer-API von AWS Transfer Family als universelles Ziel für Ihren Zeitplan an.

Ja. AWS Step Functions lässt sich in verschiedene AWS-Services integrieren, einschließlich AWS Transfer Family, sodass Sie die StartFileTransfer-Aktion des SFTP-Connectors direkt von Ihrem State-Computer aus aufrufen können. Sobald Sie Ihren SFTP-Konnektor mit AWS Transfer Family erstellt haben, nutzen Sie die AWS-SDK-Integrationen von Step Functions, um die StartFileTransfer-API aufzurufen. Weitere Informationen finden Sie in der Dokumentation zu Step Functions.

Ja. Jeder Dateiübertragungsvorgang mit SFTP-Connectors veröffentlicht eine Ereignisbenachrichtigung in Ihrem Standard-Event-Bus in Amazon EventBridge. Sie können SFTP-Connector-Ereignisse abonnieren und sie verwenden, um die ereignisgesteuerte Verarbeitung Ihrer übertragenen Dateien mithilfe von Amazon EventBridge oder einem anderen Workflow-Orchestrierungsservice Ihrer Wahl zu orchestrieren, der in diese Ereignisse integriert ist.

Ja. Ihren Konnektoren sind standardmäßig statische IP-Adressen zugeordnet, die verwendet werden können, um Verbindungen auf der Firewall Ihres Geschäftspartners zuzulassen. Sie können die statischen IP-Adressen, die Ihren Konnektoren zugeordnet sind, ermitteln, indem Sie in der AWS-Transfer-Family-Konsole zur Seite mit den Konnektor-Details navigieren oder den Befehl DescribeConnector API/CLI/CDK verwenden.

Ja. Alle SFTP-Connectors in einer AWS-Kontoregion teilen sich eine Reihe statischer IP-Adressen. Die gemeinsame Nutzung von IP-Adressen zwischen Connectors eines bestimmten Typs reduziert den Umfang der Dokumentation auf der Zulassungsliste sowie die erforderliche Onboarding-Kommunikation mit Ihren externen Partnern.

Nein. Sie müssen die vollständigen Dateipfade angeben, wenn Sie den API-Vorgang StartFileTransfer verwenden, um Dateien über SFTP-Konnektoren zu kopieren. Wenn Ihr Anwendungsfall die Verwendung von Platzhaltern für die Angabe von Dateien für die Übertragung erfordert, teilen Sie uns dies bitte über den AWS-Support oder Ihr AWS-Kontoteam mit.

Nein. Derzeit können SFTP-Konnektoren nur für die Verbindung mit Servern verwendet werden, die einen über das Internet zugänglichen Endpunkt bieten. Wenn Sie eine Verbindung zu Servern herstellen müssen, auf die nur über ein privates Netzwerk zugegriffen werden kann, teilen Sie uns dies bitte über den AWS-Support oder Ihr AWS-Account-Team mit.

Ja. Während der Einrichtung können Sie die Protokolle auswählen, die aktiviert werden sollen, um es Clients zu ermöglichen, eine Verbindung zum Endpunkt herzustellen. Der Server-Hostname, die IP-Adresse und der Identitätsanbieter werden für alle ausgewählten Protokolle gemeinsam genutzt. In ähnlicher Weise können Sie auch die Unterstützung zusätzlicher Protokolle für bestehende Endpunkte der AWS Transfer Family aktivieren, sofern die Endpunktkonfiguration die Anforderungen für alle Protokolle erfüllt, die Sie verwenden möchten.

Wenn Sie FTP verwenden müssen (nur für den Zugriff innerhalb von VPC unterstützt) und auch SFTP, AS2 oder FTPS über das Internet unterstützen müssen, benötigen Sie einen separaten Server-Endpunkt für FTP. Sie können den gleichen Endpunkt für mehrere Protokolle verwenden, wenn Sie den gleichen Endpunkt-Hostnamen und die gleiche IP-Adresse für Clients verwenden möchten, die Verbindungen über mehrere Protokolle herstellen. Wenn Sie die gleichen Anmeldeinformationen für SFTP und FTPS verwenden möchten, können Sie außerdem einen einzelnen Identitätsanbieter für das Authentifizieren von Clients, die Verbindungen über eines dieser Protokolle herstellen, einrichten und verwenden.

Ja. Sie können dem gleichen Benutzer Zugriff über mehrere Protokolle bereitstellen, sofern die protokollspezifischen Anmeldeinformationen in Ihrem Identitätsanbieter eingerichtet wurden. Wenn Sie FTP aktiviert haben, sollten Sie separate Anmeldeinformationen für FTP nutzen. Informationen zum Einrichten separater Anmeldeinformationen für FTP finden Sie in der Dokumentation.

Im Gegensatz zu SFTP und FTPS überträgt FTP die Anmeldeinformationen im Klartext. Wir empfehlen, FTP-Anmeldeinformationen von SFTP oder FTPS zu isolieren, denn wenn FTP-Anmeldeinformationen versehentlich freigegeben oder offengelegt werden, bleiben Ihre Workloads, die SFTP oder FTPS verwenden, sicher.

Ja. Sie können diese Open-Source-Lösung bereitstellen, mit der Sie eine browserbasierte Schnittstelle über die Endpunkte Ihrer AWS Transfer Family SFTP bereitstellen können.

Der Service unterstützt drei Identitätsanbieter-Optionen: Serviceverwaltet, bei der Sie Benutzeridentitäten innerhalb des Services speichern, Microsoft Active Directory und benutzerdefinierte Optionen, bei denen Sie einen Identitätsanbieter Ihrer Wahl integrieren können. Die Authentifizierung mithilfe des verwalteten Services wird für Serverendpunkte unterstützt, die ausschließlich für SFTP aktiviert sind.

Sie können die serviceverwaltete Authentifizierung verwenden, um Ihre SFTP-Benutzer mit SSH-Schlüsseln zu authentifizieren.

Sie können bis zu 10 SSH-Schlüssel pro Benutzer hochladen. RSA-, ED25519- und ECDSA-Schlüssel werden unterstützt.

Ja. Weitere Informationen zum Einrichten der Schlüsselrotation für Ihre SFTP-Benutzer finden Sie in der Dokumentation.

Bei der Erstellung Ihres Servers wählen Sie ein Verzeichnis in AWS Managed Microsoft AD, Ihre On-Premises-Umgebung oder selbst verwaltetes AD in Amazon EC2 als Ihren Identitätsanbieter aus. Anschließend müssen Sie die AD-Gruppen, die Sie für den Zugriff aktivieren möchten, mit einem Security Identifier (SID) angeben. Sobald Sie Ihre AD-Gruppe mit Zugriffskontrollinformationen wie IAM-Rolle, Scope-Down-Richtlinie (nur S3), POSIX-Profil (nur EFS), Home-Verzeichnis-Speicherort und logischen Verzeichniszuordnungen verknüpft haben, können die Mitglieder der Gruppe ihre AD-Anmeldeinformationen zur Authentifizierung und Übertragung von Dateien über die aktivierten Protokolle (SFTP, FTPS, FTP) verwenden. 

Wenn Sie Ihre Benutzer einrichten, geben Sie eine Abgrenzungsrichtlinie an, die zur Laufzeit auf der Grundlage der Benutzerinformationen, wie z. B. dem Benutzernamen, ausgewertet wird. Sie können für alle Benutzer dieselbe Scope-Down-Richtlinie verwenden, um den Zugriff auf eindeutige Präfixe in Ihrem Bucket basierend auf ihrem Benutzernamen zu ermöglichen. Zusätzlich kann ein Benutzername auch dazu verwendet werden, logische Verzeichniszuordnungen auszuwerten, indem eine standardisierte Vorlage bereitgestellt wird, wie der Inhalt Ihres S3-Buckets oder EFS-Dateisystems für den Benutzer sichtbar gemacht wird. Weitere Informationen finden Sie in der Dokumentation zur Gewährung des Zugriffs auf AD-Gruppen.

Ja. Sie können Microsoft AD verwenden, um Benutzer für den Zugriff über SFTP, FTPS und FTP zu authentifizieren.

Ja. Sie können den Dateiübertragungszugriff für einzelne AD-Gruppen widerrufen. Nach dem Widerruf können die Mitglieder der AD-Gruppen keine Dateien mehr mit ihren AD-Anmeldeinformationen übertragen.

Im benutzerdefinierten Modus („BYO“ -Authentifizierung) können Sie einen vorhandenen Identitätsanbieter nutzen, um Ihre Endbenutzer für alle Protokolltypen (SFTP, FTPS und FTP) zu verwalten und so eine einfache und nahtlose Migration Ihrer Benutzer zu ermöglichen. Berechtigungsnachweise können in Ihrem Unternehmensverzeichnis oder in einem internen Identitätsdatenspeicher gespeichert werden, und Sie können sie für die Authentifizierung von Endbenutzern integrieren. Beispiele für Identitätsprovider sind Okta, Microsoft AzureAD oder jeder kundenspezifische Identitätsprovider, den Sie als Teil eines allgemeinen Bereitstellungsportals verwenden.

Um Ihren Identitätsanbieter in einen AWS-Transfer-Family-Server zu integrieren, können Sie eine AWS-Lambda-Funktion oder einen Amazon-API-Gateway-Endpunkt verwenden. Benutzen Sie Amazon API Gateway, falls Sie eine RESTful API benötigen, um sich mit Ihrem Identitätsanbieter zu verbinden oder falls Sie AWS WAF für Ihre Ratenbegrenzungs- und Geoblockingfunktionen nutzen möchten. In der Dokumentation erfahren Sie mehr über die Integration von gängigen Identitätsanbietern wie AWS Cognito, Okta und AWS Secrets Manager.

Ja. Die Quell-IP des Clients wird an Ihren Identitätsanbieter weitergegeben, wenn Sie mit AWS Lambda oder API Gateway eine Verbindung zu einem benutzerdefinierten Identitätsanbieter herstellen. Dies ermöglicht es Ihnen, den Zugriff auf der Grundlage der IP-Adressen von Clients zu erlauben, zu verweigern oder einzuschränken, um sicherzustellen, dass der Zugriff auf Ihre Daten nur von IP-Adressen erfolgt, die Sie als vertrauenswürdig eingestuft haben.

Ja. Sie können mehrere Authentifizierungsmethoden erzwingen, um eine zusätzliche Sicherheitsebene zu bieten, wenn auf Ihre Daten über SFTP zugegriffen wird. Ihr SFTP-Server kann so konfiguriert werden, dass sowohl ein Passwort als auch ein SSH-Schlüssel, ein Passwort oder ein SSH-Schlüssel, nur ein Passwort oder nur ein SSH-Schlüssel erforderlich sind. Einzelheiten zur Aktivierung mehrerer Authentifizierungsmethoden mithilfe Ihres Kundenidentitätsanbieters finden Sie in der Dokumentation.

Nein. Das Speichern von Passwörtern zur Authentifizierung innerhalb des Services wird derzeit nicht unterstützt. Wenn Sie eine Passwortauthentifizierung benötigen, verwenden Sie Active Directory, indem Sie ein Verzeichnis in AWS Directory Service auswählen, oder folgen Sie der Architektur, die in diesem Blog zum Aktivieren der Passwortauthentifizierung mit Secrets Manager beschrieben wird.

Nein. Anonyme Benutzer werden derzeit für keines der Protokolle unterstützt.

Nein. Wir unterstützen nur die Einstellung des Zugriffs durch AD-Gruppen.

Nein. Die Unterstützung der AWS Transfer Family für Microsoft AD kann nur für die kennwortbasierte Authentifizierung verwendet werden. Um eine Mischung von Authentifizierungsmodi zu verwenden, verwenden Sie die Lambda-Genehmiger-Option.

Ja. Der Support von AWS Transfer Family für AS2 wurde mit dem offiziellen AS2-Cloud-Zertifizierungssiegel der Drummond Group ausgezeichnet. Die AS2-Funktionen der AWS Transfer Family wurden eingehend auf Sicherheit und Nachrichtenaustauschkompatibilität mit vierzehn anderen AS2-Lösungen von Drittanbietern überprüft. Besuchen Sie unsere Ankündigung, um mehr zu erfahren.

Ihr Handelspartner wird durch seinen AS2 Identifier (AS2 ID) eindeutig identifiziert. Auf ähnliche Weise identifizieren Ihre Handelspartner Ihre Nachrichten anhand Ihrer AS2 ID.

Sie können die bestehende Unterstützung der AWS Transfer Family für Amazon S3, Netzwerk-Features (VPC-Endpunkte, Sicherheitsgruppen und Elastic IPs) und Zugriffskontrollen (AWS IAM) für AS2 nutzen, wie Sie es auch für SFTP, FTPS und FTP tun können. , logische Verzeichnisse, benutzerdefinierte Banner und Amazon EFS als Speicher-Backend werden für AS2 nicht unterstützt.

Die Nichtabstreitbarkeit, die es nur bei AS2 gibt, bestätigt, dass die Nachrichten zwischen zwei Parteien erfolgreich ausgetauscht wurden. Non-Repudiation in AS2 wird mit Message Disposition Notifications (MDN) erreicht. Wenn eine MDN in einer Transaktion angefordert wird, stellt sie sicher, dass der Absender die Nachricht gesendet und der Empfänger sie erfolgreich empfangen hat und dass die vom Absender gesendete Nachricht mit der vom Empfänger empfangenen Nachricht übereinstimmt.

Bei der Übermittlung von Nachrichten gibt es zwei Aspekte – einen vom Absender und einen vom Empfänger. Sobald der Absender festgelegt hat, welche Nachricht er senden möchte, wird die Nachricht signiert (mit dem privaten Schlüssel des Absenders), verschlüsselt (mit dem Zertifikat des Empfängers) und die Integrität der Nachricht wird mithilfe eines Hashes berechnet. Diese signierte und verschlüsselte Nachricht wird über das Kabel an den Empfänger übertragen. Sobald die Nachricht empfangen wurde, wird sie entschlüsselt (mit dem privaten Schlüssel des Empfängers), validiert (mit dem öffentlichen Schlüssel des Absenders), verarbeitet und eine signierte Message Disposition Notifications (MDN), falls angefordert, wird an den Absender zurückgeschickt, um die erfolgreiche Zustellung der Nachricht zu bestätigen. Lesen Sie in der Dokumentation nach, wie AS2 die Nachrichtenübertragung handhabt.

Die Kombination der möglichen Optionen wird vom Standpunkt des Absenders aus gesteuert. Der Absender kann wählen, ob er die Daten nur verschlüsseln oder nur signieren möchte (oder beides), und er kann eine Message Disposition Notifications (MDN) anfordern. Wenn der Absender sich entscheidet, eine MDN anzufordern, kann er eine signierte oder unsignierte MDN anfordern. Es wird erwartet, dass der Empfänger diese Optionen wahrnimmt.

Ja. Der Absender kann wählen, ob er eine MDN anfordert, ob er eine signierte oder unsignierte MDN anfordert und welche Signieralgorithmen für die Signatur der MDN verwendet werden sollen.

Derzeit unterstützen wir sowohl synchrone als auch asynchrone MDN-Antworten. Auf diese Weise können Sie Ihren Handelspartnern nach Erhalt einer AS2-Nachricht entweder mit einem synchronen oder einem asynchronen MDN antworten. Da synchrone MDNs über denselben Verbindungskanal wie die Nachricht gesendet werden, ist dies viel einfacher und daher die empfohlene Option. Wenn Sie mehr Zeit benötigen, um die Nachricht zu verarbeiten, bevor Sie eine MDN senden, sind asynchrone MDNs vorzuziehen. Wenn Sie beim Senden von Nachrichten an Ihre Handelspartner asynchrone MDNs anfordern und empfangen müssen, wenden Sie sich über den AWS Support oder Ihren Account Manager an uns.

AWS Transfer Family extrahiert wichtige AS2-Informationen aus ausgetauschten Payloads und MDNs und speichert sie als JSON-Dateien in Ihrem Amazon S3-Bucket. Sie können diese JSON-Dateien mit S3 Select oder Amazon Athena abfragen oder die Dateien mit Amazon OpenSearch oder Amazon DocumentDB für Analysen indizieren.

Ja. Sobald Sie eine MDN von Ihrem Handelspartner erhalten, validiert der Service die MDN mit Ihrem Zertifikat und speichert die Nachricht in Ihrem Amazon-S3-Bucket. Sie können die Nachricht archivieren, indem Sie die S3-Lifecycle-Richtlinien nutzen.

Sobald Ihre Daten zur Übermittlung bereit sind, müssen Sie die StartFileTransfer-API über den AS2-Konnektor aufrufen, der die AS2-Serverinformationen des Empfängers enthält. Dadurch wird der Service benachrichtigt, die Nachricht an den Server Ihres Handelspartners zu senden. Lesen Sie die Dokumentation über Konnektoren, um Nachrichten über AS2 an Ihren Handelspartner zu senden.

Ja. Wenn Sie das Profil Ihres Handelspartners einrichten, können Sie für jeden von ihnen unterschiedliche Ordner verwenden.

Ja. Sie können die vorhandenen Schlüssel und Zertifikate Ihres Partners importieren und Verlängerungen und Rotationen verwalten. Lesen Sie die Dokumentation zum Importieren von Zertifikaten.

Über die AWS-Transfer-Family-Konsole können Sie ein Dashboard mit Zertifikaten anzeigen, die nach ihrem Ablaufdatum sortiert sind. Darüber hinaus können Sie sich für den Erhalt von Benachrichtigungen vor Ablauf des Zertifikats entscheiden, so dass Sie genügend Zeit haben, das Zertifikat zu wechseln, um eine Unterbrechung des Betriebs zu vermeiden.

Ja. Ihren Konnektoren sind standardmäßig statische IP-Adressen zugeordnet, die verwendet werden können, um Verbindungen auf dem AS2-Server Ihres Handelspartners zuzulassen. Sie können die statischen IP-Adressen, die Ihren Konnektoren zugeordnet sind, ermitteln, indem Sie in der AWS-Transfer-Family-Konsole zur Seite mit den Konnektor-Details navigieren oder den Befehl DescribeConnector API/CLI/CDK verwenden.

Ja. Wir unterstützen die Möglichkeit, mithilfe der Standardauthentifizierung eine Verbindung zum AS2-Server Ihres Handelspartners herzustellen. Weitere Informationen finden Sie in der Dokumentation zur Konfiguration der Standardauthentifizierung in AS2-Connectors.

Ja. Ihre AS2-Connectors verwenden statische IP-Adressen, wenn sie Nachrichten an Remote-AS2-Server senden und asynchrone MDN-Antworten (Message Disposition Notification) zurückgeben. Sie können die mit Ihren Connectors verknüpften statischen IP-Adressen identifizieren, indem Sie in der Managementkonsole von AWS Transfer Family zur Connector- oder Serverdetailseite navigieren oder die API-/CLI-/CDK-Befehle DescribeConnector oder DescribeServer verwenden.

Ja. Ihre AS2-Serverendpunkte unterstützen die Konfiguration von Steuerelementen für IP-Zulassungslisten mithilfe von Sicherheitsgruppen mit Internetzugriff, VPC-gehosteten Endpunkten.

Ja. Ihre asynchronen AS2-MDN-Antworten verwenden statische IP-Adressen. Sie können die statischen IP-Adressen identifizieren, die zum Senden Ihrer asynchronen MDN-Antworten verwendet werden, indem Sie zur Seite mit den Serverdetails in der Managementkonsole der AWS Transfer Family navigieren oder den Befehl DescribeServer API/CLI/CDK verwenden.

Jede empfangene AS2-Nachricht veröffentlicht ein Ereignis in Ihrem Standard-Event-Bus in Amazon EventBridge. Sie können diese Ereignisse abonnieren und sie verwenden, um die ereignisgesteuerte Verarbeitung der empfangenen Nachrichten mithilfe von Amazon EventBridge oder einem anderen Workflow-Orchestrierungsservice zu orchestrieren. Sie können diese Ereignisse beispielsweise verwenden, um eingehende Nachrichten an andere Speicherorte in S3 zu kopieren, den Inhalt von Nachrichten mit einer benutzerdefinierten Lambda-Funktion zu scannen oder Nachrichten anhand ihres Inhalts zu kennzeichnen, sodass sie von Services wie Amazon CloudSearch indexiert und durchsucht werden können.

Ja. Sie können die X12-EDI-Inhalte Ihrer eingehenden AS2-Nachrichten mithilfe von AWS B2B Data Interchange automatisch in gängige Datendarstellungen wie JSON und XML umwandeln. Erstellen Sie dazu eine Amazon-EventBridge-Regel, die dem Ereignismuster des Ereignisses AS2 Payload Receive Completed von AWS Transfer Family entspricht und die die StartTransformerJob-API von AWS B2B Data Interchange als universelles Ziel für die Regel angibt. Durch die Umwandlung der X12-EDI-Inhalte Ihrer eingehenden AS2-Nachrichten mit AWS B2B Data Interchange können Sie die Integration Ihrer EDI-Daten in nachgelagerte Geschäftsanwendungen und -systeme automatisieren und beschleunigen.

Sie können das Senden von AS2-Nachrichten automatisieren, indem Sie sie mit Amazon EventBridge Scheduler planen oder indem Sie sie mithilfe von Amazon-EventBridge-Regeln auslösen. Um automatisierte, zeitbasierte Workflows für den Versand von AS2-Nachrichten zu erstellen, erstellen Sie mit EventBridge Scheduler einen Zeitplan, der den Anforderungen Ihres Unternehmens entspricht, und geben Sie die StartFileTransfer-API von AWS Transfer Family als universelles Ziel für Ihren Zeitplan an. Um automatisierte, ereignisgesteuerte Workflows für das Senden von AS2-Nachrichten zu erstellen, erstellen Sie eine Amazon-EventBridge-Regel, die in EventBridge veröffentlichte Ereignissen abgleicht, und geben Sie die StartFileTransfer-API von AWS Transfer Family als universelles Ziel für Ihre Regel an.

Ja. Jede gesendete AS2-Nachricht und jedes MDN veröffentlicht ein Ereignis in Ihrem Standard-Event-Bus in Amazon EventBridge. Sie können diese Ereignisse abonnieren und sie verwenden, um AS2-Nachrichten und MDN, die erfolgreich an Ihren Handelspartner gesendet wurden, zu löschen oder zu archivieren.

Ja. AWS Transfer Family veröffentlicht Ereignisse in Amazon EventBridge für jede erfolgreiche oder fehlgeschlagene AS2-Nachricht oder jedes MDN, das gesendet und empfangen wurde. Diese Ereignisse werden in Ihrem Standard-Event-Bus in Amazon EventBridge veröffentlicht, wo sie verwendet werden können, um E-Mail-Benachrichtigungen an Sie oder Ihre Partner mithilfe von Services wie Amazon SNS auszulösen.

Nein. Derzeit werden verwaltete Workflows für Ihre AS2-Endpunkte nicht unterstützt. Wir empfehlen, die in Amazon EventBridge veröffentlichten Ereignisbenachrichtigungen von Transfer Family zu verwenden, um die Verarbeitung Ihrer AS2-Nachrichten zu orchestrieren. Weitere Informationen finden Sie im Abschnitt „Automatisieren der Dateiverarbeitung“.

Nein. Die AWS Transfer Family bietet derzeit keine Unterstützung für AS3 oder AS4.

Sie haben zwei Möglichkeiten: 1) Die AWS Transfer Family veröffentlicht Ereignisbenachrichtigungen für Dateiübertragungen in Amazon EventBridge für Dateien, die über SFTP, AS2, FTPS und FTP übertragen werden, und Sie können diese Ereignisse nutzen, um die Verarbeitung Ihrer Dateien mit einem beliebigen Service auszulösen, der sich in EventBridge-Ereignisse integrieren lässt. 2) Die AWS Transfer Family bietet verwaltete Workflows, die es Ihnen erleichtern, die Verarbeitung von Dateien, die über SFTP-, FTPS- und FTP-Server-Endpunkte hochgeladen wurden, automatisch nach dem Upload auszuführen, indem vorgefertigte Schritte zur Dateiverarbeitung verwendet werden. Wenn Sie Ihrem Serverendpunkt einen verwalteten Workflow zuordnen, werden alle über diesen Endpunkt hochgeladenen Dateien mit denselben Workflow-Schritten verarbeitet.

AWS Transfer Family veröffentlicht Ereignisbenachrichtigungen in Amazon EventBridge, wenn jeder Dateiübertragungsvorgang erfolgreich oder nicht erfolgreich abgeschlossen wurde, sowohl für Server- als auch für Connector-Ressourcen. Weitere Informationen zu Transfer-Family-Ereignissen, die auf Amazon EventBridge veröffentlicht wurden, finden Sie in der Dokumentation. 

Die von der AWS Transfer Family verwalteten Workflows bieten ein vorgefertigtes Framework, mit dem Sie eine lineare Abfolge von Schritten für die Verarbeitung von Dateien erstellen, ausführen und überwachen können, die über SFTP-, FTPS- und FTP-Serverendpunkte hochgeladen wurden. Mit diesem Feature können Sie Zeit sparen, indem Sie vordefinierte Schritte zur Ausführung gängiger Dateiverarbeitungsaufgaben wie Kopieren, Markieren und Entschlüsseln von Dateien ausführen. Sie können die Dateiverarbeitung auch mithilfe einer Lambda-Funktion für Aufgaben wie das Scannen von Dateien auf personenbezogene Daten, Viren/Malware oder andere Fehler wie falsches Dateiformat oder falscher Dateityp anpassen, sodass Sie Anomalien schnell erkennen und Ihre Compliance-Anforderungen erfüllen können. Wenn Sie Ihrem Serverendpunkt einen verwalteten Workflow zuordnen, werden alle über diesen Endpunkt hochgeladenen Dateien mit denselben Workflow-Schritten verarbeitet.

Wenn Sie Dateien verarbeiten müssen, die Sie mit Ihren Geschäftspartnern austauschen, müssen Sie eine Infrastruktur einrichten, um benutzerdefinierten Code auszuführen, kontinuierlich auf Laufzeitfehler und Anomalien zu überwachen und sicherzustellen, dass alle Änderungen und Transformationen an den Daten geprüft und protokolliert werden. Darüber hinaus müssen Sie technische und geschäftliche Fehlerszenarien berücksichtigen und gleichzeitig sicherstellen, dass die Ausfallsicherungsmodi ordnungsgemäß ausgelöst werden. Wenn Sie Anforderungen an die Rückverfolgbarkeit stellen, müssen Sie die Herkunft der Daten auf dem Weg durch die verschiedenen Komponenten Ihres Systems verfolgen. Die Pflege separater Komponenten eines Dateiverarbeitungs-Workflows kostet Sie Zeit, die Ihnen dann bei der Konzentration auf die entscheidende Arbeit fehlt, die Sie für Ihr Unternehmen leisten könnten. Verwaltete Workflows beseitigen die Komplexität der Verwaltung mehrerer Aufgaben und bieten eine standardisierte Lösung für die Dateiverarbeitung, die im gesamten Unternehmen repliziert werden kann, mit integrierter Ausnahmebehandlung und Rückverfolgbarkeit der Dateien für jeden Schritt, damit Sie Ihre geschäftlichen und rechtlichen Anforderungen erfüllen können.

Verwaltete Workflows ermöglichen Ihnen die einfache Vorverarbeitung von Daten, bevor sie von Ihren Downstream-Anwendungen verwendet werden, indem Sie eine lineare Abfolge von Dateiverarbeitungsaufgaben für alle auf Ihre Serverendpunkte hochgeladenen Dateien ausführen, z. B. das Verschieben hochgeladener Dateien in benutzerspezifische Ordner, das Entschlüsseln von Dateien mithilfe von PGP-Schlüsseln, Malware-Scannen und Tagging. Sie können Workflows mithilfe von Infrastructure as Code (IaC) bereitstellen und so gängige Aufgaben der Dateiverarbeitung, die mehrere Geschäftsbereiche in Ihrem Unternehmen betreffen, nach dem Hochladen schnell replizieren und standardisieren. Sie können eine granulare Kontrolle haben, indem Sie Ihrem Serverendpunkt einen verwalteten Workflow zuordnen, der nur bei vollständig hochgeladenen Dateien ausgelöst wird, und indem Sie einen separaten verwalteten Workflow zuordnen, der nur für teilweise hochgeladene Dateien ausgelöst wird, um unvollständige Uploads zu verarbeiten. Workflows bieten auch eine integrierte Ausnahmebehandlung, mit der Sie im Falle von Fehlern oder Ausnahmen bei der Workflow-Ausführung problemlos auf Ergebnisse der Dateiverarbeitung reagieren können, sodass Sie Ihre geschäftlichen und technischen SLAs einhalten können. Jeder Dateiverarbeitungsschritt in Ihrem Workflow erzeugt außerdem detaillierte Protokolle, die überprüft werden können, um die Datenherkunft nachzuverfolgen.

Die Serverendpunkte und Connectors der AWS Transfer Family veröffentlichen automatisch Ereignisbenachrichtigungen in Amazon EventBridge, wenn ein Dateiübertragungsvorgang abgeschlossen ist, zusammen mit Betriebsinformationen wie Dateispeicherort, Benutzername des Absenders, Server-ID oder Connector-ID, Übertragungsstatus usw. Sie können diese Ereignisse verwenden, wenn Sie eine granulare Kontrolle bei der Definition der Dateiverarbeitung benötigen, z. B. mithilfe einer bedingten Logik, die auf der Quelle der Datei basiert, oder wenn Sie ereignisgesteuerte Architekturen für die Integration mit anderen AWS-Services, Drittanbieteranwendungen und Ihren eigenen Anwendungen erstellen müssen. Andererseits bieten die von AWS Transfer Family verwalteten Workflows ein vorgefertigtes Framework zur Definition einer linearen Abfolge allgemeiner Dateiverarbeitungsschritte, die auf alle Dateien angewendet werden, die über Ihre SFTP-, FTPS- und FTP-Serverendpunkte hochgeladen werden. Sie können Ihrem Endpunkt einen verwalteten Workflow zuordnen, wenn alle hochgeladenen Dateien mit denselben allgemeinen Dateiverarbeitungsschritten verarbeitet werden müssen, ohne dass eine granulare oder bedingte Logik angewendet werden muss.

Richten Sie zunächst Ihren Workflow so ein, dass er Aktionen wie Kopieren, Markieren und eine Reihe von Aktionen enthält, die Ihren eigenen benutzerdefinierten Schritt in einer auf Ihren Anforderungen basierenden Abfolge von Schritten enthalten können. Als Nächstes ordnen Sie den Workflow einem Server zu, so dass beim Eintreffen einer Datei die in diesem Workflow angegebenen Aktionen in Echtzeit ausgewertet und ausgelöst werden. Weitere Informationen finden Sie in der Dokumentation, in dieser Demo zu den ersten Schritten mit verwalteten Workflows oder in diesem Blogbeitrag zur Bereitstellung einer cloudnativen Dateiübertragungsplattform.

Ja. Derselbe Workflow kann mehreren Servern zugeordnet werden, sodass Sie Konfigurationen einfacher verwalten und standardisieren können.

Die folgenden allgemeinen Aktionen sind verfügbar, sobald ein Übertragungsserver eine Datei vom Client erhalten hat:

Datei mit PGP-Schlüssel entschlüsseln. Lesen Sie diesen Blogbeitrag zum Verschlüsseln und Entschlüsseln von Dateien mit PGP.

Verschieben oder Kopieren von Daten von dem Ort, an dem sie ankommen, zu dem Ort, an dem sie genutzt werden sollen.

Löschen der Originaldatei nach dem Archivieren oder Kopieren an einen neuen Speicherort.

Markieren der Datei anhand ihres Inhalts, damit sie von nachgeschalteten Services indiziert und durchsucht werden kann (nur S3)

Beliebige benutzerdefinierte Logik für die Dateiverarbeitung, indem Sie Ihre eigene Lambda-Funktion als benutzerdefinierten Schritt für Ihren Workflow bereitstellen. Zum Beispiel die Überprüfung der Kompatibilität des Dateityps, das Scannen von Dateien auf Malware, die Erkennung von persönlich identifizierbaren Informationen (PII) und die Extraktion von Metadaten, bevor die Dateien in Ihre Datenanalyse aufgenommen werden.

Ja. Sie können einen Workflow-Schritt so konfigurieren, dass er entweder die ursprünglich hochgeladene Datei oder die Ausgabedatei des vorherigen Workflow-Schrittes verarbeitet. So können Sie das Verschieben und Umbenennen Ihrer Dateien nach dem Hochladen auf Amazon S3 ganz einfach automatisieren. Um beispielsweise eine Datei zur Archivierung oder Aufbewahrung an einen anderen Speicherort zu verschieben, konfigurieren Sie zwei Schritte in Ihrem Workflow. Der erste Schritt besteht im Kopieren einer Datei an einen anderen Amazon-S3-Speicherort und der zweite Schritt im Löschen der ursprünglich hochgeladenen Datei. Lesen Sie die Dokumentation, um mehr über die Auswahl eines Dateispeichers für Workflow-Schritte zu erfahren.

Ja. Sie können einen vorgefertigten, vollständig verwalteten Workflow-Schritt für die PGP-Entschlüsselung von Dateien verwenden, die über Ihre SFTP-, FTPS- und FTP-Serverendpunkte hochgeladen wurden. Weitere Informationen finden Sie in der Dokumentation zu verwalteten Workflows und in diesem Blogbeitrag zum Verschlüsseln und Entschlüsseln von Dateien mit PGP.

Sie können einen Workflow-Schritt so konfigurieren, dass er entweder die ursprünglich auf Ihren Serverendpunkt hochgeladene Datei oder die Ausgabedatei aus dem vorherigen Schritt in einem Workflow verarbeitet. So können Sie das Verschieben und Umbenennen Ihrer Dateien nach dem Hochladen auf Amazon S3 ganz einfach automatisieren. Um beispielsweise eine Datei zur Archivierung oder Aufbewahrung an einen anderen Speicherort zu verschieben, konfigurieren Sie zwei Schritte in Ihrem Workflow. Der erste Schritt besteht im Kopieren einer Datei an einen anderen Amazon-S3-Speicherort und der zweite Schritt im Löschen der ursprünglich hochgeladenen Datei. Lesen Sie die Dokumentation, um mehr über die Auswahl eines Dateispeichers für Workflow-Schritte zu erfahren.

Ja. Mithilfe verwalteter Workflows können Sie mehrere Kopien der Originaldatei erstellen und gleichzeitig die Originaldatei für die Aufbewahrung von Aufzeichnungen beibehalten.

Ja. Sie können jetzt den Benutzernamen als Variable in Workflow-Kopierschritten verwenden, wodurch Sie Dateien dynamisch an benutzerspezifische Ordner in Amazon S3 weiterleiten können. Dadurch entfällt die Notwendigkeit, den Speicherort des Zielordners beim Kopieren von Dateien fest zu codieren, und die Erstellung benutzerspezifischer Ordner in Amazon S3 wird automatisiert, sodass Sie Ihre Dateiautomatisierungs-Workflows skalieren können. Lesen Sie die Dokumentation, um mehr zu erfahren.

Einzelheiten zu den unterstützten Features für die Protokollierung Ihrer Aktivitäten in verwalteten Workflows finden Sie im Abschnitt Überwachung.

AWS Step Functions ist ein Serverless-Orchestrierungsservice, mit dem Sie AWS Lambda mit anderen Services kombinieren können, um die Ausführung von Geschäftsanwendungen in einfachen Schritten zu definieren. Zur Durchführung von Dateiverarbeitungsschritten mit AWS Step Functions verwenden Sie AWS-Lambda-Funktionen mit den Ereignisauslösern von Amazon S3, um Ihre eigenen Workflows zusammenzustellen. Verwaltete Workflows bieten einen Framework für die einfache Orchestrierung einer linearen Abfolge von Verarbeitungen und unterscheiden sich in folgenden Punkten von bestehenden Lösungen: 1) Sie können Workflows granular definieren, die nur auf vollständigen Datei-Uploads aufgeführt werden, sowie Workflows, die auf partiellen Dateiuploads ausgeführt werden, 2) Workflows können sowohl für S3 als auch für EFS (das keine Post-Upload-Ereignisse bietet) automatisch ausgelöst werden, und 3) Workflows bieten keinen Code und vorgefertigte Optionen für gängige Dateiverarbeitungsvorgänge wie PGP-Entschlüsselung und 4) Kunden erhalten in CloudWatch-Protokollen einen umfassenden Einblick in ihre Dateiübertragungen und -verarbeitung.

Ja. In diesem Blogbeitrag erfahren Sie mehr über die Verwendung verwalteter Workflows für Benachrichtigungen zur Dateibereitstellung.

Ja. Sie können separate Workflows definieren, die bei vollständigen Dateiuploads und bei teilweisen Datei-Uploads ausgelöst werden.

Derzeit können verwaltete Workflows nur für Dateien ausgelöst werden, die über Ihre SFTP-, FTPS- und FTP-Serverendpunkte hochgeladen wurden, und pro Ausführung wird eine Datei verarbeitet. Verwaltete Workflows werden nicht für Nachrichten unterstützt, die über AS2 ausgetauscht werden, für Dateidownloads über Ihre Serverendpunkte und für Dateien, die mit SFTP-Connectors übertragen werden.

Nein. Die Verarbeitung kann nur beim Eintreffen der Datei über den Eingangsendpunkt aufgerufen werden.

Nein. Workflows verarbeiten derzeit eine Datei pro Ausführung.

Nein. Verwaltete Workflows können nicht granular pro Benutzer aufgerufen werden. Sie können eine bedingte Dateiverarbeitungslogik definieren, die darauf basiert, welcher Benutzer die Datei mithilfe der in Amazon EventBridge veröffentlichten Benachrichtigungen zu Dateiübertragungsereignissen hochgeladen hat.

Die Datenübertragung zwischen den Servern der AWS Transfer Family und Amazon S3 erfolgt über interne AWS-Netzwerke und nicht über das öffentliche Internet. Deshalb ist es nicht erforderlich, dass Sie AWS PrivateLink für Daten verwenden, die vom Server der AWS Transfer Family zu Amazon S3 übertragen werden. Der Transfer-Family-Service erfordert keine AWS-PrivateLink-Endpunkte für Amazon S3, um zu verhindern, dass Datenverkehr über das Internet geleitet wird. Es stehen somit keine Endpunkte für die Kommunikation mit Speicherservices zur Verfügung. Hierbei gehen wir davon aus, dass die AWS-Speicherservices und der Server der Transfer Family sich in der gleichen Region befinden.

AWS IAM wird verwendet, um die Zugriffsebene zu bestimmen, die Sie Ihren Benutzern zur Verfügung stellen möchten. Dies beinhaltet Informationen darüber, welche Operationen Sie auf ihrem Client aktivieren möchten und auf welche Amazon-S3-Buckets die Benutzer Zugriff haben, d. h. ob es sich um den gesamten Bucket oder um Teile davon handelt.

Das Startverzeichnis, das Sie für Ihren Benutzer einrichten, legt dessen Anmeldeverzeichnis fest. Das entspricht dem Verzeichnispfad, in den der Client die Benutzer nach dem erfolgreichen Authentifizieren am Server platziert. Sie werden sicherstellen müssen, dass die bereitgestellte IAM-Rolle den Benutzerzugriff auf das Startverzeichnis zur Verfügung stellt.

Ja. Sie können eine einzelne IAM-Rolle für alle Benutzer zuweisen und logische Verzeichniszuordnungen verwenden, die angeben, welche absoluten Amazon-S3-Bucket-Pfade den Endbenutzern angezeigt werden sollen und wie diese Pfade von den Clients dargestellt werden. In diesem Blog erfahren Sie, wie Sie Ihre AWS-SFTP/FTPS/FTP-Struktur mit Chroot und logischen Verzeichnissen vereinfachen können.

Dateien, die über die unterstützten Protokolle übertragen werden, werden als Objekte in Ihrem Amazon-S3-Bucket gespeichert, und es gibt eine Eins-zu-Eins-Zuordnung zwischen Dateien und Objekten, die einen nativen Zugriff auf diese Objekte über AWS-Services zur Verarbeitung oder Analyse ermöglicht.

A: Nach erfolgreicher Authentifizierung, basierend auf den Anmeldeinformationen Ihrer Benutzer, stellt der Service Amazon-S3-Objekte und -Ordner als Dateien und Verzeichnisse für die Übertragungsanwendungen Ihrer Benutzer dar.

Es werden gängige Befehle zum Erstellen, Lesen, Aktualisieren und Löschen von Dateien und Verzeichnissen unterstützt. Dateien werden in Ihrem Amazon-S3-Bucket als einzelne Objekte gespeichert. Verzeichnisse werden in S3 als Ordnerobjekte verwaltet und verwenden dieselbe Syntax wie die S3 Konsole.

Verzeichnisumbenennungsvorgänge, Anfügevorgänge, Besitzwechsel, Berechtigungen und Zeitstempel sowie die Verwendung symbolischer und fester Links werden aktuell nicht unterstützt.

Ja. Sie können Dateioperationen mit der AWS-IAM-Rolle, die Sie den jeweiligen Benutzernamen zugeordnet haben, aktivieren und deaktivieren. Weitere Informationen finden Sie in der Dokumentation zum Erstellen von IAM-Richtlinien und -Rollen zum Steuern des Endbenutzerzugriffs

Ja. Der oder die Buckets, auf die Ihr Benutzer zugreifen kann, werden durch die AWS-IAM-Rolle und die optionale Scope-Down-Richtlinie bestimmt, die Sie für diesen Benutzer festlegen. Sie können nur einen einzelnen Bucket als Startverzeichnis für den Benutzer verwenden.

Ja. Sie können S3-Zugangspunkt-Aliase mit AWS Transfer Family verwenden, um granularen Zugriff auf einen großen Datensatz zu ermöglichen, ohne dass Sie eine einzelne Bucket-Richtlinie verwalten müssen. Durch die Kombination von S3-Zugangspunkt-Aliasen mit den logischen Verzeichnissen der AWS Transfer Family können Sie eine fein abgestufte Zugriffskontrolle für verschiedene Anwendungen, Teams und Abteilungen erstellen und dabei gleichzeitig den Aufwand für die Verwaltung von Bucket-Richtlinien reduzieren. Weitere Informationen und erste Schritte finden Sie im Blogbeitrag zur Verbesserung der Datenzugriffskontrolle mit AWS Transfer Family und Amazon S3 Access Points.

Ja. Sie können die CLI und die API verwenden, um einen kontenübergreifenden Zugriff zwischen Ihrem Server und den Buckets einzurichten, die Sie für das Speichern von Dateien, die über die unterstützten Protokolle übertragen werden, verwenden möchten. Die Dropdown-Liste der Konsole listet nur Bereiche in Konto A auf. Außerdem müssen Sie sicherstellen, dass die dem Benutzer zugewiesene Rolle zu Konto A gehört.

Ja. AWS Transfer Family veröffentlicht nach Abschluss eines Dateiübertragungsvorgangs Ereignisbenachrichtigungen in Amazon EventBridge. Sie können diese Ereignisse verwenden, um die Verarbeitung Ihrer Dateien nach dem Hochladen zu automatisieren. Wenn alle Ihre hochgeladenen Dateien mit denselben Dateiverarbeitungsschritten ohne bedingte Logik verarbeitet werden müssen, können Sie alternativ die von AWS Transfer Family verwalteten Workflows verwenden, um eine lineare Abfolge allgemeiner Dateiverarbeitungsschritte zu definieren, die automatisch für jede Datei aufgerufen werden, die Ihre Benutzer über Ihre SFTP-, FTPS- oder FTP-Serverendpunkte hochladen.

Ja. Wenn der Benutzer eine Datei hochlädt, werden Benutzername und Server-ID des Servers, der für das Hochladen verwendet wird, als Teil der zugeordneten Metadaten des S3-Objekts gespeichert. Beachten Sie die Dokumentation zu den Informationen, die Sie für die Nachbearbeitung des Uploads verwenden. Die Endbenutzerinformationen sind auch in der von AWS Transfer Family in Amazon EventBridge veröffentlichten Ereignisbenachrichtigung zum automatischen Datei-Upload verfügbar. Sie können diese Informationen verwenden, um die granulare Verarbeitung nach dem Hochladen Ihrer Dateien auf der Grundlage des Benutzers zu orchestrieren. 

Amazon S3 kann Ereignisbenachrichtigungen für jedes neue Objekt veröffentlichen, das in Ihrem Bucket erstellt wurde. Andererseits veröffentlicht AWS Transfer Family bei erfolgreichem oder fehlgeschlagenem Abschluss jedes Dateiübertragungsvorgangs Ereignisbenachrichtigungen. Es unterscheidet sich in den folgenden Punkten von Amazon-S3-Ereignisbenachrichtigungen: 1) Sie können die Verarbeitung nach dem Hochladen für vollständige Dateiuploads im Vergleich zu teilweisen Datei-Uploads genau festlegen, 2) Transfer-Family-Ereignisse werden für Datei-Uploads sowohl in S3 als auch in EFS veröffentlicht, und 3) Von Transfer Family generierte Ereignisse enthalten Betriebsinformationen wie den Benutzernamen des Absenders, die Server-ID, den Übertragungsstatus usw. und ermöglichen Ihnen eine granulare Dateiverarbeitung basierend auf bedingter Logik für diese Attribute.

Ja. Sie können Ihre S3-Verzeichnisliste optimieren, sodass Ihre Endbenutzer ihr Verzeichnis schneller auflisten können – von Minuten auf Sekunden. Wenn Sie nach dem 17.11.2023 über die Konsole einen neuen Server erstellen, ist auf Ihrem Server standardmäßig die optimierte S3-Verzeichnisliste aktiviert, wenn Sie Amazon S3 als Speicher verwenden. Dies kann jederzeit ein- oder ausgeschaltet werden. Wenn Sie diese Funktion ausschalten, wird Ihre S3-Verzeichnisliste auf die Standardleistung zurückgesetzt. Wenn Sie CloudFormation, CLI oder API verwenden, um einen Server zu erstellen, ist die optimierte S3-Verzeichnisliste standardmäßig deaktiviert, kann aber jederzeit aktiviert werden. Lesen Sie in der Dokumentation nach, wie Sie eine optimierte S3-Verzeichnisliste aktivieren.

Obwohl dies von Ihrer Verwendung von Sitzungsrichtlinien und anderen internen Anforderungen abhängt, benötigen Sie im Allgemeinen nicht sowohl Sitzungsrichtlinien als auch logische Verzeichnisse, um sicherzustellen, dass Ihre Benutzer nur auf die Dateien zugreifen, auf die Sie zugreifen möchten. Logische Verzeichniszuordnungen ermöglichen Benutzern nur den Zugriff auf ihre angegebenen logischen Pfade und Unterverzeichnisse und verbieten relative Pfade, die die logischen Wurzeln durchqueren. Wir validieren jeden Pfad mithilfe einer relativen Notation, die relative Elemente enthalten kann, und blockieren aktiv die Auflösung dieser Pfade, bevor wir diese Pfade an S3 übergeben, um zu verhindern, dass Ihre Benutzer ihre logischen Zuordnungen überschreiten. 

Bevor Sie AWS Transfer Family für die Arbeit mit einem Amazon-EFS-Dateisystem einrichten, müssen Sie die Eigentümerschaft von Dateien und Ordnern mit denselben POSIX-Identitäten (Benutzer-ID/Gruppen-ID) einrichten, die Sie Ihren AWS-Transfer-Family-Benutzern zuweisen möchten. Wenn Sie auf Dateisysteme in einem anderen Konto zugreifen, müssen außerdem Ressourcenrichtlinien auf Ihrem Dateisystem konfiguriert werden, um den kontoübergreifenden Zugriff zu ermöglichen. Eine schrittweise Anleitung zur Verwendung von AWS Transfer Family mit EFS finden Sie in diesem Blog-Beitrag.

Die Datenübertragung zwischen den Servern der AWS Transfer Family und Amazon EFS erfolgt über interne AWS-Netzwerke und nicht über das öffentliche Internet. Deshalb ist es nicht erforderlich, dass Sie AWS PrivateLink für Daten verwenden, die vom Server der AWS Transfer Family zu Amazon EFS übertragen werden. Der Transfer-Family-Service erfordert keine AWS-PrivateLink-Endpunkte für Amazon EFS, um zu verhindern, dass Traffic über das Internet geleitet wird. Es stehen somit keine Endpunkte für die Kommunikation mit Speicherservices zur Verfügung. Hierbei gehen wir davon aus, dass die AWS-Speicherservices und der Server der Transfer Family sich in der gleichen Region befinden.

Amazon EFS verwendet POSIX-IDs, die aus einer Betriebssystem-Benutzer-ID, einer Gruppen-ID und einer sekundären Gruppen-ID bestehen, um den Zugriff auf ein Dateisystem zu steuern. Wenn Sie Ihren Benutzer in der AWS-Transfer-Family-Konsole/CLI/API einrichten, müssen Sie den Benutzernamen, die POSIX-Konfiguration des Benutzers und eine IAM-Rolle für den Zugriff auf das EFS-Dateisystem angeben. Sie müssen auch eine EFS-Dateisystem-ID und optional ein Verzeichnis innerhalb dieses Dateisystems als Landeverzeichnis für Ihren Benutzer angeben. Wenn sich Ihr AWS-Transfer-Family-Benutzer erfolgreich über seinen Dateiübertragungs-Client authentifiziert, wird er direkt im angegebenen Home-Verzeichnis oder im Stammverzeichnis des angegebenen EFS-Dateisystems platziert. Ihre Betriebssystem-POSIX-ID wird auf alle Anfragen angewendet, die über ihre Dateiübertragungs-Clients gestellt werden. Als EFS-Administrator müssen Sie sicherstellen, dass die Dateien und Verzeichnisse, auf die Ihre AWS-Transfer-Family-Benutzer zugreifen sollen, den entsprechenden POSIX-IDs in Ihrem EFS-Dateisystem gehören. Lesen Sie die Dokumentation, um mehr über die Konfiguration der Eigentümerschaft von Unterverzeichnissen in EFS zu erfahren. Beachten Sie, dass Transfer Family keine Access Points unterstützt, wenn Sie Amazon EFS für die Speicherung verwenden.  

Dateien, die über die aktivierten Protokolle übertragen werden, werden direkt in Ihren Amazon-EFS-Dateisystemen gespeichert und sind über eine Standard-Dateisystem-Schnittstelle oder von AWS-Services, die auf Amazon-EFS-Dateisysteme zugreifen können, zugänglich.

A: SFTP/FTPS/FTP-Befehle zum Erstellen, Lesen, Aktualisieren und Löschen von Dateien, Verzeichnissen und symbolischen Links werden unterstützt. In der folgenden Tabelle finden Sie die unterstützten Befehle für EFS sowie S3.

1. Es werden nur Dateiumbenennungen unterstützt. Verzeichnisumbenennungen und das Umbenennen von Dateien zum Überschreiben vorhandener Dateien werden nicht unterstützt.

2. Nur Root-Benutzer, d. h. Benutzer mit uid=0, können Eigentümer und Berechtigungen von Dateien und Verzeichnissen ändern.

3. Unterstützt entweder für root z. B. uid=0 oder für den Eigentümer der Datei, der die Gruppe einer Datei nur in eine seiner sekundären Gruppen ändern kann.

4. Wird nur bei nicht leeren Ordnern unterstützt.

Die IAM-Richtlinie, die Sie für Ihren AWS-Transfer-Family-Benutzer bereitstellen, bestimmt, ob er schreibgeschützten, nicht schreibgeschützten und Root-Zugriff auf Ihr Dateisystem hat. Darüber hinaus können Sie als Dateisystemadministrator Besitzrechte einrichten und den Zugriff auf Dateien und Verzeichnisse innerhalb Ihres Dateisystems über ihre Benutzer- und Gruppenkennungen gewähren. Dies gilt für Benutzer, unabhängig davon, ob sie innerhalb des Dienstes (service managed) oder innerhalb Ihres Identitätsmanagementsystems („BYO Auth“) gespeichert sind.

Ja. Wenn Sie Ihren Benutzer einrichten, können Sie verschiedene Dateisysteme und Verzeichnisse für jeden Ihrer Benutzer angeben. Bei erfolgreicher Authentifizierung erzwingt EFS ein Verzeichnis für jede Dateisystemanforderung, die mit den aktivierten Protokollen erfolgt.

Ja. Mit den logischen Verzeichniszuordnungen der AWS Transfer Family können Sie die Sicht Ihrer Endbenutzer auf Verzeichnisse in Ihren Dateisystemen einschränken, indem Sie absolute Pfade auf für Endbenutzer sichtbare Pfadnamen abbilden. Dazu gehört auch die Möglichkeit, den Benutzer in sein gewünschtes Home-Verzeichnis zu „chrooten“.

Ja. Wenn symbolische Links in Verzeichnissen vorhanden sind, auf die Ihr Benutzer Zugriff hat, und Ihr Benutzer versucht, auf diese zuzugreifen, werden die Links in sein Ziel aufgelöst. Symbolische Links werden nicht unterstützt, wenn Sie logische Verzeichniszuordnungen verwenden, um den Zugriff Ihrer Benutzer einzurichten.

Ja. Wenn Sie einen AWS-Transfer-Family-Benutzer einrichten, können Sie in der IAM-Richtlinie, die Sie als Teil Ihrer Benutzereinrichtung bereitstellen, ein oder mehrere Dateisysteme angeben, um Zugriff auf mehrere Dateisysteme zu gewähren.

Sie können Clients und Anwendungen für Microsoft Windows, Linux, macOS oder jedes andere Betriebssystem verwenden, das SFTP/FTPS/FTP unterstützt, um Dateien hochzuladen und auf Dateien zuzugreifen, die in Ihren EFS-Dateisystemen gespeichert sind. Konfigurieren Sie einfach den Server und den Benutzer mit den entsprechenden Berechtigungen für das EFS-Dateisystem, um über alle Betriebssysteme hinweg auf das Dateisystem zuzugreifen.

Sie haben zwei Möglichkeiten: 1) AWS Transfer Family veröffentlicht nach Abschluss eines Dateiübertragungsvorgangs Ereignisbenachrichtigungen in Amazon EventBridge, und Sie können diese Ereignisse verwenden, um die Verarbeitung Ihrer Dateien nach dem Hochladen zu automatisieren, und 2) Wenn alle Ihre hochgeladenen Dateien mit denselben Dateiverarbeitungsschritten ohne bedingte Logik verarbeitet werden müssen, können Sie mithilfe der von AWS Transfer Family verwalteten Workflows eine lineare Abfolge allgemeiner Dateiverarbeitungsschritte definieren, die für jede über SFTP-, FTPS- oder FTP-Server-Endpunkte hochgeladene Datei angewendet werden.

Für neue Dateien wird die POSIX-Benutzerkennung des Benutzers, der die Datei hochlädt, als Eigentümer der Datei in Ihrem EFS-Dateisystem festgelegt. Zusätzlich können Sie Amazon CloudWatch verwenden, um die Aktivitäten Ihrer Benutzer für Dateierstellungs-, Aktualisierungs-, Lösch- und Lesevorgänge zu verfolgen. In der Dokumentation erfahren Sie mehr darüber, wie Sie die Amazon-CloudWatch-Protokollierung aktivieren können.

Ja. Sie können die Befehlszeilenschnittstelle und die API verwenden, um den kontoübergreifenden Zugriff zwischen Ihren AWS-Transfer-Family-Ressourcen und EFS-Dateisystemen einzurichten. Die AWS-Transfer-Family-Konsole listet nur Dateisysteme auf, die demselben Konto angehören. Außerdem müssen Sie sicherstellen, dass die IAM-Rolle, die dem Benutzer für den Zugriff auf das Dateisystem zugewiesen wurde, zu Konto A gehört.

Wenn Sie einen AWS-Transfer-Family-Server für den Zugriff auf ein kontoübergreifendes EFS-Dateisystem einrichten, das nicht für den kontoübergreifenden Zugriff aktiviert ist, wird Ihren SFTP/FTP/FTPS-Benutzern der Zugriff auf das Dateisystem verweigert. Wenn Sie die CloudWatch-Protokollierung auf Ihrem Server aktiviert haben, werden kontoübergreifende Zugriffsfehler in Ihren CloudWatch-Protokollen protokolliert.

Nein. Sie können AWS Transfer Family nur für den Zugriff auf EFS-Dateisysteme in derselben AWS-Region verwenden.

Ja. Mit AWS DataSync können Sie Dateien in EFS kopieren und die Einstellungen für das EFS- Lifecycle Management so konfigurieren, dass Dateien, auf die über einen festgelegten Zeitraum nicht zugegriffen wurde, in die Speicherklasse für seltenen Zugriff (Infrequent Access, IA) migriert werden.

Ja. Amazon EFS stellt eine Dateisystemoberfläche, eine Dateisystem-Zugriffssemantik (z. B. starke Konsistenz und Dateisperren) sowie Speicher bereit, auf die bzw. den Tausende von NFS/SFTP/FTPS/FTP-Clients gleichzeitig zugreifen können.

Ja. Der Zugriff auf Ihre EFS-Dateisysteme über Ihre AWS-Transfer-Family-Server verbraucht Ihr EFS-Burst-Guthaben unabhängig vom Durchsatzmodus. Lesen Sie die Dokumentation zu den verfügbaren Leistungs- und Durchsatzmodi und sehen Sie sich einige nützliche Leistungstipps an.

Für die sichere Übertragung über öffentliche Netzwerke sollte SFTP oder FTPS verwendet werden. Aufgrund der zugrunde liegenden Sicherheit der Protokolle basierend auf kryptografischen SSH- und TLS-Algorithmen werden Daten und Befehle über einen sicheren, verschlüsselten Kanal übertragen.

Sie können die in Ihrem Bucket gespeicherten Dateien mit Amazon-S3-Server-Side Encryption (SSE-S3) oder Amazon KMS (SSE-KMS) verschlüsseln. Für Dateien, die in EFS gespeichert sind, können Sie AWS oder vom Kunden verwaltetes CMK für die Verschlüsselung von Dateien im Ruhezustand wählen. Weitere Informationen zu den Optionen für die Verschlüsselung von Dateidaten und Metadaten im Ruhezustand mithilfe von Amazon EFS finden Sie in der Dokumentation.

Die AWS Transfer Family ist konform mit PCI-DSS, GDPR, FedRAMP und SOC 1, 2 und 3. Der Service ist auch HIPAA-konform. Erfahren Sie mehr über den Leistungsumfang von Compliance-Programmen .

Die AWS-Regionen Ost/West und GovCloud (USA) sind FISMA-konform. Wenn die AWS Transfer Family für FedRAMP autorisiert ist, wird sie innerhalb der jeweiligen Regionen FISMA-konform sein. Diese Compliance wird durch die FedRAMP-Autorisierung dieser beiden Regionen gemäß FedRAMP-Moderate und FedRAMP-High nachgewiesen. Wir weisen die Konformität durch jährliche Prüfungen und die Dokumentierung der Compliance mit geltenden NIST-SP-800-53-Kontrollen in unseren Systemsicherheitsplänen nach. Vorlagen sind zusammen mit unserer Kundenverantwortungsmatrix (CRM) auf Artifact verfügbar. Diese zeigt auf detaillierter Ebene unsere Verantwortung, diese NIST-Kontrollen gemäß FedRAMP zu erfüllen. Artifact ist über die Managementkonsole verfügbar und für AWS-Konten in den Regionen Ost/West und GovCloud zugänglich. Wenn Sie weitere Fragen zu diesem Thema haben, wenden Sie sich bitte an die Konsole.

Dateien, die über Services hochgeladen werden, werden durch den Vergleich ihrer MD5-Prüfsumme vor und nach dem Hochladen verifiziert.

Sie können von AWS Transfer Family verwaltete Workflows verwenden, um Dateien automatisch mithilfe von PGP-Schlüsseln zu entschlüsseln, wenn sie auf Ihre SFTP-, FTPS- oder FTP-Serverendpunkte von AWS Transfer Family hochgeladen werden. Weitere Informationen finden Sie in unserer Dokumentation zu verwalteten Workflows. Alternativ können Sie die in Amazon EventBridge veröffentlichten Ereignisbenachrichtigungen von AWS Transfer Family abonnieren, um die granulare und ereignisgesteuerte Verarbeitung übertragener Dateien mithilfe Ihrer eigenen Verschlüsselungs-/Entschlüsselungslogik zu orchestrieren.

Sie können Ihre Endbenutzer und deren File-Transfer-Aktivitäten mithilfe von JSON-formatierten Protokollen überwachen, die an Amazon CloudWatch übermittelt werden. Mit CloudWatch können Sie Ihre Protokolle mithilfe von CloudWatch Log Insights, das automatisch JSON-formatierte Felder erkennt, leicht analysieren und abfragen. Mit CloudWatch Contributor Insights können Sie auch die wichtigsten Benutzer, die Gesamtzahl der einzelnen Benutzer und deren fortlaufende Nutzung verfolgen. Wir bieten auch vorgefertigte CloudWatch-Metriken und -Grafiken, auf die in der Managementkonsole von AWS Transfer Family zugegriffen werden kann. Weitere Informationen finden Sie in der Dokumentation.

Ja. Sie können Protokollstreams von mehreren Servern der AWS Transfer Family in einer einzigen CloudWatch-Protokollgruppe kombinieren. So können Sie konsolidierte Protokollmetriken und Visualisierungen erstellen, die zu CloudWatch-Dashboards hinzugefügt werden können, um die Servernutzung und -leistung zu verfolgen.

Workflow-Ausführungen können mithilfe von AWS-CloudWatch-Metriken wie der Gesamtzahl der Workflow-Ausführungen, der erfolgreichen Ausführungen und der fehlgeschlagenen Ausführungen überwacht werden. Über die AWS-Managementkonsole können Sie den Echtzeitstatus laufender Workflow-Ausführungen suchen und anzeigen. Verwenden Sie CloudWatch-Protokolle zur detaillierten Protokollierung der Workflow-Ausführungen.

Die AWS Transfer Family liefert Protokolle im JSON-Format für alle Ressourcen – einschließlich Server, Connectors und Workflows – und alle Protokolle – wie SFTP, FTPS, FTP und AS2.

Sie können die verwalteten Workflows der Transfer Family verwenden, um Benachrichtigungen für Dateien zu erhalten, die über Ihre SFTP-, FTPS- und FTP-Serverendpunkte hochgeladen wurden. Lesen Sie diesen Blogbeitrag. Alternativ können Sie Ereignisse von AWS Transfer Family in Amazon EventBridge abonnieren, um Benachrichtigungen über Amazon Simple Notification Service (SNS) zu erhalten.

Ja. Wenn eine Dateivalidierungsprüfung anhand vorkonfigurierter Workflow-Validierungsschritte fehlschlägt, können Sie den Ausnahme-Handler verwenden, um Ihr Überwachungssystem aufzurufen oder Teammitglieder über ein Amazon-SNS-Thema zu benachrichtigen.

Die Rechnung wird für jedes aktivierte Protokoll vom Zeitpunkt des Erstellens und Konfigurierens des Serverendpunkts bis zu seiner Löschung auf Stundenbasis erstellt. Die Abrechnung erfolgt außerdem auf der Grundlage der über SFTP, FTPS oder FTP hoch- und heruntergeladenen Datenmenge und der Anzahl der über AS2 ausgetauschten Nachrichten, sowie der vom Workflow-Schritt Entschlüsseln genutzten Datenmenge. Wenn Sie SFTP-Connectors verwenden, werden Ihnen die übertragene Datenmenge und die Anzahl der API-Aufrufe für Dateiübertragungen in Rechnung gestellt. Weitere Informationen finden Sie auf der Seite mit den Preisangaben

Nein. Die Abrechnung erfolgt für jedes der aktivierten Protokolle und für die Datenmenge, die über die einzelnen Protokolle übertragen wird, auf Stundenbasis. Dabei spielt es keine Rolle, ob der gleiche Endpunkt für mehrere Protokolle aktiviert wird oder ob unterschiedliche Endpunkte für die einzelnen Protokolle verwendet werden.

Ja. Das Stoppen des Servers über die Konsole oder durch Ausführen des CLI-Befehls „stop-server“ oder des API-Befehls „StopServer“ hat keine Auswirkungen auf die Abrechnung. Ab dem Zeitpunkt, an dem Sie Ihren Server-Endpunkt erstellen und den Zugriff auf ihn über ein oder mehrere Protokolle konfigurieren, bis zu dem Zeitpunkt, an dem Sie ihn löschen, werden Sie auf Stundenbasis abgerechnet.

Der Workflow-Schritt Entschlüsseln wird Ihnen auf der Grundlage der Datenmenge, die Sie mit PGP-Schlüsseln entschlüsseln, in Rechnung gestellt. Für die Nutzung verwalteter Workflows fallen keine zusätzlichen Kosten an. Abhängig von Ihrer Workflow-Konfiguration wird Ihnen die Nutzung von Amazon S3, Amazon EFS, AWS Secrets Manager und AWS Lambda in Rechnung gestellt.

Nein. Es gibt keine stündliche Abrechnung für SFTP-Connectors. Die Abrechnung erfolgt auf der Grundlage der Datenmenge, die Sie mithilfe von Connectors senden oder abrufen. Darüber hinaus wird Ihnen jeder Dateipfad in Rechnung gestellt, den Sie in einem StartFileTransfer-API-Aufruf angeben.