Verwaltung von HTTP-Umleitungen
Übersicht
Für Websites ist die Verwaltung von Umleitungen eine häufige Anforderung. Sie wird oft verwendet, um nicht vorhandene URLs umzuleiten (z. B. bei abgelaufenen Kampagnen oder nach Änderungen der Website-Struktur) oder um Inhalte nach Ländern zu lokalisieren. Umleitungen können am Ursprung oder im CDN verwaltet werden. Die Verwaltung von Umleitungen auf CDN-Ebene könnte die Belastung des Ursprungs verringern und die Antwortzeiten verkürzen. In einigen Fällen, z. B. bei statischem Hosting (z. B. S3), können Umleitungen nicht am Ursprung verwaltet werden. Umleitungen auf CloudFront werden mithilfe der Edge-Funktionen verwaltet.
Architektonische Entscheidungen
Umleitungen können je nach Ihren Anforderungen auf unterschiedliche Weise mithilfe von Edge-Funktionen implementiert werden. Berücksichtigen Sie die folgenden Fragen, um die beste Implementierung für Ihr Unternehmen zu entwerfen:
- Wie oft aktualisieren Sie Ihre Umleitungslogik? Eine intensive parallele Nutzung von Umleitungen durch verschiedene Teams erfordert eine aufwändigere Implementierung im Vergleich zu einfacheren, gelegentlichen A/B-Tests.
- Wie viele Umleitungsregeln haben Sie in Ihrer Logik? Die Größe der Umleitungsdatenbank ist ein Faktor, der bei der Bewertung verschiedener Speicheroptionen berücksichtigt werden muss.
- Sind die Umleitungen statisch oder dynamisch (z. B. abhängig vom Land des Benutzers oder von den Gerätefunktionen)? Bei dynamischen Weiterleitungen sollte die Umleitungslogik in einem Kontext ausgeführt werden, in dem alle erforderlichen Parameter zur Verfügung stehen, um die Antwort zu variieren.
- Schreiben Sie die URL für den Benutzer transparent um oder senden Sie eine 3xx-Umleitung?
Weitere Informationen über einige der Implementierungen von Umleitungen mithilfe der Edge-Funktionen von CloudFront finden Sie in diesem praktischen Workshop. Im folgenden Abschnitt werden wir zwei gängige Implementierungen der Umleitungsverwaltung mit CloudFront vorstellen.
Häufige Anwendungsfälle
Statische HTTP-Umleitungen
Wenn Sie HTTP-Umleitungen mit wenigen Regeln implementieren möchten, die sich selten ändern, konfigurieren Sie eine CloudFront-Funktion für das Betrachter-Anfrageereignis, wobei die Umleitungslogik in den Funktionscode eingebettet ist. Wenn sich die Umleitungslogik weiterentwickelt, können Sie den Funktionscode aktualisieren und die neue Logik wird innerhalb von Sekunden auf Benutzer angewendet.
Zum Beispiel sendet die folgende CloudFront-Funktion, die für das Betrachter-Anfrageereignis konfiguriert ist, eine 3xx-HTTP-Antwort an Benutzer aus ausgewählten Ländern (Spanien und VAE), um sie auf die lokale Version einer Einzelseitenanwendung umzuleiten (z. B. https://example.com/ -> https://example.com/es/). Damit dies funktioniert, müssen Sie den Header cloudfront-viewer-country in die Richtlinie für Ursprungsanfragen aufnehmen. Sie weist CloudFront an, diesen Header im Ereignisobjekt der CloudFront-Funktion verfügbar zu machen, das von Ihrer Funktionslogik verwendet wird. Beachten Sie, dass in diesem Beispielcode der Benutzer basierend auf seinem Land umgeleitet wird, es sei denn, er fragt ausdrücklich nach einer anderen Länderversion der SPA.
function handler(event) {
var request = event.request;
var headers = request.headers;
var host = request.headers.host.value;
var supported_countries = ['ie','ae', 'es']; // countries in which you'd like to serve a localized version of your Single Page Application
var defaultCountryIndex = 0; // default country index in the support_countries array. here it is 'ie'
if ((supported_countries.includes(request.uri.substring(1,3))) && ((request.uri.substring(3,4) === '/') || (request.uri.length === 3))) {
// If one of the supported country codes is included in the path (e.g. /es/about) then add index.html when needed to the reauest
return requestWithIndexHTML(request);
} else if ((headers['cloudfront-viewer-country']) && (headers['cloudfront-viewer-country'].value.toLowerCase() !== supported_countries[defaultCountryIndex])){
// Otherwise if the user reauest is coming from one of the supported countries except the default one, then redirect to country specific version (e.g. /about -> /es/about)
var response = {
statusCode: 302,
statusDescription: 'Found',
headers: { location: { value: `https://${host}/${headers['cloudfront-viewer-country'].value.toLowerCase()}${request.uri}` } },
};
return response;
} else {
// Otherwise send rewrite the request to the default country path, add index.html if needed and return
request.uri = '/'+supported_countries[defaultCountryIndex] + request.uri;
return requestWithIndexHTML(request);
}
}
// Add index.html to SPA path when needed
function requestWithIndexHTML(request) {
if (request.uri.endsWith('/')) {
request.uri += 'index.html';
} else if (!request.uri.includes('.')) {
request.uri += '/index.html';
}
return request;
}Massen-HTTP-Umleitungen
CloudFront-Funktion ist auch in der Lage, mithilfe von CloudFront KeyValueStore größere Umleitungszuordnungen zu unterstützen, die die maximale Funktionsgröße von 10 KB überschreiten. Sie könnten beispielsweise die URIs, mit denen Sie einen Abgleich durchführen möchten, in den Schlüsseln und die Weiterleitungs-URLs im Wert speichern. Die im Ereignisobjekt der Betrachter-Anfrage verfügbare URI kann auf einen passenden URI ausgewertet werden. Wenn eine in den Schlüsseln vorhanden ist, kann Ihre Funktion eine 3xx-Umleitung mit dem zugehörigen Wert zurückgeben.
Die Verwendung von KeyValueStore hat außerdem den Vorteil, dass sich regelmäßig ändernde Daten von Ihrem Code entkoppelt werden. Der KeyValueStore eignet sich hervorragend als globaler (jeder PoP), Lese- und Schlüsselwert-Datenspeicher mit niedriger Latenz in großem Maßstab (Millionen von Anfragen pro Sekunde).
Erweiterte Anforderungen für HTTP-Umleitungen
Eine auf Lambda@Edge basierende Lösung eignet sich besser für fortgeschrittene Umleitungsanforderungen, die durch die maximale Größe (5 MB) von KeyValueStore oder die Änderungsgeschwindigkeit von wenigen API-Aufrufen pro Sekunde nicht erfüllt werden können. Ein Beispielszenario wäre, wenn viele verschiedene Marketingteams täglich Hunderttausende Kampagnenumleitungen aktualisieren.
Bei dieser Architektur wird eine Lambda@Edge-Funktion, die für das Ereignis der Ursprungsanfrage konfiguriert ist, bei jedem Fehler im Cache ausgeführt, um mit einem externen Regelspeicher wie S3 oder DynamoDB zu prüfen, welche Umleitungsregel anzuwenden ist. Die Regeln werden direkt im ausgewählten Speicher verwaltet. Darüber hinaus besteht die Möglichkeit, eine einfache Benutzeroberfläche zu erstellen, um die Verwaltung zu erleichtern. Ein Beispiel für diese Architektur mit einem S3-basierten Speicher und einer authentifizierten Oberfläche für die Verwaltung wird in diesem Blog beschrieben.
