タグ

AWSとトラブルに関するlocke-009のブックマーク (7)

  • Gmailに届かない神奈川県立高校入試のインターネット出願システムのメールを調べてみた | DevelopersIO

    Gmailに届かないと報告されている2024年神奈川県立高校入試の出願システム自動返信メール、 2024年1月15日にYahooメールに届いたメールヘッダー情報などから、送信ドメイン認証(SPF、DKIM、DMARC)の確認を試みました。 2024年2月の神奈川県立高校の受験を予定している家族から、 "インターネット出願システムの登録を試みたが、システムからの返信メールがGmailのアドレスが届かないため、代わりにYahooメールを利用した。" との報告を受けました。 今回、2024年1月15日にYahooメールで受信したインターネット出願システムのメールを調査する機会がありましたので、紹介させて頂きます。 2024年1月19日 追記 ネット出願システムの不具合解消後のメールの調査結果を公開しました。 2024年1月18日 追記 ネット出願システムのメールサーバ側の問題について調査結果を公

    Gmailに届かない神奈川県立高校入試のインターネット出願システムのメールを調べてみた | DevelopersIO
  • AWSコスト最適化:失敗編(CloudWatch アラーム定義増殖事件) - Qiita

    1. はじめに 今回は コスト最適化の勘所で記載した「6.持続したコスト管理の重要性」を疎かにしてしまったが故の失敗事例になります。 失敗事例というのは外部公開を忌避する事が多いかと思います。 しかし、失敗事例にこそ多くの学びがあるという思想の下、そういった事例もなるべく隠さず公開していこうと思います。 2. 背景 弊社の某システム(仮称:Aシステム)ではWebサーバをホストするEC2にオートスケールを採用しています。 スケールアウトしたEC2に対しても監視/通知が必要な為、スケールアウトしたEC2のカスタムメトリクスに対するアラーム定義を追加する処理を実装しています。このアラーム定義はEC2がスケールインすると不要になりますので、削除する処理も実装していました。 処理自体は AutoScalingGroup のイベントを EventBridge でフックし、Lambdaでアラーム定義を操

    AWSコスト最適化:失敗編(CloudWatch アラーム定義増殖事件) - Qiita
  • AWSにおけるアプリケーションのログ記録のベストプラクティス - Qiita

    はじめに アプリケーションログは、アプリケーションの動作状況をログファイルに記録するプロセスです。アプリケーションよって、この動作状況は1つ以上のファイルに記録することが多いです。このログファイルは、セキュリティとパフォーマンスの分析の実行、アプリの問題のトラブルシューティングなどに役立ちます。この記事では、ログ、ログの種類およびAWSのCloudwatLogsサービスについて説明したいと思います。 各個人によって好きなAWSサービスがそれぞれだと思います。これが正解という訳ではありませんが、参考にしてただければと思います。 対象者 AWSでログの記録に興味がある方。 AWSでワークロードを運用している担当者。 ログレベル ログレベルについて皆さんご存じだと思いますが、主に3種類のログがあります。 レベル 説明

    AWSにおけるアプリケーションのログ記録のベストプラクティス - Qiita
  • 本当にあったIT怖い話 AWSの設定ミスで300万円のコスト超過、1日1回だったはずの処理が1分で160万回に 当事者に聞く反省点

    当にあったIT怖い話 AWSの設定ミスで300万円のコスト超過、1日1回だったはずの処理が1分で160万回に 当事者に聞く反省点(1/3 ページ) バックアップデータがあると思って安心していたのに、いざ障害時に取得できていなかったことが発覚したり、ネットワークアクセスの制限を強化しようと設定をいじったら、自分すらアクセスできない状態にして手詰まりになったり……もっとヒヤッとする事態も含め、IT業界には「当にあった怖い話」がいろいろある。 クラウドサービスの利用料金がいつの間にかに膨大になる「クラウド破産」もその一つだ。検索してみると、便利だからとあれもこれもとクラウドサービスを利用していたら料金が想像以上に大きく膨らんでしまい、課金額を見て目を回した経験談がいくつかのブログにつづられている。 システムインテグレーションやセキュリティサービスを提供するラックも、そんな経験をしてしまった企

    本当にあったIT怖い話 AWSの設定ミスで300万円のコスト超過、1日1回だったはずの処理が1分で160万回に 当事者に聞く反省点
  • 【懺悔】稼働中の本番DBで殆どのテーブルをtruncateしてしまった話 - Qiita

    これは8年ほど前のある日のことです。 番環境のテーブルを淡々とtruncateし続けたことがあります。 リリース前などではなく、稼働中のサービスでした。 思い出せる限り、私のエンジニア歴において最大の「やらかし」です。 「そんなミスありえないだろ…」「どんだけ迂闊なんだよ」という感想を持たれる方もいらっしゃるかと思います。 むしろ、それが正常だと思います。しかし、当時の私はやってしまった。 ただ、それでエンジニアをやめるようなこともなく、現在では人を指導する機会も増えました。 どうしたらそんな事が起きるのか? その後、どのような対応が行われたのか? 教訓はなにか? この機に記させていただきたいと思います。 量産現場の社二病社員 当時働いていた職場では、「同じような機能を持ったスマートフォンアプリ」を量産する部署がありました。 私は、そこに配属されました。 当時、新卒2年目。社二病真っ只中

    【懺悔】稼働中の本番DBで殆どのテーブルをtruncateしてしまった話 - Qiita
  • API gateway + lambda + S3でDDoS攻撃を受けて1日あたりで$3000溶かした話 - Qiita

    qiita夏祭りに乗り遅れてしまったので一人後夜祭 ~2019年某日~ パイセン「それじゃあ、ワイ君は明日からフロントのログデータを飛ばすのにAPI gatewaylambdaでS3に保存するようにしてな。木曜までな。その間に自分はサービンのドメイン取ったりRoute53周りの構築するから」 ワイ「これもcloud formationに書くんです?」 パイセン「serverless frameworkっていう基的な設定はデフォルトで構築してくれる便利なものがあるんやで。これ使い」 ワイ「めっちゃ素敵やん。わかったやで」 パイセン「週初めのMTGは終わりや飯いに行こう。上野に新しい醤油ラーメン屋ができたんや」 ワイ「いいですね〜」 パイセン「それじゃ自分は新しいロードバイク持ってきたからワイ君も付いてきてな!」 ワイ「ワイ無手なんやが?え、気で漕初めやがった!こなくそおおおぉぉぉ!」

    API gateway + lambda + S3でDDoS攻撃を受けて1日あたりで$3000溶かした話 - Qiita
  • AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary

    情けない話ですが、自分の大チョンボで AWS の個人アカウントが第三者にアクセスされた結果 190万円相当のリソースが使われ、最終的に AWS さんに免除を頂きました。反省込みで件のまとめを書きます。 自分が馬鹿を幾つも重ねた結果であって、AWS 自体は怖くないというのが伝われば幸いです はじめにまとめ S3 実験してた時に SECRET KEY を見える場所に貼っていた事があり、第三者がそれでアクセスし大量の高性能インスタンスを全力で回す (恐らくBitCoin採掘) AWS さんから不正アクセスの連絡があり、急いで ACCESS KEY 無効&パスワード変更、インスタンス全停止、イメージ削除、ネットワーク削除 免除の承認フェーズを進めて、クレジットカードの引き落とし前に完了して助かる AWS さんのサポート AWS さんは最大限サポートしてくれました 承認フェーズが進まない時もあまり

    AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary
  • 1