営業部 佐竹です。 本日は、2021年9月2日 の 午前7時30分から午後1時42分までの間に発生していた「東京リージョンにおけるダイレクトコネクト（専用線：以下 DX と記載）障害に関する記事となります。 はじめに 影響範囲について 一時的な対応策 DX をダウンさせる 1-1. CGW で NIC を Shutdown する 1-2. 物理線を抜く 1-3. DX フェイルオーバーテストの実行 2021年10月5日 追記 BGP 設定で対応する 2-1. 広報経路を更新する その他の手法 参考情報 Personal Health Dashboard の履歴1 [4:00 PM PDT] [4:45 PM PDT] [6:49 PM PDT] [6:49 PM PDT] [9:56 PM PDT] Personal Health Dashboard の履歴2 [05:39 PM PDT]

スマートキャンプ、エンジニアの入山です。 前回のブログで、弊社プロダクトのインフラをEC2基盤からECS/Fargate基盤へ移行した話を紹介しました。 tech.smartcamp.co.jp 上記プロジェクトは大規模なインフラの刷新だったこともあり、CI/CDについても従来の仕組みからECS/Fargateの構成に合わせて変更しています。 CI/CDは、安定したプロダクト開発には必須且つ長期に渡って継続的に利用するものなので、いかにストレス少なく効率的に出来るかが重要だと考えています。 また、CI/CDは一度構築してしまうと放置されがちですが、日々の開発チーム全体の生産性にも大きな影響を与えるため、こういった数少ない再構築のタイミングではコストを掛ける価値があるのではないでしょうか。 今回は、弊社のインフラ移行時に実施したCI/CDの改善について紹介したいと思います。 従来のCI/CD

昨日、上野宣（@sen_u）さんがパスワードの総当りに要する時間の表をツイートされ、話題になっています。 総当たり攻撃時のパスワード最大解読時間の表を日本語化した。https://t.co/cVSNUZkAKv pic.twitter.com/rtS8ixwOqi — Sen UENO (@sen_u) August 17, 2021 1万件を超えるリツイートがありますね。大変よく読まれているようです。しかし、この表は何を計測したものでしょうか。上野さんにうかがってもわからないようでした。 何ですかね？パスワード空間が大きくなると解読に時間が掛かるということくらいがわかりますかね。 — Sen UENO (@sen_u) August 17, 2021 一般に、パスワードの総当たり攻撃（ブルートフォースアタック）というと、以下の二通りが考えられます。 ウェブサイト等でパスワードを順番に試す

再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス

中山（順）です EC2 Image Builderで利用するコンポーネントにおいてパラメーターを利用できるようになりました。 EC2 Image Builder now supports parameters in components for creating custom images 例えば、コンポーネントでインストールするソフトウェアのバージョン指定をしたい時、新しいバージョンを作成したりコンポーネントを作り分ける必要性がかなり減ると思います。 具体的には、以下のようにパラメーターを定義できるようになりました。 このドキュメントではインストールするAWS CLI v2のマイナーバージョンを指定できるようにしています（実際にドキュメントを記述するときには適切な検証等を行うようにしてください）。 name: AWS CLI version 2 description: Installs

いわさです。 AWS System Managerに Change Managerという機能があります。 変更タスクのテンプレートを事前準備し、そのテンプレートを使ってリクエストを送信後に承認者がリクエストを承認し、テンプレートで定義されたタスクが自動実行されるというものでした。 こちらの承認フローで、自動承認機能が実装されたので試してみました。 Now enable auto-approval of change requests and expedite changes with AWS Systems Manager Change Manager ユースケースとしては、変更に伴う影響の少ない作業における承認ステップの簡略化を目的としたもののようです。 テンプレート作成 テンプレート作成時に「リクエスト承認者を変更」の項目にChangeTemplate.Create.builder.a

ちゃだいん（@chazuke4649）です。 Amazon CloudWatch でクロスアカウントアラームが使用可能になりました！ Announcing Amazon CloudWatch cross account alarms Amazon CloudWatchは、クロスアカウントアラームを発表しました。これは、お客様がアラートを設定し、他のAWSアカウントのメトリクスの変更に基づいてアクションを実行できるようにする新機能です。クロスアカウントアラームは、さまざまなAWSアカウントの指標の傾向に基づいてアラートを提供し、既存のクロスアカウントダッシュボードと組み合わせて使用​​して、集中型モニタリングアカウントの運用の可視性を設定できます。クロスアカウントアラームでは、異なるAWSアカウントでトレンドとなっている指標が、運用上の問題を引き起こしたり、エンドユーザーの体験に影響を与えた

中山（順）＠リカバリー中 です Well-Architected Toolでワークロードを評価する際、何らかの事情で適用できないベストプラクティスがあると思います。 従来は質問毎に用意されたテキストボックスに入力して管理する必要がありました。 先日、質問に含まれる個々のベストプラクティス毎に適用できない理由を入力できるようになりました。 Mark individual best practices as not applicable within the AWS Well-Architected Tool やってみた 例えば、セキュリティに関する質問である "SEC 1. How do you securely operate your workload?" には、"Secure AWS account" というベストプラクティスがあります。 これの具体的な対策としては、ルートユーザーをM