こんな構成があるとします。Batchがあると思いますが、要件が合わずこの構成では1台のEC2インスタンスでバッチ処理を定期的に実行しています。EC2に障害があった場合どうしましょうか。SNSで通知を飛ばして再起動なりAMIから復旧なりや、あらかじめHAクラスター製品を導入しておくなどいろいろ考えられますよね。Automatorで??ワタシは思いつきました。Automatorなら冗長化してるぽできるんじゃね??」と。実際にやってみた実際にやってみました。Automatorのジョブを含めるとこんな感じの構成。1つずつ見ていきましょう。AWS環境EC2EC2を2台用意しました。検証用途なのでAmazonLinux2のt3.microです。今回は間違えて同じAZに構築してしまいましたが、異なるAZに配置するのがよいです。インスタンスでコマンドを実行」はSSMのRunCommandを利用するため、インスタンスにSSMエージェントをインストール・適切なIAMロールを付与し、またインターネットもしくはVPCエンドポイント経由でSSMと通信できる必要があります。AutomatorでSQSを使用します。2つのSQSキューを作成しておきます。Automatorのジョブは3つ作成しました。検証のためHTTPトリガーとしてます。SSMのRunCommand経由でインスタンスにて指定のコマンドを実行します。本番環境ではバッチ処理を実行するコマンドとなります。「する」の場合、インスタンス内で実行されたコマンドの終了ステータスによってジョブの成功/失敗を判断できます。インスタンスへ接続出来ずに失敗とみなすまでのタイムアウト秒数。デフォルトは900秒なので指定しません。本番環境ではせめてEメール後処理くらいあってもよいかも。SQS後処理で指定のSQSキューにメッセージを送信します。作成しておいたうちの1つを指定します。指定したSQSキュー内にメッセージがあるとそれをトリガーとします。ここではジョブ1のSQS後処理で指定したキューをトリガーとします。指定のインスタンスを起動します。SQS後処理で指定のSQSキューにメッセージを送信します。ジョブ1で指定したものとは別の残りの1つを指定します。バッチ用2の起動の失敗時にメール通知します。その後は手動で何とかするしかないですね。バッチ用2でコマンド実行バッチ用2でのRunCommand失敗時にバッチ用2を起動するジョブです。指定したSQSキュー内にメッセージがあるとそれをトリガーとします。ここではジョブ1のSQS後処理で指定したキューをトリガーとします。SSMのRunCommand経由でインスタンスにて指定のコマンドを実行します。本番環境ではバッチ処理を実行するコマンドとなります。「する」の場合、インスタンス内で実行されたコマンドの終了ステータスによってジョブの成功/失敗を判断できます。インスタンスへ接続出来ずに失敗とみなすまでのタイムアウト秒数。デフォルトは900秒なので指定しません。