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

【Amazon Connect Customer Profiles】データソースの統合

### はじめに
Customer Profilesは、Amazon Connect（コールセンターサービス）で使用できる顧客情報の集約サービスです。例えば、顧客の電話番号や氏名、性別、過去の問い合わせ履歴などの情報を、顧客からの着信時に表示することができます。個人的にはAmazon ConnectのCRM（顧客関係管理）だと思っています。
本記事では顧客情報のデータソース統合について紹介します。

## 本記事の注意点

本記事では以下のように使い分けをしています。

– **Customer Profiles**：サービスの名称
– **顧客情報**：Customer Profilesに登録する顧客データ

### 統合できるデータソース

Customer Profilesは、さまざまなデータソースと統合することで、顧客情報を一元管理できます。主なデータソースは以下の通りです。

– **Amazon S3**
– **Salesforce**
– **ServiceNow**
– **Zendesk**
– **Marketo**
– **カスタムコネクタ**

#### 注

HeatlhEventの通知を一つのアカウントへ集約する

## 概要

– 複数のAWSアカウントで発生したHealthイベントを一つのアカウントで確認できるようにしたい
– 上記要件を実現するために、EventBridgeのクロスアカウント送受信を使用する
– **AWS Organizationを使用して複数アカウントを管理できる場合はもっと簡単に集約する方法がある**が、諸事情によりメンバーアカウントの中だけで集約する必要があったため、今回の対応を実施

## 構成

– 集約するイベントを受信するアカウントをアカウントA、イベントを送信するアカウントをアカウントBとする
– 各アカウントでイベントを補足したいリージョンすべてにEventBridgeルールを設定する
– 今回は東京リージョンとバージニア北部リージョンで構成
– イベントをユーザに通知する手段と

AWS Backupを使用してEC2インスタンスをリストアする際の権限不足エラーとその解決方法

### AWS Backupを使用してEC2インスタンスをリストアする際のエラー

AWS Backupを使用してEC2インスタンスをリストアする際に、次のようなエラーが発生することがあります。

“`
You are not authorized to perform this operation. Please consult the
permissions associated with your AWS Backup role(s), and refer to the
AWS Backup documentation for more details. xxxxxxxxxxxxxxxxxx~
“`

この記事では、このエラーの原因と解決方法について説明します。

### 原因

バックアップの復元時にAWS Backupが使用する

【Kubernetes】マニフェストファイルの読み方

## はじめに
Kubernetesのマニフェストファイルの内容がよくわからない、という方いらっしゃるではないでしょうか？
私もその一人です。

今回はマニフェストファイルの読み方について`yaml`コード内にコメントをつけて解説してきたいと思います。
補足説明はコード外にいたします。

## マニフェストファイルの解説

“`yaml
apiVersion: apps/v1 # KubernetesにはAPIバージョンがあるためそれを記述します。 ①
kind: Deployment # リソースの種類を記述します。 (Ingress, Serviceなど) DeploymentはReplicaSetを生成/管理し、ReplicaSetはPod(Podの数 = レプリカ数)を生成/管理します。
metadata: # その名の通りメタデータ、要するに「そのデータ(ここではDeployment)に関連する情報を記述したデータ」を記述します。
name: nginx-deployme

IAMユーザーに特定EC2の起動停止権限を付与する

## 概要
指定されたEC2の起動停止権限を付与するjsonと、思った事についてまとめます。
## なぜこのようなことが必要なのか？
起動停止させたいなら、AdministratorAccessでも付与したらいいじゃないか？
と思う人もいるでしょう。(自分も最初そう思いました)
ただ、AWS公式が提唱している[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html)には反してしまいます。
最小権限にしておかないと、ポリシーをアタッチしたユーザーが意図しない
操作をできてしまいインタンスの停止起動等ができてしまいます。
そのため、最小権限を付与し動作を縛ってあげる必要があります。
## 実際のコード
““
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“A

AWSのknowledgebaseで同期ができないときの対処法

## AWSのナレッジベースでRAGを作ろうとしたらソースの同期でエラーを吐いたので忘備録

– ナレッジベースを作成し、データソースの同期ボタンを押すと以下のエラーが出ました。

>Data sync failed. There is an ongoing ingestion job for this data source with ID 〇〇〇>〇〇〇〇〇〇〇. Retry your request after the ingestion job completes.

– AWSのOpensearch serviceのコレクションのページを確認したところ、こちらにもエラーメッセージが。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/233734

Intelligent-TieringでS3コスト削減に挑戦した話

# はじめに

S3バケットのコスト削減策として昨年末頃よりIntelligent-Tieringを導入し、経過観察を行ってきました。
本記事ではその過程について書きたいと思います。

# Intelligent-Tieringとは

BlackBelt「[Amazon Simple Storage Service (Amazon S3) コスト最適化編](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-S3-CostOptimization_0602_v1.pdf)」より引用します。


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

私たちの体内における鉄の重要性

私たちの体内における鉄の重要性
記事全文を読むにはここをクリックしてください
サイトリンク:-
https://educationplusxyz.blogspot.com/2024/10/Importance%20of%20iron%20in%20our%20body%20.html

VPC内部からAWSサービスへの通信をどのように設計するか？

# はじめに
VPC内部からAWSサービスへの通信っていろいろありますよね。
今回はどうやって通信するか、その特徴と選択肢を解説していきたいと思います。


# パターン
パターンとしては以下２つが考えられます。
１．VPCエンドポイント
２．IGW（NATGW利用）
それぞれの特徴を書いていきます。

## VPCエンドポイント

いわずもがな知られたパターンですが、IGWが存在せずとも、対応するサービスのVP

CloudFront ディストリビューションで使用しているOAIの確認

## やりたいこと
CloudFrontのディストリビューションで設定しているOAIを確認したい。
マネコンからでも確認はできるが、一つずつ設定を見るのは大変なので、スクリプトを作成しました。
## 実践

“`
export AWS_PROFILE=”your_profile”

aws cloudfront list-distributions \
–query “DistributionList.Items[*].{CF_ID:Id,OAI_ID:Origins.Items[*].S3OriginConfig.OriginAccessIdentity}”
“`
上記コマンドで、アカウント内のディストリビューションIDと、OAI_IDを値にもつ配列は出力できます。
ただちょっとこのままだと見づらいのと、OAIが複数のディストリビューションで使用されていないか確認したかったので以下スクリプトにします。

“`
export AWS_PROFILE=”your_profile”

aws cloudfront list-distributions \
–query “Dist

AWS: AWS入門(EC2編3) – 固定のIPv4アドレスを使用する

###### 実施環境

Microsoft Edge 124.0.2478.67 (64bit)

### 0. 概要

EC2 のインスタンスのパブリック IPv4 アドレスは、インスタンスを停止して再び起動すると変わってしまう場合があります。
個人利用であればそれでも問題ないかもしれませんが、 Web サーバーとして公開したい場合などは接続先が変わってしまうと困ることもあるでしょう。

そのような場合に対応できるように、 AWS には「 Elastic IP アドレス」というものがあります。
Elastic IP アドレスはパブリック IPv4 アドレスの一種ですが、通常のパブリック IPv4 アドレスと異なりアカウントに対して割り当てられ、勝手に変更されることはありません。
今回はこの「 Elastic IP アドレス」を用いて、 EC2 の Linux インスタンスに対し固定のパブリック IPv4 アドレスを関連付けてみます。

:::note info
Elastic IP アドレスはあくまで IP アドレスです。
Elastic IP アドレスを使えばドメイン名

Auth0をSAML IdPにしたAmazon Managed GrafanaをTerraformで構築する

# はじめに
Auth0活用記事第2弾。
第一弾では、AWSのマネージメントコンソールログインをSAML認証で行えるようにした。

https://qiita.com/neruneruo/items/14ff2e9d53eb9c082faa

今回は、Amazon Managed GrafanaへのログインをAuth0をIdPに設定して行えるようにする。

Amazon Managed Grafanaは、Grafanaをフルマネージド化した魅力的なサービスだが、GrafanaへのログインがAmazonのマネージメントコンソールログインとは分けられており、かつSAML認証が必要である。
AWSに閉じて利用しようとすると、Organizationsを前提としたIAM Identity Centerを設定しなければならず、お手軽には使いにくい。
おためしで使ったり、小さいチームで利用するユースケースとしては、Auth0等のIDaaSの機能を利用するのが良いだろう。

今回は、このAmazon Managed GrafanaとAuth0の連携部分についてTerraformで自動構築をしていく。

コマンドラインで始めるAWS：EBS・RDSのスナップショット取得手順

# コマンドラインで始めるAWS：EBS・RDSのスナップショット取得手順


## 目次

1. [はじめに](#はじめに)
2. [スナップショットとは](#スナップショットとは)
– [EBSスナップショット](#ebsスナップショット)
– [RDSスナップショット](#rdsスナップショット)
3. [AWS CloudShellの利用準備](#aws-cloudshellの利用準備)
– [1. AWS CloudShellの起動](#1-aws-cloudshellの起動)
– [2. 環境の確認](#2-環境の確認)
4. [EBSのスナップショット取得手順](#ebsのスナップショット取得手順)
– [1. EBSボリュームの確認](#1-ebsボリ

AWS KendraとBedrockを利用してRAGを実装して得た知見について

# はじめに
近年、生成系AI（Generative AI）や大規模言語モデル（LLM: Large Language Models）の活用が急速に進んでおり、様々なタスクでの有用性が注目されています。しかし、LLMは常に最新情報を持っているわけではなく、特に特定の企業内情報や最新のドキュメントに対する応答生成には限界があります。そこで注目されているのが、RAG（Retrieval-Augmented Generation, 検索拡張生成）と呼ばれる手法です。

RAGでは、テキスト生成をプライベートデータソースまたは独自のデータソースからの情報で補完して行います。
今回はRAGに関しては初心者の私が実装の際に参考としたサイトをまとめ、実装後の所感や最初から知っていれば良かったと感じた内容をまとめます。
※具体的なコードについて、基本的に本記事では記載しません。

# 前提事項について
### 1. LLMに入れるデータは学習に利用されないか
RAGは外部情報(独自データ)をLLMの入力とするため、個人的に最も気になっていた点でした。
こちらの点については、AWSのBedrockを利用

aws-auth ConfigMap から アクセスエントリへの移行

## はじめに
セルフマネージドAmazon Linuxノードを作成し、EKSクラスターに参加させる方法として、以下のAWS公式ドキュメントを参考にしていました。

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/launch-workers.html

手順内でノードを参加させるのに`aws-auth ConfigMap`を使用していますが、`aws-auth ConfigMap`は現在非推奨となっているようです。


https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/auth-configmap.html

`アクセスエントリ`を使用したノードの参加方法を記事に残しておきます。

## アクセスエントリとは
– EKS

技術検証: NLBでターゲットグループの自動切り替えをLambda関数で実現する手順

## はじめに
本記事では、AWSのNLB（Network Load Balancer）を利用して、ターゲットグループを自動で切り替える方法について解説します。

EC2インスタンスのヘルスチェック結果に基づき、正常時と障害時に応じてトラフィックの送信先を変更する設定を行います。

これにより、サービスの可用性を高めるとともに、自動化された障害対応が可能になります。

## 知識整理

:::note info
**まず、基本的な役割と機能を整理していきます。**
**ターゲットグループ:**
NLBがトラフィックを送信する先のリソースをまとめたグループです。通常、WebサーバーのEC2インスタンスが含まれます。

**Lambda関数:**
サーバーレスでコードを実行できるAWSのサービス。今回は、ターゲットグループを自動で切り替える処理をLambda関数で実装します。

**EventBridge(今回は、作成しない):**
AWSのイベントバスサービス。EC2インスタンスの状態変化（例: ヘルスチェック失敗）をトリガーにして、Lambda関数を起動するために利用します。
:::

Lamda→DynamoDBへ接続した際のエラー解決方法

今回は、同じリージョンにあるLamdaからDynamoDBへ接続し、データを挿入できたらゴールとなります。

その中で、LamdaからDynamoDBへの接続に手間取ったので解決方法を記載します。

– [開発環境](#開発環境)
– [使用していたコード](#使用していたコード)
– 発生したエラー
– [require→importへの変更](#require→importへの変更)
– [aws-sdkの使用](#aws-sdkの使用)
– [exportsの変更](#exportsの変更)
– [Lamda関数のIAMロールにDynamoDBへの適切なアクセス権限がアタッチされているか](#Lamda関数のIAMロールにDynamoDBへの適切なアクセス権限がアタッチされているか)

# 開発環境

– Lamda
– ランタイム：Node.js 18
– DynamoDB

# 使用していたコード

“`jsx
let doc = require(‘dynamodb-doc’);
let dynamo = new doc.DynamoDB(

[AWS]GithubActionsで terraform のCI/CDやってみた

# はじめに
「良いコードは良い筋肉から」、「筋肉は全てを解決する」って誰かが言ってました。
最近コードは全く書かなくなって、代わりに毎日パワポを書いているのですが、
どんなに筋トレ頑張ってもいいパワポはいっこうに書けるようになりません。

筋肉じゃパワポは書けないのかしら(´・ω・｀)
いや、筋肉が足りていないのか？？？

ということで、
前回かその前ぐらいに、 terraform を使った AWS 環境の構築をしました。

https://qiita.com/Ixy_194/items/ac9623434537e81b8618

今回は、 GithubActions を使って terraform の CI/CD をやってみようと思います。
# 今回のゴール
こんな感じの CI/CD フローを作成します。

流れとしてはこんな感じ。
1

AWS Certified Solutions Architect – Associateに合格しました

9月末にSAAを受験し合格したので、勉強法について公開します。

## 自己紹介
未経験で8月半ばに入社し、初めて取得した資格がSAAです(プラクティショナーは持っていません。)
AWSという言葉は知っていたけど、amazon？通販サイトのサービス？ぐらいの認識でした。

## 勉強法
以下3の柱を用意して勉強しました。
1. スキルビルダー
1. 生成AIに質問
1. 実際に動かしてみる

1つ目についてですが、AWSがスキルビルダーというものを用意しており
その中にプラクティショナー向けのものがあります。
[スキルビルダー](https://explore.skillbuilder.aws/learn/course/internal/view/elearning/1875/AWS-Cloud-Practitioner-Essentials-Japanese-%E6%97%A5%E6%9C%AC%E8%AA%9E%E5%AE%9F%E5%86%99%E7%89%88)

2つ目についてですが、ナレコムでは「ナレコムボット」という生成AIの
システムがありこちらを使ってわからない事を質

Amazon API GatewayとAWS Lambdaを組み合わせてみた

## はじめに
こんにちは。
今回はAPI Gateway、Lambda、Translateを連携させてみました。

本記事は以下記事の続編です。

https://qiita.com/uccy/items/33ffdcc855e54e1ba1fe

↓参考にしたハンズオンはこちら。

https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-Serverless-1-2022-confirmation_422.html

↓今回のゴール

## やってみた
マネジメントコンソールにアクセスし、API Gatewayのページにアクセスします。
前回作成したtranslate-apiをクリックします。
![image.png](https://qiita-image-stor