- 1. オッス!AutoScalingでEC2の起動・終了をオート化すっぞ!
- 2. RevenueCat WebhookをAWS API Gateway、Rust Lambda、DynamoDBで処理する
- 3. AWSのサービス(CognitoやSES等)をWireMockでモックする
- 4. Amazon Connectで画面録画を試してみた
- 5. Amazon Bedrockモデル推論の解説
- 6. AWS Lambda – Provisioned Concurrency設定時の振る舞い
- 7. aws hands-on がすごく役立った件
- 8. CLFのOUTPUT
- 9. ゼロから始めるAIシステム開発 #01 「初歩の初歩」
- 10. 個人開発サービス(Q)の技術構成
- 11. 【Terraform】resourceとmoduleって何が違うの???
- 12. 新卒エンジニアのyuuです!
- 13. GPGキーとは?AWSサーバーでのMySQLインストール事例に基づく備忘録
- 14. サーバーのOSと開発環境でのフレームワーク等のバージョニングに関する備忘録
- 15. AWSロードバランサー設定で詰まったところ – ヘルスチェック設定に関する備忘録
- 16. ガバメントクラウドにおけるオンプレミスからAWSへの名前解決の指針について
- 17. AWS Client VPN のハンズオン
- 18. CloudShell で cfn-lint と cfn-nag を使う
- 19. Lambda関数でMySQLに接続する
- 20. 【API Gateway】バイナリペイロードを適切に扱う
オッス!AutoScalingでEC2の起動・終了をオート化すっぞ!
# :pencil2: はじめに
2年くらい資格学習だけのエアプ勢だった僕が、いよいよAWSをさわり始めました。
そして最初の試練として上司から以下のような依頼をもらいました。
「EC2インスタンスを2個実行中だけど、営業時間外は使わないから止めてコストカットしよう:point_up:」# :pencil2: AutoScalingスケジュールで実現!
該当のEC2インスタンスはAutoScalingグループで管理されているので、下記の通りスケジュールを2個作成することで実現はできました。EC2 >AutoScalingグループ >(僕のAutoScalingグループ名) >
オートスケーリング >予定されたアクション >予定されたアクションを作成するボタン– 終了スケジュール
(Japan 06:00~, 希望するキャパシティ:0, 最小キャパシティ:0, 最大キャパシティ:0)
– 起動スケジュール
(Japan 21:00~, 希望するキャパシティ:2, 最小キャパシティ:2, 最大キャパシティ:10)![image.png](https://qiita-im
RevenueCat WebhookをAWS API Gateway、Rust Lambda、DynamoDBで処理する
RevenueCatは、iOS、Android、Webなど様々なプラットフォームでアプリ内サブスクリプションを簡素化する強力なサブスクリプション管理サービスです。その主要機能の1つは、購入、更新、キャンセルなどのサブスクリプションイベントについてバックエンドに通知するWebhookを送信する能力です。この記事では、AWS API Gateway、AWS Lambda(Rustで実装)、およびストレージ層としてDynamoDBを使用して、RevenueCat Webhookを処理する方法を探ります。
![RevenueCat-Webhooks with AWS.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3887819/8af63fd5-705c-983d-48e9-b334c03a9315.jpeg)
## アーキテクチャ概要
アーキテクチャは以下の主要コンポーネントで構成されています:
1. **RevenueCat Webhook**:RevenueCatはWebhookイベント(サブスク
AWSのサービス(CognitoやSES等)をWireMockでモックする
# はじめに
ローカル開発環境下で、AWSの実際のサービスに接続せずモックで対応したいケースは多々あります。
AWSサービスのmockは巷にはあるのですが、それを使えるようにするための準備が結構大変そうです。
しかし、WireMockを利用すれば、手早く使用するサービスの機能に限定してMockすることが出来ます。
ここでは、WireMockを使用してAWSのサービスをMockする方法を紹介したいと思います。# 使用するライブラリ
* [WireMock](https://wiremock.org/docs/standalone/java-jar/)**前提条件**
上記ライブラリはjava環境が必要なため、Javaがインストールされている必要があります。## WireMockとは
WireMockとは、WebAPIのシミュレーションを行えるツールです。# やり方
## MockするためのAPI仕様を確認するAWSの使用するサービスによりやり方が変わってくるかと思いますが、まずは、以下のサイトにより、APIの仕様を確認します。
https://docs.aws.am
Amazon Connectで画面録画を試してみた
# はじめに
Amazon Connectではオペレーターの画面を録画する機能があります
画面録画を実施するには、オペレーターの方のPCにアプリケーションをダウンロード・インストールを実施する必要があります。当記事はオペレーターの方のPCへのアプリケーションのインストール方法とAmazon Connect側の設定について説明します。## 注意点
– 画面録画の開始と終了のタイミングは、通話開始からアフターコールワーク終了までです
– Amazon Connect側の設定だけでは、画面録画はされません
– 画面録画はアフターコールワーク終了後、1分程度で設定したS3に出力されます
– 複数ディスプレイの場合は3画面まで録画可能です
– オペレーターの方がアプリケーションをインストールしていない場合は、録画はされないがフローや受電でエラーになることはありません# 画面録画を実施するPCの設定
画面録画を実施するには、オペレーターの方のPCにアプリケーションをダウンロード・インストール方法を記載しています。
### 1. アプリケーションのダウンロード
A. 以下のリンクを
Amazon Bedrockモデル推論の解説
##はじめに
この記事では、Amazon Bedrockを使って生成AIモデルを簡単に活用する方法を解説します。
**前提知識**
生成AIは、大量のデータで学習された機械学習モデル(基盤モデル)によって実現されています。
– **基盤モデル**: データの種類によって様々な能力を持つモデルに分類されます。
– **大規模言語モデル(LLM)**: テキストデータを学習し、文章生成、要約、翻訳など様々なタスクをこなします。
– **画像生成モデル**: 画像データを学習し、テキストから画像を生成します。
– **プロンプト**: 基盤モデルへの入力テキストのことです。
– **推論**: 入力から出力を算出する処理のことです。
– **推論パラメーター**: 推論結果を調整するパラメーターです。例えば、テンプラーやトップP/Kは、出力のランダム性や多様性を調整します。**Amazon Bedrockによるモデル推論**
Amazon Bedrockは、サーバーレスで様々な基盤モデルを提供するサービスです。アプリケーションからAPIを通じてAmazon
AWS Lambda – Provisioned Concurrency設定時の振る舞い
AWS LambdaにProvisioned Concurrencyを設定した際、不可解な現象に遭遇したため、原因を調査した。
### 発生した現象
Provisioned Concurrencyを設定したLambda関数について、同時実行がないにも関わらず下記のような `Init Duration` を含むログが出力され、コールドスタートが発生してしているように見える。さらに `Init Duration` の数値がOn-Demand Concurrencyの場合に比べて大幅に増加している。
“`
REPORT RequestId: xxxx Duration: xx ms Billed Duration: xx ms Memory Size: xx MB Max Memory Used: xx MB Init Duration: xx ms
“`### 解析結果
* 結論としては、ログに `Init Duration` が出力されているが、実際にはコールドスタートは発生していない。
* Provisioned Concurrencyを設定した場合も定期的にインスタン
aws hands-on がすごく役立った件
## aws初心者の私は、これがとても役立ちました。
自分用メモです。### AWS ハンズオン資料
https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/AWS 初心者向けハンズオン
AWS 初心者向けに「AWS Hands-on for Beginners」と題し、初めて AWS を利用する方や、初めて対象のサービスを触る方向けに、操作手順の解説動画を見ながら自分のペースで進められるハンズオンをテーマごとにご用意しています。
CLFのOUTPUT
# コンピューティングリソースの最適化
## サイジングとは?
システムやサービスの規模に合わせてリソースを見積、適切な規模を決定することを指す。
### 主な特徴
– システムやサービスの要件に基づいて、必要なサーバー台数、ディスク容量、ネットワーク帯域などのリソースを見積もる作業
– システムの安定稼働の為に非常に重要な工程
– 新規システム構築の場合は、予想に基づいて見積もりを行う
### AWSでサイジングを特定できるAWSのサービスまたはツールは何か?
#### AWS Compute Optimizer
AWS Compute Optimizerは機械学習を利用してインスタンスの使用パターンを分析し、パフォーマンスとコストのバランスを最適化するためのインスタンスタイプやサイズの推奨事項を提供する
#### AWS Const Explorer
使用状況とコストのデータを視覚化し、インスタンスの最適化を支援するために推奨されるサイズの機会を提供
ゼロから始めるAIシステム開発 #01 「初歩の初歩」
## 自己紹介
ミナイと申します。
– 非エンジニア
– 工業系の高校と大学でプログラミング経験あり
– 進路は別ジャンルへ、20年ほどブランクあり
このほぼゼロの状態からAIシステム開発を勉強する過程を公開していこうと思います。## 1週目
– Amazon Bedrockについて調べる
そもそもAWSについて概念しか分かってないので単語レベルですべてが分からない。エンジニア語が出るたびにググる始末。寄り道に寄り道を重ねた末にAWSコンソールをチョットワカル程度になり、Stable Diffusion XLを体験。
– Stable Diffusion XLについて調べる
触りながら調べる。思い描いた構図で出力するのがかなり難しい。ガチャとはよく言ったもの。多少でも絵心があればi2iでやったほうが大幅に早そう。
### SDXL 設定について
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3885923/af13b765-95dd-546c-6661-da73ae7c1fbf.pn
個人開発サービス(Q)の技術構成
## 概要
2024年春から個人でサービス(Q)の開発を行っています。本ページではサービス(Q)に含まれる各アプリの技術構成を紹介します。*サービス自体は非公開としています。
## フロントエンド
– [ ] React
– シングルページアプリケーション(SPA)とするために採用しました。
– SPAの場合、フロントエンドとバックエンド(API)が分離できることが利点だと考えています。
– [ ] TypeScript
– JavaScriptとの比較で型付けを利点として採用しました。## バックエンド
– [ ] Spring Boot (REST)
– オーソドックスなフレームワークを採用したかったのでSpring Bootになりました。
– ただしRESTフレームワークとして使用しています。
– [ ] Java
– バックエンドには静的型付けのオブジェクト指向言語をと考えて採用しました。
– オーソドックスなバックエンド言語としての魅力も考慮しました。
– [ ] Postgres
– 汎用性、安定性を考慮して選択しました。
【Terraform】resourceとmoduleって何が違うの???
## 結論
去年はじめてTerraformを使ってからあまり違いを理解せずにいましたが、現在は
**`resource`はあるリソースを作成する、`module`は複数の`resource`を組み合わせてテンプレート化したもの**という感じで理解しました。`module`を使うと複数のリソースを簡単に作れるイメージです。以降では、30日後にglacier deep archiveへオブジェクトを移行するライフサイクルルールを持つS3バケットをTerraformで作る例をあげながら、`module`と`resource`の違いについて説明していこうと思います。
## resourceとは
resourceを使う場合、ライフサイクルルールを適用したS3を作成するには以下のようなコードになります。
“`terraform
# S3バケット作成
resource “aws_s3_bucket” “example_bucket” {
bucket = “example-bucket-123”
}# ライフサイクルルールの設定 (30日後にglacier deep archiveに
新卒エンジニアのyuuです!
## 初めまして!新卒エンジニアのyuuです
こんにちは!2024年に新卒としてIT業界に飛び込んだyuuと申します。現在、**AWSを用いたインフラ業務**に携わっており、エンジニアとしてのスキルを学んでいます!
### 取得資格
– **基本情報技術者**
– **AWS クラウドプラクティショナー**今のところはインフラをメインに業務を行っていますが、**フロントエンドやバックエンドの開発**にも興味があり、現在並行して学習を進めています。フルスタックエンジニアを目指して、技術の幅を広げていきたいと考えています!
### 取り組んでいる技術
– **AWS**
– **インフラ構築・運用**
– **Java**### 今後の目標
今後は、AWSを使ったインフラ業務に加えて、アプリケーションの**開発**にも挑戦し、インフラからアプリケーションまで一貫してサポートできるスキルを身に付けたいです。また、技術的な発見や学びをQiitaで積極的に共有していこうと思っています!### 最後に
エンジニアとしてはまだまだ未熟ですが、学びを続けてどんどん成長していきたいで
GPGキーとは?AWSサーバーでのMySQLインストール事例に基づく備忘録
### 概要
開発中にAWSのサーバーにMySQLをインストールする際、GPGキーの使用が必要になる場面がありました。GPGキーは、データの署名や暗号化に使われるもので、ソフトウェアのパッケージの信頼性を検証するためにも重要な役割を果たします。この記事では、その具体的な事例をもとに、GPGキーの使い方とその意義を簡潔に解説します。
### 1. なぜGPGキーが必要だったのか?
AWSのサーバーにMySQLをインストールする際、公式のMySQLリポジトリからパッケージをダウンロードしましたが、そのパッケージの信頼性を確認するために、GPGキーが必要になりました。多くの公式リポジトリは、パッケージが改ざんされていないことを証明するために、GPG署名を使います。
– **GPGキーの役割**:
パッケージが配布元の正当なものであるかを確認し、改ざんや不正なアクセスを防ぐために使われます。GPGキーを使用することで、セキュリティの高いインストールを保証できます。### 2. AWSサーバーでのMySQLインストール時の手順
### (1) GPGキーのインポート
MySQLを
サーバーのOSと開発環境でのフレームワーク等のバージョニングに関する備忘録
### 概要
サーバーのOSや開発環境で使用するフレームワークやライブラリのバージョン管理は、プロジェクトの安定性と互換性を保つために非常に重要です。今回の開発では、AWSのAmazon Linux 2を使用しており、PHP 8.2をインストールできない問題や、使用するライブラリのバージョン制限に直面しました。この記事では、こうしたバージョニングに関する注意点について備忘録としてまとめます。
### 1. 開発環境とサーバー環境のバージョン管理の重要性
開発環境とサーバー環境で異なるバージョンのOSやフレームワークを使用すると、依存関係の問題や互換性の問題が発生する可能性があります。特に、以下の点に注意が必要です:
– **PHPやNode.jsのバージョンの互換性**
– **使用するライブラリやフレームワークのサポート状況**
– **OSバージョンに依存するパッケージのインストール可否**### 2. Amazon Linux 2とPHPのバージョン互換性問題
今回のプロジェクトでは、AWSのAmazon Linux 2を使用していましたが、PHP 8.2のインスト
AWSロードバランサー設定で詰まったところ – ヘルスチェック設定に関する備忘録
### 概要
AWSのロードバランサー(ELB)を使用している際に、ヘルスチェックの設定で詰まった経験があります。ヘルスチェックは、ロードバランサーが正常なインスタンスを識別し、リクエストを効率的に振り分けるために必要不可欠な機能です。この記事では、ヘルスチェックの設定で直面した問題と解決方法について備忘録としてまとめます。
### 1. ヘルスチェックの役割
ヘルスチェックとは、ロードバランサーがバックエンドのインスタンス(EC2インスタンスやコンテナ)が正常に動作しているかを確認するための仕組みです。AWS ELBでは、ターゲットグループに属するインスタンスに対して定期的にリクエストを送り、その応答を基にインスタンスが正常かどうかを判断します。
– **正常なインスタンス**はリクエストを受け続け、不正なインスタンスはロードバランサーの対象から外されます。
### 2. 直面した問題
ヘルスチェックの設定で以下のような問題が発生しました:
1. **ヘルスチェックが頻繁に失敗する**
– 正常に稼働しているインスタンスにもかかわらず、ヘルスチェックが失敗し続け
ガバメントクラウドにおけるオンプレミスからAWSへの名前解決の指針について
# はじめに
オンプレミスからAWSのプライベートDNSを使用して名前解決したい、あるいは、オンプレミスからAWS PrivateLinkにアクセスしたいといった要件を実現するためにRoute 53 Resolverを利用するケースがあります。
AWS→オンプレミスも同様です。:::note info
## Route 53 Resolverとは
– VPC内にてデフォルトで存在する、フォワーダー機能を持つDNSサーバー
– Route 53 プライベートホストゾーンへ通信を転送![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/b1056a38-5823-ca24-ee36-1fe35d210f59.png)
### インバウンドエンドポイントの利用
– インバウンドエンドポイントを立てることで、エンドポイント経由でオンプレミスからRoute 53 Resolverにクエリ処理を送ることが可能
– つまり、オンプレミスからAWS上の名前解決が可能に!
### アウトバウ
AWS Client VPN のハンズオン
# はじめに
以下のハンズオンを実施した。https://catalog.us-east-1.prod.workshops.aws/workshops/be2b90c2-06a1-4ae6-84b3-c705049d2b6f/ja-JP
以下のAWSのドキュメントを踏まえて、実施内容を簡単に記載した。
https://docs.aws.amazon.com/ja_jp/vpn/latest/clientvpn-admin/cvpn-getting-started.html
# ステップ 1: サーバーおよびクライアント証明書とキーの生成
ハンズオンの以下の場所が該当する
https://catalog.us-east-1.prod.workshops.aws/workshops/be2b90c2-06a1-4ae6-84b3-c705049d2b6f/ja-JP/03-hands-on/03-01-common/04-certificate
easy-rsa で生成したファイルを ACM に取り込む。
“`
# find | grep -e crt -e ke
CloudShell で cfn-lint と cfn-nag を使う
使ってみたかったけど環境を準備するのが面倒だったので `CloudShell` で使えるようにする方法を調べました。
`CloudFormation` のテンプレートは `template` に格納しているとします。
“`bash:cfn-lint
pip install cfn-lint# バージョン確認
cfn-lint –version# 使い方
cfn-lint template/*
“`“`bash:cfn-nag
sudo dnf install -y ruby ruby-devel gcc
sudo gem update –system
sudo gem install cfn-nag# バージョン確認
cfn_nag –version# 使い方
cfn_nag_scan –input-path template
“`
Lambda関数でMySQLに接続する
AWSが提供しているライブラリには直接MySQLデータベースと接続する機能は含まれていないため、LambdaでRDSのMySQLに接続する場合、PyMySQLなどの外部ライブラリを使う必要がある。
## レイヤー追加
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3412108/f41bd875-cf0d-41bb-6c7f-74fa61612888.png)レイヤーソース:ARNを指定
パブリック公開されているレイヤーのARNを指定するhttps://github.com/keithrozario/Klayers/tree/master/deployments
ランタイムとレイヤーのPythonバージョンは合わせる
※バージョンが異なると、ライブラリのバイナリや依存関係が異なるため、互換性の問題が生じる可能性がある## lambdaコード
“`python
import pymysql
import osdef lambda_handler(event, con
【API Gateway】バイナリペイロードを適切に扱う
# はじめに
API Gatewayで扱うリクエスト、レスポンスに含まれるペイロードはテキストペイロードとバイナリペイロードに区分される。
| ペイロード | 説明 |
|:-:|:-:|
|テキスト|UTF-8エンコードされた JSON 文字列|
|バイナリ|テキストペイロード以外のペイロード|![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/7482c394-14ef-0951-549b-b77d379f76b4.png)
バイナリペイロードを扱うためには、Lambdaプロキシ統合の利用有無によって適切にAPI Gatewayを構成する必要がある。# Lambdaプロキシを利用する場合
必要な設定は以下の通りです。
– レスポンスのbase64エンコード
Lambdaプロキシの利用時にバイナリペイロードを処理するためには、Lambdaからのレスポンスをbase64でエンコードする必要がある。
– binaryMediaTypes
binaryMedi