ALB, CloudFront がインターフェースにある場合のメンテナンス切り替え方法をまとめました。

https://aws.amazon.com/jp/about-aws/whats-new/2022/02/amazon-cloudfront-managed-prefix-list/

VPC が CloudFront のマネージドプリフィックスリストをサポートするようになりました。
これにより CloudFront からのアクセスをセキュリティグループルールベースでアクセス制限できるようになります。

2022-01-15 11:40 頃 AWS ElastiCache (ap-northeast-1) のいくつかの node で CPU 使用率が 100 % を優に超える値を記録する事象が確認されました。

状況整理し特段ユーザ影響がないことを確認しています。

CPU 使用率上昇時の状況整理

• Service Health Dashboard には特に記録なし
• キャッシュヒット率が一時的に92% → 78% (-14%) 程度下がった
• アプリケーションの Redis 利用箇所で 5xx エラーはなし
• Redis を利用する worker のジョブも影響なし
• エンジン CPU 使用率 (=Redis エンジンスレッドの CPU 使用率) が低いことから Redis の処理自体の影響はないと思われる
• CPU 使用率 (Redis 以外のホスト全体の CPU 使用率) が高騰したことから、 AWS 側でホストに対する更新があったと思われる
  • この辺の影響だろうか？
    https://aws.amazon.com/jp/about-aws/whats-new/2022/01/amazon-elasticache-streaming-storing-redis-engine-logs/

参考: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/CacheMetrics.Redis.html

TODO: サポート問い合わせし、追記します。

AWS サポートに問い合わせた結果

メトリクスのバグとのことでした。（ほっ）

aws_rds_cluster の kms_key_id は Optional (任意) ですが、
これを設定するとどんなメリットがあるか考えたいと思います。

以前 AWS EC2 メンテ通知のイベントチェックスクリプトを作成しました。
合わせて、対象インスタンスを停止・起動する様にしました。

AWS [Retirement Notification] 対応

概要とある日、AWS よりこんなメール通知が来ました。 要約するとホストしている基盤のハードウェアで回復不可能な障害が検知されたので指定期限までに対応しないとインスタンスが停止する、とのこと。 今回こちらの対応をまとめました。 12345678910111213141516171…

これを AWS Lamda で Slack 通知させる様にし
毎朝メンテの必要なイベントがわかる様にしました。

事前準備

1
2

macOS%$ pip install lambda-uploader awscli
macOS%$ aws configure --profile <profile>

プロジェクト clone

1
2
3
4
5
6
7
8

macOS%$ git clone https://github.com/kenzo0107/AWSEC2Events2Slack
macOS%$ tree AWSEC2Events2Slack
.
├── README.md
├── event.json
├── lambda.json
├── lambda_function.py
└── requirements.txt

各種環境に合わせて情報編集

• lambda.json

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
    "name": "AWSEvent2Slack",
    "description": "Notificate AWS events to Slack",
    "region": "ap-northeast-1",
    "handler": "lambda_function.lambda_handler",
    "role": "arn:aws:iam::xxxxxxxxxxxx:role/lambda-check-events-to-slack",
    "timeout": 60,
    "memory": 128,
    "variables":
    {
        "SLACK_INCOMING_WEBHOOK":"https://hooks.slack.com/services/XXXXXXXXX/XXXXXXXXX/XXXXXXXXXXXXXXXXXXXXXXXX",
        "SLACK_CHANNEL":"#channel",
        "SLACK_USERNAME":"AWSEvent2Slack",
        "SLACK_ICON_URL":"http://i.imgur.com/6RCTdfi.png"
    }
}

AWS Lambda へソースアップロード

1
2
3
4
5

macOS%$ lambda-uploader --profile <profile>

λ Building Package
λ Uploading Package
λ Fin

AWSコンソールより Lambda 確認

登録されていることがわかります。

テスト実行

イベントを取得しSlackに通知させる様にすることができました。

トリガー設定

CloudWatch スケジュール式で cron 設定し 毎朝届ける様に指定しました。

総評

lambda-uploader でのアップロードにより
ローカルで開発→テスト→デプロイ
とバージョン管理が明確になって良いです。

但し、一点気になる点はアップロード後、ソースがコンソール上で見えません。

具体的には

Lambda 関数 「AWSEvent2Slack」のデプロイパッケージが大きすぎて、インラインコード編集を有効にできません。ただし、関数を今すぐ呼び出すことはできます。

とコンソール上に表示されます。

前まで zip にまとめてアップロードするシェルを書いていたけど
その時はソースは見ることができました。

ローカルで挙動確認しておりコンソール上では見えなくても今のところ支障なしです。

以上
参考になれば何よりです。