AWS関連のことを調べてみた2022年03月05日

クラウドコンピューティング？何それおいしいの？

## クラウドコンピューティング ってなんだ
IT界隈では最近クラウドコンピューティングという言葉がはやっています。
Amazon が提供している AWS や Microsoft が提供している Azure 、Google が提供している GCP とか。。。。

なんか流行ってるけど、それなんなん？おいしいの？
という疑問のアンサーとして、クラウドコンピューティングとは何かについて説明します。
はじめて聞いた！という人にはちょうど良い程度の情報を得られると思います。

クラウドコンピューティングとは、かんたーんに言うと、
**パソコン・インターネット・ストレージといったものをネット経由で貸し出しますよ！**
というものです。

これを初めて聞いた時の僕の反応
> は？パソコンって手元にないと使えなくない？どゆこと？おいしいの？

謎すぎたので、調べてみました。
以下しょうもないやりとりを見て、「クラウドコンピューティングとは」をざっくりと理解してみてください。

提供側 : パソコン・インターネット・ストレージとか必要なものはうちで用意してあげる。それがクラウドコンピューティングです

Cognito UserPool Oauth2.0 AuthorizationCodeGrantで認可認証する

# この記事について
Cognito UserPoolで認可認証するWEBアプリをいくつか作成してきたので大まかなフローについてまとめる
全機能を網羅するのはさすがに難しいので以下に絞って書いていく

– UserPoolへのサインアップ
– サーバーサイドで認証するフロー(`ADMIN_USER_PASSWORD_AUTH`)についてまとめる
– MFAデバイス登録については触れない
– Lambdaを使って認証フローをカスタマイズする機能についても触れない
– トークン取得
– OAuth2.0 `AuthorizationCodeGrant`によるアクセストークン等の取得方法についてまとめる
– OIDCやUserPoolのサインインAPIによるトークン取得方法については触れない
– また、IDプールによるユーザー毎の権限管理等についても触れない

# サインアップ
## フローの確認
超ざっくりとしたフローはこんな感じになる↓※クライアント＝フロントエンド＋バックエンド
![Untitled Diagram.png](https://qiita-imag

AWS DeepRacer 日記 2022/2 (ハイパラチューニングで一定の効果が見られた！)

AWS DeepRacer 日記 2022/2

2021年10月から本格的にDeepRacerリーグに参加し始めました。
今回はDeepRacer日記第4回です。
筆者の試行錯誤を記載していきます。
参考になればうれしいです。

※DeepRacer参加方法については下記にまとめています

https://qiita.com/toma_shohei/items/a79abd8d71a2e284273f

## 1/31　（前回記事参照）

https://qiita.com/toma_shohei/items/0c2f5617cb9ef66a2dbb

前回の最後でエラー解消したので、ハイパラチューニング再開。
安定志向のハイパーパラメータで試していた。

“` A:安定志向のパラメータ
コース：VivalasSpeedway
バッチサイズ　64→128
エポック数　3→10
エピソード数　20→40（推奨される値は10、20 および 40 ）
MinimumSpeed 0.5→1
Maximu speed 1→2
学習時間 120分
“`

※ハイパラの意味やチューニング事例に

Amazon Connect 로 아웃바운드콜 전화하기

# TL;DR
> Slack 장애 발생을 전화로 전달받고 싶었습니다.
> Amazon Connect의 OutBoundCall(아웃바운드콜) 을 활용해서 구현해보았습니다.
> 전체 과정에서 `Lambda > Amazon Connect > Phone` 부분을 기록하였습니다.

# Amazon Connect 설정
Amazon Connect > 인스턴스 추가
(고유의) 액세스 URL을 지정 (예: `betahelloworld`) > 다음
![i

AWS公式資料で挑むSCS認定(12)-AuditManager

[前回] [AWS公式資料で挑むSCS認定(11)-Artifact](https://qiita.com/mingchun_zhao/items/23e0fb58313badec62a8)

## はじめに

今回は「Security, Identity & Compliance」に分類されるサービス、
AWS Audit Manager の勉強です。
これも監査関連サービスで、AWS の使用状況に対する監査証跡を自動的に収集してくれるみたいです。

## 教材を選ぶ

[[AWS Black Belt Online Seminar] AWS Audit Manager](https://d1.awsstatic.com/webinars/jp/pdf/services/20210309_AWSblackbelt_AWSAuditManager.pdf)を教材として使用します。

AWS様のプレゼン資料、論理的にまとまっており、読んでいて気持ちいいですね。

## Audit Manager とは

– AWSの使用状況を継続的に監査
– 従来手動で行われていた証跡収集を自動化し作業

S3のストレージクラス

# スタンダード
デフォルトで設定されているストレージクラス。
頻繁にアクセスされるデータ向け。
# スタンダード-IA
スタンダードクラスと同等の耐久性がある。
データの格納コストはスタンダードクラスと比較して安価。
アクセス頻度は低いが、重要度が高いデータ向け。
# One Zone-IA
ひとつのAZのみにデータを保存。
必要に応じてすぐに取り出したい場合に適用する。
重要度が低いデータ向け。
# Glacier
アーカイブを目的としたストレージ。
大容量のデータを安価に保管することができるが、アクセスに時間を要する。
# Glacisr Deep Archive
通常のGlacierよりさらにアクセス時間を要する。
取得時間に12時間許容されるデータ向け。
# Intelligent-Tiering
アクセス頻度に応じて、最も効率の良い階層へデータを保管。

バケット所有者強制（BucketOwnerEnforced）の場合マネジメントコンソールでS3クロスアカウントアップロードの「AccessControlListNotSupported」エラーを解消する方法

# 背景

マネコンを経由してクロスアカウントのS3アップロードをやりたいです。
バケットのオブジェクト所有者を「ACL無効」→バケット所有者強制（BucketOwnerEnforced）に設定します。

# 設定

##### ・アカウントAのS3バケットポリシーでアカウントBに対するアップロード権限を付与する

“`json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“arn:aws:iam::<アカウントBのID>:role/<ロール名>”
]
},
“Action”: [
“s3:ListBucket”,
“s3:GetBucketVersioning”,

DynamoDBの並列スキャンをboto3で試してみた

# はじめに
DynamoDBでデータを取得する際scanを使用するとテーブルの全てのレコードに対して逐次処理をしていきます。
そのため基本的には`scan`ではなく、`query`を使うというのが[ベストプラクティス](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-query-scan.html#bp-query-scan-performance)です。
しかし、どうしてもスキャンを使いたいときに効率よくスキャンできそうな、並列スキャンについてboto3で試してみた備忘録です。

並列スキャンについてのドキュメントは[こちら](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Scan.html#Scan.ParallelScan)です。

# 環境
確認に使用した環境は以下です。
– python: v3.9.7
– boto3: v1.21.11

# 検証
## 検証用データの準備
今回

AWS LambdaからTwilio Funcitonsに値を渡す

# これはなに？
AWSLambdaからTwilio Fnctionsへ値を渡すときに使用した例です。

例えばですが、CloudWatchAlarmの発生をトリガーにLambdaが動き、
LambdaからTwilio Functionsが呼び出されSMSの通知内容でアラート名をお知らせするなど行えると思います。

## Lambda側
下記にて紹介されているコードを転用して作成しております。
今回はCloudWatchAlarmよりアラートが上がった際のアラート名を連携するようにしています。

https://qiita.com/mobilebiz/items/406461282a23d2e056a6#%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AE%E6%BA%96%E5%82%99

“`index.js
exports.handler = function (event, context, callback) {
const crypto = require(‘crypto’);
const

Terraformを使ったインフラ構築入門(EC2+RDS)

# 記事を書いたきっかけ
– 案件で使った技術をメモとして残しておきたかったから
– ~~ぶっちゃけ最近アウトプットしてなかったから~~

# 対象者
– Terraform を触れたことがない人
– AWS のマネコンからインフラの立ち上げに飽きた人

# 動作環境
– Cloud9(設定は全てデフォルトでOK。今回は立ち上げ手順は省略）
– 作成されるリソースが IAM ポリシーに含まれていること

# 本記事で作るインフラ構成
– パブリックサブネットに踏み台サーバを1台設置
– プライベートサブネットからインターネットに接続させるため、NAT ゲートウェイを設置
– プライベートサブネットにDBサーバを１台設置
– サブネットグループは２つ以上の AZ が必要なため、サブネットを2つ展開
– DB サーバにはパブリックサブネットからのみ接続可能
![構成図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/416385/1730787f-7c3f-6eea-3db7-0cc

コーヒーショップの例をベースにAWSの勉強をしていったらクラウドプラクティショナーに合格した話

# はじめに
今回、AWSを体系的に勉強したら、結果的にクラウドプラクティショナー（AWS Certified Cloud Practitioner）に合格できたので、やったことをまとめておきます。

AWSの勉強をしようと思い立ったのは、なんだかんだあり1年8ヶ月も取得してしまった育児休業が終わる段階で、「この休業期間なにも成してない・・この浦島太郎状態のまま復帰はまずい・・！」という焦りからです。
ちょうど上司との面談もあったため勉強しておいた方がいい領域を相談してみたところ、「もしあまり詳しくなければ、AWSを体系的に勉強してみたら？」と薦めていただきました。なるほどたしかに今まで前提知識があまりない状態でEC2とS3を軽く触ったことしかなかったな、と思い、勉強してみることに。

# 勉強のためにやったこと
## AWS Cloud Practitioner Essentialsの視聴
実務ではEC2とS3にかろうじて触ったことがある程度で、体系的なこともほぼ知らなかったため、まず知識をいれよう！ということで、AWSが公式で提供している **AWS Cloud Practiti

AWS 構築したEC2からRDSとS3に疎通確認する

# 概要

– 別記事で構築したEC2インスタンスから別記事で構築したRDSとS3に接続できるかを確認する。

# 前提

1. 下記に記載されている記事をそれぞれ実施して作業完了していること。
1. [AWS VPCの作成](https://qiita.com/miriwo/items/b28a4395264c08d183c6)
1. [AWS VPCの中にサブネットを作成する](https://qiita.com/miriwo/items/9abebd478c53744b1b05)
1. [AWS インターネットゲートウェイの作成](https://qiita.com/miriwo/items/20f05f40a3f2d5314a1d)
1. [AWS ルートテーブルの作成とルートの追加](https://qiita.com/miriwo/items/02ec1626632a53081cb3)
1. [AWS EC2 → S3接続用のIAMユーザーの作成](https://qiita.com/miriwo/items/9b20caab0ac8

AWS Systems Manager Session Managerを用いてvscodeのRemote-SSHでEC2接続してみた

## 概要

別件で特定のRDSと同じVPC内でEC2立てて環境構築する必要が出たのですが、キーペアがなかったのでチーフに.pemを要求したところ、

**「キーペア作らないでsession managerでつなぐ方式にしてもらったほうがいいかも！」**

ということで、AWS Systems Manager Session Managerを介してEC2に接続する形にしました。以下の点だけ注意すれば、いつものEC2のインスタンスの立ち上げ方と同じでした。

– AmazonSSMManagedInstanceCoreのIAMポリシーを含んだIAMロールをEC2にアタッチする
– EC2からSystems Managerのエンドポイントにアクセスするので、EC2がインターネットあるいはVPCエンドポイントへアクセス可能にする
– せっかくSession Managerで接続するので、セキュリティグループのSSHインバウンドポートが開いてないセキュリティグループをアタッチする。このとき警告が表示されるが気にせず次に進む

参考文献）
[【まだEC2のSSHで消耗してるの？】AWS Syst

laravel学んで2か月で自サービスを開発した話 Part6

皆さんこんばんわ（この記事を投稿したのは真昼間です）

今回も引き続き、プロフィール画面の続きを開発していきます。

今までの開発記録はこちらへ
胡蝶蘭を捨てるくらいならワイが欲しいので、サービス開発する編

Amazon LinuxでMysqlクライアントをインストールしたらGPGキーのエラーが発生した件

## 経緯
AWSのプライベートサブネットにあるRDSをパブリックサブネットにあるEC2サーバを踏み台にしてアクセスしたかったので、EC2サーバにMysqlクライアントをインストールしたらGPGキーのエラーが発生してしまった。
以前までは同様のエラーが発生しないでインストールできていたので備忘録として残してみた。

## 検証環境
OS：Amazon-Linux2
DB：Mysql8.0

## 事象を発生させる
### Mysql8.0のリポジトリを追加する

“`
yum localinstall -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm

Installed:
mysql80-community-release.noarch 0:el7-3

Complete!
“`

### Mysql5.7のリポジトリを無効化にして、Mysql8.0のリポジトリを有効化させる

“`
yum-config-

AWS EC2 AmazonLinux2インスタンスの作成

# 概要

– AWSのEC2にてAmazonLinux2インスタンスを作成する。

# ご注意！！！

– AWSは従量課金です。
– 本作業で料金が発生する可能性があります。
– 筆者は本作業で発生するいかなる料金も負担する事ができません。
– ご自身の責任の下作業をお願いいたします。

# 前提

– 下記のすべての作業が完了していること。
– [AWS VPCの作成](https://qiita.com/miriwo/items/b28a4395264c08d183c6)
– [AWS VPCの中にサブネットを作成する](https://qiita.com/miriwo/items/9abebd478c53744b1b05)
– [AWS Webサーバー用のセキュリティグループを作成](https://qiita.com/miriwo/items/65e8e7f9f65617d02746)
– [AWS DBサーバー用のセキュリティグループを作成](https://qiita.com/miriwo/items/cd50169047f6c903f6

ECSのスケーリングポリシーについて

# ECSのスケーリングポリシーについて

## スケーリングポリシーの種類
ECSにおいてスケーリングポリシーは下記２種類
１、ターゲット追跡ポリシー
定義したメトリクスとターゲットの値に基づいてスケーリングの調整を行うポリシー。
指定したターゲット値またはそれに近い状態でメトリクスを維持するために必要に応じてタスクの量を増減させる。
２、ステップスケーリングポリシー
メトリクスの値に閾値を設定し、それを超えた際のアラームに対してタスクの増減を行うポリシー。
タスクを増やすパターンと減らすパターンで２種類のアラームをcloudwatchで作成する必要がある。

[AWS]ReactアプリケーションをS3にデプロイするときにyarn buildができない

# 初めに
今回はReactアプリケーションを初めてS3にデプロイしようとしたときに直面したエラーについて綴っていこうと思います。
かなり初歩的なミスなのですが、自分への戒めとして残していきます。

ディレクトリ構成は以下の通り
(dockerにて環境を作っております。)

“`
front
├ app
┃ ├ node_modules
┃ ├ public
┃ ├ src
┃ ├ types
┃ ├ package.json　・・・①
┃ ├ README.md
┃ ├ tsconfig.json
┃ └ yarn.lock
├ node_modules
├ Dockerfile
├ package.json ・・・②
└ yarn.lock

“`

frontディレクトリにてyarn buildを実行。

“` ターミナル
$ cd xxx/front

$ yarn build
“`

すると、下記のエラー発生。

“`
error Command “build” not found.
info Visit https://yarnpkg.com

Cognitoが現在抱えるサインアップに関するバグ(2022/03/04現在)

## 同じ電話番号のユーザが複数同時に作られてしまう

Usernameに電話番号を指定して、SignUpAPIを一度しか叩いていないのに、
ユーザープールのコンソールでその電話番号を検索するとなぜか複数のアカウントが出現！
という事象に遭遇しました。

これを**AWSのサポートに問い合わせたところ、現在かかえるバグ**なのだそうです。
ちなみに、そのユーザープールはサインアップ前のトリガーでLambdaをつかってゴニョゴニョしていたため、
トリガーの設定によるものかと尋ねたところ、それは関係なく確認されているそうです。

(明確にサポート側からバグだと明言されたのは私には初めての体験でした！）

## 知っておこう

こういう事象が発生するということを認識していないと、電話番号が一意であるという前提でシステムを組んでいる場合に問題が発生します。
この挙動を知っていれば一意にするために何か別の処理を加えることで対応はできますね。

## 具体例

私が最初に遭遇したのは以下のような設定のユーザープールでした。

![スクリーンショット 2022-03-04 9.18.21.png](

AWS CodeBuild をローカル環境で実行テストする方法

# 概要
AWS CodeBuild の処理内容を記載した buildspec.yml のファイルをローカルで動作検証する方法をまとめてみました。
今回は、Amazonlinux2（aws/codebuild/amazonlinux2-x86_64-standard:3.0）を利用してビルドします。

# 作業

## イメージ取得

まずは実行イメージとビルドイメージをpullしてきます。

“`shell
$ docker pull public.ecr.aws/codebuild/amazonlinux2-x86_64-standard:3.0
$ docker pull public.ecr.aws/codebuild/local-builds:latest
“`

## 実行エージェントの取得

実行用のスクリプトをダウンロードし、権限を付与します。
“`shell
$ wget https://raw.githubusercontent.com/aws/aws-codebuild-docker-images/master/local_builds/codebuild_