Amazon Elastic Kubernetes Service（EKS）における動的ワークロードは、通常、需要に応じて自動的にデプロイ、スケーリング、および終了されるコンテナ化されたマイクロサービスで構成されています。EKSにおけるバックアップ戦略では、永続データ（例：ポッドにアタッチされたボリューム）とクラスターの状態（例：デプロイメント、サービス、コンフィグマップ）の両方を考慮する必要があります。VeleroやEBSと統合されたAWS Backupなどのツールは永続ボリュームのデータを取得できますが、クラスター構成の復元には、GitOpsの実践やHelm、TerraformなどのIaCツールがよく使用されます。バックアップソリューションは、動的に変化するネームスペース、ボリューム、ノードグループを識別し、追跡できる必要があります。
AWS Lambda
AWS Lambda関数は本質的に一時的かつステートレスですが、S3、DynamoDB、SQSなどの動的なデータソースに関連付けられたイベントを処理したり、トリガーしたりすることがよくあります。Lambdaベースのワークロードに対するバックアップ戦略は、関連するデータや構成アーティファクト（関数コード、環境変数、IAMロール、イベントソースのマッピング）の保護に重点を置きます。AWS CloudFormation または AWS Serverless Application Model (SAM) を使用して、インフラストラクチャをコードとしてキャプチャできます。誤削除やデプロイエラーが発生した場合に迅速な復旧を確実にするためには、関数定義の定期的なエクスポートとバージョン管理が不可欠です。
オートスケーリンググループ（ASG）を使用したAmazon EC2
オートスケーリンググループ（ASG）は、定義されたポリシーに基づいてEC2インスタンスを起動および終了させるため、アクティブなリソースのセットは非常に動的になります。ASGインスタンスは頻繁に置き換えられるため、バックアップは、基盤となる起動テンプレート、構成ファイル、およびEBSボリュームのような永続ストレージに重点を置きます。AWS BackupおよびDLMを使用すると、タグベースのポリシーを使用してEBSボリュームのスナップショットを自動化できます。バックアップ戦略では、起動構成で使用されるゴールデンAMIに加え、共有ボリュームや外部データベースに保存されていないインスタンス固有のデータも確実に取得する必要があります。
サーバーレス AWS ワークロード
サーバーレスアーキテクチャでは、Lambda、API Gateway、Step Functions、DynamoDB、S3 などの複数のマネージドサービスが、疎結合なアプリケーションとして組み合わされることがよくあります。これらのワークロードをバックアップするには、マルチサービスアプローチが必要です。各コンポーネントの状態と構成に加え、DynamoDBテーブルやS3バケットなどのデータ永続化レイヤーもキャプチャする必要があります。DynamoDB PITRやS3レプリケーションが一般的に使用されます。IaCやアプリケーションテンプレート（例：AWS CloudFormation StackSets）をサポートするツールはアーキテクチャ定義の保持に役立ち、AWS Backupのような集中管理型サービスは、対応している場合、データ保護を処理できます。
