AWSをはじめとするクラウドプラットフォームの普及に伴い、DevとOpsの境目はかなり曖昧になっています。その中でもIAMの管理は設定によっては権限昇格を引き起こしかねないことから、その管理権限は慎重な管理になりがちです。結果的に、IAMは属人的な管理を行っている組織が多いのではないでしょうか。 一方で、DevとOpsの境目がどんどん曖昧になっていく中で、IAMロールやIAMユーザーを自由に作りにくい状況があると大変不便です。IAM関係のトライ・アンド・エラーが手軽に行えないことから、開発速度の鈍化を引き起こしたり、アーキテクチャ設計の上で運用上の足かせとなったりといったことが起こります。 また、それらの問題を回避しようとした結果として、IAMロールやIAMユーザーの使い回しが横行しはじめるなど、結果的に最小権限の原則が守られなくなっていくことも少なくはないのではないでしょうか。最小権限の

JAWS-UG 浜松　AWS 勉強会 2021#2　2021/02/26

AWS SSOのコンソール画面を触ってると、「んん？？どういうこっちゃ??‍♂️」みたいに混乱することありませんか？画面に沿ってなんとなく設定はできたけど、どういう仕組みになっているかわからないというか… すみません、うまく言語化できていない自覚があるんですが、以下のような点がモヤモヤしています。 ユーザー&グループ、アカウント、アクセス権限セット各概念の関係性がわからない いや、俺はそもそもアクセス権限セットがどういうものなのか理解していないのでは？(モヤモヤ?) 今回はこのモヤモヤを解消するために、SSOの概念を図解していきたいと思います。SSOコンソール上での以下各操作によってどういうリソースが作成され、それぞれがどう動作するのかまとめます。 初期状態(SSO有効化前) SSOを有効化する ユーザーやグループを作成する アクセス権限セットを作成する アカウントにユーザー・グループを割

この記事は「本番環境でやらかしちゃった人 Advent Calendar 2020」24日目の記事です。 遠い昔、はるか彼方の銀河系での話です。 TL;DR IAMの権限はしっかりやりましょう。検証環境と本番環境でアカウントを分けるとより安心できます。 何をやらかしたのか やらかし前の状態 マッチングサービスの開発をしています。そのサービスにはサービス内でメッセージが届くとその旨をEメールで通知する機能があります。 システム的にはサービスを動かしているWebアプリケーションからSQSのメール用のキュー（以後Maill Queue）にメッセージを送信し、メール送信用のWorkerがMaill Queueからメッセージを取得、差出人やURLなどの情報を埋めてEメールを送信します。差出人やURLは本番環境、検証環境でそれぞれ別の値が入ります。 また検証環境と本番環境は同一のAWSアカウント内にあ

こんにちは、臼田です。 みなさん、AWSセキュリティやってますか？(挨拶 今回は開催中のre:Invent 2020にて発表された「AWSセキュリティのための10のこと」最新版について紹介します。 前置き 「AWSセキュリティのための10のこと」は実は昨年行われたre:Invent 2019にてAWSのCISOであるスティーブ・シュミット氏が発表していました。 その時の内容は以下AWSブログでも紹介されています。 AWS アカウントのセキュリティを改善するための 10 個の項目 | Amazon Web Services ブログ 上記では「AWSアカウントのセキュリティを改善するための10個の項目」というタイトルですが、長いので私は「AWSセキュリティのための10のこと」と勝手に表現しました。決して公式の表現ではないのでご容赦を。 で、上記は以下の10項目になっています。 アカウント情報を

コンバンハ、千葉（幸）です。 皆さんは、 PassRole と AssumeRole についてきちんと理解ができていますか？どちらも IAM ロールに関するものですね。 私はカラダ（ボディ）の調子がいい時は思い出せるのですが、雨が降っている日や、ちょっと疲れて気を抜いた時にはすぐ分からなくなってしまいます。 ということで、イメージとして脳に刻み付けることによって忘れられなくしてやろうと思いました。 そこで出来上がったのが以下です。 間違えました。以下です。 あ、でもやっぱり忘れづらいのはこちらかもしれませんね。 どうですか？もう忘れられなくなりましたね？ 先にまとめ IAM ロールには以下ポリシーを設定できる アイデンティティベースポリシー Permissions boundary 信頼ポリシー AWS リソースに IAM ロールを引き渡す際には PassRole の権限が必要 PassR

よく訓練されたアップル信者、都元です。Amazon S3について細かい説明は不要かと思いますが、要するにファイルストレージです。HTTPベースでファイルをアップロードでき、そしてダウンロードできるサービスですね。 古くから、データはシリアライズされた形式でファイルという単位に格納し、管理されてきました。ローカルマシン内でファイルを管理する仕組みがファイルシステムで、その多くにはフォルダという階層構造を扱う仕組みが備わっています。 Amazon S3も、Management Consoleによってフォルダを作成し、その中にさらにフォルダを作成したり、ファイルを格納できたりします。しかし。 Amazon S3には実はフォルダという概念は無い のです。Amazon S3の基礎技術は、単純なKVS（Key-Value型データストア）でしかありません。例えば下記のようなフォルダ（と我々が認識している

TL;DR Lambda がコンテナをサポートしたらしいので試してみる 動かすDocker イメージはLambda のAPI に対応させる必要があるため、今まで使用していたイメージがそのまま動くわけではない New for AWS Lambda – Container Image Support | AWS News Blog 概要 re:Invent の発表でコンテナの実行ができるようになったので、ざっくり試してみるだけの記事 ためす 失敗例 単純なAlpine イメージだと動かないらしいので失敗してみる ECR へコンテナを上げる env コマンドを実行するだけのイメージを作成 $ export ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text) $ cat <<EOL | docker b

AWS DevDay Online Japan 2020 の登壇資料です

>_cd /blog/id_213 development technology#AWS BillingDate2020-10-12Time00:00:00 JST サーバーレスアーキテクチャを採用する理由として、コスト削減が挙げられるケースをしばしば耳にします。しかし本当にコストは常に削減されるのでしょうか？ EC2に対するAWS Lambdaのコストのメリットを説明するために、以下のような図が用いられるケースがあります。 サーバーが起動していた時間に対して課金されるEC2に対して、AWS Lambdaはプログラムが実行された時間に対して課金されるため、最終的にはコストが最適化されることをこの図では説明しています。では、実際にどんな場合にでもコストは最適化・削減されているのかを見ていきましょう。 LambdaとEC2のコストを比較するトラフィックが少ないワークロードの場合月間2万リクエス

AWS Lambdaの環境がどのようになっているか、ユーザが用意したLambdaファンクションがどんな感じで実行されるかってあたりを可能な限り詳しく説明したいと思います。 はじめに 大前提 コールドスタート/ウォームスタート コントロールプレーン/データプレーン アイソレーション AWS Lambdaのコンポーネント群 同期実行かつ初回呼び出し（コールドスタート）、もしくはスケーリング 同期実行かつ再利用（ウォームスタート） 非同期実行 スケールアップ エラーハンドリング リトライ その他 ネットワーク まとめ はじめに この投稿は2020年9月29日の21時から開催予定のイベント（ライブストリーミング）で話す内容です。 serverless-newworld.connpass.com もし間に合えば、かつ時間があればぜひライブ配信のほうにも参加ください。 （2020.09.30 upda

Amazon Web Services(AWS)がクラウドのアーキテクチャ図を自動生成するソリューション実装「AWS Perspective」を公開しました。AWS Perspectiveを利用することによって、アーキテクチャ図の状態を常に最新に保ち、開発チーム内のシステム状況の共有を円滑に行うことができます。 AWS Perspective | Implementations | AWS Solutions https://aws.amazon.com/jp/solutions/implementations/aws-perspective/ AWS Perspectiveのページにある「Launch in the AWS Console」をクリックし、AWS Perspectiveの構築を始めます。 AWS PerspectiveはCloudFormationのテンプレートが提供されて

AWS でのワークロード検出 (旧称: AWS Perspective) は、AWS クラウドのワークロードを可視化するツールです。この AWS ソリューションを使用し、AWS からのライブデータに基づいて、ワークロードの詳細なアーキテクチャ図を作成、カスタマイズ、および共有できます。 このソリューションは、アカウントと AWS リージョン全体の AWS リソースのインベントリを維持し、それらの間の関係をマッピングし、それらをウェブユーザーインターフェイス (UI) に表示します。 このソリューションには、コストが発生している可能性のある AWS リソースやサービスを検索できるコストクエリビルダーも付属しています。予想コストデータは、指定された期間について自動的に計算され、アーキテクチャ図に表示されます。予想コストの概要を含むアーキテクチャ図のコストレポートを生成し、それらを CSV でエ

CloudFront と S3 を使ってサーバーレスなウェブサイトを構築し、特定のユーザーにのみ公開するために Google, GitHub など外部の認証プロバイダ (IdP) を使って認証をおこなう方法です。CloudFront ではリクエスト中継時に Lambda 関数を実行し認証などの処理をおこなうことができるため、それを使うことにします。 OpenID Connect による認証シーケンス CloudFront にアクセスした際のシーケンスは以下のようになります。 構築手順 OpenID Connect (OIDC) による認証をおこなう Lambda 関数を Widen/cloudfront-auth というツールを使って生成します。様々な認証プロバイダに対応していますが、ここでは Google で認証し、特定ドメインのメールアドレスのユーザーのみをアクセス許可してみます。 ※

タイトルについて 妄想ですが、 何らかの理由によりEC2をStopさせたいにも関わらず、 Webコンソールにアクセスできず、 AWS CLI とか AWS SDK とかインストールできず、 サポートに電話することもままらない状況だけど、 運良く AWS_ACCESS_KEY と AWS_SECRET_ACCESS_KEY は知っていて、 たまたま curl（と他に必要なコマンド群）は使える環境であれば何とかできるTipsです。 普通、そんな状況にはならない。 少しまじめに AWS CLI や AWS SDK を使わないケース自体は↓のようなものがあります 使用する必要のある機能が、AWS SDK または CLI でサポートされていないため。これは一般的ではありませんが、新しいサービス機能がリリースされてから、すべての AWS SDK でその機能がサポートされるまで、多少時間がかかることが

利用可能なリージョン 2020年8月14日現在、Amazon Braketは以下のリージョンで提供されています。 us-east-1(N.Virginia) us-west-1(N.California) us-west-2(Oregon) 後述しますが、これらはそれぞれAmazon Braketのエンドポイントがあるリージョンとなっています。 早速触ってみた 何はともあれ、ようやくAmazon Braketが一般提供されて触れるようになったので、早速触ってみました。 今回やってみたこととしては、以下になります。 Amazon Braketの有効化 ノートブックインスタンスの作成 D-Waveのチュートリアルを試してタスクの作成 Amazon Braketの有効化(初回) まず、Amazon Braketを利用する為にはAmazon Braketの有効化が必要となっています。 利用可能リー

ログ分析勉強会では、「ログ分析」に関わるすべての技術、事例、知見を共有し、日々の業務に役立てられる情報交換ができる場所を目的として活動。初のオンライン開催となった今回、NTTドコモサービスイノベーション部の千田拓矢氏が、AWS純正サーバーレスなログ分析基盤を構築する方法を解説しました。関連資料はこちら。 AWSのサーバーレスサービスでセキュリティのログ分析 千田拓矢氏：それでは始めたいと思います。AWSのサーバーレスサービスでセキュリティのログ分析をしようという話です。 簡単に自己紹介します。千田と申します。NTTドコモのサービスイノベーション部というR&Dの部署に所属していて、5年目社員です。 基本的に普段の業務では、クラウド、AWS、GCP、Azureのセキュリティに関わる仕事をしています。機械学習もちょっとわかるくらいに勉強していて、その関連でFPGAとかGPUみたいなハードウェアの