2020/2/18追記 サポートに問い合わせたところ、ALBの不具合はロールバック済みで、cookie名を縮める対応は不要、とのことでした。試してみたところ、たしかにcookie名の指定をやめても問題なく認証できました。 AWSのApplication Load Balancerの認証機能を使って、スタッフからのアクセスのみ許可する社内向けウェブサービスを運用しているのだけど、昨日くらいからGoogle Chromeで認証が通らなないという声を聞くようになった。 現象としてはリダイレクトループが発生していて、コンソールを見るとSet-Cookie headerが長すぎるというエラーが出ていた。 Set-Cookie header is ignored in response from url: https://****/oauth2/idpresponse?code=e51b4cf0-8b
RedisやMongoDB、Kafka、Elasticsearchなどのオープンソースソフトウェアの開発元企業が、AWSなど大手クラウドベンダがそのオープンソースを用いたマネージドサービスを提供して大きな利益を上げていることに反発して、ライセンスを変更するなどで商用サービス化を制限する動きがあることは、今年の1月の記事で紹介しました。 Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発 この動きに対してGoogleは4月、Google Cloudにオープンソースベンダによるマネージドサービスを統合すると発表し、彼らとの戦略的提携という姿勢を打ち出しました。 ［速報］Google、大手クラウドに不満を表明していたMongoDB、RedisらOSSベンダと戦略的提携。Google Clou
SSRF対策としてAmazonから発表されたIMDSv2の効果と限界
サマリ Capital OneからのSSRF攻撃による大規模な情報漏えい等をうけて、Amazonはインスタンスメタデータに対する保護策としてInstance Metadata Service (IMDSv2) を発表した。本稿では、IMDSv2が生まれた背景、使い方、効果、限界を説明した上で、SSRF対策におけるIMDSv2の位置づけについて説明する。 SSRFとは SSRFは、下図のように「外部から直接アクセスできないエンドポイント」に対して、公開サーバーなどを踏み台としてアクセスする攻撃方法です。SSRF(Server Side Request Forgery)の詳細については過去記事「SSRF(Server Side Request Forgery)徹底入門」を参照ください。 最終的な攻撃目標は多様ですが、近年問題になっているのが、クラウドサービスのインスタンス・メタデータを取得する
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 みなさんこんにちは🎄 「フォトリ」という家族写真の撮影サービスを運用している会社でCTOをしてるカイトズズキと申します。 この記事では、先日会社のAWSで割と高額の請求が来てしまい😭死にたくなる思いをしたので、そのお話についてしていきます。 AWSは便利だけど、お金使いすぎたりしないか不安になりますよね。 特に僕はそんなにAWSには詳しくない人間なので、なおさらドキドキです。 この記事を通して、僕がやっちまった失敗をみなさんに知ってもらい、 同じような失敗をする人が1人でも減ることを祈ってます🙏 やらかした話 やらかしレベル
Distributed assault hampering connectivity for websites, apps, customers are warned Updated Parts of Amazon Web Services were effectively shoved off the internet today – at times breaking some customers' websites – after the cloud giant came under attack. Unlucky netizens were intermittently unable to reach sites and other online services relying on the internet goliath's technology as a result of
サーバーワークスは、2019年8月23日（金）にAWS東京リージョン(AP-NORTHEAST-1) で発生した障害を受け、障害の概要と今後ビジネスに影響を及ぼさないための対策をまとめたホワイトペーパーを公開いたしました。 ■背景 東京リージョンの1つのアベイラビリティゾーンで発生した、制御システムの複合的な不具合によって、いくつかのAWSサービスが影響を受けました。 ECサイトやゲームを含む国内多数のサービスにも影響が生じ、クラウド利用に対する不安が広がりました。今回のような障害に備えるためには、提供しているサービスの稼働レベルを考慮した上で最適な構成を選ぶことが求められます。 当社はAWSのプレミアコンサルティングパートナーの視点で障害発生時からホームページ等で障害に対するお知らせや提言を公開してまいりました。今回それらをまとめ対策として解説することで、お客様のクラウド環境最適化に寄与
Netcraftは、2019年5月13日頃にユニクロのオーストラリア向けオンラインショップが改ざんされ、画面上で入力する様々な情報が外部へ流出する可能性があったと報告しました。データの送信先や改ざんの手口から、RiskIQなども発表していたmagecartによる攻撃を受けたとみられます。 その後レポートは更新され、ファーストリテイリングより提供を受けた情報を元に、実際にはカード情報を含む顧客データが盗まれた可能性は低いと訂正されました。ここでは関連する情報をまとめます。 ユニクロオーストラリアの侵害 2019年8月29日、Netcraftが調査レポートを公開した。 news.netcraft.com Netcraftが事態を認知したのは2019年5月18日。 オンラインショップ利用者の情報が影響を受ける可能性があった。 発表当初はカード情報が必ず窃取される報告だったが、その後その可能性は低
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする 中山（順）です 先日に東京リージョンで比較的規模の大きな障害が発生いたしました。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 障害の影響は特定のAZに限られていたことは上記の公式メッセージで説明されているとおりです。 また、障害発生の早い段階で単一のAvailability Zoneで問題が発生していることがService Health Dashboardでアナウンスされていました。 しかし、Design for Failureの原則に基づいてリソースを複数のAvailability Zoneで冗長化してるケースでも何らかの影響を
AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告 2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは追加の報告を行い、複数のアベイラビリティゾーンで稼働していたアプリケーションでも障害の影響があったことを認めました。 下記は大規模障害の報告ページです。赤枠で囲った部分が、8月28日付けで追記されました。 当初の報告は、障害の原因が空調装置のバグであり、それが引き金となってサーバーのオーバーヒートが発生したことなどが説明されていました。 そして障害の影響範囲は単一のアベイラビリティゾーンに閉じており、 複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。 と説明されていました。 複数のアベイ
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
米アマゾン ウェブ サービス（Amazon Web Services）は2019年8月23日に発生したクラウドサービス「Amazon Web Services（AWS）」東京リージョンの大規模障害に関して同月28日、新しい報告をWebサイトに掲示した。障害が発生したサービスを追加したほか、利用企業が複数のアベイラビリティーゾーン（独立性の高いデータセンター群、AZ）横断の冗長構成にしたシステムにも一部で障害（予期せぬ影響）があったと認めた。 障害が発生していたサービスとして追加したのは日経 xTECHの既報の通り、アプリケーションロードバランサーの「Amazon ALB」、インメモリーキャッシュの「Amazon ElastiCache」、データウエアハウスの「Amazon Redshift」、仮想デスクトップの「Amazon Workspaces」などだ。仮想マシンの「Amazon EC2
2019年8月23日 13時頃からAmazon AWS 東京リージョン でシステム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。 AWSの障害報告 aws.amazon.com AWS障害の状況 障害発生時間（EC２） 約６時間 2019年8月23日 12時36分頃～18時30分頃（大部分の復旧） 障害発生時間（RDS） 約９時間半 2019年8月23日 12時36分頃～22時5分頃 障害原因（EC２） 一部EC2サーバーのオーバーヒートによる停止 制御システム障害により冷却システムが故障したことに起因 影響範囲 東京リージョン（AP-NORTHEAST-1）の単一のAZに存在する一部EC2、EBS、およびRDS。 発生リージョンは東京。東京近郊４データセンター群の内、1つで発生。 日本国内のAWSの契約先は数十万件とみられる。*
Summary of the Amazon EC2 Issues in the Asia Pacific (Tokyo) Region (AP-NORTHEAST-1)
2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご
8月23日午後1時ごろに発生した、米Amazon Web Servicesのクラウドサービス「AWS」の東京リージョンでの障害について、同社は午後8時18分、クラウドサーバの復旧がほぼ完了したことを明らかにした。制御システムの障害により、サーバの温度が上がりすぎたことが原因だったという。 同社によると問題が起きたのは、「Amazon Elastic Compute Cloud」（EC2）の東京リージョンを構成する4つのデータセンター（アベイラビリティーゾーン、AZ）の内の1カ所。AZ内の制御システムに問題が発生し、複数の冗長化冷却システムに障害が起きたという。結果として、AZ内の少数のEC2サーバが過熱状態となり、障害として表面化したとしている。 冷却システムは午後3時21分に復旧。午後6時30分までに、ほぼ全てのストレージ（EBSボリューム）とインスタンスが復旧したという。 同社は、障害
米アマゾン・ドット・コムが運営するクラウドサービス「アマゾン・ウェブ・サービス（AWS）」で23日、大規模なシステム障害が発生し、影響は広範囲に広がった。同社によると、同サービスを提供している東京近郊の4群あるデータセンターのうちの1つで問題が起きたという。障害が起きた原因は特定されたとしており、アマゾンによると午後10時すぎに復旧したとしている。ソフトバンクグループ傘下でスマートフォン決済を
2019年のAmazon Prime Day。AWS上の42万6000台相当のサーバや1900個のデータベースインスタンスなどで乗り切る
2019年のAmazon Prime Day。AWS上の42万6000台相当のサーバや1900個のデータベースインスタンスなどで乗り切る Amazonは毎年、プライム会員向けのセールである「Amazon Prime Day」を開催しています。2019年のPrime Dayも、7月15日と16日の2日間行われました。 Amazon Prime Dayは世界各国で同じ日に行われているため、国ごとの時差はあるものの開催期間中はものすごい勢いでプライム会員がAmazonのECサイトにアクセスを繰り返します。Amazon Prime Dayが世界最大級のオンライントランザクションが発生するイベントであることに異論を唱える人はいないでしょう。 そのECサイトの基盤を支えているのがAmazon Web Services（AWS）です。 AWSのチーフエバンジェリストJeff Bar氏は、ブログ「Amaz
Amazon Web Services（以下AWS）は、SQL互換の新しい問い合わせ言語およびそのリファレンス実装である「PartiQL」をオープンソースとして公開したことを発表しました。 PartiQLはSQL互換の構文に最小限の拡張を施すことで、リレーショナル形式のデータベースだけでなく、KVSやJSONなどを含むNoSQLデータベースやCSVファイルなど、さまざまなデータソースに対して横断的に検索できる問い合わせ言語およびそのリファレンス実装です。 下記はPartiQLを発表したブログからの引用です。 Today we are happy to announce PartiQL, a SQL-compatible query language that makes it easy to efficiently query data, regardless of where or in
マネージドサービスについて AWSなどが提供するマネージドサービスを使うかどうかは利用者側の状況にひとえに依存すると思う。 まず気にするべきポイントは、マネージドサービスを使うことで得られるメリットを明確にすることだ。一般に、マネージドサービスはインフラストラクチャからよりアプリケーションに近いレイヤ、多くの場合特定のミドルウェアまで、を抱合して提供してくれるため、運用面での負担が減る。できるだけ利用する方がよいと思う。一方で、運用のやり方やスタイルは提供者側の目線にあわせないといけない。ここにギャップが生まれやすい。理由としては、提供者側の気にする点が全体最適化のうえでベストエフォートで提供できるラインはどこか・そのうえで提示できるSLAがどこにあるか、なのに対して、利用者側の気にする点はミクロな視点で特定リソースが安全に継続可能性が十分にある状態で妥当なコストで利用できるか、の違いがあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
