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

S3 ライフサイクルルール作成

## はじめに
業務でS3のライフサイクルルールを作成する際、バージョニングとライフサイクルの挙動が分かりづらく、作成するのが大変でした。

バージョニング・ライフサイクルの概要・作成方法をまとめたので、記事に残したいと思います。

## バージョニング
### 概要
・ライフサイクルルールを作成するためには、S3バケットのバージョニングを有効にする必要がある。

・S3 バージョニングを使用すると、オブジェクトの複数のバージョンを１つのバケットに保持し、誤って削除・上書きされたオブジェクトを復元することができる。

・オブジェクトを削除した場合、オブジェクトを完全に削除する訳ではなく、オブジェクトに削除マーカーを挿入し、それが最新のオブジェクトバージョンになる。そのため、以前のバージョンを復元することができる。

・オブジェクトを上書きした場合、オブジェクトに新しいバージョンが追加される。以前のバージョンはバケットに残るが、最新のバージョンではなくなる。削除した場合と同様に、以前のバージョンは復元することができる。

https://docs.aws.amazon.com/ja_jp

氷河(Glacier)に眠っている写真たちをサルベージする 〜 その3 ボールドインベントリの登録

# 目的
AWS S3 Glacier内の各ボールドのボールドインベントリをMongoDBに登録する。

# やり方
* InitiateJobCommandを実行しボールドインベントリを要求する

https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/glacier/command/InitiateJobCommand/

* DescribeJobCommandを実行し進捗状況を取得する

https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/glacier/command/DescribeJobCommand/

* ボールドインベントリの取得が可能となったら、GetJobOutputCommandを実行しボールドインベントリを取得する

https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/glacier/command/GetJobOutputCommand/

# 事

【AWS】Step Functions redriveってどんな感じ？

## はじめに
もうだいぶ時間が経ってしまってますが、2023年11月頃にStep Functionsにredrive機能がリリースされました。
Step Functionsは、途中でエラーが起こってもエラーが起こった場所からリトライが出来ませんでした。そのため、長時間駆動が想定されるワークフロー処理には使い辛く、「Amazon Managed Workflows for Apache Airflow」の利用等検討していたと思います。
[Amazon Managed Workflows for Apache Airflow](https://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/what-is-mwaa.html)

この課題に対して途中からリトライできるredrive機能がリリースされました。

このredrive機能に関していくつか気になる点があったので、とりあえず使ってみて整理してみましたので、ご紹介させて頂きます。

※ 本ブログに記載した内容は個人の見解であり、所属する会社、組織とは全く関係ありません。

## リリー

CloudFormationによるAWSリソース作成時のエラーに対処してみた

# はじめに
こんにちは。すぎもんです:smile:

突然ですが、「Infrastructure as Code」という言葉を聞いたことがありますか？
OSやミドルウェアなどのITインフラいわゆる「Infrastructure」を「コード」化することです。

オンプレが主流だった頃のンフラ構築は専門部隊がそれなりに大きな工数をかけて対応していましたが、近年はそれらのインフラ構築自体をコード化し、自動で作成してくれるサービスが存在します。

[*AWS CloudFormation*](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/Welcome.html)　などがまさにそうですね。利用側としては、決められたパラメータを渡すことで各種インフラリソースを自動で作成してくれますし、何度実行しても同様に動くので、手動で各種インフラリソースを設定していくことに比べて、ミスなどは大幅に軽減されます。

企業のITシステムは、迅速かつ変化に対応しながら進められている昨今、より効率的にインフラ構築運用を開始

【AWS CDK】「CDKを用いたKMSマルチリージョンキー実装 ~APP分割での半自動化編~」

## はじめに
AWS KMSには、複数のリージョンで同じキーを利用できるマルチリージョンキーという機能があります。
[KMSマルチリージョンキー](https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/multi-region-keys-overview.html)

このマルチリージョンキーを利用する際は、ソースとなるマルチリージョンキーをDeployした後に、利用するリージョンにてレプリカキーをDeployする必要があります。
CDKを用いて実装する場合、Stackコードはリージョンに紐つくため、1Stackコードでは実装することは出来ず、ソースとなるマルチリージョンキーをDeployするStack、利用するリージョンにてレプリカキーをDeployするStackの2つに分割する必要があります。

この分割を1APP 2Stack構成では現状実現できません。
なぜ実現できないのかは、以下のリンクの記事にて紹介させて頂いておりますので、合わせてご確認ください。
[CDKを用いたKMSマルチリージョンキー実装](http

【AWS CDK】「CDKを用いたKMSマルチリージョンキー実装」

## はじめに
AWS KMSには、複数のリージョンで同じキーを利用できるマルチリージョンキーという機能があります。
[KMSマルチリージョンキー](https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/multi-region-keys-overview.html)

このマルチリージョンキーを利用する際は、ソースとなるマルチリージョンキーをDeployした後に、利用するリージョンにてレプリカキーをDeployする必要があります。
CDKを用いて実装する場合、Stackコードはリージョンに紐つくため、1Stackコードでは実装することは出来ず、ソースとなるマルチリージョンキーをDeployするStack、利用するリージョンにてレプリカキーをDeployするStackの2つに分割する必要があります。

この分割を1APP 2Stack構成で実施した際にちょっとした問題が発生したので、ご紹介させて頂きます。

問題の詳細は、本記事に記載しますが、結論としては、「リージョン毎にAPPを分割する」ことをお勧めします。
1APP

Amazon Verified PermissionsをAWS CLIで環境構築してみました

# 記事の概要

AWSにおける認可のサービスAmazon Verified Permissions（以下、Verified Permissions）が2023年6月にGAとなりました。
アプリケーションの認可機能の効率的な実現が期待できるサービスとのことで、実際にVerified Permissionsの環境を構築して機能を確認してみました。構築の手段にはWebコンソールではなくCLIを利用しています。

# Amazon Verified PermissionsとCedar言語とは

Amazon Verified Permissionsはアプリケーションのリソースに対するアクセス権限を管理するための仕組みです。
AWSで認可機能というとIAMもありますが、IAMはAWSサービスのリソースの認可、Verified Permissionsは自前のアプリケーション内のリソースの認可という住み分けになります。

Verified Permissionsの機能は、後述のCedarという言語を用いて定義されたポリシを用いてリソースへのアクセス許可、禁止を行うというものになっています。
V

AWS Redshift でEverything It’s you してみた！

DEA(AWS Certified Data Engineer – Associate 認定)の勉強を兼ね Redshift を触ろうと、そのメモです。
4つ目のAssociate認定試験として、2024年から新設されましたね。

https://aws.amazon.com/jp/certification/certified-data-engineer-associate/

https://aws.amazon.com/jp/blogs/news/aws-certification-retirements-and-launches/

個人的には、 AWS Certified Database – Specialty は残っても良かったと思うけど、

# Redshiftって？
フルマネージドのペタバイト級データウェアハウスサービスです。

https://aws.amazon.com/jp/redshift/

# 準備

とりあえず何かしらデータをということで、ChagGPTにお願いしました。

![image.png](https://qiita-image-store.

Amazon Bedrock+KendraのRAGでXのポストをベースにした自己分析は出来るのか

# はじめに
先日、勤務先での定例ミーティングの勉強会の担当の際に、
**Amazon Bedrock+Kendra**のRAGを利用して、
社内のドキュメントを生成AIを使って説明してもらう機能を作成しました。

自分の個人アカウントで作成したものでしたが、
Amazon Kendraは個人レベルでは非常に高価なサービスであり、
今現在利用している、無料利用枠でもう少し遊んでみようと考えました。

個人レベルで、ドキュメントの様な物を読み込ませて流用出来ないか？
と考えた際に、**自分のX(twitter)でのポストを食べさせて、**
**その内容を生成AIに説明してもらおう**と考えたのがきっかけです。

:::note
無料利用枠の間に全力で楽しまないと、もったいないと思ったのが本音です。
:::

# 構築図
シンプルなAmazon Bedrock+KendraでのRAGの構成になります。
今回はXのポストを読み込ませるので、
S3に出力した複数のjsonファイルを格納したバケットをターゲットとし、
Kendraのデータソースとして利用しています。

![qiita_2024

「Need to perform AWS calls for account…」エラーへの対応

## 背景
Proxy環境にてCDKを活用した開発を実施している最中に`cdk bootstrap`コマンドを
実行してCloudFormationで利⽤するデプロイ用途のS3バケットを作成する際に
下記のエラーが発生した。

“`
Need to perform AWS calls for account [AccountID], but no credentials have been configured
“`

## 実施したこと
まずは同様のエラーに対応していると思われた下記の記事を参考に、
「~/.aws/config」ファイルの形式を確認したものの、特に形式に問題はなかった。

https://qiita.com/tomokon/items/9aace52fc19e8904ab26

その後`cdk doctor`コマンドを実行して、作成したcdkプロジェクトに問題点がないかの
確認を実施したところ、その結果にも問題なかった。

なかなか目ぼしい対処方法が見つけられない中で、ふと実行環境がProxy環境下に
あることが気になり始めた。そこで、下記のコマンドを実行し

ルートアカウントのアクセスキーを発行するのが危険な理由

# はじめに
– クラウドプラクティショナーの資格勉強をしていると、APIキー（アクセスキーとシークレットキー）の管理に関する注意が出てきました。
– ルートアカウントで、発行するのがとても危険ということで、その意味が全く分からなかったので調べてみました。

## 具体的なアクセスキーの使い方
まずは、APIキーをどう使うのかを調べてみました。
– IAMグループで、ポリシーを付与(例えば、S3のフル権限とした場合)
– このグループにIAMユーザーを追加
– IAMユーザーに対して、アクセスキーとシークレットキーを発行
– つまり、このIAMユーザーはS3に対して、このキーを利用しS3を操作できる

## つまりアクセスキーとは何か
– IAMユーザーに対して発行される
– そのIAMユーザーが持つすべての権限を、このキーを用いて利用することができる

## ルートアカウントのAPIキーを発行するのが危険な理由

– これが良くないのは、すべての権限を持つIAMユーザーに対して、アクセスキーとシークレットキーを発行してしまった場合、このキーですべての操作が可能になってしまうという

AWS 生成AI×Data Catalog 新機能について :Amazon DataZone AI recommendations

## はじめに
[Amazon DataZone](https://aws.amazon.com/jp/datazone/#:~:text=Amazon%20DataZone%20%E3%81%A8%E3%81%AF%E4%BD%95,%E3%81%99%E3%82%8B%E3%83%87%E3%83%BC%E3%82%BF%E7%AE%A1%E7%90%86%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%A7%E3%81%99%E3%80%82) は、AWS、オンプレミス、およびサードパーティのソース全体に保存されているデータを迅速かつ簡単にカタログ化、発見、共有、管理できるようにするデータ管理サービスです。今回紹介する[Amazon DataZone AI recommendations](https://aws.amazon.com/jp/blogs/news/new-generative-ai-capabilities-for-amazon-datazone-to-further-simplify-data-cataloging-and-d

CloudFormation・OpsWorks・Elastic Beanstalkの違い

皆さん、こんにちは！　、ITエンジニアのSkyvixenです！
今回は、自己学習用のメモを以下に書いています。
もし活用できる部分があれば、読んでくださると嬉しいです！

## 1.CloudFormation
– AWSで環境を構築するときに、リソースの設定やプロビジョニングをコード化したテンプレートを作成できる。
＝他案件でも一部使える
– ほとんど全てのAWSのリソース構築や設定を行えるため、自由度が高いサービス。
– 環境のみ構築するため、その上に立てるアプリ・ツールは関係ない。

**メリット**
・インフラの管理や制御が簡単になる
・テンプレートができることで、同じ・似た構成の環境を素早く簡単に再現でき、開発期間を短縮できる
・CloudFormation自体は無料

**デメリット**
・テンプレートからスタックを作成・適用する必要があるため、修正に時間がかかる
・スタックの作成・削除を繰り返すと、AWSのリソース作成

【AWS】CFn用CI/CD環境の作り方(単一リポジトリに複数ファイルが存在する場合)

## はじめに

CloudFormation をデプロイする際にどのように実行していますか？
私は CloudShell にテンプレファイルを格納してデプロイすることが多いです。

ただ、以下参考記事に記載されているように、
テンプレートをバージョン管理する前提であれば、
リポジトリにあるテンプレートと AWS インフラを同期させるためにパイプラインからの実行が必要になります。

本記事は複数ファイルが格納されているリポジトリである前提の元、
更新した特定ファイルをパイプラインから CloudFormation デプロイするための手順を記載した内容になります。

■ 参考先

https://dev.classmethod.jp/articles/aws-all-iac/#toc-28

## 結論
以下2パターンの方法で、
複数ファイルが混在するリポジトリのファイル更新を検知することが可能になる。
– パターン①：CodePipeline*Codebuildを利用
– Codebuildを利用してリモートリポジトリの HEAD 情報の差分を取得。
更新有無を検知し特定ファイ

AmazonBedrock基盤モデルの利用状況を知ろう 【CloudWatchで監視編】

# はじめに
Amazon Bedrock 基盤モデルの利用状況を知る方法、2つ目の記事です。
前回はBedrock基盤モデルの過去の利用実績をログから分析する方法を紹介しました。
以下の記事で紹介しているのでよければご参考ください。

https://qiita.com/kanuazut/items/82d3d761e4bb8c6e3e03

今回は、リアルタイムの監視を行う方法として、CloudWatchを使ってリアルタイムの利用を監視し、大量リクエストがあった場合にEメールに通知する手順を確認します。
手順は非常に単純なので、CloudWatchを使ったことがある人は読む必要がないかもしれません。

# 手順
## メトリクスの確認
マネジメントコンソールからCloudWatchのページを開きます。
左メニューの「すべてのメトリクス」をクリック。
![2024-03-26-21-30-27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3115707/5f441e9e-a3b4-

太陽光発電で電気代がどれだけおトクになったか確認してみる

太陽光発電により毎月どれだけお得になったか、投資額をいつ回収できるかを確認できるようにしてみる。（やり方検討中、S3とDynamoDBは使いたいので使う予定）

【徹底比較】AWS・GCP・Azureの違い｜3大クラウドサービスの特徴や料金、シェア率、各AI系サービスを紹介

こんにちは。スキルアップAI編集部です。近年、クラウドサービスの導入を検討、活用している企業が増加しています。
その中でも3大クラウドサービスである[Amazon Web Service（AWS）](https://aws.amazon.com/jp/)、[Google Cloud（GCP）](https://cloud.google.com/?hl=ja)、[Microsoft Azure（Azure）](https://azure.microsoft.com/ja-jp/)について、**各サービスの概要、シェア率、特徴、タスク別のAI系サービスについて比較し、わかりやすく紹介**します。
またそれぞれのサービスの特徴を踏まえて、向いている企業やユーザについても紹介しているので、ぜひ参考にしてください。

<目次>
1. クラウドサービスとは
1. AWSの特徴
1. GCPの特徴
1. Azureの特徴
1. クラウドサービスを利用する3つのメリット
1. クラウドサービスを利用する3つのデメリット
1. AWS/GCP/AzureにおけるAI系サービスの比較
1. Azure/G