こんにちは。データアナリティクス事業本部 サービスソリューション部の北川です。 今回は、Cognitoで新しく追加された「属性変更の確認」を試してみたいと思います。この機能によって、メールアドレスや電話番号変更時に変更前の値を保持できるようになります。 Cognitoでメールアドレス変更時の問題 Cognitoでは、メールアドレスの変更（updateUserAttributes）を実行すると、コード検証を行う前に、実行したタイミングでメールアドレスが切り替わってしまうという問題がありました。 Github上でも、かなり前からこの問題に対して議論されていたようです。 内容を見て分かる通り、今回、その問題を解消するための機能が追加されました。 属性の変更の確認というタイトルの新しいセクションがAmazonCognitoコンソールに追加されました。この機能をアクティブにすると、更新が保留されてい

Amazon Verified Permissions とは 従来の認可処理 Cedar 言語の使い方 基本的な記述方法 RBAC の例 ABAC の例 golang で動かしてみる 1. ポリシーストアを AWS コンソールから作成する 3. サンプルアプリケーションの実装 最後に こんにちは、2023年5月にバックエンドエンジニアとしてジョインした yamanoi です。 最近は Cloudflare スタックに注目しており、新機能を触ったりアップデートを眺めたりしています。 今回は先日 GA （一般利用可能）になった AWS のサービス Amazon Verified Permissions を、 golang で実装した簡単なサンプルを交えて紹介したいと思います。 Amazon Verified Permissions とは Amazon Verified Permissions

ECSにはFireLensというログルーティング機能があり、これを使えばログをCloudWatchやS3へ同時に流すことが簡単にできるようになります。 Firehoseのコストが高くついてしまう場合や、ただ流すだけでなく途中でログを整形したい場合などもFireLensは選択肢としてありだと思います。 今回はFireLensを使い、NginxのログをJSONに整形しつつCloudWatchとS3へ同時に出力してみます。 FireLensの概要説明 FireLensはECSタスクにおけるシンタックスシュガーであり、データ・ログ収集アプリケーションのFluentd/FluentBitを指します。 Fluentd/FluentBitの比較はこちらにまとめられており、ECSにおいては軽量なFluentBitのほうが推奨されています。 FluentBitを利用する場合、以下の図のようにメインとなるコン

エージェンシー事業でリードアプリケーションエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3

はじめに 昨年 Amazon EventBridge Schedulerという機能が公開されました。今回はこれを利用して、Amazon CloudWatch LogsをAmazon S3に転送してみます。 設定方法 EventBridge Schedulerは多数のAWSサービスのAPIをターゲットに指定できます。この中にはCloudWatch Logsの CreateExportTask も含まれており、これはLog GroupからS3バケットにエクスポートするタスクを作成します。今回はこのAPIを利用して、CloudWatch LogsからS3バケットへのエクスポートを定期的に実行することを目指します。 EventBridge Scheduer用のIAMロール作成 EventBridge SchedulerからCloudWatch Logsに対する操作権限を付与します。今回は横着して

Amazon/楽天のブラックフライデーで例年通り散財した、@kojiisdです。 今回、光学30倍ズーム、という謳い文句に惹かれて、10年ぶりくらいにパナソニックのコンデジを買ってしまいました。 これから写真を撮るのが楽しみになりそうです（＾＾ みなさんは散財しましたか？ さて、アクロクエストでは、エンジニアたちが仕事の中で気になっていたことを調査・検討・検証した際に、 その内容を社内勉強会でフィードバックしています。 今月は12月ということで、そのような調べたことを、アドベントカレンダーとしてブログに公開していくことにしました～！ 初日はタイトルにもあるとおり、「Amazon EventBridge Schedulerの使いどころを整理してみた」です。 Amazon EventBridge Schedulerとは AWSでイベント／スケジュールドリブンな処理の管理、というとAmazon

はじめに 前回以下で各種ログの出力先をまとめていきましたが、CloudWatchLogsからS3にログを転送したいという場合にどのような方法をとるべきか今回記載していきたいと思います。 なぜS3に転送するのか そもそもなぜS3に転送する必要があるのかという疑問を持つ方がいるかもしれません。 CloudWatchLogsで保管もできるし、検索もできるのではないかと。 それはそのとおりなのですが、CloudWatchLogsのログ保管のコストはS3より高めに設定されており、純粋にログ保管をしたいだけであれば、S3に保存する（長期保管だけであればGlacier等）ことがおすすめです。 また、S3をデータレイクとし、各種データの分析等に利用するケースも考えられます。 方式 ・手動でのS3エクスポート ・KinesisDataFirehoseを使ったS3エクスポート ・EventBridge＋Lam

Amazon Simple Email Service (Amazon SES) で送信した E メールが、受信者のスパムフォルダに届きます。なぜこのようなことが起こるのですか? E メールがスパムとして報告されないようにするには、どうすればよいですか? 解決方法 スパムフォルダに配置されたメッセージは、Amazon SES が受信者のメールサーバー (ISP) にメッセージを正常に配信したことを示します。この段階では、Amazon SES はメッセージを制御できないため、受信トレイの配置を保証できません。 ISP は、電子メールがスパムとして分類されているかどうかを判断し、メールボックスの全体的な配置を決定します。ISP が E メールメッセージにスパムのフラグを付けた場合、E メールは受信者のスパムまたは迷惑メールフォルダに振り分けられる可能性があります。 ISP が E メールをスパ

はじめに 今年も AWS Dev Day で登壇しました。私が AWS に入社したのが2019年でそこから毎年何かしら登壇して、今年が４回目でした。過去の登壇資料なんかは巻末に貼り付けておきます。 今年は運営メンバーにも加わってイベント作りから関わり、 CFP の選定や他のセッションのレビュー、総合司会なんかもやりました。 そもそも AWS Dev Day は、AWS が開催するイベントの一つで、名前の通り特に開発者の方、普段ソフトウェア・アプリケーションを開発している方、プログラミングしている方というところに焦点を絞って、「開発者の方に登壇いただき、開発者の方に楽しんで欲しい、開発者の方が今日から役立てるコンテンツをお届けしたい」そういうイベントです。 登壇資料/動画 兎にも角にもまずは以下を一度ご覧いただくことをこの記事ではおススメします。その上で補足・解説していくような立て付けの記事

Amazon Inspectorとは FAQ: https://aws.amazon.com/jp/inspector/faqs/ Amazon Inspector は マネージドのEC2 インスタンス/ECRのimageをスキャンして、インストールされているソフトウェアの脆弱性とネットワーク到達性の問題がないか調べるツール Amazon Inspector を使用した Amazon EC2 インスタンスのスキャン - Amazon Inspector 前提 Amzon Inspector v2が出ていてそちらの最新バージョンを使用する 公式: https://docs.aws.amazon.com/inspector/latest/user/getting_started_tutorial.html https://dev.classmethod.jp/articles/amazon-i

目次 手順の概要 実行環境 手順 まとめ 手順の概要 Inspectorの有効化 マネージドインスタンス化 脆弱性情報の確認 注意事項など 実行環境 OSについては執筆時点で下記のみが対象となっています。 https://docs.aws.amazon.com/ja_jp/inspector/latest/user/supported.html 対象のOSが比較的新しめのLinuxばかりのため、Windowsや古いLinuxをご利用の場合、Inspector v2は対応していません。 Classicであれば対応していますので、Classicをご検討下さい。 手順 Inspectorの有効化 AWSマネジメントコンソールにログインし、Inspectorの画面に遷移します。 有効化をしていない場合は、下のような画面が表示されるはずです。 ※Inspectorはリージョナルサービスのため、必ずI

脆弱性の検知対象 基本スキャンはオープンソースの Clair プロジェクトの CVE データベースを使用したスキャンを提供します。脆弱性の検知対象は OS パッケージのみです。 拡張スキャンは OS パッケージに加え、プログラミング言語パッケージの脆弱性を検知することが可能です。対応するプログラミング言語は以下のとおりです。 C# Golang Java JavaScript PHP Python Ruby Rust 脆弱性の検知タイミング 基本スキャンはイメージが Push された際にスキャンを起動する (Scan on push) か、手動でスキャンを開始することができます。そのため脆弱性を検知できるタイミングもそのどちらかになります。手動スキャンの実行は各イメージごとに24時間に1回に制限されます。 拡張スキャンではリポジトリに対し連続スキャンを利用することができます。連続スキャンは

こんにちは、CX事業本部の若槻です。 AWS上に構築したシステムを外部サービスと連携する時はAWSでIAMユーザーのアクセスキーを発行することが多いですが、このIAMアクセスキーの作成は手動で行うと手数が多くなかなか手間が掛かり、また数が増えすぎると管理も大変になります。 そこで「IAMアクセスキーについても他のリソースと同様にAWS CDKで管理できないか？」と考えたのですが、その際にCDKスタックの再デプロイ時にアクセスキーの値が変更されてしまわないか？という懸念があり、今回実際に確認してみました。 確認してみた スタック初回デプロイ 発行したアクセスキーのIDとシークレットをAWS System ManagerのパラメータストアにString形式で格納しています。 lib/sample-app-stack.ts import * as cdk from "@aws-cdk/core"

AWSのParameter StoreとSecrets Manager、結局どちらを使えばいいのか？比較AWSSecurityIAMSSM AWSのアクセスキー/シークレットアクセスキーのコード書き込みは危険 GitHubにAccess Key/Secret Access Keyを含むコードをPushしてしまい、 公開されたキーで犯罪者にAWS環境へのアクセスを許してしまい、 ハイスペックインスタンスタイプ(料金が高い)のインスタンスを 仮想通貨マイニング等に利用されてしまい、 請求書を見て青ざめる、 というインシデントが定期的に発生しています。 今年の2月にその危険性を検証された方がおられ、 「git pushから13分でご利用開始」とのこと。 GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！ - Qiita GitHubからアクセスキーを抽出するスクレ