tonapaのブックマーク (910)

  • Lambdaの冪等性について学びながら整理してみた - Qiita

    はじめに AWS Lambda を使った処理では、同じイベントや同じリクエストが複数回処理されることがあります。 最初は「Lambda が2回動くことなんてそんなにあるのか?」と思っていたのですが、調べていくと、Lambda や周辺サービスを使う以上、重複実行は普通に考慮しておいた方がよさそうだと感じました。 たとえば、以下のようなケースです。 API クライアントがタイムアウトして、同じリクエストを再送する EventBridge、S3イベント通知、SNS などの非同期イベントで Lambda が再実行される SQS、Kinesis、DynamoDB Streams などから同じメッセージやレコードが再処理される Lambda の処理中にタイムアウトし、呼び出し元やイベントソース側で再試行される 処理自体は成功したが、その後のエラーによって Lambda 全体としては失敗扱いになる この

    tonapa
    tonapa 2026/06/29
  • AWSのIAMロール・ポリシー・許可セットの関係を整理する - Qiita

    ポイントは、実体を持って「操作する主体」になれるのはユーザーやロールで、アカウントはそれらを内包する箱にすぎないということです。 ポリシーは「できることの定義書」 ポリシーは、たとえば「ec2:DescribeInstances を許可する」のように、できることの中身そのものを書いた定義です。 重要なのは、ポリシーは単体では誰にも効力を持たないという点です。ユーザーやロールにアタッチして初めて意味を持ちます。台だけ置いてあっても、誰かが演じなければ何も起きないのと同じです。 ロールは「台を持った衣装」 ロールは、ユーザーのように特定の人へ固定された身分ではなく、必要なときに人やサービスが「引き受ける(assume する)」ための、権限の入れ物です。 衣装(ロール)には、どの台(ポリシー)を持たせるかが結びついている 人がその衣装を着ている間は、台に書かれた権限で動ける ログイン時に

    AWSのIAMロール・ポリシー・許可セットの関係を整理する - Qiita
    tonapa
    tonapa 2026/06/23
  • CDKをやめてTerraformに移行しようか迷っている話 vol.1

    これはなに どうもかわごえです。 わたし、めっちゃCDKが好きです。Cfnも大好きです。 AWSの中で好きなサービスは?と聞かれたら、間違いなくこれらのIaCのサービスを真っ先に挙げると思います。 いままでCDKでいろんなシステムを構築し、運用してきました。 その中でも、やはりCDKで楽になった反面、どうしても超えられない障壁があり。 これを機に、一度terraformに移行しようと考えているときの、思考のダンプです。 繰り返しになりますが私はCDKが好きですし、 小規模な開発であれば、やはり第一にCDKを選択すると思いますが 大規模なシステムといったことを考える時にはもしかすると、という話です。 どこが障壁になるか スタックあたりのリソース数という境界 まずは、ひとことで言えば、AWSのCloudFormationのStackという名の境界です。 2026/05/28時点で、1Stack

    CDKをやめてTerraformに移行しようか迷っている話 vol.1
    tonapa
    tonapa 2026/05/31
  • AWS_自動起動と自動停止

    ●Instance Scheduler ①CloudFormation テンプレートを用意して作成する。(ここでIAMポリシー設定される) ②DynamoDB InstanceSchedulerのtool自身の保存場所 ConfigTable を確認し、設定したいスケジュール名(例: default や office-hours)があるか確認(または作成)する。 ③EC2インスタンスの画面にて、AL2023にSchedule = Value のタグを貼る。 キー=Schedule Value=スケジュール名(DynamoDBに元々設定されているものがある) ④RDS画面に行き、Oracleインスタンスと ③と同じ様にタグのキーとValueに記入する。 ※Auroraの場合、シングル構成でもクラスタができてしまう。 ⑤DynamoDBにて時間を設定する。 10分後に停止、起動する用のスケジュ

    AWS_自動起動と自動停止
    tonapa
    tonapa 2026/05/21
  • パスワードの時代が終わる理由 - パスキーの仕組みを図解でわかりやすく整理する - Qiita

    はじめに 最近、GoogleApple、メルカリ、楽天、PlayStationなどで「パスキー」という言葉を見かけることが増えました。「パスワードの代わりになる新しいログイン方法らしい」くらいは知っていても、「結局それって何なの?」「なぜパスワードより安全なの?」と聞かれると、説明に困る方も多いのではないでしょうか。 この記事では、パスキーの仕組みをゼロから整理します。エンジニアでない方でも読めるよう、専門用語には例え話を添えています。 対象読者 パスキーを使い始めた、または使うように促されているが仕組みが分からない方 「なぜパスワードが時代遅れになりつつあるのか」を背景から理解したい方 開発者ではないが、認証技術の流れを把握しておきたい方 この記事で得られるもの パスキーがパスワードと比べて何が違うのか 「公開鍵暗号方式」を南京錠の比喩で理解できる 登録時とログイン時に裏側で何が起きて

    パスワードの時代が終わる理由 - パスキーの仕組みを図解でわかりやすく整理する - Qiita
    tonapa
    tonapa 2026/05/18
  • なぜ防衛省は富士通を選んだのか “国家の安全保障”を支える新システムの正体 | DXマガジン

    防衛省の予備自衛官等管理システム「ReSMS(リスモス)」の構築を、富士通が手掛けた。この事実は、単なる受託案件以上の意味を持っています。2026年、地政学リスクとデジタル化が交差する最前線において、日を代表するテックジャイアントである富士通が「国家の安全保障」をどうアップデートしようとしているのか。「富士通だからこそ成し得た」という視点から、その質を読み解きます。 1. 「信頼の象徴」としての富士通:防衛×クラウドの架け橋 防衛省という、日で最もセキュリティに厳格な組織が、Salesforceというグローバルなパブリッククラウドを採用する。この「大胆な一歩」を支えたのが、長年日のナショナルセキュリティを支えてきた富士通への「圧倒的な信頼」です。 「日を知る」企業の強み:外資系プラットフォームをそのまま導入するのではなく、日の法体系や自衛隊特有の運用ルール(郵送や電話での調整文

    なぜ防衛省は富士通を選んだのか “国家の安全保障”を支える新システムの正体 | DXマガジン
    tonapa
    tonapa 2026/05/18
  • LiteLLMでAmazon Bedrock・Vertex AI・Azure AI FoundryのLLMを呼び出してみる | DevelopersIO

    LiteLLMでAmazon Bedrock・Vertex AI・Azure AI FoundryのLLMを呼び出してみる | DevelopersIO
    tonapa
    tonapa 2026/05/08
  • AWSで整理する、フロントエンドの知識地図 - Qiita

    【序章】はじめに クラウドエンジニアフロントエンドの領域に手を伸ばすと、ReactNext.jsVue・Nuxt・LaravelRailsFastAPI…と技術の選択肢が山ほどあり、何がどう違うのか理解しにくい。記事では、デプロイ先のインフラ構成を軸に、各フレームワークがどのパターンに対応するか整理する。 先に結論 ※ ポイント:ブラウザでUIを構築する役割(FE)を担えるのは、事実上JS/TSだけ。他言語はBE(🔌)として参加する。 分類 デプロイ先 主要技術

    AWSで整理する、フロントエンドの知識地図 - Qiita
    tonapa
    tonapa 2026/05/04
  • 【Windows ネイティブ版】Amazon Bedrock を使用した Claude Code の始め方

    はじめに Claude Code は、Anthropic が開発している Agentic coding のコマンドラインツールです。Claude モデルに最適化されているという特徴があり、Anthropic 自体が提唱する MCP やスキルといった仕組みを活用しつつ、幅広いコーディングタスクを処理して開発タスクを加速できます。AWS のクレデンシャルや Bedrock のモデルアクセス権限を持った状態で、環境変数を指定すると Claude Code が Bedrock のモデルを利用するように設定できます。 この記事では、Windows ネイティブ環境で Claude Code を Amazon Bedrock 経由で使用するための設定方法を紹介します。 前提条件 以下の環境が整っていることを前提とします。 AWS のアカウントを持っていること AWS 認証情報の設定 Claude Cod

    【Windows ネイティブ版】Amazon Bedrock を使用した Claude Code の始め方
    tonapa
    tonapa 2026/05/04
  • GuardDuty Findings を Bedrock で要約して SES でメール通知する AWS サンプルを試してみた | DevelopersIO

    DLQ も用意されており、maxReceiveCount: 3 で失敗時の退避先も確保されているのが良いですね。 前提条件 試すにあたって以下の準備が必要です。 GuardDuty が有効化されている SES で送信元・宛先メールアドレスが検証済み(サンドボックスの場合は受信側も要検証) 利用リージョンで Bedrock の Claude Sonnet 4.6 モデルアクセスが許可されている 私はサンドボックスのまま試したので、送信元と受信先の両方を SES の検証済み ID に登録しました。 やってみる デプロイ リポジトリをクローンして CloudFormation でデプロイします。 test@example.comは任意の値に書き換えてください。同一アドレスでテストするだけなら 1 回の検証で済みます。 > git clone https://github.com/aws-samp

    GuardDuty Findings を Bedrock で要約して SES でメール通知する AWS サンプルを試してみた | DevelopersIO
    tonapa
    tonapa 2026/05/04
  • CloudFormation の新組み込み関数 Fn::GetStackOutput で依存関係のないクロスリージョン・クロスアカウント参照が可能になりました | DevelopersIO

    CloudFormation に新しい組み込み関数 Fn::GetStackOutput が追加されました。2016年から提供されている Fn::ImportValue では制限があった、クロスリージョン・クロスアカウントのスタック間参照がネイティブに可能になります。 この機能の存在は、AWS CDK の PR #37724(2026年5月1日マージ)で確認しました。 PR の説明文に以下の記載があります。 But CloudFormation has now released a new intrinsic function, Fn::GetStackOutput, which, as the name suggests, gets the value of a arbitrary output. This function works cross-region and cross-ac

    CloudFormation の新組み込み関数 Fn::GetStackOutput で依存関係のないクロスリージョン・クロスアカウント参照が可能になりました | DevelopersIO
    tonapa
    tonapa 2026/05/04
  • AWS Systems Manager Distributor と Automation で、組織配下の指定した EC2 にソフトウェアを配布してみた | DevelopersIO

    AWS Systems Manager Distributor と Automation で、組織配下の指定した EC2 にソフトウェアを配布してみた | DevelopersIO
    tonapa
    tonapa 2026/05/04
  • デジタル庁の生成AI基盤「源内」のOSSをAWS上で動かしてみた話

    🎯 この記事の対象読者 自治体や行政機関のデジタル部門で、源内に関心を持っている職員の方 事業者さんから提案を受ける前に、まず仕組みを自分の目で確認しておきたい方 AWSや生成AI基盤の構築に関わるエンジニアの方 行政DXの現場で「実際に動くもの」を起点に議論を進めたい方 💡 この記事を読むと得られること 源内Web(インターフェース部分)を自分のAWS環境にデプロイする際の手順、所要時間 半日の検証で発生した費用の目安 動かしてみて見えた、内部構造の解説 自治体で導入を検討する際に、技術担当として確認しておくと有益そうな観点 🚀 はじめに:なぜこの記事を書いたか 2026年4月24日、デジタル庁から「源内」(GenAI)というOSSが公開されました。中央省庁の約18万人の職員を対象とした大規模実証が令和8年度に予定されているガバメントAIの基盤の一部が、商用利用可能なライセンスで公

    デジタル庁の生成AI基盤「源内」のOSSをAWS上で動かしてみた話
    tonapa
    tonapa 2026/05/03
  • ガバメント AI「源内」の行政実務用 AI アプリ(genai-ai-api)を閉域の AWS 環境へデプロイしてみた - Qiita

    デジタル庁が政府機関で実装を進めている生成 AI 利用環境であるガバメント AI「源内」について、その一部が先日オープンソースとして公開されました。 地方自治体側としても、将来的に源内をガバメントクラウドで使うことがあるのではないかと気になっているところです。 そこで早速、地方自治体のガバメントクラウドにある基幹システムで源内を使うようなケースを想定し、源内を閉域ネットワーク環境でデプロイできないか、Claude Code に相談しながら試してみました。 genai-ai-api の閉域 AWS 環境へのデプロイ検証の構成図 閉域ネットワーク環境へ genai-ai-api をデプロイするために、元の CDK から以下のとおり変更しています。 LambdaVPC 内にデプロイする Lambda 関数から Bedrock と KMS へ VPC エンドポイント経由でアクセスさせる La

    ガバメント AI「源内」の行政実務用 AI アプリ(genai-ai-api)を閉域の AWS 環境へデプロイしてみた - Qiita
    tonapa
    tonapa 2026/05/02
  • デジタル庁のガバメントAI「源内(GENAI)」がOSS化されたので、GenUとの差分を調べながらAWSアカウントにデプロイしてみた | DevelopersIO

    デジタル庁のガバメントAI「源内(GENAI)」がOSS化されたので、GenUとの差分を調べながらAWSアカウントにデプロイしてみた いわさです。 デジタル庁が開発・運用しているガバメントAI「源内(GENAI)」をご存知でしょうか。 源内は、政府職員が安全・安心に生成AIを利用できる環境として、デジタル庁が内製開発しているプラットフォームです。 名前の由来について、デジタル庁のnote記事[1]では以下のように説明されています。 源内の名前の由来は、生成AI英語略称でGenAIと書くことから、と様々な生成AIアプリケーションの発明が集まって欲しいという願いを込めて、の2点からです。 2025年5月にデジタル庁職員向けに運用が開始され、2026年度には全府省庁の約18万人の政府職員を対象とした大規模パイロットが進められています。[2] そんな源内ですが、日2026年4月24日に一部がO

    デジタル庁のガバメントAI「源内(GENAI)」がOSS化されたので、GenUとの差分を調べながらAWSアカウントにデプロイしてみた | DevelopersIO
    tonapa
    tonapa 2026/04/26
  • いまさら AWS AppConfig に触ってみた

    はじめに 現在のプロジェクトでは、アプリケーションの設定管理を以下のように行っている。 実装コード内にconfigファイルを配置 環境変数で環境(dev/stg/prod等)を切り替え、対応するconfigを読み込む この方式で感じている不便さ: 設定を変えるたびにデプロイが必要 設定変更のレビュー・マージ・デプロイのリードタイムが長い Feature Flagのような動的な切り替えがやりづらい 環境ごとの設定差分の管理が煩雑 そこで、AWS AppConfigを使えばこのあたりが改善できるのではないかと考え、調べて試してみることにした。 今回作成したコードは以下のリポジトリに置いている。 AWS AppConfigとは AWS Systems Managerの一機能 アプリケーションの設定を外部化し、デプロイなしで動的に変更できるサービス バリデーション、段階的デプロイ、ロールバックの仕

    いまさら AWS AppConfig に触ってみた
    tonapa
    tonapa 2026/04/13
  • まずは「APIゲートウェイ」「サービスメッシュ」の基本から 分散アーキテクチャ時代のAPI管理

    組織内外における「API」(Application Programming Interface)の数が増え続ける中で、それらをいかに統制し、設計と運用の一貫性を保つかが重要な課題となっています。前回(第3回)は、「APIガバナンス」の必要性と、その質が「制限」ではなく「共通設計思想と可視性」にあることを整理しました。しかし、ガバナンスは理念だけで成立するものではありません。 重要なのは、それをどのようなアーキテクチャとして実装し、日々の運用に落とし込むかです。 APIの数が増え、システム構成が分散化・複雑化する中で、API管理は単一の方式で完結するものではなくなりつつあります。稿では、API管理の代表的な技術とその進化を整理しながら、分散型アーキテクチャにおけるAPI管理の考え方を掘り下げていきます。 1.APIゲートウェイによる集中管理――入り口を制するアプローチ API管理の領域に

    まずは「APIゲートウェイ」「サービスメッシュ」の基本から 分散アーキテクチャ時代のAPI管理
    tonapa
    tonapa 2026/04/13
  • バックエンドをLambdaにするかECS(Fargate)にするかの判断基準 - Qiita

    💡 5つの判断基準 1. ワークロードの特性(実行時間とステート) Lambda 1回の実行時間は「最大15分」 → 短時間で完了するステートレスな処理(APIのバックエンド、軽量な非同期処理など)に最適。 ECS 実行時間の制限無し。 → 15分を超えるような重いバッチ処理、機械学習の推論、WebSocketなどによるクライアントとの継続的な接続(ステートフルな処理)が必要な場合はこちら。 2. トラフィックの傾向とスケーラビリティ Lambda 突発的なアクセス増に極めて強い。アクセスが来たら一瞬で自動的に並列スケールし、使われない時はゼロ台になる。 → トラフィックの予測が難しいシステムに最適。 ECS オートスケーリングは可能だが、コンテナの起動には数十秒〜数分の時間がかかる。Lambdaほどの瞬発力はない。基的には常に必要最小限のコンテナを稼働させておき、メトリクス(CPU使

    バックエンドをLambdaにするかECS(Fargate)にするかの判断基準 - Qiita
    tonapa
    tonapa 2026/04/12
  • AWS振り返り記事 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 💡AWSを学び始めたきっかけ 仕事の内容に release が関わっており、その流れの中でAWSに頻繁に触れる機会がありました。 この機会を活かして、AWSの知識をいくつか学びました。 ❓AWSとは AWSAmazon Web Services)は、Amazonが提供するクラウドサービスプラットフォームです。サーバー、ストレージ、データベース、監視、デプロイツールなどのインフラが必要な場合でも、必要に応じていつでも該当するサービスを利用開始できます。 📝現在主に触れて学んだAWSサービス ⭐ EC2:クラウドサーバー EC2は、ク

    AWS振り返り記事 - Qiita
    tonapa
    tonapa 2026/04/12
  • [Amazon Bedrock] S3 Vectors + Rerank の Knowledge Base を CDK で一撃デプロイ ― ハマりどころと解決策 | DevelopersIO

    [Amazon Bedrock] S3 Vectors + Rerank の Knowledge Base を CDK で一撃デプロイ ― ハマりどころと解決策 | DevelopersIO
    tonapa
    tonapa 2026/04/11