AWS Storage Gateway – Häufig gestellte Fragen

Amazon S3 File Gateway ist eine Konfiguration des AWS-Storage-Gateway-Services, die Ihren Anwendungen eine Dateischnittstelle zur Verfügung stellt. Die Dateien werden nahtlos als Objekte in Amazon S3 gespeichert und Sie können auf diese zugreifen, unter Verwendung von dem Branchenstandard entsprechenden Dateiprotokollen.

Anwendungsfälle für Amazon S3 File Gateway umfassen: (a) die Migration On-Premises-Dateidaten zu Amazon S3 unter Beibehaltung des schnellen lokalen Zugriffs auf Daten, auf die unlängst zugegriffen wurde, (b) die Sicherung von On-Premises-Dateidaten als Objekte in Amazon S3 (einschließlich Microsoft-SQL-Server- und Oracle-Datenbanken und -Protokolle) mit der Möglichkeit, S3-Funktionen wie Lebenszyklusmanagement und regionsübergreifende Replikation zu nutzen, und (c) Hybrid-Cloud-Workflows unter Verwendung von Daten, die von lokalen Anwendungen für die Verarbeitung durch AWS-Services wie Machine Learning, Big Data Analytics oder Serverless-Funktionen generiert wurden.

Mit Amazon S3 File Gateway können Ihre bestehenden dateibasierten Anwendungen, Geräte und Workflows Amazon S3 nutzen, ohne dafür Änderungen zu erfordern. Amazon S3 File Gateway speichert sowohl Dateiinhalte als auch Metadaten sicher und dauerhaft als Objekte, während Ihre On-Premises-Anwendungen mit geringer Latenz auf zwischengespeicherte Daten zugreifen können.

Amazon S3 File Gateway unterstützt Amazon S3 Standard, S3 Intelligent-Tiering, S3 Standard – Infrequent Access (S3 Standard-IA) und S3 One Zone-IA. Einzelheiten zu den Speicherklassen finden Sie in der Dokumentation zu Amazon S3. Sie konfigurieren die anfängliche Speicherklasse für Objekte, die das Gateway erstellt, und können dann die Bucket-Lebenszyklusrichtlinien verwenden, um Dateien von Amazon S3 nach Amazon S3 Glacier zu verschieben. Wenn eine Anwendung versucht, über Amazon File Gateway auf eine Datei oder ein Objekt zuzugreifen, die bzw. das nun in Amazon S3 Glacier gespeichert ist, erhalten Sie einen generischen E/A-Fehler.

Amazon S3 File Gateway unterstützt Linux-Clients, die sich mit dem Gateway über Network File System (NFS) Version 3 und 4.1 verbinden, und Windows-Clients, die sich mit dem Gateway über Server Message Block (SMB) Version 2 und 3 verbinden.

Sie können mithilfe der AWS-Managementkonsole oder Service-API eine NFS- oder SMB-Dateifreigabe erstellen und diese mit einem neuen oder bestehenden Amazon S3-Bucket verknüpfen. Um über Ihre Anwendungen auf die Dateifreigabe zuzugreifen, stellen Sie sie von Ihrer Anwendung aus mithilfe von standardmäßigen UNIX- oder Windows-Befehlen bereit. Zu Ihrer Unterstützung werden in der Managementkonsole für jede Umgebung praktische Beispielbefehlszeilen angezeigt.

Sie können Ihre NFS-Dateifreigabe mit administrativer Kontrolle konfigurieren und beispielsweise den Zugriff auf bestimmte NFS-Clients oder -Netzwerke beschränken, Lese- oder Schreibzugriff festlegen oder das Squashing von Benutzerberechtigungen aktivieren.

Sie können Ihre SMB-Dateifreigabe so konfigurieren, dass nur Active Directory(AD)-Benutzer darauf zugreifen können, oder Sie stellen authentifizierten Gastzugriff für Benutzer in Ihrer Organisation bereit. Sie können den Zugriff auf die Dateifreigabe weiter einschränken: schreibgeschützt, mit Lese- und Schreibrechten oder auf bestimmte AD-Benutzer und -Gruppen.

Ja, Sie können eine zugriffsbasierte Aufzählung für Ihre SMB-Dateifreigaben konfigurieren, um zu verhindern, dass Benutzer Ordner und Dateien sehen, die sie aufgrund ihrer Zugriffsberechtigungen nicht öffnen könnten. Sie können auch steuern, ob die Dateifreigaben auf dem Amazon-S3-File-Gateway für Benutzer durchsuchbar sind.

Ja, Amazon S3 File Gateway lässt sich sowohl in Microsoft Active Directory vor Ort als auch in In-Cloud-Active-Directory-Lösungen wie Managed Microsoft AD integrieren.

Ja. Sie können eine SMB-Dateifreigabe exportieren, indem Sie einen Gastbenutzernamen und ein Passwort verwenden. Sie müssen das Standardpasswort über die Konsole oder die Service-API ändern, bevor Sie Ihre Dateifreigabe für den Gastzugriff einrichten können.

Ja.

Nein, derzeit als S3-Objekt-Metadaten gespeicherte Datei-Metadaten, wie z. B. Eigentum, können nicht auf verschiedenen Protokolle zugeordnet werden.

Amazon S3 File Gateway nutzt eine AWS Identity and Access Management (IAM)-Rolle für den Zugriff auf Ihr S3-Bucket. Sie können selbst eine IAM-Rolle einrichten oder sie automatisch über die Managementkonsole von AWS Storage Gateway einrichten lassen. Für die automatische Einrichtung erstellt AWS Storage Gateway eine neue IAM-Rolle in Ihrem Konto und verknüpft sie für den Zugriff auf Ihr S3-Bucket mit einer IAM-Zugriffsrichtlinie. Die IAM-Rolle und IAM-Zugriffsrichtlinie werden in Ihrem Konto erstellt, und Sie können sie vollkommen selbstständig verwalten.

Um die Dateifreigabe zu nutzen, stellen Sie sie von Ihrer Anwendung aus mithilfe von standardmäßigen UNIX- oder Windows-Befehlen bereit. Zu Ihrer Unterstützung werden in der Managementkonsole praktische Beispielbefehlszeilen angezeigt.

Die Dateifreigabe kann auf die Root des S3-Buckets oder auf ein S3-Präfix innerhalb eines S3-Buckets gemappt werden. Wenn Sie beim Erstellen einer Dateifreigabe ein S3-Präfix angeben, binden Sie die Dateifreigabe an das S3-Präfix. Wenn Sie bei der Erstellung einer Dateifreigabe kein S3-Präfix erstellen, ist die Dateifreigabe an den Root des S3-Buckets gebunden.

Ja. Der Name der Dateifreigabe muss nicht mit dem Namen des S3-Buckets oder des S3-Präfixes übereinstimmen.

Ja. Sie können den Namen Ihrer Dateifreigabe ändern.

Dateien werden in Ihren S3-Buckets als Objekte gespeichert und Sie können die anfängliche Speicherklasse für die von File Gateway erstellten Objekte konfigurieren. Es besteht eine Eins-zu-Eins-Beziehung zwischen Dateien und Objekten, und Sie können die anfängliche Speicherklasse für Objekte konfigurieren, die von Amazon S3 File Gateway erstellt werden.

Der Objektschlüssel leitet sich vom Dateipfad innerhalb des Dateisystems ab. Wenn Sie beispielsweise ein Gateway mit dem Hostnamen file.amazon.com haben und my-bucket/my-prefix zugeordnet haben, dann stellt File Gateway einen Mounting-Punkt namens file.amazon.com:/export/my-bucket/my-prefix zur Verfügung. Wenn Sie diesen dann lokal auf /mnt/my-bucket/my-prefix mounten und eine Datei namens file.html in einem Verzeichnis /mnt/my-bucket/my-prefix/dir erstellen, wird diese Datei als Objekt im Bucket my-bucket mit dem Schlüssel my-prefix/dir/file.html gespeichert. Die Erstellung von Dateien mit geringer Dichte führt in S3 zu einem mit Nullen gefüllten Objekt ohne geringe Dichte.

Ihre Clients können Dateien und Verzeichnisse erstellen, lesen, aktualisieren und löschen. Ihre Clients können auch die Berechtigungen und Besitzer von Dateien und Ordnern ändern. Dateien werden in Amazon S3 als einzelne Objekte gespeichert. Verzeichnisse werden in S3 als Ordnerobjekte verwaltet und verwenden dieselbe Syntax wie die S3 Konsole. Symbolische Verknüpfungen und feste Links werden nicht unterstützt. Falls die Erstellung eines Links versucht wird, tritt ein Fehler auf. Allgemeine Dateioperationen ändern Dateimetadaten, was zur Löschung des aktuellen S3-Objekts und zur Erstellung eines neuen S3-Objekts führt.

Umbenennungsvorgänge werden den Clients atomar angezeigt, allerdings unterstützt S3 keine Umbenennung von Objekten. Wenn Sie eine Datei oder ein Verzeichnis umbenennen, führt das Gateway Kopier- und Einfügeanforderungen (copy-put) aus, um unter den neuen Schlüsseln eine Kopie der Objekte in S3 zu erstellen, und löscht anschließend die Originalobjekte. Dadurch wird vermieden, dass große Dateien erneut im Netzwerk gesendet werden müssen. Die Umbenennung von Verzeichnissen, die viele Dateien enthalten, erfolgt nicht umgehend und führt dazu, dass in S3 zwei Kopien Ihrer Daten gespeichert werden und dass Operationen in den Verzeichnissen blockiert werden, bis der Umbenennungsvorgang abgeschlossen ist.

Ihre Clients können auf Metadaten im POSIX-Stil zugreifen, einschließlich Besitz, Berechtigungen und Zeitstempel, die dauerhaft in S3 in den Benutzermetadaten des der Datei zugeordneten Objekts gespeichert sind. Wenn Sie eine Dateifreigabe für einen bestehenden Bucket erstellen, werden die gespeicherten Metadaten wiederhergestellt und Ihren Clients zur Verfügung gestellt.

Für jede freigegebene Datei können Sie das Erraten von MIME-Typen für hochgeladene Objekte bei Erstellung aktivieren oder die Funktion später aktivieren. Sofern File Gateway aktiviert ist, verwendet es die Dateinamenserweiterung, um den MIME-Typ für die Datei zu bestimmen und den Inhaltstyp der S3-Objekte entsprechend festzulegen. Dies ist von Vorteil, wenn Sie File Gateway zur Verwaltung von Objekten in S3 verwenden, auf die Sie direkt über eine URL zugreifen oder die Sie über Amazon CloudFront verteilen.

Ja. Sobald Objekte in S3 gespeichert sind, können Sie darauf ohne Amazon S3 File Gateway direkt in AWS für Workloads innerhalb der Cloud zugreifen. Ihre Objekte erben die Eigenschaften des S3-Buckets, in dem sie gespeichert sind, darunter Lebenszyklusverwaltung und regionsübergreifende Replikation.

Ein Objekt, auf das der Zugriff über eine Dateifreigabe erfolgen muss, sollte nur von dem Gateway verwaltet werden. Wenn Sie ein Objekt, das zuvor von Amazon S3 File Gateway geschrieben wurde, direkt überschreiben oder aktualisieren, resultiert dies in nicht definiertem Verhalten, wenn der Zugriff auf das Objekt über die Dateifreigabe erfolgt.

Falls Ihr Bucket bereits Objekte enthält, werden, wenn Sie ihn für die Verwendung mit Amazon S3 File Gateway konfigurieren, Objektschlüssel verwendet, um den NFS- und SMB-Clients die Objekte als Dateien zur Verfügung zu stellen. Die Dateien erhalten standardmäßig Dateisystem-Metadaten.

Wenn Sie Dateien oder Verzeichnisse explizit auflisten, scannt Amazon S3 File Gateway nur die Header nach Datei-Metadaten, die mit den Objekten verknüpft sind, um die Latenzzeit und die Anzahl der Amazon S3-Anforderungen zu verringern. Datei-Metadaten werden im Rahmen dieses Scans erfasst; der Dateiinhalt wird nur heruntergeladen, wenn das Objekt gelesen wird.

Ein automatisches Herunterladen vollständiger Objekte oder aller im Bucket vorhandenen Daten durch das Gateway findet nicht statt. Daten werden nur heruntergeladen, wenn ausdrücklich von den Clients darauf zugegriffen wird. Um den Overhead bei der Datenübertragung zu reduzieren, verwendet File Gateway mehrteilige Uploads und Copy-Puts, sodass nur geänderte Daten in Ihren Dateien auf S3 hochgeladen werden.

Für Objekte, die direkt in den S3-Bereich hochgeladen werden, d. h. ohne Verwendung von File Gateway und einer NFS-Freigabe, können Sie Standardbesitz und -berechtigungen konfigurieren.

Für Objekte, die direkt in das S3-Bucket hochgeladen werden, d. h. ohne Verwendung von Amazon S3 File Gateway und ohne eine SMB-Freigabe, werden Metadaten wie Besitzer und Berechtigungen aus dem übergeordneten Ordner des Objekts vererbt. Berechtigungen im Stammverzeichnis der Freigabe sind festgelegt, und Objekte, die direkt unter dem Stammordner erstellt wurden, erben diese festen Berechtigungen. Beachten Sie die Dokumentation zu den Metadaten-Einstellungen von Objekten, die außerhalb des Gateways angelegt wurden.

Sie können mit mehreren NFS-Clients auf ein einziges File Gateway zugreifen. Wie bei allen NFS-Servern kann das gleichzeitige Ändern von mehreren NFS-Clients jedoch auch hier zu unvorhersehbarem Verhalten führen. Koordination auf Anwendungsebene ist erforderlich, um diesbezüglich einen sicheren Ablauf zu gewährleisten.

Nein. Wir empfehlen einen einzigen Autor für Ihr S3-Bucket. Wenn Sie ein Objekt, das zuvor von File Gateway geschrieben wurde, direkt überschreiben oder aktualisieren, resultiert dies in nicht definiertem Verhalten, wenn der Zugriff auf das Objekt über die Dateifreigabe erfolgt. Gleichzeitiges Ändern desselben Objekts (beispielsweise über die S3 API und Amazon S3 File Gateway) kann zu unvorhersehbaren Ergebnissen führen, und wir raten Ihnen von dieser Konfiguration ab.

Wir raten von der Konfiguration mehrerer Autoren in einem einzigen Bucket ab, da dies zu unvorhersehbaren Ergebnissen führen kann. Sie könnten eindeutige Objektnamen oder Präfixe durch Ihren Anwendungs-Workflow verstärken. S3 File Gateway wird Statusmeldungen ausgeben, wenn in einer solchen Einrichtung Konflikte auftreten.

Ja. Sie können mehrere Readers auf einem Bucket haben, das über ein Amazon-S3-File-Gateway verwaltet wird. Sie können eine Dateifreigabe als schreibgeschützt konfigurieren und mehreren Gateways das Lesen von Objekten aus dem selben Bucket erlauben. Außerdem können Sie mithilfe der Storage-Gateway-Konsole, des automatisierten periodischen Cache-Aktualisierungsprozesses oder der RefreshCache-API den Bestand der Objekte aktualisieren, die Ihrem Gateway bekannt sind.

Beachten Sie jedoch, dass, wenn Sie eine Dateifreigabe nicht als schreibgeschützt konfigurieren, Amazon S3 File Gateway diese Readers nicht überwacht oder daran hindert, versehentlich in den Bucket zu schreiben. Sie entscheiden, ob Sie eine Konfiguration mit einem einzigen Autor/mehreren Lesern von Ihrer Anwendung aus beibehalten.

Ja, Sie können die Nutzung Ihrer Dateifreigabe mit Amazon CloudWatch-Metriken überwachen und sich durch CloudWatch Events benachrichtigen lassen, wenn die Dateioperationen beendet sind. Weitere Informationen finden Sie unter Überwachung Ihrer Dateifreigabe.

Wenn Sie Dateien mit Amazon S3 File Gateway in Ihre Dateifreigabe schreiben, werden die Daten zuerst lokal gespeichert und dann asynchron in Ihr S3-Bucket hochgeladen. Sie können Benachrichtigungen über AWS-CloudWatch-Ereignisse anfordern, wenn der Upload einer einzelnen Datei abgeschlossen ist. Diese Benachrichtigungen können als Auslöser für zusätzliche Workflows genutzt werden. Zum Beispiel zum Aufrufen einer AWS Lambda-Funktion oder Amazon EC2 Systems Manager-Automatisierung, die von den derzeit in S3 verfügbaren Daten abhängt. Weitere Informationen finden Sie in der Dokumentation für Datei-Upload-Benachrichtigungen.

Die Datei-Upload-Benachrichtigung bietet eine Benachrichtigung für jede einzelne Datei, die über S3 File Gateway auf Amazon S3 hochgeladen wird. S3-Ereignisbenachrichtigungen bieten Benachrichtigungen, die partielle Datei-Uploads enthalten, so dass aus der S3-Ereignisbenachrichtigung nicht ersichtlich ist, dass der Datei-Upload abgeschlossen ist.

Wenn Sie Dateien mit Amazon S3 File Gateway in Ihre Dateifreigabe schreiben, werden die Daten zuerst lokal gespeichert und dann asynchron in Ihr S3-Bucket hochgeladen. Sie können Benachrichtigungen über Amazon-CloudWatch-Ereignisse anfordern, wenn der Upload eines Arbeitsdateisets abgeschlossen ist. Diese Benachrichtigungen können als Auslöser für zusätzliche Workflows genutzt werden. Zum Beispiel zum Aufrufen einer AWS Lambda-Funktion oder Amazon EC2 Systems Manager-Automatisierung, die von den derzeit in S3 verfügbaren Daten abhängt. Um mehr darüber zu erfahren, lesen Sie bitte die Dokumentation zu Benachrichtigungen über das Hochladen von Arbeitsdateisets.

Ja. Sie können mithilfe der Konsole, des dateisystemgesteuerten Cache-Aktualisierungsprozesses oder der RefreshCache-API den Bestand der Objekte aktualisieren, die Ihrem Amazon S3 File Gateway bekannt sind. Sie erhalten Benachrichtigungen über AWS-CloudWatch-Ereignisse, wenn der RefreshCache-API-Vorgang abgeschlossen wurde. Diese Benachrichtigungen können verwendet werden, um E-Mails mit dem Amazon Simple Notification Service (SNS) zu versenden oder einen lokalen Vorgang mit den aktualisierten Inhalten auszulösen. Weitere Informationen finden Sie in der Dokumentation.

Ja, Sie können das Gateway für den kontoübergreifenden Zugriff auf Buckets verwenden. Weitere Informationen finden Sie in der Dokumentation zur Verwendung der Dateifreigabe für einen kontoübergreifenden Zugriff.

Ja. beim Erstellen Ihrer Dateifreigabe können Sie den Zugriff auf S3-Buckets mit Zahlung durch den Anforderer aktivieren. Als Anforderer übernehmen Sie die Gebühren, die mit dem Zugriff auf Daten von Buckets mit Zahlung durch den Anforderer verbunden sind.

Sie können mehrere Dateifreigaben für einen einzigen S3-Bucket erstellen, indem Sie während des Vorgangs der Dateifreigabe ein S3-Präfix angeben.

Sie können bis zu 50 Freigaben für einen S3-Bucket in einem einzigen Gateway erstellen. Wir beschränken die Anzahl der Dateifreigaben pro Bucket nicht auf mehrere Gateways, aber jedes Gateway ist auf 50 Freigaben beschränkt. Wir empfehlen jedoch, einen einzelnen Autor im Bucket zu verwenden, entweder ein Amazon S3 File Gateway oder einen Client mit Direktzugriff auf S3.

Ja. Sie können den Namen einer Dateifreigabe ändern.

Die maximale Größe einer einzelnen Datei beträgt 5 TB, was auch der maximalen Größe eines einzelnen Objekts in S3 entspricht. Wenn Sie eine Datei schreiben, die größer ist als 5 TB, erhalten Sie die Fehlermeldung "Datei zu groß", und nur die ersten 5 TB der Datei werden hochgeladen.

Das Gateway gibt eine große Zahl (8 EB) als Ihre Gesamtkapazität an. Amazon S3 begrenzt den Gesamtspeicher nicht.

Ja. Ihre Bucket-Richtlinien für Lebenszyklusverwaltung, regionsübergreifende Replikation und S3-Ereignisbenachrichtigung werden direkt auf Objekte angewendet, die über AWS Storage Gateway in Ihrem Bucket gespeichert sind.

Sie können S3-Lebenszyklus-Richtlinien verwenden, um das Speicherkontingent eines Objekts zu verändern oder um alte Objekte oder Objektversionen löschen. Bei Objekten, die durch die Lebenszyklusrichtlinie gelöscht wurden, müssen Sie die regelmäßige Cache-Aktualisierung aktivieren oder die RefreshCache-API aufrufen, damit diese Änderungen für Ihre NFS-Clients berücksichtigt werden.

Wenn Sie einen S3-Bucket verwenden, der das Ziel für die regionsübergreifende Replikation ist, müssen Sie möglicherweise die Funktion zur regelmäßigen Cache-Aktualisierung aktivieren oder die RefreshCache-API verwenden, um sicherzustellen, dass der Gateway-Cache und der S3-Bucket synchronisiert sind.

Wenn S3-Ereignisbenachrichtigungen verwendet werden, erhalten Sie evtl. Ereignisse für unvollständige Dateien, die vom Gateway erstellt wurden, um zu gewährleisten, dass Ihre Daten dauerhaft in S3 gespeichert werden. Unvollständige Dateien können aus mehreren Gründen auftreten. So könnte es z. B. sein, dass für das Gateway Cache freigegeben werden muss oder dass in einer Datei viele Schreiboperationen stattfinden. Diese unvollständigen Dateien sind evtl. nicht anwendungseinheitlich.

Amazon S3 File Gateway unterstützt die SMB-Versionen 2 und 3 sowie die NFS-Versionen 3, 4.0 und 4.1. Wir setzen laufende Tests mit gängigen Backup-Anwendungen fort. Teilen Sie uns über den AWS-Support oder das AWS-Kontoteam mit, mit welchen Anwendungen Sie die Kompatibilität testen möchten.

Nein. Mit Amazon S3 File Gateway können Sie Dateien als Objekte in S3 speichern.

Sie können Amazon S3 File Gateway verwenden, wenn Sie mithilfe von standardmäßigen Dateisystemoperationen auf Objekte als Dateien in S3 zugreifen möchten. Amazon S3 File Gateway bietet außerdem schnellen lokalen Zugriff und effiziente Datenübertragung. Sie können die S3 API verwenden, wenn Ihre Anwendung keine Dateisystemoperationen erfordert und die Datenübertragung direkt verwalten kann.

Lokale Plattenspeicherung auf dem Gateway wird verwendet, um veränderte Daten, die in AWS übertragen werden müssen, vorübergehend aufzunehmen, und um Daten für einen schnellen Lesezugriff lokal zwischenzuspeichern. File Gateway verwaltet automatisch den Cache und behält die Daten mit dem neuesten Zugriff basierend auf Client-Lese- und -Schreibvorgängen bei. Daten werden nur dann aus dem Cache entfernt, wenn Platz zum Speichern verwendeter Daten mit neuerem Datum benötigt wird.

Für maximale Schreibleistung verwendet das Gateway einen Writeback-Mechanismus, bei dem die Daten zuerst auf der Platte bleiben und dann asynchron zu S3 hochgeladen werden. Das Gateway stellt Daten aus dem lokalen Cache bereit, um die Leseleistung zu maximieren. Wenn nicht vorhanden, werden die Daten mithilfe von Bytebereich-GETs effizient und synchron von Amazon S3 abgerufen.

Die Größe des lokalen Caches sollte allgemein für die Arbeitsdaten angepasst sein, auf die Sie mit niedriger Latenz zugreifen müssen. Wenn der Cache zu klein ist, erhöhen sich Leselatenzen, da angeforderte Daten aus S3 abgerufen werden müssen, und Schreibvorgänge können fehlschlagen, wenn es keinen freien Cache-Speicherplatz zum lokalen Speichern von Daten gibt, die noch zu S3 hochgeladen werden müssen.

Sie sollten Ihren Cache gemäß folgender Kriterien bereitstellen:
1. Der Größe Ihres Arbeitsdatensatzes, auf den Sie mit geringer Latenz zugreifen müssen, damit Sie Leselatenzen reduzieren können, indem Sie die Häufigkeit, mit der Daten von S3 angefordert werden, verringern.
2. Der Größe der von Ihren Anwendungen auf das Gateway geschriebenen Dateien.

Kleinere Cache-Platten können zu Leistungseinbußen und Fehlern beim Schreiben führen, wenn kein freier Cache-Speicherplatz zum lokalen Speichern von Daten vorhanden ist, wenn der Upload auf S3 ansteht. Weitere Informationen zum Überwachen Ihrer Cache-Nutzung finden Sie unter Überwachung Ihrer Dateifreigabe in der Dokumentation.

Daten, die aus Ihren Anwendungen oder durch Abruf von Amazon S3 in den Cache geschrieben werden, werden nur dann aus dem Cache entfernt, wenn Speicherplatz für neuere Daten benötigt wird.

Dateien werden unverändert und eindeutig Objekten im Bucket zugeordnet. Dadurch können Sie in S3 direkt auf Ihre Daten zugreifen, ohne das Gateway verwenden zu müssen oder zusätzliche Software zum Rehydrieren Ihrer Daten bereitstellen zu müssen.

Amazon S3 File Gateway nutzt mehrteilige Uploads sowie Put- und Copy-Operationen, damit nur geänderte Daten in S3 hochgeladen werden. Damit kann Datenübertragung reduziert werden. Ein automatisches Herunterladen vollständiger Objekte oder aller im Bucket vorhandenen Daten durch das Gateway findet nicht statt. Daten werden nur heruntergeladen, wenn ausdrücklich vom NFS-Client darauf zugegriffen wird.

File Gateway verwendet die beschleunigten Endpunkte nicht, selbst wenn Ihr Bucket für die S3 Transfer Acceleration konfiguriert ist.

Alle zwischen dem Gateway und dem AWS-Speicher übertragenen Daten werden mithilfe von SSL verschlüsselt. Standardmäßig werden alle in S3 gespeicherten Daten serverseitig mit Amazon S3-Managed Encryption Keys (SSE-S3) verschlüsselt. Für jede Dateifreigabe können Sie optional konfigurieren, ob Sie Ihre Objekte mit AWS KMS-Managed Keys mithilfe von SSE-KMS verschlüsseln möchten. Weitere Informationen finden Sie unter „Encrypting Your Data Using AWS Key Management System“ im Storage Gateway-Benutzerhandbuch, das wichtige Details zur Verwendung des Features enthält.  

Amazon FSx File Gateway optimiert den lokalen Zugriff auf Windows-Dateifreigaben auf Amazon FSx und erleichtert den Benutzern den Zugriff auf Daten von FSx for Windows File Server mit geringer Latenz und unter Erhaltung der gemeinsamen Bandbreite. Benutzer profitieren von einem lokalen Cache für häufig verwendete Daten, auf den sie zugreifen können, was eine schnellere Leistung und eine geringere Datenübertragung ermöglicht. Dateisystemoperationen, wie das Lesen und Schreiben von Dateien, werden alle gegen den lokalen Cache ausgeführt, während Amazon FSx File Gateway geänderte Daten im Hintergrund mit FSx für Windows File Server synchronisiert. Mit diesen Funktionen können Sie alle Ihre lokalen Dateifreigabedaten in AWS auf FSx für Windows File Server konsolidieren und von geschützten, ausfallsicheren und vollständig verwalteten Dateisystemen profitieren.

Viele On-Premises-Desktop-Anwendungen sind latenzempfindlich, was zu Verzögerungen bei Ihren Endbenutzern und einer langsamen Leistung führen kann, wenn diese von entfernten Standorten aus direkt auf Dateien in AWS zugreifen. Außerdem kann der direkte Zugriff einer großen Anzahl von Benutzern auf Daten in der Cloud zu einer Überlastung Ihrer gemeinsam genutzten Bandbreitenressourcen wie AWS-Direct-Connect-Verknüpfungen führen. Mit Amazon FSx File Gateway können Sie Amazon FSx for Windows File Server für diese Arbeitslasten verwenden und Ihren lokalen Speicher durch vollständig verwalteten, skalierbaren und äußerst zuverlässigen Dateispeicher in AWS ersetzen, ohne Ihre Anwendungen oder Ihr Netzwerk zu beeinträchtigen.

Amazon FSx File Gateway bietet einen SMB-Dateiprotokollserver, mit dem sich Clients verbinden können, und einen lokalen Cache der häufig verwendeten Daten, auf den sie mit der gleichen geringen Latenz zugreifen können, die sie auch innerhalb von AWS erfahren würden. Dateisystemoperationen, wie das Lesen und Schreiben von Dateien, werden alle gegen den lokalen Cache ausgeführt, während Amazon FSx File Gateway geänderte Daten im Hintergrund mit Amazon FSx for Windows File Server synchronisiert. Amazon FSx File Gateway trägt außerdem dazu bei, den Umfang der Datenübertragung zu minimieren und gleichzeitig die Nutzung der Netzwerkbandbreite zu AWS zu optimieren.

Um Amazon FSx File Gateway zu verwenden, müssen Sie mindestens ein laufendes Amazon-FSx-Dateisystem haben und sicherstellen, dass Sie entweder über ein VPN oder über eine AWS-Direct-Connect-Verbindung einen lokalen Zugriff auf Amazon FSx for Windows File Server haben. Erste Schritte mit FSx für Windows File Server finden Sie in der Anleitung zur Dokumentation hier. Anschließend beginnen Sie entweder mit dem Herunterladen und Bereitstellen einer virtuellen Amazon-FSx-File-Gateway-VMware-Anwendung oder einer AWS-Storage-Gateway-Hardware-Anwendung in Ihrer lokalen Umgebung. Sobald Amazon FSx File Gateway installiert ist und Sie auf FSx für Windows File Server zugreifen können, können Sie die AWS-Managementkonsole verwenden, um ein FSx-für-Windows-File-Server-Dateisystem anzuhängen. Die AWS-Managementkonsole führt Sie dann durch alle Schritte, die erforderlich sind, um Dateifreigaben lokal zugänglich zu machen.

Nachdem die Dateifreigaben konfiguriert wurden, können Client-Systeme die Dateifreigaben auf Amazon FSx File Gateway durchsuchen und eine Verbindung zu den ausgewählten Amazon-FSx-Dateisystemen herstellen. Wenn die Dateifreigaben verbunden sind, können die Benutzer ihre Dateien lokal lesen und schreiben und gleichzeitig von allen Funktionen profitieren, die auf FSx für Windows File Server verfügbar sind. 

Amazon FSx File Gateway kann für den Zugriff auf Windows-Dateisysteme in allen AWS-Regionen verwendet werden, in denen FSx for Windows File Server angeboten wird.

Die Abrechnung für Amazon FSx File Gateway erfolgt stundenweise. Informationen zu Preisen erhalten Sie auf der Preisseite für AWS Storage Gateway.

Amazon FSx File Gateway unterstützt die Versionen 2.x und 3.x des Server-Message-Block-Protokolls (SMB). SMB wird von Microsoft Windows, MacOS und dem Linux-Betriebssystem unterstützt.

Amazon FSx File Gateway ordnet lokale Dateifreigaben und deren Inhalte auf Dateifreigaben zu, die in Amazon FSx for Windows File Server gespeichert sind. Es besteht eine 1:1-Entsprechung zwischen den entfernten und lokal sichtbaren Dateien und deren Freigaben.

Ja. Sie können sowohl von Amazon FSx File Gateway als auch direkt von Amazon FSx in AWS auf Ihre Dateifreigaben zugreifen; Sie sollten jedoch sicherstellen, dass Dateien jeweils nur von einem einzigen Speicherort geschrieben werden können. In dieser Version vermeidet Amazon FSx File Gateway nicht, dass sich Schreibvorgänge von mehreren Speicherorten so überschneiden, dass Probleme entstehen.

Sie haben die Möglichkeit, Amazon FSx for Windows File Server über eine Remote-Verwaltungsschnittstelle mit allen Tools zu verwalten, die von FSx for Windows File Server bereitgestellt werden.

Ja. Sie können ein Gateway an Freigaben auf bis zu 5 Dateisystemen anhängen, solange diese alle Mitglieder derselben Active-Directory-Domäne sind. Amazon FSx File Gateway wird nur einer einzigen Active-Directory-Domäne beitreten.

Sie können eine virtuelle Maschine bereitstellen, die die Amazon-FSx-File-Gateway-Software auf VMware ESXi, Microsoft Hyper-V oder Linux KVM enthält, oder Sie können Storage Gateway als Hardwaregerät bereitstellen.

Amazon FSx File Gateway wird ein Mitglied der Active-Directory-Domäne, unabhängig davon, ob die AD-Infrastruktur im AWS-Directory-Service gehostet wird oder ob sie vor On-Premises verwaltet wird. Sobald Amazon FSx File Gateway Mitglied der Domäne ist, hat es Zugriff auf alle Benutzer und Richtlinien, die in dieser Domäne zum Zweck der Durchsetzung der Sicherheit festgelegt wurden. Amazon FSx File Gateway verhält sich dann identisch zu jedem Windows Server und erzwingt alle anwendbaren Dateizugriffsrichtlinien auf der Grundlage dessen, was in Active Directory konfiguriert ist. 

Amazon FSx File Gateway verwendet native Windows-Zugriffskontrollen und ist mit allen vorhandenen statischen Zugriffslisten kompatibel, die mit Microsoft Windows funktionieren. Die maximale Größe eines ACL beträgt 64 KB oder ca. 1 820 Einträge zur Zugriffskontrolle. Dies ist identisch mit Windows-Server-Hosts. Die Zugriffskontrollen werden auf dem FSx-Windows-File-Server festgelegt und gespeichert, so dass Sie sie nur einmal erstellen müssen und sie in allen angeschlossenen File-Gateways übernommen werden.

Ja. Amazon FSx File Gateway unterstützt die SMB-Verschlüsselung bis zur neuesten SMB-v3.1.1-Spezifikation, einschließlich AES 128 CCM und AES 128 GCM. Kompatible Clients verbinden sich automatisch mit Verschlüsselung. Zusätzlich verwendet Amazon FSx File Gateway SMB-Verschlüsselung, wenn es mit FSx für Windows File Server in AWS kommuniziert. Sie müssen entweder ein VPN oder eine Direct-Connect-Verbindung zu AWS konfigurieren und entsprechende Richtlinien festlegen, damit SMB-Datenverkehr und Management-Datenverkehr zu AWS durchgelassen werden.

Genau wie Amazon S3 File Gateway erreicht Amazon FSx File Gateway eine Hochverfügbarkeit auf VMware dadurch, dass es eine Serie von kontinuierlichen Zustandsprüfungen gegen die Operation des Gateway durchführt, der an den VMware-Überwachungsservice angeschlossen ist. Während eines Hardware-, Software- oder Netzwerk-Ausfalls löst VMware einen Gateway-Neustart auf einem neuen Host oder auf dem bestehenden Host aus, sofern dieser Host noch funktionsfähig ist. Bei einem Neustart treten für Benutzer und Anwendungen maximal 60 Sekunden Ausfallzeit auf. Verbindungen zum Gateway werden nach einem Neustart automatisch wiederhergestellt, ein manueller Eingriff ist nie nötig. Bei der Neuinitialisierung sendet das Gateway Metriken zurück in die Cloud, um den Kunden einen vollständigen Überblick über das Verfügbarkeitsereignis zu geben. 

Ein Amazon FSx File Gateway mit aktivierter VMware HA und eingerichteter Anwendungsüberwachung entdeckt und erholt sich sowohl von Hardware-, Hypervisor- und Netzwerkausfällen, als auch von Softwareproblemen, die zu Verbindungsausfällen oder zur Unerreichbarkeit von Filesharing führen. 

Amazon FSx File Gateway unterstützt bis zu 50 Freigaben und 500 aktive Client-Sitzungen, die mit Amazon-FSx-File-Gateway-Instances in einer einzigen Instance-Konfiguration verbunden sind.

Im Vergleich zur Lagerung physische Bänder an einem externen Standort erhalten Sie bei der Speicherung virtueller Bänder in AWS mit Tape Gateway mit S3 Glacier Deep Archiv eine Datenbeständigkeit von 99,999999999 %, eine regelmäßige Überprüfung der Daten auf Beständigkeit durch AWS, Datenverschlüsselung, die richtigen Daten bei der Wiederherstellung sowie Kosteneinsparungen. Zunächst werden alle in S3 Glacier Deep Archive gespeicherten virtuellen Bänder über mindestens drei geografisch weiträumig verteilte Availability Zones repliziert und gespeichert. Sie sind mit einer Datenbeständigkeit von 99,999999999 % ausgelegt. Im nächsten Schritt führt AWS regelmäßige Überprüfungen der Datenbeständigkeit aus, um zu bestätigen, dass Ihre Daten gelesen werden können und keine Fehler aufgetreten sind. Im dritten Schritt werden alle in S3 Glacier Deep Archive gespeicherten Bänder unter Verwendung von Standardschlüsseln oder Ihrer KMS-Schlüssel durch S3 Server Side Encryption geschützt. Außerdem vermeiden Sie physische Sicherheitsrisiken, die durch die Tragbarkeit der Bänder entstehen. Im vierten Schritt erhalten Sie im Vergleich zu den Erfahrungen mit der externen Lagerung von Bändern, bei der Sie während der Wiederherstellung ggf. falsche oder defekte Bänder erhalten, mit Tape Gateway stets die richtigen Daten. Schließlich können Sie im Vergleich zur externen Lagerung von Bändern monatliche Speicherkosten einsparen, wenn Sie Ihre Daten in S3 Glacier Deep Archive speichern.

Tape Gateway unterstützt die Speicherklassen S3 Standard, S3 Glacier und S3 Glacier Deep Archive. Die Daten auf Ihren virtuellen Bändern werden in einer virtuellen Bandbibliothek in Amazon S3 gespeichert, wenn die Backup-Anwendung Daten auf Bänder schreibt. Nachdem Sie die Bänder aus der Backup-Anwendung ausgeworfen haben, werden Ihre Bänder in S3 Glacier oder S3 Glacier Deep Archive archiviert.

Die minimale und maximale Größe eines virtuellen Bands, das Sie auf einem Tape Gateway erstellen können, beträgt jeweils 100 GiB und 15 TiB. Bitte beachten Sie, dass Sie nur für die auf jedem Band gespeicherte Datenmenge zahlen und nicht für die Größe des Bands.

Ein einzelnes Tape Gateway kann bis zu 1 500 virtuelle Bänder in der VTL mit einer maximalen Gesamtkapazität von 1 PB enthalten. Die Datenmenge und die Anzahl der virtuellen Bänder, die Sie archivieren können, sind jedoch nicht begrenzt. Sie können auch zusätzliche Tape Gateways bereitstellen, um den Speicher für virtuelle Bänder zu skalieren, die nicht archiviert sind. Weitere Informationen finden Sie in unserer Dokumentation zu Limitierungen in Storage Gateway.

Es gibt keine Begrenzung für die Menge oder Größe virtueller Bänder, die Sie archivieren können.

Sie können ein in S3 Glacier oder S3 Glacier Deep Archive archiviertes Band nach S3 abrufen. Ein in S3 Glacier archiviertes Band wird für gewöhnlich innerhalb von drei bis fünf Stunden auf Basis von Standardabrufmethoden nach S3 abgerufen. Ein in S3 Glacier Deep Archive archiviertes Band wird für gewöhnlich innerhalb von zwölf Stunden auf Basis von Standardabrufmethoden nach S3 abgerufen.

Das virtuelle Band mit Ihren Daten muss in einer Virtual Tape Library gespeichert sein, damit der Zugriff erfolgen kann. Der Zugriff auf virtuelle Bänder in Ihrer Virtual Tape Library erfolgt unmittelbar. Wenn das virtuelle Band, das Ihre Daten enthält, archiviert wird, können Sie das virtuelle Band mithilfe der AWS-Managementkonsole oder der API abrufen. Wählen Sie zuerst das virtuelle Band und anschließend die Virtual Tape Library aus, in die das virtuelle Band geladen werden soll. Sie können Ihre Bänder, die in S3 Glacier und S3 Glacier Deep Archive archiviert wurden, in der Regel nach drei bis fünf Stunden bzw. innerhalb von zwölf Stunden abrufen. Sobald es in der Virtual Tape Library vorhanden ist, können Sie das virtuelle Band in Ihrer Sicherungsanwendung zur Wiederherstellung von Daten verwenden.

Nein. Über Amazon S3- oder Amazon S3 Glacier-APIs ist kein Zugriff auf Daten auf virtuellen Bändern möglich. Über die Tape Gateway-APIs können Sie allerdings Ihre Virtual Tape Library und Ihr Virtual Tape Shelf verwalten.

Wenn Sie neue Bänder über die Storage Gateway-Konsole oder die API erstellen, können Sie als Ziel für den archivierten Speicher S3 Glacier Deep Archive festlegen. Wenn Ihre Backup-Software die Bänder ausgibt, werden sie nach S3 Glacier Deep Archive archiviert. Sie können in S3 Glacier Deep Archive archivierte virtuelle Bänder für gewöhnlich innerhalb von zwölf Stunden auf Basis von Standardabrufmethoden nach S3 abgerufen.

Ja. Tape Gateway unterstützt die Verschiebung Ihrer Bänder in S3 Glacier auf S3 Glacier Deep Archive. Sie können das in Glacier Pool platzierte Band mit der AWS Storage Gateway Console oder API dem Deep Archive Pool zuweisen. Tape Gateway verschiebt das virtuelle Band dann in den Deep Archive Pool, der mit der Speicherklasse S3 Glacier Deep Archive assoziiert ist. Wenn Sie ein Band vor Ablauf von 90 Tagen von S3 Glacier nach S3 Glacier Deep Archive verschieben, fällt eine Gebühr für das Verschieben des Bandes von S3 Glacier nach S3 Glacier Deep Archive und gegebenenfalls eine Gebühr für die vorzeitige Löschung von S3 Glacier an.

Nein, Sie können keine Bänder von S3 Glacier Deep Archive auf S3 Glacier verschieben. Sie können ein Band von S3 Glacier Deep Archive auf S3 abrufen oder es aus S3 Glacier Deep Archive löschen.

Die VTL-Schnittstelle ist mit Sicherungs- und Archivierungsanwendungen kompatibel, die die iSCSI-basierte Bandbibliotheks-Schnittstelle gemäß Branchenstandard verwenden. Eine vollständige Liste der unterstützten Anwendungen für die Datensicherung finden Sie auf der Übersichtsseite zu Storage Gateway.

Alle zwischen dem Gateway und dem AWS-Speicher übertragenen Daten werden mithilfe von SSL verschlüsselt. Standardmäßig werden alle vom Tape Gateway in S3 gespeicherten Daten serverseitig mit von Amazon S3 verwalteten Verschlüsselungsschlüsseln (SSE-S3) verschlüsselt.

Sie können optional die Verschlüsselung auf Bändern mit AWS KMS-Managed Keys über die Storage Gateway-API konfigurieren. Sie können einen der verwalteten Customer Master Keys (CMKs) als KMS-Schlüssel angeben. Der konfigurierte CMK, der zum Verschlüsseln von Banddaten verwendet wird, kann nach der Erstellung nicht geändert werden. Weitere Informationen finden Sie unter „Encrypting Your Data Using AWS Key Management System“ im Storage Gateway-Benutzerhandbuch, das wichtige Details zur Verwendung des Features enthält.

Jedes Volume Gateway kann bis zu 32 Volumes unterstützen. Im Cached-Modus kann jedes Volume bis zu 32 TB bei maximal 1 PB an Daten pro Gateway (32 Volumes, jedes 32 TB groß) betragen. Im Stored-Modus kann jedes Volume bis zu 16 TB bei maximal 512 TB an Daten pro Gateway (32 Volumes, jedes 16 TB groß) betragen. Weitere Informationen finden Sie in unserer Dokumentation zu Limitierungen in Storage Gateway.

Volume Gateways komprimieren die Daten, bevor sie in AWS übertragen und während sie in AWS gespeichert werden. Diese Komprimierung kann die Kosten für Datenübertragung und Speicherung senken. Volume-Storage wird nicht vorab bereitgestellt. Sie zahlen nur für die auf dem Volume gespeicherte Datenmenge und nicht für die Größe des erstellten Volumes.

Ihre Volumen werden in einem Amazon S3-Bucket gespeichert, das vom AWS Storage Gateway Service verwaltet wird. Ihre Volumen sind für E-/A-Vorgänge über AWS Storage Gateway verfügbar. Sie können nicht direkt mithilfe von Amazon S3 API-Aktionen darauf zugreifen. Sie können zeitpunktbezogene Snapshots von Gateway-Volumes erstellen, die als Amazon EBS-Snapshots zur Verfügung gestellt werden. Diese können dann in Storage Gateway- oder EBS-Volumen verwandelt werden. Verwenden Sie File Gateway, um mit Ihren Daten nativ in S3 zu arbeiten.

Alle zwischen dem Gateway und dem AWS-Speicher übertragenen Daten werden mithilfe von SSL verschlüsselt. Standardmäßig werden alle vom Volume Gateway in S3 gespeicherten Daten serverseitig mit von Amazon S3 verwalteten Verschlüsselungsschlüsseln (SSE-S3) verschlüsselt.

Optional können Sie die Verschlüsselung für in AWS auf Volumes gespeicherte Daten mit AWS KMS-Managed Keys über die Storage Gateway-API konfigurieren. Sie können einen der verwalteten Customer Master Keys (CMKs) als KMS-Schlüssel angeben. Der konfigurierte CMK, der zum Verschlüsseln eines Datenträgers verwendet wird, kann nach der Erstellung nicht geändert werden. Weitere Informationen finden Sie unter „Encrypting Your Data Using AWS Key Management System“ im Storage Gateway-Benutzerhandbuch, das wichtige Details zur Verwendung des Features enthält.

Ja. Sie können einen EBS-Snapshot aus einem mit AWS KMS verschlüsselten Volume über die API erstellen. Der EBS-Snapshot wird mit demselben Schlüssel verschlüsselt, der für die Volume-Verschlüsselung verwendet wurde.

Ja. Sie können ein verschlüsseltes Volume aus einem mit KMS verschlüsselten EBS-Snapshot über die API erstellen. Das verschlüsselte Volume kann denselben Schlüssel verwenden, der zur Verschlüsselung des EBS-Snapshots genutzt wurde. Sie können aber auch einen anderen Schlüssel zur Verschlüsselung des Volume angeben.

Sie können zeitpunktbezogene Snapshots Ihrer Volume-Gateway-Volumes als Amazon-EBS-Snapshots erstellen. Sie können einen Snapshot Ihres Volumes als Ausgangspunkt eines neuen Amazon-EBS-Volumes nutzen, das Sie anschließend einer Amazon-EC2-Instance zuordnen können. Durch diesen Ansatz können Sie Daten aus Ihren lokalen Anwendungen in Anwendungen problemlos bereitstellen, die in Amazon EC2 ausgeführt werden, falls Sie bedarfsabhängig zusätzliche Rechenkapazitäten für die Datenverarbeitung oder Ersatzkapazitäten für die Notfallwiederherstellung benötigen.

Bei Cached-Volumes, bei denen Ihre Volume-Daten bereits in Amazon S3 gespeichert werden, können Sie mithilfe von Snapshots Versionen Ihrer Daten beibehalten. Durch diesen Ansatz können Sie gegebenenfalls zu einer früheren Version zurückkehren oder eine zeitpunktbezogene Version als neues Volume wiederverwenden. Sie können spontane oder geplante Snapshots erstellen. Wenn Sie einen neuen Snapshot erstellen, werden nur die Daten gespeichert, die sich seit dem letzten Snapshot geändert haben. Wenn sich beispielsweise bei einem Volume mit einer Datenmenge von 100 GB seit dem letzten Snapshot nur 5 GB geändert haben, werden nur die zusätzlichen 5 GB der Snapshot-Daten in Amazon S3 gespeichert. Wenn Sie einen Snapshot löschen, werden nur die Daten entfernt, die nicht für einen anderen Snapshot benötigt werden.

Bei Stored-Volumes, bei denen Ihre Volume-Daten lokal gespeichert werden, bieten Snapshots dauerhafte, externe Sicherungen in Amazon S3. Sie können ein neues Volume anhand eines Snapshots erstellen, wenn Sie eine Sicherung wiederherstellen müssen. Sie können auch einen Snapshot Ihres Volumes als Ausgangspunkt eines neuen Amazon-EBS-Volumes nutzen, das Sie anschließend einer Amazon-EC2-Instance anfügen können.

Snapshots stellten eine Zeitpunktkopie des Volumes am Anforderungszeitpunkt des Snapshots dar. Sie enthalten alle Informationen, die zum Wiederherstellen Ihrer Daten auf einem neuen Volume erforderlich sind (ab dem Zeitpunkt der Snapshot-Erstellung). Daten, die von Ihrer Anwendung vor der Erstellung des Snapshots auf das Volume geschrieben, aber noch nicht auf AWS hochgeladen wurden, werden in den Snapshot aufgenommen.

Der Snapshot erhält einfach gesagt eine ID und wird in der AWS-Managementkonsole und in der AWS-Befehlszeilenschnittstelle (AWS CLI) sofort angezeigt, hat aber zunächst den Status PENDING. Sobald alle Daten, die vor der Snapshot-Anforderung auf das Volume geschrieben wurden, vom Gateway zu EBS hochgeladen wurden, ändert sich der Status in AVAILABLE. Zu diesem Zeitpunkt können Sie den Snapshot als Grundlage für ein neues Gateway oder EBS Volume verwenden.

Jedem Snapshot wird eine einmalige Kennung zugewiesen, die Sie mithilfe der AWS Management Console einsehen können. Sie können AWS Storage Gateway- oder Amazon EBS-Volumes durch Angabe dieser einmaligen Kennung basierend auf einem beliebigen vorhandenen Snapshot erstellen.

Mithilfe der AWS Management Console können Sie ein neues Volume anhand eines Snapshots erstellen, den Sie in Amazon S3 gespeichert haben. Sie können anschließend dieses Volume als iSCSI-Gerät Ihrem lokalen Anwendungsserver zuordnen.

Bei Cached-Volumes werden Ihre primären Daten in Amazon S3 gespeichert. Wenn Sie anhand eines Snapshots ein neues Volume erstellen, behält Ihr Gateway die Snapshot-Daten in Amazon S3 bei, sodass diese zu den primären Daten für Ihr neues Volume werden.

Da bei Stored-Volumes Ihre primären Daten lokal gespeichert werden, lädt Ihr Gateway beim Erstellen eines neuen Volumes anhand eines Snapshots die Daten im Snapshot auf Ihre lokale Hardware herunter. Dort werden sie zu den Primärdaten für Ihr neues Volume.

Nein, zum Erstellen von Snapshots müssen Sie die Bereitstellung des Volumes nicht aussetzen und es wirkt sich auch nicht auf die Anwendungsleistung aus. Snapshots erfassen jedoch nur Daten, die auf Ihren AWS Storage Gateway-Datenträger geschrieben wurden. Darin sind möglicherweise nicht die Daten enthalten, die lokal von Ihrer Anwendung oder dem Betriebssystem gepuffert wurden.

Sie können für all Ihre Volumes einen Snapshot-Zeitplan einrichten. Sie können sowohl den Zeitpunkt ändern, an dem der Snapshot täglich erfolgt, als auch das Intervall (alle 1, 2, 4, 8, 12 oder 24 Stunden).

Die zum Erstellen eines Snapshots benötigte Zeit hängt weitgehend von der Größe Ihres Volumes und der Geschwindigkeit Ihrer Internetverbindung mit AWS ab. AWS Storage Gateway komprimiert alle Daten vor dem Hochladen und reduziert so die zum Erstellen eines Snapshots benötigte Zeit.

Nein, auf Snapshots kann nur über AWS Storage Gateway und Amazon EBS zugegriffen werden, nicht direkt über die Amazon S3-APIs.

Es gibt keine Obergrenzen hinsichtlich der Anzahl der Snapshots oder der Menge der Snapshot-Daten, die ein einzelnes Gateway erzeugen kann.

Das Verwenden von AWS Backup zum Sichern von Volume-Gateway-Volumes vereinfacht und zentralisiert die Backup-Verwaltung, wodurch der operative Aufwand verringert und die Einhaltung von Compliance-Anforderungen für alle AWS-Ressourcen erleichtert wird. Mit AWS Backup können Sie benutzerdefinierte, geplante Sicherungsrichtlinien festlegen, die Ihren Sicherungsanforderungen entsprechen. Dank AWS Backup können Sie Regeln für die Aufbewahrung und den Ablauf von Sicherungen festlegen, sodass Sie keine benutzerdefinierten Skripte mehr entwickeln oder die zeitpunktbezogenen Sicherungen Ihrer Volume Gateway-Volumes manuell verwalten müssen. Schließlich können Sie Sicherungen über mehrere Volume Gateways und andere AWS-Ressourcen wie EBS-Volumes und RDS-Datenbanken von einer zentralen Ansicht aus verwalten und überwachen.

Sie können AWS Backup verwenden, um entweder einen einmaligen Backup durchzuführen oder einen Sicherungszeitplan für Volume-Gateway-Volumes zu definieren. Die Volume-Backups werden in Amazon S3 als Amazon-EBS-Snapshots gespeichert und in der AWS-Backup-Konsole oder Amazon-EBS-Konsole angezeigt. Die von AWS Backup erstellten Volume-Backups können manuell oder automatisch über die AWS-Backup-Konsole gelöscht werden.

Sie können Ihre Sicherungen entweder von der Storage Gateway-Konsole oder der AWS Backup-Konsole aus verwalten. Wenn Sie die Storage Gateway-Konsole verwenden, haben Sie die Möglichkeit, zur AWS Backup-Konsole zu navigieren, um Ihre Sicherungsplan-Konfiguration abzuschließen oder eine On-Demand-Sicherung durchzuführen. Alternativ können Sie die AWS Backup-Konsole verwenden, um mit der Konfiguration Ihres Sicherungsplans zu beginnen oder eine On-Demand-Sicherung der Volume Gateway-Volumes durchzuführen.

Nein. Alle vorhandenen Volume Gateway Snapshot-Funktionen und Ihre bestehenden Amazon EBS-Snapshots bleiben verfügbar und unverändert. Sie können weiterhin die Storage Gateway-Konsole verwenden, um Volumes aus Ihren EBS-Snapshots zu erstellen, und mit der Amazon EBS-Konsole Ihre Snapshots anzeigen oder löschen.

Ja. Sie können die vorhandenen Snapshot-Funktionen von Volume Gateway weiterhin verwenden, um Amazon EBS-Snapshots zu erstellen und Ihre zuvor erstellten Snapshots für die Wiederherstellung zu verwenden. Der Sicherungsplan von AWS Backup arbeitet unabhängig von den geplanten Snapshots des Volume Gateway und bietet Ihnen eine zusätzliche Möglichkeit, alle Ihre Sicherungs- und Aufbewahrungsrichtlinien zentral zu verwalten.

Ja. AWS Backup sichert KMS-verschlüsselte Volumes in Volume Gateway mit demselben Schlüssel, der für die Volume-Verschlüsselung verwendet wurde.

AWS Backup unterstützt die Sicherung von Volume-Gateway-Volumes innerhalb der gleichen Region, in der AWS Backup ausgeführt wird.

AWS Storage Gateway ist als Hardware-Appliance verfügbar, bei der die Storage-Gateway-Software auf einer validierten Serverkonfiguration vorinstalliert wurde. Sie verwalten die Appliance über die AWS-Konsole.

Die Hardware-Appliance unterstützt Amazon S3 File Gateway mit NFS- und SMB-Schnittstellen, Amazon FSx File Gateway mit SMB, Volume Gateway zwischengespeicherte Volumen mit iSCSI und Tape Gateway mit iSCSI-VTL.

Die Hardware-Appliance vereinfacht die Bereitstellung und Verwaltung von AWS Storage Gateway On-Premises für IT-Umgebungen wie Außenstellen und Abteilungen, die über keine virtuelle Serverinfrastruktur, keine ausreichenden Festplatten- und Speicherressourcen und kein Personal mit Hypervisor-Verwaltungskenntnissen verfügen. Sie vermeiden so den Erwerb weiterer Infrastruktur, die für eine virtuelle Umgebung nötig ist, um die lokale Storage-Gateway-VM-Appliance betreiben zu können.

Es sind zwei Modelle erhältlich, die 5 TB oder 12 TB lokalen SSD-Cache bieten.

Die Hardware-Appliance basiert auf validierten Server-Konfigurationen. Technische Daten finden Sie auf der Produktseite der Storage-Gateway-Hardware-Appliance.

Sie wird in 16 AWS-Regionen unterstützt, darunter USA Ost (Nord-Virginia, Ohio), USA West (Nordkalifornien, Oregon), Kanada (Zentral), Südamerika (São Paulo), Europa (Irland, Frankfurt, London, Paris, Stockholm) und Asien-Pazifik (Mumbai, Seoul, Singapur, Sydney, Tokio).

Sie konfigurieren eine IP-Adresse über die lokale Hardware-Appliance-Konsole und nutzen diese IP-Adresse in der AWS-Storage-Gateway-Konsole, um Ihre Appliance zu aktivieren. Damit wird Ihre Hardware-Appliance mit Ihrem AWS-Konto verknüpft. Sobald die Hardware-Appliance aktiviert ist, erstellen Sie den gewünschten Gateway-Typ, der auf der Hardware-Appliance ausgeführt werden soll. Der ausgewählte Gateway-Typ wird dann auf der Appliance aktiviert. Sie verwalten und nutzen Ihre Storage-Gateway-Hardware-Appliance von der AWS-Konsole aus, ähnlich wie Sie es mit der virtuellen Appliance tun würden. Weitere Informationen finden Sie in der Dokumentation der Hardware-Appliance.

Nein. Die Hardware-Appliance unterstützt jeweils nur ein Gateway.

Ja. Um die Gateway-Art zu ändern, nachdem es auf einer Hardware-Appliance installiert wurde, wählen Sie Gateway entfernen aus der Storage Gateway-Konsole, womit das Gateway und die damit verknüpften Ressourcen gelöscht werden. Danach können Sie ein neues Gateway auf der Hardware-Appliance starten.

Sie können dem 5-TB-Modell mehr Speicherplatz hinzufügen, um die nutzbare lokale Cache-Kapazität auf 12 TB zu erhöhen, indem Sie 5 zusätzliche SSDs zur Appliance hinzufügen. Wenn Sie die Appliance bereits aktiviert und mit Ihrem AWS-Konto verknüpft haben, müssen Sie sie auf Werkseinstellungen zurücksetzen, bevor Sie weiteren Speicher hinzufügen können.

Nein. Sie können nur die SSDs hinzufügen, die beim Hersteller der Appliance verfügbar sind. Diese SSDs sind für die Verwendung in der Storage-Gateway-Hardware-Appliance qualifiziert.

Ja. Die Hardware-Appliance verwendet softwarebasiertes ZFS-RAID und bietet Schutz vor dem Ausfall von Speicherlaufwerken. Das 5-TB-Modell toleriert den Ausfall von 1 SSD und das 12-TB-Modell toleriert den Ausfall von bis zu 2 SSDs.

Storage Gateway erreicht Hochverfügbarkeit dadurch, dass es eine Serie von kontinuierlichen Zustandsprüfungen gegen den Betrieb des Gateway durchführt, der an den VMware Monitoringservice angeschlossen ist. Während eines Hardware-, Software- oder Netzwerk-Ausfalls löst VMware einen Gateway-Neustart auf einem neuen Host oder auf dem bestehenden Host aus, sofern dieser Host noch funktionsfähig ist. Bei einem Neustart treten für Benutzer und Anwendungen maximal 60 Sekunden Ausfallzeit auf. Verbindungen zum Gateway werden nach einem Neustart automatisch wiederhergestellt, ein manueller Eingriff ist nie nötig. Bei der Neuinitialisierung sendet das Gateway Metriken zurück in die Cloud, um den Kunden einen vollständigen Überblick über das Verfügbarkeitsereignis zu geben.

Die Hochverfügbarkeit von Storage Gateway kann derzeit in geclusterten VMware-vSphere-Umgebungen aktiviert werden, in denen VMware HA aktiviert ist und freigegebener Datenträgerspeicher verfügbar ist.

Mit dem Betrieb von Storage Gateway mit aktivierter Integration von Hochverfügbarkeit sind keine Zusatzkosten verbunden.

Ein Storage Gateway mit aktivierter VMware HA und eingerichteter Anwendungsüberwachung entdeckt und erholt sich sowohl von Hardware-, Hypervisor- und Netzwerkausfällen, als auch von Softwareproblemen, die zu Verbindungsausfällen oder zur Unerreichbarkeit von Filesharing, Volumes oder Virtual Tape Library führen.

Ja.

NFS-Clients, die mit File Gateways verbunden sind, können sich während einer Lese- oder Schreiboperation für 60 Sekunden aufhängen, während der Gateway neu startet, und es anschließend erneut versuchen, sofern die Kunden die empfohlenen Einstellungen verwenden. SMB-Clients können das Lesen oder Schreiben einer Datei während eines Neustarts verweigern, je nach den Einstellungen des Clients. Alle iSCSI-Lese- und Schreibvorgänge für Volume Gateway und Tape Gateway bleiben während eines Gateway-Neustarts hängen und werden dann automatisch wiederholt.

Ja. Gateways werden unter Verwendung desselben zugrunde liegenden freigegebenen Speichers neu initialisiert, wobei der lokale Cache und die Upload-Warteschlangen erhalten bleiben

Nein. Gateways werden erneut initialisiert, unter Nutzung desselben zugrunde liegenden freigegebenen Speichers und unter Beibehaltung von lokalem Cache und Upload-Warteschlangen.

Wenn der Gateway mit VMware mit aktivierter VMware HA bereitgestellt ist, können Sie die Neustart-Sensitivität des Storage Gateway VM im VMware-vSphere-Kontrollzentrum einstellen. Der Storage-Gateway-VM-Heartbeat wird verfügbar sein und Ihnen die Möglichkeit geben, das Gateway nach einem bestimmten Timeout automatisch neu zu starten.

VMware HA überwacht die grundlegende Infrastruktur, z. B. Speicher und Netzwerke. Storage Gateway bietet eine ganze Reihe von Zustandschecks, wie zum Beispiel Dateisystemverfügbarkeit, SMB Endpunkt Verfügbarkeit, NFS Endpunkt Verfügbarkeit, und überwacht alle kritischen Operationen des Gateways und stellt damit sicher, dass der ganze Service, und nicht nur die darunter liegende Infrastruktur, permanent für Ihre Nutzer und Anwendungen zur Verfügung stehen.

Ja. Storage Gateway Hochverfügbarkeit kann in der VMware Cloud™ ohne Zusatzanforderungen verwendet werden. In VMware Cloud on AWS ist VMware HA standardmäßig aktiviert und freigegebene Volumes sind verfügbar.

Beim Einrichten eines neuen Gateways für VMware haben Sie die Möglichkeit, HA zunächst zu testen. Sie können auch testen, ob ein bereitgestelltes Gateway HA-fähig ist, indem Sie in der Konsole die Aktion „VMware HA testen“ wählen.

Die AWS Storage Gateway Konsole zeigt während eines Gateway-Neustarts Verfügbarkeitsereignisse in Logtabellen, und Unterbrechungen in Leistungsgrafen.

Ja, wenn Sie die Integration mit CloudWatch konfiguriert haben, stehen Ihnen Verfügbarkeitsereignisse, ausgelöst vom Gateway, über CloudWatch zur Verfügung.

Wenn Sie die Integration mit CloudWatch konfiguriert haben, wird bei erneuter Initialisierung ein CloudWatch-Ereignis ausgelöst. Zusätzlich zeigen Leistungsdiagramme die Betriebsparameter des Gateways, einschließlich der Anzahl an aktiven Sitzungen.

Ja. Administratoren können über die vSphere-Konsole ein Timeout einstellen, das den Service neu startet, wenn das Gateway für die eingestellte Sekundenanzahl unerreichbar ist.

Alle zwischen einer Gateway-Appliance und dem AWS-Speicher übertragenen Daten werden mithilfe von SSL verschlüsselt. Standardmäßig werden alle von AWS Storage Gateway in S3 gespeicherten Daten serverseitig mit Amazon S3-Managed Encryption Keys (SSE-S3) verschlüsselt. Außerdem können Sie optional verschiedene Gateway-Typen konfigurieren, um gespeicherte Daten mit AWS Key Management Service (KMS) über die Storage Gateway-API zu verschlüsseln. Weitere Informationen zum KMS-Support durch File Gateway, Tape Gateway, und Volume Gateway finden Sie weiter unten.

Ja. AWS Storage Gateway ist HIPAA-konform. Wenn Sie ein Business Associate Agreement (BAA) mit AWS abgeschlossen haben, können Sie Storage Gateway zum Speichern, Sichern und Archivieren geschützter Gesundheitsinformationen (PHI) in skalierbaren, kostengünstigen und sicheren AWS-Speicherservices verwenden, einschließlich Amazon S3, Amazon S3 Glacier, Amazon S3 Glacier Deep Archive, Amazon FSx für Windows File Server und Amazon EBS, die ebenfalls HIPAA-konform sind.

Informationen zu HIPAA-konformen Services auf AWS stehen auf unserer Seite zur HIPAA-Compliance zur Verfügung und Sie können hier eine BAA mit AWS abschließen. Die HIPAA-Berechtigung für Storage Gateway gilt für alle Gateway-Typen (File, Volume und Tape).

Ja. AWS Storage Gateway ist basierend auf aktuellen Prüfungen konform mit dem Payment Card Industry Data Security Standard (PCI DSS). Bestandskunden können die Attestation of Compliance (AOC) und PCI-Responsibility-Summary-Berichte in der AWS-Managementkonsole mit AWS Artifact herunterladen. Interessenten können die Berichte beim AWS Sales-Team anfordern.

Ja. AWS Storage Gateway ist FedRAMP-konform mit der Autorisierungsstufe „Hoch“ in den AWS GovCloud (USA)-Regionen und der Autorisierungsstufe „Mittel“ in den AWS-US-Commercial-Regionen. Weitere Informationen finden Sie auf der Seite zur FedRAMP-Compliance von AWS.

S3 File Gateway, Amazon FSx File Gateway, Volume Gateway und Tape Gateway unterstützen FIPS-140-2-konforme Endpunkte.

AWS Storage Gateway unterstützt FIPS 140-2-konforme Endpunkte in den folgenden AWS-Regionen: USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Nordkalifornien), USA West (Oregon), Kanada (Zentral), GovCloud (USA West) und GovCloud (USA Ost).

Eine Liste der für das AWS Storage Gateway verfügbaren FIPS-Endpunkte finden Sie im Referenzhandbuch zu AWS-Storage-Gateway-Endpunkte oder im Benutzerhandbuch von AWS GovCloud (USA).

Nein. Die Hardware-Appliance von AWS Storage Gateway ist nicht FIPS 140-2-konform.

Ja. mithilfe von Prüfprotokollen von File Gateway können Client-Aktivitäten für Ordner und Dateien innerhalb von SMB-Dateifreigaben überwacht werden.

Sie können Prüfprotokolle von File Gateway so konfigurieren, dass sie Benutzeraktivitäten für Ordner und Dateien auf Ebene der Dateifreigabe für jede SMB-Freigabe überwachen.

Prüfprotokolle von File Gateway unterstützen SMB-Freigaben.

Ihnen werden Details zu den folgenden Aktivitäten angezeigt, die für Dateien und Verzeichnisse protokolliert werden: Öffnen, Löschen, Lesen, Schreiben, Umbenennen, Ändern von Berechtigungen und erfolgreiche Dateiaktivität. Benutzerinformationen für jede Aktivität einschließlich Zeitstempel, Active-Directory-Domäne, Benutzername und Client-IP-Adresse werden ebenfalls protokolliert.

Sie können Prüfprotokolle von File Gateway in Amazon CloudWatch aufrufen. Prüfprotokolle können zudem von CloudWatch an ein Amazon-S3-Bucket Ihrer Wahl gesendet werden. Prüfprotokolle können über Amazon S3 mithilfe von Amazon Athena angezeigt werden und zudem zur Analyse innerhalb dieser Tools in SIEM-Anwendungen (Security Information and Event Management) von Drittanbietern exportiert werden.

Ja. bei der manuellen Erstellung neuer virtueller Bänder oder bei der Konfiguration der automatischen Banderstellung in Tape Gateway können Sie den WORM-Bandtyp wählen. Daten auf virtuellen WORM-Bändern können nicht absichtlich oder versehentlich von der Anwendung gelöscht werden. Darüber hinaus verhindert die Tape Gateway Tape Retention Lock-Funktion, dass archivierte virtuelle Bänder für eine bestimmte Zeit oder sogar auf unbestimmte Zeit gelöscht werden können.

Ja, Sie können auch AWS Direct Connect verwenden, um den Durchsatz zu erhöhen und die Netzwerkkosten senken, indem Sie eine dedizierte Netzwerkverbindung zwischen dem lokalen Gateway und AWS herstellen. Bitte beachten Sie, dass AWS Storage Gateway Ihre Internetbandbreite effizient verwendet, um das Hochladen Ihrer On-Premises-Anwendungsdaten in AWS zu beschleunigen.

Ja. Volume und Tape Gateways unterstützen die Konfiguration eines Socket Secure Version 5 (SOCKS5)-Proxy-Servers zwischen Ihrem On-Premises-Gateway und AWS. File Gateway unterstützt die Konfiguration eines HyperText Transfer Protocol (HTTP)-Proxy-Servers.

Ja. Sie können ein Storage Gateway in einem privaten, nicht routing-fähigen Netzwerk bereitstellen, wenn dieses Netzwerk über DX oder VPN mit Ihrer Amazon VPC verbunden ist. Der Datenverkehr im Storage Gateway wird über VPC-Endpunkte geleitet, die von AWS PrivateLink unterstützt werden, eine Technologie, die eine private Verbindung zwischen AWS-Services über Elastic Network-Schnittstellen (ENI) mit privaten IPs in Ihren VPCs ermöglicht. Weitere Informationen zu PrivateLink erhalten Sie in der PrivateLink-Dokumentation. Um AWS PrivateLink for Storage Gateway einzurichten, sehen Sie sich die Dokumentation zu AWS PrivateLink for Storage Gateway an.

Ja, der Service unterstützt PrivateLink für alle Gateway-Typen (File/Volume/Tape).

Ihnen wird jede Stunde in Rechnung gestellt, die Ihr VPC-Endpunkt weiterhin bereitgestellt wird. Für jedes Gigabyte an Daten, die durch den VPC-Endpunkt verarbeitet werden, fallen ebenfalls Datenverarbeitungsgebühren an, unabhängig von Quelle oder Ziel der Datenübertragung.

PrivateLink-fähige Gateways können über die AWS-Konsole aktiviert werden, wenn Ihr Webbrowser sowohl auf das Internet als auch auf Ihr privates Netzwerk zugreifen kann, oder über die CLI in der Region, in der sie sich befinden.

Um File Gateway On-Premises mit PrivateLink und privaten virtuellen Schnittstellen (VIFs) für den Zugriff auf Ihre Amazon-S3-Buckets zu verwenden, müssen Sie einen Amazon-EC2-basierten Proxyserver einrichten. Um über ein privates Netzwerk auf Amazon S3 zugreifen zu können, müssen Sie die Gateway-Endpunkte von S3 verwenden. Diese Endpunkte sind allerdings nicht direkt von lokalen Umgebungen aus erreichbar. Der Proxy-Server ermöglicht den Zugriff über den VPC-Endpunkt für S3 und macht ihn für ein lokales File Gateway zugänglich. Wir empfehlen die Verwendung einer EC2-Instance-Familie, die für die Netzwerkbandbreite optimiert ist.

Nein.

Volume und Tape Gateways verbinden sich direkt mit AWS-Services über den Storage-Gateway-VPC-Endpunkt, ohne dass ein Proxy zu S3 erforderlich ist.

Die Netzwerkschnittstellen der Hardware-Appliance müssen für einen ordnungsgemäßen Betrieb mit öffentlichen AWS-Endpunkten kommunizieren können. Die virtuellen Gateway-VM-Schnittstellen können jedoch so konfiguriert werden, dass sie PrivateLink verwenden und nur mit VPC-Endpunkten kommunizieren.

Das AWS Storage Gateway liegt zwischen Ihren Anwendungen und den Amazon-Speicherservices. Die zu erwartende Leistung hängt von der Host-Plattform (Hardware-Appliance, virtuelle Maschine, Amazon-EC2-Instance) ab, mit der Sie die Storage-Gateway-Software betreiben, sowie von anderen Faktoren. Dazu zählen die Netzwerkbandbreite zwischen Ihrem iSCSI-Initiator oder NFS-Client und dem Gateway, die Geschwindigkeit und Konfiguration der verwendeten lokalen Festplatten, die Konfiguration Ihrer VM, die Größe des lokalen Speichers, der Ihrem Gateway zugeordnet ist, und die Bandbreite zwischen Ihrem Gateway und dem Amazon Speicher. Unsere technische Dokumentation bietet Richtlinien zur leistungsoptimierten Einrichtung Ihrer Umgebung für AWS Storage Gateway.

Um AWS Storage Gateway auf einer virtuellen Maschine oder einer Amazon EC2-Instance zu betreiben, schlagen Sie die Anforderungen im Benutzerhandbuch von AWS Storage Gateway nach. AWS Storage Gateway ist auch als Hardware-Appliance mit vorvalidierten Spezifikationen verfügbar.

Volume- und Tape-Gateways komprimieren Daten bei Übertragung und bei Speicherung, wodurch Übertragungs- und Speicherkosten gesenkt werden können. AWS Storage Gateway lädt nur Daten hoch, die geändert wurden, und minimiert so die über das Internet übertragene Datenmenge.

Ja. Sie können die Netzwerkbandbreite, die vom Gateway zur Datensynchronisierung mit AWS verwendet wird, basierend auf einem Zeitplan für Volume- und Tape-Gateways drosseln. Sie können Wochentag, Uhrzeit und Bandbreitenraten für eingehenden und ausgehenden Datenverkehr angeben.

Sie können Amazon CloudWatch verwenden, um die Leistungsmetriken für Ihr Gateway zu überwachen und Erkenntnisse in Speicher, Bandbreite, Durchsatz und Latenz zu erhalten. Auf diese Metriken können Sie direkt in CloudWatch zugreifen; oder indem Sie den Links in der AWS Storage Gateway Console folgen, die Sie direkt zu den CloudWatch-Metriken für die angezeigte Ressource leiten. Auf den Detail- und Preisseiten für CloudWatch erhalten Sie weitere Informationen.

Sie können Amazon CloudWatch Metriken nutzen, einschließlich CachePercentDirty, CacheHitPercent, CacheFree, und CachePercentUsed. Sie können diese über den Link "Monitoring" auf der Registerkarte mit den Gatewaydetails in der AWS Storage Gateway Console anzeigen.

Sie können Amazon CloudWatch Metriken nutzen, einschließlich CloudBytesUploaded und CloudBytesDownloaded.

Sie können empfohlene Amazon-CloudWatch-Alarme erstellen, wenn Sie ein neues Gateway erstellen oder nachdem Sie ein neues Gateway über die AWS-Storage-Gateway-Konsole erstellt haben. Sie können Alarme für Ihr Gateway auch in der Amazon-CloudWatch-Konsole erstellen.

AWS Storage Gateway stellt regelmäßig wichtige Updates und Software-Patches in Ihrer virtual Machine (VM, virtuelle Maschine) des Gateway bereit. Sie können eine wöchentliche Wartung planen, mit der Sie steuern können, wann diese Updates auf Ihr Gateway angewendet werden. Alternativ dazu können Sie Updates manuell installieren, wenn sie verfügbar sind, entweder über die AWS-Storage-Gateway-Konsole oder -API. Updates sind meist nach wenigen Minuten abgeschlossen. Weitere Informationen finden Sie im Abschnitt Verwaltung von Gateway-Updates in unserer Dokumentation.

3 Elemente sind dafür ausschlaggebend, wie AWS Storage Gateway abgerechnet wird: Speicherung, Anforderungen und Datenübertragung. Detaillierte Informationen zu Preisen erhalten Sie auf der Seite Preise von AWS Storage Gateway.

File Gateway speichert Daten direkt in Amazon S3. Die Abrechnung erfolgt durch Amazon S3 für Objekte, die in Ihrem File-Gateway gespeichert sind, und für davon gestellte Anforderungen. Weitere Informationen zu den Preisen finden Sie auf der Seite mit den Preisen von Amazon S3.

Die Abrechnung erfolgt für die Menge an Volume-Daten und Daten virtueller Bänder, die Sie in AWS speichern. Diese Gebühr wird tageweise umgelegt und variiert je nach Region. Ihnen wird nur der Anteil an Volume- oder virtueller Bandkapazität in Rechnung gestellt, den Sie nutzen, und nicht die bereitgestellte Größe der Ressource. Alle Volume- und Daten virtueller Bänder werden vor Übertragung in AWS durch das Gateway komprimiert, wodurch Ihre Speicherkosten gesenkt werden können. Detaillierte Informationen zu Preisen erhalten Sie auf der Seite Preise von AWS Storage Gateway.

EBS-Snapshots werden von Ihren Storage Gateway Volumes gemacht und durch Amazon EBS gespeichert und abgerechnet. Wenn Sie einen neuen Snapshot erstellen, werden nur die Daten gespeichert, die sich seit dem letzten Snapshot geändert haben, um die Speicherkosten zu reduzieren. Weitere Informationen finden Sie auf der Seite Preise von Amazon EBS.

Wenn Ihr Gateway Daten in AWS schreibt, wird Ihnen eine Flatrate von 0,01 USD pro GB an Daten verrechnet, die in AWS geschrieben werden, bis zu einer monatlichen Höchstrate von 125 USD pro Gateway. Es fällt keine Gebühr für das Lesen von Daten von AWS an. Da das Gateway Cache-Speicherung, Bandbreitenoptimierung und – für Volume und Tape-Gateways – Komprimierungen durchführt, beträgt die in AWS geschriebene Datenmenge möglicherweise weniger als die Datenmenge, die von Ihrer Anwendung in das Gateway geschrieben wird. Sie können die Datenmenge, die von Ihrem Gateway in AWS geschrieben wird, über die zur Verfügung gestellten Amazon CloudWatch-Metriken überwachen, und Sie können Bandbreitenbegrenzungen für Ihr Gateway konfigurieren, um Ihre Kosten zu verwalten.

Es entstehen pauschalierte Kosten von 0,01 USD pro GB Daten auf dem Band, wenn Sie ein virtuelles Band abrufen, das in S3 Glacier gespeichert wurde. Beispielsweise würden für das Abrufen von 5 Bändern mit jeweils 100 GB folgende Kosten anfallen: 5 x 100 GB x 0,01 USD = 5,00 USD.

Wenn ein virtuelles Band innerhalb von drei Monaten nach der Archivierung in S3 Glacier oder innerhalb von sechs Monaten nach der Archivierung in S3 Glacier Deep Archive gelöscht wird, wird Ihnen eine Gebühr für vorzeitiges Löschen in Rechnung gestellt. Wenn die virtuellen Bänder mindestens drei Monate in S3 Glacier oder mindestens sechs Monate in S3 Glacier Deep Archive gespeichert werden, entstehen keine Kosten für das Löschen.

In der Region USA Ost (Nord-Virginia) wird eine umgelegte Gebühr für vorzeitiges Löschen (vor Ablauf von drei Monaten) von 0,012 USD pro GB fällig. Wenn Sie z. B. ein virtuelles Band mit 1 GB Daten einen Monat nach dem Hochladen und Archivieren in S3 Glacier löschen, wird Ihnen eine Gebühr für vorzeitiges Löschen von 0,008 USD berechnet. Wenn Sie dasselbe virtuelle Band mit 1 GB Daten nach zwei Monaten löschen, wird Ihnen eine Gebühr für vorzeitiges Löschen von 0,004 USD berechnet.

In S3 Glacier Deep Archive gespeicherte virtuelle Bänder werden gemäß der Gebühr für die S3 Glacier Deep Archive-Speicherklasse abgerechnet. Die Preise für Tape Gateway können Sie der Website mit den Storage Gateway-Preisen entnehmen.

Die Nutzung und Kosten für virtuelle Bänder, die Sie im Deep Archive Pool speichern, werden als unabhängiger Serviceposten auf Ihrer monatlichen AWS-Rechnung unter AWS Storage Gateway Deep Archive und getrennt von AWS Storage Gateway und den zugehörigen Kosten aufgeführt. Falls Sie jedoch das Tool AWS-Kostenmanagement verwenden, sind die Nutzung und die Kosten für virtuelle Bänder, die Sie im Deep Archive Pool speichern, in den ausführlichen monatlichen Ausgabeberichten enthalten und werden nicht als getrennter Einzelposten aufgeführt.

In der Region AWS USA Ost (Nord-Virginia) wird Ihnen beim Verschieben eines virtuellen, in S3 Glacier archivierten Bands auf S3 Glacier Deep Archive ein Tarif von 0,032 USD pro gespeicherte GB Banddaten in Rechnung gestellt. Wenn Sie zum Beispiel ein in S3 archiviertes Band mit 100 GB auf S3 Glacier Deep Archive verschieben, kostet dies 100 GB x 0,032 USD/GB = 3,20 USD. Wenn Sie ein Band, das weniger als 90 Tage in S3 Glacier archiviert wurde, auf S3 Glacier Deep Archive verschieben, wird Ihnen ebenfalls eine Frühlöschungsgebühr für die Bandspeicherung in S3 Glacier in Rechnung gestellt.

Die Internetdatenübertragung jedes GB, das aus AWS auf Ihr Gateway heruntergeladen wird, wird Ihnen in Rechnung gestellt. Die Datenübertragung beim Hochladen in AWS ist gratis.

In der Fakturierungs- und Kostenverwaltungskonsole wird eine Schätzung der aktuellen monatlichen Nutzung für die einzelnen Services angezeigt, einschließlich AWS Storage Gateway-Volumes und virtuelle Bandlaufwerke. Eine Aufstellung der Nutzung nach einzelnem Volume oder virtuellem Bandlaufwerk finden Sie in den detaillierten Rechnungsberichten. Dort sehen Sie die Nutzung jeder einzelnen Ressource pro Tag.

Die durch das File Gateway für Sie gestellten S3-Anfragen für das Speichern und Abrufen Ihrer Dateien in S3 als Objekte sind kostenpflichtig. Das Gateway legt Daten bis zu der von Ihnen zugeordneten Kapazität an lokalen Platten im Cache ab. Dadurch lassen sich die Kosten für den Datenabruf unter Umständen verringern.

Ihnen werden Standardtarife für Amazon CloudWatch Logs, Amazon CloudWatch Events und Amazon CloudWatch Metrics berechnet, wenn Sie File-Gateway-Prüfprotokolle konfigurieren.

Das Fakturierungssystem arbeitet mit der koordinierten Weltzeit (Coordinated Universal Time, UTC). Der Kalendermonat beginnt um Mitternacht UTC am ersten Tag eines jeden Monats.

Falls nicht anders angegeben, gelten unsere Preise zuzüglich anfallender Steuern und Abgaben, u. a. MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung der Region Asien-Pazifik (Tokio) der japanischen Verbrauchssteuer.

Ja. AWS Premium Support deckt Probleme im Zusammenhang mit der Verwendung von AWS Storage Gateway ab. Auf der Detailseite für AWS Premium Support erhalten Sie weitere Informationen sowie Preisangaben.

Sie können über das Diskussionsforum von AWS Storage Gateway das vorhandene vielfältige Wissen der AWS-Community nutzen.

Kontaktieren Sie den AWS Support, der Software- und Service-Support für AWS Storage Gateway bereitstellt. Der AWS Support koordiniert auch alle Hardware-bezogenen Fälle mit dem Support-Team des Hardware-Herstellers. Wir empfehlen, den AWS Premium Support zu erwerben.

Das Service-Tag für die Hardware-Appliance finden Sie in der Hardware-Ansicht der AWS-Storage-Gateway-Konsole.

Der AWS Support arbeitet mit dem Hardware-Hersteller für den Hardware-Support zusammen. Der Hardware-Support ist beim Kauf Ihrer Appliance mit inbegriffen und bietet 36 Monate Telefon-Support rund um die Uhr, 7 Tage die Woche, sowie Vor-Ort-Service zum Komponentenaustausch ab dem folgenden Werktag.

Die Hardware-Appliance wird mit einer 3-Jahres-Garantie und einem Vor-Ort-Service am nächsten Arbeitstag für den Ersatz von Teilen durch den Hardware-Hersteller geliefert. Informationen zur Garantie finden Sie hier.