AWS での DevOps Monitoring Dashboard | AWS ソリューション | AWS ソリューションライブラリ
このソリューションは、継続的インテグレーション/継続的デリバリー (CI/CD) メトリックスの取り込み、分析、および可視化のプロセスを自動化します。これらのメトリックスは Amazon QuickSight ダッシュボードに表示され、DevOps リーダーは DevOps イニシアチブのインパクトを測定し、データに基づく決定を行って開発チームの継続的な改善を促進することができます。
AWS、DevOpsメトリクスダッシュボードの実装を容易にする「AWS DevOps Monitoring Dashboard」の一般提供を開始
米Amazon Web Servicesは、AWS上での開発においてDevOpsメトリクスダッシュボードのセットアップを自動化するリファレンス実装である、「AWS DevOps Monitoring Dashboard」の一般提供を3月26日（現地時間）に開始した。 AWS DevOps Monitoring Dashboardを使用することで、AWSが提供している開発者ツール全体の顧客ごとのアクティビティと使用状況のメトリクスをキャプチャ・分析して、単一のダッシュボードで表示できるようになる。AWSパイプライン環境における、DevOpsダッシュボードのセットアップを自動化するため、平均修復時間の測定、変更の失敗率、デプロイ頻度、デプロイステータス、コード変更量の測定を、迅速に始められる。 CI/CDパイプラインが実行されているプライマリAWSアカウントにテンプレートをインストールすること
SSM セッションマネージャーでサーバー上の操作ログを取得 | DevelopersIO
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 AWS 上の EC2 に対してリモートでメンテナンスする際に 監査の要件でサーバー上の操作ログを取得しければならないシステムは数多いと思います。 今回はセッションマネージャーを使って サーバーメンテナンス操作ログを徹底的に記録してみます。 前提 以下のような前提を置きました。 リモートからのメンテナンスは必ず踏み台サーバーを経由する 踏み台サーバーへはセッションマネージャー経由でログインする SSH ポートは開放しない 踏み台サーバーへのアクセス許可は IAM で管理 踏み台サーバーは Amazon Linux 2 ログインはメール通知 ログイン後の操作ログは S3 へ保管 準備 リモートメンテナンスを行うクライアント PC に AWS CLI と Ses
TerraformでECSのService Discoveryを使う - Carpe Diem
概要 少し前にECSのサービスディスカバリが東京リージョンにも登場しました。 Amazon ECS Service Discovery がフランクフルト、ロンドン、東京、シドニー、シンガポールの各リージョンで利用可能に 今回Terraformでの使い方を説明します。 環境 Terraform v0.11.10 terraform-provider-aws v1.50.0 設定 Namespaceの設定 まずnamespaceを用意します。実行するとRoute53のドメインとして登録されます。 今回ECSで使う＝内部アクセスのみなのでaws_service_discovery_private_dns_namespaceを利用します。 これはVPC内部からしかDNSクエリを叩けません。 resource "aws_vpc" "example" { cidr_block = "10.10.0.0
AWS: 日付と時刻に基づいてアクセスを許可します - AWS Identity and Access Management
この例では、日付と時刻に基づいてアクションへのアクセスを許可する ID ベースポリシーを作成する方法を示します。このポリシーは、2020 年 4 月 1 日から 2020 年 6 月 30 日 (UTC) の間に発生するアクションへのアクセスを制限します。このポリシーでは、AWS API または AWS CLI から、このアクションをプログラムで完了するために必要なアクセス権を許可します。このポリシーを使用するには、サンプルポリシーのイタリック体のプレースホルダーテキストを独自の情報に置き換えます。次に、ポリシーの作成またはポリシーの編集の手順に従います。 IAM ポリシーの Condition ブロック内で複数の条件を使用する方法については、「条件内の複数の値」を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Effect":
リモートのtfstateを書き換えずに安全にterraform state mv後のplan差分を確認する手順 - Qiita
はじめに Terraformを長く運用しているとリソース名をリネームしたいというようなリファクタリングが稀によくあります。 これは terraform state mv コマンドを使うとできるのですが、このコマンドはtfstate(Terraformの状態管理ファイル)をデフォルトではその場で書き換えてしまいます。 https://www.terraform.io/docs/commands/state/mv.html しかしながらチーム開発をしている場合、 *.tf はgitでバージョン管理し、 tfstateはリモートのbackend(AWS S3とか)に保存するという管理方法が一般的です。つまり、リモートのtfstateをその場で書き換えてしまうと、masterブランチの状態と差分が出てしまいます。 tfファイル変更のレビュー前に、リモートのtfstateを書き換えずに、terraf
AWS×コンテナで基本的なDevSecOpsアーキテクチャをデザインしたお話 - How elegant the tech world is...!
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは？ DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
「ついに来た！Amazon Detectiveでセキュリティインシデントの調査がちょー捗るからまずやってみよう」という内容で動画投稿しました #devio2020 | DevelopersIO
こんにちは、臼田です。 みなさん、インシデントの調査やっていますか？(挨拶 今回はオンラインで2020年6月16日より開催しているDevelopers.IO 2020 CONNECTにおいてAmazon Detectiveの紹介とガッツリデモを含んだ動画を公開したのでそちらを紹介します！ 動画 解説 前置き スライドは最後尾に乗せています。が、デモの内容をバッサリカットしているので動画を見ていただくのが一番いいです。 今回は事前に収録できるということで、思う存分見せたい内容、伝えたい内容を乗せてみました。普段デモをやるのはけっこう大変なためやっていませんので、今回は私の中では珍しい内容です。 そして、お見せできないようなデータはモザイクをかけられるので、気にせず公開することができるのも動画投稿のいいところですね。 以下の内容は主に動画をこれから見る方向けです。 今回のコンセプト 2020年
GuardDuty が検出した脅威をいい感じに Slack へ通知する | はったりエンジニアの備忘録
AWS re:Invent 2017 で発表された脅威検出サービスの GuardDuty はもう試されましたか？ 発表されたその日に有効化してみましたが、さっそく意図せずオープンになっていたポートへの攻撃が検出されました。幸いポートスキャンされただけで実害はありませんでしたが、GuardDuty で検出されなかったら気づくことはなかったと思います。 ところで、GuardDuty が検出した脅威は AWS Management Console で確認できますが、メールや Slack でプロアクティブに通知する機能はありません。 AWS あるあるですが、通知したければ自分で仕組みを作る必要があります。 いつも参考にさせてもらっている Developers.IO の「GuardDuty を設定してメンバーアカウントを招待してみた」にもこんな感想がありました。 いまの状態だと、毎日 GuardDu
[AssumeRole] アクセスキーが漏洩しても被害が最小限になるIAMユーザでCloudFormationにデプロイする方法 | DevelopersIO
IAMユーザ & IAMロールを作成 デプロイ用のIAMユーザと付与するIAMポリシーについて このユーザ自身に与える権限は、AssumeRoleできる権限のみです。 そのため、万が一このIAMユーザのアクセスキーが流出しても、流出したアクセスキーでは実質何もできません。 デプロイ用のIAMユーザがAssumeRoleするIAMロールについて 「デプロイ用のIAMユーザ」がAssumeRoleする（引き受ける）「IAMロール」です。 今回作成するIAMロールには下記の権限を付与しますが、必要に応じて変更してください。 S3バケットの作成権限 S3オブジェクトの作成権限 お試しデプロイとしてAWS SAMを使うため、S3の権限も付与（Lambdaコードのアップロードをするため） CloudFormationのデプロイ準備に必要な権限 「CloudFormation用のIAMロール」はclou
![[AssumeRole] アクセスキーが漏洩しても被害が最小限になるIAMユーザでCloudFormationにデプロイする方法 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/3a9299c22c271be79f273b6db38d8ba6bc81bd1c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F05%2F8823428add162ea6925215296ff8c67f.png)
aws-vault についてのあれこれ - Qiita
クラウドワークス SREチームの @kangaechu です。アンタッチャブルのコンビ復活に目が離せないこの頃です。 クラウドワークス Advent Calendar 2019の4日目として、最近SREチーム内で使われるようになったツール、 aws-vault を紹介します。 背景 aws-vaultの話をする前に、少しだけAssumeRoleの話をします。 AssumeRole assumeは引き受けるなどの意味を持つ単語で、AWSを使用するユーザやリソースが本来持っている権限とは別の権限を引き受けることができるしくみです。ものすごいざっくりいうと、sudoコマンドのような感じです。AssumeRoleはどのようなときに便利なのでしょうか。 マルチアカウントでのIAMユーザ集約管理 リソースの分離や課金管理などを目的として、最近はAWS Organizationsを使用したマルチアカウン
JMESPath チュートリアルでプロジェクションを理解する | DevelopersIO
渡辺です。 前回に引き続き、AWSCLIのqueryオプションで利用できるJMESPathのチュートリアルを紹介します。 今回のチュートリアルを終わらせると、かなり細かい抽出まで可能になるのでしょう。 プロジェクション（投射） プロジェクション（投射）は、JMESPathのキーとなる機能のひとつです。 イメージしずらいですが、要素をイイ感じにArrayに変換していくことができます。 リストのプロジェクション ワイルドカードを使った[*]はJSONのArrayに投射します。 [ {"first": "James", "last": "d"}, {"first": "Jacob", "last": "e"}, {"missing": "different"}, null ] JMESPath Result
【AWS】小ネタ aws-cliでIAM RoleのTrust Relationship（信頼関係）を表示・更新する | DevelopersIO
はじめに こんにちは植木和樹です。今回はIAM RoleのTrust Relationship（信頼関係）をaws-cliを用いて設定する方法を備忘録としてまとめました。 IAM Roleを使いましょう！ IAM Roleは非常に便利な機能でクラスメソッドでは様々な場面で利用しています。特に複数のAWSアカウントをaws-cliで管理するケースで威力を発揮します。 例えばプロジェクトごとにAWSアカウントを分けている場合、通常であれば各アカウント毎にIAMユーザーを作成して個別にログインしたりアクセスキーを用いてアクセスするかと思います。しかしこの方法だとAWSアカウント と IAMユーザーの掛け算の数だけパスワードやアクセスキーを管理しなければならず、AWSアカウントやユーザー数が増えると煩雑になります。 そこで、マネージメントコンソールを利用する場合はSwitchRoleを、aws-c
ECSでごっつ簡単に機密情報を環境変数に展開できるようになりました！ | DevelopersIO
従来アプリケーション側で必須だった機密情報の復号化が、マネージドな仕組みで実現できるようになりました。 これでついにあんな秘密やこんな秘密をコンテナに渡しやすくなりますね — ポジティブな Tori (@toricls) 2018年11月16日 先日のアップデートで、ECSコンテナ内への機密情報の受け渡しが非常に簡単になりました。 従来は機密情報の展開にアプリケーション側での処理が必要だったものが、マネージドな仕組みで実現可能となっているので、既存ECSユーザーには必見のアップデートとなっております。 参考：AWS Launches Secrets Support for Amazon Elastic Container Service あんなことやこんなこと！？ ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ / 従来の方法の面倒くささ（自前で機密情報を展開していた
AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!
はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント（ルートユーザー）の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ
AWSで目指した理想のCI/CDを別視点で考察してみる（データ保護観点） - How elegant the tech world is...!
はじめに 前回のブログでは、マルチアカウントにおけるIAMユーザーの設計戦略についてご紹介しました。 今回は少しテーマを変え、以前筆者がJAWS DAYS 2020で登壇させていただいたCI/CDの内容を基に、データ保護の観点からの設計~実装を取り上げたいと思います。 ※少々お硬い内容を含みますが、AWS CI/CDセキュリティを考える上で一つのポイントになるはずなので、ご興味をお持ちの方は是非お付き合いください。m(_ _)m 前回ご紹介したCI/CD内容のおさらい JAWSDAYS2020にて「金融サービス向けに理想のCI/CDを追い求めたお話」というタイトルで、筆者が担当するサービスのCI/CD設計をご紹介いたしました。 ここで、「理想」という点についてもう一度振り返ると、それは「CI/CD導入により期待すること」と、「業務特性として守らなければならないこと」の両立でした。 高アジリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://media.amazonwebservices.com/jp/summit2015/docs/Dev-04d-Tokyo-Summit-2015.pdf
あなたの組織に最適なコンテナデプロイ方法とは？〜ECSにおけるデプロイ最新機能てんこ盛り〜
金融系サービスで ECS/Fargateを設計するということ
How to Rotate Access Keys for IAM Users | Amazon Web Services