AWS

1.この記事を書こうと思った背景 複数の AWS Lambda に CloudWatch Alarms で監視しよう！ということがあったので、 Terraform で以下のように dimensions で監視したい Lambda を列挙するだけだろ！と思いきや、ダメだった。 apply すると、最後に書いた FunctionName のみがCloudWatch Alarms に適用されてしまった。(以下の場合、my_lambda_function2 ) resource "aws_cloudwatch_metric_alarm" "this" { metric_name = "Errors" namespace = "AWS/Lambda" dimensions = { "FunctionName" = "my_lambda_function1", "FunctionName" = "my_lambda_function2" }#略 } ※ FunctionName に * をつけても「*_lambda_function」などとベタ書きとして認識されてしまってダメ。正規表現っぽく指定することは出来なかった。 dimensions = { "FunctionName" = "*_lambda_function", } さて、じゃあどうしようか？と調べたことを書き留めておく。 なお、上記の dimensions は以下を参考に指定した。 Choose a dimension....

1.この記事を書こうと思った背景 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (通称、ちいとぽ本）を読み進めていくうちに、以下の疑問を抱くようになった。 Amazon社のピザ２枚ルール、チーム間のコミュニケーションは、インターフェイスを通して行うことというルールは実際にどんなかんじにされているのか？ 気になる。 Teams must communicate with each other through these interfaces. 出所：AmazonのAPI設計方針 (The Bezos Mandate) - Qiita 明確な答えを導き出したわけではないけれども、考えを深めることができたターニングポイントとなったのが、タイトルで触れているインタビュー記事、A Conversation with Werner Vogels - ACM Queue を読んだことだった。また、先にお伝えしておくと新たな疑問も抱くようになったので、インタビュー記事を読んで学んだことと新たな疑問について書き留めておきたい。 インタビュー記事を知ったきっかけ 左記のインタビュー記事を知ったきっかけは、Team Topologies(by Manuel Pais)のキーポイント を読んだことである。この記事は書評記事ではないが、同書の趣旨を理解する上でも大きな助けとなった。“A Conversation with Werner Vogels"をご紹介いただき、ありがとうございました！ 2.“A Conversation with Werner Vogels - ACM Queue"を読んで学んだこと 各サービスの構成メンバーは 利用ユーザーの目的やニーズに応えることにフォーカス するべきだということ ↓の例だと、デベロッパーの関心事はアプリケーションを開発することであり、アプリケーションを開発するために内部的に生成されているURLがどうやって構成されるのか？には関心がないということ。責任共有モデルが各サービス間で徹底されているということ。 Do we see that customers who develop applications using AWS care about REST or SOAP?...

1.この記事を書こうと思った背景 AWS Certified Solutions Architect Professional Exam(SAP-C01 / AWS認定ソリューションアーキテクト プロフェッショナル, 以下SAP試験とする)を自宅で受験して合格した。 スコアは773と、合格点が750なのでギリギリだった。なお、模擬試験の問題集の相性の兼ね合いやドキュメントの多さを考慮して英語で受験している。 2.受験しようと思った動機 SAP試験を受けようと思ったモチベーションは、AWS に関して体系的な知識を身につけ、いざググろうとなったときの助けとなるインデックスを脳内に貼っておきかったからだ。 たとえば、弊社のAWS環境においてAWSリソースにアクセスする仕組みを理解するためには AssumeRole という AWS が提供する権限付与の IAM の機能に関する知識が求められる。ここで業務に取り掛かる際に AssumeRole がなんたるか？の一般的な知識がアタマに入っていれば、だいぶラクなんだろうな〜と歯がゆい思いをすることがあった。 目的のAWSアカウントにはAssumeRoleを利用して切り替えます。 認証用AWSアカウントに誰がどのアカウントに切り替えてよいかを定義しておき、それに基づいて切り替え可否を制御しています。 出所：AWS + Azure ADによるSingle Sign-Onと複数AWSアカウント切り替えのしくみ作り - Cybozu Inside Out | サイボウズエンジニアのブログ もちろん試験に合格してもすぐ役に立つということはないのだろうけど、受験がインプットしてのわかりやすいターニングポイントとなってくれたことは間違いないと感じる。 3.試験対策の検討方法について 日本語受験の方は、「AWS SAP 合格」などでググるのがいいと思う。 英語受験の方は、reddit で aws sap などでググるとアドバイスが見つかるのでおすすめ! https://www.reddit.com/search/?q=aws%20sap 4.試験当日までの勉強方法 受験日の4ヶ月前に受験を決意してから3ヶ月くらい前まで 試験ガイド(AWS Certified Solutions Architect - Professional Exam Guide)を一読 AWS Certified Solutions Architect - Professional Certification | AWS Certification | AWS 以下の参考書を1周 AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル : 山下光洋 以下の Udemy の講座で配布されるPDF資料を一読しながら1問1答だけやる Ultimate AWS Certified Solutions Architect Professional 2022 | Udemy 以下の Udemy の模擬試験4回セットのうち1回を解き、難しさに絶望し、長期戦を覚悟する（1ヶ月もあれば終わるだろうと思っていたらとんでもなかった） AWS Certified Solutions Architect Professional Practice Exam | Udemy 3ヶ月くらい前から当日まで Redditで評判がよさそうだった、以下の模擬試験セットのうち、4回分と分野別の問題集をひととおりやる AWS Certified Solutions Architect Professional | whizlabs 模擬試験としては全5回だけど、準備期間が足りず4回しかできず ただし、ふりかえると模擬試験を一周するより、既に解いた問題の解き直し、解説や自分でまとめたメモの見直しなど復習に時間をかけた のが今回の合格の決め手になった感じはする ↑の問題集を解いて復習していくのと併せて、Udemyの模擬試験2回分も解いていく Udemy の模擬試験は全4回だが準備期間が足りず、1回分解いていないが、こちらも復習を優先した。 当日が近づくにつれ、これまで解いた模擬試験やAWSが提供するサンプル問題や模擬試験の問題と解説、自分でまとめたメモの読み直しの時間を増やした 1週間前に AWSからサンプル問題と模擬試験が無料で配布 されていることに気が付き、急いでやる AWS Certified Solutions Architect - Professional Certification | AWS Certification | AWSでサンプル問題と模擬試験が配布されている サンプル問題：AWS Certified Solutions Architect - Professional Sample Questions 模擬試験：AWS Certified Solutions Architect - Professional Official Practice Question Set ※ 受験日を決めたのは1ヶ月前。模擬試験の演習の手応えを感じたためというより、これ以上後ろにずらすことができなかったため受験日を決めた。...

1.この記事を書こうと思った背景 これまで、Terraform AWS Provider のバージョンを3.7系から4.x系に引き上げようとすると以下のissueで取り上げられているような、 aws_s3_bucket resourceでエラーとなっていた。 S3 bucket issue: Can’t configure a value for “versioning” #23125 このエラーは、Terraformの以下のガイドに記載されているとおり、aws_s3_bucket resourceの大規模な仕様変更が入ったことに起因する。 Version 4.0.0 of the AWS Provider introduces significant changes to the aws_s3_bucket resource. See S3 Bucket Refactor for more details. 出所：Terraform AWS Provider Version 4 Upgrade Guide ところが、AWS Provider 4.9に引き上げるとエラー判定とされなくなっていた、、！？ v4.0のリリース内容もびっくりだが、これもびっくりなので筆を執ることにした。 AWS Provivder 4.9.0の CHANGELOG 2.AWS Provider 4.9に引き上げるとエラー判定ではなくWARNING判定となる これまでの4.x系では aws_s3_bucket resource で3.7系までの書きっぷりをすると、エラーとしてきた 一方、4.9系ではWARNINGは出れどresourceは作ってくれた。それと明示的に修正が必要な箇所を指摘してくれる！！ ※ WARNINGが出ていて大丈夫なんですか？ という点については分かっていない。Terraform が指摘してくれた箇所の修正をしたほうがいいことは間違いないだろう。(今後のアップグレードによっては、またエラー扱いとなるというこもありうる)...

1.この記事を書こうと思った背景 AWSの利用料金が想定以上に高くてびっくりしたことがあった AWSの利用料金が想定より高くなったら検知するようにしようと決意したい ↓こういったことが起きないためにも、、 AWSでやらかして3桁万円請求された話 - Qiita 無事できたので、この記事でどうやったか？またいくつか検知する方法があるなかでどういった選定基準を持ったか？書いていきたい ※ サンプルコードはこちら https://github.com/gkzz/serverless-aws-budget-alerts-to-slack 2.前提 AWSの利用料金が想定より高くなったら検知する方法は2022/02/24時点で3種類あり、この記事ではbudget alertsを使った方法を採用している。ただし、各サービスの仕様変更やアップデートなどにより今後は他2つの方法を採用した方がいいということも。 3.環境情報 Serverless Frameworkのバージョンは3.2 $ grep VERSION= /etc/os-release VERSION="20.04.3 LTS (Focal Fossa)" $ sls --version Framework Core: 3.2.0 Plugin: 6.0.0 SDK: 4.3.1 $ npm --version 6.14.16 $ nodejs --version v10.19.0 Serverless Frameworkでは環境変数としてAWSのRegionとSlackのincoming webhook urlを使っている 環境変数の使い方や適用方法については以前書いたのでそちらを参照してほしい Serverless Framework 3.xでserverless-dotenv-pluginを使った環境変数の読み込みができなかったのでserverless.ymlを修正した | gkzz.dev　 # ....