SageMaker Auto Scaling trifft auf eine Bereitstellungsbeschränkung, die AWS CDK orchestrieren muss

AWS hat einen Workaround für SageMaker Auto Scaling veröffentlicht, der Endpoint-Updates ermöglicht, die fehlschlagen, solange die Skalierung registriert bleibt. Der Ansatz nutzt AWS CDK, ein Framework zur Definition von Cloud-Infrastruktur als Code, um Änderungen zu koordinieren, die andernfalls manuelle Eingriffe erfordern. Seine Bedeutung liegt in der Lücke, die er schließt: Die gewünschte Infrastruktur zu deklarieren, beschreibt nicht immer die erforderliche Abfolge, um sie zu erreichen.

Der Beitrag vom 23. Oktober beschreibt ein wiederverwendbares Konstrukt, eine paketierte Infrastrukturkomponente, die die Skalierungsregistrierung vorübergehend entfernt und sie nach dem Endpoint-Update wiederherstellt. AWS CloudFormation, der Dienst zur Bereitstellung von Ressourcen aus Vorlagen, bleibt für die Bereitstellung verantwortlich. Custom Resources, Erweiterungen, die anwendungsspezifische Bereitstellungslogik ausführen, übernehmen die Übergänge rund um dieses Update.

Für Platform Engineers liegt der zentrale Konflikt zwischen deklarativer Konfiguration und operativer Abfolge. Eine Vorlage kann einen Endpoint und seine Skalierungseinstellungen korrekt beschreiben, während ein Update dennoch durch ihre Beziehung blockiert wird. Das AWS-Beispiel integriert diese Beziehung in den Bereitstellungsablauf, doch Teams müssen weiterhin Wiederherstellung, Kapazität und Verantwortlichkeiten bewerten.

SageMaker Auto Scaling legt eine Lücke zwischen Konfiguration und Ausführung offen

Die Änderung ist ein veröffentlichtes Orchestrierungsmuster und keine Aufhebung der zugrunde liegenden Update-Beschränkung von SageMaker.

AWS-Beraterin Lauren Eterno beschreibt den Ansatz in einem Konstrukt für Endpoint-Updates. Es ersetzt native Skalierungsressourcen durch benutzerdefinierte Bereitstellungsschritte rund um die Endpoint-Änderung. Laut AWS können dadurch die Endpoint-Konfiguration und Skalierungsparameter innerhalb einer einzigen Bereitstellung geändert werden.

Die Unterscheidung ist wichtig, weil die pauschale Aussage, Skalierung blockiere Endpoint-Updates, eingeordnet werden muss. Die Regeln für Endpoint-Updates von SageMaker nennen Änderungen des Instanztyps ausdrücklich als Fall, der fehlschlägt, solange das Modell registriert bleibt. Sie erlauben jedoch auch, das Modell für eine bereits für die Skalierung konfigurierte Variante zu ändern. Eine Variante ist eine Konfiguration zur Bereitstellung eines Modells innerhalb eines Endpoints.

Diese Ausnahme verhindert eine zu weit gefasste Auslegung der Ankündigung. Teams sollten nicht annehmen, dass jede Modellveröffentlichung eine Aufhebung der Skalierungsregistrierung erfordert. Entscheidend ist, welche Ressourceneigenschaften sich ändern und ob diese Änderungen auf die dokumentierte Beschränkung treffen. Die Bereitstellungsstrategie sollte dieser Unterscheidung folgen.

Betrachten wir einen hypothetischen Empfehlungsdienst, der sein Modell auf einen anderen Instanztyp umstellt. Das Modell selbst könnte unverändert bleiben, doch das Infrastruktur-Update überschreitet eine Grenze, die durch die Skalierungsregistrierung geschützt wird. Ein Engineer, der nur die neue Endpoint-Konfiguration prüft, könnte diese Voraussetzung übersehen.

Das Beispiel behandelt daher ein Lebenszyklusproblem, also die geordneten Übergänge, die zum Erstellen, Aktualisieren und Entfernen von Ressourcen erforderlich sind. Es führt keinen weiteren Skalierungsalgorithmus ein. Sein Wert liegt in der Koordinierung bestehender Vorgänge, damit der Bereitstellungsprozess ihre Voraussetzungen versteht.

Das ist eine sinnvolle Grenze für die Bewertung dieser Nachricht. Ein neues Konstrukt sollte danach beurteilt werden, ob es Infrastrukturänderungen wiederholbar und wiederherstellbar macht. Behauptungen über bessere Inferenzqualität, schnellere Modellausführung oder höhere Skalierungseffizienz würden separate Belege erfordern.

Die Veröffentlichung schafft zudem ein konkretes Prüfziel für Teams, die private Workarounds pflegen. Sie können ihre Skripte mit einer von AWS verfassten Referenz vergleichen, statt allein anhand einer Fehlermeldung zu argumentieren. Das macht die Referenz nicht automatisch für jede Produktionsumgebung geeignet.

Der unmittelbare Druck trifft Teams, deren Release-Prozess davon ausgeht, dass eine gültige Vorlage auch einen gültigen Update-Pfad garantiert. Das Beispiel zeigt, warum der Pfad selbst überprüft werden sollte. Zielzustand und Übergangsverhalten gehören in dieselbe technische Diskussion.

Platform Teams übernehmen die Folgen manueller Eingriffe

Eine erfolgreiche Endpoint-Änderung ist unvollständig, wenn das vorgesehene Skalierungsverhalten nicht wiederhergestellt wurde.

Die stärkste operative Sorge ist die Distanz zwischen Infrastrukturkonfiguration und laufendem Verhalten. Ein Endpoint kann Anfragen beantworten, ohne über die von seinen Verantwortlichen erwartete Skalierungskonfiguration zu verfügen. Eine Release-Prüfung, die auf Anwendungsantworten fokussiert, würde nicht belegen, dass die Infrastruktur für veränderte Nachfrage bereit bleibt.

AWS beschreibt Szenarien manueller Deregistrierung, bei denen die Skalierung entweder ausbleibt oder spätere Ressourcenupdates fehlschlagen. Diese Beispiele offenbaren unterschiedliche Probleme. Ein sichtbarer Bereitstellungsfehler verlangt sofortige Aufmerksamkeit, während fehlende Skalierung einer Prüfung entgehen kann, die sich darauf konzentriert, ob die Anwendung weiterhin antwortet.

Der On-Call-Engineer trägt die Folgen in beiden Fällen. Jemand muss feststellen, welche Änderungen abgeschlossen wurden, welche Ressourcen existieren und was die nächste Bereitstellung versuchen wird. Ohne eine gemeinsame Aufzeichnung hängt die Wiederherstellung davon ab, Aktionen nachzuvollziehen, die außerhalb des normalen Release-Workflows durchgeführt wurden.

Für ein Platform Team ist das ebenso ein Verantwortungsproblem wie ein Tooling-Problem. Anwendungsentwickler können für das Modellverhalten zuständig sein, während Infrastruktur-Engineers die Bereitstellungssteuerung verantworten. Ein beide Bereiche umfassender Workflow benötigt eine explizite Definition des Abschlusses, die keine der Gruppen allein erfüllen kann.

Diese Definition sollte die Serving-Konfiguration und die vorgesehenen Kapazitätskontrollen einschließen. Sie sollte außerdem zwischen Registrierung und Richtlinienzuordnung unterscheiden. Ein skalierbares Ziel, also die registrierte Ressource, deren Kapazität sich ändern kann, und seine Skalierungsrichtlinie stellen zusammenhängende, aber getrennte Teile des Endzustands dar.

Die praktische Konsequenz ist eine umfassendere Release-Abnahmeprüfung. Teams sollten verifizieren, dass der Endpoint die vorgesehene Konfiguration verwendet und dass seine Kapazitätskontrollen der genehmigten Änderung entsprechen. Die Anwendungsintegrität bleibt notwendig, beantwortet jedoch eine andere Frage.

Das ist besonders relevant, wenn eine Hardwareänderung mit überarbeiteten Skalierungseinstellungen einhergeht. Das Release verändert dann sowohl die Ausführung von Anfragen als auch das spätere Kapazitätsverhalten. Die isolierte Prüfung einer der beiden Änderungen lässt ihre Wechselwirkung ungeprüft.

Eine wiederverwendbare Komponente kann diese Verantwortung bündeln. Statt jedes Anwendungsteam daran zu erinnern, eine Abfolge einzuhalten, kann das Platform Team eine gemeinsame Implementierung pflegen. Der Nutzen hängt davon ab, die Komponente als gewartete Infrastruktur mit klaren Verantwortlichkeiten und einem dokumentierten Wiederherstellungsprozess zu behandeln.

Die Dokumentation muss Entscheidungen ebenso wie Befehle festhalten. Engineers, die einen späteren Vorfall untersuchen, müssen wissen, warum die vorübergehende Deregistrierung existiert und welche Annahmen sie rechtfertigen. Eine durchsuchbare Engineering-Wissensdatenbank kann diese Entscheidungen zusammen mit Bereitstellungsnachweisen bewahren.

Die geschäftliche Auswirkung ist Vorhersehbarkeit bei Releases. Eine Infrastrukturänderung, die regelmäßig Eingriffe von Spezialisten erfordert, verursacht bei jeder betroffenen Bereitstellung Koordinationsaufwand. Die Abfolge in Code zu überführen, bietet eine Möglichkeit, diesen Aufwand zu reduzieren – sofern Fehler für die Personen, die sie betreiben, verständlich bleiben.

Diese Einschränkung trennt nützliche Automatisierung von versteckter Komplexität. Das Ziel sollte eine Bereitstellung sein, die ihren Zustand klar erklärt. Manuelle Befehle lediglich in Funktionen zu verschieben, stellt dieses Ergebnis nicht sicher.

Das Konstrukt macht Reihenfolge und Bereitschaft explizit

Der Mechanismus kombiniert eine geordnete Abhängigkeitskette mit Prüfungen, dass jede Voraussetzung tatsächlich nutzbar geworden ist.

Die Beispielimplementierung folgt einer festgelegten Abfolge: Skalierung deregistrieren, den Endpoint aktualisieren, das Ziel registrieren und die Richtlinie anhängen. Die Registrierungsphase wartet, bis der Endpoint InService, seinen betriebsbereiten Status, erreicht. Die Richtlinienphase wartet, bis das registrierte Ziel abgefragt werden kann.

Diese Prüfungen betreffen unterschiedliche Grenzen. Der Endpoint muss für die Registrierung bereit sein, und die Registrierung muss sichtbar werden, bevor die Richtlinie angehängt werden kann. Diese Bedingungen getrennt zu behandeln, macht den Workflow leichter überprüfbar, als anzunehmen, dass eine akzeptierte Anfrage bedeutet, jede abhängige Operation könne fortfahren.

Application Auto Scaling, der AWS-Dienst zur Anpassung der Kapazität unterstützter Ressourcen, dokumentiert diese Sichtbarkeitslücke. Seine Registrierungs-API weist auf Eventual Consistency hin, was bedeutet, dass eine erfolgreiche Änderung Zeit benötigen kann, bevor sie in späteren Anfragen erscheint. Bereitschaftsprüfungen sind daher eine Reaktion auf dokumentiertes Verhalten.

Das Beispiel verwendet asynchrone Vervollständigung, ein Muster, das den Start einer Operation von der Prüfung trennt, ob sie abgeschlossen ist. Das CDK-Provider-Framework ruft einen Completion Handler wiederholt auf, bis er erfolgreich ist oder sein Timeout erreicht. Dadurch wird nicht die gesamte Wartezeit an eine einzige Funktionsausführung gebunden.

Die Referenz konfiguriert Prüfungen alle 30 Sekunden. Sie erlaubt bis zu eine Stunde für die Zielregistrierung und 15 Minuten für die Richtlinienzuordnung. Diese Werte beschreiben die Wartezeiten der Implementierung; sie sind weder zugesicherte Bereitstellungsdauern noch Belege für typische Produktionsleistung.

Der Konfigurationsauslöser ist ebenso wichtig. Eine ConfigHash-Eigenschaft, ein Wert, der die relevante Konfiguration repräsentiert, ändert sich, wenn sich Endpoint- oder Skalierungseinstellungen ändern. Das gibt CloudFormation eine geänderte Custom-Resource-Eigenschaft zur Verarbeitung und bringt die Orchestrierung wieder in das Update ein.

Hier geht das Muster über die Reihenfolge von Abhängigkeiten hinaus. Eine Ordnungsregel allein lässt eine unveränderte Custom Resource nicht erneut laufen. Der Workflow benötigt sowohl einen Ausführungsgrund als auch eine erzwungene Reihenfolge, sobald die Ausführung beginnt.

Das umfassendere CDK-Verhalten zeigt sich in seinem Custom-Resource-Framework. CloudFormation sendet Lebenszyklusereignisse an Provider, und das Framework unterstützt Abschlussprüfungen für zeitaufwändige Vorgänge. Es meldet außerdem Fehler, wenn ein Handler fehlschlägt oder die Wartezeit abläuft.

Für Reviewer sind dies getrennte Verantwortlichkeiten. Der Konfigurationsauslöser bestimmt, wann Arbeit erforderlich ist. Abhängigkeiten bestimmen, wann Arbeit beginnen kann. Abschlussprüfungen bestimmen, wann spätere Arbeit fortfahren kann. Die Wiederherstellungslogik muss anschließend berücksichtigen, was geschieht, wenn der Fortschritt zwischen diesen Grenzen stoppt.

Das daraus resultierende Design ist expliziter als ein Bereitstellungsskript, das Anfragen der Reihe nach absendet und von unmittelbarer Bereitschaft ausgeht. Explizitheit sollte jedoch nicht mit einem Korrektheitsbeweis verwechselt werden. Die Referenz bietet einen überprüfbaren Mechanismus, den Teams anhand ihrer eigenen Betriebsanforderungen bewerten können.

Managed Inference überlässt die Bereitstellungskoordination weiterhin dem Betreiber

Der breitere Vergleich betrifft die Frage, wie Plattformen Verantwortung für den Lebenszyklus offenlegen, und nicht, welcher Anbieter automatische Skalierung anbietet.

Google Cloud dokumentiert ebenfalls konfigurierbare Skalierung für bereitgestellte Vorhersagemodelle. Seine Einstellungen für Inferenz-Autoskalierung umfassen minimale und maximale Replikatanzahlen, wobei Replikate laufende Kopien sind, die ein Modell bedienen. Die Dokumentation unterscheidet in unterstützten Konfigurationen außerdem zwischen erfolgreicher Bereitstellung und vollständiger Kapazitätsbereitschaft.

Dieser Vergleich schafft Kontext, ohne eine Anbieter-Rangfolge zu begründen. Ähnliche Einstellungen bedeuten nicht identische Aktualisierungsbeschränkungen, Fehlerbehandlung oder Bereitstellungssemantik. Das AWS-Beispiel liefert keine Grundlage für die Behauptung, dass eine andere Plattform jedes vergleichbare Koordinationsproblem vermeidet.

Für Unternehmenskäufer geht der hilfreiche Vergleich über die bloße Frage hinaus, ob Skalierung vorhanden ist. Sie sollten fragen, wie Hardwareänderungen mit Kapazitätssteuerungen interagieren, wie Betriebsbereitschaft gemeldet wird und wer die Konfiguration nach einem Fehler wiederherstellt. Diese Fragen verknüpfen Produktfähigkeiten mit dem Aufwand, der für ihren Betrieb erforderlich ist.

Dieselbe Unterscheidung gilt innerhalb einer AWS-Umgebung. Die Definition von Infrastruktur über CDK bietet Entwicklern zwar eine Programmierschnittstelle, die resultierende Bereitstellung folgt jedoch weiterhin dem Verhalten von CloudFormation. Die Sprache zur Beschreibung von Ressourcen hebt Voraussetzungen auf Serviceebene nicht auf.

Deshalb verdient das Beispiel über seine konkrete Implementierung hinaus Aufmerksamkeit. Es macht eine operative Abhängigkeit im Infrastrukturcode sichtbar. Dadurch erhalten Prüfer einen Ort, an dem sie eine Abfolge untersuchen können, die andernfalls über Release Notes, Skripte und individuelle Erfahrungen verstreut bleiben könnte.

Zwischen der Verfügbarkeit von Updates und der Verfügbarkeit von Skalierung besteht ebenfalls eine Grenze. Die Endpoint-Update-API von SageMaker beschreibt, wie Datenverkehr auf eine neue Flotte verlagert wird, während die vorherige außer Betrieb genommen wird. Dieser Serving-Übergang belegt für sich genommen nicht, dass die vorgesehene Skalierungsrichtlinie wiederhergestellt wurde.

Ein Team kann daher getrennte Abnahmekriterien für die Bearbeitung von Anfragen und das Kapazitätsmanagement definieren. Die Anwendung sollte während der Änderung funktionsfähig bleiben, während die Bereitstellung mit den vorgesehenen Skalierungssteuerungen abgeschlossen werden sollte. Keine der beiden Bedingungen sollte als Ersatz für die andere dienen.

Diese Trennung verbessert auch die Incident-Analyse. Wenn Anfragen fehlschlagen, können Engineers den Serving-Übergang untersuchen. Wenn die Kapazität der Nachfrage nicht mehr folgt, können sie den Skalierungsstatus prüfen. Ein Bereitstellungsprotokoll, das diese Ergebnisse unterscheidet, bietet den Verantwortlichen einen klareren Ausgangspunkt.

Für Organisationen, die ihre Inferenzinfrastruktur standardisieren, besteht die Entscheidung darin, diese Koordination in eine gemeinsame Komponente aufzunehmen. Die Alternative besteht darin, jedes Team für das Verständnis derselben Lifecycle-Grenze verantwortlich zu lassen. Eine gemeinsame Komponente bietet Konsistenz, bündelt jedoch auch die Wartungsverantwortung.

Dieser Zielkonflikt braucht einen bewussten Verantwortlichen. Jemand muss Änderungen an der Komponente prüfen, die Kompatibilität mit bestehenden Bereitstellungen gewährleisten und entscheiden, wann ihre Annahmen nicht mehr passen. Wiederverwendbarkeit schafft nur dann organisatorischen Wert, wenn auch das Wartungsmodell gleichermaßen wiederverwendbar ist.

Die Deregistrierung macht die Wiederherstellung zum Teil des Designs

Die Wiederherstellung des Ziels ist notwendig, doch die Produktionsabnahme muss alles abdecken, was die Deregistrierung entfernt.

Die Deregistrierungs-API besagt, dass das Entfernen eines skalierbaren Ziels die zugehörigen Skalierungsrichtlinien und geplanten Aktionen löscht. Geplante Aktionen sind Kapazitätsänderungen, die für bestimmte Zeitpunkte konfiguriert wurden. Damit ist die Deregistrierung ein destruktiver Lifecycle-Vorgang, selbst wenn sie nur vorübergehend beabsichtigt ist.

Dieses Verhalten wirft für bestehende Endpoints unmittelbar eine Kompatibilitätsfrage auf. Wenn eine Organisation geplante Aktionen oder zusätzliche Richtlinien verwendet, sollten Prüfer klären, wie diese Konfigurationen zurückkehren. Das Vorhandensein einer Target-Tracking-Richtlinie, die Kapazität auf einen gewählten Metrikwert ausrichtet, beantwortet diese Frage nicht.

Die dokumentierte Abfolge des Beispiels konzentriert sich auf die Registrierung des Ziels und das Anfügen seiner konfigurierten Richtlinie. Teams sollten nicht daraus schließen, dass jede bereits an einem Endpoint angehängte Skalierungskonfiguration erkannt und rekonstruiert wird. Umfassendere Wiederherstellungsanforderungen benötigen eine explizite Prüfung und Validierung.

Auch die Skalierungslücke verdient Aufmerksamkeit. Das Entfernen der Registrierung bedeutet nicht, dass der Endpoint gelöscht wurde, doch seine bisherigen automatischen Kapazitätssteuerungen fehlen. Betreiber sollten bewerten, welche Nachfrage die Serving-Flotte in diesem Zeitraum bewältigen muss.

Das ist eine workloadspezifische Bewertung. Ein stabiler interner Service und eine öffentliche Anwendung mit unvorhersehbarer Nachfrage stellen unterschiedliche Abnahmebedingungen dar. Die Referenz liefert keine gemessenen Belege für ein akzeptables Unterbrechungsfenster in einem der beiden Fälle.

Kapazitätseinstellungen erfordern nach einer Hardwareänderung eine separate Überprüfung. Die Beibehaltung der bisherigen Richtlinienkonfiguration belegt nicht, dass sie für einen anderen Instanztyp weiterhin geeignet ist. Teams sollten das resultierende Verhalten unter repräsentativer Nachfrage bewerten, bevor sie die Wiederherstellung als operativen Erfolg betrachten.

Fehlertests sollten den Übergangsgrenzen folgen. Prüfer sollten einen Fehler beim Endpoint-Update, einen Registrierungsfehler und einen Fehler beim Anfügen einer Richtlinie untersuchen. Jeder davon hinterlässt eine andere Frage zum tatsächlichen Zustand und zu den für die Wiederherstellung erforderlichen Maßnahmen.

Rollback, also der Prozess der Rückkehr in Richtung der vorherigen Konfiguration nach einem Fehler, benötigt dieselbe Aufmerksamkeit wie die Vorwärtsbereitstellung. Eine Custom Resource nimmt über ihre Handler an diesem Lifecycle teil. Ihre Existenz garantiert nicht, dass jeder nur teilweise abgeschlossene Vorgang sauber rückgängig gemacht wird.

Die CDK-Dokumentation weist ausdrücklich darauf hin, dass ein Ressourcenvorgang fehlschlagen kann, obwohl eine zugrunde liegende Aktion technisch erfolgreich war. Diese Unterscheidung ist bei der Interpretation von Logs wichtig. Ein gemeldeter Fehler sollte eine Prüfung des tatsächlichen Ressourcenstatus auslösen, bevor jemand annimmt, dass die Aktion nie stattgefunden hat.

Die Ressourcenidentität ist ein weiterer Prüfpunkt. CloudFormation verwendet die physische Ressourcenkennung eines Providers, um ein Update von einem Ersatz zu unterscheiden. Teams, die das Beispiel ändern, sollten dieses Verhalten verstehen, bevor sie Kennungsformate oder Bereinigungslogik anpassen.

Diese Aspekte entkräften den Ansatz nicht. Sie definieren die Nachweise, die für eine verantwortungsvolle Einführung erforderlich sind. Eine Orchestrierungskomponente sollte Fehlerzustände sichtbar machen, ausreichend Kontext für die Wiederherstellung bewahren und den Abschluss nicht melden, bevor das beabsichtigte Ergebnis vorliegt.

Die verfügbare Veröffentlichung ist ein technischer Leitfaden, keine unabhängige Zuverlässigkeitsstudie. Sie belegt weder einen produktiven Einsatz noch eine messbare Verringerung von Incidents oder eine universelle Wiederherstellungsgarantie. Ihr stärkster Beitrag ist ein explizites Design, das Betreiber testen können, statt es selbst rekonstruieren zu müssen.

Die nächsten Nachweise sollten aus Updates, Wiederherstellung und nativer Unterstützung stammen

Die nützlichsten Signale sind beobachtbare Engineering-Ergebnisse und nicht weiter gefasste Behauptungen über Automatisierung.

Das erste Signal sind wiederholbare Konfigurationsupdates, nach denen die Skalierung wiederhergestellt ist. In den kommenden Monaten sollten Anwender nach Nachweisen suchen, die Hardwareänderungen und Änderungen an Skalierungseinstellungen abdecken. Erfolgreiche Wiederholung würde die Annahme stärken, dass die Komponente die beabsichtigte Abhängigkeit konsistent erfasst.

Die Nachweise sollten den Endzustand beschreiben, nicht lediglich einen abgeschlossenen Bereitstellungsbefehl. Prüfer benötigen die Bestätigung, dass der Endpoint mit der vorgesehenen Konfiguration läuft und dass das erwartete Ziel sowie die Richtlinie vorhanden sind. Eine fehlende Wiederherstellung würde den praktischen Wert des Musters schwächen, selbst wenn das Serving funktionsfähig bleibt.

Das nächste Signal ist dokumentiertes Verhalten bei gezielt eingebrachten Fehlern. Eine überzeugende Bewertung würde aufzeigen, wo der Workflow angehalten hat, was aktiv blieb und wie die Wiederherstellung ablief. Klare Nachweise zur Wiederherstellung würden das Vertrauen stärker erhöhen als eine weitere erfolgreiche Erstbereitstellung.

Umgekehrt würden Fehler, die undokumentierte Eingriffe über die Konsole erfordern, auf unvollständige operative Arbeit hinweisen. Das würde den Wert der automatisierten Abfolge nicht aufheben, aber die Einführungsentscheidung verändern. Teams müssten diese verbleibende Arbeit in ihrem Release-Prozess berücksichtigen.

Das letzte Signal sind Fortschritte bei nativer Lifecycle-Unterstützung. Beobachten Sie die Dokumentation von SageMaker, CloudFormation und CDK auf Änderungen, die Endpoint-Updates und die Skalierungsregistrierung betreffen. Eine native Behandlung der erforderlichen Abfolge würde den Bedarf an anwendungsseitig gepflegter Orchestrierung verringern.

Bis eine solche Unterstützung verfügbar ist, bietet die Referenz eine konkrete Grundlage für Entscheidungen im Platform Engineering. Sie integriert SageMaker Auto Scaling in den Endpoint-Bereitstellungs-Lifecycle, statt die Wiederherstellung als separate Aufgabe für Betreiber zu behandeln. Ihr Argument für die Einführung hängt davon ab, ob dieser explizite Workflow in der Umgebung, in der er ausgeführt wird, vorhersehbar funktioniert.

Für Teams, die das Konstrukt erwägen, empfiehlt es sich, mit einem Endpoint zu beginnen, dessen Update-Historie und Skalierungskonfiguration bekannt sind. Prüfen Sie die generierte Infrastruktur, identifizieren Sie jede Konfiguration, die die Deregistrierung entfernt, und weisen Sie die Verantwortung für die Wiederherstellung zu. Führen Sie dann ein repräsentatives Update und einen kontrollierten Fehler durch, bevor Sie die Einführung ausweiten. Bewahren Sie die daraus gewonnenen Nachweise bei der Betriebsdokumentation der Komponente auf, damit künftige Releases sowohl die Begründung als auch den Code übernehmen. Die Frage für eine Release-Prüfung ist konkret: Kann das Team nach der Änderung des Endpoints feststellen, dass Serving-, Skalierungs- und Wiederherstellungsverhalten sämtlich seinen Anforderungen entsprechen? Nutzen Sie diesen Maßstab zur Bewertung der SageMaker-Auto-Scaling-Orchestrierung und verlangen Sie, dass die Bereitstellungsnachweise ihn beantworten.