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

AWS関連のことを調べてみた2022年04月02日
目次

AWS公式資料で挑むSCS認定(25)-こんな時どうする(全分野その2)

##### [前回] [AWS公式資料で挑むSCS認定(24)-こんな時どうする(全分野その1)](https://qiita.com/mingchun_zhao/items/d4e6cf1651d52523fe65)

## はじめに

AWS資格11冠制覇の名人(同僚)の[ブログ記事](https://qiita.com/Sunameri_Beluga/items/1559d33eb44b7a790a8f)から、
「公式ドキュメント(理論)とハンズオン(実践)のクイックな往復こそ最も有効な試験対策」

自分のやり方あっていたようです。よっしゃ、試験準備続けよう。
引き続き、AWS公式資料を参考に「こんな時どうする」の追記です。

## 分野1: インシデント対応

– 外部からIAMアクセスキーを悪用した不正アクセス発生、どのような操作が行われたか特定したい
– AWS CloudTrailを使用し、IAMアクセスキーと関連付けされたユーザの操作履歴を確認
– AWS CloudTrailは、インフラストラクチャ全体のアカウントアクティビティをモニタリング/記録し、

元記事を表示

GuardDuty有効化から無効化まで

本番運用だと無効化することもないと思ったので、参考までに無効化までやってみます。

# 1.Amazon GuardDuty とは

GuardDuty は、AWS 上で発生しているログを自動的に収集し、機械学習や、悪意のある IP アドレスやドメインのリストなどの脅威インテリジェンスフィードを利用して、怪しい動きを検知する。

Amazon GuardDuty 脅威検知のために使用するログは以下の5種類。

– AWS CloudTrail
– Amazon S3 データイベント
– VPC Flow Logs
– DNS logs
– Kubernetes 監査ログ(New!)

# 2.設定
基本有効化するだけ。GuardDutyを有効化すれば、上記5種類のログが内部的に自動で収集開始される。
ただし、GuardDutyが内部的に生成・検出したログはユーザがコンソール上から閲覧することができないため、インシデント発生時にGuardDuty画面からしかログの参照ができない。このため、VPC フローログ、 Cloud Trail 監査ログは自身で別途有効化しておくことが推

元記事を表示

カスタムリソースを使わずにCDKでクロスリージョンな WAF + CloudFront + S3 を構成する

# WHAT
S3 Bucket を ap-northeast-1 に 作成し、CloudFront の Origin に指定し、その CloudFront に WAFv2 の WebACL を assosiate します

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2418911/d337fcf8-471c-7fe3-501b-4ec3fe91a8c6.png)

# WHY

CDKで構成する場合、下記のような構成をとることがあると思います
1. WAF を先に us-east-1 で作成する
1. ap-northeast-1 に S3 Bucket を作成し、CloudFront の Origin に指定し、さらに WAF を設定する

このときに手順の 2 では ap-northeast-1 に S3 Bucket を作成する関係上、CloudFront に渡す WAF の WebACL を us-east-1 から引っ張ってこようとすると cross-region err

元記事を表示

【インフラ構築】MENTAにてフォローしていただいた事を振り返ります

## 背景
Laravelで作成したポートフォリオのAWSデプロイに苦労していた時、**MENTAにて@adachin0817さん**よりお声がけいただき、インフラ構築のフォローをしていただきました。

以下のプランよりフォリーしていただきました。

https://menta.work/plan/442/5218

https://speakerdeck.com/rvirus0817/menta-sabaenziniajiao-yu-nituite?slide=22

## 構築過程
まず最初に開発環境構築に使用すたDockerの設定があまりよろしくなかったので、
開発環境の再構築から始めました。
(本番環境と設定を合わせる目的もあります)

### 開発環境

**開発環境にはDockerを使用しています**

– **Docker 20.10.12**
– **Docker Compose v2.2.3**
– **Docker image**
– **laravel-app(appコンテナ)**
– **php7.4-fpm-alpine(nginx,p

元記事を表示

【AWS+Laravel】本番環境構築についてまとめてみました

## 背景

Laravelを使用して開発したポートフォリオのデプロイをする目的で、AWSで本番環境を構築しました。
AWSを使用した理由は、インフラの構造をしっかりと理解したかったからと、
実務に入るとプログラミングだけではなく、サーバーやネットワークについての知識も必要だろうと考えたからです。

– **開発環境構築(Docker+Laravel6)については以下にまとめました**
**[【Docker+Laravel6メモ】開発環境構築についてまとめてみました](https://qiita.com/yuuichimizuta/items/85015a63a8e53c058cb2)**

## 本番環境について

– **AWS:EC2, RDS, VPC, Route 53, ALB, ACM, S3, CloudWatch**
**EC2 : nginx, php-fpm**
**RDS : mysql 8.0.27**
– **CircleCI**
**deploy job : git pullデプロイ自動化**
**slack orb : Slackデプロイ結果通知**

元記事を表示

AWS インスタンス 初回ログイン

# 概要
AWS EC2インスタンスを久しぶりに作って、初回ログイン時に、忘れていたことを備忘録として記載

# 前提

* EC2インスタンスを作成済みであること
※ OSは、[ubuntu OS]を使用していること。

# 目次

Ⅰ. 権限設定
Ⅱ. ログイン方法

## Ⅰ:権限設定

まず、インスタンス作成した際に、作成した「秘密鍵」の権限の修正が必要です。
権限は「600」でないと「秘密鍵」の権限が広すぎると怒られる。

“`
chmod 600 XXXXXXX.pem
“`

## Ⅱ:ログイン方法

“`
ssh -i XXXXXXX.pem ubuntu@XX.XXXX.XXX(IPアドレス)
“`

ここで注意が必要で、ubuntuで作成した場合は、ユーザー名=ubuntu。
一方、amazon_linuxで作成した場合のユーザー名=ec2-user。

ここら辺は、よく忘れがち!!!
※CentOSに関しては、分からないので未記載です。ご存知の方、いらっしゃれば教えてください。

# 終わりに

基本、上記2点さえ、間違わなければスムーズにログインできる

元記事を表示

Lambdaを定期実行する

# 背景・目的
– [VPC内のLambdaからインターネットに接続する](https://qiita.com/zumastee/items/21c77e66156a8d26856e)で作成したLambda関数を定期的に実行する。
– 定期実行には、EventBridge Ruleを利用してみる。

# 内容
## 実装
### 1. EventBridgeルールの作成
– EventBridgeのルールをクリックしトップ画面から、「ルールを作成」をクリックする。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/768de97d-5740-9d9b-52a7-8d8ba39fc58b.png)

### 2. ルールの詳細
– 名前と説明、イベントパス、ルールタイプ「スケジュール」を選択して「次へ」をクリックする。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/206276/6

元記事を表示

AWS CLIコマンドでS3オブジェクトの中身を見る方法

S3に関するaws cliのコマンドには `ls` や `cp` は存在するが `cat` コマンドは存在しない。

https://qiita.com/uhooi/items/48ef6ef2b34162988295

catコマンドは無いのですが、catと同様にファイルの中身を見るコマンドがあります。

# s3オブジェクトの中身を見るコマンド

cpコマンドのコピー先として `-` を指定するとオブジェクトファイルを見る事ができます。

“`
$ aws s3 cp s3://app-s3-server-access-log/2022-04-01-05-13-25-47E6B98F6C4197 –
“`

元記事を表示

Amazon Kinesis Video Streams WebRTC

# Amazon Kinesis Video Streams WebRTC基本情報
## 用語定義

Signaling channel
WebRTCではシグナリングメッセージを交換することにより、ピアツーピア接続における検出、設定、制御、終了が可能になります。
シグナリングメッセージはメタデータであり、メディアコーデックやコーデックパラメータといったメディア情報や相互のアプリケーションをライブストリーミングで接続するためのネットワークパス情報が含まれます。
シグナリングチャネルは、複数のアプリケーション間をone-to-fewモデル(一つのマスタが複数のビューアと接続)で接続します。
マスタは、ConnectAsMaster APIを、ビューワはConnectAsViewer APIを使用し接続します。
Peer
Kinesis Video Streams with WebRTCを通じて、リアルタイムストリーミングを行うデバイスやアップりケーション(モバイル端末やWebアプリ、Webカメラなど)
元記事を表示

Amazon Route53 主なルーティングポリシー

# はじめに
Markdown記法でテーブルを作ってみた。

# 主なルーティングポリシー
| ルーティングポリシー | 説明 |
|:-:|:-:|
| レイテンシールーティング | 最もレイテンシーが低いリソースへルーティングする |
| 加重ルーティング | 複数のリソースに対して加重度を設定し、指定した比率に応じて処理を分散するようにルーティングする |
| 位置情報ルーティング | 接続クライアントの場所に基づいて、地理的に近い場所へルーティングする |
| フェイルオーバールーティング | ルーティング対象となるリソースのヘルスチェックを行い、利用できるリソースへルーティングする |
| シンプルルーティング | 設定されたレコードの情報に従って、ルーティングする |
| 地理的近接性ルーティング | ユーザーとリソースの地理的場所に基づいてトラフィックをルーティングする |
| 複数値回答ルーティング | 最大8つからランダムに選ばれた正常なレコードを使用し、Route53がDNSクエリに応答する |

元記事を表示

VPC内のLambdaからインターネットに接続する

# 背景・目的
インターネット上のAPIを呼び出して、データを取得したい。
これを、Lambdaで実現する方法を試す。

# 内容
## 概要
– [Qiita API](https://qiita.com/api/v2/docs#get-apiv2tags)の“/api/v2/items“を使用して記事の一覧を作成日時の降順で取得する。

## 前提
– ネットワーク(VPC、サブネット、ルートテーブル)、インターネットゲートウェイ、NATゲートウェイなど正しく設定されているものとする。

## 実践
### Lambda関数の作成

– 上記の他に、予め作成したVPC、サブネット、セキュリティグループを指定する。

### コード
– 以下のコードを書いて、Deploy&Testを実行。
“`
import ur

元記事を表示

S3に格納されたファイルを検知し、EC2上のシェルを自動実行する

### S3に格納されたファイルを検知して、EC2上のシェルを自動実行する(&SNSにて、結果をメールに送信する)

(やった手順)
1.(EC2上)シェルの作成
2.(EC2上)シェルの動作確認
3.(AWS)S3バケットの作成
4.(AWS)Lambdaの作成 & IAMの設定
5.SNSの設定(トピックの作成 & サブスクリプションの作成)
6.動作確認

(省略していること)
・EC2へのsshの接続手順(teratermなどで、接続済みの状態で記載してます)
・EC2のインスタンス名などは、知っている状態で記載しています

### 1.(EC2上)シェルの作成【test.sh】
(※今回は環境の都合上、「hulft」ユーザで作成しています。)
(※合わせる必要がある箇所は、※表記していきます)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2518095/9e13d193-f6c9-ba13-ecde-0e56a09e630b.png)

(【test.sh】の中身)
“`

元記事を表示

VPCドメインのOpenSearch dashboardにアクセスする方法

# 初めに:OpenSearchのドメイン

OpenSearchを構築するときは
– パブリックドメイン
– VPCドメイン

のどちらかを選択して構築します。
パブリックドメインで構築するとインターネットに接続されたあらゆるデバイスからアクセスできるような形でデプロイが行われますが、VPCドメインですと指定したVPCの中でOpenSearchがデプロイされますので、OpenSearchにアクセスするときはプロキシを用意するなど一手間が必要になります。
セキュリティを考慮したプロダクション環境ではVPCドメインで構築されることもよく発生すると思います。

# 今回実施すること

OpenSearchにはOpenSearch dashboardというブラウザからアクセスするGUIが提供されています。
VPCドメインでデプロイされたOpenSearch dashboardにアクセスするときは以下のような方法が考えられます。

– VPC内のEC2インスタンスにプロキシを立ててPort Forwardingする
– Client VPNでVPCにアクセス
– VPCにWorkspaces

元記事を表示

[AWS Kendra]Slackをデータソースとして設定できるようになったのでやってみた

## AWS Kendraとは
> 自然言語処理および高度な検索アルゴリズムを使用して非構造化データおよび構造化データを検索できるようにする、高精度でインテリジェントな検索サービスです

要するに自然言語で色々検索できちゃうよ〜〜〜っていうすごいやつです

## 今回行うこと
3/23にデータソースとしてSlackを設定できるようになったのでそちらを試してみたいと思います!

https://aws.amazon.com/jp/about-aws/whats-new/2022/03/amazon-kendra-slack-connector-messaging-search/

## やってみる

### 事前準備
検索を行うSlackで適当にメッセージを送信しておく

今回は事前に、英語の適当な文字列,「AWS SAAの試験ガイド英語版のPDF」を送っておきました
![スクリーンショット 2022-04-01 10.30.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/501320/17616be

元記事を表示

Web負荷テストツールの紹介(JMeter・AWS分散負荷テストソリューション)

# はじめに
社内向けにWebサイト・Webシステムの負荷テストツールであるJMeterとAWS分散負荷テストソリューションの基本的な使い方をまとめた資料を作成したのですが、どちらも汎用的なツールなのでQiitaにも投稿することにしました。
メモ的な要素が強いので、画像が少なくツールの説明としてはあまり優しくありませんが、そのあたりはご了承ください。

# JMeterの使い方
## インストール
以下のWebサイトで、Binariesのzipファイルをダウンロード&解凍
[Apache JMeter – Download Apache JMeter](https://jmeter.apache.org/download_jmeter.cgi)

![jmeterinstall.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2528939/8cb9172d-a941-7633-3ec2-c08f093f4b4d.png)

## 起動
JMeterを展開したフォルダ/binにあるjmeter.

元記事を表示

Amazon ECS & Fargate と Docker on AWS CICDの学習まとめ(超初心者向け)

# これからはAWSのFargateだ!
ということで学習しながら設定の流れをメモとして随時更新します。

学習内容 ECS & Fargate, Load Balancing, Auto Scaling, ECR, CICD for ECS
最終的には、Rubu on Rails をFargateで動かすところまで目指します。

## AWSの準備&ユーザ設定
* AWSのアカウント作成
* IAM ユーザーの設定
ルートユーザ→Adominユーザ
* AWS アクセスの種類を選択(全部選択)
* アクセス許可の設定
→既存のポリシーを直接アタッチを選択
→AmazonECS_FullAccessを選択
* タグの追加 (不要)
* 認証情報(コンソールのサインインリンク保存)
* アクセス権限の追加
→既存のポリシーを直接アタッチを選択
→AdministratorAccess

## Fargateの設定
* リージョンを選択(東京)
* Elastic Container Service (ECS)を選択
* 2022/04時点では、ECS

元記事を表示

【AWS環境構築メモ⑩】EC2インスタンスにLaravel環境を構築してアプリのデプロイをする

## 0.はじめに

**作成したEC2インスタンスにLaravel環境を構築します。**
**また、RDS(MySQL)との接続とチェックも行います。**

**今回のタスクでAWS本番環境構築はおおよそ完了します!!**

**EC2 : Nginx, php-fpm**
**RDS : MySQL**

## 1.前回の記事

**[【AWS環境構築メモ⑨】RDSを作成する](https://qiita.com/yuuichimizuta/items/ac43d5e2be0c1d8f1bc2)**

## 2.前提条件

– **AWSアカウント作成済み**
– **リージョンはアジアパシフィック(東京) ap-northeast-1**
– **VPC作成済み**
– **セキュリティーグループ作成済み**
– **EC2インスタンス作成済み**
– **SSL証明書発行済み**
– **ELB作成済み**
– **Aレコードのエイリアス作成済み**
– **RDS作成済み**
– **RDS作成時のマスターユーザー名、パスワード、DB名をメモしている**

## 3.作成手順

元記事を表示

AWS認定試験11冠達成したので、更新時の自分に向けてアドバイスを残す

# はじめに

いつの間にか、 AWS 全冠制覇は珍しいものではなくなりましたね。
合格に特化した RTA 的な記事や詳細な学習方法について記載された記事もたくさんありますので、本記事ではタイトル通り、数年後の更新のため、自分に向けたアドバイスを残します。

# この記事が役に立つ人

– 自分
– 全冠制覇目指す人も若干役に立つかもしれません

# 受験履歴

勉強は長くても 1 ヶ月くらいがダラけなくて丁度よかったです。
以下を見ると、更新時には 15 hくらい勉強すれば、五分五分で合格点ギリギリには達しそうです。

|試験名|取得日|スコア|勉強期間|正味勉強時間|
|:———–|:———–|:———–|:———–|:———–|
|CLF|2021/1/11|921|1ヶ月||
|SAA|2021/3/21|777|1ヶ月半||
|SAP|2021/5/23|895|1ヶ月|80h|
|SOA|2021/7/17|839|1週間|2h,公式サンプル問題のみ(実務と被りが多い)|
|DVA|2021/8/8|93

元記事を表示

営業職からエンジニアに転向してAWS資格11冠制覇したので振り返ってみる

# はじめに
先日、AWS認定資格11冠を達成しました。
(最後に取得したAWS Certified Machine Learning – Specialtyの会場 高田馬場駅をとても好きになりました)
また、AWS認定資格取得で得た知見を大いに活用することができ、
昨年は2021 APN AWS Top Engineersにも選出されました。

11冠を目標に走ってきた3年半の取り組みを振り返ってみたいと思います。

この記事が、AWS認定資格にこれから取り組む人だけでなく、
他の認定資格を取得されようとしている方や未知の領域にチャレンジしようとしている方、
何か高い目標に向かって日々努力されているロマンティックな方など、
自己実現を遂げようとする全ての人に少しでも響けば嬉しいです。
※結構ざっくりした内容です
※試験対策的な部分はがっつり別の機会にもう少し詳細に書こうと思います

# 経歴とAWS認定資格
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2610137/c7d1ca12

元記事を表示

Amazon Athena どうしても日本語カラムを使ったテーブルをcliでCREATEしたい場合

# この記事の目的
 本記事では、Amazon Athenaのcliで日本語カラムがあるテーブルを作成する方法を記述します。備忘録です。
 Amazon Athenaに限らずDBテーブルで日本語カラムを設定するケースは殆どありませんが、運悪くそのような場面(SESで案件の規定がそうなっていた、など)に出会った時に活用していただければありがたいです。

# 使用する環境
vagrant(amazonlinux2) amazon athenaを使用できる環境構築は完了しているものとする(awscliのインストールなど)。

# 結論
日本語カラムはバックスラッシュ + バッククォーテーションで囲みます。
その他注意点として、WITH SerDePropertiesのカッコ内はダブルクォーテーションではなくシングルクォーテーションを使うほうが望ましいです(エスケープしようとするとぐちゃぐちゃになるため)。

下記は日本語カラムを用いたテーブル作成クエリです。s3に保存されたcsvをデータとして使用します。

“`テーブル作成クエリ
aws athena start-query-execut

元記事を表示

OTHERカテゴリの最新記事