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

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

RDS for MySQLからAuroraへの移行ガイド

2ヶ月くらい前に、RDS for MySQLからAurora MySQLへDB移行したので、そのときに検討したことや実際の作業手順などをまとめました。

同様の作業をされる方の参考になれば幸いです。

## 背景
コストをケチって、サービスのリリース後もシングルAZのRDS for MySQLを利用していましたが(よくない)、クライアントやトラフィックが日々増えていくなかで、データの耐久性と将来的なパフォーマンスに不安がでてきていました。そこで、複数AZにデータを分散し、MySQLのパフォーマンスが最大5倍向上するAuroraへ移行することにしました。

## 移行
– 新規で作成するリソース(Auroraクラスター、インスタンス、サブネットグループ、パラメータグループ)についてはTerraformでコード管理することにしました(移行元のRDSはコード管理していなかった)
– アプリケーション(Lambda)との接続はRDS Proxyのターゲット先を変更することで完了しました
– 移行手段としてスナップショットかDMSを検討しましたが、ダウンタイムを前提としてスナップショットを選択し

元記事を表示

オンプレエンジニアがAWSを触って思ったのと違うと感じたこと

# はじめに
この仕事を始めた当初(約20年前)はオンプレミスという言葉がありませんでした。いや厳密には私の周りではパブリッククラウドとオンプレミスを分けて話す人はおらず、インフラ構築といえば今でいうオンプレミスが中心でした(世の中的にはパブリッククラウドがサービスとして存在していました)。オンプレミスみたいに新しい概念が出てきた時にそれまでの概念を説明するためにできる言葉を**レトロニム**というそうです。
私が本格的にパブリッククラウドの仕事をし始めたのは約3年前でAWSでした。研修ではAzureを先に触れていたのと、[この本](https://www.amazon.co.jp/dp/B01KUN5LI2 “Cloud First Architecture 設計ガイド(日経BP Next ICT選書)”)を読んでいたという知識があった程度です。

ここではずっとオンプレミスのインフラ構築をしていた私がAWSに触れて最初に戸惑ったことを記事したいと思います。また、戸惑いましたということだけ書いても学びがないため**対応したこと**も併せて記載します。AWSに慣れている人からすれば常識

元記事を表示

[Amazon Web Services]AWS Resource Groupsを使ってアクティブなリソースを検索

今日は個人AWSアカウントの整理を進めております。

これまで試してみたいサービスを好きに使っていたので、
不要なリソース削除のためにも、今現在アクティブなリソースを一括で知る方法がないかを探していたところ、AWS Resource Groupsを使用すれば簡単に使用中のリソース一覧を取得することができました。

## AWS Resource Groupsを使ってアクティブなリソースを検索
① Resource Groupsコンソールに遷移
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3822026/8ce31499-f884-87b4-996a-824e105e46a9.png)

② 左ペイン > タグエディタをクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3822026/4f26bc55-233d-5564-5d60-49d5a2aac1cb.png)

③ 対象リージ

元記事を表示

【AWS】S3コスト最適化のポイント【S3】

## はじめに
AWSのアーキテクチャを評価する際の観点の1つとして、発生するコストが最適化されているかというものがあります。
Well-Architected Frameworkのコスト最適化の柱ベストプラクティスでは「クラウド財務管理を実践する」「経費支出と使用量の認識」「費用対効果の高いリソース」「需要を管理しリソースを供給する」「継続的最適化」という領域があり、いかにコストの発生を可視化、あるいは監視してそれを分析し、最適化するかが求められます。
この基本的な考え方は各AWSサービスに共通でもAWSサービスごとに実践できる具体的な対策は変わってきます。
今回の記事ではS3に関するコスト最適化の例をいくつか記載しました。

## S3のコストは何に対して発生するか
参考「Amazon S3 の料金」:https://aws.amazon.com/jp/s3/pricing/
AWS公式のS3の料金の参考サイトから以下の項目に関しての主に料金が発生することが記載されています。
### 「ストレージとリクエスト」
S3 バケットにオブジェクトを保存するための料金が発生し、この料金はス

元記事を表示

AWS Well-Architected Frameworkの設計原則をただただ箇条書きで並べた

## モチベーション

公式のページは6つの柱と設計原則のページが分かれており、ざっと一気に見られないのが少しストレスだった。
クラウドプラクティショナーの試験では頻出なのにこのままでは覚えづらいので、ただただ自分のためにまとめた記事となります。
(記事と言っても抜き出しただけですが)

不安な方は試験直前の見直しにご利用ください!

公式のページはこちらです。

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/the-pillars-of-the-framework.html

## 6つの柱と設計原則

### 運用上の優秀性

– ビジネス成果に基づいてチームを編成する
– オブザーバビリティを実装して実用的なインサイトを取得する
– 可能な限り安全に自動化する
– 小規模かつ可逆的な変更を頻繁に行う
– 運用手順を定期的に改善する
– 障害を想定する
– 運用上のあらゆるイベントやメトリクスから学ぶ
– マネージドサービスを使用する

### セキュリティ

– 強力なアイデンティティ基盤を

元記事を表示

VPC関連周りを学習

## VPC
AWSクラウド内に仮想ネットワークを作成できるサービスです。
仮想ネットワークを作成することでユーザーが自由に作業を行う土地を提供してくれます。

## IPアドレス
IPアドレスはネットワーク上の住所を表しており、コンピューターやスマホなどのネットワークに接続されているデバイスを識別します。

### IPv4
「Internet Protocol Version 4」の略称です。
一般的に広く使用されていますがアドレス数に限りがあり、枯渇問題を抱えています。
形式は192.168.1.1のような4つの数字のグループです。

### IPv6
IPv4の枯渇問題を解決するために、誕生したプロトコルで形式は
2001:0db8:85a3:0000:0000:8a2e:0370:7334 のような長い文字列になっています。

## CIDR
IPアドレスの範囲を決定するための表記方法で、VPC内で使用可能なIPアドレスの範囲を決定します。
例: 10.0.0.0/16を指定すると、10.0.0.0〜10.0.255.255までの範囲が使用可能になります。この時の使用可能アド

元記事を表示

【keycloak on Fargate 3】ALB認証で受け取ったトークンでAPI Gateway認可も突破する

# やったこと
– https://qiita.com/yuta0003/items/b383406d09c082e252e7 にて作成したALB認証を元に、取得したアクセストークンを使用してAPI Gatewayの認可にも利用する。
– keycloak側でユーザにロールを付与しておき、そのロールがあればAPIGatewayのコールも許すよといったコードを書く
– イメージ的にはこんな感じ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/33518817-0181-ac07-aa64-ef17262028e6.png)

# 本記事で作成するリソース
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/a2c5d38c-b742-e2e4-621e-7545f93d7361.png)

# keycloakのrealmユーザにロールを付与
「Realm rol

元記事を表示

Llama3.1 70B を AWS P4d インスタンスで微調整

Meta-Llama-3.1-70B-Instruct を LoRA や量子化を用いずに Amazon EC2 P4d インスタンスで教師あり微調整しました。手順を紹介します。

https://huggingface.co/meta-llama/Meta-Llama-3.1-70B-Instruct

P4d インスタンスの p4d.24xlarge は、GPU あたり 40GB メモリの NVIDIA A100 Tensor Core GPU を 8 基搭載し、GPU メモリの合計は 320 GB です。また、1152 GiB のインスタンスメモリと 8 TB NVMe ベースの SSD インスタンスストレージを備えています。

https://aws.amazon.com/jp/ec2/instance-types/p4/

微調整には推定 500GB 超の GPU メモリが必要なので Transformers の DeepSpeed 統合で GPU メモリの不足を補います。

https://huggingface.co/docs/transformers/ja/main_

元記事を表示

CloudFormationエラーの詳細をCloudTrailで確認した

# 概要

CloudFormationのトラブルシュートでは、以下のように情報収集を行うことができる。

1. スタックの作成または更新の実行結果を確認する。表示される[スタックステータスコード](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html#cfn-console-view-stack-data-resources-status-codes)が`CREATE_COMPLETE`もしくは`UPDATE_COMPLETE`以外だったら、おそらくなにかしらのエラーが起きたと分かる。
2. スタックの「テンプレート」タブや「パラメータ」タブで、指定値が想定通りか確認する。
3. スタックの「スタック情報」タブの「状況の理由」を確認する。エラーメッセージが分かる。
4. スタックの「イベント」タブを確認する。エラーメッセージを出力したAPI呼出しが分かる。
5. CloudTrailの「イベント履歴」を確認する。原因

元記事を表示

Bedrockナレッジベースの新機能全部入りのRAGを作る

Bedrockおよびナレッジベースの新機能を幾つか確認したので、全部入りのRAGプログラムを書いてみます。

# ナレッジベースの作成

以下の

https://qiita.com/cyberBOSE/items/44515b0989b79ecfcda0

Use foundation model for parsing、Hierarchicalチャンキング で構築したナレッジベースを使います。

# ガードレールの作成

以下の

https://qiita.com/cyberBOSE/items/cc8ed630470b96dc3ed8

Contextual grounding check を有効にしたガードレールを使います。

# ナレッジベースの検索仕様

テストツールで言うところの以下のハイブリッドサーチを使います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3573242/cf151b99-0b9c-d892-0bb9-151abfa04e93.png)

テストツ

元記事を表示

Azure と AWS の L4 ロードバランサーの主要な違いを個人的に比較

L4 ロードバランサーは、ざっくりいうと、TCP/UDP のプロトコルでの負荷分散です。

Azure の場合は Standard Load Balancer(以降、Azure LB と表記) / Basic Load Balancer、AWS の場合は Network Load Balancer(以降、AWS NLB と表記)が該当します。

ただ、 Azure Basic Load Balancer は[廃止予定](https://azure.microsoft.com/ja-jp/updates/azure-basic-load-balancer-will-be-retired-on-30-september-2025-upgrade-to-standard-load-balancer/)なので、今回の比較に含めません。

## 機能面の比較

| 項目 | Azure LB | AWS NLB |
| ——-

元記事を表示

AWS Health Aware を Power Automate の Teams Incoming Webhook コネクタに対応させる

# はじめに
Microsoft (以下MS) が、Teams内のOffice 365コネクタを廃止することを発表しました。
これにはIncoming Webhookも含まれ、記事執筆時点では、以下のスケジュールが設定されています。

2024年8月15日: 新規コネクタの作成が停止し、これ以降、新規にIncoming Webhookを利用する場合、Power Automateのワークフローでコネクタを介して受信する方式に対応する必要あり
2024年12月31日: 既存のWebhook URLが無効化される予定 (ただし、URLを更新すれば2025年12月まで利用可能)
最新の情報は、以下のMS公式サイトをご参考ください。

Retirement of Office 365 connectors within Microsoft Teams

さて、このMSのコネクタ廃止に伴い、AWSが出している **「AWS Health Aware」** をお使いの方は、WebhookのURLが変更にな

元記事を表示

DynamoDBコスト削減ベストプラクティス

# はじめに

サーバーレス大好きなエンジニアです!
今日はDynamoDBのコスト最適化についてAWS SUMMIT2024の内容を参考に説明していきたいと思います。

https://aws.amazon.com/jp/summits/japan-2024/

# 対象読者

– NoSQLを使用している方
– 今後NoSQLを使用したい方
– DynamoDBに関心がある方
– サーバーレスが好きな人

# 目次

1. なぜコスト削減が重要なのか
2. データベースのコスト削減
3. NoSQLのコスト削減
4. Amazon DynamoDBのコスト削減

# 1. なぜコスト削減が重要なのか

システムを運用する際には、さまざまなコストが発生します。

– インフラコスト
– ライセンスコスト
– オペレーションコスト
– 開発コスト
– ビジネスコスト

コストが十分に確保できないと最新技術の導入が難しくなり、新機能の開発ができなくなる可能性もあります。
つまり、**コストを抑えることはビジネスの競争力を向上させる**ためにも非常に重要です。

# 2. データベースのコ

元記事を表示

Serverless Frameworkを使わず、Nuxt3でSSR構成(CloudFront + Lambda + S3)をする方法

# 対象者
– 自分と同じAWS初心者
– 「俺たちは感覚でAWSを触っている」状態の人
– バックエンドなんもわからんけどAWSへのデプロイを控えている人
– ~~Next全盛の今NuxtのSSRで頑張っている人~~

# なぜやろうと思ったか?

「Nuxt3 SSR AWS」で検索するとAmplifyを使うパターンか、Serverless Frameworkを使うパターンしか検索結果に引っかからないからです。

Amplifyは融通が効かない部分があるため今回は使いたくないし、
かといってServerless Frameworkはv4から有料になるしv3は2024年でサポート終了するらしいし…

ということで、自前で一からCloudFront + Lambda + S3構成を作ってみたのですが、
できるまで丸二日間スタックしたので皆さんが同様の状況にならないようにまとめました。

# 前提

1. Nuxt SSR構成でビルドできる状態であること
1. 調べればすぐ出てくるようなデプロイ用の設定は終わっていること
1. `nuxt.config.ts`の`nitro`

元記事を表示

Amazon Inspectorのエージェントスキャンとエージェントレススキャンで結果が異なることがある原因と対処

# これは何?

Amazon Inspectorにおける EC2の脆弱性検出において、エージェントベーススキャンだと検出されなかったアプリケーションのパッケージ脆弱性が、エージェントレススキャンで検出されたため、原因を調べた時のメモです。

# 結果が異なる原因

以下公式ページの注意点に書いてありました。

https://docs.aws.amazon.com/inspector/latest/user/scanning-ec2.html#agentless

:::note
Linuxインスタンスでアプリケーションプログラミング言語パッケージの脆弱性をスキャンする際、エージェントレス方式ではすべての利用可能なパスをスキャンしますが、エージェントベースのスキャンではデフォルトのパスと、Amazon Inspectorのディープインスペクションの一環として指定した追加パスのみをスキャンします。このため、同じインスタンスでもエージェントベース方式とエージェントレス方式でスキャンされた場合、異なる結果が得られる可能性があります。
:::

エージェントベーススキャンでは、デフォルトでは

元記事を表示

AWS Lambda から Power Automate の Teams Incoming Webhook コネクタの挙動をテストする

# はじめに
Microsoft (以下MS) が、Teams内のOffice 365コネクタを廃止することを発表しました。
これにはIncoming Webhookも含まれ、記事執筆時点では、以下のスケジュールが設定されています。

* 2024年8月15日: 新規コネクタの作成が停止し、これ以降、新規にIncoming Webhookを利用する場合、Power Automateのワークフローでコネクタを介して受信する方式に対応する必要あり
* 2024年12月31日: 既存のWebhook URLが無効化される予定 (ただし、URLを更新すれば2025年12月まで利用可能)

最新の情報は、以下のMS公式サイトをご参考ください。

Retirement of Office 365 connectors within Microsoft Teams

AWSユーザーも、**[AWS Health Aware](https://aws.amazon.com/jp/blogs/news/aws

元記事を表示

122日目 Terraformを触ってみた社畜S

## :file_cabinet:はじめに
こんにちは、社畜Sです。 
最近新しい案件でTerraformを触る機会がありました。

せっかく新しく触ったものをそのままにしておくのもなんだかもったいないので、今回はTerraformのざっくりとした概要と合わせて、初心者目線からTerraformを触ってみた感想を記事にしていこうと思います。 

完全初心者目線での感想ですのでTerraform仙人の皆様には物足りない記事かもしれませんが、「自分たちにもこんな頃があったなぁ」と生暖かい目で見守ってください。
## :file_cabinet:学習開始時のレベル
・仕事が始まって4か月目
・IaCは1~2か月前にAWS Cloudfourmationで簡単な環境を作った経験のみあり
・Terraformは今回の案件で初めて知ったので完全に知識0
## :file_cabinet:そもそもTerraformって何?
HashiCorpによって開発されたIoC(Infrastructure as Code)ツールのことです。

他のIaCツールと同じようにクラウドリソースやインフラストラクチ

元記事を表示

Amazon Q Developer無料プランをVSCodeで使う方法

先日JAWS-UG CDK支部にて登壇した内容の一部抜粋です

## 1. VSCodeの拡張機能からインストール
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3480176/8495ed9e-4e50-c99f-e604-1f333797f673.png)

## 2. Builder IDと連携
タブが開くのでここから使用しているBuilderIDと連携します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3480176/3bcfc47d-00f7-a961-39de-f6f66dca5069.png)

Builder IDを連携して使用するプランは「永続的な無料利用枠」として書かれているので勝手にサブスクリプ

元記事を表示

VMware Cloud コンソールから AWS アカウントのリンクを削除する方法

## はじめに

VMware Cloud on AWS で Software Defined Data Center (SDDC) を作成する際に、 AWS アカウントとリンクするステップがあります。

一つの Org で色々な AWS アカウントとリンクをさせると以下のように大量に AWS アカウントが表示されるようになります。そのうちのいくつかのアカウントともう連携する必要がなくなった場合、VMware Cloud コンソール(VMC コンソール)で表示させたくない、というケースが出てきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/efccb8ba-d885-153e-5df9-dc1146687a2c.png)

このアカウントのリンクの削除方法についてドキュメントを探しても見つからなかった為、備忘録を兼ねて削除ステップをまとめてみました。

## CloudFormation、IAM ロールを削除しただけでは、コンソールからのリンクは消えない

SDD

元記事を表示

AWS Lambdaの def lambda_handler(event, context): って決まり文句??

## この記事の対象者
初めてLambdaを使う人、使い始める人

## 結論
– パラメータ名:決まり文句ではないが **ほぼ決まり文句**

## AWS Lambda ランタイムの基本

### パラメータの基本構造

1. 第一パラメータ:イベントデータ(通常 `event`)
2. 第二パラメータ:コンテキスト情報(通常 `context`)
“`
def lambda_handler(第一パラメータ, 第二パラメータ):
“`

### 順序の重要性

– 第一パラメータ:常にイベントデータ
– 第二パラメータ:常にコンテキスト情報

## パラメータ名のカスタマイズ例

### 標準的な使用方法

“`python
def lambda_handler(event, context):
return {
‘statusCode’: 200,
‘body’: json.dumps(‘Hello from Lambda!’)
}
“`

## カスタム名の使用例

“`python
def l

元記事を表示

OTHERカテゴリの最新記事