

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Optimierung der Kosten von Amazon Keyspaces-Tabellen
<a name="bp-cost-optimization"></a>

In diesem Abschnitt werden bewährte Methoden zur Optimierung der Kosten für Ihre vorhandenen Amazon Keyspaces-Tabellen beschrieben. Sie sollten sich die folgenden Strategien zur Kostenoptimierung ansehen, um herauszufinden, welche davon Ihren Anforderungen am besten entspricht, und sie iterativ angehen. Jede Strategie bietet einen Überblick darüber, was sich auf Ihre Kosten auswirken könnte, wie Sie nach Möglichkeiten zur Kostenoptimierung suchen können, sowie präskriptive Anleitungen zur Implementierung dieser bewährten Verfahren, um Ihnen beim Sparen zu helfen.

**Topics**
+ [Auswerten Ihrer Kosten auf Tabellenebene](CostOptimization_TableLevelCostAnalysis.md)
+ [Bewerten Sie den Kapazitätsmodus Ihrer Tabelle](CostOptimization_TableCapacityMode.md)
+ [Evaluieren Sie die Application Auto Scaling Scaling-Einstellungen Ihrer Tabelle](CostOptimization_AutoScalingSettings.md)
+ [Identifizieren Sie Ihre ungenutzten Ressourcen, um die Kosten in Amazon Keyspaces zu optimieren](CostOptimization_UnusedResources.md)
+ [Bewerten Sie Ihre Tabellennutzungsmuster, um Leistung und Kosten zu optimieren](CostOptimization_TableUsagePatterns.md)
+ [Auswerten Ihrer bereitgestellten Kapazität, um eine angemessene Bereitstellung zu erzielen](CostOptimization_RightSizedProvisioning.md)

# Auswerten Ihrer Kosten auf Tabellenebene
<a name="CostOptimization_TableLevelCostAnalysis"></a>

Mit dem Cost Explorer Explorer-Tool im AWS-Managementkonsole können Sie die Kosten nach Typ aufgeschlüsselt anzeigen, z. B. Lese-, Schreib-, Speicher- und Backup-Gebühren. Sie können diese Kosten auch nach Zeitraum zusammengefasst sehen, beispielsweise die Kosten für einen Monat oder einen Tag.

Eine häufige Herausforderung bei Cost Explorer besteht darin, dass Sie die Kosten nur einer bestimmten Tabelle nicht einfach überprüfen können, da Sie mit Cost Explorer nicht nach den Kosten einer bestimmten Tabelle filtern oder gruppieren können. Sie können die metrische **Größe der fakturierbaren Tabelle (Byte)** jeder Tabelle in der Amazon Keyspaces-Konsole auf der Registerkarte **Monitor** der Tabelle einsehen. Wenn Sie mehr kostenbezogene Informationen pro Tabelle benötigen, erfahren Sie in diesem Abschnitt, wie Sie mithilfe von [Tagging](tagging-keyspaces.md) eine Kostenanalyse für einzelne Tabellen im Cost Explorer durchführen können.

**Topics**
+ [So zeigen Sie die Kosten einer einzelnen Amazon Keyspaces-Tabelle an](#CostOptimization_TableLevelCostAnalysis_ViewInfo)
+ [Standardansicht von Cost Explorer](#CostOptimization_TableLevelCostAnalysis_CostExplorer)
+ [So verwenden Sie Tabellen-Tags in Cost Explorer](#CostOptimization_TableLevelCostAnalysis_Tagging)

## So zeigen Sie die Kosten einer einzelnen Amazon Keyspaces-Tabelle an
<a name="CostOptimization_TableLevelCostAnalysis_ViewInfo"></a>

In der Konsole finden Sie grundlegende Informationen zu einer Amazon Keyspaces-Tabelle, darunter das Primärschlüsselschema, die Größe der fakturierbaren Tabelle und kapazitätsbezogene Kennzahlen. Sie können die Größe der Tabelle verwenden, um die monatlichen Speicherkosten für die Tabelle zu berechnen. Zum Beispiel 0,25\$1 pro GB im Osten der USA (Nord-Virginia) AWS-Region.

Wenn die Tabelle den Modus für bereitgestellte Kapazität verwendet, werden auch die aktuellen Einstellungen für die Lesekapazitätseinheit (RCU) und die Schreibkapazitätseinheit (WCU) zurückgegeben. Sie können diese Informationen verwenden, um die aktuellen Lese- und Schreibkosten für die Tabelle zu berechnen. Beachten Sie, dass sich diese Kosten ändern können, insbesondere wenn Sie die Tabelle mit der automatischen Skalierung von Amazon Keyspaces konfiguriert haben.

## Standardansicht von Cost Explorer
<a name="CostOptimization_TableLevelCostAnalysis_CostExplorer"></a>

Die Standardansicht im Cost Explorer enthält Diagramme, in denen die Kosten der verbrauchten Ressourcen, z. B. Durchsatz und Speicherplatz, dargestellt werden. Sie können diese Kosten nach Zeitraum gruppieren, z. B. nach Gesamtkosten nach Monat oder Tag. Die Kosten für Speicher, Lese- und Schreibvorgänge und andere Kategorien können ebenfalls aufgeschlüsselt und verglichen werden.

![\[Bild, das die Kosten der verbrauchten Ressourcen in der Cost-Explorer-Ansicht zeigt.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png)


## So verwenden Sie Tabellen-Tags in Cost Explorer
<a name="CostOptimization_TableLevelCostAnalysis_Tagging"></a>

Standardmäßig bietet der Cost Explorer keine Zusammenfassung der Kosten für eine bestimmte Tabelle, da er die Kosten mehrerer Tabellen zu einer Summe zusammenfasst. Sie können jedoch [AWS -Ressourcen-Tagging](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) verwenden, um jede Tabelle mit einem Metadaten-Tag zu identifizieren. Tags sind Schlüssel-Wert-Paare, die Sie für eine Vielzahl von Zwecken verwenden können, z. B. um alle Ressourcen zu identifizieren, die zu einem Projekt oder einer Abteilung gehören. Weitere Informationen finden Sie unter [Arbeiten mit Tags und Labels für Amazon Keyspaces-Ressourcen](tagging-keyspaces.md).

In diesem Beispiel verwenden wir eine Tabelle mit dem Namen. **MyTable**

1. Setze ein Tag mit dem Schlüssel von **table\$1name** und dem Wert von. **MyTable**

1. [Aktivieren Sie das Tag in Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) und filtern Sie dann nach dem Tag-Wert, um einen besseren Einblick in die Kosten der einzelnen Tabellen zu erhalten.

**Anmerkung**  
Es kann ein oder zwei Tage dauern, bis das Tag in Cost Explorer angezeigt wird.

Sie können Metadaten-Tags selbst in der Konsole oder programmgesteuert mit CQL, dem oder dem AWS CLI SDK festlegen. AWS Überlegen Sie sich, im Rahmen des neuen Tabellenerstellungsprozesses Ihrer Organisation die Festlegung eines **table\$1name**-Tags zu erfordern. Weitere Informationen finden Sie unter [Kostenverteilungsberichte mithilfe von Tags für Amazon Keyspaces erstellen](CostAllocationReports.md).

# Bewerten Sie den Kapazitätsmodus Ihrer Tabelle
<a name="CostOptimization_TableCapacityMode"></a>

Dieser Abschnitt bietet einen Überblick darüber, wie Sie den geeigneten Kapazitätsmodus für Ihre Amazon Keyspaces-Tabelle auswählen. Jeder Modus ist auf die Anforderungen einer anderen Workload abgestimmt, sowohl was die Reaktionsfähigkeit auf Durchsatzänderungen, als auch was die Abrechnung der Nutzung anbelangt. Sie müssen diese Faktoren bei Ihrer Entscheidung abwägen.

**Topics**
+ [Verfügbare Tabellenkapazitätsmodi](#CostOptimization_TableCapacityMode_Overview)
+ [Fälle, in denen der On-Demand-Modus ausgewählt werden sollte](#CostOptimization_TableCapacityMode_OnDemand)
+ [Fälle, in denen der Modus bereitgestellter Kapazität ausgewählt werden sollte](#CostOptimization_TableCapacityMode_Provisioned)
+ [Zusätzliche Faktoren, die bei der Auswahl eines Tabellenkapazitätsmodus zu berücksichtigen sind](#CostOptimization_TableCapacityMode_AdditionalFactors)

## Verfügbare Tabellenkapazitätsmodi
<a name="CostOptimization_TableCapacityMode_Overview"></a>

Wenn Sie eine Amazon Keyspaces-Tabelle erstellen, müssen Sie entweder den Modus „On-Demand-Kapazität“ oder „Bereitgestellte Kapazität“ wählen. Weitere Informationen finden Sie unter [read/write Kapazitätsmodi in Amazon Keyspaces konfigurieren](ReadWriteCapacityMode.md).

**On-Demand-Kapazitätsmodus**  
Der On-Demand-Kapazitätsmodus ist so konzipiert, dass Sie die Kapazität Ihrer Amazon Keyspaces-Tabelle nicht mehr planen oder bereitstellen müssen. In diesem Modus bearbeitet Ihre Tabelle Anfragen sofort, ohne dass Ressourcen nach oben oder unten skaliert werden müssen (bis zum Doppelten des vorherigen Spitzendurchsatzes der Tabelle). 

On-Demand-Tabellen werden abgerechnet, indem die Anzahl der tatsächlichen Anfragen mit der Tabelle verglichen wird. Sie zahlen also nur für das, was Sie tatsächlich nutzen, und nicht für das, was bereitgestellt wurde.

**Modus bereitgestellter Kapazität**  
Der Modus für bereitgestellte Kapazität ist ein traditionelleres Modell, bei dem Sie entweder direkt oder mit Hilfe von Application Auto Scaling definieren können, wie viel Kapazität die Tabelle für Anfragen zur Verfügung hat. Da zu jedem Zeitpunkt eine bestimmte Kapazität für die Tabelle bereitgestellt wird, basiert die Abrechnung auf der bereitgestellten Kapazität und nicht auf der Anzahl der Anforderungen. Eine Überschreitung der zugewiesenen Kapazität kann auch dazu führen, dass die Tabelle Anfragen ablehnt und die Benutzererfahrung der Benutzer Ihrer Anwendung beeinträchtigt.

Der Modus „Bereitgestellte Kapazität“ erfordert ein ausgewogenes Verhältnis zwischen der Nichtbereitstellung und der Unterbereitstellung der Tabelle, um sowohl das geringe Auftreten von Fehlern bei unzureichender Durchsatzkapazität als auch die Optimierung der Kosten zu erreichen.

## Fälle, in denen der On-Demand-Modus ausgewählt werden sollte
<a name="CostOptimization_TableCapacityMode_OnDemand"></a>

Bei der Kostenoptimierung ist der On-Demand-Modus die beste Wahl, wenn Sie eine unvorhersehbare Arbeitslast haben, die der in der folgenden Grafik dargestellten ähnelt.

Diese Faktoren tragen zu dieser Art von Arbeitslast bei:
+ Unvorhersehbares Timing der Anforderungen (dadurch Datenverkehrsspitzen)
+ Variables Volumen der Anforderungen (aufgrund von Batch-Workloads)
+ Sinkt in einer bestimmten Stunde auf Null oder unter 18% des Spitzenwerts (aufgrund von Entwicklungs- oder Testumgebungen)

![\[Bild, das eine Workload mit vielen zufälligen Datenverkehrsspitzen zeigt.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png)


Bei Workloads mit den oben genannten Merkmalen kann die Verwendung von Application Auto Scaling, um genügend Kapazität aufrechtzuerhalten, damit die Tabelle auf Datenverkehrsspitzen reagieren kann, zu unerwünschten Ergebnissen führen. Entweder ist die Tabelle überdimensioniert und kostet mehr als nötig, oder die Tabelle ist zu wenig bereitgestellt und Anfragen führen zu unnötigen Durchsatzfehlern bei niedriger Kapazität. In solchen Fällen sind On-Demand-Tabellen die bessere Wahl.

Da On-Demand-Tabellen auf Anfrage abgerechnet werden, müssen Sie auf Tabellenebene nichts weiter tun, um die Kosten zu optimieren. Sie sollten Ihre On-Demand-Tabellen regelmäßig überprüfen, um sicherzustellen, dass der Workload weiterhin die oben genannten Merkmale aufweist. Wenn sich die Arbeitslast stabilisiert hat, sollten Sie erwägen, zum Bereitstellungsmodus zu wechseln, um die Kostenoptimierung aufrechtzuerhalten.

## Fälle, in denen der Modus bereitgestellter Kapazität ausgewählt werden sollte
<a name="CostOptimization_TableCapacityMode_Provisioned"></a>

Ein idealer Workload für den Modus mit bereitgestellter Kapazität ist ein Workload mit einem besser vorhersehbaren Nutzungsmuster, wie in der folgenden Grafik dargestellt.

Die folgenden Faktoren tragen zu einer vorhersehbaren Arbeitslast bei:
+ Vorhersagbarer/zyklischer Datenverkehr für eine bestimmte Stunde oder einen bestimmten Tag
+ Begrenzte kurzfristige Datenverkehrsspitzen

![\[Bild, das eine recht vorhersehbare Workload mit begrenzten Datenverkehrsspitzen zeigt.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png)


Da das Datenverkehrsvolumen innerhalb einer bestimmten Zeit oder eines bestimmten Tages stabiler ist, können Sie die bereitgestellte Kapazität relativ nahe an der tatsächlich verbrauchten Kapazität der Tabelle festlegen. Bei der Kostenoptimierung einer Tabelle mit bereitgestellter Kapazität geht es letztlich darum, die bereitgestellte Kapazität (blaue Linie) so nah wie möglich an die verbrauchte Kapazität (orange Linie) heranzuführen, ohne die Anzahl der `ThrottledRequests` Ereignisse in der Tabelle zu erhöhen. Der Abstand zwischen den beiden Zeilen ist sowohl verschwendete Kapazität als auch eine Versicherung gegen eine schlechte Benutzererfahrung aufgrund unzureichender Durchsatzkapazitätsfehler.

Amazon Keyspaces bietet Application Auto Scaling für bereitgestellte Kapazitätstabellen, das diese automatisch in Ihrem Namen ausgleicht. Sie können Ihre verbrauchte Kapazität im Laufe des Tages verfolgen und die bereitgestellte Kapazität der Tabelle anhand einer Handvoll Variablen konfigurieren.

**Einheiten für minimale Kapazität**  
Sie können die Mindestkapazität einer Tabelle festlegen, um das Auftreten von Fehlern bei unzureichender Durchsatzkapazität zu begrenzen. Die Kosten der Tabelle werden dadurch jedoch nicht gesenkt. Wenn Ihre Tabelle Perioden mit geringer Auslastung aufweist, gefolgt von einem plötzlichen Anstieg hoher Auslastung, kann die Festlegung des Minimums verhindern, dass Application Auto Scaling die Tabellenkapazität zu niedrig festlegt.

**Einheiten für maximale Kapazität**  
Sie können die maximale Kapazität einer Tabelle festlegen, um zu verhindern, dass eine Tabelle stärker als beabsichtigt skaliert wird. Erwägen Sie, ein Maximum für Entwicklungs- oder Testtabellen festzulegen, bei denen umfangreiche Auslastungstests nicht erwünscht sind. Sie können für jede Tabelle einen Höchstwert festlegen. Achten Sie jedoch darauf, diese Einstellung regelmäßig mit der Tabellenbasislinie abzugleichen, wenn Sie sie in der Produktion verwenden, um versehentliche Fehler bei unzureichender Durchsatzkapazität zu vermeiden.

**Zielauslastung**  
Die Festlegung einer Zielauslastung der Tabelle ist das primäre Mittel zur Kostenoptimierung für eine Tabelle mit bereitgestellter Kapazität. Wenn Sie hier einen niedrigeren Prozentwert angeben, erhöht sich die Überbelegung der Tabelle, was die Kosten erhöht, aber das Risiko von Fehlern bei unzureichender Durchsatzkapazität verringert. Wenn Sie einen höheren Prozentwert festlegen, verringert sich die Überbelegung der Tabelle, erhöht sich jedoch das Risiko von Fehlern bei unzureichender Durchsatzkapazität.

## Zusätzliche Faktoren, die bei der Auswahl eines Tabellenkapazitätsmodus zu berücksichtigen sind
<a name="CostOptimization_TableCapacityMode_AdditionalFactors"></a>

Bei der Entscheidung zwischen den beiden Kapazitätsmodi sollten einige zusätzliche Faktoren berücksichtigt werden.

 Berücksichtigen Sie bei der Entscheidung zwischen den beiden Tabellenmodi, wie stark sich dieser zusätzliche discount auf die Kosten des Tisches auswirkt. In vielen Fällen kann selbst eine relativ unvorhersehbare Arbeitslast kostengünstiger sein, wenn sie auf einer Tabelle mit überdimensionierter Kapazität und reservierter Kapazität ausgeführt wird. 

**Verbessern der Vorhersehbarkeit Ihrer Workload**  
In manchen Situationen kann ein Workload scheinbar sowohl ein vorhersehbares als auch ein unvorhersehbares Muster aufweisen. Dies kann zwar mit einer On-Demand-Tabelle problemlos unterstützt werden, aber die Kosten werden wahrscheinlich niedriger sein, wenn die unvorhersehbaren Muster in der Arbeitslast verbessert werden können.

Eine der häufigsten Ursachen für diese Muster sind Batch-Importe. Diese Art von Verkehr kann die Basiskapazität der Tabelle oft so stark überschreiten, dass bei der Ausführung Fehler mit unzureichender Durchsatzkapazität auftreten würden. Um eine Workload wie diese in einer Tabelle mit bereitgestellter Kapazität auszuführen, sollten Sie die folgenden Optionen in Betracht ziehen:
+ Wenn der Batch zu geplanten Zeiten ausgeführt wird, können Sie eine Erhöhung der Kapazität Ihrer Anwendung für die auto Skalierung planen, bevor sie ausgeführt wird.
+ Wenn der Batch zufällig ausgeführt wird, sollten Sie versuchen, die für die Ausführung benötigte Zeit zu verlängern, anstatt ihn so schnell wie möglich auszuführen.
+ Fügen Sie dem Import eine Anlaufphase hinzu, in der die Geschwindigkeit des Imports gering beginnt, aber über einige Minuten langsam erhöht wird, bis Application Auto Scaling die Möglichkeit hatte, mit der Anpassung der Tabellenkapazität zu beginnen.

# Evaluieren Sie die Application Auto Scaling Scaling-Einstellungen Ihrer Tabelle
<a name="CostOptimization_AutoScalingSettings"></a>

Dieser Abschnitt bietet einen Überblick darüber, wie Sie die Application Auto Scaling Scaling-Einstellungen Ihrer Amazon Keyspaces-Tabellen auswerten können. [Amazon Keyspaces Application Auto Scaling](autoscaling.md) ist eine Funktion, die den Tabellendurchsatz auf der Grundlage Ihres Anwendungsdatenverkehrs und Ihrer Zielnutzungsmetrik verwaltet. Dadurch wird sichergestellt, dass Ihre Tabellen über die für Ihre Anwendungsmuster erforderliche Kapazität verfügen.

Der Application Auto Scaling Scaling-Dienst überwacht Ihre aktuelle Tabellenauslastung und vergleicht sie mit dem Zielnutzungswert:`TargetValue`. Er benachrichtigt Sie, wenn es an der Zeit ist, die zugewiesene Kapazität zu erhöhen oder zu verringern. 

**Topics**
+ [Grundlegendes zu Ihren Application Auto Scaling Scaling-Einstellungen](#CostOptimization_AutoScalingSettings_UnderProvisionedTables)
+ [So ermitteln Sie Tabellen mit geringer Zielauslastung (<= 50 %)](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization)
+ [So bewältigen Sie Workloads mit saisonalen Schwankungen](#CostOptimization_AutoScalingSettings_SeasonalVariance)
+ [So bewältigen Sie stark schwankende Workloads mit unbekannten Mustern](#CostOptimization_AutoScalingSettings_UnknownPatterns)
+ [So bewältigen Sie Workloads mit verknüpften Anwendungen](#CostOptimization_AutoScalingSettings_BetweenRanges)

## Grundlegendes zu Ihren Application Auto Scaling Scaling-Einstellungen
<a name="CostOptimization_AutoScalingSettings_UnderProvisionedTables"></a>

Die Festlegung des richtigen Werts für die Zielauslastung, den ersten Schritt und die Endwerte erfordert die Beteiligung Ihres Operations-Teams. Auf diese Weise können Sie die Werte auf der Grundlage der historischen Anwendungsnutzung, die zum Auslösen der Application Auto Scaling Scaling-Richtlinien verwendet wird, richtig definieren. Das Auslastungsziel ist der Prozentsatz Ihrer Gesamtkapazität, der während eines bestimmten Zeitraums erreicht werden muss, bevor die Application Auto Scaling Scaling-Regeln gelten.

Wenn Sie ein **hohes Auslastungsziel festlegen (ein Ziel von etwa 90%)**, bedeutet dies, dass Ihr Traffic für einen bestimmten Zeitraum höher als 90% sein muss, bevor Application Auto Scaling aktiviert wird. Ein hohes Auslastungsziel sollten Sie nur verwenden, wenn Ihre Anwendung sehr konstant arbeitet und keine Datenverkehrsspitzen verzeichnet.

Wenn Sie eine sehr **niedrige Auslastung festlegen (ein Ziel von weniger als 50%)**, bedeutet dies, dass Ihre Anwendung 50% der bereitgestellten Kapazität erreichen müsste, bevor sie eine Application Auto Scaling Scaling-Richtlinie auslöst. Sofern Ihr Anwendungsdatenverkehr nicht extrem schnell zunimmt, führt dies in der Regel zu ungenutzter Kapazität und einer Ressourcenverschwendung. 

## So ermitteln Sie Tabellen mit geringer Zielauslastung (<= 50 %)
<a name="CostOptimization_AutoScalingSettings_IdentifyLowUtilization"></a>

Sie können entweder das AWS CLI oder verwenden AWS-Managementkonsole , um die Auto Scaling-Richtlinien `TargetValues` für Ihre Anwendung in Ihren Amazon Keyspaces-Ressourcen zu überwachen und zu identifizieren.

**Anmerkung**  
Wenn Sie Tabellen mit mehreren Regionen im Modus für bereitgestellte Kapazität mit Amazon Keyspaces Auto Scaling verwenden, stellen Sie sicher, dass Sie die Amazon Keyspaces-API-Operationen verwenden, um Auto Scaling zu konfigurieren. Die zugrunde liegenden API-Operationen für Application Auto Scaling, die Amazon Keyspaces in Ihrem Namen aufruft, verfügen nicht über Funktionen für mehrere Regionen. Weitere Informationen finden Sie unter [Sehen Sie sich die bereitgestellten Kapazitäten und Auto-Scaling-Einstellungen für eine Tabelle mit mehreren Regionen in Amazon Keyspaces an](tables-mrr-view.md).

------
#### [ AWS CLI ]

1. Verwenden Sie den folgenden Befehl, um die gesamte Ressourcenliste zurückzugeben:

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace cassandra
   ```

   Dieser Befehl gibt die gesamte Liste der Application Auto Scaling Scaling-Richtlinien zurück, die für jede Amazon Keyspaces-Ressource ausgestellt wurden. Wenn Sie nur die Ressourcen aus einer bestimmten Tabelle abrufen möchten, können Sie den `–resource-id parameter` hinzufügen. Beispiel:

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name”
   ```

1. Geben Sie nur die Auto Scaling-Richtlinien für eine bestimmte Tabelle zurück, indem Sie den folgenden Befehl ausführen

   ```
   aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name”
   ```

   Die Werte für die Application Auto Scaling Scaling-Richtlinien sind unten hervorgehoben. Sie müssen sicherstellen, dass der Zielwert über 50% liegt, um eine übermäßige Bereitstellung zu vermeiden. Das Ergebnis sollte etwa wie folgt aussehen:

   ```
   {
       "ScalingPolicies": [
           {
               "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy:<uuid>:resource/keyspaces/table/table-name-scaling-policy",
               "PolicyName": $<full-table-name>”,
               "ServiceNamespace": "cassandra",
               "ResourceId": "keyspace/keyspace-name/table/table-name",
               "ScalableDimension": "cassandra:table:WriteCapacityUnits",
               "PolicyType": "TargetTrackingScaling",
               "TargetTrackingScalingPolicyConfiguration": {
                   "TargetValue": 70.0,
                   "PredefinedMetricSpecification": {
                       "PredefinedMetricType": "KeyspacesWriteCapacityUtilization"
                   }
               },
               "Alarms": [
                   ...
               ],
               "CreationTime": "2022-03-04T16:23:48.641000+10:00"
           },
           {
               "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy:<uuid>:resource/keyspaces/table/table-name-scaling-policy",
               "PolicyName":$<full-table-name>”,
               "ServiceNamespace": "cassandra",
               "ResourceId": "keyspace/keyspace-name/table/table-name",
               "ScalableDimension": "cassandra:table:ReadCapacityUnits",
               "PolicyType": "TargetTrackingScaling",
               "TargetTrackingScalingPolicyConfiguration": {
                   "TargetValue": 70.0,
                   "PredefinedMetricSpecification": {
                       "PredefinedMetricType": "KeyspacesReadCapacityUtilization"
                   }
               },
               "Alarms": [
                   ...
               ],
               "CreationTime": "2022-03-04T16:23:47.820000+10:00"
           }
       ]
   }
   ```

------
#### [ AWS-Managementkonsole ]

1. Melden Sie sich bei der an AWS-Managementkonsole und navigieren Sie zur CloudWatch Serviceseite unter [Erste Schritte mit dem](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). AWS-Managementkonsole Wählen Sie bei AWS-Region Bedarf das entsprechende aus.

1. Wählen Sie in der linken Navigationsleiste die Option **Tables** (Tabellen) aus. Wählen Sie auf der Seite **Tables** (Tabellen) den **Namen** der Tabelle aus.

1. Überprüfen Sie auf der Seite **Tabellendetails** auf der Registerkarte **Kapazität** die Einstellungen für Application Auto Scaling Ihrer Tabelle.

------

Bei Zielauslastungswerten von maximal 50 % sollten Sie Ihre Tabellenauslastungsmetriken prüfen, um festzustellen, ob eine [zu geringe oder eine übermäßige Bereitstellung](CostOptimization_RightSizedProvisioning.md) vorliegt. 

## So bewältigen Sie Workloads mit saisonalen Schwankungen
<a name="CostOptimization_AutoScalingSettings_SeasonalVariance"></a>

Stellen Sie sich folgendes Szenario vor: Ihre Anwendung läuft die meiste Zeit unter einem minimalen Durchschnittswert, doch das Auslastungsziel ist niedrig. Somit kann Ihre Anwendung schnell auf Ereignisse reagieren, die zu bestimmten Tageszeiten auftreten, Sie verfügen über genügend Kapazität und es kommt nicht zu Drosselungen. Ein solches Szenario kommt häufig vor, wenn eine Anwendung während der normalen Bürozeiten (9 bis 17 Uhr) sehr stark ausgelastet ist, außerhalb der Geschäftszeiten jedoch auf niedrigem Niveau läuft. Da einige Benutzer vor 9 Uhr eine Verbindung herstellen, verwendet die Anwendung diesen niedrigen Schwellenwert, um schnell hochzufahren und zu Spitzenzeiten die *erforderliche* Kapazität zu erreichen.

Dieses Szenario könnte wie folgt aussehen: 
+ Zwischen 17 Uhr und 9 Uhr bleiben die `ConsumedWriteCapacityUnits`-Einheiten zwischen 90 und 100.
+ Benutzer beginnen vor 9 Uhr, eine Verbindung zu der Anwendung herzustellen, und die Kapazitätseinheiten steigen erheblich an (der maximale Wert, den Sie gesehen haben, beträgt 1 500 WCU).
+ Im Durchschnitt variiert Ihre Anwendungsnutzung während der Arbeitszeit zwischen 800 und 1 200.

Wenn das vorherige Szenario auf Ihre Anwendung zutrifft, sollten Sie die [Application Auto Scaling nach Zeitplan](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) in Betracht ziehen, bei der in Ihrer Tabelle immer noch eine Regel für Application Auto Scaling konfiguriert sein könnte, aber mit einer weniger aggressiven Zielauslastung, die die zusätzliche Kapazität nur in den von Ihnen benötigten Intervallen bereitstellt.

Mit dem können Sie die AWS CLI folgenden Schritte ausführen, um eine geplante Auto Scaling-Regel zu erstellen, die auf der Grundlage der Tageszeit und des Wochentags ausgeführt wird.

1. Registrieren Sie Ihre Amazon Keyspaces-Tabelle als skalierbares Ziel bei Application Auto Scaling. Ein skalierbares Ziel ist eine Ressource, die Application Auto Scaling auf- und abskalieren kann.

   ```
   aws application-autoscaling register-scalable-target \
       --service-namespace cassandra \
       --scalable-dimension cassandra:table:WriteCapacityUnits \
       --resource-id keyspace/keyspace-name/table/table-name \
       --min-capacity 90 \
       --max-capacity 1500
   ```

1. Richten Sie geplante Aktionen entsprechend Ihren Anforderungen ein.

   Sie benötigen zwei Regeln, um das Szenario abzudecken: eine für die Hochskalierung und eine weitere für die Verkleinerung. Die erste Regel zum Hochskalieren der geplanten Aktion wird im folgenden Beispiel gezeigt.

   ```
   aws application-autoscaling put-scheduled-action \
       --service-namespace cassandra \
       --scalable-dimension cassandra:table:WriteCapacityUnits \
       --resource-id keyspace/keyspace-name/table/table-name \
       --scheduled-action-name my-8-5-scheduled-action \
       --scalable-target-action MinCapacity=800,MaxCapacity=1500 \
       --schedule "cron(45 8 ? * MON-FRI *)" \
       --timezone "Australia/Brisbane"
   ```

   In diesem Beispiel wird die zweite Regel zum Verkleinern der geplanten Aktion gezeigt.

   ```
   aws application-autoscaling put-scheduled-action \
       --service-namespace cassandra \
       --scalable-dimension cassandra:table:WriteCapacityUnits \
       --resource-id keyspace/keyspace-name/table/table-name \
       --scheduled-action-name my-5-8-scheduled-down-action \
       --scalable-target-action MinCapacity=90,MaxCapacity=1500 \
       --schedule "cron(15 17 ? * MON-FRI *)" \
       --timezone "Australia/Brisbane"
   ```

1. Führen Sie den folgenden Befehl aus, um zu bestätigen, dass beide Regeln aktiviert wurden:

   ```
   aws application-autoscaling describe-scheduled-actions --service-namespace cassandra
   ```

   Das Ergebnis sollte ungefähr wie folgt aussehen:

   ```
   {
       "ScheduledActions": [
           {
               "ScheduledActionName": "my-5-8-scheduled-down-action",
               "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction:<uuid>:resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action",
               "ServiceNamespace": "cassandra",
               "Schedule": "cron(15 17 ? * MON-FRI *)",
               "Timezone": "Australia/Brisbane",
               "ResourceId": "keyspace/keyspace-name/table/table-name",
               "ScalableDimension": "cassandra:table:WriteCapacityUnits",
               "ScalableTargetAction": {
                   "MinCapacity": 90,
                   "MaxCapacity": 1500
               },
               "CreationTime": "2022-03-15T17:30:25.100000+10:00"
           },
           {
               "ScheduledActionName": "my-8-5-scheduled-action",
               "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction:<uuid>:resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action",
               "ServiceNamespace": "cassandra",
               "Schedule": "cron(45 8 ? * MON-FRI *)",
               "Timezone": "Australia/Brisbane",
               "ResourceId": "keyspace/keyspace-name/table/table-name",
               "ScalableDimension": "cassandra:table:WriteCapacityUnits",
               "ScalableTargetAction": {
                   "MinCapacity": 800,
                   "MaxCapacity": 1500
               },
               "CreationTime": "2022-03-15T17:28:57.816000+10:00"
           }
       ]
   }
   ```

Im folgenden Bild ist ein Workload zu sehen, bei dem immer die Zielauslastung von 70 % beibehalten wird. Beachten Sie, dass die Auto Scaling-Regeln immer noch gelten und der Durchsatz nicht reduziert wird.

![\[Ein Diagramm, das den Schreibverbrauch in Einheiten pro Sekunde zeigt und die bereitgestellte mit der verbrauchten Kapazität über einen Zeitraum von einem Tag vergleicht.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png)


Wenn wir die Ansicht vergrößern, sehen wir, dass es in der Anwendung einen Spitzenwert gegeben hat, der den 70%-Schwellenwert für Auto Scaling ausgelöst hat, sodass Auto Scaling aktiviert und die für die Tabelle benötigte zusätzliche Kapazität bereitgestellt wurde. Die geplante Auto Scaling-Aktion wirkt sich auf Höchst- und Minimalwerte aus, und es liegt in Ihrer Verantwortung, sie einzurichten.

![\[Eine detailliertere Ansicht des Diagramms, das die Schreibnutzung in Einheiten pro Sekunde im Vergleich der bereitgestellten mit der verbrauchten Kapazität zeigt, wobei eine bestimmte Zeit vergrößert wird.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png)


![\[Zeigt die detaillierte Ansicht des Diagramms an, das den Schreibverbrauch in Einheiten pro Sekunde im Vergleich zwischen bereitgestellter und verbrauchter Kapazität über einen Zeitraum von einem Tag zeigt.\]](http://docs.aws.amazon.com/de_de/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png)


## So bewältigen Sie stark schwankende Workloads mit unbekannten Mustern
<a name="CostOptimization_AutoScalingSettings_UnknownPatterns"></a>

In diesem Szenario verwendet die Anwendung ein sehr niedriges Auslastungsziel, da Sie die Anwendungsmuster noch nicht kennen und Sie sicherstellen möchten, dass es bei Ihrem Workload nicht zu Durchsatzfehlern mit niedriger Kapazität kommt.

Sie sollten stattdessen die Verwendung des [On-Demand-Kapazitätsmodus](ReadWriteCapacityMode.OnDemand.md) in Betracht ziehen. On-Demand-Tabellen eignen sich perfekt für stark schwankende Workloads, deren Datenverkehrsmuster Sie nicht kennen. Im On-Demand-Kapazitätsmodus zahlen Sie pro Anforderung für die Lese- und Schreibvorgänge, die Ihre Anwendung in Ihren Tabellen ausführt. Sie müssen nicht angeben, wie viel Lese- und Schreibdurchsatz Sie von Ihrer Anwendung erwarten, da Amazon Keyspaces Ihre Workloads sofort berücksichtigt, wenn sie hoch- oder herunterfahren.

## So bewältigen Sie Workloads mit verknüpften Anwendungen
<a name="CostOptimization_AutoScalingSettings_BetweenRanges"></a>

In diesem Szenario hängt die Anwendung von anderen Systemen ab. Dies kann beispielsweise in Batchverarbeitungsszenarien der Fall sein, bei denen es abhängig von Ereignissen in der Anwendungslogik zu starken Datenverkehrsspitzen kommen kann.

Erwägen Sie die Entwicklung einer benutzerdefinierten Logik zur auto-scaling von Anwendungen, die auf Ereignisse reagiert, bei denen Sie die Tabellenkapazität erhöhen können `TargetValues` und die Ihren spezifischen Anforderungen entspricht. Sie könnten von einer Kombination von AWS Diensten wie Λ Amazon EventBridge und Step Functions profitieren und diese nutzen, um auf Ihre spezifischen Anwendungsanforderungen zu reagieren.

# Identifizieren Sie Ihre ungenutzten Ressourcen, um die Kosten in Amazon Keyspaces zu optimieren
<a name="CostOptimization_UnusedResources"></a>

Dieser Abschnitt gibt einen Überblick darüber, wie Sie Ihre nicht verwendeten Ressourcen regelmäßig bewerten können. Wenn sich Ihre Anwendungsanforderungen weiterentwickeln, sollten Sie sicherstellen, dass keine Ressourcen ungenutzt bleiben und zu unnötigen Amazon Keyspaces-Kosten beitragen. Die unten beschriebenen Verfahren verwenden CloudWatch Amazon-Metriken, um ungenutzte Ressourcen zu identifizieren und Maßnahmen zur Kostensenkung zu ergreifen.

Sie können Amazon Keyspaces mithilfe von Amazon Keyspaces überwachen CloudWatch, das Rohdaten von Amazon Keyspaces sammelt und zu lesbaren, nahezu in Echtzeit verfügbaren Metriken verarbeitet. Diese Statistiken werden eine gewisse Zeit aufbewahrt, damit Sie zum besseren Verständnis Ihrer Nutzung Verlaufsdaten zur Verfügung haben. Standardmäßig werden Amazon Keyspaces-Metrikdaten CloudWatch automatisch an gesendet. Weitere Informationen finden Sie unter [Was ist Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) und [Aufbewahrung von Kennzahlen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention) im * CloudWatch Amazon-Benutzerhandbuch*. 

**Topics**
+ [So ermitteln Sie nicht verwendete Ressourcen](#CostOptimization_UnusedResources_Identifying)
+ [Ermitteln von nicht verwendeten Tabellenressourcen](#CostOptimization_UnusedResources_Tables)
+ [Bereinigen von nicht verwendeten Tabellenressourcen](#CostOptimization_UnusedResources_Tables_Cleanup)
+ [Bereinigen ungenutzter point-in-time Wiederherstellungs-Backups (PITR)](#CostOptimization_UnusedResources_Backups)

## So ermitteln Sie nicht verwendete Ressourcen
<a name="CostOptimization_UnusedResources_Identifying"></a>

Um ungenutzte Tabellen zu identifizieren, können Sie sich die folgenden CloudWatch Kennzahlen über einen Zeitraum von 30 Tagen ansehen, um festzustellen, ob in einer bestimmten Tabelle aktive Lese- oder Schreibvorgänge vorhanden sind:

**`ConsumedReadCapacityUnits`**  
Die Anzahl der in einem bestimmten Zeitraum verbrauchten Lesekapazitätseinheiten, um nachverfolgen zu können, wie viel Kapazität Sie genutzt haben. Sie können die gesamte verbrauchte Lesekapazität für eine Tabelle abrufen.

**`ConsumedWriteCapacityUnits`**  
Die Anzahl der in einem bestimmten Zeitraum verbrauchten Schreibkapazitätseinheiten, um nachverfolgen zu können, wie viel Kapazität Sie genutzt haben. Sie können die gesamte verbrauchte Schreibkapazität für eine Tabelle abrufen.

## Ermitteln von nicht verwendeten Tabellenressourcen
<a name="CostOptimization_UnusedResources_Tables"></a>

Amazon CloudWatch ist ein Überwachungs- und Beobachtbarkeitsservice, der die Amazon Keyspaces-Tabellenmetriken bereitstellt, anhand derer Sie ungenutzte Ressourcen identifizieren können. CloudWatch Metriken können sowohl über AWS-Managementkonsole als auch über die eingesehen werden. AWS Command Line Interface

------
#### [ AWS Command Line Interface ]

Um die Metriken Ihrer Tabellen über anzuzeigen AWS Command Line Interface, können Sie die folgenden Befehle verwenden.

1. Werten Sie zunächst die Lesevorgänge Ihrer Tabelle aus:
**Anmerkung**  
Wenn der Tabellenname in Ihrem Konto nicht eindeutig ist, müssen Sie auch den Namen des Schlüsselraums angeben.

   ```
   aws cloudwatch get-metric-statistics --metric-name
   ConsumedReadCapacityUnits --start-time <start-time> --end-time <end-
   time> --period <period> --namespace AWS/Cassandra --statistics Sum --
   dimensions Name=TableName,Value=<table-name>
   ```

   Damit Tabellen nicht fälschlicherweise als nicht verwendet ermittelt werden, sollten Sie die Metriken über einen längeren Zeitraum auswerten. **Wählen Sie einen geeigneten Start- und Endzeitbereich, z. B. **30 Tage**, und einen geeigneten Zeitraum, z. B. 86400.**

   In den zurückgegebenen Daten zeigt eine **Summe** von mehr als **0** an, dass die auszuwertende Tabelle während dieses Zeitraums Lesedatenverkehr empfangen hat.

   Das folgende Ergebnis zeigt eine Tabelle, die im ausgewerteten Zeitraum Lesedatenverkehr empfangen hat:

   ```
           {
               "Timestamp": "2022-08-25T19:40:00Z",
               "Sum": 36023355.0,
               "Unit": "Count"
           },
           {
               "Timestamp": "2022-08-12T19:40:00Z",
               "Sum": 38025777.5,
               "Unit": "Count"
           },
   ```

   Das folgende Ergebnis zeigt eine Tabelle, die im ausgewerteten Zeitraum keinen Lesedatenverkehr empfangen hat:

   ```
           {
               "Timestamp": "2022-08-01T19:50:00Z",
               "Sum": 0.0,
               "Unit": "Count"
           },
           {
               "Timestamp": "2022-08-20T19:50:00Z",
               "Sum": 0.0,
               "Unit": "Count"
           },
   ```

1. Werten Sie als Nächstes die Schreibvorgänge Ihrer Tabelle aus:

   ```
   aws cloudwatch get-metric-statistics --metric-name
   ConsumedWriteCapacityUnits --start-time <start-time> --end-time <end-
   time> --period <period> --namespace AWS/Cassandra --statistics Sum --
   dimensions Name=TableName,Value=<table-name>
   ```

   Damit Tabellen nicht fälschlicherweise als nicht verwendet ermittelt werden, sollten Sie die Metriken über einen längeren Zeitraum auswerten. Wählen Sie einen geeigneten Startzeit- und Endzeitbereich, beispielsweise **30 Tage**, und einen geeigneten Zeitraum, wie z. B. **86400**.

   In den zurückgegebenen Daten zeigt eine **Summe** von mehr als **0** an, dass die auszuwertende Tabelle während dieses Zeitraums Lesedatenverkehr empfangen hat.

   Das folgende Ergebnis zeigt eine Tabelle, die im ausgewerteten Zeitraum Schreibdatenverkehr empfangen hat:

   ```
           {
               "Timestamp": "2022-08-19T20:15:00Z",
               "Sum": 41014457.0,
               "Unit": "Count"
           },
           {
               "Timestamp": "2022-08-18T20:15:00Z",
               "Sum": 40048531.0,
               "Unit": "Count"
           },
   ```

   Das folgende Ergebnis zeigt eine Tabelle, die im ausgewerteten Zeitraum keinen Schreibdatenverkehr empfangen hat:

   ```
           {
               "Timestamp": "2022-07-31T20:15:00Z",
               "Sum": 0.0,
               "Unit": "Count"
           },
           {
               "Timestamp": "2022-08-19T20:15:00Z",
               "Sum": 0.0,
               "Unit": "Count"
           },
   ```

------
#### [ AWS-Managementkonsole ]

Mit den folgenden Schritten können Sie Ihre Ressourcennutzung anhand der bewerten. AWS-Managementkonsole

1. Melden Sie sich bei an AWS-Managementkonsole und navigieren Sie zur CloudWatch Serviceseite unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). Wählen Sie bei Bedarf oben rechts AWS-Region in der Konsole die entsprechende Option aus.

1. Suchen Sie in der linken Navigationsleiste den Abschnitt **Metriken** und wählen Sie **Alle Metriken** aus.

1. Die obige Aktion öffnet ein Dashboard mit zwei Bereichen. Im oberen Bereich sehen Sie die aktuellen Kennzahlen grafisch dargestellt. Unten können Sie die Metriken auswählen, die grafisch dargestellt werden können. Wählen Sie im unteren Bereich Amazon Keyspaces aus.

1. Wählen Sie im Auswahlfeld für Amazon Keyspaces-Metriken die Kategorie **Tabellenmetriken** aus, um die Metriken für Ihre Tabellen in der aktuellen Region anzuzeigen.

1. Identifizieren Sie Ihren Tabellennamen, indem Sie im Menü nach unten scrollen und dann die Metriken `ConsumedReadCapacityUnits` und `ConsumedWriteCapacityUnits` für Ihre Tabelle auswählen.

1. **Wählen Sie den Tab **Graphed Metrics (2)** und passen Sie die Spalte **Statistik** auf Summe an.**

1. Um zu vermeiden, dass eine Tabelle fälschlicherweise als unbenutzt identifiziert wird, werten Sie die Tabellenmetriken über einen längeren Zeitraum aus. Wählen Sie oben im Grafikfenster einen geeigneten Zeitraum, z. B. einen Monat, für die Auswertung Ihrer Tabelle aus. Wählen Sie **Benutzerdefiniert**, wählen Sie im Dropdownmenü die Option **1 Monat** aus und wählen Sie **Anwenden** aus.

1. Werten Sie die grafisch dargestellten Metriken für Ihre Tabelle aus, um festzustellen, ob die Tabelle genutzt wird. Metriken, die über **0** hinausgehen, weisen darauf hin, dass eine Tabelle während des ausgewerteten Zeitraums genutzt wurde. Ein flaches Diagramm bei **0** für Lese- und Schreibvorgänge zeigt an, dass eine Tabelle unbenutzt ist.

------

## Bereinigen von nicht verwendeten Tabellenressourcen
<a name="CostOptimization_UnusedResources_Tables_Cleanup"></a>

Wenn Sie nicht verwendete Tabellenressourcen ermittelt haben, können Sie die laufenden Kosten für diese Ressourcen auf folgende Weise reduzieren.

**Anmerkung**  
Wenn Sie eine nicht verwendete Tabelle ermittelt haben, die jedoch verfügbar bleiben soll, falls in Zukunft darauf zugegriffen werden muss, sollten Sie eine Umstellung auf den On-Demand-Modus in Betracht ziehen. Andernfalls können Sie erwägen, die Tabelle zu löschen.

**Kapazitätsmodi**  
Amazon Keyspaces berechnet Gebühren für das Lesen, Schreiben und Speichern von Daten in Ihren Amazon Keyspaces-Tabellen.

Amazon Keyspaces bietet [zwei Kapazitätsmodi](ReadWriteCapacityMode.md) mit spezifischen Abrechnungsoptionen für die Verarbeitung von Lese- und Schreibvorgängen in Ihren Tabellen: auf Abruf und bereitgestellt. Der read/write Kapazitätsmodus steuert, wie Ihnen der Lese- und Schreibdurchsatz in Rechnung gestellt wird und wie Sie die Kapazität verwalten.

Für On-Demand-Modustabellen müssen Sie nicht angeben, wie viel Lese- und Schreibdurchsatz Sie von Ihrer Anwendung erwarten. Amazon Keyspaces berechnet Ihnen die Lese- und Schreibvorgänge, die Ihre Anwendung an Ihren Tabellen durchführt, in Form von Leseanforderungseinheiten und Schreibanforderungseinheiten. Wenn auf Ihrer Tabelle keine Aktivität stattfindet, zahlen Sie nicht für den Durchsatz, aber es fallen trotzdem Speichergebühren an.

**Löschen von Tabellen**  
Wenn Sie eine unbenutzte Tabelle entdeckt haben und diese löschen möchten, sollten Sie zunächst eine Sicherungskopie erstellen oder die Daten exportieren.

Durchgeführte Backups AWS Backup können Cold Storage Tiering nutzen und so die Kosten weiter senken. In der Dokumentation zur [Verwaltung von Backup-Plänen](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans) finden Sie Informationen dazu, wie Sie einen Lebenszyklus verwenden können, um Ihr Backup in einen Cold Storage zu verschieben.

Nachdem Ihre Tabelle gesichert wurde, können Sie sie entweder über die AWS-Managementkonsole oder über die AWS Command Line Interface löschen.

## Bereinigen ungenutzter point-in-time Wiederherstellungs-Backups (PITR)
<a name="CostOptimization_UnusedResources_Backups"></a>

Amazon Keyspaces bietet Point-in-time Recovery, d. h. kontinuierliche Backups für 35 Tage, um Sie vor versehentlichen Schreib- oder Löschvorgängen zu schützen. Mit PITR-Backups sind Kosten verbunden.

In der Dokumentation unter finden Sie Informationen [Daten mit point-in-time Wiederherstellung für Amazon Keyspaces Backup und wiederherstellen](PointInTimeRecovery.md) darüber, ob für Ihre Tabellen Backups aktiviert sind, die möglicherweise nicht mehr benötigt werden.

# Bewerten Sie Ihre Tabellennutzungsmuster, um Leistung und Kosten zu optimieren
<a name="CostOptimization_TableUsagePatterns"></a>

Dieser Abschnitt bietet einen Überblick darüber, wie Sie beurteilen können, ob Sie Ihre Amazon Keyspaces-Tabellen effizient verwenden. Es gibt bestimmte Nutzungsmuster, die für Amazon Keyspaces nicht optimal sind, und sie bieten Raum für Optimierungen sowohl in Bezug auf die Leistung als auch in Bezug auf die Kosten.

**Topics**
+ [Ausführen von weniger strikt konsistenten Lesevorgängen](#CostOptimization_TableUsagePatterns_StronglyConsistentReads)
+ [Aktivieren von Time to Live (TTL)](#CostOptimization_TableUsagePatterns_TTL)

## Ausführen von weniger strikt konsistenten Lesevorgängen
<a name="CostOptimization_TableUsagePatterns_StronglyConsistentReads"></a>

Amazon Keyspaces ermöglicht es Ihnen, die [Lesekonsistenz](consistency.md#ReadConsistency) pro Anfrage zu konfigurieren. Leseanforderungen sind standardmäßig letztendlich konsistent. Eventuell werden konsistente Lesevorgänge mit 0,5 RCU für bis zu 4 KB Daten berechnet.

Die meisten Teile von verteilten Workloads sind flexibel und können letztendliche Konsistenz tolerieren. Es kann jedoch Zugriffsmuster geben, die strikt konsistente Lesevorgänge erfordern. Für stark konsistente Lesevorgänge werden 1 RCU für bis zu 4 KB Daten berechnet, wodurch sich Ihre Lesekosten im Wesentlichen verdoppeln. Amazon Keyspaces bietet Ihnen die Flexibilität, beide Konsistenzmodelle in derselben Tabelle zu verwenden. 

Durch Auswertung Ihres Workloads und Anwendungscodes können Sie prüfen, ob strikt konsistente Lesevorgänge nur bei Bedarf verwendet werden.

## Aktivieren von Time to Live (TTL)
<a name="CostOptimization_TableUsagePatterns_TTL"></a>

[Time to Live (TTL)](TTL.md) hilft Ihnen dabei, Ihre Anwendungslogik zu vereinfachen und den Speicherpreis zu optimieren, indem Daten aus Tabellen automatisch ablaufen. Daten, die Sie nicht mehr benötigen, werden basierend auf dem von Ihnen festgelegten Time-to-Live-Wert automatisch aus Ihrer Tabelle gelöscht.



# Auswerten Ihrer bereitgestellten Kapazität, um eine angemessene Bereitstellung zu erzielen
<a name="CostOptimization_RightSizedProvisioning"></a>

Dieser Abschnitt bietet einen Überblick darüber, wie Sie beurteilen können, ob Ihre Amazon Keyspaces-Tabellen über die richtige Größe für die Bereitstellung verfügen. Wenn sich Ihre Arbeitslast weiterentwickelt, sollten Sie Ihre Betriebsabläufe entsprechend ändern, insbesondere wenn Ihre Amazon Keyspaces-Tabelle im Bereitstellungsmodus konfiguriert ist und Sie das Risiko einer Über- oder Unterbereitstellung Ihrer Tabellen eingehen.

Die in diesem Abschnitt beschriebenen Verfahren erfordern statistische Informationen, die aus den Amazon Keyspaces-Tabellen erfasst werden sollten, die Ihre Produktionsanwendung unterstützen. Um Ihr Anwendungsverhalten zu verstehen, sollten Sie einen Zeitraum definieren, der signifikant genug ist, um die saisonale Datenabhängigkeit Ihrer Anwendung zu erfassen. Wenn Ihre Anwendung beispielsweise wöchentliche Muster aufweist, sollte ein Zeitraum von drei Wochen ausreichen, um die Anforderungen an den Anwendungsdurchsatz zu analysieren.

Wenn Sie nicht wissen, wo Sie anfangen sollen, verwenden Sie für die folgenden Berechnungen die Datennutzung von mindestens einem Monat.

Bei der Bewertung der Kapazität können Sie für Amazon Keyspaces-Tabellen **Lesekapazitätseinheiten (RCUs)** und **Schreibkapazitätseinheiten (WCU)** unabhängig voneinander konfigurieren.

**Topics**
+ [So rufen Sie Verbrauchsmetriken aus Ihren Amazon Keyspaces-Tabellen ab](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics)
+ [So identifizieren Sie Amazon Keyspaces-Tabellen mit unzureichender Bereitstellung](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables)
+ [So identifizieren Sie übermäßig bereitgestellte Amazon Keyspaces-Tabellen](#CostOptimization_RightSizedProvisioning_OverProvisionedTables)

## So rufen Sie Verbrauchsmetriken aus Ihren Amazon Keyspaces-Tabellen ab
<a name="CostOptimization_RightSizedProvisioning_ConsumptionMetrics"></a>

Um die Tabellenkapazität zu bewerten, überwachen Sie die folgenden CloudWatch Kennzahlen und wählen Sie die entsprechende Dimension aus, um Tabelleninformationen abzurufen:


| Lesekapazitätseinheiten | Schreibkapazitätseinheiten | 
| --- | --- | 
|  `ConsumedReadCapacityUnits`  |  `ConsumedWriteCapacityUnits`  | 
|  `ProvisionedReadCapacityUnits`  |  `ProvisionedWriteCapacityUnits`  | 
|  `ReadThrottleEvents`  |  `WriteThrottleEvents`  | 

Sie können dies entweder über die AWS CLI oder die tun AWS-Managementkonsole.

------
#### [ AWS CLI ]

Bevor Sie die Kennzahlen zum Tabellenverbrauch abrufen, müssen Sie zunächst einige historische Datenpunkte mithilfe der CloudWatch API erfassen.

Erstellen Sie zunächst zwei Dateien: `write-calc.json` und `read-calc.json`. Diese Dateien stellen die Berechnungen für die Tabelle dar. Sie müssen einige der Felder aktualisieren, wie in der Tabelle unten angegeben, damit sie zu Ihrer Umgebung passen.

**Anmerkung**  
Wenn der Tabellenname in Ihrem Konto nicht eindeutig ist, müssen Sie auch den Namen des Schlüsselraums angeben.


| Feldname | Definition | Beispiel | 
| --- | --- | --- | 
| <table-name> | Der Name der Tabelle, die Sie analysieren | SampleTable | 
| <period> | Der Zeitraum, den Sie zur Bewertung des Nutzungsziels verwenden, basierend auf Sekunden | Für einen Zeitraum von 1 Stunde müssen Sie Folgendes angeben: 3600 | 
| <start-time> | Der Beginn Ihres Bewertungsintervalls, angegeben im ISO8601 Format | 2022-02-21T23:00:00 | 
| <end-time> | Das Ende Ihres Bewertungsintervalls, angegeben im ISO8601 Format | 2022-02-22T06:00:00 | 

Die Datei mit Schreibberechnungen ruft die Anzahl der WCUs ab, die im angegebenen Zeitraum für den angegebenen Zeitraum bereitgestellt und verbraucht wurden. Außerdem wird ein Nutzungsprozentsatz generiert, der für Analysen verwendet werden kann. Der vollständige Inhalt der `write-calc.json` Datei sollte wie im folgenden Beispiel aussehen.

```
{
  "MetricDataQueries": [
    {
      "Id": "provisionedWCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Cassandra",
          "MetricName": "ProvisionedWriteCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>"
            }
          ]
        },
        "Period": <period>,
        "Stat": "Average"
      },
      "Label": "Provisioned",
      "ReturnData": false
    },
    {
      "Id": "consumedWCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Cassandra",
          "MetricName": "ConsumedWriteCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>""
            }
          ]
        },
        "Period": <period>,
        "Stat": "Sum"
      },
      "Label": "",
      "ReturnData": false
    },
    {
      "Id": "m1",
      "Expression": "consumedWCU/PERIOD(consumedWCU)",
      "Label": "Consumed WCUs",
      "ReturnData": false
    },
    {
      "Id": "utilizationPercentage",
      "Expression": "100*(m1/provisionedWCU)",
      "Label": "Utilization Percentage",
      "ReturnData": true
    }
  ],
  "StartTime": "<start-time>",
  "EndTime": "<end-time>",
  "ScanBy": "TimestampDescending",
  "MaxDatapoints": 24
}
```

Die gelesene Berechnungsdatei verwendet ähnliche Metriken. Diese Datei ruft ab, wie viele während des angegebenen Zeitraums bereitgestellt und genutzt RCUs wurden. Der Inhalt der `read-calc.json` Datei sollte wie in diesem Beispiel aussehen.

```
{
  "MetricDataQueries": [
    {
      "Id": "provisionedRCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Cassandra",
          "MetricName": "ProvisionedReadCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>"
            }
          ]
        },
        "Period": <period>,
        "Stat": "Average"
      },
      "Label": "Provisioned",
      "ReturnData": false
    },
    {
      "Id": "consumedRCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Cassandra",
          "MetricName": "ConsumedReadCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>"
            }
          ]
        },
        "Period": <period>,
        "Stat": "Sum"
      },
      "Label": "",
      "ReturnData": false
    },
    {
      "Id": "m1",
      "Expression": "consumedRCU/PERIOD(consumedRCU)",
      "Label": "Consumed RCUs",
      "ReturnData": false
    },
    {
      "Id": "utilizationPercentage",
      "Expression": "100*(m1/provisionedRCU)",
      "Label": "Utilization Percentage",
      "ReturnData": true
    }
  ],
  "StartTime": "<start-time>",
  "EndTime": "<end-time>",
  "ScanBy": "TimestampDescending",
  "MaxDatapoints": 24
}
```

Sobald Sie die Dateien erstellt haben, können Sie mit dem Abrufen der Nutzungsdaten beginnen.

1. Geben Sie den folgenden Befehl ein, um die Schreibauslastungsdaten abzurufen:

   ```
   aws cloudwatch get-metric-data --cli-input-json file://write-calc.json
   ```

1. Geben Sie den folgenden Befehl ein, um die Lesenutzungsdaten abzurufen:

   ```
   aws cloudwatch get-metric-data --cli-input-json file://read-calc.json
   ```

Das Ergebnis für beide Abfragen ist eine Reihe von Datenpunkten im JSON-Format, die für Analysen verwendet werden können. Ihre Ergebnisse hängen von der Anzahl der von Ihnen angegebenen Datenpunkte, dem Zeitraum und Ihren eigenen spezifischen Workload-Daten ab. Es könnte wie im folgenden Beispiel aussehen.

```
{
    "MetricDataResults": [
        {
            "Id": "utilizationPercentage",
            "Label": "Utilization Percentage",
            "Timestamps": [
                "2022-02-22T05:00:00+00:00",
                "2022-02-22T04:00:00+00:00",
                "2022-02-22T03:00:00+00:00",
                "2022-02-22T02:00:00+00:00",
                "2022-02-22T01:00:00+00:00",
                "2022-02-22T00:00:00+00:00",
                "2022-02-21T23:00:00+00:00"
            ],
            "Values": [
                91.55364583333333,
                55.066631944444445,
                2.6114930555555556,
                24.9496875,
                40.94725694444445,
                25.61819444444444,
                0.0
            ],
            "StatusCode": "Complete"
        }
    ],
    "Messages": []
}
```

**Anmerkung**  
Wenn Sie einen kurzen Zeitraum und einen langen Zeitraum angeben, müssen Sie möglicherweise den `MaxDatapoints` Wert ändern, der im Skript standardmäßig auf 24 gesetzt ist. Dies entspricht einem Datenpunkt pro Stunde und 24 pro Tag.

------
#### [ AWS-Managementkonsole ]

1. Melden Sie sich bei an AWS-Managementkonsole und navigieren Sie zur CloudWatch Serviceseite unter [Erste Schritte mit dem AWS-Managementkonsole](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Wählen Sie bei AWS-Region Bedarf das entsprechende aus.

1. Suchen Sie in der linken Navigationsleiste den Abschnitt Metriken und wählen Sie **Alle Metriken** aus.

1. Dadurch wird ein Dashboard mit zwei Bedienfeldern geöffnet. Im oberen Bereich wird die Grafik angezeigt, und im unteren Bereich befinden sich die Kennzahlen, die Sie grafisch darstellen möchten. Wählen Sie das Amazon Keyspaces-Panel.

1. Wählen Sie in den Unterfenstern die Kategorie **Tabellenmetriken** aus. Dies zeigt Ihnen die Tabellen in Ihrer aktuellen Version AWS-Region.

1. Ermitteln Sie Ihren Tabellennamen, indem Sie im Menü nach unten scrollen und die Metriken für Schreibvorgänge auswählen: `ConsumedWriteCapacityUnits` und `ProvisionedWriteCapacityUnits`.
**Anmerkung**  
In diesem Beispiel geht es um Metriken für Schreibvorgänge, Sie können diese Schritte jedoch auch verwenden, um die Metriken für Lesevorgänge grafisch darzustellen.

1. Wählen Sie die Registerkarte **Graphed metrics (2)** (Grafisch dargestellte Metriken (2)) aus, um die Formeln zu ändern. CloudWatch Wählt standardmäßig die statistische Funktion **Durchschnitt** für die Grafiken.

1. Wenn beide grafisch dargestellten Metriken ausgewählt sind (Kontrollkästchen auf der linken Seite), wählen Sie das Menü **Add math** (Math. hinzufügen), dann **Common** (Allgemein) und schließlich die Funktion **Percentage** (Prozent) aus. Wiederholen Sie den Vorgang zweimal.

   Wählen Sie zum ersten Mal die **Prozentfunktion** aus.

   Wählen Sie zum zweiten Mal die Funktion **Percentage** aus.

1. Zu diesem Zeitpunkt sollten vier Metriken im unteren Menü aufgeführt sein. Befassen wir uns nun mit der Berechnung von `ConsumedWriteCapacityUnits`. Um konsistent zu sein, müssen Sie die Namen mit denen abgleichen, die Sie im AWS CLI Abschnitt verwendet haben. Klicken Sie auf die **m1 ID** und ändern Sie diesen Wert in **consumedWCU**. 

1. Ändern Sie die Statistik von **Average** (Durchschnitt) in **Sum** (Summe). Diese Aktion erstellt automatisch eine weitere Metrik namens **ANOMALY\$1DETECTION\$1BAND**. **Im Rahmen dieses Verfahrens können Sie dies ignorieren, indem Sie das Kontrollkästchen für die neu generierte ad1-Metrik entfernen.**

1. Wiederholen Sie Schritt 8, um die **m2 ID** in **provisionedWCU** umzubenennen. Lassen Sie die Statistik auf **Average** (Durchschnitt) eingestellt.

1. **Wählen Sie das Label **Expression1** und aktualisieren Sie den Wert auf **m1** und das Label auf Consumed. WCUs**
**Anmerkung**  
Stellen Sie sicher, dass Sie nur **m1** (Kontrollkästchen links) und **provisionedWCU** ausgewählt haben, damit die Daten richtig angezeigt werden. Aktualisieren Sie die Formel, indem Sie auf **Details** klicken und die Formel in **consumedWCU/PERIOD(consumedWCU)** ändern. Durch diesen Schritt wird möglicherweise auch eine weitere **ANOMALY\$1DETECTION\$1BAND-Metrik** generiert, die Sie jedoch im Rahmen dieses Verfahrens ignorieren können.

1. Sie sollten jetzt über zwei Grafiken verfügen: eine, die Ihre bereitgestellten Daten in der Tabelle anzeigt, und eine andere, die WCUs den Verbrauch angibt. WCUs 

1. Aktualisieren Sie die Prozentformel, indem Sie die Grafik für Expression2 (**e2**) auswählen. Benennen Sie die Labels und in IDs **UtilizationPercentage** um. Benennen Sie die Formel so um, dass sie **100\$1(m1/provisionedWCU)** entspricht.

1. Entfernen Sie das Kontrollkästchen von allen Metriken außer **UtilizationPercentage, um Ihre Nutzungsmuster** zu visualisieren. Das Standardintervall ist auf 1 Minute festgelegt, Sie können es jedoch nach Bedarf ändern.

Die Ergebnisse, die Sie erhalten, hängen von den tatsächlichen Daten Ihres Workloads ab. Intervalle mit einer Auslastung von mehr als 100% sind anfällig für Fehler bei geringer Durchsatzkapazität. Amazon Keyspaces bietet [Burst-Kapazität](throughput-bursting.md), aber sobald die Burst-Kapazität erschöpft ist, treten bei Werten über 100% Fehler bei niedriger Durchsatzkapazität auf.

------

## So identifizieren Sie Amazon Keyspaces-Tabellen mit unzureichender Bereitstellung
<a name="CostOptimization_RightSizedProvisioning_UnderProvisionedTables"></a>

Bei den meisten Workloads gilt eine Tabelle als unzureichend bereitgestellt, wenn sie ständig mehr als 80% der bereitgestellten Kapazität beansprucht.

[Burst-Kapazität](throughput-bursting.md) ist eine Funktion von Amazon Keyspaces, mit der Kunden vorübergehend mehr RCUs/WCUs als ursprünglich bereitgestellt nutzen können (mehr als den bereitgestellten Durchsatz pro Sekunde, der für die Tabelle definiert wurde). Die Burst-Kapazität soll plötzliche Zunahmen des Datenverkehrs aufgrund von besonderen Ereignissen oder Auslastungsspitzen auffangen. Diese Burst-Kapazität ist begrenzt. Weitere Informationen finden Sie unter. [Effektive Nutzung von Burst-Kapazitäten in Amazon Keyspaces](throughput-bursting.md) Sobald die ungenutzten RCUs Kapazitäten aufgebraucht WCUs sind, kann es zu Durchsatzfehlern mit niedriger Kapazität kommen, wenn Sie versuchen, mehr Kapazität als die bereitgestellte Kapazität zu verbrauchen. Wenn sich Ihr Anwendungsdatenverkehr der Auslastungsrate von 80% nähert, ist das Risiko, dass Durchsatzfehler bei niedriger Kapazität auftreten, erheblich höher.

Die Regel der Auslastungsrate von 80 % hängt von der Saisonalität Ihrer Daten und dem Wachstums Ihres Datenverkehrs ab. Betrachten Sie folgende Szenarien: 
+ Wenn Ihr Datenverkehr in den letzten 12 Monaten bei einer Auslastung von \$1 90 % **stabil** war, hat Ihre Tabelle genau die richtige Kapazität.
+ Wenn Ihr Anwendungsdatenverkehr monatlich um 8 % **wächst**, werden Sie in weniger als 3 Monaten 100 % erreichen.
+ Auch wenn Ihr Anwendungsdatenverkehr monatlich um 5 % **wächst**, werden Sie in etwas mehr als 4 Monaten 100 % erreichen.

Die Ergebnisse der obigen Abfragen vermitteln ein Bild Ihrer Auslastungsrate. Verwenden Sie sie als Orientierungshilfe für die Auswertung weiterer Metriken, die bei der Entscheidung, Ihre Tabellenkapazität nach Bedarf zu erhöhen, hilfreich sein können (z. B. monatliche oder wöchentliche Wachstumsrate). Legen Sie gemeinsam mit Ihrem Operations-Team fest, welcher Prozentsatz für Ihren Workload und Ihre Tabellen geeignet ist.

Es gibt spezielle Szenarien, in denen die Daten verzerrt sind, wenn Sie sie täglich oder wöchentlich analysieren. Beispielsweise könnten Sie bei saisonalen Anwendungen, die während der Arbeitszeit stark ausgelastet sind (aber außerhalb der Geschäftszeiten auf nahezu Null sinken), von der [Planung der auto-scaling der Anwendung](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) profitieren, bei der Sie die Tageszeiten (und Wochentage) angeben, um die bereitgestellte Kapazität zu erhöhen, sowie den Zeitpunkt, zu dem sie reduziert werden soll. Anstatt eine höhere Kapazität anzustreben, um die geschäftigen Zeiten abzudecken, können Sie auch von den [auto-scaling Skalierungskonfigurationen der Amazon Keyspaces-Tabellen](autoscaling.md) profitieren, wenn Ihre Saisonalität weniger ausgeprägt ist.

## So identifizieren Sie übermäßig bereitgestellte Amazon Keyspaces-Tabellen
<a name="CostOptimization_RightSizedProvisioning_OverProvisionedTables"></a>

Die mit den obigen Skripts erhaltenen Abfrageergebnisse liefern die für eine erste Analyse erforderlichen Datenpunkte. Wenn Ihr Datensatz für mehrere Intervalle Auslastungswerte von weniger als 20 % aufweist, wurde für Ihre Tabelle möglicherweise zu viel Kapazität bereitgestellt. Um genauer zu definieren, ob Sie die Anzahl von WCUs und RCUS reduzieren müssen, sollten Sie die anderen Messwerte in den Intervallen erneut überprüfen.

Wenn Ihre Tabelle mehrere niedrige Nutzungsintervalle enthält, können Sie von der Verwendung von Application Auto Scaling-Richtlinien profitieren, indem Sie entweder Application Auto Scaling planen oder einfach die standardmäßigen Application Auto Scaling Scaling-Richtlinien für die Tabelle konfigurieren, die auf der Auslastung basieren.

Wenn Sie eine Arbeitslast mit einem niedrigen Verhältnis zwischen Auslastung und hoher Drosselung haben **(Max (ThrottleEventsThrottleEvents) /Min (**) im Intervall), kann dies passieren, wenn Sie eine sehr hohe Arbeitslast haben, bei der der Verkehr an bestimmten Tagen (oder Tageszeiten) erheblich zunimmt, ansonsten aber konstant niedrig ist. In diesen Szenarien kann es von Vorteil sein, [geplantes Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) zu verwenden.