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 CloudFront mit eigenen SSL-Zertifikaten

Amazon Web Services CloudFront unterstützt schon seit letztem Jahr eigene SSL-Zertifikate für CloudFront.

Diese kosten 600 USD / Monat, da dafür in jedem CloudFront POP eine IP-Adresse reserviert wird.

Seit heute gibt es eine weitere Option für eigene SSL-Zertifikate, die kostenlos ist:  CloudFront serves your content over HTTPS only to clients that support SNI. Older browsers and other clients that don’t support SNI can’t access your content over HTTPS.

SNI ist hier näher erläutert: http://de.wikipedia.org/wiki/Server_Name_Indication.

Wichtig ist, dass das folgende Systeme das können bzw. nicht können:

Browser

  • Mozilla Firefox 2.0 und neuer
  • Opera 8.0 und später (TLS 1.1 muss aktiviert sein)
  • Internet Explorer ab Version 7 und ab Windows Vista, unter Windows XP wird es selbst mit Internet Explorer 8 nicht unterstützt
  • Google Chrome
  • Safari 3.0 und später (ab OS X 10.5.6, ab Windows Vista)

Browser auf mobilen Systemen

  • Android Browser ab Honeycomb (3.0) auf Tablets und ab Ice Cream Sandwich (4.0) auf Smartphones[1]
  • Safari auf iOS ab iOS 4[2]
  • Mozilla Firefox Mobile
  • Opera (Mini & Mobile) mindestens ab Version 10.1 auf Android

CloudFront, ELB und virtuelle WebServer

Bei Projekten kommt oft die Anforderung, dass eine CloudFront-Distribution gegen einen Elastic-Load-Balancer (ELB) konnektiert, hinter dem wiederum mehrere EC2-Instanzen mit WebServern stehen. Wenn nun auch die WebServer so konfiguriert sind, dass unterschiedliche Domänen von unterschiedlichen virtuellen WebServern bedient werden, beginnt das Drama, denn

  • die CloudFront Distribution überträgt nur den Inhalt des Feldes “Origin Domain Name” als Host-Header an den ELB der dieses dann an die virtuellen WebServer weiterreicht.
  • in dem Feld “Origin Domain Name” steht aber nur der DNS-Name des ELB ….
  • die weiteren Domänen, die man in der CloudFront-Distribution in dem Feld “Alternate Domain Names(CNAMEs)” angeben kann, werden NICHT als Host-Header an den ELB weitergegeben
  • somit können die virtuellen WebServer nicht mehr auf die unterschiedlichen Domänennamen reagieren …

In diesem Artikel http://virtuallyhyper.com/2012/11/cloudfront-with-elb-and-apache-virtualhosts/ ist eine gute Lösung beschrieben, wie man das Problem lösen kann, in dem man für die ELBs entsprechende CNames definiert.

IIS7.5 – gzip-Kompression für CloudFront aktivieren

Amazons CloudFront ist ein guter Service um beispielsweise die Ladezeiten seiner Internetpräsenz weltweit zu verbessern. Um die Ladezeiten weiter zu optimieren lohnt es sich auch über CloudFront die IIS-seitige gzip-Kompression zu nutzen.

Da CloudFront aber aktuell nur gzip-Kompression über HTTP1.0 unterstützt und der IIS7.5 standardmäßig nur über HTTP1.1 gzip-komprimierten Content verteilt, muss eine kleine Anpassung am IIS vorgenommen werden.

(mehr …)

CloudFront Caching

CloudFront ermöglichkeit das weltweite verteilte lokale Caching, damit auf Daten in S3-Buckets oder von Custom HTTP Origins (externe URLs soder Elastic Load Balancer) schneller zugegriffen werden kann.

CloudFront Daten werden standardmäßig 24h in den lokalen Edges gecached. Übersteuern kann man diese, wenn man entsprechende HTTP-Header setzt.

Gerade bei S3-Daten ist wichtig, das jede S3-Datei den HTTP-Header “Cache-Control” = “max-age=Wert in Sekunden” bekommt. Besonders gemein ist, dass man bei den Behaviors der Cloudfron-Distribution

beim Object Caching “customize” einstellen kann und man dann eine Minimum TTL definieren kann. Man schliesst dann folgerichtig (auch beim Lesen der ?-Hilfe), das damit ein fehlender Cache-Control Header bei S3-Dateien gesetzt wird. Nein, es wird nur ein vorhandener überschrieben … also immer auf “use Origin Cache Headers” lassen und dann bei den S3-Dateien die Cache-Header richtig setzten. Kann man mit Tools wie Cloudberry auch einfach für ganz viele Dateien machen …

 

Video HTTP Streaming mit Flash Media Server mit CloudFront

Viele Kunden nutzen als kostenlosen Videoplayer den flashbasierten Player “Flash Media Playback” um damit das HTTP Streaming des Flash Media Servers über CloudFront zu nutzen. Leider zeigt die von Adobe veröffentlichte URL auf eine doch sehr alte Version … und diese hat zahlreiche Probleme mit dem HTTP Streaming (HDS Streaming) … es kommt zu zahlreichen Bufferproblemen …

Der offizielle Link http://www.osmf.org/configurator/fmp/# führt zur Version 1.5x ….

Über diesen Link http://osmf.org/dev/2.0gm/setup.html kommt man zur aktuellen Version 2.x

 

Das in den Screenshots dargestellt Overlay mit der Versionsnummer kann man übrigens abrufen, in dem man unten rechts auf das letzte Icon eine Mausklick mit der rechten Maustaste macht …

grosse Live-Events mit CloudFront HTTP-Streaming und Flash Media Server 4.5

Seit der Version 4.5 des Adobe Flash Media Servers (demnächst ohne Flash im Namen … nur noch Adobe Media Server) wird HTTP-Streaming für Live- und VOD-Szenarien für den Flash Player und iOS Devices unterstützt. Das Gute daran ist, das der Flash Media Server über entsprechende URL Aufrufe die vorhandenen VOD-Videodateien oder einen Live-Stream on-the-fly in das entsprechende HTTP-Streaming Format (HDS oder HLS) konvertiert und ausliefert. Seit neuestem unterstützt Amazon AWS CloudFront auch HTTP-Streaming, so dass sich hier nun die Frage stellt, wie viele concurrent User kann ich mit einem oder zwei Flash Media Server und vorgeschaltetem CloudFront bei z.B. einem Live-Szenario unterstützen, ohne das es zu einer Überforderung der zugrunde liegenden Flash Media Server kommt …

(mehr …)

AWS CloudFront Video-Streaming über RTMP

Mittels CloudFront kann man auch ohne einen Adobe Flash Media Server Videos über das Adobe eigene RTMP Protokoll streamen. Dazu müssen alle Videos in einem S3-Bucket abgelegt werden, dieser S3-Bucket wird dann entsprechend mit CloudFront als Streaming Distribution verbunden.

Über z.B. den Flash Media Playerback Videoplayer von Adobe (http://www.osmf.org/configurator/fmp/#)  kann man dann das Video als Stream über das RTMP Protokoll abrufen. Wichtig ist dabei, dass die URL wie folgt angegeben werden muss:  rtmp://CLOUDFRONT-URL/cfx/st/_definst_/mp4:VIDEONAME.mp4

Das mit dem cfx/st steht ja noch irgendwo in der Dokumentation … aber das mit dem _definst_ hat Amazon AWS glatt vergessen zu dokumentieren …

CloudFront unterstützt als Protokolle RTMP und RTMPE (die leicht verschlüsselte Variante) und verwendet ausschliesslich den Port 1935. Leider wird die getunnelte Version RTMPT nicht unterstützt … schade.

Nachtrag am 6.6.2012: Habe noch mal recherchiert und dann getestet … RTMPT und RTMPTE gehen nun auch und zwar über Port 80 und auch Port 443, war wohl nur eine kleine Störung an dem Tag meines Tests …