omuronの備忘録

個人的な備忘録

「JAWS-UG朝会 #13」 #jawsug_asa 受講メモ

jawsug-asa.connpass.com

今日もラジオ体操からスタート...
出遅れて参加できませんでした。

セッション① AWS Single Sign-Onのお話

講師:ANAシステムズ(株) 鄭昌浩さん

資料: AWS SSOのお話 by 昌浩 鄭 on Prezi Next

Prezi でのプレゼンでした。
グリグリ動くサービスけど、オンラインだとそれが伝わりづらいのが勿体ない。

メモ

  • AWS SSO は Organizationsのサブ機能
    • Organizationsの全機能有効化をする必要がある
    • すでにアカウントがある場合はすべてのマスターアカウントで承認する必要がある
    • 有効化後に作成したアカウントでは有効になる
  • 本番への誤アクセスが多い
    • 本番系は管理者がスイッチロールでアクセス
  • 開発系と分離して解決
    • 開発系はAWS SSOでのアクセス
  • マルチアカウントへのアクセス管理が容易
  • マルチアカウントへのサインインが容易

セッション② Cognito、Azure ADと仲良くしてみた

講師:NECソリューションイノベータ 近藤 恭史さん

www.slideshare.net

  • Cognito と Azure AD で認証ができないか?
    • Cognito User Pool と Azure AD 連携
    • Cognito の Token を利用して AppSync を認証して、DB へアクセスする構成
  • 業務システム側でのサインイン、ユーザー管理
    • それぞれ準備するのが大変
  • サインイン画面を準備する手間
    • Amplify で楽に作れるけど、日本語化など手はかかる
  • エラーレスポンスのパラメータにエラー内容が表示される
    • Try&Error で対応していける

LT① clientvpnとprivate ca

講師:株式会社ターンアンドフロンティア 富松 広太さん

12冠!

docs.google.com

  • Clinet VPN 認証方式
    • AD 認証( AD のユーザー/パスワードで認証)
    • SAML 連携(IDP に登録したユーザで認証)
    • 相互認証(クライアント証明書で認証)
  • ACM に Private CA を登録して Clinent VPC Endpoint にインポートして証明
    • サーバー管理不要
    • SDKCLI が必要
    • 料金が $400 と高い

LT② Permission Boundary をやっと理解できたので誰か聞いてくれ(雑)

講師:日本電気株式会社 大竹 孝昌さん

www.slideshare.net

Permission Boundary「アクセス許可の境界」
AWS Organizations に似た機能がある
SCP 親アカウントから子アカウントに対する制御

Action/Resource に * が設定されることが多い...
IAM 権限をわたすけど、「特定の操作は制限したい」

  • IAM 権限を持つ人に十分なスキル
  • Teamsが小規模
  • Teamsに信頼関係あり

権限与えたいけど、制約したい!
ひとまず全許可して、制御する。
IAM 権限で悩んだら Permission Boundary を検討してみるといい。

LT③ AWSでたくさんお金を使っちゃった話

講師:NECソリューションイノベータ 高原未菜さん

www.slideshare.net

初心者と言ってましたが、SAP 持ち...150万円課金されたお話。

  • Aurora に 15TB のデータ保管していた
    • 停止時もストレージ料が課金
    • 7日間停止すると自動で起動される
  • 解決策
    • スナップショットを作成し、S3 に保管
    • Aurora インスタンスごと削除して解決
  • DynamoDB も使ってなくても400円ぐらいかかる
    -オンデマンドに変更すると0円

対策後、30万ぐらいに削減できた。

所感

認証認可のお話をセットで聞くことができました。
Azure AD と連携すると、利用する側管理する側双方らくなのですが、設定していく際に情シス部門と Try&Error するのがなかなか大変。
Organization は利用してますが、AWS アカウントを横断して利用する人が管理者の私以外ほとんどいなくて、各プロダクト専用の AWS を使うだけの状況なので、利用できてません。
Organization ミスると怖いからチャレンジできてないんだけど、知識としては知っておいて今後試せるようになりたい。

「サーバーレスアンチパターン今昔物語 番外編 」の SSR を試してみる #serverless_newworld

serverless-newworld.connpass.com

赤いドクロがトレードマークの西谷さんの「サーバーレスアンチパターン今昔物語 番外編 」で紹介された SSR を試してみたいと思います。
試す内容は、以下のブログの内容です。

www.keisuke69.net

リポジトリこちら

はじめに

私は元々バックエンドエンジニアであり、その延長で AWS を触り始めました。
ゆえに、フロントエンドはめっぽう弱いので、あまり知見がないという前提での作業です。
とりあえず、AWS で動かすことを目指すので、正しいやり方かどうかは手探り状態です。

試してみる

環境構築

macOS 10.14 で作業しています。
まずは、リポジトリを取得。

$ git clone git@github.com:Keisuke69/serverless-newworld-20200909.git
$ cd serverless-newworld-20200909

Dockerfile があったので中身を見てみる。

$ head Dockerfile 
FROM node:12.18.3

node v12.18.3 が必要そうとわかったので、 ndenv で設定する。

$ ndenv install 12.18.3
Downloading node-v12.18.3-darwin-x64.tar.gz...
-> https://nodejs.org/dist/v12.18.3/node-v12.18.3-darwin-x64.tar.gz
Installing node-v12.18.3-darwin-x64...

$ ndenv local 12.18.3
$ node --version
v12.18.3

ServerlessFramework を使っているので、 serverless.yml を確認。

$ head serverless.yml 
service: nuxt-ssr
plugins: 
  - serverless-offline

frameworkVersion: '2'

provider:
  name: aws
  runtime: nodejs12.x

ServerlessFramework の v2 と serverless-offlineプラグインが必要そう。
手元の sls が v1 だったので、アップデートも兼ねてインストール。

$ npm install -g serverless
$ npm install -D serverless serverless-offline
$ sls version
Framework Core: 2.1.1
Plugin: 4.0.4
SDK: 2.3.2
Components: 3.1.3

これにて環境構築完了。

動作確認

おもむろにデプロイしてみる。

$ sls deploy
Serverless: Running "serverless" installed locally (in service node_modules)
...
.................................
Serverless: Stack update finished...
Service Information
service: nuxt-ssr
stage: dev
region: ap-northeast-1
stack: nuxt-ssr-dev
resources: 12
api keys:
  None
endpoints:
  ANY - https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev
  ANY - https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/{proxy+}
functions:
  nuxt-ssr: nuxt-ssr-dev-nuxt-ssr
layers:
  None

デプロイはできたので、表示されたエンドポイントにアクセスしてみる...

// 20200924092440
// https://vxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev

{
  "message": "Internal server error"
}

内部エラーが発生してしまった。
CloudWatch Logs から該当のログを探してみてみる。
CloudWatch -> CloudWatch Logs -> Log groups -> /aws/lambda/nuxt-ssr-dev-nuxt-ssr

    "errorType": "Runtime.ImportModuleError",
    "errorMessage": "Error: Cannot find module 'nuxt'\nRequire stack:\n- /var/task/lambda.js\n- /var/runtime/UserFunction.js\n- /var/runtime/index.js",

ログを見ると nuxt なさそう。
このあたりフロントエンド全く知らない影響が出ている。
ということで、まずはローカルで動かすことを目指す。

ローカルでの動作確認

npm install をとりあえず...

$ npm install

したあとに、「 yarn のほうがいいんだっけ?」となって、 yarn で動作確認。

$ yarn install
$ yarn dev
...

   ╭───────────────────────────────────────╮
   │                                       │
   │   Nuxt.js @ v2.14.6                   │
   │                                       │
   │   ▸ Environment: development          │
   │   ▸ Rendering:   server-side          │
   │   ▸ Target:      server               │
   │                                       │
   │   Listening: http://localhost:3000/   │
   │                                       │
   ╰───────────────────────────────────────╯

無事に localhost:3000 で起動できた模様。
ブラウザでアクセスするとちゃんと表示されている。

f:id:omron:20200924174529p:plain

nuxt のセットアップとビルドができてないことがわかったので、ビルドして再デプロイ。

$ yarn build
$ sls deploy

API Gateway の URL に再アクセスすると、無事表示を確認。
ただし、トップページは表示されるが、各記事にアクセスするとステージ変数の /dev が抜けるため、正しく表示ができない。
これは、 API Gateway でカスタムドメイン設定をすることで、ステージ変数を省略した状態にできるのでこちらの設定をすれば解決できるとのこと。

f:id:omron:20200924175009p:plain

所感

フロントエンドエンジニアからすれば、当たり前と思える作業が省略されているため、まずはそこを調べながらの作業となってしまいましたが、とりあえず動かすことはできました。
次は、Nuxt.js を違うものに置き換えて、動かしながら理解することを目指したいと思います。

「JAWS SONIC 2020 & MIDNIGHT JAWS 2020」 #jawssonic2020 ゆるゆる参加

f:id:omron:20200914101301p:plain

はじめに

jaws-ug.doorkeeper.jp

オンラインでの JAWS 27時間お祭りイベント!
土日27時間はさすがにすべて見ることはできませんでしたが、つまみつまみゆるゆる参加しました。

OP & JINGLE MOVIE

dev.classmethod.jp

最初にびっくりしたのはオープニングムービー。
知っている方がたくさん出てきて、短時間でインパクトあることしたりしてるし、何度見ても飽きませんでした。
とてもセンスよく綺麗に作ってますね。
どこかのプロがつくったのかと思ったら、クラメソ新卒エンジニアのたいがーさん。 写真だけじゃなくてムービーもできるんだ。

セッション

AWSコミュニティマネージャーから見たJAWS-UGとは

講師:JAWS SONIC 2020 実行委員会沼口 繁

www.slideshare.net

AWS は本当にコミュニティを盛り上げるのが上手ですね。
小島さんが仕掛けた血は脈々と受け継がれていると感じます。

MediaServicesを使って動画配信サービスを構築しよう!

講師:Media-JAWS 三浦一樹

speakerdeck.com

  • Zoom 落ちない?
  • OBS PC/アプリ落ちない?
  • YouTube いきなり BAN される

今回の配信にも利用していた Amazon IVS を利用しよう。
最後まで安定して配信できてたのは本当にすごいですね。
Chrome で見てましたが、たまに止まることはあって、再読み込みで復帰しました。
これは、PC 側の問題かなぁ。

長く使えるAWSスキルを効率良く身に付けよう

講師:JAWS-UG CLI専門支部 波田野 裕一

speakerdeck.com

GUI が許されるのは中学生まで!」でおなじみの CLI 専門支部波多野さん。
いつもお世話になっております。何度も参加させていただきました。
GUI はすぐ変わっていけど、CUI だと普遍的で長く戦えるよ」とのこと。
GUI でキャプチャーを取って手順書をとる文化のところは大変だろうなー。
CUI は初学者にはハードルは高いし、画面キャプチャーの重要性も感じますが、誰も読まない納品のために無駄に準備する場合は避けたいところ。

一方、始めて新機能を触るときに、キャプチャーの手順書があると助かるのは事実。
Developers.IO とかでもキャプチャーが準備されていると、安心感があります。
調査のための GUI と開発や本番に向けての CUI をうまく使い分けていきたい。

APIアクション名と CLI サブコマンド名は、原則同じ」
例: AllocateAddress = allocate-address
キャメルケースとケバブケースの違いと覚えておけばいいでしょう。

ラジオ局員による音声サービスへの熱い想い & more

講師:AWS-UG 和歌山支部 山口誠二

ラジオ局を「Amazon Polly」を使って実現したお話。
AWS って沢山サービスがあるけど、それらを良い感じに組み合わせてプロダクトに持っていく必要があります。
Text2Speech とか、ありがちなサービスですが、ちゃんと活用するアイデアとプロダクト品質にまで持っていくことの実現は本当に大変そう。
森元首相」の「元」を「げん」と読んでしまい意味が逆になったりとか、実際に使ったからこその苦労話に興味が惹かれました。

お蔵入りのネタが今夜解禁!!NとKのキーマンがAWSで描く未来を語りつくす!!

講師:NW-JAWS 里見宗律、大橋衛

今回のイベントは、タイムスケジュールをしっかりまもっており、20分という短い時間で少し早めに終了して次のセッションに進む感じでした。
「2分前」「30秒前」とか運営からアナウンスがあるんですが、みなさん上手に時間内に終わらせていました。
自分が見てた中では、唯一強制終了されたセッションでした。
深夜ということもあり内容も終わり方も面白かった。

AWSの研修環境構築のためにAWS CDKとAmplify Console使った話

講師:JAWS-UG 新潟支部 笠原宏

speakerdeck.com

CDK がなかった時代、CloudFormation から手をだしたため CDK は未だに触ったことがありません。
プログラムで書けるのが CDK のメリットですが、プログラムからもすっかり離れているためチャレンジができていない。
CloudFormation は秘伝のソースのように拡張されていって、後から読み解くのが非常に時間がかかるため、CDK に移行していったほうがいいんだろうなーと思ってはいますが踏み出せていません。

Copilotによる、お手軽3分間ECSクッキング

講師:JAWS-UG コンテナ支部 新井雅也、濱田孝治

speakerdeck.com

ハマコーさんハート強すぎw
AWS Copilot 便利ですね、とりあえず何も考えずに Fargate を動かすことができます。
初期化からプロジェクト立ち上げまでのデモ( CUI の画面動いてなかったので後から再度説明)と、デプロイされた画像へのアクセス(ができなかったら事前に準備した画像へアクセス)。
事故っても、「すでに準備してあるこちらを使って」という感じが3分間クッキングのようでとても面白かった。
AWS Copilot は、まだβ版なので今後に期待です。

回線速度が遅くたって不安定でもクラウドは便利!

講師:南の島派出所 佐々木貴

個人での発表で、衛生通信を利用した南の島からの配信でした。
衛星通信でもとても安定して配信できるのはすごい。
本当の意味での孤島なので、機材の調達もできず、1年以上帰れない過酷な環境のようです。

  • 手作業で画面キャプチャーとかやってられない
  • 事前に準備したラズパイなどで、監視業務を自動化したりしている
  • 追加機材は、定期便がくる1年後なので当てにできない
  • 画像などの監視ログをとにかく全て S3 に放り込んで対応している
  • 1人で作業されているので後任者への引き継ぎが不安

有名な方なのでどこで働いてるかはググるとでてきますね。
あの大きなサメよく持ち込めたなぁ。 とてもチャレンジングな環境に身をおいているのが尊敬できます。

Importance and Power of User Groups

講師:Jeff Barr

Chief Evangelist, Vice President for Amazon Web Services の Jeff Barr さんです!
日本のイベントにも参加してくれるのはすごい。
一度だけ、直接お話を聞いたことがあります。
2015年の re:Invent で、数名だけ集めた少人数特別セッション Amazon カルチャーで、AWS の文化についてお話しいただきました。
有名な「2 Pizza Teams」とかを始めて聞いたのはこのとき。
とても貴重な体験でした。

所感

運営のみなさま、本当にお疲れさまでした。
27時間って本当にすごいですよね。
受講したセッションはもっとあるのですが、全てをまとめきれておりません。
27時間安定して配信している AWS IVS や、セッション内容ももちろんですが、何より運営が素晴らしかった。
次々参加者が変わるのに見ている範囲ではトラブルもなく、タイムテーブルにちゃんと沿って進んでいました。

オフラインのような直接的な出会いだったり話だったりをすることができないのは残念ですが、オンラインならではの27時間開催。
新しい JAWS のお祭りの形に参加できてとても楽しめました。
後ほど、アーカイブもされるようなので、興味あるセッションを見て復習したいと思います。

「JAWS-UG CLI専門支部 #167R EventBridge入門 (旧Events)」受講 #jawsug_cli

jawsug-cli.connpass.com

「資料は公開しません。個人的にキャプチャーとか取るのは問題ありません。」
とのことで、メモのとり方を迷ってしまってちゃんと取ることができなかった...

なので、非常に綺麗にまとまってるよっしーさんブログを備忘録としてメモっておく。

michimani.net

所感

CloudWatch Events が、 Amazon EventBridge に切り替わった。
このようなサービス名ごと切り替わるのは非常に珍しいとのこと。
CloudWatch にもイベントメニューが残ってますが、Amazon EventBridge を使えと促されますね。

f:id:omron:20200910235445p:plain

今回面白いなーと思ったのは、エディタすら使わずに Lambda Function 作成 してたところ。
さすが CLI専門支部です。

「JAWS-UG CLI専門支部 #167R EventBridge入門 (旧Events)」受講 #jawsug_cli

jawsug-cli.connpass.com

「資料は公開しません。個人的にキャプチャーとか取るのは問題ありません。」
とのことで、メモのとり方を迷ってしまってちゃんと取ることができなかった...

なので、非常に綺麗にまとまってるよっしーさんブログを備忘録としてメモっておく。

michimani.net

所感

CloudWatch Events が、 Amazon EventBridge に切り替わった。
このようなサービス名ごと切り替わるのは非常に珍しいとのこと。
CloudWatch にもイベントメニューが残ってますが、Amazon EventBridge を使えと促されますね。

f:id:omron:20200910235445p:plain

今回面白いなーと思ったのは、エディタすら使わずに Lambda Function 作成 してたところ。
さすが CLI専門支部です。

「第一回 AWSマルチアカウント事例祭り」 #ama_fes01 受講メモ

zozotech-inc.connpass.com

ZOZOタウンで買い物したことなくて恐縮ですが、テクノロジーとしてはとても魅力ある企業ですね。

AWS Configを用いたマルチアカウント・マルチリージョンでのリソース把握とコンプライアンス維持への取り組みについて

講師:株式会社ZOZOテクノロジーズ 技術開発本部 SRE部 テックリード 光野 達朗(@kotatsu360)

speakerdeck.com

QA

通知を受け取った後の対応はどうしてるんですか?

実験的に見ているところなので自身で見てプロダクトチームへ連絡している。 プロダクトチームへ直接通知を検討中。

今後設定したいルールってなんですか

セキュリティに対して強く効果がある部分。ssh ポートをインターネットに公開してないかなど。
次にログに関して。「Aでは出てlB出だしてない」とかの状況にならないように、アカウントでログの状況を統一したい。

ルールはcontroltowerをベースに設定されたのでしょうか?

まだしてない。 Config のプリセットのマネージドルールを使ってる。 利用するだけでベストプラクティスになるので、これを中心にセキュリティを高めている。

Config Rulesの標準ルールだけでも汎用的なものからパラメータを個別に設定が必要なものまでいろいろあります。後者は各AWSアカウントの利用状況に依るので、全AWSアカウントに共通設定を適用は難しいなと感じています。ルールの採用方針があれば教えてください。

書いてあるとおりと思われる。 Config を採用したばかりということもあり、絶対に守りたい 22 port や S3 の公開権限などを中心にしている。 各アカウントの事情を細かく見なくていいレベルとしている。

Security Hubのセキュリティ標準チェックも活用できそうでしょうか?

活用できると思われるがまだ見れてない。 マルチアカウントマルチリージョンができることが重要。 リージョンに広く使えると思われるので検討していきたい。

どれくらいの期間で、現在の状態まで構築出来ましたか?

Try&Error も含めて、足掛け2週間。 Config の設定がアカウント単位やリージョン単位などをサポートに問い合わせるなどに時間がかかった。

マルチアカウント運用の開始までの取り組み

講師:株式会社ウェザーニューズ Cloud Initiative 小野 晃路

アプリいつも使ってます。
86年創業。94年入社とのこと。
そんなにも歴史ある会社だったんですね。アプリのイメージしかなかった。

www.slideshare.net

  • 2012年から AWS 利用。グローバルの天気アプリの作成がきっかけ
  • 元々、オンプレがメイン。密結合
    • 現地に行くのも時間かかる
    • ケーブル片付けだけで半日など
    • ビルの法定停電
  • 最初は運用アカウントのみ、オンプレ接続
    • 開発アカウント追加、オンプレ接続
    • 利用促すために PoC アカウントを発行、オンプレ接続なし
      • 同じアカウントを使うとコスト配分できない
      • IAM 最低限にするのは大変、詳しくないときに作った最初のチームは権限ゆるい
      • サービス上限にひっかかる
      • オンプレと接続したい
      • 開発アカウントで試すときに権限がないので調整に時間がかかる --> オンプレでいいや
        • 問題も多いからマルチアカウントを検討へ
  • AWS Summit 2017 「AWSにおけるマルチアカウント管理の手法とベストプラクティス」を参考に
  • AWS Transit Gateway
  • AWS SSO
    • 複数アカウントのログインの一元管理が可能に
    • G suite 使ってるけど SAML 連携はせず
      • 各アカウントに対する細かい設定が難しそう
    • IAM ユーザーやスイッチ Role を使わなかった
      • アカウントごとに設定するのが大変だった
        • MFA がアカウントごとに増えたりとか
      • スイッチ Role も設定が大変
  • AWS 利用のガバナンスの決定
    • ガバナンスと権限移譲のバランスを取る
      • ガードレール方式
  • アクターの整理
    • AWS を利用する管理者と役割を定義
      • アプリ開発担当、アプリ管理者担当、事業部の管理者、監視担当、インフラ管理担当、セキュリティ管理担当、コスト管理者
  • アカウント名とメールアドレスの命名規則
    • {env}-{team}{-system}
    • ml-aws-{team}{-system}{+env}@wni.com
  • CDK を使って管理
    • cli も併用、コードベースにする
  • まとめ
    • SSO 使おう
    • 運用ルールを事前に決める
    • コード管理で運用しましょう
  • 課題
    • マスターアカウント=運用アカウントのためシステムが乗ってる
      • 支払い専用へどう移行するか

QA

コード管理で運用するとのことですが、初期構築だけではなく運用含めて全てをコードで管理されるのでしょうか?

変更があれば、コードでするようにしている。

「進化し続けるインフラ」のためのマルチアカウント管理

講師:株式会社リクルート インフラソリューションユニット SRE部 須藤 悠

  • 13チーム、90アカウントを管理
    • 2016年数アカウントからスタート
  • Terraform 運用
    • Pull Request で 自動 plan
    • 最初は手動
    • 次の1年程度は CFn
    • 次の2年程度で次第に Terraform へ
    • 現在すべて Terraform + Terraform Enterprise で運用
      • 1000plan/月、200apply/月
  • 基盤の権限構成
    • 4つの権限
      • 管理者権限:プロダクト責任者向け
      • 開発者権限:開発者一般向け
      • 運用者権限:運用者向け
      • コンテンツ権限:S3 バケット更新用
  • root 権限はかなり厳重に制限
    • 基盤チーム専用の MFA デバイス
    • root 必須以外は利用不可
  • 利用リソース
    • CloudTrail
      • S3 の出力内容は変更削除不可、参照のみ
    • Config
    • CuardDuty
      • SNS Topic でメールと Slack 通知
    • VPC Peering
    • Transit Gateway
    • Organizations SCP
    • Compute SavingsPlans
      • Fagate で恩恵を受けたい場合は個別アカウントで設定
      • RI は個別アカウントのみ
    • Consolidated Billing & Cost Explorer
    • RDS
      • 意図せず再起動が出ないようにメンテンススケジュールを Slack 通知
    • Route53
      • 内部 HostedZone レコードを DynamoDB に集約
    • ACM + Route53
      • 開発でも HTTPS 使う
      • クロスアカウント化が必要なので Terraform 化してない
  • LDAP により ID 管理とフェデレーション
    • LDAP アカウントに登録で ssh とマネコン使える
    • 公開鍵と MFA トークン自動払い出しメール通知
    • Web アプリの管理ツールを作って提供
    • 今から作る人はマネージドサービスを使うべき
      • AWS SSO, Directory Service, Sysytems Manager ...
      • 独自 ID 管理は覚悟が必要
  • マルチアカウントで大切にしていること
    • 進化し続けるインフラ
    • 基盤チームでプロダクトを幸せに
      • インフラ運用だけじゃない価値を
      • プロダクトに寄り添い伴走し成長させる
    • AWS 新機能、新サービスのキャッチアップ
    • 障害を学びに
      • トラブルシュートは学びの宝庫

QA

アーキテクチャレビューできるには幅広いAWSスキルが必要になると思いますが、そのために基盤チームのメンバーの教育は何かやっているのでしょうか

メンバーごとに得分野と不得意があると思う。まず一つの機能の適用検証を一人でする。レビューアートしてハイスキルな人や知見のある人をつける。壁打ち相手を作って進めるようにする。

CFnからterraformへの移行を決めた際に、CFnでは辛いなと感じたポイントをいくつか教えていただきたいです。

当時は yaml が使えなかった。json を書くのが辛かった。 Terraform だとインポートして IaC に組み込めるのが良かった。

CCoEチームにいます。当初はCCoEチームがAWS全般に詳しかったのですが、複数案件を経るとプロダクトチームの方にノウハウが蓄積するようになり、相談されても答えられないものが増えつつあるのが悩みです。社内のAWSノウハウ共有のいい方法と、CCoEチームメンバーとしてのモチベ維持方法に関して何かあればお聞かせください。

前半に関しては、プロダクトチームが成長成熟することは素直に喜ぶ。CCoE チームが関与してたからこそ成長できたと誇っていいと思う。 社内のノウハウに関しては、モチベーションを持った特定の人が何人かいると思うので、その人に声をかけて勉強会とかカジュアルにオンライン飲み会で技術の話するなどもいいかなと。 モチベーションの維持は、プロダクトと CCoE で注目すべき AWS のサービスは違うと思う。そういったところでそれぞれ興味を持って突き進めばいいと思いました。

所感

10年ほど AWS 触ってるから徐々にアカウントが増えていき、綺麗にマルチアカウント管理はできてない状況です。
最初に作ったアカウントがマスターアカウントになって運用もしている状態だし、自分がメインでみてないアカウントはセキュリティ周りも後回しになったりするし...
計画的にまとめて管理を考えないとダメな状況になってきましたが、専門のインフラチームとかでないとなかなか難しいですね。

CodeBuild の環境変数翻訳が面白い

CodeBuild と戯れてて、環境変数を調べる必要があったので、下記のページで調査をしてました。

ビルド環境の環境変数 - AWS CodeBuild

マネジメントコンソールなども含めて、日本語化が一部おかしいところがあるのは散見されますが、このページの環境変数については見どころ満載だったのでいくつかピックアップしてみます。

環境変数

CODEBUILD_BATCH_BUILD_IDENTIFIER(IDIDID)

なんで、 ID が3つになったの?
大事なことなので3回言ったのかな?

CODEBUILD_BUILD_ARN コードビルド_ビルド

中途半端な翻訳で ARN は消えちゃいました。

コードビルドビルドID

環境変数だから元の CODEBUILD_BUILD_ID から翻訳したらダメでしょう。

CODEBUILD_BUILD_IMAGE(コードビルドビルド)

これも IMAGE が消えてますね。
カッコがついているやつは、本文の翻訳が混ざってる状態でしょうか?

CODEBUILD_BUILD_数字

CODEBUILD_BUILD_NUMBER じゃないと呼び出せないです...

CODEBUILD_BUILD_SUCCEEDING(建設済み_建設済み_建設中)

BUILD が「建設」に翻訳されたのか?
意味がわかりません。

まとめ

概ね2パターンに別れており、カッコが無駄に追加されているものと、環境変数名なのに中途半端に翻訳されるものがありそうです。
カッコがついているものは、カッコ内は英文にも無いから不要な翻訳ですね。
AWS に限ったことじゃないですが、英文にも当たらないと正確にわからないことが多い世界なので、英語が苦手な身としては辛いです。