- 1. AXIOSでヘッダーに認証情報をつける処理でエラーが出た話
- 2. Amazon RDSとAmazon Auroraの耐障害性を考える
- 3. サーバーレスはなぜ人気なのか
- 4. DynamoDBとAmazon RDSの料金体系
- 5. AWSのクレジット適応ができるサービスの確認の仕方
- 6. re:Invent 2023 旅行記 Part1
- 7. SeleniumをAWS Lambdaでサーバーレスに動かしてみる
- 8. AWS EC2に負荷ツールTaurusをインストールする
- 9. 【AWS】S3に必要なファイルが全てアップロードされたことを確認してステートマシンを動かす実装例【Lambda】
- 10. AWS CDK for Goを使用して、Go言語で書かれたLambda関数を定期実行する
- 11. 【AWS】Amazon CloudWatchの詳細モニタリングのメトリクスをCLIで取る(Elastic Beanstalk編)
- 12. KendraとBedrockによるRAG実装を誤解していた話
- 13. Glue DataQualityをAWS CLIで作成や実行してみる
- 14. CloudFormation yaml構文エラー
- 15. AWS lambdaの新機能
- 16. Security Hub におけるセキュリティ基準のコントロール一覧を一回で全部出力するスクリプトを作った
- 17. Amazon Route53の耐障害性を考える
- 18. Amazon Bedrockの新機能アップデート予想!(AWS re:Invent 2023)
- 19. Step Functionsでフィールド名にスペースが入っている場合の表記
- 20. Amazon EKS on サービスアカウントの IAMロール
AXIOSでヘッダーに認証情報をつける処理でエラーが出た話
### はじめに
本記事ではCORSエラーが出てから解消するまで流れを記述しています。
以下のアーキテクチャ図で取得したデータをフロント側で表示、制御をしています。
今回はフロント側からAPIを叩く際にCORSエラーがでて苦戦したのでその部分について書いています。APIでの認証にAPIキーを使用しています。
基本的にはAPIキーを使用するべきではありませんが、今回は検証用で一時的に利用するものなので使用しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3524923/4b8b369f-1256-fa93-981a-3efa6ef2c6b5.png)### API Gatewayの設定
以下のレスポンスヘッダーに’*’を使用して全てのオリジンからのアクセスを許可をしています。
Access-Control-Allow-Headers
Access-Control-Allow-Methods
Access-Control-Allow-Origin### エラーが出た時
Amazon RDSとAmazon Auroraの耐障害性を考える
# はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧は[こちら](https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2)。この記事ではRDSとAuroraを耐障害性の観点から超詳細解説しています。
具体的には以下流れで説明します。
– Amazon RDSとは
– Amazon RDSのスケーラビリティ
– Amazon RDSのディザスタリカバリ
– Amazon Auroraとは
– Amazon Auroraのスケーラビリティ
– Amazon AuroraのディザスタリカバリAWSの区分でいう「Level 200:トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。
# この記事を読んでほしい人
– RDSとAuroraを採用するときのベストプラクティスを説明できるようになりたい人
– RDSとAuroraの耐障害性に不安を感じている人
– AWS Certified DevOps Engineer
サーバーレスはなぜ人気なのか
サーバーレスアーキテクチャが近年人気を集めているのには、いくつかの大きな理由があります。
## 管理の簡素化
サーバーレスは、サーバーやOS、ミドルウェアなどの提供や管理をクラウド提供事業者が行うため、開発者はコードの作成に集中できます。
これにより、アプリケーションの開発とデプロイのプロセスが簡素化されます## 課金方式の柔軟性
サーバーレスは利用単位で課金され、処理のリクエスト数と実行時間に応じて料金が決まります。
これにより、サービスの利用頻度に応じてコストを削減できる可能性があります## スケーラビリティ
サーバーレスアーキテクチャは需要に応じて自動的にリソースがスケールするため、トラフィックの急増にも迅速に対応できます
## 用途の多様性
サーバーレスは動的なWebサイトやモバイルアプリのバックエンド、簡単なデータ処理、新規サービスのスタートアップ、マイクロサービスアーキテクチャの実現など、さまざまな用途に適用可能です
## 注意点
ただし、サーバーレス単体ではプログラムの実行しかできず、データベースやストレージなどの他のサービスとの組み合わせが必
DynamoDBとAmazon RDSの料金体系
2023/11/27時点
## DynamoDBの料金体系
DynamoDBの料金は、データの読み込み、書き込み、およびストレージの使用量に基づいて計算されます。
読み取りには4KBごと、書き込みには1KBごとに単位が計算されます。
また、使用するGSI(Global Secondary Index)によっても料金が変わることがあります。DynamoDBには以下の2つの料金体系があります1. **オンデマンド容量モード**: アプリケーションのトラフィックに基づいて料金が計算されます。データベースのトラフィックが予測不可能な場合や、使用した分だけを支払いたい場合に適しています。
2. **プロビジョンド容量モード**: ユーザーが秒間の読み書きの量を指定する必要があります。トラフィックが予測可能で一定の場合に適しています。
https://aws.amazon.com/jp/dynamodb/pricing/#How_to_calculate_costs
## Amazon RDSの料金体系
Amazon RDSの料金は、使用するデータベースインスタンスごとに月額が課金
AWSのクレジット適応ができるサービスの確認の仕方
## はじめに
ありがたいことに、AWSのクレジットを頂ける機会があるかと思います。
ですが、対象サービスが何かわからない方もいらっしゃるかと思うので、対象サービスの確認方法を記載します。## AWSの公式ドキュメント(法務関連)からの確認
私が冒頭に記載したクレジットとは、販促クレジット(AWS Promotional Credit)を指します。
[こちら](https://d1.awsstatic.com/legal/termsandconditions/AWS_Promotional_Credit_Terms_and_Conditions_2021-06-01_Japanese.pdf)に詳細が書かれております。>販促クレジットは、お客様が該当する販促クレジットコードをご自身の AWS アカウントに適用した請求期間中、またはそれ以降に発生した料金および代金であってお客様の AWS 契約事業体により指定された特定のサービス(総称して「対象サービス」)についてのみ使用することができます。販促クレジットは、Amazon Mechanical Turk、AWS マネージドサービス
re:Invent 2023 旅行記 Part1
# re:Invent2023 旅行記 Part1
この記事では、英語を喋れないSEが初めてre:Inventに参加する様子を記載します。re:Invent行ってみたいけどどんな感じか分からない、英語喋れない、アメリカ怖い…と感じてる筆者の様な方の助けになれば幸いです。
因みに、筆者はre:Inventだけでなく、アメリカも初めてです。そういった部分も含め記載していくので、暖かい目で見て頂ければと思います🙇
## 申し込み
筆者は近畿日本ツーリストさんが主催する[AWS re:Invent 2023 Japan Tour](https://knt.reinventjapantour.com/)を申し込みました。re:Invent2023の申込者数約38,000人に対して、日本人が約1,600名いるようなのですが、1,600名の内600名の方がこのツアー申し込んでいるようです。因みに、このツアーには以下が含まれています。
– 往復の飛行機
– ホテル
– 空港とホテルの往復バス一方で、re:Inventのチケットは含まれていなきので、ツアーとは別に自分でre:Invent
SeleniumをAWS Lambdaでサーバーレスに動かしてみる
# SeleniumをAWS Lambdaでサーバーレスに動かしてみる
## TL;DR
APIが提供されていないなどの理由で、Seleniumを使ってWebサービスを操作する際に、サーバーレスで実行できると便利ですが、AWS Lambdaで実行するためには依存モジュールなどの調整が必要です。このあたりの面倒な作業については、有難いことに以下のリポジトリで開発されています。
* [docker-selenium-lambda](https://github.com/umihico/docker-selenium-lambda)
SeleniumをAWS Lambdaで動かすためのDockerコンテナが定義されており、SeleniumをHeadlessで動かすためのコードサンプルも付いています。基本的にそのまま利用できますが、実行例がServerless Frameworkになっているので、AWS CDKでの実行例を作ってみました。
## フォルダ構成
“`
📦src
┣ 📂app
┃ ┣ 📜Dockerfile
┃ ┣ 📜app.py
┃ ┗ 📜requirem
AWS EC2に負荷ツールTaurusをインストールする
# やりたいこと
AWS DTLではjmeterしか使えず、taurusファイルで実行したかったのでEC2にいれてみて試してみました
https://gettaurus.org/
# やりかた
debian系ではこれなので“`bash
sudo apt-get install python3 default-jre-headless python3-tk python3-pip python3-dev libxml2-dev libxslt-dev zlib1g-dev net-tools
sudo python3 -m pip install bzt
“`yumでのインストールにそれぞれ変える
“`bash
sudo yum update -y
sudo yum install python3 gcc python3-devel java-17-amazon-corretto tk-devel python3-pip net-tools libxml2-devel libxslt-devel zlib-devel -y
sudo python3 -m pip i
【AWS】S3に必要なファイルが全てアップロードされたことを確認してステートマシンを動かす実装例【Lambda】
## 初めに
前回の記事ではS3にファイルがアップロードされたことを契機にEventBridge経由でステートマシンを実行する方法を投稿した。
しかしステートマシンを動かすために必要なファイルが複数ある場合、S3のファイルアップロード契機だけだと1ファイルごとにステートマシンが実行されてしまい、不必要な実行がされてしまったり、誤った結果が保存されてしまう危険がある。
そのため、今回の記事ではステートマシンが必要とするS3のファイルが複数の場合で、それら全てのファイルが処理実行日に作成されたものか(昨日作成されたものをステートマシンで処理しようとしていないかどうか)を確認した後でステートマシンを実行する実装例を記載した。
※前回の記事
https://qiita.com/Nana_777/items/8dc23b9fc331ba7a7905## 使うAWSサービス
・Amazon EventBridge
・Amazon S3
・AWS Lambda
・AWS StepFunctions## アーキテクチャ図
![S3イベントplusLambda.png](https://qiit
AWS CDK for Goを使用して、Go言語で書かれたLambda関数を定期実行する
## はじめに
AWS CDK(Cloud Development Kit)は、クラウドリソースをコードで定義し、デプロイするためのオープンソースのソフトウェア開発フレームワークです。この記事では、AWS CDK for Goを使用してGo言語で書かれたLambda関数を定期的に実行するスケジュールを設定する方法を説明します。
## 前提条件
– AWSアカウントがすでに設定されていること。
– AWS CDKを操作するCLIがインストールされていること。CDKのCLIのインストールについては[こちら](https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/cli.html)をご覧ください
## 環境
– Go 1.20
## プロジェクトの初期化
新しいディレクトリを作成し、その中に移動します。
“`bash
mkdir go-lambda-cdk
cd go-lambda-cdk
“`以下のコマンドを実行して新しいCDKプロジェクトを初期化します。
“`bash
cdk init app –language=
【AWS】Amazon CloudWatchの詳細モニタリングのメトリクスをCLIで取る(Elastic Beanstalk編)
## はじめに
CloudWatchの詳細モニタリングでどんな情報が取れるんだっけ、というのを改めて確認したくなったので、復習ついでにElasticBeanstalkの拡張モニタリング(Elastic Beanstalkは「詳細モニタリング」を「拡張モニタリング」と呼ぶ)のメトリクスをCLIで取ってみる。(ドキュメントによっては「モニターリング」という表記になっていたりするけど、本記事では「モニタリング」に統一)
CloudWatch公式ドキュメント
https://aws.amazon.com/jp/cloudwatch/
## 1. 基本モニタリングと詳細モニタリング
`基本モニタリング`……AWSサービスを利用すると自動で有効になる。5分間隔。無料。
`詳細モニタリング`……一部のサービスでのみ利用可能。課金あり。基本モニタリングより短い間隔でメトリクスを取得できたり、基本モニタリングには無い情報を取得することができる。詳細モニタリングは、対象のAWSサービスによって呼び名やオプション内容が変わる。
例えばEC2の場合は「詳細モニタリング」と
KendraとBedrockによるRAG実装を誤解していた話
# はじめに
お疲れ様です。yuki_inkです。
社内文書の内容を踏まえた回答をしてくれるチャットbotが欲しい!
と言っていたら「KendraとBedrockの組み合わせでRAG作れば?」という助言をいただき、時流に乗ってやってみようと思い立ちました。事前知識も何もない状態で、なんとなく想像していたイメージはこう。
**※全然違うので参考にしないでください**![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/731275/924cc98d-95e6-d52f-6c12-41bbb8cad673.png)
– ユーザからのリクエストをBedrockが受ける
– Bedrockの裏にKendraがいて(?)、社内文書に関するリクエストが来たときはBedrockがKendraにいい感じに(?)その内容を問い合わせに行く
– 問い合わせをもらったKendraは、S3などのデータソースに格納されたファイルに検索をかけにいき、得られた内容をいい感じに(?)問い合わせ元(Bedrock)に返
Glue DataQualityをAWS CLIで作成や実行してみる
# はじめに
そろそろre:Inventですね。今年はどんなアップデートが出てくるか楽しみです。
今回は、去年のre:Inventで発表されたAWS Glue Data QualityをAWS CLIで触ってみようと思います。
具体的には、ルールを作って実行して確認する、以下の4つのステップを実行してみます。
1. ルールを作成する
2. ルールを実行する
3. 実行情報の確認
4. 結果の確認# 前提条件
– 東京リージョンで実施
– Cloud9で実施
– AWS CLIはv2にバージョンアップ済み
– Cloud9はv1が入っているので、v2にバージョンアップしました
– 事前にGlue DataQualityが実行できるロールを用意しておく
– テストのテーブルとして、Glueデータカタログのテーブルを用意しておく
– 今回は、以下のようなテーブルを作成済み![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2949357/5c550d30-a170-a6ae-
CloudFormation yaml構文エラー
CloudFromationのyaml作成時に出た構文エラーについてまとめてみました。
## 構文エラー1
“`: エラー例1
Property vaildation failure: [Value of property {該当箇所} does not match type {Array}, THe property {/Tags/0/Value} is required, The property {/Tags/1/Key} is required}
“`
対処方法:下記のようにSecurityGroupIds部分を修正することで解決しました。
“`javascript: コード修正前
RedshiftServerlessWorkGroup:
Type: AWS::RedshiftServerless::Workgroup
Properties:
SecurityGroupIds: !Ref RedshiftServerlessSecurityGroup
“`
“`javascript: コード修正後
Redshif
AWS lambdaの新機能
AWSのLambdaでロギングについて新機能が追加されました!
>AWS Lambda では、JSON 構造化形式でネイティブにログをキャプチャし、ログレベルを調整し、Lambda 関数用の Amazon CloudWatch ロググループを選択できる高度なロギングコントロールを発表しました。
(公式サイトより引用)# 変更内容
+ JSON形式でLambdaログを取得
+ ログレベルの制御
+ CloudWatchのロググループを選択# JSON形式でLambdaログを取得
LambdaのログをJSON形式で管理できるようになったため、keyとvalueの値からログの検索がしやすくなりました。
また、Kibanaなどのダッシュボードで分析しやすくなりました。# ログレベルの制御
ログレベルを変えるにはソースコードを変更する必要がありましたが、Lambdaの新機能でログレベル(INFO、WARNING、ERRORなど)を調整できるようになりました。
これによりデバッグがしやすくなりました。# CloudWatchのロググループを選択
Lambdaがログを送るCloud
Security Hub におけるセキュリティ基準のコントロール一覧を一回で全部出力するスクリプトを作った
背景
「[AWS Security Hub が AWS CloudFormation を使用した管理機能の強化を発表](https://aws.amazon.com/jp/about-aws/whats-new/2023/06/aws-security-hub-enhanced-management-capabilities-cloudformation/)」で以下のような update(Jun. 2023) がありました。
また、新しい AWS::SecurityHub::Standard リソースを使用することで、NIST 800-53 や PCI DSS など、特定のセキュリティ基準を有効にして、そこに含まれる個別のコントロールを管理することもできます。
コントロール毎の有効化/無効化の設定をするために、Security Hub のコントロール情報を AWS CLI で出力したくなった人が急増(?)しているのではないでしょうか。
以下のように `aws securityhub describe-standards-controls` コマンドでセキュリティ基
Amazon Route53の耐障害性を考える
# はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧は[こちら](https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2)。この記事ではAmazon Route53を耐障害性の観点から超詳細解説しています。
具体的には以下流れで説明します。
– Amazon Route53とは
– 耐障害性を考慮したルーティングAWSの区分でいう「Level 200:トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。
# この記事を読んでほしい人
– Amazon Route53を採用するときのベストプラクティスを説明できるようになりたい人
– Amazon Route53の耐障害性に不安を感じている人
– AWS Certified DevOps Engineer Professionalを目指している人# Amazon Route53とは
Amazon Route53とは高可用、スケーラブル、そして完全マネージド型
Amazon Bedrockの新機能アップデート予想!(AWS re:Invent 2023)
さぁ今年もクラウドサービスAWSの年一回のお祭り「AWS re:Invent」の季節がやって来ました。
https://aws.amazon.com/jp/events/reinvent-2023/
2023年は何と言っても生成AIが大注目。re:InventでもBedrock関連のアップデートが多数発表されることが予想されます。
今年は私も初めてラスベガスで現地参加するのですが、Bedrock芸人としてアップデート予想をしてみます。
# ① Agent for Amazon Bedrockの一般提供開始
8月からプライベートプレビュー中のBedrockの新機能です。これは高い確率でre:Invent中にGAされるのではないでしょうか。
https://aws.amazon.com/jp/blogs/news/preview-enable-foundation-models-to-complete-tasks-with-agents-for-amazon-bedrock/
AWSマネジメントコンソールからの操作だけで、S3バケット等に格納した文書ファイルを参照させてタス
Step Functionsでフィールド名にスペースが入っている場合の表記
# はじめに
AWS Step Functionsを使っている時に、フィールド名にスペースが入っていて困ったので、その際の対応方法を記事にしました。
# 概要
入力のサブセットにアクセスするパスの表記は以下の2つがあります。
– ドット (.) を使う方法
– `$.abc.def`
– フィールド名にスペースがある場合はうまく動きません
– 角括弧 ([ ]) を使う方法
– `$[‘abc’][‘def’]`
– フィールド名にスペースがある場合は、こちらが使えます# 参考
https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/amazon-states-language-paths.html#amazon-states-language-reference-paths
# やってみた
## 入力イベント
ステートマシンの入力に、スケールアウト成功のイベントを使います。https://docs.aws.amazon.com/autoscaling/ec2/user
Amazon EKS on サービスアカウントの IAMロール
# サービスアカウント
Pod 内のコンテナから各リソースへのアクセス制御の際に用いられる。
# サービスアカウントの IAMロール
IAM ロールをサービスアカウントと関連付けて、サービスアカウントを使用するように Pod を設定する。
***要するに、Pod 単位で IAM ロールを割り当てることができる!!!***
# 手順
大まかな流れ
1. クラスター用の IAM OIDC プロバイダーを作成
2. IAM ロールを引き受けるための サービスアカウントの設定
3. サービスアカウントを使用するように Pod を設定する## 1. クラスター用の IAM OIDC プロバイダーを作成
クラスターには、**OIDC 発行者 URL** が関連付けられています。
サービスアカウントで IAM ロールを使用するには、クラスターの OIDC 発行者 URL に対して **IAM OIDC プロバイダー**が存在している必要があります。EKS クラスターのコンソール画面より
![スクリーンショット 2023-11-25 18.44.20.png](https: