Optimierung AWS S3 Kosten
Tags: AWS, cloud computing, linux, web service
Kategorie Software Engineering | 1 Kommentar »
Seit vielen Jahren nutze ich AWS S3, um meine private Fotosammlung in der Cloud zu sichern. Inzwischen gibt es ein paar zusätzliche S3 Speicheroptionen, um die dafür anfallenden Kosten zu optimieren…
S3 Speicherklassen
Für die Nutzung von S3 fallen primär die Kosten pro Gigabyte ins Gewicht. Aktuell sind das für das Rechenzentrum in Frankfurt (Region eu-central-1) 0,0245 USD pro GB und Monat für die normale Speicherklasse.
Über S3 Speicherklassen steuert man die Verfügbarkeit der Daten. So variiert z.B. das SLA des Service. Auch gibt es Speicherklassen, bei denen die Daten nicht sofort verfügbar sind, sondern erst nach Stunden heruntergeladen werden können. Die Langlebigkeit der Daten ist hingegen bei allen Speicherklassen identisch.
Technisch verwendet Amazon hier sicher unterschiedliche Speichertechnologien. In der Standard Speicherklasse werden die Daten sicherlich auf normalen „Festplatten“ gespeichert.
Bei der Archiv und Deep Access Speicherklasse werden höchstwahrscheinlich die Daten auf Bandlaufwerken gesichert. Greift man dann auf die Daten zu, müssen die erst auf eine Festplatte kopiert werden. Das kann durchaus Stunden dauern, wenn der Bandroboter gerade entsprechend beschäftigt ist.
Neu ist, im Vergleich zu vor 5 Jahren, dass das Verschieben von Festplatte auf Band und zurück nun transparent von Amazon erledigt wird und man nicht selbst eine Lösung mittels S3 Glacier stricken muss.
Tatsächlich werden bei einem Backup die meisten Daten nie wieder gelesen. Zumindest hatte ich in den letzten 6 Jahren keinen Wohungsbrand oder Wohnungseinbruch, der mich gezwungen hätte, das Backup zu nutzen.
S3 Intelligent-Tiering
Um das automatische Verschieben von Dateien (genannt Objekte in AWS-Lingo) zwischen Festplatten und Bandlaufwerken zu nutzen, muss man 2 Dinge tun:
- Objekt die Speicherklasse „S3 Intelligent-Tiering“ zuweisen
- eine „Intelligent-Tiering-Archivkonfigurationen“ aktivieren
Durch den ersten Schritt wird eine Datei nach 30 Tagen auf die erste günstigere Ebene verschoben, falls kein Lesezugriff erfolgte. Allein dieser Schritt halbiert die monatlichen Speicherkosten für das Objekt auf aktuell 0,0135 USD pro GB und Monat.
Mit der „Intelligent-Tiering-Archivkonfigurationen“ steuert man, ab wann eine Datei auf die „Bandlaufwerke“ verschoben werden soll. Hier gibt es nochmals 2 Ebenen und es werden von Amazon jeweils 90 bzw. 180 Tage ohne Lesezugriff als Mindestwerte vorgegeben.
- Archive Access Tier (0,0045 USD pro GB und Monat) – frühestens nach 90 Tagen ohne Leserequest
- Deep Access Tier (0,0018 USD pro GB und Monat) – frühestens nach 180 Tagen ohne Leserequest
Wurden nach einem halben Jahr alle Dateien automatisch auf die „Deep Access Tier“ verschoben, dürften weniger als 10% der ursprünglichen monatlichen Speicherkosten anfallen (falls ich mich nicht verrechnet habe).
S3 Speicherklasse per Bucket Policy erzwingen
Leider kann man keine Speicherklasse für neue Objekte zentral vorgeben, sondern muss diese bei jedem neuen Upload angeben. Damit ich das nicht vergesse, habe ich meine S3 Bucket Policy entsprechend erweitert. Meine aktuelle S3 Bucket Policy erzwingt 3 Einstellungen:
- nur verschlüsselter Zugriff gestattet (DenyUnSecureCommunications)
- alle Objekte müssen S3 Verschlüsselung aktivieren (DenyUnEncryptedObjectUploads)
- nur Speicherklasse Intelligent-Tiering zulassen (DenyNotIntelligentTieringStorageClass)
{
"Version": "2012-10-17",
"Id": "Policy123456789",
"Statement": [
{
"Sid": "DenyUnSecureCommunications",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::S3-BUCKET-ID",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
},
{
"Sid": "DenyUnEncryptedObjectUploads",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::S3-BUCKET-ID/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
},
{
"Sid": "DenyNotIntelligentTieringStorageClass",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::S3-BUCKET-ID/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-storage-class": "INTELLIGENT_TIERING"
}
}
}
]
}Gut ist, dass man inzwischen zentral am Bucket konfigurieren kann, dass es keinen öffentlichen Zugriff auf Objekte geben darf. Gerade diese typische Fehlkonfiguration hat in den letzten Jahren zu riesigen Datenlecks geführt.
Upload mittels AWS CLI
Inzwischen bin ich auf das offizielle AWS CLI umgestiegen und nutze s3cmd nicht mehr. Ich nutze auch inzwischen lokale AWS Profile, da ich mehrere Nutzer habe. Nach der Installation kann man AWS CLI folgendermaßen mit Profil „privat“ einrichten:
aws configure --profile=privatMan muss nun die Access ID und Security Key des gewünschten IAM Nutzers eingeben. Danach kann man folgendermaßen auf das Bucket zugreifen:
aws s3 ls s3://S3-BUCKET-ID --profile=privatDas AWS S3 CLI bietet ein sync Kommando, um z.B. den Bucketinhalt mit einen lokalen Dateibaum abzugleichen.
aws s3 sync ~/bilder-encrypted s3://S3-BUCKET-ID/bilder --sse --delete --storage-class=INTELLIGENT_TIERING --exclude=".encfs6.xml" --profile=privatDie Optionen im Einzelnen:
- –sse – neue Dateien sollen S3 Verschlüsselung nutzen
- –delete – Dateien, die lokal nicht mehr vorhanden sind, sollen auch im Bucket gelöscht werden
- –storage-class – die gewünschte Speicherklasse
- –exclude – die .encfs6.xml Datei habe ich manuell hochgeladen und die soll natürlich nicht durch –delete gelöscht werden
- –profile – welches lokale AWS Profil man nutzen möchte
Im Gegensatz zu s3cmd verwendet AWS S3 CLI keinen Dateihash, sondern lediglich Dateigröße und Änderungsdatum, um festzustellen, ob eine Datei sich verändert hat und neu hochgeladen werden muss. Bis jetzt habe ich aber keinen Unterschied bemerkt.
Am Anfang empfiehlt es sich, die Option –dryrun zu verwenden. Dann passiert nicht wirklich was, sondern die Ausgabe listet lediglich, was passieren würde, also welche Dateien gelöscht bzw. hochgeladen würden.
Das ist gerade bei den ersten Versuchen sinnvoll, da ich mehrere Versuche benötigt habe, um die Pfadangaben richtig zu setzen. Ich will immer nur die Dateien des aktuellen Jahrs, die in einem eigenen Ordner liegen, sichern, da der Abgleich sonst bei bald 100k Dateien zu lange dauern würde.
Dateien zwischen S3 Buckets verschieben
Da ich sowieso schon am Konfigurieren war, habe ich meine gesamten Backup Dateien von Irland nach Frankfurt in ein neues S3 Bucket verschoben. Das Verschieben war denkbar einfach:
aws s3 mv s3://S3-BUCKET-ID-ALT/ s3://S3-BUCKET-ID-NEU/ --recursive --storage-class=INTELLIGENT_TIERING --sse --source-region=eu-west-1 --region=eu-central-1 --profile=privatEin erneuter Upload ist nicht notwendig. Das Kommando führt die Verschiebung direkt auf der Amazon Infrastruktur durch. Die Daten wurden mit ca. 25MB/s verschoben. Das hat bei den inzwischen über 250GB an Daten einen Nachmittag gedauert.
Fazit
Noch kann ich nicht berichten, ob meine Dateien wirklich in günstigere Speicherklassen verschoben werden, da ich durch das Verschieben der Daten in ein neues Bucket auf diese natürlich zugegriffen habe.
Ich reiche aber in 2 Monaten nach, ob sich meine Rechnung zumindest schon mal halbiert hat. Gegen Ende des Sommers sollten die meisten Daten dann sogar in die Deep Access Tier verschoben sein. Mal schauen, ob das klappt.
Update: Insgesamt konnte ich meine AWS S3 Kosten auf ca. 25% des ursprünglichen Werts einstampfen.
[…] Update: Auch nach über 5 Jahren nutze ich die Lösung. Inzwischen gibt es eine gute Lösung, um die Speicherkosten zu optimieren ohne eine Lösung mittels S3 Glacier bauen zu müssen. Alle Details dazu hier: Optimierung AWS S3 Kosten […]