AWS関連のことを調べてみた

Amazon Linux 2023

# AWS Linux 3世代
AWSが独自に提供しているLinux OSが３世代あります。
1. Amazon Linux 1 (2023年 EOL)
2. Amazon Linux 2 (2025年 EOL)
3. Amazon Linux 2023 (latest)
:sun_with_face: 「Amazon Linux 3」のような単純な名称にならず良かった
:thunder_cloud_rain:「Amazon Linux 2」と「Amazon Linux 2023」がどちらが最新かな？と最初は疑問があった。

# Amazon Linux 2023
ベースとなるOSがRedHatからFedoraへ変更したため、パッケージ管理ツールもyumからdnfへ変更になりました。
しかし、yumコマンドはそのまま使えます。dnfへのポイントとして生きています。

[Package management tool][ref0]

[ref0]: https://docs.aws.amazon.com/linux/al2023/ug/package-management.html

こ

AWS CDKでS3,VPC,EC2等を構築する

# CDKに慣れるために
前の記事でLambdaの構築を行うことができたので今度はS3,VPC,EC2などを立ち上げていきます。
EC2の構築にはVPC周辺の設定が必須なので勉強になりそうです。

# コーディング
構築したいリソースについて記載方法を調べていきます。

lib/○○.ts
“`ts
import * as cdk from ‘aws-cdk-lib’;
import * as ec2 from ‘aws-cdk-lib/aws-ec2’;
import * as s3 from ‘aws-cdk-lib/aws-s3’;

export class MyArchitectureStack extends cdk.Stack {
constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
super(scope, id, props);

// VPCの作成
const vpc = new ec2.Vpc(this, ‘MyVpc’, {
maxAzs: 2

アレ、Amazon Linux 2023がログを吐かない。。。

#はじめに
某ベンダで、クラウドの人材育成企画と研修トレーニングのデリバリを担当しています。
先日、研修準備のためラボ環境を評価していたのですが、Amazon Linux 2023がシステムログを出力しないトラブルに遭遇。ちょっと焦る事態に発展しちゃいました。

結論から言うと、Ammazon Linux2から仕様変更に伴い、ログの出力が変わったんですね。
Amazon Linux 2023のユーザーガイドの情報はこちら。

>systemd ジャーナルの置き換え rsyslog
>https://docs.aws.amazon.com/ja_jp/linux/al2023/ug/journald.html

Red Hat Enterprise Linuxはどうなんだっけ？と思い調べるとRHEL7からjournaldが導入済み、現状のバージョンは9なので、数年前から変更されてたんですね、、、知りませんでした。
Red Hat Enterprise Linux 7の情報はこちら。

>第23章 ログファイルの表示と管理
ログファイルは、systemd のコンポーネントである journ

AWS Bottlerocketをワーカーノードとして利用するEKS環境で FSx for NetApp ONTAP環境のNFSボリューム利用がサポートされたので試してみた

NetApp Trident 24.06で AWS BottlerocketでNFS volumeの利用が[サポート](https://www.netapp.com/blog/netapp-astra-trident-supports-more-cloud-workloads/
)されました。

AWS Bottlerocket はコンテナに最適化された安全なワーカーノードとして利用でき、必要なパッケージのみを導入することでセキュリティ向上や、リソース使用率を改善して管理オーバーヘッドを削減するなどのメリットがあるかと思います。

そのBottlerocketをワーカーノードとして利用するEKSの環境下でのストレージプラットフォームとしてFSx for NetApp ONTAPを利用できるようになったとのことなので、とりあえず実際に試してみました。せっかくなのでその手順を紹介したいと思います。

## 前提
以下の環境で試しています。

– Amazon EKS 1.30
– eksctl 0.194.0
– Trident 24.06

## やってみること
Bottlero

AWS LambdaでOpenAIのライブラリを使おうとして「No module named ‘jiter.jiter’」のエラー

## 環境
– AWS Lambda
– Python 3.12

## 先に解決策
openaiのバージョンをopenaiのバージョンを下げる(1.39.0にしたらエラーにならなかった)

## 何が起こったか
案件でAWS Lambdaを使ってChatGPTに投げたいということがあった。それこそchatGPTやQiitaを見ながら環境構築していきました。
– [AWS Lambda(Python)からOpenAIのGPT4のAPIを呼び出してみた](https://qiita.com/nabata/items/903a2ebff8e44516598e)

そこではじめは`Unable to import module ‘lambda_function’: No module named ‘pydantic_core._pydantic_core`というエラーになったのですが、これは解決策が載っていたので特に問題なく。
– [AWS Lambda Layers + OpenAI でつまづいた件](https://zenn.dev/galapagos/articles/a222e38a

LambdaとS3間の再帰ループ検出の検証

# はじめに
株式会社ジールの @oreo_tです。
2024/10/9のアップデートで、AWSのLambdaとS3間の再起ループの検出と自動停止ができるようになりましたので紹介しようと思います。

今回の更新情報

https://aws.amazon.com/about-aws/whats-new/2024/10/aws-lambda-detects-stops-recursive-loops-lambda-s3/

Lambdaの再起ループ検出について

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/invocation-recursion.html

この機能は、Lambda関数が再帰的に呼び出されることで意図せず延々と動作し、莫大なコストがかかってしまうという事故を防ぐための措置で、デフォルトで有効化されています。
Lambda関数の設定で機能のオンオフの切り替えができますが、ループ処理を16回検知したら停止する、という閾値は変更できず固定になります。
SQS、Lambda、SNS間での再起ループ検出、自動停止は去年の7

ゼロから始めるAIシステム開発 #05 「プロンプトエンジニアリング」

## 入門書3章「生成AIアプリ開発手法」
たびたび同じ画像で申し訳ないですが、こちらの入門書の第3章へ。今回は前半。
**Amazon Bedrock 生成AIアプリ開発入門 ［AWS深掘りガイド］**
https://amzn.asia/d/co7MB5S

## プロンプトとは
生成AIモデルとのやり取りに使用する文字列のこと。以下の3種類がある。
### システムプロンプト
AIの口調や役割など、システムとして指定しておきたいことを記述するプロンプト。2章で実践したSDKによるAPI呼び出しを使用する。一つだけ指定可能。
### ユーザープロンプト
AIの利用者が入力する部分。
### アシスタントプロンプト
AIの出力結果。
## トークンとは
AIの内部で処理する文字列の単位のこと。トークン数によって生成AIの利用料金が決まる

【コスト削減したい方必見】簡単かつ汎用的にAWSリソースを止める方法 ～AWS100本ノック～ 11/100

# はじめに


みなさんコスト削減してますか？

AWSを構築する上で、出来るだけコスト削減したいっていうのはみなさんよく感じることだと思います。
開発環境でも意外とお金かかりますよね…(ぼそっ)

しかし、平日の夜間や土日は使わないのに、EC2やRDSをずっと動かしっぱなしの方も、結構いるんじゃないでしょうか？
そこで今回は`不要な時間に停止し、必要な時間に起動する複数のアカウントで使いまわせる方法`をご紹介します。

いきなり結論になりますが、最終形は以下になります。

![学ぶべきこと-不要な時間停止-最終形.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/87924/013a7c2a-8b69-fb91-d63a-e562

CAP定理の整理とAWSリソースの対応関係

# CAP定理とは

まずここでは理論的なCAP定理の説明をします。

CAP定理とは、

**分散システムにおいて、ネットワーク分断が発生した場合、「一貫性」、「可用性」、「分断耐性」の3つの特性のうち、同時に2つまでしか完全には満たすことができない**

というものです。

# CAP定理の3つの特性

CAP定理は以下の3つの特性からなります。

1. 一貫性
2. 可用性
3. 分断耐性

それぞれについて簡単に説明します。

## 一貫性(Consistency)

「一貫性」とは「すべてのノードで同じ最新のデータが取得できること」を指します。

クライアントが任意のノードにリクエストを送ったときに、常に最新のデータを返すことが保障されているというのが「一貫性」になります。

つまり、システムに更新が行われた場合、その結果がすべてのノードで即座に反映され、どのノードからも同じ結果を取得できることを意味します。

例えば、ネットワークが分断されているときに、最新ではないデータを返すとこれは「一貫性がない」状態になります。

## 可用性(Availability)

「可用性」

ローカルでRails環境を構築し、DockerイメージにしてECRへアップロードする

### 1.ローカルでRailsのインストールとプロジェクトの作成
1.Railsのインストール
“`
gem install rails
“`

2.新規Railsプロジェクトの作成
“`
rails new hello_world –skip-active-record –skip-test –skip-bundle
“`
・–skip-active-recordでデータベース関連の設定をスキップ
・–skip-testでテストフレームワークをスキップ
・–skip-bundleでbundle installの設定をスキップ

3.プロジェクトディレクトリに移動
“`
cd hello_world_rails
“`

4.Gemfileの依存関係をインストール
“`
bundle install
“`

5.トップページに”Hello World!!”を表示するルートを定義
“`config/routes.rb
Rails.application.routes.draw do
root to: ‘application#hello’
end
“`

東大の「コードで学ぶAWS入門」を読んで理解したことのまとめ＃２

## 第２章の「クラウド概論」を理解する＃２
#### 「クラウド」が提供する３つのサービス形態
前回はクラウドについて大まかなイメージを理解したので、今回はクラウドが提供する３つのサービス形態の理会を深めていく。

##### Software as a Service (SaaS)
まずソフトウェアとは、「パソコンやスマホに入っているアプリ」をイメージするとわかりやすい。アプリにも色々あって、たとえば一度Apple Storeからダウンロードすればインターネットが繋がってなくても使える電卓アプリ、アラームアプリなどもあれば、パズドラやモンストなど、インターネットを介して新しいイベントが配布されたり、他のプレイヤーと対戦できたりできるものもある。SaaSとは クラウド上で実行されるアプリケーションをサービスとしてユーザーに提供する形態らしく、これだけを聞くとパズドラとモンストはSaaSにカテゴライズされそうだか、ChatGPTによると、それは違うらしく、どうやらこの 「クラウド上で実行される」<

元記事を表示

LambdaのログをCloudWatchLogsからS3へ転送してAthenaでキレイに参照したかった

前回の続き的なもの

前回はECSにあるログをAthenaから参照することを目的にした内容でしたが、
今回はLambdaから出力されるログもAthenaから参照することを目的にしています。

## 目的（背景）
1. Lambdaのログも可能な限りリアルタイムで参照したい
2. AthenaのテーブルをECSからのログとLambdaのログで分けることはしたくない
3. ロググループは一つではなく多数
4. ロググループ自体に入っているログの量の合計は月あたり1GBにも満たない

## 構成図


## 処理詳細

目的（背景）にも書いてあるように、ログの容量自体そこまで多くないためDataFirehoseを使ってます。
CloudWatchLogsのサブスクリプションフィルターからパターンにログレベルを指定（NOTICE WARN ERRO

元記事を表示

【月々のクラウド費用が激減！】絶対に押さえておきたいAWSコスト削減術5選

## はじめに
こんばんは、uiroleです！
今日はAWSユーザーなら、誰もが気にするであろうコスト削減術についてまとめてみました。

### 【記事の対象者】

この記事は、次のような方を対象としています。
– AWSを導入したばかりで、コスト最適化の方法がわからない初学者
– 毎月のAWS費用が高く、コスト削減を検討している人

### 【前提】

この記事では、以下の前提をもとに進めていきます。

– AWSの基本サービス（EC2、S3、RDS、Lambdaなど）の利用経験がある
– CloudWatchなどのAWSモニタリングツールをある程度理解している

### 【この記事を読んで解決すること】

– 無駄なリソースを削減し、効果的なAWSリソースの運用方法を知る
– コスト最適化に役立つ具体的な手法やAWSの機能について学べる
– 継続的にAWSコストを管理・削減するための戦略を理解する

## 1. インスタンスのサイズと種類を最適化する

AWSのEC2インスタンスは、用途や負荷に応じてさまざまなサイズと種類があります。コストを抑えるために、以下のポイントを意識して

元記事を表示

AWSコンソール初心者必見！不要なAMIとスナップショットを安全に削除する方法

# AWSコンソール初心者必見！不要なAMIとスナップショットを安全に削除する方法

## 目次

1. [はじめに](#はじめに)
2. [不要なAMIとスナップショットがもたらす影響](#不要なamiとスナップショットがもたらす影響)
– 2.1 [コストの増加](#コストの増加)
– 2.2 [リソース管理の煩雑化](#リソース管理の煩雑化)
– 2.3 [セキュリティリスク](#セキュリティリスク)
3. [AWSコンソールでの削除準備](#awsコンソールでの削除準備)
– 3.1 [必要な権限の確認](#必要な権限の確認)
– 3.2 [削除対象の特定](#削除対象の特定)
– 3.3 [バックアップの取得](#バックアップの取得)
4. [AMIの削除ステップバイステップ](#amiの削除ステップバイステップ)
– 4.1 [AMI一覧の確認](#ami一覧の確認)
– 4.2 [AMIの詳細情報の確認](#amiの詳細情報の確認)
– 4.3 [AMIの削除手順](#amiの削除手順)
5. [スナップショットの削除

元記事を表示

Amazon Bedrock Knowledge base deletion error

BedrockのKnowledge baseを削除する時，先に依存サービスを削除すると，Knowledge baseの削除に失敗します。
その対応法です。

# 1.現象


こんな感じでdeleteに失敗しています。

# 2.対応

Knowledge baseのリンクをクリック。


Data sourceのリンクをクリック。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2059/57530443-7000

元記事を表示

【Amazon ECS】コンソール以外でタスクの停止理由を確認する方法

ECSを利用していると、タスクが何らかの理由で起動に失敗したり、停止してしまうことがごくたまにあります。
その場合、AWSコンソール上で停止理由を確認できますが、タスクが停止してから1時間以上経過してしまうとその情報がコンソールから見えなくなってしまいます。

こんな感じで何も表示されなくなる↓

しかし、その状態でも諦めなくて大丈夫です。
タスクの停止理由を確認する方法が3つあります。

## 1.CLIを利用する

まず、停止したタスクIDを取得します。
“`
$ aws ecs list-tasks –cluster –desired-status STOPPED
“`

取得したタスクIDを使って以下のコマンドを実行
“`
$ aws ecs

元記事を表示

Amazon RDS for Db2とのQレプリケーション

# Amazon RDS for Db2とのQレプリケーション
2023年11月より、Db2もAWSのマネージド・サービスとして提供開始されています。

このRDS for Db2とのQレプリケーションのセットアップに関する文書が出たため、それに沿って実際にレプリケーションを動かしてみました。

– [QRep Setup Between Db2 On-Prem and AWS RDS for Db2](https://community.ibm.com/community/user/dataops/viewdocument/qrep-setup-between-db2-on-prem-and?CommunityKey=3bfc9f2f-4a5e-470a-9295-4b7cc90c9518&tab=librarydocuments)

この中では以下の５パターンが示されていますが、今回は2.のパターンを行いました。
1. ソース：RDS for Db2、ターゲット：Db2 LUWオンプレ
2. ソース：Db2 LUWオンプレ、ターゲット：RDS for Db2
3. ソー

元記事を表示

aws cloudwatch logsinsights　ログ確認クエリ(kosekiメモNO6)

# はじめに

aws cloudWatchのログインサイト、よくクエリを実行してシステムログを確認するので、
クエリのテンプレートをメモしておきます。

# 動作環境
aws cloudwatchアクセスできるユーザー。

# 使い方
fields、filter、parseなどのコマンドは参考文献から確認できます。

“`logsinsights.log
fields @message
| filter @logStream like /testtesttest001/
| parse @message ‘”message”:”*”‘ as logMessage
| fileter logMessage like /test01/ and logMessage not like /test02/
| display logMessage
| sort @timestamp desc
#| limit 2000
“`

# 参考文献
[CloudWatch Logs Insights クエリ構文](https://docs.aws.amazon.com/ja_jp/Amazon

元記事を表示

【ほぼ自分用】RDSのAutoScallingをクラスターDBに紐づくリードレプリカのいづれか一つがCPU使用率の閾値を超えた場合に発動させるLambda

# 目次
[1.はじめに](#1-はじめに)
[2.前提条件](#2-前提条件)
[3.実装内容について](#3-実装内容について)
[4.Lambda関数の中身](#4-Lambda関数の中身)
[5.まとめ](#5-まとめ)

# 1. はじめに
AWSコンソール上ではクラスター全体のCPU使用率の平均値がトリガーのAutoScallingとなってしまうため、CLIで設定できるクラスターに紐づいたリードレプリカ各々のCPU使用率をトリガーとしてAutoScallingさせたい旨で開発しました。
この要件実装したいよって人が他にも現れたら役に立てばなと

# 2. 前提条件
前提条件として、Lambda関数実行用のIAMロールが必要です。
RDS制御系のポリシーとCloudwatchにログを出力するための許可ポリシーあたりをアタッチしておけば問題ありません。
今回は、手っ取り早く以下二つを使用しました。
・AmazonRDSFullAccess
・CloudWatchFullAccess

# 3. 実装内容について

Lambdaで実装します。
ランタイムはpython3.12を使

元記事を表示

ecsからrdsにrds proxyを挟まずに直接接続する際のssl/tls証明書について

通常はrds proxyを介してRDSに接続を行っていたが、今回はrds proxyを介さずに直接RDSに接続を行った。

その際に、
“`
failed to initialize database, got error tls: failed to verify certificate: x509: certificate signed by unknown authority
“`
が発生した。

これを解決するために以下公式ドキュメントを参照して証明書バンドルをインストールした。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html

自身のリージョンによる証明書のバンドルをダウンロードし、作業ディレクトリに配置する。

CA証明書を読み込み、カスタムTLS設定に登録を行う。

“`Go
import (
“crypto/tls”
“crypto/x509”
“fmt”
“io/ioutil”
“log”

“sample/domain”
“

元記事を表示