クラウドインフラ on AIによる技術記事備忘録

自宅サーバー公開におけるルーティング設計：Cloudflare TunnelとCaddyの役割分担

Sun, 25 Oct 2026 22:30:33 +0900

自宅サーバーで複数のWebアプリケーションをホストする際、外部公開手段としての Cloudflare Tunnel（cloudflared） 、ローカル環境用のリバースプロキシとしての Caddy、そしてLAN内の名前解決を担う AdGuard Home などのDNSサーバーを併用する設計は広く利用されています。

この構成を検討する際によく生じる疑問が、「外部からのアクセスは Caddy を経由させるべきなのか、それとも cloudflared から直接各アプリケーションのポートへ向けるべきなのか」というルーティングの設計判断です。結論から言えば、通信プロトコルとしてはいずれの経路も正常に成立します。両者の違いは正誤ではなく、システムの単純性を取るか、ローカル側での制御の一元化を取るかという設計原則のトレードオフにあります。

物理配置とネットワーク境界の前提

構成を整理する上での大前提として、各コンポーネントがネットワーク上のどこに配置されているかを正確に把握する必要があります。

外部からのトラフィックを受ける最初の接点は、インターネット上に分散配置された Cloudflare Edge です。外部ユーザーはこのエッジサーバーに対して HTTPS アクセスを行います。一方、 cloudflared の実体はインターネット上ではなく、自宅LAN内のサーバー上で動作するデーモンです。このデーモンが自宅内から Cloudflare Edge に向けて外向き（アウトバウンド）の安全なトンネル接続を確立し、外部からの要求を自宅ネットワーク内部へ引き込みます。

したがって、通信の物理的な境界線は「インターネット上の Cloudflare Edge」と「自宅LAN内の cloudflared」の間に引かれます。その上で、引き込んだトラフィックを LAN 内でどう分配するかが設計の分岐点となります。

graph TD subgraph "インターネット (WAN)" User_Ext["外部ユーザー"] CF_Edge["Cloudflare Edge"] end subgraph "自宅LAN" Tunnel["cloudflared"] User_Int["LAN内クライアント"] AGH["AdGuard Home(スプリットDNS)"] Caddy["Caddy(リバースプロキシ)"] App["Webアプリケーション群"] end User_Ext --> CF_Edge CF_Edge Tunnel User_Int -.-> AGH AGH -.-> User_Int

Caddy を経由させる構成（単一ゲートウェイ原則）

外部からの通信をすべて一度 Caddy に集約し、Caddy から各アプリケーションへ中継する構成です。この方式は、トラフィックの流入元が外部トンネルであれローカルWi-Fiであれ、すべてのアプリケーションの前段に Caddy を唯一の「内部ゲートウェイ」として配置するという思想に基づいています。

外部: ユーザー -> Cloudflare Edge -> cloudflared -> Caddy -> アプリケーション
内部: ユーザー -> (AdGuard Home で解決) -> Caddy -> アプリケーション

メリット

この構成の最大の強みは、ルーティングとアクセスログのローカル一元化にあります。cloudflared 側の設定は「ドメイン全体の通信をすべてローカルの Caddy へ流す」という抽象的なルールのみで固定できます。これにより、新しくアプリケーションを追加・変更する際も、外部のトンネル設定に手を加える必要がなく、ローカルの Caddyfile と内部 DNS レコードを更新するだけで作業が完結します。また、すべてのアクセスが Caddy を通過するため、ローカルサーバー単体で統一的なアクセスログを取得・監視することが可能です。

デメリットと注意点

この方式の課題は、二重リバースプロキシによる運用の複雑化です。Cloudflare Edge で一度終端された HTTPS 通信が Caddy に渡されるため、プロキシヘッダーの適切な伝播が不可欠となります。具体的には、Caddy 側で trusted_proxies などの設定を正しく行わないと、クライアントの送信元 IP アドレスが cloudflared のローカル IP に上書きされたり、プロトコル（HTTP/HTTPS）の認識違いによって WordPress 等のアプリケーションでリダイレクトループが発生する原因になります。また、Caddy が停止した際に外部・内部双方の通信が同時にダウンするという、単一障害点（SPOF）を抱えることになります。

Caddy を経由させない構成（疎結合・最小ホップ原則）

cloudflared が備える Ingress ルールを用い、外部からの通信を Caddy を介さずに直接各アプリケーションのポート番号へフォワードする構成です。

外部: ユーザー -> Cloudflare Edge -> cloudflared -> アプリケーション
内部: ユーザー -> (AdGuard Home で解決) -> Caddy -> アプリケーション

メリット

この構成の根拠は、不要な中間レイヤーの排除にあります。cloudflared 自体がリバースプロキシとしての転送機能を備えているため、後段にさらに Caddy を挟むことは処理遅延と障害要因を増やすだけにすぎないという判断です。多段プロキシ構造を避けることで、前述したヘッダーの食い違いや SSL 終端に起因するリダイレクトトラブルのリスクを根本から排除できます。また、Caddy の設定ミスや障害が外部公開用エンドポイントに波及しません。

デメリットと注意点

一方で、ルーティング設定が2箇所に分散するという管理上のコストが発生します。外部からのアクセス経路は Cloudflare 側（Zero Trust ダッシュボードまたはローカルの config.yml）で定義し、LAN 内からのアクセス経路は Caddyfile で個別に定義しなければなりません。ポート番号やコンテナの配置を変更した際に一方の更新を忘れると、「LAN内からは開けるが外部からは繋がらない」といった不整合が生じやすくなります。

運用における選択基準

コミュニティや実際の運用環境における傾向を踏まえると、選択の基準は「管理するサービスの規模」と「ローカル完結の重要度」に集約されます。

Caddy 経由が選ばれるケース: 多数のコンテナやサービスを自宅内で常時稼働させており、AdGuard Home によるスプリットホライズンDNSを構築してLAN内からの高速な直接アクセスを維持したい環境。サービス追加のたびに外部トンネルの設定を弄る手間を減らし、ローカル側の設定ファイル群でインフラを一元管理したい場合に適しています。
Caddy 非経由（直接転送）が選ばれるケース: 公開するサービスが少数（数個程度）に限定されている環境。Cloudflare Zero Trust の GUI 管理画面上でサブドメインの転送先とアクセス制御（Cloudflare Access 等による認証）をまとめて視覚的に管理したい場合や、多段プロキシに起因するネットワークトラブルの検証コストを最小限に抑えたい場合に適しています。

どちらの構成を選択する場合であっても、ネットワークの物理的な境界と各プロキシが担う責務の境界を明確に定義することが、安定したセルフホスト運用の基盤となります。

東京が消し飛んでもシステムを復旧させるのか？──現場を凍りつかせる「BCPチェックシート」という名の茶番

Thu, 17 Sep 2026 23:32:10 +0900

イランによるAmazonのデータセンターへの攻撃により顧客データが永久に失われる - GIGAZINE

中東にあるクラウド事業者のデータセンターが物理的な軍事攻撃を受け、単一アベイラビリティーゾーンに配置されていたデータが恒久的に失われたという報せは、インフラエンジニアや企業のリスク管理部門に冷水を浴びせました。どれほど論理的に抽象化されていようと、クラウドの実体は特定の緯度と経度に固定されたコンクリートとシリコンの塊であり、不可逆な物理破壊の前には無力であるという冷厳な事実です。

しかし、このニュースに触れたとき、私たちが真に直面させられるのは技術的アーキテクチャの敗北だけではありません。日本の多くの大企業で機械的に配られ、現場のエンジニアが半ば虚無感とともに記入させられている「事業継続計画（BCP）チェックシート」の欺瞞こそが、白日の下に晒されたと言えます。

「基幹インフラだけが無傷」というSF的ご都合主義

教科書的なBCPやクラウドの設計論では、東京リージョン（ap-northeast-1）が被災した際の解として「米国バージニア州（us-east-1）などへのマルチリージョン・フェイルオーバー」が平然と語られます。アーキテクチャ図の上では、太平洋を跨ぐ矢印を一本引くだけで対策が完了したかのように見えます。

しかし、現実の物理世界を少しでも想像すれば、この前提がギャグの領域にあることは明白です。東京が物理的に瓦解するほどの軍事攻撃や巨大災害が発生したとき、なぜ房総半島や茨城沿岸にある海底ケーブル陸揚局（CLS）や、都心のインターネットエクスチェンジ（IX）、超高圧変電所だけが奇跡的に無傷で稼働し続けているのでしょうか。

大動脈である太平洋横断ケーブル網や中継施設への給電が落ちれば、海外リージョンへのデータハイウェイそのものが瞬時に遮断されます。配管が根元から爆破されているのに、蛇口の先の水質を議論しているようなものです。海外拠点でデータが無事であろうと、それを国内の誰も参照できず、操作もできない状態であれば、そのシステムは宇宙空間を漂う無人の人工衛星と何ら変わりません。

「この状況で仕事するわけないだろ」という正常な直感

さらに奇怪なのは、そうした極限状態においても「生身の担当者が平然と職務を遂行する」という前提がチェックシートの裏に忍ばされている点です。

東京が壊滅的な打撃を受け、明日また第2波の攻撃や激しい余震が来るかもしれないという状況下で、人間が真っ先に取るべき行動は一つしかありません。家族の安全を確保し、水と食料を抱えて、生存のために一刻も早く東京から脱出することです。

電気も水道も止まり、通信も途絶えた混乱の都市において、脱出の判断を数時間誤ることはそのまま死に直結します。そんな極限状態に置かれた生身の人間に対して、「担当サービスを他リージョンへ切り替えて持続性を担保できるか」と問うこと自体、破綻した状況認識と言うほかありません。

チェックシートを埋めながら多くのエンジニアが抱く「この状況で仕事するわけないだろ」という吐き捨てるような直感は、職責の放棄などではなく、生命を維持しようとする生物として最も健全で正確な現実認識です。

組織防衛のためのアリバイ工作と責任の所在

では、なぜこのような絵空事のチェックシートが、大企業では全サービスの担当者に向けて一律に強制されるのでしょうか。理由は極めてシンプルで、それが現場の危機管理のためではなく「組織のアリバイ作り」として運用されているからです。

経営陣やリスク管理部門の目的は、実際に国家機能が麻痺したときにサービスを復旧させることではありません。株主総会、監査法人、取引先に対して「当社は全社的にリスクを評価し、統制を図っています」と報告するためのエビデンス、すなわち「記入済みシートの束」を揃えることが自己目的化しています。

そしてこの構造の最も残酷な点は、想定外の破滅が起きた際の泥を現場に被せられる余地を残していることです。「事前に貴方がこの時間で復旧できると書きましたよね」という手続きを踏ませることで、管理側は免責され、破綻の責任は「現場の見通しの甘さ」へと矮小化されます。

欺瞞を捨て、本当の「生存」から逆算する

平時のビジネスやSaaSが提供する価値は、社会インフラと法秩序という巨大な土台が正常に維持されていて初めて成立する二次的な産物に過ぎません。

組織の体裁を保つための書類仕事に大人の対応として付き合うことは、サラリーマンとしての処世術かもしれません。しかし、心の奥底にある「世界が終わっているときに、会社のシステムを心配している場合ではない」という冷徹な感覚だけは手放してはなりません。

物理インフラが国家間の武力衝突や未曾有の大災害に巻き込まれたとき、真に問われるのはSaaSの可用性ではなく、私たち自身がいかに今日を生き延びるかという、剥き出しのサバイバルなのです。

サーバレスの夢の残骸

Sat, 12 Sep 2026 14:05:03 +0900

「AWS文学」と一次資料至上主義の病理

かつて多くのエンジニアが、AWSの膨大な公式ドキュメントをお経のように熱心に読み解き、そこに書かれた仕様を忠実に実装することを美徳としていた時代がありました。難解で重層的な修飾節が連なり、例外規定と免責条項が張り巡らされたその独特な文体は、いつしか「AWS文学」と揶揄されるようになりました。この読みづらさは偶然の産物ではなく、コンウェイの法則に従って細分化された組織構造、サービスごとに異なる文脈、そして障害発生時の免責を徹底しようとする法律文書に近い執筆スタイルが重なり合った必然の結果です。

本来、技術者が真に求めているのは「目の前のシステムをどう安全に動かすか」という具体的な設計判断や勘所です。しかし、プラットフォーマーが公式文書として提示するのは「仕様の完全な網羅と免責」にすぎません。それにもかかわらず、業界には「一次資料こそが絶対の正義である」という盲目的な信仰が定着しました。一次資料が保証するのはあくまで現行実装に対する法的な正確さであり、読者が目的を達成するための実用性とは本質的に無関係です。難解なドキュメントと格闘したサンクコストを正当化し、二次情報を軽視して門番のように振る舞う文化は、エンジニアリングを手段から知的なマウンティングの道具へと変質させていきました。

現場を経験したエンジニアであれば誰しも、「ドキュメント上で保証されている仕様」と「本番環境の物理レイヤーで現実に起きる挙動」の間に横たわる深い溝を知っています。結果整合性の遅延、隠れたクォータ制限、ネットワーク断に伴う見かけ上のエラーなど、仕様書の外側にこそ現実の泥沼があります。何を読み、何を読まないかという情報選定の段階からエンジニアの責任は始まっています。公式の言説を無批判に崇める姿勢は、巨大プラットフォーマーのブランド力に自らの野生と批評精神を明け渡した結果にほかなりませんでした。

クラウドへの屈服とアーキテクチャの複雑性の爆発

なぜあの時代、これほど多くのエンジニアや組織が思考停止に陥り、プラットフォームに従属していったのでしょうか。その背景には、抗いがたい時代の構造的圧力が存在していました。かつてのオンプレミス環境における深夜のデータセンター作業、突然死するハードウェア、調達に数ヶ月を要する見積もりといった運用地獄からの解放は、あまりにも強烈なカタルシスをもたらしました。その恩恵の大きさゆえに、多少の歪みや理不尽には目を瞑るという暗黙の取引が成立してしまったのです。

さらに、資産を持たない身軽さを求める経営層からの強力なトップダウンや、急速に膨張する業界で未経験者を即戦力化するための「認定資格」を中心とした教育の標準化が、この流れを加速させました。その結果、エンジニアリングの本質である泥臭い問題解決能力よりも、プラットフォーム固有のお作法をどれだけ記憶しているかが重宝される歪んだ土壌が完成しました。

こうして熱狂の中で迎えられたクラウドでしたが、システムの進化は新たな袋小路へと突き当たります。S3、DynamoDB、Lambda、SQSといったサービス群は、インフラの存在を忘れさせる圧倒的な未来を確かに予感させました。しかし、それらを組み合わせて巨大な業務システムを構築しようとした瞬間、アーキテクチャの複雑性の爆発という過酷な代償を支払うことになりました。

かつてモノリスの内部でメモリ上の関数呼び出しとして完結していた処理が、細切れのマイクロサービスやイベント駆動へと分解された結果、単なるデータの受け渡しがすべてネットワーク越しの分散トランザクションへと化しました。重複配信への対策、メッセージの順序制御、デッドレターキューの監視、そして数千行に及ぶ設定ファイル（IaC）の保守など、コードの行数を減らした代わりにインフラの接続点と失敗パターンが指数関数的に増大していったのです。

コンテナオーケストレーションという名の欺瞞

分散システムの複雑性に疲弊した業界が次に逃げ込んだのが、ECSやKubernetesをはじめとするコンテナオーケストレーションでした。しかし、それは解決策どころか、さらなる高額な固定費と運用の怪物を飼い慣らす選択にすぎませんでした。

コンテナオーケストレーションは、本質的にIaaS（仮想インフラ）のレイヤーにとどまるリソース占有型のモデルです。どれだけ軽量なコンテナを動かそうと、背後には24時間365日稼働し続ける仮想マシンやプロビジョニングされたリソースが存在します。そこにコントロールプレーンの維持費、高額なデータ転送料、監視エージェントのオーバーヘッド、そして安全マージンとして死蔵される大量の空きリソースが積み重なります。結果として、何も処理していなくても毎月莫大なプラットフォーム税が徴収される構造から抜け出せなくなりました。

現代の物理ハードウェアは目覚ましい進化を遂げています。コンテナ基盤に投じられる年間数百万円から数千万円規模のコストがあれば、最新のワークステーションやサーバー、堅牢なネットワーク機器を一式揃え、さらには物理的なオフィススペースの賃料を払ってもお釣りが来るという計算は、決して荒唐無稽な暴論ではありません。「可用性とスケーラビリティ」という美名のもとに仮想化レイヤーの上で自作PCごっこを繰り返す経済的な不条理に、多くの現場が直面しています。

果たせぬ夢だったサーバレスと、物理バイナリへの誇り

いま振り返るべきは、私たちがかつて信じた真のサーバレスアーキテクチャの思想とは何であったかという問いです。だからこそ、コンテナを裏で自動起動するだけの仕組みを「サーバレス」と呼ぶ昨今の風潮には、強い違和感を覚えざるを得ません。それは、かつての美しい思想に対するマーケティング的な簒奪でした。

本来のサーバレスが提示した革命とは、以下のような計算モデルの根本的な転換でした。

常駐（Daemon）からの解放リクエストを待ち受けるためにリソースを占有し続ける旧来のあり方を否定し、事象（Event）が発生したその刹那だけ実体化し、計算を終えたら跡形もなく虚空へ消え去るという儚くも無駄のないモデル。
因果関係の記述への純化ハードウェアのキャパシティに頭を悩ませるのではなく、世界で起きる変化に対して純粋関数をマッピングしていくという、プログラミングの原初的な快感への回帰。
ゼロの誠実さ動いていない時間には1円のコストも発生させないという、真の従量課金がもたらす透明で合理的な経済性。

DynamoDBやLambdaは、強烈なベンダーロックインと引き換えにこの思想を極限まで具現化した稀有な道具であり、その純粋な割り切りとコストパフォーマンスにおいて、今なお独自の輝きを放っています。しかし、その純粋な思想は、業界全体の複雑化と巨大なプラットフォームビジネスの波に呑み込まれ、果たせぬ夢として終わりました。

下品な無差別サーバ攻撃の不快感

Thu, 27 Aug 2026 23:33:57 +0900

Webサイトを運用していると、海外の特定地域から意味をなさない無差別なアクセスや脆弱性スキャンが大量に押し寄せてくることがあります。実害としてはCPU使用率がわずかに上昇する程度で、システムが破綻する危険性は皆無であっても、管理者の精神やログ領域を無意味に汚染される不快感は拭えません。

無差別スキャンの実態と「下品な攻撃」がもたらす徒労感

サイトの言語設定や稼働環境を一切無視して、存在しないWordPressのログインパス（wp-login.php）や特定プラグインの脆弱性URLを機械的に乱打してくる行為は、高度なサイバー攻撃などではなく、単なる全IPアドレスへの絨毯爆撃です。感染したボットネットやスクリプトキディが、使い捨ての環境から無差別にツールを垂れ流しているに過ぎません。

かつてのハッカー文化や義賊的な存在に見られたような、一定の技術的哲学や対象への選定眼、抑制といったものはここには一切存在しません。成功確率が0%であるにもかかわらずリクエストを垂れ流す行為は、公共のインターネット空間に生ゴミを不法投棄しているのと同義です。

このような行為は、夜中に窓ガラスへ狂ったように体当たりを繰り返す害虫の羽音に似ています。室内へ侵入される危険性は皆無であるにもかかわらず、激突音を聞かされ、窓ガラスに汚れを残されることに対する純粋な生理的嫌悪感と徒労感だけが残ります。

結論としての防御方針

こうした低レベルなノイズに対して、オリジンサーバー側のリソースや管理者の意識を割くこと自体が無駄と言えます。CloudflareのようなCDN/WAFのエッジ側で機械的にBlockまたはManaged Challengeを適用し、オリジンサーバーに一切到達させない構成を敷くことが、精神衛生上および運用管理上において最も費用対効果の高い対処法となります。

AWS DynamoDBでQuery操作を行う方法【Boto3】

Wed, 08 Jan 2025 10:41:44 +0900

DynamoDBのQuery操作は、テーブルまたはインデックスのパーティションキーを指定し、条件に一致するデータを取得するために使用します。この備忘録では、基本的な使い方から応用例までを紹介します。

必要なモジュールのインポート

import boto3
from boto3.dynamodb.conditions import Key, Attr

boto3 : AWS SDK for Python。
boto3.dynamodb.conditions.Key : KeyConditionExpression に使用。
boto3.dynamodb.conditions.Attr : FilterExpression に使用。

DynamoDBリソースの初期化

DynamoDBテーブルを操作するには、Boto3リソースまたはクライアントを使用します。

# DynamoDBリソースの初期化
dynamodb = boto3.resource('dynamodb')

# テーブルを指定
table = dynamodb.Table('YourTableName')

基本的なQuery操作

パーティションキーのみを指定

from boto3.dynamodb.conditions import Key

response = table.query(
 KeyConditionExpression=Key('partition_key').eq('your_partition_value')
)

# 結果を表示
for item in response['Items']:
 print(item)

パーティションキー + ソートキー条件

response = table.query(
 KeyConditionExpression=(
 Key('partition_key').eq('your_partition_value') &
 Key('sort_key').gte('2023-01-01') # ソートキーの条件を追加
 )
)

# 結果を表示
for item in response['Items']:
 print(item)

結果のソート順を変更

昇順（デフォルト）

response = table.query(
 KeyConditionExpression=Key('partition_key').eq('your_partition_value'),
 ScanIndexForward=True # 昇順
)

降順

response = table.query(
 KeyConditionExpression=Key('partition_key').eq('your_partition_value'),
 ScanIndexForward=False # 降順
)

フィルタリングを追加

`FilterExpression` を使用

FilterExpression を使用すると、データの一部を除外できます。

response = table.query(
 KeyConditionExpression=Key('partition_key').eq('your_partition_value'),
 FilterExpression=Attr('attribute_name').contains('example_value') # 属性のフィルタリング
)

注意: FilterExpression はDynamoDBから取得したデータのフィルタリングを行います。KeyConditionExpression とは異なり、データスキャン後にフィルタリングされるためコストが増加する可能性があります。

結果のページング処理

DynamoDBはデフォルトで1MBのデータを返します。結果が複数ページにわたる場合、LastEvaluatedKey を使用して次のページを取得します。

response = table.query(
 KeyConditionExpression=Key('partition_key').eq('your_partition_value')
)

items = response['Items']

# ページング処理
while 'LastEvaluatedKey' in response:
 response = table.query(
 KeyConditionExpression=Key('partition_key').eq('your_partition_value'),
 ExclusiveStartKey=response['LastEvaluatedKey'] # 次のページの開始キー
 )
 items.extend(response['Items'])

# 全データを表示
for item in items:
 print(item)

インデックスを使用したQuery

ローカルセカンダリインデックス（LSI）やグローバルセカンダリインデックス（GSI）を指定してクエリを実行できます。

例: GSIの指定

response = table.query(
 IndexName='YourGSIName', # インデックス名を指定
 KeyConditionExpression=Key('gsi_partition_key').eq('value')
)

エラーハンドリング

DynamoDB操作中にエラーが発生する場合に備えて、エラーハンドリングを追加します。

try:
 response = table.query(
 KeyConditionExpression=Key('partition_key').eq('your_partition_value')
 )
 for item in response['Items']:
 print(item)
except Exception as e:
 print(f"エラーが発生しました: {e}")

実際のデータ例

テーブル構造

Partition Key	Sort Key	Data
user1	2023-01-01	Entry A
user1	2023-01-02	Entry B
user2	2023-01-01	Entry C

クエリ結果例

クエリ: Key('partition_key').eq('user1') & Key('sort_key').gte('2023-01-01')

結果:

[
 { "Partition Key": "user1", "Sort Key": "2023-01-01", "Data": "Entry A" },
 { "Partition Key": "user1", "Sort Key": "2023-01-02", "Data": "Entry B" }
]

注意点とベストプラクティス

適切なインデックス設計:

効率的なクエリを実現するため、事前にパーティションキーとソートキーを適切に設計します。

FilterExpression の使用を最小限に:

KeyConditionExpression を活用し、スキャンコストを削減。

エラー処理:

ネットワークエラーやスロットリング（リクエスト制限）に備えてリトライロジックを実装。

これでDynamoDBのQuery操作に関する基本と応用が網羅されています。必要に応じてコピー＆ペーストして活用してください！

AWS Systems Manager Parameter Storeからパラメータを取得する方法（Python + Boto3）

Sat, 16 Nov 2024 10:57:15 +0900

AWS Systems Manager Parameter Storeは、設定データや機密情報（APIキーやパスワードなど）を安全に管理するためのサービスです。本記事では、Pythonを使ってParameter Storeから値を取得する汎用的な方法を解説します。

必要な準備

Python環境の構築 PythonとAWS SDK for Python（Boto3）がインストールされている必要があります。以下のコマンドでBoto3をインストールします。

pip install boto3

AWSの認証情報と権限 プログラムを実行する環境に、適切なAWS認証情報が設定されている必要があります（~/.aws/credentials または環境変数）。また、以下の権限が必要です。

ssm:GetParameter
暗号化された値を取得する場合は、KMSキーの復号化権限（kms:Decrypt）

Parameter Storeへの登録 Parameter Storeに取得したい値を登録します。例として、以下のコマンドで値を登録できます。

aws ssm put-parameter \
 --name "/example/parameter" \
 --value "my-secret-value" \
 --type "SecureString"

汎用的なPythonコードスニペット

以下のコードは、Parameter Storeから値を取得するための汎用的な関数です。

import boto3
from botocore.exceptions import BotoCoreError, ClientError

def fetch_parameter(parameter_name, with_decryption=True):
 """
 AWS Systems Manager Parameter Storeからパラメータを取得する汎用関数

 Args:
 parameter_name (str): 取得するパラメータの名前
 with_decryption (bool): 暗号化された値を復号化するかどうか

 Returns:
 str: パラメータの値（取得成功時）
 None: エラー時
 """
 # SSMクライアントの初期化
 ssm_client = boto3.client('ssm')

 try:
 # パラメータの取得
 response = ssm_client.get_parameter(
 Name=parameter_name,
 WithDecryption=with_decryption
 )
 return response['Parameter']['Value']
 except (BotoCoreError, ClientError) as e:
 print(f"Error fetching parameter '{parameter_name}': {e}")
 return None

# 使用例
if __name__ == "__main__":
 parameter_name = "/example/parameter"
 value = fetch_parameter(parameter_name)

 if value:
 print(f"Parameter value: {value}")
 else:
 print("Failed to fetch the parameter.")

コードの説明

`fetch_parameter` 関数の引数

parameter_name Parameter Storeで登録されているパラメータ名を指定します。
with_decryption 暗号化されたパラメータを復号化するかを指定します。デフォルトはTrue（復号化する）です。

例外処理

BotoCoreError および ClientError は、AWSクライアントでよく発生する例外です。適切にキャッチしてエラー内容をログに記録します。

実行例

上記のコードを実行すると、Parameter Storeに登録されたパラメータの値が出力されます。

注意点

認証情報の設定 AWS CLIの設定が済んでいない場合、以下のコマンドで設定を行います。

aws configure

暗号化パラメータの権限 暗号化されたパラメータを取得するには、Parameter Storeで使用されているKMSキーに対するkms:Decrypt権限が必要です。
セキュリティ パラメータ名や値をログに直接記録しないようにしてください（特に値が機密情報の場合）。

応用例

この汎用関数を利用して、複数のパラメータをまとめて取得する場合や、環境変数として設定する場合のコード例を示します。

複数パラメータの取得

parameter_names = ["/example/param1", "/example/param2", "/example/param3"]
values = {name: fetch_parameter(name) for name in parameter_names}

for name, value in values.items():
 if value:
 print(f"{name}: {value}")
 else:
 print(f"Failed to fetch {name}")

環境変数への設定

import os

parameter_name = "/example/parameter"
value = fetch_parameter(parameter_name)

if value:
 os.environ["MY_SECRET"] = value
 print("Environment variable set successfully.")
else:
 print("Failed to set environment variable.")

まとめ

AWS Systems Manager Parameter Storeは、機密情報を安全に管理するための強力なツールです。Pythonでの利用もBoto3を使えば簡単に実現できます。このコードスニペットを活用して、セキュアで柔軟なアプリケーション構築を目指してください。

[Python, Boto3] DynamoDBのクエリで1MBを超えるデータをすべて取得する関数のスニペット

Sun, 06 Oct 2024 15:48:30 +0900

以下は、DynamoDBのクエリで1MBを超えるデータをすべて取得する汎用的な関数のスニペットです。このスニペットは、特定のテーブルや条件に依存しないため、どのプロジェクトでも簡単に利用できます。

スニペット

import boto3
from boto3.dynamodb.conditions import Key, Attr

def query_all_items(table_name, key_condition_expression, filter_expression=None):
 """
 DynamoDBテーブルからすべてのアイテムをクエリし、1MBを超えるデータも取得する。

 :param table_name: クエリするテーブルの名前
 :param key_condition_expression: クエリのKeyConditionExpression
 :param filter_expression: オプションのFilterExpression
 :return: すべてのアイテムのリスト
 """
 # DynamoDBクライアントの初期化
 dynamodb = boto3.resource('dynamodb')
 table = dynamodb.Table(table_name)

 # すべてのアイテムを格納するリスト
 all_items = []
 last_evaluated_key = None

 # ページングしてクエリを実行
 while True:
 query_params = {
 "KeyConditionExpression": key_condition_expression
 }
 # FilterExpressionがある場合は追加
 if filter_expression:
 query_params["FilterExpression"] = filter_expression

 # LastEvaluatedKeyがある場合はExclusiveStartKeyを設定
 if last_evaluated_key:
 query_params["ExclusiveStartKey"] = last_evaluated_key

 # クエリの実行
 response = table.query(query_params)

 # 結果をリストに追加
 all_items.extend(response['Items'])

 # LastEvaluatedKeyが存在する場合、次のページがある
 last_evaluated_key = response.get('LastEvaluatedKey')

 # 次のページがない場合は終了
 if not last_evaluated_key:
 break

 return all_items

使用例

# クエリ条件の定義（例: 'partition_key' が 'example_value' と等しい）
key_condition = Key("partition_key").eq("example_value")

# すべてのアイテムを取得
items = query_all_items("your_table_name", key_condition)

# 結果の出力
print(items)

オプション: `FilterExpression` の利用

フィルタ条件を追加して、結果をさらに絞り込むことができます。

# クエリ条件の定義
key_condition = Key("partition_key").eq("example_value")

# フィルタ条件の定義（例: 属性 'status' が 'active' のものだけ取得）
filter_condition = Attr('status').eq('active')

# すべてのアイテムを取得
items = query_all_items("your_table_name", key_condition, filter_condition)

# 結果の出力
print(items)

備考

table_name: クエリを実行するDynamoDBテーブルの名前。
key_condition_expression: プライマリキーの条件式を定義します。パーティションキーとソートキーの条件を設定できます。
filter_expression: 結果をさらにフィルタリングするためのオプションの条件式です。

このスニペットを活用することで、DynamoDBのすべてのアイテムをクエリしやすくなり、1MB以上のデータを扱う際のページング処理も簡単に行えます。

AWS SAMでLambda関数をスケジュール実行する

Wed, 25 Sep 2024 00:27:32 +0900

AWS LambdaをAWS SAM（Serverless Application Model）で管理する際に、特定の間隔で定期的に実行されるようにスケジュール設定する方法について説明します。たとえば、10分ごとにLambda関数を起動したい場合に、どのように設定するかを見ていきます。

SAMテンプレートにスケジュールイベントを追加

まず、既存のSAMテンプレートに新しいイベントを追加します。今回は、AWS::Serverless::Functionリソースにスケジュールイベントを設定する例を示します。

MyFunction:
 Type: AWS::Serverless::Function
 Properties:
 Handler: src/my_lambda.lambda_handler
 Role: !GetAtt MyLambdaRole.Arn
 Environment:
 Variables:
 POWERTOOLS_SERVICE_NAME: MyFunction
 Events:
 HttpRequestEvent:
 Type: HttpApi
 Properties:
 ApiId: !Ref MyApiGateway
 Path: /myendpoint
 Method: get
 ScheduleEvent:
 Type: Schedule
 Properties:
 Schedule: rate(10 minutes)

`Schedule` イベントの詳細

この例では、既存のLambda関数に Schedule イベントを追加しています。具体的には、以下の点に注目してください。

Type: Schedule：これは、Lambda関数が定期的に実行されるようにするための設定です。
Schedule: rate(10 minutes)：10分ごとに実行されるように指定しています。AWSでは、rate 式や cron 式を使用してスケジュールを定義できます。

`rate` 式の使用例

rate 式を使うことで、簡単にスケジュールを定義できます。例えば、以下のようなスケジュールが設定できます：

1時間ごとに実行したい場合:

Schedule: rate(1 hour)

1日ごとに実行したい場合:

Schedule: rate(1 day)

rate 式は短い間隔で繰り返し実行する場合に便利です。

`cron` 式の使用例

より複雑なスケジュールが必要な場合は、cron 式を使用することもできます。

cron 式は、定期的なスケジュールを指定するための強力なツールで、より細かい制御が可能です。AWSで使用される cron 式は、5つまたは6つのフィールドで構成され、それぞれのフィールドが特定の時間単位を表します。

cron(Minutes Hours Day-of-month Month Day-of-week Year)

各フィールドの意味は以下の通りです：

Minutes (0-59) : 分単位。0から59の間で指定できます。
Hours (0-23) : 時間単位。0から23の間で指定できます。
Day-of-month (1-31) : 月の日。1から31の間で指定できます。
Month (1-12) : 月。1月が1、12月が12です。
Day-of-week (1-7) : 曜日。日曜日が1、土曜日が7です（またはSUN, MONなどの省略形が使えます）。
Year (オプション) : 年単位。省略可能ですが、指定する場合は4桁で記述します。

以下に、よく使われる cron 式の例をいくつか示します。

毎日午前9時に実行

Schedule: cron(0 9 * * ? *)

説明: 毎日午前9時にLambda関数を実行します。
式の解釈: 分は0、時間は9（午前9時）、日・月・曜日はすべての値（*）、特定の年は指定しない。

毎月1日午前8時に実行

Schedule: cron(0 8 1 * ? *)

説明: 毎月1日の午前8時に実行します。
式の解釈: 毎月の1日に分0、午前8時に実行します。

平日の毎日午後1時に実行

Schedule: cron(0 13 ? * MON-FRI *)

説明: 平日（月曜〜金曜）の毎日午後1時に実行します。
式の解釈: 分0、午後1時、曜日は月曜から金曜（MON-FRI）。

週末の毎日午前10時に実行

Schedule: cron(0 10 ? * SAT,SUN *)

説明: 毎週土曜日と日曜日の午前10時に実行します。
式の解釈: 分0、午前10時、曜日は土曜日と日曜日。

毎時30分に実行

Schedule: cron(30 * * * ? *)

説明: 毎時30分にLambda関数を実行します。
式の解釈: 毎時間の30分に実行（時間は全ての値）。

cron式のワイルドカード`?` と `*` の使い分け

cron 式で使われる * と ? は、どちらもワイルドカードとして機能しますが、使用場所に違いがあります。

* : すべての値を指定するために使用します。たとえば、Minutes フィールドが * なら「毎分」を意味します。
? : Day-of-month または Day-of-week フィールドでのみ使用でき、「特定しない」という意味です。これにより、日または曜日のどちらかに特定の値を設定しない場合に使用します。

まとめ

AWS SAMを使用してLambda関数を10分ごとなどの定期的な間隔で実行する設定は非常に簡単です。rate 式や cron 式を利用して、ニーズに応じたスケジュールを柔軟に設定できます。

参考資料

AWS Lambda Layers に特定のリポジトリからライブラリをアップロードする

Sat, 21 Sep 2024 10:20:34 +0900

AWS Lambda Layers を利用することで、Lambda 関数の依存関係を外部化し、関数のデプロイパッケージをシンプルに保つことができます。本記事では、特定の Git リポジトリから取得したライブラリを AWS Lambda Layers にアップロードする手順を解説します。

前提条件

以下のツールがインストールされていることを確認してください。

Python 3.x
pip
AWS CLI
zip コマンド

Lambda Layer 用のディレクトリ構造を作成

Lambda Layer 用に、ライブラリをインストールするディレクトリを作成します。Lambda Layers は、このディレクトリ内にライブラリを配置することで、Lambda 関数がそれらを参照できるようにします。

mkdir python

python ディレクトリが Layer にアップロードされる場所です。この中にライブラリをインストールしていきます。

Git リポジトリからライブラリをインストール

次に、pip を使って特定の Git リポジトリからライブラリを python ディレクトリ内にインストールします。例えば、特定のコミットハッシュやブランチを指定してライブラリを取得したい場合、以下のようなコマンドを使います。

pip install git+https://<リポジトリのURL>@<コミットハッシュまたはブランチ名> -t python/

<リポジトリのURL> は対象ライブラリの Git リポジトリ URL を指定し、<コミットハッシュまたはブランチ名> には特定のバージョンやブランチを指定します。

不要なファイルを削除（オプション）

インストールしたライブラリには、不要なファイル（例：ドキュメントやテストファイル）が含まれることがあります。Lambda Layers のサイズを抑えるために、以下のコマンドで不要なファイルを削除します。

find python/ -name "*.dist-info" -exec rm -r {} +
find python/ -name "*.egg-info" -exec rm -r {} +

Layer の ZIP ファイルを作成

次に、python ディレクトリを ZIP ファイルに圧縮します。この ZIP ファイルが、AWS Lambda にアップロードされる Layer の内容になります。

zip -r layer.zip python

これで Layer の準備が整いました。

AWS Lambda Layer にアップロード

AWS CLI を使って、作成した ZIP ファイルを AWS Lambda Layer にアップロードします。以下のコマンドを実行します。

aws lambda publish-layer-version \
 --layer-name <Layer名> \
 --description "Lambda Layer for custom libraries" \
 --zip-file fileb://layer.zip \
 --compatible-runtimes python3.x \
 --region <リージョン名>

<Layer名> には Layer の名前を指定します。
<リージョン名> には AWS のリージョンを指定します（例：ap-northeast-1 など）。

このコマンドを実行すると、Layer の ARN（Amazon リソースネーム）が返されます。この ARN を後で Lambda 関数に設定します。

Lambda 関数に Layer を追加

Layer を作成した後、それを Lambda 関数で使用できるようにします。以下はSAMのtemplate.yaml での例です。

Globals:
 Function:
 CodeUri: src
 Runtime: python3.x
 Timeout: 30
 MemorySize: 256
 Layers:
 - arn:aws:lambda:<リージョン名>:<アカウントID>:layer:<Layer名>:<バージョン番号>
 Environment:
 Variables:
 TABLE_NAME: "example_table"

<リージョン名>, <アカウントID>, <Layer名>, <バージョン番号> は、AWS CLI で Layer を作成した際に取得した情報を入力してください。

デプロイして動作確認

Layer を Lambda 関数に追加したら、通常通りに関数をビルドしてデプロイします。

sam build
sam deploy

デプロイ後、関数が正しく Layer を参照して動作しているか確認します。

まとめ

AWS Lambda Layers を使用することで、Lambda 関数に依存関係を簡単に管理し、ライブラリの一元管理や再利用が可能になります。特定の Git リポジトリからライブラリを取得して Layer にアップロードすることで、より柔軟な開発環境を構築できるようになります。

コンテナでAWS認証情報を安全に渡す方法 – 環境変数を使った手軽なアプローチ

Sun, 08 Sep 2024 11:57:22 +0900

AWSのリソース（例：DynamoDBやSecrets Manager）を操作するアプリケーションをコンテナで実行する場合、認証情報（AWS_ACCESS_KEY_ID や AWS_SECRET_ACCESS_KEY）をコンテナ内にどのように渡すかが重要です。特に、手軽で一般的な方法として 環境変数 を利用する方法があります。この記事では、環境変数を使った認証情報の渡し方と、その際のセキュリティ上の注意点について解説します。

環境変数を使って認証情報を渡す

AWS認証情報を渡す最も簡単な方法は、環境変数を使うことです。これにより、コード内に直接認証情報をハードコードする必要がなくなります。次のようにDockerを実行する際に -e オプションを使って認証情報を渡せます。

Dockerを使った実行例

docker run \
 -e AWS_ACCESS_KEY_ID=your_access_key_id \
 -e AWS_SECRET_ACCESS_KEY=your_secret_access_key \
 -e AWS_DEFAULT_REGION=your_region \
 your_image_name

また、認証情報を .env ファイルにまとめて管理することもできます。

`.env` ファイルの例

AWS_ACCESS_KEY_ID=your_access_key_id
AWS_SECRET_ACCESS_KEY=your_secret_access_key
AWS_DEFAULT_REGION=your_region

Docker実行時にこの .env ファイルを読み込ませます。

docker run --env-file .env your_image_name

環境変数を使うことで、シンプルかつ手軽にAWS認証情報をコンテナに渡せますが、次のようなセキュリティに関する注意点があります。

セキュリティ上の注意点

環境変数は簡単で便利な方法ですが、適切に管理しなければセキュリティリスクがあります。以下は、環境変数を使う際に意識しておきたい主なポイントです。

環境変数の漏洩リスク

環境変数にAWSの認証情報を設定する場合、それが ログに出力されないように注意 する必要があります。誤って認証情報がログに残ると、悪意のある第三者がアクセスできるリスクが高まります。例えば、システムやアプリケーションのログで環境変数が出力される設定になっていないか確認しましょう。

アクセス制御の強化

コンテナをホストしているVPSへの アクセス権限を制御 することも非常に重要です。VPSにアクセスできるユーザーが多い場合、誰でも環境変数にアクセスできる可能性があります。SSHの鍵管理やファイルシステムの権限設定などを適切に行い、限られたユーザーだけがアクセスできるようにしましょう。

長期運用時の考慮

開発環境や小規模なプロジェクトでは環境変数での管理は問題ないですが、長期的に運用する場合や規模が大きくなる場合は、IAMロールやAWSの セキュリティトークンサービス (STS) などの高度な管理方法を検討するべきです。これにより、認証情報の自動ローテーションや、一時的なトークンの使用が可能になります。

改善ポイント：セキュリティを強化する方法

環境変数を使う方法自体は手軽で問題ありませんが、セキュリティを向上させるために以下の対策を取ることをおすすめします。

`.env` ファイルのバージョン管理を避ける

認証情報が含まれる .env ファイルは バージョン管理システム（例：Git）に含めない ようにしましょう。.gitignore に .env を追加し、誤ってリポジトリにプッシュされるのを防ぐことが重要です。

最小権限の原則に従う

DynamoDBやSecrets ManagerにアクセスするためのAWSユーザーには、必要最低限の権限だけを付与しましょう。例えば、DynamoDBへの読み取りと書き込みの権限、Secrets Managerへの読み取り権限など、最小限のIAMポリシー を設定します。

認証情報のローテーション

認証情報は定期的に ローテーション（更新） することを検討してください。長期間にわたり同じキーを使い続けると、万が一流出した際のリスクが増大します。AWSでは、IAMユーザーのアクセスキーのローテーションを簡単に設定できます。

まとめ

環境変数を使ってAWSの認証情報をコンテナに渡す方法は、特に小規模なプロジェクトや開発環境では 手軽で一般的 なアプローチです。ただし、セキュリティを考慮して、環境変数が漏洩しないように管理し、アクセス権限やファイル管理を適切に行うことが重要です。また、長期的な運用環境ではIAMロールや認証情報のローテーションなど、よりセキュアな方法を導入することも検討する価値があります。

安全かつ効率的なAWSリソースの操作を目指して、正しい認証情報の管理を心がけましょう。

参考資料

Amazon Cognitoの認証フロー解説

Mon, 08 Jan 2024 19:19:37 +0900

この記事は、Cognitoの認証フローの各選択肢について解説します。また、なぜ多くのアプリケーションにおいてALLOW_USER_SRP_AUTHフローだけで十分であるのか、その理由を明確に説明することを目指します。

Cognitoでの認証フローの種類

Amazon Cognitoは、セキュアなユーザー管理と認証フローを実現するための多様なオプションを提供します。これにより、開発者はアプリケーションのセキュリティ要件に応じて最適な認証戦略を選択できます。Cognitoが提供する認証フローは、以下のように分類されます。

ADMINユーザーによる認証（ALLOW_ADMIN_USER_PASSWORD_AUTH）

この認証フローは、アプリケーションのバックエンドや管理者がユーザーの代わりに認証を行う場合に使用されます。例えば、新規ユーザーのアカウントをセットアップする際や、パスワードリセットのプロセス中に管理者が介入する必要がある場合などです。このフローは強力で柔軟性がありますが、管理者の権限を使うため、セキュリティ対策を十分に施す必要があります。

カスタム認証（ALLOW_CUSTOM_AUTH）

カスタム認証フローは、開発者が独自の認証シーケンスを実装したい場合に適しています。AWS Lambdaトリガーを活用して、ワンタイムパスワードやキャプチャ、二要素認証など、標準的なユーザー名とパスワードの組み合わせ以外の方法でユーザーを認証するロジックをカスタマイズできます。これは、特定のセキュリティ要件を満たすためや、ユーザーエクスペリエンスを向上させるために有効です。

ユーザーによるパスワード認証（ALLOW_USER_PASSWORD_AUTH）

ユーザーによるパスワード認証フローは、ユーザーが直接自身のユーザー名とパスワードを提供してサインインする一般的な認証方法です。このフローはシンプルで直感的なため、ユーザーには親しみやすいですが、パスワードが直接送信されるため、SRPを使用するフローと比較してセキュリティ上のリスクが高くなります。

SRPによるユーザー認証（ALLOW_USER_SRP_AUTH）

SRPによるユーザー認証フローは、ユーザー名とパスワードを使用しながらも、パスワードをネットワーク上で送信せずに認証する方法です。これは、セキュリティを強化しつつ、ユーザーが簡単にサインインできる方法を提供します。SRPプロトコルは、数学的な計算に基づいており、パスワードの代わりに一時的な証明を交換することで認証を行います。これにより、万が一通信が盗聴されても、パスワードが漏洩するリスクが非常に低くなります。

リフレッシュトークンによる認証（ALLOW_REFRESH_TOKEN_AUTH）

ユーザーが一度サインインすると、リフレッシュトークンを使用してセッションを維持し、新しいアクセストークンやIDトークンを定期的に取得できます。これは、長期間にわたるセッション管理に適しており、ユーザーが頻繁にサインインし直す必要をなくします。

これらの認証フローは、アプリケーションのニーズに合わせて柔軟に組み合わせることができますが、多くのシナリオではALLOW_USER_SRP_AUTHフローだけでセキュリティと利便性のバランスを取ることが可能です。次のセクションでは、このフローがなぜ多くの場合で最適な選択であるかについて、さらに深堀りしていきます。

`ALLOW_USER_SRP_AUTH`の重要性

セキュアな認証フローを実現するためには、ユーザーの資格情報が安全であることを確保しなければなりません。ALLOW_USER_SRP_AUTHは、この目的を達成するための最も効果的な手段の一つです。このフローはセキュアリモートパスワード（SRP）プロトコルを使用し、パスワードを直接ネットワーク上で交換することなく、サーバーがユーザーの身元を検証することを可能にします。結果として、セキュリティが大幅に向上し、潜在的な攻撃からユーザーのパスワードを保護します。

パスワード露出のリスク回避

ALLOW_USER_PASSWORD_AUTHフローでは、ユーザーのパスワードがクライアントからサーバーへと明示的に送信されます。これは、中間者攻撃や、ネットワーク上でのデータの盗聴といったセキュリティの脅威に対して脆弱性を持ちます。対照的に、ALLOW_USER_SRP_AUTHフローでは、パスワードに代わる一時的な証明が生成され、この証明だけが交換されます。そのため、ユーザーの実際のパスワードはサーバーや他のどのネットワーク機器にも露出することはありません。

セキュリティとユーザビリティのバランス

セキュリティ対策は、ユーザビリティを損なわないように慎重に行われるべきです。ユーザーにとって複雑すぎる認証プロセスは、使い勝手を低下させる原因となります。ALLOW_USER_SRP_AUTHフローは、高いセキュリティを維持しつつも、エンドユーザーには通常のユーザー名とパスワードを入力するだけの簡単な手順を提供します。これにより、最終的なユーザーエクスペリエンスは向上し、セキュリティに関する知識がないユーザーでも安全にサービスを利用できます。

クライアントアプリケーションとの互換性

ALLOW_USER_SRP_AUTHフローは、多くのクライアントライブラリやフレームワークでサポートされており、開発者は追加の労力をかけずにこの認証フローを実装できます。AWSのSDKなどのツールは、このプロトコルを直接扱うことができるため、開発者はセキュリティの複雑さを理解しなくても、安全な認証システムを構築できます。

総合すると、ALLOW_USER_SRP_AUTHフローは、高いセキュリティ基準と優れたユーザーエクスペリエンスの両方を提供します。クライアントアプリケーションにとって、このフローはセキュアな認証プロセスを簡単に実装するための鍵となるため、多くの一般的な使用シナリオで推奨される選択肢です。多くの一般的なクライアントアプリケーションでは、ALLOW_USER_SRP_AUTH認証フローだけでユーザー認証の要件を満たすことができます。

セキュリティのベストプラクティスとして、最小限の必要権限でシステムを運用することが推奨されます。ALLOW_USER_SRP_AUTHはこの原則に沿っており、最小限の認証情報のみを使用して最大限のセキュリティを提供します。これにより、不要なセキュリティリスクを排除し、アプリケーションの攻撃面を最小限に抑えることができます。

認証フローの実装ガイド

ALLOW_USER_SRP_AUTH フローを利用した実装は、セキュリティを重視しながらもユーザーフレンドリーなアプリケーションを構築する上で重要です。このセクションでは、具体的な実装ステップとベストプラクティスを提供します。

実装の前提条件と準備

ALLOW_USER_SRP_AUTH フローを実装する前に、以下の前提条件と準備が必要です：

AWS Cognito User Poolの設定: AWS Cognito User Poolを設定し、アプリケーションクライアントIDを取得します。これは、ユーザー認証時にCognitoとの通信に使用されます。
適切なAWS SDKの選択: AWS SDK（たとえば、AWS SDK for JavaScript、Boto3 for Pythonなど）を選択し、プロジェクトに組み込みます。これらのSDKは、SRP認証フローをサポートしており、実装を容易にします。
セキュリティの構成: HTTPS通信を確保し、エンドポイントのセキュリティを強化します。これにより、データのプライバシーと完全性が保たれます。

`ALLOW_USER_SRP_AUTH`を使用した認証プロセスのコード例

以下に、JavaScriptを使用したAWS CognitoとのSRP認証プロセスの基本的なコード例を示します。

const AmazonCognitoIdentity = require('amazon-cognito-identity-js');
const AWS = require('aws-sdk');

const poolData = {
 UserPoolId: 'ap-northeast-1_Example', // Cognito User Pool ID
 ClientId: 'exampleclientid' // Cognito User Pool Client ID
};
const userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData);

const authenticationData = {
 Username: 'username',
 Password: 'password',
};
const authenticationDetails = new AmazonCognitoIdentity.AuthenticationDetails(authenticationData);

const userData = {
 Username: 'username',
 Pool: userPool
};
const cognitoUser = new AmazonCognitoIdentity.CognitoUser(userData);

cognitoUser.authenticateUser(authenticationDetails, {
 onSuccess: (session) => {
 console.log('Authentication successful!', session);
 },
 onFailure: (err) => {
 console.error('Authentication failed:', err);
 }
});

このコードは、ユーザーがユーザー名とパスワードを提供してサインインする基本的なシナリオを実装しています。成功時にはセッション情報が取得され、失敗時にはエラーが報告されます。

ベストプラクティスとデバッグのヒント

エラーハンドリングの実装: 認証プロセス中に発生する可能性のあるエラーを適切に処理し、ユーザーにわかりやすいフィードバックを提供します。
セキュリティの監査とテスト: アプリケーションのセキュリティを定期的に監査し、脆弱性テストを実施して、セキュリティの弱点を特定し対処します。
ログの活用: 認証プロセスにおける詳細なログを記録し、問題発生時の迅速なトラブルシューティングに役立てます。

ALLOW_USER_SRP_AUTH フローの実装は、セキュアなユーザー認証を提供するための基礎を形成します。このフローを適切に利用することで、ユーザーの安全を保ちながら、優れたユーザーエクスペリエンスを提供するアプリケーションを構築できます。次のセクションでは、これまでの内容をまとめ、認証フローの選択がアプリケーションに与える影響について総括します。

まとめ

この記事では、Amazon Cognitoの認証フローについて深く掘り下げ、特にALLOW_USER_SRP_AUTHフローが多くのアプリケーションにとってなぜ最適な選択肢であるかを詳細に説明しました。このフローは、セキュリティとユーザビリティのバランスを最適化し、開発者にとっても容易に実装可能な選択肢です。

認証フロー選択の意思決定プロセス

認証フローの選択は、アプリケーションのセキュリティ要件、ユーザーエクスペリエンス、開発の容易さを考慮して行うべきです。ALLOW_USER_SRP_AUTHは、これらの要素をバランス良く兼ね備えているため、一般的なアプリケーション開発において最適な選択となることが多いです。ただし、特定のケースでは他の認証フローやカスタム認証が必要になることもあります。

セキュリティを維持しながらのユーザーエクスペリエンスの最適化

ユーザーが直感的に利用できる安全な認証システムは、アプリケーションの成功において重要な要素です。ALLOW_USER_SRP_AUTHフローは、ユーザーに対して簡単かつ安全なサインインプロセスを提供し、同時にデータ保護の最高基準を満たします。

認証フローの今後の展望

セキュリティ技術の進化に伴い、認証フローの選択肢も変化していきます。Cognitoのようなサービスは継続的にアップデートされ、新しいセキュリティ機能やユーザビリティ向上のためのオプションが提供されることが予想されます。そのため、開発者は常に最新のセキュリティトレンドとベストプラクティスに注意を払い、アプリケーションのセキュリティを維持する必要があります。

認証フローの選択は、アプリケーションのセキュリティとユーザーエクスペリエンスに大きな影響を与えます。ALLOW_USER_SRP_AUTHフローは多くの場合に最適な選択ですが、プロジェクトの特定の要件に基づいて最終的な決定を行うことが重要です。この記事が、Cognitoの認証フローに関する理解を深め、適切な選択を行うためのガイドとなれば幸いです。

direnvを活用したAWSアカウントの自動切り替え方法

Sun, 10 Dec 2023 00:39:39 +0900

クラウドリソースを頻繁に使用する場合、異なるプロジェクトやクライアントごとに異なるAWSアカウントを切り替える必要があることは珍しくありません。この記事では、開発環境におけるAWSアカウントの自動切り替えを実現するためにdirenvというツールの使用方法に焦点を当てます。

direnvは、シェル環境においてディレクトリごとに環境変数を自動で切り替えることができる非常に便利なツールです。これにより、プロジェクトや作業環境に応じて、AWSプロファイルや他の環境設定を簡単に切り替えることが可能になります。この記事では、direnvの基本的なインストール方法から、AWSアカウントの切り替え設定までをステップバイステップで説明していきます。

direnvのインストールと設定

開発環境のカスタマイズにおいて、direnvは非常に重要なツールの一つです。direnvを使用すると、異なるディレクトリに移動した際に自動的に環境変数を切り替えることができ、特に複数のAWSアカウントを使い分ける際に大いに役立ちます。ここでは、direnvのインストールと基本的な設定方法について説明します。

direnvのインストール

direnvは多くのUnix系オペレーティングシステムで利用可能です。以下は、主要なOSにおけるdirenvのインストール方法です：

macOS: Homebrewを使用して簡単にインストールできます。

brew install direnv

Ubuntu/Debian: aptパッケージマネージャを利用します。

sudo apt-get install direnv

Fedora: dnfを使用してインストールします。

sudo dnf install direnv

シェルにdirenvをフックする

インストール後、direnvを使用するためにはシェルにフックする必要があります。これは、使用しているシェルの設定ファイルに特定の行を追加することで行います。以下は、いくつかの一般的なシェルの設定方法です：

Bash (.bashrc or .bash_profile) :

eval "$(direnv hook bash)"

Zsh (.zshrc) :

eval "$(direnv hook zsh)"

Fish (.config/fish/config.fish) :

eval (direnv hook fish)

これらの設定を適用した後、シェルを再起動するか、新しいターミナルウィンドウを開いて設定を有効にします。

基本的な使用法

direnvを使うための最初のステップは、環境変数や設定を含む.envrcファイルを作成することです。このファイルは、特定のディレクトリに配置され、direnvによって自動的に読み込まれます。.envrcファイルには、AWSプロファイルの設定や他の必要な環境変数を指定できます。

セキュリティ上の理由から、新しい.envrcファイルはdirenvによってデフォルトで無視されます。ファイルを承認するためには、次のコマンドを使用します：

direnv allow .

このコマンドは、.envrcファイルが安全であることをdirenvに伝え、そのディレクトリでの変更を有効にします。

direnvを使用したAWSアカウントの実践例とトラブルシューティング

direnvを活用することで、AWSアカウントの切り替えをスムーズに行うことができます。このセクションでは、実際の使用例と一般的な問題の解決方法について説明します。

実際の使用例

想定するシナリオは、異なるAWSアカウントを使用する複数のプロジェクトに取り組んでいる状況です。それぞれのプロジェクトディレクトリに.envrcファイルを作成し、適切なAWSプロファイル名を設定します。

例えば、プロジェクトAとプロジェクトBがあり、それぞれ異なるAWSアカウントを使用するとします。プロジェクトAのディレクトリの.envrcには以下のように書きます：

export AWS_PROFILE=projectA-profile

同様に、プロジェクトBの.envrcには：

export AWS_PROFILE=projectB-profile

これにより、各プロジェクトディレクトリに移動するだけで、direnvが自動的にAWSプロファイルを適切なものに切り替えます。

トラブルシューティングのヒント

問題：.envrcが読み込まれない
解決策：direnv allowコマンドを使用して、.envrcファイルを承認します。また、シェルの設定ファイル（例：.bashrc、.zshrc、.config/fish/config.fish）でdirenvが正しくフックされていることを確認してください。
問題：AWSプロファイルが切り替わらない
解決策：AWS_PROFILE変数が正しく設定されているか確認します。また、AWS CLIがインストールされていること、および~/.aws/credentialsと~/.aws/configに正しい認証情報が設定されていることを確認してください。
問題：セキュリティ上の懸念
解決策：.envrcファイルに機密情報（例：アクセスキー、シークレットキー）を直接書かないようにします。代わりに、プロファイル名のみを使用し、認証情報は~/.aws/credentialsに安全に保存します。

まとめ

direnvを使用したAWSプロファイルの自動切り替えの方法について詳しく説明しました。この手法は、複数のAWSアカウントを扱う際の生産性を高め、エラーの可能性を減らすのに役立ちます。

主なポイントの再確認:
direnvをインストールし、シェルにフックする。
.envrcファイルを使用して、ディレクトリごとに異なるAWSプロファイルを設定する。
direnv allowを実行して、新しい.envrcファイルを承認する。
応用例: この手法はAWSプロファイルに限らず、他の環境変数や設定（例えば、データベース接続設定やAPIキー）の管理にも応用できます。
セキュリティ上の注意: .envrcファイルに機密情報を直接記述することは避け、安全な方法で認証情報を管理することが重要です。

参考記事

direnv公式ドキュメント: direnv公式ウェブサイトには、インストール方法、使用方法、さまざまな設定オプションに関する詳細情報があります。
AWS CLI公式ドキュメント: AWS CLIの使用方法に関する詳細情報は、AWS公式ドキュメントで提供されています。
関連ブログ記事やフォーラム: コミュニティの経験やベストプラクティスを共有する多くのブログ記事やフォーラムが存在します。これらは、具体的なシナリオや高度な使用例を理解するのに役立つかもしれません。

DynamoDBでデータを自動削除：TTL設定のステップバイステップ

Tue, 28 Nov 2023 00:06:37 +0900

現代のアプリケーション開発において、迅速かつ効率的なデータ管理は不可欠です。Amazon DynamoDBは、そのようなニーズを満たすために開発されたNoSQLデータベースサービスです。DynamoDBは、高い可用性と拡張性を提供し、大量のデータを素早く処理する能力があります。これにより、開発者はアプリケーションのパフォーマンスを最適化し、よりスムーズなユーザー体験を提供することができます。

この記事では、データが自動的に削除されるべき時点を定義する機能であるTTL（Time To Live）を利用し、DynamoDBで有効期限のあるデータを効率的に扱う方法について掘り下げていきます。

TTLとは何か？

「Time To Live」（TTL）は、データがデータベース内で生存する時間の長さを指します。具体的には、データ項目に設定された特定の時間が経過すると、そのデータは自動的にデータベースから削除されます。この時間は、通常、UNIXタイムスタンプ形式で指定されます。

TTLは、DynamoDBのようなNoSQLデータベース管理システムで特に有用です。これにより、データのライフサイクルを自動的に管理し、データベースのサイズとコストを効率的に管理することが可能になります。

TTL機能を活用することで、以下のような多くの利点があります。

自動的なデータのクリーンアップ: DynamoDBでは、TTLを設定することで、期限切れのデータを自動的に削除し、データの整合性を保つことができます。
ストレージコストの削減: 不要なデータを自動的に削除することで、ストレージの使用量を減らし、コストを節約できます。
セキュリティリスクの軽減: 古いデータや期限切れのデータはセキュリティリスクを引き起こす可能性があります。これらを自動的に削除することで、リスクを減少させることができます。
システムパフォーマンスの最適化: 不要なデータを削除することで、データベースの応答性とパフォーマンスが向上します。
コンプライアンスのサポート: 特定の業界規制では、データの保持期間に厳格な制限がある場合があります。TTLを用いることで、これらの規制要件を自動的に満たすことが可能になります。

DynamoDBにおけるTTLの利用方法

DynamoDBでTTLを設定するプロセスは、シンプルかつ直感的です。主なステップは以下の通りです。

TTL属性の選択:

DynamoDBのテーブルには、TTLのための特定の属性（列）が必要です。これは、各アイテムがどのタイミングで削除されるべきかを示すUNIXエポックタイムスタンプを格納します。

AWSコンソールでのTTL設定:

AWSマネジメントコンソールを使用して、TTLを有効にします。テーブルを選択し、TTL属性を指定して、TTLを有効化するオプションを選びます。

TTL値の設定:

新しいアイテムをテーブルに追加する際、または既存のアイテムを更新する際に、TTL属性にUNIXタイムスタンプを設定します。このタイムスタンプは、アイテムが自動的に削除されるべき時刻を表します。

TTL属性の設定は、アイテムの追加や更新時に行われます。例えば、セッションデータや一時的なトークンなど、一定期間後に自動的に削除したいデータに対して効果的です。

例: セッションが1時間後に期限切れになるように設定する場合、TTL属性には現在のUNIXタイムスタンプに3600秒（1時間）を加えた値を設定します。

TTLの実践的な使用例

DynamoDBのTTL機能は、多くの実用的なシナリオで有効です。ここでは、特に一般的な使用例としてセッション管理とトークン管理を取り上げます。

セッション管理

ウェブアプリケーションやモバイルアプリケーションでは、ユーザーのセッション情報を管理する必要があります。セッションは、特定の期間の活動後に期限切れになるべきです。DynamoDBのTTLを利用して、期限切れのセッションデータを自動的に削除することで、セキュリティを強化し、データの整理を効率的に行うことができます。

例: ユーザーがログインすると、セッションデータがDynamoDBに保存され、TTL属性には現在時刻から数時間後のタイムスタンプが設定されます。この期間が経過すると、セッションデータは自動的に削除されます。

トークン管理

APIトークンや一時的な認証コードなど、一定期間後に無効化されるべきトークンも、TTLを利用して管理することができます。これにより、期限切れのトークンがシステム内に残らないようにし、セキュリティを向上させることが可能です。

例: ユーザーがパスワードリセットを要求すると、一時的な認証コードが生成され、TTL属性には短い期限（例えば30分後）が設定されます。この期限が経過すると、認証コードは自動的に削除されます。

期限切れデータの自動削除

TTLは、特に期限が設定されたデータ（例えば、プロモーション情報やイベント情報）に有効です。イベントが終了したり、プロモーションが終了した後に自動的にデータを削除することで、データの整合性を保ち、不要なデータの蓄積を防ぐことができます。

例: 特定のイベントに関連するデータには、イベント終了日のタイムスタンプがTTL属性として設定されます。イベント終了後、これらのデータは自動的に削除されます。

TTLの使用時に考慮すべき点

DynamoDBでのTTL機能の使用は、多くの利点を提供しますが、その実装と管理には注意が必要です。以下に、TTLを使用する際に考慮すべきいくつかの重要な点を挙げます。

適切なタイムスタンプの使用: TTL属性に設定されるUNIXタイムスタンプは正確でなければなりません。誤ったタイムスタンプは、データの早すぎる削除や予定された削除の遅延を引き起こす可能性があります。
非同期的な削除: TTLによる削除は非同期で行われるため、設定された時刻を過ぎた直後にアイテムが削除されるわけではありません。この遅延は、アプリケーションのロジックに影響を与える可能性があります。
パフォーマンスへの影響: 大量のアイテムが同時に削除される場合、一時的にテーブルのパフォーマンスに影響を与える可能性があります。
コスト削減: 不要なデータを削除することでストレージコストを削減できますが、TTL設定自体の管理にもリソースが必要です。

TTLの最適な活用法

DynamoDBのTTL機能を最大限に活用するためには、戦略的なアプローチが必要です。以下に、TTLを効果的に使用するためのベストプラクティスを紹介します。

データの種類と重要性の評価: データの種類によって、その保持期間は異なります。例えば、セッションデータや一時的なトークンは短期間で削除するのが適していますが、顧客情報や取引記録は長期間保持する必要があるかもしれません。
ビジネス要件と規制の遵守: ビジネスの要件と規制上の要件に基づいてTTLポリシーを設定します。これにより、データの整合性とコンプライアンスを確保できます。
複雑なロジックの適用: すべてのデータがTTLによる単純な削除ルールに適合しない場合、バッチ処理を利用してより複雑な削除ロジックを適用することができます。
非同期処理の活用: バッチ処理を非同期で実行し、データベースのパフォーマンスに与える影響を最小限に抑えることが重要です。
パフォーマンスへの影響のモニタリング: TTLによる削除操作がテーブルのパフォーマンスに与える影響を定期的にモニタリングし、必要に応じて調整します。
負荷の分散: 削除操作がテーブルに集中することを避けるために、負荷を分散させる戦略を検討します。これには、データの分割や異なるテーブルへの配置が含まれます。

まとめ

DynamoDBのTTL機能は、データのライフサイクル管理を自動化し、ストレージコストを削減し、セキュリティを強化するための強力なツールです。適切に設定され、効果的に管理されたTTLは、データベースの整理と最適化に大きな貢献をします。しかし、その利用には、ビジネスの要件、データの種類、およびセキュリティとコンプライアンスの要件を考慮する必要があります。戦略的なアプローチをとることで、TTLはDynamoDBを使用するアプリケーションの効率を大幅に向上させることができます。

AWS AppSync + DynamoDB（複合キーテーブル）の自動生成されたリゾルバによるアイテム削除が失敗した時の対応

Fri, 24 Nov 2023 00:02:18 +0900

端的に言うと、AppSync + DynamoDBで自動生成されたリゾルバを使ってデータ削除しようとしたら、次のエラーが出た時の対応です。

"The variables input contains a field that is not defined for input object type 'DeleteHogeHoge' "

結論的には、DynamoDBのソートキーが無視されたリゾルバになっていました。

はじめに

AWS Amplifyは、Webおよびモバイルアプリケーションの開発を迅速化するためのツールセットです。Amplifyを使用すると、認証、データストレージ、APIなどの機能を簡単に実装できます。特に、GraphQL APIの作成とデプロイに関しては、AWS AppSyncが強力な支援を提供します。

AWS AppSyncは、開発者が効率的にGraphQL APIを構築し、管理できるように設計されたフルマネージドサービスです。AppSyncは、データのリアルタイム同期やオフラインデータアクセスなど、複雑なデータ操作を簡単に処理できることで知られています。

しかし、これらのツールは自動化されたプロセスに頼っているため、特定のデータモデルやユースケースに対する細かいカスタマイズが必要な場合、問題が生じることがあります。私が直面した問題は、AWS Amplifyが提供する自動コード生成機能と、DynamoDBの複合プライマリキーを使用したテーブル設計の間の整合性に関するものでした。

AppSyncとDynamoDBの基本

AWS AppSyncとDynamoDBは、AWSエコシステムの中で重要な位置を占めています。これらのサービスを理解することは、モダンなクラウドベースのアプリケーション開発において不可欠です。

AWS AppSync

AWS AppSyncは、データ駆動型のアプリケーションにおいてリアルタイムのデータ同期と通信を容易にするマネージドGraphQLサービスです。AppSyncを使用すると、フロントエンド開発者はバックエンドの複雑さを意識せずに、必要なデータを簡単に取得、変更、購読することができます。

GraphQLスキーマを定義することで、AppSyncはそのスキーマに基づいてAPIを生成します。例えば、本のデータモデルに対する簡単なGraphQLスキーマは次のようになります：

type Book {
 book_id: ID!
 title: String
 author: String
 ...
}

type Query {
 getBook(book_id: ID!): Book
 listBooks: [Book]
}

type Mutation {
 addBook(book: BookInput): Book
 deleteBook(book_id: ID!): Book
}

DynamoDB

DynamoDBは、高速かつ柔軟なNoSQLデータベースサービスで、キー-バリューおよびドキュメントデータモデルをサポートしています。DynamoDBは、パーティションキーとソートキーを組み合わせた複合プライマリキーを使ってデータをユニークに識別します。

例えば、本の情報を格納するDynamoDBテーブルの設計は次のようになります：

{
 "TableName": "Books",
 "KeySchema": [
 { "AttributeName": "user_id", "KeyType": "HASH" }, // パーティションキー
 { "AttributeName": "book_id", "KeyType": "RANGE" } // ソートキー
 ],
 ...
}

ここでの問題は、AppSyncが自動的に生成するリゾルバがこの複合キー構造を正しく扱っていないことでした。次のセクションでは、この問題がどのように発生し、どのようにしてそれに気づいたのかを詳しく説明します。

問題の発生

プロジェクトの進行中に、AWS AppSyncとDynamoDBを使用してデータの保存と取得を行っていましたが、特定の操作で予期せぬ問題に直面しました。

自動生成されたリゾルバの問題

AWS AppSyncは、GraphQLスキーマに基づいてAPIを生成し、さらにDynamoDBテーブルとの間でデータを操作するためのリゾルバを自動生成します。私のプロジェクトでは、user_id と book_id を複合キーとするDynamoDBテーブルを用意していました。通常、このようなテーブル設計では、両方のキーを使用してデータを操作することが期待されます。

しかし、AppSyncが生成した削除操作のリゾルバは、book_id を無視し、user_id のみを使用してデータを削除しようとしていました。このため、期待通りにデータを削除できず、エラーが発生していました。

コードによる問題の特定

この問題に気づいたのは、削除操作を試行した際にエラーが発生し、データが削除されなかったことからでした。エラーメッセージを解析した結果、DynamoDBからのレスポンスが「提供されたキーエレメントがスキーマと一致しない」という内容であることを突き止めました。

AWS AppSyncのコンソールにアクセスし、リゾルバのコードを確認したところ、自動生成されたリゾルバが以下のようになっていることがわかりました：

/
 * Deletes an item with user_Id `ctx.args.input.user_Id` from the DynamoDB table.
 * @param {import('@aws-appsync/utils').Context<{input: {user_id: unknown;}}>} ctx the context
 * @returns {import('@aws-appsync/utils').DynamoDBDeleteItemRequest} the request
 */
export function request(ctx) {
 const { user_id } = ctx.args.input;
 return {
 operation: 'DeleteItem',
 key: util.dynamodb.toMapValues({ user_id }),
 }
}

このリゾルバは、book_id を考慮せずに user_id のみを使用しているため、複合キーを持つテーブルで適切な削除操作を行うことができませんでした。

次のセクションでは、この問題をどのように分析し、解決策をどのように導き出したかを詳しく説明します。

もちろんです。以下は、「問題の解析と解決策」セクションの詳細な文章です。

問題の解析と解決策

問題の根本的な原因

エラーメッセージの分析から、問題の根本原因がAppSyncの自動生成リゾルバにあることが明らかになりました。AppSyncは、スキーマ定義に基づいて削除操作のリゾルバを生成する際、DynamoDBテーブルの複合キー（user_id と book_id）を正しく扱っていませんでした。リゾルバは user_id のみを使用して削除を試み、book_id を完全に無視していました。

リゾルバの手動修正

この問題に対処するためには、リゾルバを手動で修正し、DynamoDBのテーブルキー構造に合わせる必要がありました。具体的には、リゾルバのリクエストマッピングテンプレートを次のように更新しました：

/
 * Deletes an item with user_Id `ctx.args.input.user_Id` from the DynamoDB table.
 * @param {import('@aws-appsync/utils').Context<{input: {user_id: unknown, book_id: unknown;}}>} ctx the context
 * @returns {import('@aws-appsync/utils').DynamoDBDeleteItemRequest} the request
 */
export function request(ctx) {
 const { user_id, book_id } = ctx.args.input;
 return {
 operation: 'DeleteItem',
 key: util.dynamodb.toMapValues({ user_id, book_id }),
 }
}

この修正により、リゾルバは user_id と book_id の両方を使用して削除操作を実行するようになり、DynamoDBのテーブルキー構造に適切に合わせられました。

まとめ

この記事を通じて、AWS AmplifyとAppSyncを利用する際に直面する可能性のある一つの典型的な問題とその解決策を共有しました。自動生成されたリゾルバがDynamoDBの複合キー構造を正しく扱わない場合の対処法と、その過程で得られた学びを詳しく説明しました。

AWS AppSyncの自動生成リゾルバは、複雑なキースキーマを持つDynamoDBテーブルに対して常に適切ではない。
データモデルや要件に応じてリゾルバを手動で検証し、調整することが重要。
基礎となるAWSサービスの動作と制約を理解することが、問題解決に不可欠。

AWS AmplifyとAppSyncは強力なツールですが、それらを最大限に活用するには、サービスの内部動作に対する深い理解が必要です。

参考

API (GraphQL) - JavaScript - AWS Amplify Documentation

DynamoDBで小数点(float)を扱う: PythonでFloatをDecimalに変換する

Wed, 15 Nov 2023 18:51:17 +0900

DynamoDBで小数点を扱う時の注意

Amazon DynamoDBは、高速で柔軟性があり、スケーラブルなNoSQLデータベースサービスとして広く利用されています。このサービスは、大規模なデータセットを迅速に処理し、簡単にアクセスする能力で知られており、ウェブスケールアプリケーションからビッグデータ分析まで、幅広い用途に適しています。しかし、DynamoDBを最大限に活用するには、そのデータ型の特性を理解し、適切に扱う必要があります。

特に注意が必要なのは、DynamoDBにおける数値データの扱いです。DynamoDBは数値をDecimal型として保存し、この形式は浮動小数点数（float型）とは異なる特性を持っています。なぜこれが重要なのでしょうか？一般的なプログラミング言語では、数値はしばしばfloat型で扱われますが、この型は精度の問題を引き起こす可能性があります。一方、Decimal型は固定小数点数を用いることで、これらの精度の問題を回避します。この特性は、金融データの処理や、正確な数値計算が求められる場合に特に重要です。

このため、DynamoDBにデータを保存する際には、float値をDecimal型に変換することが不可欠です。この小さな変更が、データの整合性を維持し、予期せぬエラーや計算の不正確さを防ぐ鍵となります。本記事では、この変換プロセスを簡単に行うためのPython関数を紹介し、その実装方法と利用例について詳しく説明します。

解決策の提示

DynamoDBでのfloat値の扱いに関する問題を解決するための鍵は、適切なデータ変換です。具体的には、float型の数値をDecimal型に変換する関数を作成し、DynamoDBに書き込むデータをこの関数で処理します。このアプローチにより、DynamoDBのデータ型の制約に適合しつつ、データの精度を維持することができます。

Decimal変換関数

この変換を行うためのPython関数は、以下のように定義できます：

from decimal import Decimal

def convert_floats_to_decimals(item):
 """
 Recursively converts all float values in a dictionary or list to Decimals,
 which is required for DynamoDB compatibility.
 """
 if isinstance(item, dict):
 return {key: convert_floats_to_decimals(value) for key, value in item.items()}
 elif isinstance(item, list):
 return [convert_floats_to_decimals(element) for element in item]
 elif isinstance(item, float):
 return Decimal(str(item))
 else:
 return item

この関数は、辞書やリストに含まれるfloat値を再帰的に探索し、それらをDecimal型に変換します。PythonのDecimalクラスは、float型の数値を正確な固定小数点数として表現するため、DynamoDBとの互換性が確保されます。

関数の動作原理

この関数は、入力されたデータ構造を再帰的に探索します。辞書の場合、すべてのキーと値のペアに対してこの関数を適用し、リストの場合はリスト内の各要素に対して適用します。float型の値が見つかると、それをDecimal型に変換し、他のデータ型はそのまま返します。

この方法により、辞書やリスト内の任意の深さにあるfloat値を確実にDecimalに変換することができます。これは特に、ネストされたデータ構造を扱う際に有効です。

関数の使用例

前のセクションで紹介したconvert_floats_to_decimals関数は、実際のデータ変換プロセスでどのように役立つのでしょうか？ここでは、具体的な使用例を通して、この関数の実用性を示します。

使用例：辞書の変換

考えられる一般的なシナリオとして、辞書にfloat値が含まれる場合があります。例えば、次のような辞書があるとします：

example_dict = {
 "key1": 1.23,
 "key2": [3.45, 6.78],
 "key3": {"nested_key": 9.01}
}

この辞書をDynamoDBに保存する前に、float値をDecimalに変換する必要があります。convert_floats_to_decimals関数を使用すると、以下のように変換できます：

converted_dict = convert_floats_to_decimals(example_dict)

結果は次の通りです：

{
 'key1': Decimal('1.23'),
 'key2': [Decimal('3.45'), Decimal('6.78')],
 'key3': {'nested_key': Decimal('9.01')}
}

この変換により、元の辞書内のすべてのfloat値がDecimal型に変更され、DynamoDBへの書き込みが可能になります。

使用例：ネストされたリストと辞書

この関数は、より複雑なネストされたデータ構造にも対応しています。例えば、辞書の中にリストがあり、そのリストの中にさらに辞書があるような構造に対しても、すべてのfloat値を適切にDecimalに変換します。

complex_data = {
 "key1": [{"inner_key1": 2.34, "inner_key2": 5.67}, 3.21],
 "key2": {"nested_list": [7.89, {"deep_key": 4.56}]}
}

converted_complex_data = convert_floats_to_decimals(complex_data)

この関数を使用することで、どのように深くネストされたデータ構造であっても、float値を正確にDecimalに変換することが可能です。

ベストプラクティスと考慮事項

convert_floats_to_decimals関数を使用する際には、いくつかのベストプラクティスと考慮事項を心に留めておくことが重要です。

データ型の確認

入力データの確認： 関数に渡す前に、入力データが辞書やリスト形式であることを確認してください。これは関数がこれらのデータ型のみを対象としているためです。
他のデータ型との互換性： 関数はfloat型以外のデータ型をそのまま返しますが、DynamoDBに保存する前に他のデータ型に対する検証も検討してください。

性能の考慮

大規模データの取り扱い： 非常に大きなデータセットや深くネストされたデータ構造を扱う際は、性能への影響を考慮する必要があります。関数の再帰的な性質は、特に大規模なデータ構造で処理時間が長くなる可能性があります。

エラーハンドリング

エラーハンドリングの実装： 関数を組み込む際には、不適切なデータ型や予期しない入力に対するエラーハンドリングを考慮することが重要です。これにより、データ変換プロセスの堅牢性が向上します。

DynamoDBとの統合

DynamoDBとの連携： この関数はDynamoDBへのデータ書き込みの一部として組み込むことが最も効果的です。データをDynamoDBに保存する前の最終段階でこの関数を使用することで、データの整合性を保つことができます。

まとめ

この記事では、DynamoDBでfloat値を効率的かつ正確に扱うための方法を紹介しました。Pythonでのconvert_floats_to_decimals関数の実装と使用方法を通じて、DynamoDBのデータ型の制約に対応しつつ、数値データの精度を維持する方法を学びました。適切なデータ変換プロセスを実施することで、アプリケーションのデータ整合性を向上させ、DynamoDBの利用を最大化することができます。

了解しました。最後に「参考文献とリソース」のセクションを含めて、記事を締めくくります。

参考文献とリソース

この記事で紹介した内容の理解を深めるために、以下のリソースが役立つでしょう：

Amazon DynamoDB 公式ドキュメント： DynamoDBの基本的な概念、データ型、およびベストプラクティスに関する公式ガイドは、このデータベースサービスを理解するのに最適な出発点です。
Amazon DynamoDB Developer Guide
Pythonのdecimalモジュール： PythonのDecimalクラスに関する公式ドキュメントを参照して、数値の精度と表現についての理解を深めることができます。
Python decimal Documentation

これらのリソースは、DynamoDBの利用とデータ変換のスキルを向上させるための貴重な情報源です。この記事で紹介した関数と併用することで、DynamoDBのポテンシャルを最大限に活用し、アプリケーションのデータ処理能力を高めることができます。

この記事では、DynamoDBでのfloat値の扱いとその解決策に焦点を当て、具体的なPython関数の実装と使用方法を通じて、この問題に対処する方法を提供しました。これらの知識を活用して、自身のプロジェクトでより効果的にDynamoDBを使用してください。

AWS Systems Manager パラメータストアから Python で値を取得する方法

Sun, 29 Oct 2023 02:49:11 +0900

AWS Systems Manager のパラメータストアは、データベースの接続文字列やパスワードなどの設定情報をセキュアに保存して管理するためのサービスです。この記事では、ローカルの Python スクリプトを使ってパラメータストアに保存されている値を取得する方法を説明します。

1. 必要なライブラリをインストール

まず、AWS SDK for Python (Boto3) をインストールします。これをインストールするために、以下のコマンドを実行します。

pip install boto3

2. Python スクリプトを作成

以下のサンプルコードを使用して、パラメータストアから任意のパラメータ名で保存されている値を取得します。

import boto3

def get_parameter_from_store(param_name):
 # Boto3 クライアントを初期化
 ssm = boto3.client('ssm')

 # パラメータを取得
 response = ssm.get_parameter(
 Name=param_name,
 WithDecryption=True # 暗号化されている場合はデコード
 )

 # パラメータの値を返す
 return response['Parameter']['Value']

if __name__ == "__main__":
 param_name = input("Enter the parameter name: ")
 param_value = get_parameter_from_store(param_name)
 print(f"Value of '{param_name}': {param_value}")

3. AWS 認証情報を設定

ローカルマシンに ~/.aws/credentials というファイルを作成し、以下の内容を追加します。これにより、Boto3 は自動的にこのファイルの認証情報を使用します。

[default]
aws_access_key_id = YOUR_ACCESS_KEY_ID
aws_secret_access_key = YOUR_SECRET_ACCESS_KEY

注意: 実際のアクセスキーとシークレットアクセスキーに置き換えてください。

4. Python スクリプトを実行

上記のスクリプトを保存し、ローカルマシンで実行します。スクリプトを実行すると、取得したいパラメータ名を入力するプロンプトが表示されるので、対応する名前を入力してください。これにより、指定したパラメータの値がコンソールに表示されます。

これで、AWS Systems Manager のパラメータストアからローカルの Python スクリプトで値を読み取る方法についての概要を把握することができました。

AWS CloudWatch Logs Insightsで特定のイベントが起きた回数をbin()関数で時間ごとにカウントする

Mon, 25 Sep 2023 18:10:47 +0900

はじめに

AWS CloudWatch Logs Insightsは、ログデータを効率的に探索・分析するためのさまざまな機能と能力を提供しています。その中でも特に強力な関数の一つがbin()で、これによって時間ベースの区間にレコードを集約することが可能です。この記事では、bin()関数が特に有用なシナリオについて探ります。

`bin()`とは？

bin()関数は、レコードを時間間隔に基づいてグループ化します。これにより、ログデータを分、時間、日といった期間で分析することができます。構文は非常に簡単です：

bin(時間間隔)

この時間間隔は、秒（s）、分（m）、時間（h）などの複数の単位で表現できます。

特定のイベントの時間別カウント

特定のイベントが時間にわたって何回発生したかをカウントしたい場合、bin()をstats count(*)と組み合わせて使用することができます。

fields @timestamp, @message
| filter service = "何らかのサービス" and eventType = "何らかのイベント"
| stats count(*) by bin(10m)
| sort @timestamp desc

ユーザー活動の分析

時間区間でユーザー活動を分析したい場合、bin()は効率的にデータをグループ化するのに役立ちます。

fields @timestamp, @message, message.payload.user_id
| filter service = "何らかのサービス" and message.payload.user_id = "特定のユーザーID"
| stats count(*) as userCount by bin(10m)
| sort @timestamp desc

時間区間による比較

bin()を使用することで、異なる時間区間でのメトリクスを簡単に比較することができます。

fields @timestamp, @message, latency
| filter service = "何らかのサービス"
| stats avg(latency) by bin(1h)

複数の`bin()`の組み合わせ

単一のクエリ内で複数のbin()を使用することで、複雑な時間ベースの集約を作成することが可能です。

fields @timestamp, @message, message.payload.user_id, eventType
| filter service = "何らかのサービス"
| stats count(*) by bin(10m), eventType

まとめ

bin()関数は、AWS CloudWatch Logs Insightsで時間ベースのログデータを集約・分析する際の強力なツールです。この関数を効果的に使用する方法を理解することで、アプリケーションの動作やパフォーマンスについてより深い洞察を得ることができます。特定のイベントをカウントしたい、ユーザー活動を分析したい、あるいはその他の時間ベースのログ分析を行いたい場合にも、bin()はそれを簡単に実現する方法を提供しています。

Amazon Cognito: ID Tokenの取得するPythonコード

Sun, 17 Sep 2023 12:36:02 +0900

テストの時とかで、CognitoのID Tokenをさらっとほしいことがある。なので、ChatGPT-4にお願いした備忘録。

はじめに

Amazon Cognitoは、ユーザー認証やアイデンティティの提供に関する多くの便利な機能を提供しています。この記事では、管理者権限を使用して特定のユーザのID Tokenを取得する方法について説明します。

前提条件

AWSのアカウント
Python環境
Boto3ライブラリのインストール
Cognito User PoolとApp Clientの作成済み

ステップバイステップガイド

1. Boto3のインストール

Boto3はAWSの公式SDKです。以下のコマンドでインストールできます。

pip install boto3

Pythonコードの準備

以下は、指定されたユーザプールとクライアントアプリで指定されたユーザのID Tokenを取得するPythonコードです。

import boto3
def get_id_token(user_pool_id, client_id, username, password):
 client = boto3.client('cognito-idp')
 response = client.admin_initiate_auth(
 UserPoolId=user_pool_id,
 ClientId=client_id,
 AuthFlow='ADMIN_NO_SRP_AUTH',
 AuthParameters={
 'USERNAME': username,
 'PASSWORD': password
 }
 )
 # ID Tokenを取得
 id_token = response['AuthenticationResult']['IdToken']
 return id_token

# パラメータ設定
USER_POOL_ID = 'your-user-pool-id'
CLIENT_ID = 'your-client-id'
USERNAME = 'target-username'
PASSWORD = 'target-user-password' # 管理者として取得する場合、正確なパスワードを知っている必要があります
token = get_id_token(USER_POOL_ID, CLIENT_ID, USERNAME, PASSWORD)
print(token)

注意点

このアプローチにはいくつか注意点があります:

管理者の権限を必要とします。
ユーザーのパスワードを直接知っている必要があります。
セキュリティ対策やIAMポリシーの適切な設定も考慮する必要があります。

まとめ

Amazon Cognitoを使用してID Tokenを取得する方法は複数ありますが、管理者として特定のユーザーのID Tokenを取得する際のアプローチについて解説しました。セキュリティの観点から注意深く使用することを忘れないでください。

寸評

珍しく何事もなくうまくいった。

AWS Lambda Powertoolsのタイムスタンプを読みやすいローカル時刻に変換するJavaScriptのスニペット

Wed, 09 Aug 2023 13:22:37 +0900

AWS Lambda PowertoolsはLambda関数使い必携の便利ユーティリティなわけだが、なぜかこれのloggerで自動的に記録されるタイムスタンプの形式が、2021-05-03 10:20:19, 650+0200のようなよくわからん形になっている。カンマ……？（参考記事: AWS Lambda Powertools Python入門第 3 回 ~Logger Utility - 変化を求めるデベロッパーを応援するウェブマガジン | AWS）

まぁちょっと直せばDate型にできそうだなと思ったので、ChatGPT-4にスニペット書いてもらってついでに記事にした。

イントロ

AWS Lambda Powertoolsは非常に便利なユーティリティで、AWS Lambdaの開発を容易にするための数々の機能を提供しています。しかし、時にはそのロギングに使用される日付フォーマットが少しわかりづらくなることがあります。

例: 2023-08-09 03:58:10,866+0000

この記事では、この特定のタイムスタンプの形式をJavaScriptでローカル時刻に変換する方法について説明します。

タイムスタンプの解析

このタイムスタンプの形式は標準的なものではないため、少し工夫して変換する必要があります。以下はその手順です。

手順

カンマをドットに置換する:タイムスタンプにはカンマが使用されているため、最初にドットに置換します。
Dateオブジェクトの作成:カンマをドットに置換した後、JavaScriptのDateオブジェクトを作成します。
ローカル時刻に変換する:Dateオブジェクトをローカル時刻に変換します。

コード例

以下は、このタイムスタンプをローカル時刻に変換するコード例です。

const timestamp = "2023-08-09 03:58:10,866+0200";
const adjustedTimestamp = timestamp.replace(',', '.');
const date = new Date(adjustedTimestamp);
const localDate = date.toLocaleString();

console.log(localDate);

このコードは、与えられた日付と時刻をJavaScriptのDateオブジェクトに変換し、その後toLocaleStringメソッドを使用してローカル時刻に変換します。

ただし、この例のタイムスタンプの形式が標準的でないため、一部のブラウザではうまく動作しない可能性があります。もし問題がある場合は、以下のようにタイムスタンプを手動で解析することもできます。

const timestamp = "2021-05-03 10:20:19,650+0200";
const parts = timestamp.split(/[- :+,]/);

// オフセットの部分を取得して、分単位に変換
const offset = parseInt(parts[7], 10) / 100 * 60;

// Date.UTCでUTC時刻を計算し、オフセットを考慮
const date = new Date(Date.UTC(parts[0], parts[1] - 1, parts[2], parts[3], parts[4], parts[5], parts[6]) - offset * 60 * 1000);
const localDate = date.toLocaleString();

console.log(localDate);

このコードは、与えられた文字列を解析して日付、時刻、およびタイムゾーンの各部分を取得し、それらを使用してDateオブジェクトを構築します。そして、このDateオブジェクトをローカル時刻に変換します。

まとめ

標準的な日付フォーマットとは異なるものに対処する際には、このように少し手間がかかることがあります。もし、このような変換がプロジェクトで頻繁に必要な場合、共通のユーティリティ関数として切り出して再利用すると良いかもしれません。

また、日付操作のライブラリ（例：moment.js、date-fnsなど）を使用することも考慮に入れると良いかもしれません。これらのライブラリは、様々なフォーマットの日付を扱う際に非常に便利です。

このユーティリティを使用して開発する際に役立つことを願っています。

寸評

こんなスニペットでも記事にしておくと案外役に立つものなので、備忘録。オフセットがある場合とか地味にしんどいわ（普通UTCかローカルタイムのどっちかだと思うけど）。ただ簡単な記事だが、オフセットの計算で一度ChatGPTが謎の暴走していたりする……。絵文字使って言い訳しててなんか笑った。

AWS LambdaとCloudWatch Logs Insightsを組み合わせて効率的にログ分析

Thu, 03 Aug 2023 17:10:03 +0900

はじめに

AWS LambdaとCloudWatch Logs Insightsを連携させることで、自動化された効率的なログ分析が可能になります。この記事では、その設定方法からテスト実行までの手順を詳しく説明します。

以下は、Lambda関数を使用してCloudWatch Logs Insightsからログを取得する一連の手順です。

IAMロールの作成

Lambda関数に適切な権限を持たせるために、関数に割り当てるIAMロールにCloudWatch Logs Insightsへのアクセス権限を付与する必要があります。この権限は、logs:StartQuery, logs:GetQueryResults, logs:StopQuery などが含まれます。

AWS Webコンソールを使用してLambda関数に適切なIAMロールを作成するには、以下の手順を実施します。

AWS Management Consoleにログインし、IAM サービスに移動します。
左側のメニューからロールを選択し、「ロールの作成」ボタンをクリックします。
AWSサービスを選択し、Lambdaをクリックして、「次のステップ: アクセス権限」ボタンをクリックします。
「ポリシーの作成」ボタンをクリックして新しいポリシーを作成します。
JSONタブを選択し、以下のポリシーを入力します。

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "VisualEditor0",
 "Effect": "Allow",
 "Action": [
 "logs:StartQuery",
 "logs:GetQueryResults",
 "logs:StopQuery"
 ],
 "Resource": "*"
 }
 ]
}

上記のポリシーは、CloudWatch Logs Insightsにクエリを投げるための基本的なアクションを許可しています。
「タグ」タブをクリックして必要なタグを追加し、「次のステップ: 確認」ボタンをクリックします。
ポリシーの名前と説明を入力し、「ポリシーの作成」ボタンをクリックします。
作成したポリシーを選択し、「次のステップ: タグ」ボタンをクリックして必要なタグを追加します。
「次のステップ: 確認」ボタンをクリックし、ロールの名前と説明を入力して、「ロールの作成」ボタンをクリックします。

これで、Lambda関数からCloudWatch Logs Insightsのクエリを実行するためのIAMロールが作成されました。このロールをLambda関数の作成時に選択して使用します。

（著者注記: 文言微妙に変わってるかも。名前とかは適当に）

Lambda関数の作成

Pythonを使用してLambda関数を作成し、CloudWatch Logs Insightsへのクエリを実行するコードを記述します。

AWS Management Consoleにログインし、Lambda サービスに移動します。
「関数の作成」ボタンをクリックします。
「一から作成」を選択し、関数名とランタイム（Python 3.x）を選択します。
IAMロール に先ほど作成したロールを適用します
「関数の作成」ボタンをクリックします。
関数コードエディタで下記のLambda関数のコードを貼り付けます。
Deployします

import boto3
import time
from datetime import datetime, timedelta

def lambda_handler(event, context):
 client = boto3.client('logs')
 log_group = 'your-log-group-name'
 end_time = datetime.now()
 start_time = end_time - timedelta(hours=1)

 start_query_response = client.start_query(
 logGroupName=log_group,
 startTime=int(start_time.timestamp() * 1000), # 開始時間（UNIXタイムスタンプ、ミリ秒）
 endTime=int(end_time.timestamp() * 1000), # 終了時間（UNIXタイムスタンプ、ミリ秒）
 queryString="fields @timestamp, @message | filter level='INFO' | sort @timestamp desc",
 limit=1000
 )

 query_id = start_query_response['queryId']

 while True:
 response = client.get_query_results(queryId=query_id)
 if response['status'] == 'Complete':
 results = response['results']
 break
 time.sleep(1)

 return results

テストの実行

「テスト」ドロップダウンメニューをクリックし、「新しいテストイベントの設定」を選びます。
テストイベントの名前を入力します。特に入力などはないので、hello-worldテンプレートをそのまま使って問題ありません
「作成」ボタンをクリックしてテストイベントを作成します。
新しく作成したテストイベントが選択されていることを確認し、「テスト」ボタンをクリックします。
実行が完了すると、結果ペインに関数の結果が表示されます。ここには、戻り値やログ出力、実行時間などの詳細が含まれます。
結果ペインの下部にある「ログを表示」リンクをクリックすると、完全なログ出力をCloudWatch Logsで確認することができます。

この手順により、AWS WebコンソールからLambda関数をテスト実行し、結果とログを確認することができます。関数の挙動を調整したい場合は、コードを編集し、再度テストを実行して確認します。

初期設定の3秒ではタイムアウトが発生する場合、下記手順によりタイムアウトを増加させます。

Lambda関数のページで「設定」タブをクリックします。
「一般設定」セクションで「編集」ボタンをクリックします。
「タイムアウト」の値を増やし（例: 30秒）、「保存」ボタンをクリックします。

まとめ

AWS LambdaとCloudWatch Logs Insightsを組み合わせることで、自動化された効率的なログ分析が容易になります。この記事の手順に従い、独自の分析タスクを自動化してみてください。

寸評

内容的にちょっと複雑なためか、記事は会話の内容を自分でかなりツギハギしている。さすがにこの内容を一発で出してくれるほど有能ではない模様。でも、イチから自分で書くよりよっぽど楽だね。

AWS CloudWatch Logs Insightsで効率的なログ分析

Thu, 03 Aug 2023 16:18:49 +0900

AWS CloudWatch Log Insights便利だよね。まぁまぁコストはかかるけれど。これをプログラム的に実行するためのスニペットをChatGPT-4に書いてもらったので、その備忘録記事。

はじめに

ログ分析はシステムの監視とトラブルシューティングに不可欠です。AWSを使ったシステムにおいては、AWS CloudWatch Logs Insightsを使用すると、ログデータを対話的に検索し分析することができます。この記事では、特定の時間範囲と条件でログを効率的に抽出する方法をPythonのBoto3ライブラリを使用して説明します。

CloudWatch Logs Insightsの概要

AWS CloudWatch Logs Insightsは、Amazon CloudWatch Logs内のログデータを分析するための強力な対話型クエリエンジンです。大量のログデータから情報を素早く取得することが可能であり、運用監視やトラブルシューティングに役立ちます。

以下のような昨日を持っています。

対話的なクエリ言語: 特殊なクエリ言語を使用して、ログデータから必要な情報を素早く抽出できます。
時間範囲のフィルタリング: クエリの実行を特定の時間範囲に制限して、分析を高速化できます。
ビジュアル化: クエリ結果をグラフやチャートで視覚的に表示できます。
プログラムからのアクセス: Boto3などのSDKを使用して、プログラムからクエリを実行できます。

クエリの作成と実行

クエリは次のようなコンポーネントから構成されます：

fields: 取得するフィールドを指定。例：fields @timestamp, @message
filter: 条件に一致するログエントリをフィルタリング。例：filter level='INFO'
sort: 特定のフィールドで結果を並べ替え。例：sort @timestamp desc
limit: 結果の数を制限。例：limit 20

例をあげましょう。以下のような構造的なjsonデータをCloudWatch Logsに出力しているとします。

{
 "level": "INFO",
 "message": "..."
}

level=“INFO"のものだけを抽出し、直近の時間のものから並べるのは、以下のようなクエリで可能です。

fields @timestamp, @message | filter level='INFO' | sort @timestamp desc

PythonとBoto3でのクエリの実行

PythonとBoto3を使用してクエリをプログラムで実行することもできます。以下は、特定のロググループについて、直近1時間のINFOデータを抽出するプログラムの例です。

from datetime import datetime
import boto3
import time

client = boto3.client('logs')
log_group = 'your-log-group-name'
end_time = datetime.now()
start_time = end_time - timedelta(hours=1)

start_query_response = client.start_query(
 logGroupName=log_group,
 startTime=start_time,
 endTime=end_time,
 queryString="fields @timestamp, @message | filter level='INFO' | sort @timestamp desc",
 limit=1000
)

query_id = start_query_response['queryId']

while True:
 response = client.get_query_results(queryId=query_id)
 if response['status'] == 'Complete':
 results = response['results']
 break
 time.sleep(1)

for result in results:
 print(result)

このコードは、指定されたロググループと時間範囲でクエリを実行し、レベルがINFOのログエントリを取得します。

まとめ

CloudWatch Logs Insightsは、大規模なログデータの分析と検索に非常に効率的なツールです。特定のフィールドのフィルタリング、並び替え、制限など、柔軟なクエリオプションが提供されています。プログラムからも簡単にアクセスできるため、自動化された分析やダッシュボードの作成にも適しています。これにより、システムの監視と分析がより効率的になります。

寸評

コードはちょっと手直しが必要だったが、普通に動いてくれたのでまぁよかったね。最初はすべてのログストリームを取得してプログラムでフィルタするという全然違うやり方を提案されて、えぇー、そんな馬鹿なと思って突っ込んで聞いたら、ちゃんとCloudWatch Logs Insightsを使ったやり方を教えてくれた。ChatGPTは本当にそういうところがある。

質問リンクは以下。興味がある人はどうぞ。

https://chat.openai.com/share/d3ae4555-46e3-4573-bc85-26ca34491ab5

Lambdaバージョン

続きの記事でLambda関数使ったやり方書きました。

AWS SAMのテンプレートファイルでParameter Storeの値を取得する記述

Tue, 01 Aug 2023 09:00:00 +0900

前の記事で「質問したことを備忘録として記事にまとめて」と言ったところ、なんと「次回は〜〜をします！お楽しみに！」とまさかの備忘録の次回作を勝手に予告されてしまってめっちゃ笑った。せっかくChatGPTが意欲的になったので、次回作を書いてもらったのだが、「パラメータストアの値をCloudformationで取得する（コードで取得しなくてよい）」という知らなかった方法を紹介されてめっちゃためになってしまった……。

はじめに

AWS SAM (Serverless Application Model)を使用すると、サーバーレスアプリケーションのデプロイメントと管理が大幅に簡素化されます。一方、AWS Systems Manager Parameter Storeは、設定データやシークレットをセキュアに保存し、アプリケーションから簡単にアクセスすることができるサービスです。今回は、これら2つのサービスを組み合わせて、AWS SAMテンプレート内で直接Parameter Storeの値を取得する方法について解説します。

直接Parameter Storeの値を取得

Lambda関数のコード内でAWS SDKを使用してParameter Storeからパラメータを取得する代わりに、AWS SAMテンプレート内でCloudFormationのサブスティテューション機能を使用してParameter Storeの値を直接取得することができます。

これは、以下のようにAWS SAMテンプレートを記述することで可能です。

Resources:
 MyFunction:
 Type: AWS::Serverless::Function
 Properties:
 Handler: index.handler
 Runtime: nodejs14.x
 CodeUri: s3://my-bucket/my-function.zip
 Environment:
 Variables:
 MY_VARIABLE: !Sub "{{resolve:ssm:/path/to/parameter:1}}"

ここで、!SubはCloudFormationのサブスティテューション（置換）機能を使用しています。{{resolve:ssm:/path/to/parameter:1}}は、バージョン1の/path/to/parameterという名前のParameter Storeのパラメータの値を取得しています。/path/to/parameterは実際のパラメータの名前に置き換えてください。

（著者注記: パス部分はパラメータストアのパラメータ名をそのまま入れたら良い）

この記述により、Lambda関数内では、process.env.MY_VARIABLEのように通常の環境変数を参照するだけで、Parameter Storeのパラメータの値を取得することができます。

注意点

この方法でパラメータを取得する際、実行はCloudFormationサービスにより行われます。そのため、CloudFormation自身がParameter Storeへのアクセス権限を持っている必要があります。通常、CloudFormationのService RoleはAWS管理ポリシー AWSCloudFormationFullAccess をアタッチして作成され、このポリシーにはParameter Storeへのアクセス権限が含まれています。したがって、通常はService Roleを特別に設定する必要はありませんが、カスタムポリシーを使用してService Roleを作成した場合など、適切な権限が設定されていることを確認してください。

まとめ

AWS SAMテンプレートとCloudFormationのサブスティテューション機能を使用することで、コード内でAWS SDKを使用せずに直接Parameter Storeからパラメータを取得することが可能になります。これにより、コードの見通しが良くなり、Parameter Storeのパラメータ管理がさらに便利になります。

次回は、AWS SAMテンプレートでのLambda Layerの利用について解説します。お楽しみに！

（著者注: そんな予定はない）

寸評

なんで備忘録だといってるのに次回予告するねんｗｗｗとか言ってたら、フツーに知らない情報書かれて焦った。ちゃんと動きました。ためになりました。

元々は環境変数の使い方とかいう超初歩的な記事を書いていたんだけれど、その中でしれっとパラメータストアの値を直接取得していて、「え、そんなことできるの？」となってしまった。毎回Lambda関数の中でGetParametersしてたっていうね。。。ためになりました。。。

AWS SAMでParameter Storeからパラメータを取得するためのIAMロールの作成

Mon, 31 Jul 2023 09:00:00 +0900

AWS SAMでどこを参照して良いのかいつも迷子になるテンプレートファイルの書き方。パラメータストアはいつも使うやつではないので、たまに使おうとすると「どう書くんだっけ……」と忘れている。

ChatGPT-4に聞いて確認しました。結果、そもそもコードで取得しなくて良いということがわかりましたが（後述）、本記事自体はあくまでコードでパラメータを取得するためのIAMロールを作成する方法になります。

はじめに

AWS SAM (Serverless Application Model) を使用してサーバーレスアプリケーションを構築する際、しばしば環境変数や設定値などをAWS Systems Manager Parameter Storeから取得する必要があります。これを適切に行うためには、Lambda関数に対してParameter Storeへのアクセス権限を持つIAMロールを付与する必要があります。本記事では、そのIAMロールをAWS SAMテンプレートでどのように定義すればよいかを詳しく解説します。

IAMロールの作成

以下のYAML形式のコードスニペットは、AWS SAMテンプレート内でIAMロールを定義する方法を示しています。

Resources:
 MyRole:
 Type: AWS::IAM::Role
 Properties:
 AssumeRolePolicyDocument:
 Version: '2012-10-17'
 Statement:
 - Effect: Allow
 Principal:
 Service:
 - lambda.amazonaws.com
 Action:
 - sts:AssumeRole
 Policies:
 - PolicyName: ParameterStoreAccess
 PolicyDocument:
 Version: '2012-10-17'
 Statement:
 - Effect: Allow
 Action:
 - ssm:GetParameters
 - ssm:GetParameter
 Resource: arn:aws:ssm:region:account-id:parameter/MyParameter

このテンプレートでは、MyRoleという名前のIAMロールが作成され、このロールはLambdaサービスがAssumeRoleを行えるようになっています。また、そのロールにはParameterStoreAccessという名前のポリシーが付与されており、このポリシーはMyParameterという名前のParameter Storeのパラメータへのアクセスを許可しています。

ここで、regionとaccount-idはそれぞれAWSリージョンとあなたのAWSアカウントIDを表します。これらを適切な値に置き換えてください。

補足情報:

この例ではパラメータ取得のための権限 (ssm:GetParameters と ssm:GetParameter) をIAMロールに付与していますが、他の権限も必要な場合はそれぞれ追加してください。また、特定のパラメータだけでなく、すべてのパラメータにアクセスする権限を付与したい場合は、リソースのARNをarn:aws:ssm:region:account-id:parameter/*としてください。

まとめ

AWS SAMテンプレートでIAMロールを適切に定義し、Lambda関数にParameter Storeへのアクセス権限を付与することで、安全にParameter Storeからパラメータを取得することが可能になります。これにより、サーバーレスアプリケーションの設定値管理を柔軟に行うことができます。

次回は、AWS SAMテンプレートでの環境変数の管理方法について詳しく解説します。お楽しみに！

（著者注：そんな予定はない）

寸評

次回作が出てきて笑ってしまった。そんな予定があったのかｗ

内容については動作確認済みです。適切だと思います。Pythonコードは以下ですね。

ssm = boto3.client("ssm")
TOKEN = ssm.get_parameters(Names=[os.environ["パラメータ"]], WithDecryption=True)[
 "Parameters"
][0]["Value"]

“パラメータ"の値を取得してTOKENに突っ込んでいます。

ただし、これは実は冗長で、テンプレートファイルから直接取得することができます。次回は環境変数の管理方法ではなく、テンプレートファイルから直接取得する方法です。

以下は質問。

AWS SAMのテンプレートで、パラメータストアから特定のパラメータについて取得するための権限の書き方は？
うまくいきました。適切なロールだったようですね。備忘録にしたいので、ブログ記事としてまとめてください。

備忘録だっつってんのに次回作書きたがるChatGPTｗwwとか言ってたら知らないこと書かれてしまった……。

AWSアカウントIDを確認する複数の方法

Sun, 16 Jul 2023 03:12:33 +0900

タイトルのとおりなんだが、AWSアカウントIDをしばしば失念して、どうやって調べたらいいんだっけ？と思ってChatGPT-4に聞いた。聞いたら答えてくれるんだが、一番いい方法をなかなか教えてくれなかった。ChatGPTはそういうところある。

イントロ

こんにちは、AWSユーザーの皆さん。本日は、AWSアカウントIDを確認する方法についていくつか紹介します。一つはAWS CLIを用いる方法、もう一つはAWS Management Consoleを利用する方法です。さらに、CLIの中でも特に効率的な方法を一つご紹介します。

コンソールからのログイン

まずAWS Management ConsoleからアカウントIDを確認する方法を見てみましょう。以下の手順になります：

AWS Management Consoleにログインします。
右上のナビゲーションバーにある自分のアカウント名またはユーザー名をクリックします。
ドロップダウンメニューから"My Security Credentials"（または"セキュリティ資格情報"）を選択します。
“Account details”（または"アカウント詳細"）セクションを展開すると、アカウントIDが表示されます。

しかしこの方法は、すでにAWS Management Consoleにログインしていることが前提となっています。つまり、ログイン前の状況では利用できないという制約があります。

AWS STSによる取得

AWS CLIから直接アカウントIDを取得したい場合には、AWS Security Token Service（STS）の get-caller-identity コマンドが非常に便利です。次のように実行します：

aws sts get-caller-identity

これにより、以下のような出力が表示されます：

{
 "UserId": "AIDAJDPLRKLG7UEXAMPLE",
 "Account": "123456789012",
 "Arn": "arn:aws:iam::123456789012:user/Alice"
}

“Account"フィールドがあなたのAWSアカウントIDです。

このget-caller-identityコマンドは、ログインを必要とせず、コマンドラインから直接アカウントIDを取得できるため、スクリプトの自動化や複数のAWSアカウントを管理する際に非常に便利です。

いずれの方法を選択するにせよ、AWSのセキュリティ資格情報（アクセスキーとシークレットアクセスキー）は適切に管理し、他人に漏れないように注意する必要があります。それでは、引き続きAWSの探求を楽しんでください。質問や意見がありましたら、お気軽にコメント欄からどうぞ！

寸評

やけにフレンドリーな文体でなんか笑う。

それはそれとして、この回答はストレートにもらえていない。何故か最初に aws iam get-user を使うやり方を勧めてきたんだよ。確かにそれでも取得できるんだけれど、aws stsを使った出力のほうが断然スマートだった。代替え案はあるか聞いたら教えてくれたんだけど……危ないなぁ。他にいい案はないか、聞くほうがいいんだな。勉強になった。

AWSのアカウントIDをCLIで知る方法はある？

ここでaws iam get-userを出してきた

うまくいった。備忘録のために、これをブログの記事風にまとめてくれ。

てっきりこれで終わるところだった。騙されるところだった

ありがとう。ちなみに他にAWSアカウントIDを確認する方法はあるかな？

ふと気になって聞いてみた

aws sts get-caller-identity が一番いいな。コンソールのほうは、ログインしないとわからないから、ログインする前だと残念ながら金庫の中の鍵なんだよねぇ。

てめー最初からそっち言えよこんにゃろーと思いつつ

ここまでの議論をブログ記事としてまとめてください。

ChatGPTは役人と思って接しなければならないと改めて感じた。ちなみに記事もそこそこ手を入れている。うーん、質問力が試される……。

Boto3のTypeDeserializerを使用してDynamoDB Streamsイベントをパースする

Thu, 06 Jul 2023 22:12:04 +0900

DynamoDB Streamのパース、ずっと自前でやっていたんだが、実はライブラリでデシリアライザが用意されていることを「DynamoDB JSONの型変換をboto3だけで行ってみる | DevelopersIO」で知った。。。これを使うとDynamoDB Streamのパースも楽にできる。

テストデータとセットであると便利に思ったので、ChatGPT-4に聞いてみた。

イントロ

Boto3のTypeDeserializerは、DynamoDBのデータ型をPythonの標準のデータ型に変換するのに役立ちます。これは、DynamoDB Streamsのイベントを処理する際に特に便利です。この記事では、TypeDeserializerの基本的な使い方と、それを使用してDynamoDB Streamsイベントをパースする方法について説明します。

TypeDeserializerの基本

TypeDeserializerクラスは、DynamoDBのレスポンスをパースするための便利なツールです。これはDynamoDBからのレスポンスをPythonの標準的なデータ型に変換します。以下に基本的な使用方法を示します。

from boto3.dynamodb.types import TypeDeserializer

deserializer = TypeDeserializer()

# DynamoDBのデータ
dynamodb_data = {
 'S': 'Hello, world!'
}

# データをデシリアライズ
deserialized_data = deserializer.deserialize(dynamodb_data)

print(deserialized_data) # 'Hello, world!'

ここでは、DynamoDBの文字列型（‘S’）をPythonの文字列にデシリアライズしています。

なお、DynamoDBの数値データ型（‘N’）は、Boto3のTypeDeserializerを使用してデシリアライズされるとき、Pythonのdecimal.Decimal型になります。

これはDynamoDBが数値を浮動小数点数として保存し、それがそのままの精度で保存されることを保証するためです。Pythonの標準的なintやfloat型を使用すると、特に大きな数値や非常に小さな数値の場合に精度が失われる可能性があります。そのため、decimal.Decimal型が使用されます。

DynamoDB Streamsイベントのパース

DynamoDB Streamsイベントは、テーブルに変更があったときに発行されます。これらのイベントには、変更前後の項目の詳細やイベントの種類（INSERT、MODIFY、REMOVE）など、役立つ情報が含まれています。

以下は、TypeDeserializerを使用してDynamoDB Streamsイベントをパースする例です。

from boto3.dynamodb.types import TypeDeserializer

def parse_dynamodb_stream_event(event): 
 deserializer = TypeDeserializer() 
 for record in event['Records']: 
 dynamodb = record['dynamodb'] 
 
 # 変更前の項目をパース
 if 'OldImage' in dynamodb: 
 old_image = {k: deserializer.deserialize(v) for k, v in dynamodb['OldImage'].items()} 
 else: 
 old_image = None 
 
 # 変更後の項目をパース
 if 'NewImage' in dynamodb: 
 new_image = {k: deserializer.deserialize(v) for k, v in dynamodb['NewImage'].items()} 
 else: 
 new_image = None 
 
 print(f"Event Name: {record['eventName']}") 
 print(f"Old Image: {old_image}") 
 print(f"New Image: {new_image}\n")

この関数は、DynamoDB Streamsイベントの各レコードの"OldImage"と"NewImage"をパースしてPythonのデータ型に変換します。これにより、変更前後の項目データを簡単に利用することができます。

なお、DynamoDB Streamのイベント例は以下です。

{
 "Records": [
 {
 "eventID": "1",
 "eventName": "INSERT",
 "eventVersion": "1.0",
 "eventSource": "aws:dynamodb",
 "awsRegion": "us-west-2",
 "dynamodb": {
 "Keys": {
 "Id": {
 "N": "101"
 }
 },
 "NewImage": {
 "Message": {
 "S": "New item!"
 },
 "Id": {
 "N": "101"
 }
 },
 "StreamViewType": "NEW_AND_OLD_IMAGES",
 "SequenceNumber": "111",
 "SizeBytes": 26
 },
 "eventSourceARN": "arn:aws:dynamodb:us-west-2:account-id:table/ExampleTableWithStream/stream/2015-06-27T00:48:05.899"
 },
 {
 "eventID": "2",
 "eventName": "MODIFY",
 "eventVersion": "1.0",
 "eventSource": "aws:dynamodb",
 "awsRegion": "us-west-2",
 "dynamodb": {
 "Keys": {
 "Id": {
 "N": "101"
 }
 },
 "NewImage": {
 "Message": {
 "S": "This item has changed"
 },
 "Id": {
 "N": "101"
 }
 },
 "OldImage": {
 "Message": {
 "S": "New item!"
 },
 "Id": {
 "N": "101"
 }
 },
 "StreamViewType": "NEW_AND_OLD_IMAGES",
 "SequenceNumber": "222",
 "SizeBytes": 59
 },
 "eventSourceARN": "arn:aws:dynamodb:us-west-2:account-id:table/ExampleTableWithStream/stream/2015-06-27T00:48:05.899"
 },
 {
 "eventID": "3",
 "eventName": "REMOVE",
 "eventVersion": "1.0",
 "eventSource": "aws:dynamodb",
 "awsRegion": "us-west-2",
 "dynamodb": {
 "Keys": {
 "Id": {
 "N": "101"
 }
 },
 "OldImage": {
 "Message": {
 "S": "This item has changed"
 },
 "Id": {
 "N": "101"
 }
 },
 "StreamViewType": "NEW_AND_OLD_IMAGES",
 "SequenceNumber": "333",
 "SizeBytes": 38
 },
 "eventSourceARN": "arn:aws:dynamodb:us-west-2:account-id:table/ExampleTableWithStream/stream/2015-06-27T00:48:05.899"
 }
 ]
}

以上が、Boto3のTypeDeserializerを使用してDynamoDB Streamsイベントをパースする方法です。

寸評

テストデータを出してくれるのが神。

以下がChatGPT-4にした質問。

boto3のTypeDeserializerの使い方を教えて
DynamoDB Streamのeventをパースするのにも使える？
DynamoDB Streamのテストデータを出して
ここまでのことを記事としてまとめてください。
（追加）このデシリアライザを使うと、数値はDecimalになりますか、それともintになりますか、それともfloatになりますか？

最初にある程度正解知ってるからよかった。

クラウドインフラ on AIによる技術記事 備忘録

自宅サーバー公開におけるルーティング設計：Cloudflare TunnelとCaddyの役割分担

物理配置とネットワーク境界の前提

Caddy を経由させる構成（単一ゲートウェイ原則）

メリット

デメリットと注意点

Caddy を経由させない構成（疎結合・最小ホップ原則）

メリット

デメリットと注意点

運用における選択基準

東京が消し飛んでもシステムを復旧させるのか？──現場を凍りつかせる「BCPチェックシート」という名の茶番

「基幹インフラだけが無傷」というSF的ご都合主義

「この状況で仕事するわけないだろ」という正常な直感

組織防衛のためのアリバイ工作と責任の所在

欺瞞を捨て、本当の「生存」から逆算する

サーバレスの夢の残骸

「AWS文学」と一次資料至上主義の病理

クラウドへの屈服とアーキテクチャの複雑性の爆発

コンテナオーケストレーションという名の欺瞞

果たせぬ夢だったサーバレスと、物理バイナリへの誇り

下品な無差別サーバ攻撃の不快感

無差別スキャンの実態と「下品な攻撃」がもたらす徒労感

結論としての防御方針

AWS DynamoDBでQuery操作を行う方法【Boto3】

必要なモジュールのインポート

DynamoDBリソースの初期化

基本的なQuery操作

パーティションキーのみを指定

パーティションキー + ソートキー条件

結果のソート順を変更

昇順（デフォルト）

降順

フィルタリングを追加

FilterExpression を使用

結果のページング処理

インデックスを使用したQuery

例: GSIの指定

エラーハンドリング

実際のデータ例

テーブル構造

クエリ結果例

注意点とベストプラクティス

AWS Systems Manager Parameter Storeからパラメータを取得する方法（Python + Boto3）

必要な準備

汎用的なPythonコードスニペット

コードの説明

fetch_parameter 関数の引数

例外処理

実行例

注意点

応用例

複数パラメータの取得

環境変数への設定

まとめ

[Python, Boto3] DynamoDBのクエリで1MBを超えるデータをすべて取得する関数のスニペット

スニペット

使用例

オプション: FilterExpression の利用

備考

AWS SAMでLambda関数をスケジュール実行する

SAMテンプレートにスケジュールイベントを追加

Schedule イベントの詳細

rate 式の使用例

cron 式の使用例

毎日午前9時に実行

毎月1日午前8時に実行

平日の毎日午後1時に実行

週末の毎日午前10時に実行

毎時30分に実行

cron式のワイルドカード? と * の使い分け

まとめ

参考資料

AWS Lambda Layers に特定のリポジトリからライブラリをアップロードする

前提条件

Lambda Layer 用のディレクトリ構造を作成

Git リポジトリからライブラリをインストール

不要なファイルを削除（オプション）

Layer の ZIP ファイルを作成

AWS Lambda Layer にアップロード

Lambda 関数に Layer を追加

クラウドインフラ on AIによる技術記事備忘録

`FilterExpression` を使用

`fetch_parameter` 関数の引数

オプション: `FilterExpression` の利用

`Schedule` イベントの詳細

`rate` 式の使用例

`cron` 式の使用例

cron式のワイルドカード`?` と `*` の使い分け

`.env` ファイルの例

`.env` ファイルのバージョン管理を避ける

`ALLOW_USER_SRP_AUTH`の重要性

`ALLOW_USER_SRP_AUTH`を使用した認証プロセスのコード例