Auswirkung von zukünftigen Preissenkungen bei AWS Reserved Instanzen

Ein Kunde fragte uns gerade, was eigentlich im Falle einer Preisenkung von AWS mit den bereits gebuchten AWS Reserved Instanzen passiert…

Im On-Demand Modell
kostet eine r3.large Linux Instanz in der Region EU-West1 stand heute: 0,195 USD / Stunde.
Bei einem monatlichen 24×7 Betrieb (entspricht ca. 744 h) bedeutet das: 744 h x 0,195 USD = 145,08 USD / Monat.

Im Reserved Instanz-Modell
(Heavy Utilization-Plan) für 1 Jahr kostet eine r3.large Linux Instanz in der Region EU-West1 eine einmalige Vorauszahlung von 698,00 USD und dann einen reduzierten Stundenpreis von 0,043 USD / Stunde.
Somit kostet diese Instanz (mit rechnerisch umgelegter Vorauszahlung) im Monat: (698 USD + (744 h x 0,043 USD * 12)) / 12 = 90,158 USD

Man spart also in diesem Beispiel ca. 38 Prozent, wenn man das Reserved Instanz Modell wählt.

Was passiert bei einer Preissenkung?

Was passiert nun bei einer Preissenkung von Amazon Web Services, die es ja in der Vergangenheit sehr oft gab:

  • Im On-Demand Modell nimmt man daran unmittelbar teil.
  • Im bereits gebuchten Reserved Instanz Modell nimmt man daran leider nicht teil,  denn es gilt weiterhin der bei Kauf der Reserved Instance definierte reduzierte Stundenpreis.

Dennoch lohnen sich Reservered Instanzen rechnerisch auf jeden Fall!

AWS Cloudwatch Logs mit Windows-Instanzen

Ich hatte ja schon in diesem Artikel über den neuen AWS Service Cloudwatch Logs berichtet …

Neben den neuen Agenten für Cloudwatch Logs ist auch im AWS Standard Windows Service EC2Config das neue Cloudwatch Logs standardmässig integriert. Allerdings nur mit der neuesten Version 2.2.5, die man hier herunterladen kann um damit vorhandene Windows EC2-Instanzen upzudaten. Neue EC2-Windows Instanzen bekommen diese Version schon jetzt ausgerollt. (EC2Config-Service: http://aws.amazon.com/developertools/5562082477397515).

CloudwatchLogs-EC2-Config1

Amazon Windows EC2Config Service

(mehr …)

Spezial Git und GitHub Training in Hannover

Unsere Freunde von Thoughtram in Hannover bieten vom 6.-7. September ein super spezial intensiv GitHub Training in Hannover an. Das Training wird mit durchgeführt von Mike Adolphs, auch bekannt als @fooforge on GitHub. Mike ist ein GitHubber und steht auch für alle Spezialfragen rund um das Thema Git und Github zur Verfügung.

Mehr Infos findet Ihr hier: http://thoughtram.io/#trainings

Neuer Service: AWS Cloudwatch Logs

Gestern wurden zahlreiche neue AWS Services zum Thema Mobile vorgestellt … aber irgendwie ist bisher der neue AWS Cloudwatch Log Service dabei ein wenig untergegangen …

AWS Cloudwatch ist bisher als Statistik-Dienst bekannt, der entsprechende Daten von fast allen AWS Ressourcen automatisch sammelt und für 14 Tage speichert und dafür ein Alerting-System als auch grafische Analysetools anbietet.

Cloudwatch Logs wurde gestern vorgestellt und ist bereits für die Virginia Region verfügbar. AWS bietet für Cloudwatch Logs Agenten (Windows, Ubuntu, Amazon Linux) an, die man innerhalb von z.B. EC2-Instanzen installiert. Diese Agenten schicken dann automatisiert definierte Log-Dateien (Apache Logs, etc.) nach AWS Cloudwatch Logs.

In Cloudwatch Logs können diese Log-Dateien nun unlimitiert lange gespeichert werden und es können Alarm-Trigger auf die Inhalte der Log-Dateien definiert werden, so dass man z.B. benachrichtigt wird, wenn in einer Log-Datei eine bestimmte Anzahl von Fehlern überschritten wird.

 

CloudWatch Management Console

Die Preisgestaltung ist wie bei AWS üblich wie immer günstig:

Amazon CloudWatch Logs (Virginia Region)

  • $0.50 per GB ingested
  • $0.03 per GB archived per month

 

Mit AWS Cloudwatch Logs macht nun AWS eigentlich Unternehmen wie Splunk, Loggly direkte Konkurrenz … und ich denke, das aktuelle Featureset von Cloudwatch Logs ist erst der Anfang …

AWS Zertifizierung

Gerade in unseren AWS Trainings werden wir oft gefragt, wie man sich optimal auf die von Amazon Web Services angebotenen Zertifizierungen vorbereiten kann.

Bisher hab es da nur Beispielfragen in einem PDF, siehe z.B. hier.

Seit heute gibt es aber nun endlich auch die Möglichkeit, direkt online einen repräsentativen Kurztest zu machen. Dieser Kurztest kostet 20 USD und beinhaltet 20 Fragen, die 30 Minuten beantwortet werden müssen. Mehr Infos dazu findet man hier.

AWS CloudFront unterstützt nun Multi-Site Hosting

Wurde bisher AWS CloudFront gegen einen Elastic Load Balancer als Origin konnektiert, ging der ursprüngliche Hostname verloren und beim Multi-Domain-Webserver kam als Host-Header lediglich der Name des ELB als Host-Header an.
Siehe auch hier: http://www.aws-blog.de/2013/07/01/cloudfront-elb-und-virtuelle-webserver/

Mit dem heute veröffentlichen neuen CloudFront Release scheint dieses Problem nun endlich gelöst zu sein:

“Multi-Site Hosting – CloudFront can now be configured to pass the Host header along to your origin server so that you can host multiple web sites and have CloudFront cache responses that are specific to each site.”

Mehr Infos dazu findet man hier: http://aws.amazon.com/blogs/aws/enhanced-cloudfront-customization/

AWS Route53: CNAME vs. ALIAS

Der Amazon Web Services DNS-Dienst Route53 ermöglicht nach einer entsprechenden Domänen-Delegation die komplette Verwaltung einer Domäne (A-, MX-, CNAME-Records, etc.).

Neben dem klassischen CNAME-Record gibt es bei AWS Route53 noch eine entsprechende Erweiterung mit dem Namen ALIAS-Record. Wo sind da genau die Unterschiede?

Beide, CNAME- und ALIAS-Records, stellen einen Pointer auf eine andere Adresse dar, bei dem ein zusätzlicher Schritt für entsprechende Auflösung notwendig ist. Der wesentliche Unterschied ist hierbei, wo dieser Schritt und die entsprechende Auflösung stattfindet:

  • Beim CNAME-Record findet dieser zusätzliche Schritt Client-seitig statt. Der DNS-Server gibt lediglich den Wert des CNAME-Records zurück und der Client muss nun in einem zweiten Schritt diesen entsprechend durch eine erneute Anfrage an den DNS-Server in einen A/AAA Record auflösen.
  • Beim ALIAS-Record findet dieser zusätzliche Schritt auf dem DNS-Server (hier AWS Route53) statt. AWS Route53 gibt also direkt nach einem internen Lookup den A/AAAA Record an den Client zurück.

Somit geht die Auflösung eines ALIAS-Records deutlich schneller als die Auflösung eines CNAME-Records.

Dazu kommt noch folgender Vorteil:

  • CNAME-Records können nicht auf eine APEX-Domäne definiert werden.
  • Also kann man bei einem Einsatz einer CloudFront-Distribution oder eines AWS Elastic Load Balancers (beide haben lediglich einen entsprechenden DNS-Namen) nur eine Subdomäne wie www.firma.de via CNAME auf z.B. den Elastic Load Balancer umleiten, für die APEX-Domäne firma.de funktioniert das nicht.
  • Über einen ALIAS-Record von AWS Route53 kann man nun auch die APEX-Domäne direkt auf einen z.B. ELB umlenken.

 

 

 

Präsentationen des AWS Summit Berlin verfügbar

AWS Summit Berlin 2014Am 15. Mai fand in Berlin der AWS Summit 2014 statt.
Auch tecRacer war als Partner bei der größten Veranstaltung der deutschen AWS-Cloud-Computing-Gemeinde dabei und stand im Self Paced Lab für Fragen rund um die Amazon Cloud bereit.

Über 1400 Besucher informierten sich in Berlin über Amazon Web Services und erfuhren in insgesamt 25 Vorträgen alles rund ums Thema Cloudcomputing mit Amazon.
Alle Präsentationen des AWS Summit Berin hat Amazon jetzt auf ihrer Webseite zum Download online gestellt.

Dazu gibt es die Keynote von CTO Dr. Werner Vogels auch als Video:

Erstes Treffen der AWS Usergroup München

AWS User Group MünchenNach Berlin und Stuttgart hat sich nun auch in München eine AWS Usergroup gegründet.

Die Münchner AWS Benutzer-Gruppe verzeichnet auf ihrer Meetup-Seite bereits 47 Mitglieder. Das erste Offline-Treffen der Gruppe soll am Dienstag, den 24. Juni um 20 Uhr stattfinden.

Ort des Geschehens ist der Augustiner Keller Biergarten in der Arnulfstr. 52.


tecRacer wünscht allen Teilnehmern einen geselligen und informativen Abend!

 

Übersicht: AWS Usergroups