AWS

Amazon Bedrock が OpenAI API 互換を提供開始 — Mantle 推論エンジンが「モデルの交換可能性」を実現する @publickey が X で投稿した、Amazon Bedrock の OpenAI API 互換機能に関するブログ記事が話題を呼んでいます。 ブログ書きました： 「Amazon Bedrock」でOpenAI API互換を提供開始。オープンウェイトな基盤モデルでOpenAI SDKが利用可能に Publickey の元記事によると、AWS は Amazon Bedrock の Mantle 推論エンジンで OpenAI API 互換機能の提供を開始しました。これにより、開発者は使い慣れた OpenAI SDK をそのまま Amazon Bedrock 上で利用できるようになります。 この動きは単なる「API の互換性」にとどまらず、AI 業界の構造を変える可能性を持っています。本記事では、Mantle 推論エンジンの技術的な仕組みと、この互換性がもたらす業界への影響を掘り下げます。 Mantle 推論エンジンとは何か 分散推論の基盤 Mantle は、Amazon Bedrock のために構築された大規模モデル向け分散推論エンジンです。単なる API ラッパーではなく、以下の機能を内包する本格的な推論インフラです。 機能 説明 サーバーレス推論 容量管理を自動化し、デフォルトのクォータを引き上げ OpenAI API 互換 Chat Completions API / Responses API をネイティブサポート ステートフル会話管理 会話履歴をサーバー側で保持（Responses API） 非同期推論 長時間実行ワークロードのバックグラウンド処理 ストリーミング リアルタイムのレスポンス生成に対応 ゼロオペレーターアクセス NitroTPM による暗号学的な実行環境保証 セキュリティ設計 Mantle のセキュリティ設計は注目に値します。EC2 インスタンス証明（Instance Attestation）機能を活用し、顧客データ処理のための硬化された不変のコンピュート環境を構成しています。Nitro Trusted Platform Module（NitroTPM）による暗号署名付き証明測定で、モデルの重みと推論オペレーションを保護します。 ...

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス AI エージェントが .env ファイルを読み取るリスクが現実のものとなり、平文の .env を代替するツールが続々と登場しています。本シリーズでは aws-vault、lkr、dotenvx + 1Password CLI をそれぞれ解説してきました。 しかし「結局どれを使えばいいのか」という疑問が残ります。本記事では、4つのツールの守備範囲・強み・限界を比較し、チーム構成や開発環境に応じた選択指針を提示します。 4ツールの守備範囲 最も重要な違いは管理対象の範囲です。 ツール 管理対象 DB接続 SaaS キー LLM API キー AWS 認証 aws-vault AWS 認証情報のみ - - - 対応 lkr LLM API キー（8社） - - 対応 - dotenvx .env に書ける全て 対応 対応 対応 対応 1Password CLI 全種類 対応 対応 対応 対応 aws-vault と lkr は特定領域に特化したツールです。.env に含まれる全てのシークレットをカバーするには、dotenvx か 1Password CLI が必要になります。 各ツールの強みと弱み aws-vault 1 $ aws-vault exec dev -- python manage.py runserver 強み 弱み STS 一時認証（15分〜で自動失効） AWS 認証情報しか管理できない AssumeRole による権限分離 macOS 限定（Keychain 依存） MFA 統合 チーム共有不可 漏洩しても短時間で無効化される 最大の強みは STS による一時認証です。他のどのツールも「漏洩しても自動で失効する」認証情報は提供できません。aws-vault が発行する一時認証情報は、仮に AI エージェントに読まれても最短15分で失効します。 ...

name: security-check description: Claude Code 利用における情報漏えいリスクをチェックする。 Auto Memory や CLAUDE.md への機密混入、.env の gitignore 漏れ、機密ファイルの存在などを検査する。 Claude Code の利用に関する情報漏えいリスクをチェックしてください。 チェック対象 以下の 4 カテゴリを順番に検査する。 1. Auto Memory の機密スキャン ~/.claude/ 配下の memory ファイルを検査する: 以下のパスを Glob で列挙する: ~/.claude/projects/*/memory/*.md ~/.claude/projects/*/memory/**/*.md 各ファイルを Read で読み込み、以下のパターンを Grep で検出する: API キー・トークン: (?i)(api[_-]?key|secret[_-]?key|access[_-]?token|bearer)\s*[:=]\s*\S+ パスワード: (?i)(password|passwd|pwd)\s*[:=]\s*\S+ AWS 認証情報: (?i)(AKIA[0-9A-Z]{16}|aws[_-]?secret) 接続文字列: (?i)(mysql|postgres|redis|mongodb):\/\/\S+ 個人情報パターン: メールアドレス、電話番号、マイナンバーらしき数字列 金額・契約情報: (?i)(契約金額|単価|請求|売上)\s*[:：]\s*[\d,￥¥$]+ 顧客 ID の具体値: (?i)(顧客id|customer[_-]?id|ユーザーid|user[_-]?id)\s*[:=：]\s*\d+ 検出があれば、ファイルパス・行番号・該当箇所を報告する 2. CLAUDE.md の機密スキャン プロジェクトの CLAUDE.md およびグローバルの ~/.claude/CLAUDE.md を検査する: 両ファイルを Read で読み込む チェック 1 と同じパターンで Grep 検査する 加えて、以下も確認する: URL にトークンやキーが含まれていないか（?token=, ?key=, ?secret=） 内部 IP アドレスやホスト名が含まれていないか CLAUDE.md はリポジトリにコミットされるため、検出時は即時対応を推奨として強調する 3. 機密ファイルの gitignore チェック プロジェクトルートで以下を確認する: ...

Agent Plugins for AWS — AI コーディングエージェントに AWS の専門知識を装着する 紹介ポスト: moritalous 公式ブログ: Introducing Agent Plugins for AWS | AWS Developer Tools Blog リポジトリ: awslabs/agent-plugins はじめに 2026年2月、AWS は Agent Plugins for AWS をオープンソースで公開した。Claude Code や Cursor といった AI コーディングエージェントに AWS の専門知識を「スキル」として装着するプラグインライブラリである。 これは単なる CLI ラッパーではない。AI エージェントがアーキテクチャ設計 → コスト見積もり → IaC 生成 → デプロイまでを一貫して実行できる「AWS ドメイン能力層」を追加するもの。 従来: 開発者が AWS ドキュメントを読み → 設計を考え → CDK/CFn を書き → デプロイ 今後: 「deploy to AWS」と言うだけ → AI が全工程を実行（人間は確認・承認のみ） Agent Plugin とは何か プラグインの構成要素 Agent Plugin は4つの部品を1つのパッケージにまとめたもの。 ...

CloudFront → ALB → Django 構成で API レスポンスの URL スキームが http:// になる問題と解決策 はじめに AWS の CloudFront + ALB + ECS Fargate で Django REST Framework (DRF) の API サーバーを運用していたところ、API レスポンスに含まれる URL が http:// で返されるという問題に遭遇しました。本記事では原因の調査過程と、最終的な解決策を紹介します。 構成 Client (HTTPS) ↓ CloudFront (SSL終端, us-east-1) ↓ HTTP ALB (HTTP:80のみ受付, ap-northeast-1) ↓ HTTP ECS Fargate (Gunicorn + Uvicorn, port 9000) ↓ Django REST Framework CloudFront がSSLを終端し、ALB へは HTTP で転送する構成です。 問題 DRF の API ルート (/api/rest/) にアクセスすると、レスポンスに含まれる URL がすべて http:// になっていました。 ...

CDC AWS環境で実現するには、主に以下の2つの方法が主流です。 AWS DMS (Database Migration Service) の利用 (実績が豊富で柔軟性が高い) Amazon RDS ゼロ ETL 統合 (最もシンプルで最新の選択肢) それぞれの構成と特徴を詳しく解説します。 1. AWS DMS (Database Migration Service) を利用した構成 AWS DMSは、データベース間のデータ移行や継続的なレプリケーション（CDC）を行うための専用サービスです。 構成の概要 RDS for MySQLの設定: MySQLの**バイナリログ（Binlog）**を有効にし、フォーマットをROWに設定します。DMSはこれを読み取って変更を追跡します。（CDCの必須設定） AWS DMS コンポーネント: レプリケーションインスタンス: データ移行（レプリケーション）を実行する専用のEC2インスタンスです。ソースとターゲットの間でデータを読み書きし、マッピングや変換を行います。 ソースエンドポイント: RDS for MySQLへの接続情報を定義します。 ターゲットエンドポイント: Amazon Redshiftへの接続情報を定義します。 移行タスク: CDC（継続的レプリケーション）を定義するコア設定です。どのテーブルを移行するか、フルロード後にCDCを継続するかなどを指定します。 データフロー: RDS for MySQLで変更（UPDATE/INSERT/DELETE）が発生すると、その変更がBinlogに記録されます。 DMSのレプリケーションインスタンスがBinlogを継続的に読み取ります。 DMSは変更データをRedshiftに適した形式に変換し、Redshiftクラスターに書き込みます（通常はS3経由でCOPYコマンドを使用）。 メリット・デメリット 項目 メリット デメリット 柔軟性 非常に高く、多種多様なデータベースに対応。テーブルやスキーマのフィルタリング、データ変換（トランスフォーメーション）も可能。 コスト レプリケーションインスタンスの料金が継続的に発生する。 運用 インスタンスの管理（サイズ選定、冗長性など）や、Binlogの保持期間の管理が必要。 安定性 実績が豊富で安定しているが、タスク設定やインスタンスサイズによってはチューニングが必要になる場合がある。 2. Amazon RDS ゼロ ETL 統合 (推奨) これは、2023年以降に登場した新しい機能で、最もシンプルかつ管理負担の少ないCDCの方法です。現時点ではAurora MySQLからRedshiftへの統合が中心ですが、RDS for MySQLへの対応も進んでいます。 ...

AWS Device Farm AWS Device Farmとは？利点と利用方法も紹介します！ AWS Device Farmとは？実機を使ったモバイルアプリのテストについて解説 AWS Device Farmは、実際のモバイルデバイスやデスクトップブラウザを使用してアプリケーションをテストするサービスです。以下のような仕組みで動作しています： 実機デバイスの使用: AWS Device Farmは、エミュレーターやシミュレーターではなく、実際のスマートフォンやタブレットを使用します。 これにより、メモリ使用量、CPU負荷、位置情報、メーカーやキャリアによるファームウェアの違いなど、実際の使用環境に近い条件でテストが可能です 1 2。 リモートアクセス: 開発者はAWSのクラウド上にあるこれらの実機デバイスにリモートでアクセスし、アプリケーションをインストールしてテストを実行します。 これにより、物理的なデバイスを手元に用意する必要がなくなります 1 2。 自動化と手動テスト: Device Farmは、AppiumやEspressoなどのオープンソースのテストフレームワークを使用して自動テストを実行できます。 また、リモートアクセスを利用して手動でのテストも可能です 1 2。 テスト結果の収集と分析: テストの実行中に、動画、ログ、パフォーマンスデータなどが収集され、これらのデータを分析することで、アプリケーションの問題点を迅速に特定し、修正することができます 1 2。 スケーラビリティ: 複数のデバイスやブラウザで同時にテストを実行できるため、テストスイートの実行時間を短縮し、効率的にテストを進めることができます 1 2。 このように、AWS Device Farmは実際のデバイスを使用して、より現実に即したテスト環境を提供し、アプリケーションの品質向上を支援しています。

Grafana Grafanaでかっけぇダッシュボード作るよ！(構築・設定編) ネットワークメトリクスを視覚化してみた（collectd + Graphite + Grafana） 収集：collectd - SNMPでルータからメトリクスを収集する 蓄積：Graphite - 収集したメトリクスを保存する 描画：Grafana - メトリクスを時系列で表示する AWS AWSの利用料金をGraphina（Grafana）を使って可視化する事例について、いくつかの方法があります。以下はその一例です。 事例: GrafanaでAWSのコストを可視化 請求メトリクスの取得: まず、AWS側で請求額のメトリクスを取得します。AWS Cost ExplorerやCloudWatchを使用して、必要なデータを収集します。 認証情報の作成: Grafanaで使用するためのIAMユーザーを作成し、必要なポリシー（例: CloudWatchReadOnlyAccess）をアタッチします。アクセスキーとシークレットキーを取得します。 データソースの設定: GrafanaのデータソースとしてCloudWatchを設定します。取得したアクセスキーとシークレットキーを使用して認証を行います。 ダッシュボードのインポート: Grafanaのダッシュボードテンプレートを使用して、AWSのコストを可視化するダッシュボードをインポートします。例えば、「AWS Billing Dashboard」というテンプレートを使用することができます¹。 カスタマイズ: インポートしたダッシュボードを自分のニーズに合わせてカスタマイズします。不要なデータを削除したり、必要な情報を追加したりします。 具体的な手順 IAMユーザーの作成: 1 2 3 aws iam create-user --user-name <username> aws iam attach-user-policy --user-name <username> --policy-arn arn:aws:iam::aws:policy/CloudWatchReadOnlyAccess aws iam create-access-key --user-name <username> Grafanaでの設定: Grafanaのメニューから「Connections > Data sources > Add new data source」を選択し、CloudWatchをデータソースとして追加します。 IAMユーザーのアクセスキーとシークレットキーを入力し、リージョンを us-east-1 に設定します。 ダッシュボードのインポート: ...

AWS ECS Fargate: pidMode AWS FargateのpidModeは、タスク内のコンテナ間でプロセスID（PID）名前空間を共有するための設定です。これにより、同じタスク内のコンテナが互いのプロセス情報にアクセスできるようになります¹²。 例えば、モニタリング用のサイドカーコンテナが、他のコンテナのプロセス情報を取得して監視することが可能になります。FargateではpidMode=taskのみがサポートされており、これを有効にすると、タスク内のすべてのコンテナが同じPID名前空間を共有します²。 この機能は、特にセキュリティや監視の観点から便利で、プロセスの監視やシステムコールのトラッキングが容易になります¹。 ソース: Copilot との会話、 2024/9/2 (1) 【アップデート】ECS on Fargateでサイドカーからプロセス …. https://dev.classmethod.jp/articles/ecs-on-fargate-support-shared-pid-namespace/. (2) AWS Fargate がプロセス ID 名前空間の共有とカーネルパラメータ …. https://aws.amazon.com/jp/about-aws/whats-new/2023/08/aws-fargate-pid-namespace-sharing-kernel-configuration/. (3) [ECS/Fargate] [request]: Support pidMode: task on Fargate #676. https://github.com/aws/containers-roadmap/issues/676. (4) 【アップデート】ECS on FargateがsystemControlsをサポートし …. https://dev.classmethod.jp/articles/ecs-on-fargate-support-systemcontrols/. (5) Amazon ECS on AWS Fargate - Datadog Infrastructure and …. https://docs.datadoghq.com/integrations/ecs_fargate/. pidModeを指定しなくてもサイドカー構成を取ることは可能です。pidModeは、特定のユースケースでプロセスID名前空間を共有するためのオプションですが、サイドカーコンテナ自体は他の方法で連携できます。 例えば、サイドカーコンテナは以下のような方法で他のコンテナと連携します： ネットワーク共有: 同じタスク内のコンテナはデフォルトで同じネットワーク名前空間を共有するため、互いに通信できます。 ボリューム共有: データを共有するために、同じボリュームをマウントすることができます。 環境変数や設定ファイル: コンテナ間で設定情報を共有するために使用できます。 これらの方法を組み合わせることで、pidModeを使用しなくても効果的なサイドカー構成を実現できます。 記事 AWS Fargate がプロセス ID 名前空間の共有とカーネルパラメータ構成のサポートを開始 Terraformを使ってAWSのECS Fargate(Django+Nginx)を構築しよう！

メモ Rye 【Python】Rye で始める Python プロジェクト Python パッケージ管理ツール比較: Poetry vs Pipenv vs Rye https://rye.astral.sh/ Contentful : Organization は削除できない 管理者の最後のアカウントが削除されたら削除できる AWS Secret Manager: 再作成 このエラーは、Secrets Manager がシークレットを直ちに削除せず、復旧期間（通常 7 日間）を設けているために発生します。この期間中は同じ名前のシークレットを再作成することができません ¹。 ただし、AWS CLI を使用して、復旧期間を設けずにシークレットを完全に削除することが可能です。以下の手順を試してみてください： 削除予定のシークレット ID を取得: AWS Secrets Manager コンソールを開きます。 ナビゲーションペインで「Secrets」を選択します。 「設定」アイコンを選択し、「詳細設定」で「削除予定のシークレットを表示」を選択します。 「Secrets」ペインで、削除予定のシークレットの ID を確認します。 AWS CLI を使用してシークレットを完全に削除: 以下のコマンドを実行します（your-secret-nameをシークレット ID または ARN に、your-regionを AWS リージョンに置き換えてください）: 1 aws secretsmanager delete-secret --secret-id your-secret-name --force-delete-without-recovery --region your-region 削除が完了したことを確認: 以下のコマンドを実行して、シークレットが完全に削除されたことを確認します: 1 aws secretsmanager describe-secret --secret-id your-secret-name --region your-region 「Secrets Manager can’t find the specified secret」というエラーが表示されれば、シークレットは正常に削除されています。 これで、同じ名前のシークレットを再作成できるようになります ¹。 ...