CUR による AWS コスト構造の継続的モニタリング
当社では複数の SaaS プロダクトを開発・稼働するための環境として、主に AWS を利用しています。AWS 等のシステムにかかるコスト構造を正確に把握することは、プロダクト原価の算定や適正なプライシングを行う上で非常に重要です。 今回、カスタム定義のコストカテゴリ体系を各種 AWS リソースにかかるコストに適用し、継続的にモニタリングするための仕組みを構築してみたので、本記事ではその内容についてご紹介したいと思います。 概要 まず、実装を試みたコストカテゴリ設計の考え方について説明します。 次に AWS Cost Categories で実装する際の課題感に触れた後、今回利用する AWS Cost and Usage Report (CUR) について紹介します。 コストカテゴリ設計 コストカテゴリのレベルとして、以下の 3 つを定義しました。 Level-1 ... プロダクト原価を構
[アップデート] CloudShell を任意の VPC 上で起動できる CloudShell VPC environment が提供されました！ | DevelopersIO
こんにちは、AWS 事業本部の平木です！ 皆さんは CloudShell を活用していますか？ 普段使用したことがある方ならご存じかと思いますが、今まで CloudShell はパブリックな環境のためインターネット経由で様々な通信を行っていました。 今回のアップデートで、ユーザーが作成した VPC 上に CloudShell を起動できる CloudShell VPC environment が提供されたため仕様を確認してみます。 何ができるようになったか 何ができるようになって、何ができないようになったのかを確認してみます。 任意の VPC 上に CloudShell を起動 まずメインの部分はこちらです。 今までは CloudShell ではインターネットに自由に出ることができましたが、今回のアップデートによりユーザーが作成した VPC 上に CloudShell を起動することでプラ
![[アップデート] CloudShell を任意の VPC 上で起動できる CloudShell VPC environment が提供されました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/0a0e7b3291eb56e38287dd9b8dd2b32df9a92dd2/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F08%2Faws-cloudshell.png)
インフラのテストに VPC Reachability Analyzer は外せないという話
人間の尊厳、幸福、アクセシビリティ / 第116回「WEB TOUCH MEETING」アクセシビリティSP
Amazon AthenaからIceberg形式のGlueテーブルの削除済みのスナップショットにタイムトラベルできないことを確認する | DevelopersIO
Amazon AthenaからIceberg形式のGlueテーブルの削除済みのスナップショットにタイムトラベルできないことを確認する データアナリティクス事業本部 インテグレーション部 機械学習チームの鈴木です。 今回は簡単な例ですが、Iceberg形式のGlueテーブルに対して、どのような場合にタイムトラベルができて、どうすればできなくなるのかをAmazon Athenaから確認してみました。 はじめに Amazon AthenaなどでサポートされているIcebergテーブルでは、スナップショットをもとに過去のデータの状態にタイムトラベルすることが可能です。 一方でスナップショットが残ってしまうことが課題となるケースもあります。例えば以下のSnowflakeの記事で紹介されているようなケースです。 GDPR：ベストプラクティス、一般的なリファレンスアーキテクチャパターン これはEU一般デ
[レポート] 生成AIを使ってファイアウォールを強化しよう #NIS375 #AWSreInforce | DevelopersIO
AWS re:Inforce 2024 NIS375 Enhance your firewall protection with generative AI のセッションレポートです。 Amazon Bedrockを使ったAWS Network Firewallの効率的な運用方法を学ぶセッションでした。 こんにちは！ AWS 事業本部コンサルティング部のトクヤマシュンです。 フィラデルフィアで開催されている AWS re:Inforce 2024 に参加していました。 本記事は AWS re:Inforce 2024 のセッション「Enhance your firewall protection with generative AI」のセッションレポートです。 Amazon Bedrockを使ったAWS Network Firewallの効率的な運用方法を体験するセッションでした。 セッシ
![[レポート] 生成AIを使ってファイアウォールを強化しよう #NIS375 #AWSreInforce | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/d1ac42cfd4e5f0a287ed5db0380a987866b4dde2/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2024%2F06%2Feyecatch_awsreinforce2024_1200x630.png)
ワークフローツールを AWS Step Functions に移行した話 | CyberAgent Developers Blog
AI事業本部の協業リテールメディアdivでソフトウェアエンジニアをしている 中澤 といいます。直近では、プロダクト開発以外にAI 事業本部の新卒研修の運営を行なったりもしていました。 私が所属しているチームで最近、定期バッチを行うワークフロー管理ツールを AWS Step Functionsへ移行したので、移行の背景や得た知見を記事として公開します。 移行前の構成 私たちのチームでは、ワークフロー管理ツールを AWS Step Functions に置き換える前には、Prefect を使っていました。 Prefect に関しては、弊社ブログの別記事があるので、Prefect について知りたい方はそちらも参考にしてみてください。 Prefect を利用している時の構成では、Prefect 側でワークフローのスケジュール管理やワークフロー内のタスク実行を Prefect、実際のワークフローのタ
pureなjsでGraphQLのrequestを投げる方法（Lambda@Edgeなど） - Qiita
Lambda@EdgeからとあるエンドポイントにGraphQLのqueryを実行したい場合がありました。 Lambda@Edgeにはレイヤーをアタッチすることができないので、Lambdaのランタイムに組み込まれている方法でhttpリクエストを飛ばす必要があります。 （正確にはコードとライブラリをまとめたzipが1MB以下に収まるのであれば、そのzipをデプロイすることでサードパーティのNodeライブラリも利用することができるようになりますが、実装時点では調査が足らず不可能だと思っていました。詳しくは下のリンクをご参照ください。） 今回はとある事情から、ランタイムとしてNode.jsのv16系を利用していました。 Nodeのhttpクライアントライブラリとしてはaxiosやnode-fetchなどがよく使われますが、Node16にこれらは組み込まれていません。 Node.jsのv18系を使え
Playwright testをLambdaコンテナ上でRICを使って動作させる - Qiita
概要 Lambda関数は通常Amazon Linux上で動作していますが、Playwrightは公式ではDebianとUbuntuしかサポートしていません（参考）。 そのため、Lambda Runtime Interface Client(RIC)を使ってDebian上のNode.jsのベースイメージを元にPlaywrightをインストールすることでLambda上で動作させました。 ローカルで動作確認したいためAWS Serverless Application Model(AWS SAM)で構築しています。 ソース類は以下にまとめています。 https://github.com/octop162/playwright-lambda SAM準備 sam init で初期化しtemplate.yamlを生成しました。 メモリ使用量を1024MB, タイムアウトを最大の900秒に設定しています
AWS LambdaでPlaywrightを使う(Python 3.10 + playwright1.42.0) - Qiita
スクレイピングにseleniumを使用していましたが、playwrightがかなり直感的で使いやすかったことから活用を始めました。また、実行環境をlambdaにすることで他のアプリケーションから利用しやすくすることもできるため、その方法をまとめておきます。 開発環境 Windows10 Home 22H2 Python 3.10.4 playwright 1.42.0 1.playwrightを利用した機能を実装する ローカルで普通に実装します。ブラウザオブジェクトを作る際には次のオプションを指定しておきます。今回は図書館のHPにアクセスして貸出状況を取得するスクレイパーを実装しています。 browser = playwright.chromium.launch( args=[ "--disable-gpu", "--single-process", ], ) 2.lambdaから利用する
OpenapiのYamlをCodeCommitにPushしたら自動的にHTMLに変換してS3にホストして公開する - Qiita
要約 Openapi仕様で書かれたYamlファイルは、ツールを使って静的なHTMLに変換することができる。ここでは、それらのツールのひとつであるredocで、YamlをHTMLに変換する。通常は、手元でredocを使い、HTMLに変換したのち、関係者に共有したり、S3の静的ホスティング機能を使って共有したりする。本稿では、手元で変換する手間を惜しむため、CodeCommitにコミットしたら、自動的にHTMLに変換し、S3にホストする仕組みを紹介する。 構成 手順 １． CodeCommitのリポジトリを準備する 下記のように、buildspec.ymlとopenapi.yamlを用意する。buildspecには、codebuildで実行する処理を記述する。 openapiはAPI仕様である。 ２．buildspec.ymlを用意する 以下のようなbuildspec.ymlを用意する。 no
AWS Chalice で実装したアプリケーションのユニットテスト - Qiita
AWS Chalice とは AWS SDK for Python を開発するチームによってメンテナンスされている、AWS Lambda に展開するアプリケーションを実装するための Python のマイクロフレームワークです。 ビルトインされている @api.route, @app.on_s3_event などのデコレータを用いて関数を実装し、CLI で簡単にそれらを実際に AWS 上に展開することが出来るようになります。 例えば、chalice CLI の中にある chalice new-project コマンドでプロジェクトの雛形を作成するとこのような実装が生成されます。 from chalice import Chalice app = Chalice(app_name='test') @app.route('/') def index(): return {'hello': 'wo
PythonのFastAPIをLambdaで動かそうと思ったらSQLModelも使ってみたくなったので調べてみた(テストまあまあ盛り) - Qiita
PythonのFastAPIをLambdaで動かそうと思ったらSQLModelも使ってみたくなったので調べてみた(テストまあまあ盛り)PythonunittestpytestSQLModel はじめに Pythonでデータ分析やスクレイピングや画像認識などをやっているのですが、Webアプリのバックエンドとして仕事で本格的に利用したいと思い、いろいろ調べてみると、AWSの LambdaでFastAPIを動かすとの話題が多く目に留まり、ふむふむ、と進めていくと、SQLModelも一緒に利用したいと思い、半日ほど試行錯誤してみたのでまとめてみたいと思います。 ソースはgithubに登録しております。 SQLModelの概要 SQLModelは、直感的で使いやすく、互換性が高く、堅牢になるように設計されており、Pythonの型アノテーションに基づき、PydanticとSQLAlchemyを利用して
AWS AppSync がアツい！ RDS Data API を使って GraphQL API を爆速で作ってみた - Qiita
CREATE TABLE conversations ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE messages ( id UUID PRIMARY KEY, conversation_id INT NOT NULL, sub UUID NOT NULL, body TEXT NOT NULL, created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (conversation_id) REFERENCES conversations(id) ); CREATE TABLE con
CDKのAPIGateway+Lambda構成をOpenAPIの定義から作成する - Qiita
どんな内容か CDKにてAPIGateway+Lambdaの構成を作る際に、RestApiではなくOpenAPI定義からAPIGatewayを作ることができるSpecRestApiを使ってみたという内容になります。 OpenAPIとは OpenAPIとは、RESTful APIを記述するための標準化されたフォーマットのことで、OpenAPI Specification(OAS)やOpenAPI Generatorなど取り巻く技術の総称としても呼ばれています。 もともとswaggerとして有名だったのですが、OASとして標準化されてからはOpenAPIと呼ばれることが多く、swaggerはOpenAPIのツール的な位置付けになっています。 例えば、https://jsonplaceholder.typicode.com/ というRESTfulAPIを公開しているサービスがあるのですが、その中
デフォルトのエンドポイントの有効無効をAWS CFnテンプレートとOpenAPIで指定する - Qiita
AWS CloudFormation と OpenAPI を使用して Amazon API Gateway を構築する時、「デフォルトのエンドポイント」を無効にする方法がわかりづらかったので、ノウハウを残します。 AWS SAM の AWS::Serverless::API リソースには、デフォルトのエンドポイントの有効と無効を切り替える DisableExecuteApiEndpoint プロパティがあります。 しかし、AWS CloudFormation テンプレートで OpenAPI を DefinitionUri 使用して設定している場合（調査中）、DisableExecuteApiEndpoint プロパティが効きません。 従って、AWS の OpenAPI 拡張を使用し、AWS CloudFormation テンプレートではなく、OpenAPI 内に設定を定義する必要があります
OpenAPI × AWS CDK × APIGateway でRest APIを管理する
OpenAPI定義からAPIGatewayをいい感じに作成できたので、伝えたかった記録になっています。 どんな流れで 「OpenAPI ×CDK」 に辿り着いたのか、つらつら書いています。 長い記事になっていますが、本当に伝えたいのは最後のCDKの話だけです！ 時間が勿体ない方は最後の方だけ読んでいただけたらと思います。 【想定している層】 APIGateway そこそこ分かる CDK 聞いたことある OpenAPI(Swagger) 聞いたことない 【私のレベル】 APIGateway 2年くらい使っているけど未だにCorsエラーとかで沼る。 CDK 1ヶ月前くらいから触り始めたけど、既に好き。CloudFormationに戻れない。 OpenAPI 『スキーマ駆動開発』、とかの記事をみて気になっていて、最近初めて実際に触った。 OpenAPIとは？ 「Restful APIの定義を記述
APIGatewayを作成するときにOpenAPIから型情報を読み込み補完がきくようにしたメモ - Qiita
概要 API Gatewayの設定にOpenAPIを連携できないか検討した。 OpenAPIのJSONから型情報を読み込む形で実装してみたメモを残す。 検討 cdk - openapi-definitionを読むと、定義はすべてOpenAPIのほうに書く必要があるもよう。また、OpenAPIは3.1は使えず3.0か2.0を使う必要がある。 すべてのリソースとメソッドは OpenAPI 仕様ファイルの一部として定義する必要があり、CDK を介して追加することはできません。これは、これらのプロパティの重複や潜在的な混乱を防ぐためです。 こちらの記事で「OpenAPI定義にAWS用の設定値を記載するのが嫌だ」と言っているように、OpenAPIとAWSの設定は分けて管理したい。 記事中ではopenapixを使用しているが、1年更新がないのが不安。 型定義をOpenAPIから取り込む方法を考える。
AWS SDK Rubyでスタブを行う - Qiita
はじめに AWS SDKを使用したコードに対してテストを記述したい場合、AWSのSDKで用意されているClientStubsを使用して、スタブを行うことが可能です。 ドキュメント自体は公式が出しているものがありますが、この例だけではやりたいこと（Aws::S3::Client以外のインスタンスを使うケース）が実現できなかったので、今回調べたことについてまとめました。 環境 Ruby: 2.7.1 aws-sdk: 3.1.0 aws-s3-sdk: 1.114.0 公式ドキュメントから このドキュメントにあるようにAws::ClientStubsというモジュールが、各サービスに対応したClientクラスにincludeされています。 今回はS3を使って、その例を紹介します。 このモジュールに定義されているのはapi_requests, stub_data,stub_responsesの３つ
Dynamo DB ベースのアプリケーションをmotoとfactory_boyを用いてユニットテストする - Qiita
boto3 は AWS SDK の Python パッケージで、Dynamo DB などの AWS のサービスを呼び出すのに使います。 この boto3 には moto という mock パッケージがあります。 moto を使うと、テストを実行するとき Dynamo DB のスタブにテスト用のデータ(fixtures)を 返させることができるので、テーブルが存在していなくてもテストケースを通すことができます。 本稿では、moto を使って Dynamo DB に依存せずにアプリケーションをテストする方法を紹介します。 さらに、factory_boy を使って fixtures の組み立てを共通化する方法も紹介します。 factory_boy は fixtures の組み立てを担う Factory クラスを備えたパッケージです。 なお、本稿ではアプリケーションとして Flaskベースの AP
moto によって requests が意図せずモック化されてしまう問題を回避する - Qiita
moto は、AWS SDK の mocking パッケージです。 moto を用いたユニットテストについては以前 エントリを書きました。 このなかで触れましたが、requests パッケージが意図せずモック化されてしまう問題があります。 この問題の回避策について自分なりのアプローチをまとめておきます 問題としては、moto でスタブをアクティブにすると その後の requests パッケージによるリクエストがすべてモック化されてしまうというものです: これにより、elasticsearch-py など requests に依存したパッケージにおいてHTTPリクエストのさいにエラーが起きることがあります。 回避策 回避策としては、moto の responses_mock にパススルーする URL を登録します:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
