以下の内容はhttps://sadayoshi-tada.hatenablog.com/より取得しました。


Athena のマネージドクエリ結果を Terraform で設定するメモ✍

タダです.

以前の記事で Athena のクエリ結果を S3 に保存しないマネージドクエリ結果オプションについて紹介しました.この記事では,この設定を Terraform で行う方法を整理します.

sadayoshi-tada.hatenablog.com

マネージドクエリ結果とは

Amazon Athena のマネージドクエリ結果は,クエリ結果を S3 バケットに保存する代わりに Athena が管理するストレージに保存するオプションです.これにより,クエリ結果用の S3 バケットを別途用意する必要がなくなります.クエリ結果は24時間保持されます.

また,マネージドクエリ結果を使うことで S3 バケットのプロビジョニングや管理,アクセス制御が不要になるため,IAM ポリシーで S3 バケットへの権限(s3:PutObject, s3:GetObject, s3:GetBucketLocation など)を付与する必要がなくなります.ワークグループレベルで GetQueryResultsGetQueryResultsStream の権限管理ができるため,IAM 権限の管理がシンプルになるのもメリットです.

Terraform での設定

aws_athena_workgroup リソース

Terraform の aws_athena_workgroup リソースでは,configuration ブロック内の managed_query_results_configuration でマネージドクエリ結果を設定できます.

基本的な設定例

マネージドクエリ結果を有効にする最小限の設定は以下の通りです.

resource "aws_athena_workgroup" "example" {
  name = "example"

  configuration {
    managed_query_results_configuration {
      enabled = true
    }
  }
}

KMS 暗号化を指定する場合

マネージドクエリ結果に対して KMS キーで暗号化を行う場合は,encryption_configuration ブロックを追加します.

resource "aws_athena_workgroup" "example" {
  name = "example"

  configuration {
    managed_query_results_configuration {
      enabled = true

      encryption_configuration {
        kms_key = aws_kms_key.example.arn
      }
    }
  }
}

KMS キーを指定する場合,Athena のサービスプリンシパルがキーを使用できるよう KMS キーポリシーの設定が必要です.ドキュメントに記載されているポリシー例を参考に,以下のように設定します.

特定のワークグループに限定する場合

{
    "Sid": "Allow athena service principal to use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": "encryption.athena.amazonaws.com"
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:Describe*"
    ],
    "Resource": "arn:aws:kms:{region-name}:{account-id}:key/{key-id}",
    "Condition": {
        "ArnLike": {
            "kms:EncryptionContext:aws:athena:arn": "arn:aws:athena:{region-name}:{account-id}:workgroup/{workgroup-name}",
            "aws:SourceArn": "arn:aws:athena:{region-name}:{account-id}:workgroup/{workgroup-name}"
        },
        "StringEquals": {
            "aws:SourceAccount": "{account-id}"
        }
    }
}

なお,クエリを実行するユーザーの IAM ポリシーにも KMS キーへの kms:GenerateDataKey および kms:Decrypt アクションの実行権限が必要です.

まとめ

Athena のマネージドクエリ結果を Terraform で設定する方法を整理しました.managed_query_results_configuration ブロックで enabled = true とするだけで有効化できるため,クエリ結果用の S3 バケット管理を省略したい場合に活用してみてください.

Bytebase の API でグループメンバーを取得するメモ✍

タダです.

以下の記事でBytebaseのグループアサインをMicrosoft EndtraIDグループで行いました.そのグループメンバーを API で取得したかったのでやり方を調べたメモを残します.

sadayoshi-tada.hatenablog.com

サービスアカウントの準備

Bytebase API を呼ぶには, まずサービスアカウントを作成してサービスキーを取得する必要があります.

  1. Workspace Admin でログインし, IAM & Admin > Users & Groups を開く
  2. + Add User からアカウントタイプを Service Account にしてアカウントを作成する
  3. 作成後に Copy Service Key でキーを取得する

トークンの取得

サービスアカウントのメールアドレスとサービスキーを使って /v1/auth/login にリクエストし, アクセストークンを取得します.

export BYTEBASE_URL=https://<your-bytebase-host>
export SERVICE_ACCOUNT=api-sample@service.bytebase.com
export SERVICE_KEY=<copied-service-key>

TOKEN=$(curl -s -X POST "${BYTEBASE_URL}/v1/auth/login" \
  -H "Content-Type: application/json" \
  -d "{\"email\": \"${SERVICE_ACCOUNT}\", \"password\": \"${SERVICE_KEY}\"}" \
  | jq -r '.token')

取得したトークンは以降のリクエストで Authorization: Bearer ヘッダーに付与して使います.

特定グループのメンバー取得

特定のグループのみ取得したい場合は GET /v1/groups/{group} を使います. {group} にはMicrosoft EndtraIDグループのオブジェクトIDを指定します.

GROUP_ID=[オブジェクトID]

curl -X GET "${BYTEBASE_URL}/v1/groups/${GROUP_ID}" \
  -H "Authorization: Bearer ${TOKEN}" \
  | jq .

これでグループ名とそのグループに所属するメンバー一覧が返ってきます.メンバーを絞り込む場合は jq で加工できます.

curl -s -X GET "${BYTEBASE_URL}/v1/groups/${GROUP_ID}" \
  -H "Authorization: Bearer ${TOKEN}" \
  | jq .members

まとめ

Bytebase の API でMicrosoft EndtraIDグループメンバーを取得する方法をまとめました. サービスアカウントのトークンを取得した後, /v1/groups/v1/groups/{group} を叩くことでメンバー情報を取得できます.

IAMロール作成がサービスワークフロー内で完結するようになったメモ✍

タダです.

2026年3月4日に IAM ロールの作成フローが改善されるアップデートがリリースされました.

aws.amazon.com

これまでの課題

AWSコンソールで各サービスを設定する際,IAMロールの作成が必要になる場面は多くあります.たとえば Lambda 関数を作成するとき,EC2 インスタンスにインスタンスプロファイルを付与するときなどです.

これまでの操作フローはこうでした.

  1. Lambda の設定画面を開く
  2. 「新しいロールを作成する」→ IAMコンソールへ遷移
  3. 別タブでロールを作成し,ポリシーをアタッチ
  4. 元のLambdaの設定画面に戻ってロールを選択

タブを行き来する手間があり,設定を進めながら「どのロールを作ったっけ」と混乱することがありました.

何が変わったか

このアップデートにより,サービスの設定画面から離れることなくその場で IAM ロールを作成できるようになりました.ロール設定が必要になると画面内に新しいパネルが表示され,権限を設定してロールを作成したらそのまま元の設定フローへ戻れます.

権限の設定方法は2つ用意されています.

  • デフォルトポリシー: そのサービスに推奨される権限がプリセットとして用意されており,ワンクリックで選択できます
  • シンプルなステートメントビルダー: カスタム権限をその場で定義できます

例えば Lambda 関数の作成画面では,Permissions セクションで「Create default role」を選択すると,その場でロールが作成されます.

Lambda 関数作成画面の Permissions セクション

「Use another role」を選択するとロールの作成パネルが画面内に展開され,デフォルトポリシーの確認や追加ポリシーの設定をその場で行えます.

画面内で開くロール作成パネル

また,このフローで作成されるロールは一時認証情報を使用する IAM ロールであるため,ハードコードされたアクセスキーを排除できる点もメリットです.

対応サービス・リージョン

2026年3月時点では US East (N. Virginia) リージョンのみの提供で,対応サービスは以下の通りです.

サービス
Amazon EC2
AWS Lambda
Amazon EKS
Amazon ECS
AWS Glue
AWS CloudFormation
AWS Database Migration Service
AWS Systems Manager
AWS Secrets Manager
Amazon Relational Database Service
AWS IoT Core

今後,他のサービス・リージョンへ順次展開される予定とのことです.

IAMロールの作成全般については以下のドキュメントも参考にしてください.

docs.aws.amazon.com

まとめ

IAMロール作成がサービスワークフロー内で完結するようになったアップデートを紹介しました.東京リージョンへの展開も楽しみにしたいと思います.

SRE Kaigi 2026 延長戦で登壇してきたので振り返りメモ✍

タダです.

SRE Kaigi 2026 延長戦で登壇させてもらったので振り返ります.

sre-connect.connpass.com

発表資料

発表資料は以下になります.

もともとは下記の記事で書いた勉強会で話した内容からのアップデートと合わせて昨今の生成AI 発展に伴って自分たちに求められていることを話しさせてもらいました.

sadayoshi-tada.hatenablog.com

所感

昨今の生成AIの進化が急速になっていることでコーディングエージェントによるコードの変更量が増えているがその後の工程が変化に追いついていないという自戒があり自分自身のマインドセットを変える必要があることを提起させてもらいました.できる限り人間の介入を減らして人間がボトルネックにならないようにしつつ品質保証および信頼性も維持した体制構築が急務だという意味合いで話をしていました.

自分の取り組みはまだ始まったばかりで価値提供ができていないのでこれからも改善をしていきたいです.

また,SRE Kaigi 2026の「AIと新時代を切り拓く。これからのSREとメルカリIBISの挑戦」という発表を聴講して自分の取り組みの延長線にある課題を共有してくださり,大変勉強になった話に触れました.中でも利用者がbotに対して問い合わせをするという設計では利用が進まなかったとというお話は同感で人間同様にアラートの調査をしている時に滑らかに参加して調べた結果をレポートしたり過去事例からアクションを提案できるようにしないと役立てないよなと今後の発展部分で気をつけたい点を教えていただきました.

sadayoshi-tada.hatenablog.com

内製したものがちゃんと使われるところに至るまでには業務に溶け込む滑らかさとプロアクティブな挙動を心がけて改善をしたいと思います.

まとめ

SRE Kaigi 2026 延長戦で登壇させていただいたので振り返りをしました.人生初の基調講演という貴重な機会をいただけて,本当にありがたかったです.懇親会で自分の発表と同じようなことをやってみたいと思っていたという話からやってみようと思うという話を聞けたのも嬉しかったです.

Claude Code × Agent Plugins for AWS を試したメモ✍

タダです.

AWS が公開した Agent Plugins for AWS を使い ブログサイトを実際にデプロイするところまで検証しました。その模様をまとめます.

github.com

aws.amazon.com

Agent Plugins for AWSとは

Agent Plugins for AWSとは AWS が公開している,AI エージェント向けの拡張プラグインです.AI に単発でコードを書かせるのではなく「分析 → 構成提案 → コスト試算 → IaC生成 → デプロイ」というワークフローをスキルとして組み込めるのが特徴です.現在はClaude Code と Cursor に対応しています.この記事では Agent Plugins for AWS を Claude Code にインストールしました.

 /plugin marketplace add awslabs/agent-plugins
  ⎿  Successfully added marketplace: agent-plugins-for-aws

❯ /plugin install deploy-on-aws@agent-plugins-for-aw
  ⎿  (no content)

❯ /plugin install deploy-on-aws@agent-plugins-for-aws
  ⎿  ✓ Installed deploy-on-aws. Restart Claude Code to load new plugins.

検証

/deploy-on-aws:deploy を試してみます.デフォルトで用意されている Amplify Hosting で行う Nextjs にデプロイします.その際にかかるコストも出してくれました.AWS を利用するに当たって利用料の試算をしてくれるのは嬉しいですね.

 /deploy-on-aws:deploy

⏺ I'll help you deploy to AWS! Let me first analyze your codebase to understand what we're working with.

⏺ I see you're in your home directory. You have several project directories here. Which application would you like to deploy to AWS? I can see a
  few candidates:

  - blog-app - A blog application
  - my-app / my-react-app - React apps
  - next-market - Possibly a Next.js marketplace
  - go_todo_app - A Go todo application
  - flamboyant-lemur-200 - Unknown project

⏺ User answered Claude's questions:
  ⎿  · Which project would you like to deploy to AWS? → blog-app

⏺ Let me analyze the blog-app project.

⏺ Searched for 1 pattern, read 2 files (ctrl+o to expand)

⏺ Explore(Explore blog-app structure)
  ⎿  Done (15 tool uses · 53.7k tokens · 17s)
  (ctrl+o to expand)

⏺ Good. Here's what I found:

  Analysis: blog-app

  ┌───────────┬────────────────────────────┐
  │ Attribute │           Value            │
  ├───────────┼────────────────────────────┤
  │ Framework │ Next.js 16 (App Router)    │
  ├───────────┼────────────────────────────┤
  │ Language  │ TypeScript                 │
  ├───────────┼────────────────────────────┤
  │ Styling   │ Tailwind CSS               │
  ├───────────┼────────────────────────────┤
  │ API       │ Next.js API Routes (REST)  │
  ├───────────┼────────────────────────────┤
  │ Database  │ In-memory (no external DB) │
  ├───────────┼────────────────────────────┤
  │ Auth      │ None                       │
  └───────────┴────────────────────────────┘

  This is a straightforward Next.js app with server-side rendering and API routes, using in-memory storage.

  Recommended AWS Service: AWS Amplify Hosting

  Why Amplify:
  - Native Next.js SSR support (including API routes)
  - Zero infrastructure management - just connect and deploy
  - Built-in CI/CD, custom domains, HTTPS
  - Pay-per-request pricing is ideal for a dev/blog app
  - No need for containers, load balancers, or Lambda config

  Note: Since your app uses in-memory storage, data resets on each deployment/cold start. This is fine for dev. For persistence, you'd add
  DynamoDB later.

  Let me get you a cost estimate before proceeding.

⏺ plugin:deploy-on-aws:awspricing - get_pricing_service_codes (MCP)(filter: "amplify")
  ⎿  {
       "result": [
         "AWSAmplify"
     … +2 lines (ctrl+o to expand)

⏺ plugin:deploy-on-aws:awspricing - get_pricing (MCP)(service_code: "AWSAmplify", region: "us-east-1", output_options:
                                                     {"pricing_terms":["OnDemand","FlatRate"],"exclude_free_products":false})
  ⎿  {
       "result": {
         "status": "success",
     … +85 lines (ctrl+o to expand)

⏺ Cost Estimate (us-east-1, dev usage)

  ┌──────────────────┬───────────────────┬────────────────────────────┬──────────────┐
  │    Component     │    Unit Price     │      Estimated Usage       │ Monthly Cost │
  ├──────────────────┼───────────────────┼────────────────────────────┼──────────────┤
  │ Build            │ $0.01/min         │ ~15 min (5 builds × 3 min)$0.15        │
  ├──────────────────┼───────────────────┼────────────────────────────┼──────────────┤
  │ SSR Requests     │ $0.30/1M requests │ ~10K requests              │ $0.003       │
  ├──────────────────┼───────────────────┼────────────────────────────┼──────────────┤
  │ Compute Duration │ $0.20/GB-hour     │ ~2,560 GB-sec              │ $0.14        │
  ├──────────────────┼───────────────────┼────────────────────────────┼──────────────┤
  │ Data Transfer    │ $0.15/GB          │ ~1 GB                      │ $0.15        │
  ├──────────────────┼───────────────────┼────────────────────────────┼──────────────┤
  │ Storage          │ $0.023/GB         │ ~0.5 GB                    │ $0.01        │
  ├──────────────────┼───────────────────┼────────────────────────────┼──────────────┤
  │                  │                   │ Total                      │ ~$0.45/month │
  └──────────────────┴───────────────────┴────────────────────────────┴──────────────┘

  Amplify also has a free tier (first 12 months): 1,000 build minutes, 5 GB storage, 15 GB data transfer served per month — so this app would
  likely be free for the first year.

コスト試算の後は専用のリポジトリ作成と CDK のプロジェクトの作成・デプロイまで一気通貫で行えて初期構築でにかかる手間をすべて賄ってくれました.

⏺ User answered Claude's questions:
  ⎿  · Ready to proceed with generating the AWS Amplify IaC code and deploying? → Yes, proceed

⏺ Let me generate the CDK infrastructure code and prepare for deployment.

⏺ Task(Research Amplify CDK patterns) Haiku 4.5
  ⎿  Done (7 tool uses · 66.8k tokens · 2m 18s)
  (ctrl+o to expand)

⏺ Bash(cd /Users/tady/blog-app && git remote -v 2>/dev/null; echo "---"; git log --oneline -5 2>/dev/null)
  ⎿  ---
     9060c3b Initial commit from Create Next App

~中略~

⏺ GitHub CLI is authenticated. Here's the plan:

  1. Create GitHub repo and push blog-app code
  2. Generate CDK infrastructure for Amplify Hosting
  3. Deploy the CDK stack

  Let me start by creating the GitHub repo and pushing the code, then generating the CDK infrastructure.

⏺ User answered Claude's questions:
  ⎿  · I'll create a GitHub repository and push your blog-app code, then deploy via CDK. OK to create a GitHub repo named 'blog-app' under
     your account (tasogare0919)? → Yes, private repo

⏺ Bash(gh repo create blog-app --private --source=. --push 2>&1)
  ⎿  https://github.com/tasogare0919/blog-app
     To github.com:tasogare0919/blog-app.git
      * [new branch]      HEAD -> main
     branch 'main' set up to track 'origin/main'.

⏺ Repo created and code pushed. Now let me create the CDK infrastructure.

~中略~

⏺ Now let me install dependencies and validate the CDK code.

~中略~
⏺ CDK synth is valid. Now let me run a security check on the template.

~中略~

⏺ Build succeeded! Your blog app is now live.

  Deployment Complete

  ┌─────────────┬────────────────────────────────────────────────────┐
  │  Resource   │                       Value                        │
  ├─────────────┼────────────────────────────────────────────────────┤
  │ App URL     │ https://main.d60hzz1t5hoge.amplifyapp.com          │
  ├─────────────┼────────────────────────────────────────────────────┤
  │ Region      │ ap-northeast-1 (Tokyo)                             │
  ├─────────────┼────────────────────────────────────────────────────┤
  │ App ID      │ d60hzz1t5hoge                                      │
  ├─────────────┼────────────────────────────────────────────────────┤
  │ GitHub Repo │ https://github.com/tasogare0919/blog-app (private) │
  ├─────────────┼────────────────────────────────────────────────────┤
  │ Stack       │ BlogAppStack                                       │
  ├─────────────┼────────────────────────────────────────────────────┤
  │ CI/CD       │ Auto-build on push to main                         │
  └─────────────┴────────────────────────────────────────────────────┘

  What was deployed

  - AWS Amplify Hosting (WEB_COMPUTE) - SSR-enabled Next.js hosting
  - IAM Role - Compute role for Amplify SSR
  - Secrets Manager - GitHub token stored securely
  - Auto-deploy branch - main branch with CI/CD

  Cost

  Estimated ~$0.45/month for dev usage (covered by free tier for first 12 months).

  Next steps

  - Push changes to main to trigger auto-deploy
  - Add a custom domain via Amplify console or CDK
  - For data persistence, consider adding DynamoDB (currently in-memory storage)

まとめ

Agent Plugins for AWS でアプリケーションを用意し,デプロイを試してみました.初期の最小構成での検証としては利用して AWS のインフラ構成を作る時間を短縮できるかもしれないと感じました.




以上の内容はhttps://sadayoshi-tada.hatenablog.com/より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14