弊社クラスメソッド株式会社主催のイベント「Developers.IO 2019 TOKYO」での登壇資料です。 セキュリティ対策メガ盛りマックス ブログ: https://dev.classmethod.jp/cloud/aws/developers-io-2019-tokyo-all-security-in-aws/ ハッシュタグ: #cmdevio ブログの方に喋った内容の補足など入れてあります ちなみにブログをシェアしてくれると喜びマックス
![AWSでのセキュリティ対策全部盛り[初級から中級まで]](https://cdn-ak-scissors.b.st-hatena.com/image/square/b014e56d2eedba5a43b5c5f7524c22b8b030d6e1/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Faba22209644646ee9ff21ef72d5a439d%2Fslide_0.jpg%3F14040252)
3行で シンプル/ミニマルな Lambda のデプロイツール lambroll を書いてるよ Lambda API 以外は極力触らないやつです 既存 function の移行も簡単です 開発の経緯 AWS Lambda を管理、デプロイするのに数年来 Apex を使っていましたが、最近更新がないと思っていたら案の定というか、残念ながら No longer maintained となってしまいました。 で、代替を探したのですが… Lambda管理、Apexがお亡くなりになってServerlessかSAMになるんだけど、本当は関数だけdeployできればよくて(IAMとか関連リソースはTerraformでやるんで)、それなら裏でCloudFormationが動くようなのじゃないシンプルなのがいいなあ。作れば作れるけどデプロイツールばっかり書くことになるな…— fujiwara (@fujiwa
2019年8月2日、インフラストラクチャエンジニアやネットワークエンジニア向けの勉強会「インフラ・ネットワークエンジニア勉強会」がアイスタイル株式会社で開催されました。同会では、AWSに関するインフラ・ネットワーク視点の話や、オンプレ環境の話など、過去の事例を共有。6人のエンジニアが成功・失敗談をシェアしました。「ネットワークしくじり先生」に登壇したのは、kaga氏。講演資料はこちら ネットワークしくじり先生 kaga氏:それでは、「ネットワーク設計アンチパターン」という話をさせていただきます……と思ったんですけれども、ちょっとタイトルが堅いので「ネットワークしくじり先生」に、ちょっとやさしい雰囲気に変えたので、肩の力を抜いて聞いていただければなと思います。よろしくお願いします。 (会場拍手) 自己紹介です。kagaといいます。もともとQAを5年やって、サーバサイドを3年やって、今はインフ
{"name": "佐藤", "age": 22, "edu-background": "Hoge University"}, {"name": "鈴木", "age": 24, "edu-background": "Fuga University", "foreign-lang": ["English", "Spanish"]}, {"name": "髙橋", "age": 25, "edu-background": "Fuga University", "foreign-lang": ["English"], "written-book": ["Intro to DB"]}, {"name": "田中", "age": 33, "edu-background": "Foo University", "written-book": ["Intro to Java", "Advanced
AWS Dev Day は AWS がお届けする開発エンジニアのための日本最大級のカンファレンスです。例年は集合形式で開催してきましたが、今年はオンラインイベントとして再構築し、2020 年 10 月 20 日 (火) ~ 22 日 (木) に開催されました。エンジニアの皆様の役に立つコンテンツを満載し、オンラインだからこそできる新たな形を追求しました。エンジニアにとってロールモデルとなるスピーカーがそろったキーノート、ユースケースが多数そろった実践的なコンテンツが集結したブレイクアウトセッション、そしてワークショップ。いずれも見逃せないコンテンツばかりです。 このたび、オンデマンド視聴の許諾のある 59 のコンテンツを一挙公開することとなりました(一部は期間限定公開となります)。ぜひ、今おさえておくべきトピックを網羅し、皆様のスキルアップにお役立てください。 主催:アマゾン ウェブ サー
Terraform入門資料(v0.12.0対応) ~基本知識から設計や運用、知っておくべきtipsまで~AWSIaCTerraformインフラのコード化 はじめに 今日は体調がよろしくないので、大人しく勉強会用のTerraform入門資料をしこしこ作る。。オライリーのIaC本読み返しながら — nari@BOOTHで好評発売中「GoとAWS CDKで作る本格SlackBot入門」 (@fukubaka0825) October 6, 2019 こんにちは。[Wano株式会社] (https://wano.co.jp/)の[nari](https://twitter.com/fukubaka0825)と申します。 本日、WanoグループでTerraform入門をテーマとした勉強会を行いました。 その際使用した勉強資料を、Qiitaに一般公開いたします。 対象参加者(読者) インフラのコード化
全体図 WebAPIを2つ、Lambdaを2つ、DynamoDBを1つ作ります。 ※Lambdaコードは省略します。DynamoDBは作るだけです。 AWS CDKプロジェクトの構築 $ mkdir AWSCDK-ResourceNameSample $ cd AWSCDK-ResourceNameSample $ cdk init app --language=typescript 必要なライブラリをインストールします。 $ npm install --save @aws-cdk/aws-apigateway $ npm install --save @aws-cdk/aws-lambda $ npm install --save @aws-cdk/aws-dynamodb リソース名を決めるロジックを作成する やりたかったのはこれですね。AWSリソース名の作成ロジックを行うファイルを作
概要 localstack を Git から Clone してそのまま使おうとしたらエラーで起動できなかったので対策をメモします。対象はmacOS利用者の方になります。 ※手っ取り早く知りたい人は一番下の解決策の項目を見てください。 環境 macOS Mojave 10.14.5 Docker version 18.09.2 対策 エラー内容 docker-composeから起動した時のエラーメッセージは下記の内容になります。 $ docker-compose up Starting localstack_localstack_1 ... error ERROR: for localstack_localstack_1 Cannot start service localstack: b'Mounts denied: The path /var/folders/p2/fwlptfcs3h5
AWS障害、“マルチAZ”なら大丈夫だったのか? インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」(1/3 ページ) 8月23日に起きたクラウドサービス「AWS」(Amazon Web Services)の東京リージョンでの障害は、国内のさまざまなサービスに影響を及ぼした。 AWSが同日午後8時ごろに復旧するまで、モバイル決済サービス「PayPay」や、仮想通貨取引所「Zaif」、オンラインゲーム「アズールレーン」などで利用できない、もしくは利用しづらい状況が続いた。PCショップの「ドスパラ」はECサイトの不具合が長引き、翌日の24日には実店舗を臨時休業して対応に当たっていた。 AWSという1つのサービス障害が起きただけで、多くの企業やサービスに影響を及ぼしたため、「クラウドサービスはもろい」という論調も散見された。 しかし、インフラエンジニアたちからは違う意見が聞こえてくる
アドテク本部の黒崎( @kuro_m88 )です。 2019/08/23にAWSの東京リージョンで特定のAZ内で大きめの障害がありました。 私が開発しているプロダクトもAWSの東京リージョンを利用していて、常時数百インスタンスが稼働しているため、今回の障害の影響範囲に含まれていました。 何が起きたのか? AWSから公式発表が出ています。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 データセンタ内の冷却の障害が原因で一部のハードウェアホストが過熱し電源が失われてしまったようです。これにより影響を受けたハードウェアホスト上で稼働していたEC2インスタンスやEBSボリュームは電源が失われているため、外部から見ると突然応答がなくなったように見えました。 担当サービスでも公式発表と同じくらいの時刻にELBやその配下のサーバ
昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装(の予想) マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB(CLB)をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス(仮称)として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
先週の金曜日(2019/8/23)に発生したAWSの東京リージョンで大規模な障害が発生しました。障害の内容は、一つのAZで空調設備の問題からEC2インスタンス並びにEBSに問題が発生したという事象です。詳細についてはAWSから発表があるので、そちらをご参照ください。 aws.amazon.com 障害の最中にTwitterのタイムラインを見ていると、単一AZ障害ではなく複数のAZで障害が発生しているのではないかという観測が多く見られました。障害としては、AWSの発表通り単一AZ障害です。では何故多くの人に勘違いされたのでしょうか?理由は2つあります。 AZの割り当ては、アカウントごとに違うという事が知られていない マルチAZ構成にしていても、単一AZの障害の影響を受ける ここでは前者のAWSアカウントの割り当ての話を説明します。 あなたが見ているap-northeast-1aは、私が見てい
発生原因 ap-northeast-1a(ID:apne1-az4) に設置されたELBのノードが、5XXのエラー応答を戻していました。 暫定対処 ELB(ALB) で利用していたAWS WAFの保護設定を一時的に解除、ELB_5XXエラーが抑制された事を確認しました。 対応経緯 14:20 チャットの通知より、DevloppersIOのブログ基盤から HTTP 5XX の発生している事を確認 14:30 ElasticBeanstalkのダッシュボードの「WARN」イベントより、HTTP 5xx の発生状況を確認 CloudWatchの ALB ダッシュボードより、HTTP 5XX の発生状況を確認 ALBのCloudWatchメトリックより、ELBに起因する「ELB_5XX」エラーである事と、 AZ別のメトリックより ap-northeast-1a(ID:apne1-az4)、アベイア
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです (当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ?という人の認識も変えられると嬉しいです)。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください (一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います)。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
2019年7月24日、ヤフー株式会社が主催するサーバーサイドエンジニア向けの勉強会「Bonfire Backend #3」が開催されました。第3回となる今回のテーマは「モバイル決済の裏側」。急速に成長するモバイル決済分野でサービスを展開する企業が一堂に会し、自社サービスの仕組みや技術スタックなど、知られざる裏側を語ります。プレゼンテーション「静的MPM決済を支える技術 」に登壇したのは、株式会社メルペイのsusho氏。今年の6月にサービスが開始したばかりのメルペイのサーバーサイドの特徴と工夫について語ります。 静的MPM決済を支える技術 susho氏:こんばんは。「静的MPM決済を支える技術」ということでsushoが発表させていただきます。 最初に自己紹介です。 社内ではsushoと呼ばれているので、ここでもそうさせていただいております。Twitterは@susho0220でやっています。
こんにちは。こむろです。 今年の札幌の夏はハードモードだ(湿気と暑さ) この先生きのこるためにエアコンが投入されました。 はじめに クラウドネイティブなアプリケーションを設計・構築・運用している皆さんは、普段どのようにアプリケーションやインフラの更新作業を行っているでしょうか。 順次インスタンスやコンテナを切り替えていくRolling Update?それとも環境を複製してDNS Routingの切り替えによるBlue-Green Deploymentでしょうか。他にも様々な方法があるかと思いますが、今回もまたBlue-Green Deploymentにおける実際の現場で発生した事象について報告したいと思います。 あまりネット上にもこういった情報が出てこないようなのですが、皆さんこういった問題は軽々とクリアされているのでしょうか。自分がポンコツなだけなのかととても不安にかられるばかりです。
You can now attach multiple target groups to your Amazon ECS services that are running on either Amazon EC2 or AWS Fargate. Target groups are used to route requests to one or more registered targets when using a load balancer. Attaching multiple target groups to your service allows you to simplify infrastructure code, reduce costs and increase manageability of your ECS services. Previously, you co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く