AWSのDMS(Data Migration Service)を使ったDB移行のために、新機能の「移行前評価(Premigration assessments)」を試してみた！

# 前提

ハピタスにはデータベースインスタンスが複数存在しています。
データベースインスタンスごとに役割がおおよそ決められており、効果的に活用できていれば
メンテナンスも部分的にできたり、負荷分散も適切に行えたり、有用な構成だったと思います。

しかしながら、長年様々なエンジニアによって改修が行われ、データベースインスタンス同士の依存関係も大きくなり、
一つのデータベースであれば単純に WEB アプリケーション上で一つのSQLで完結できたはずのものが
php を介して、SQL の問い合わせ結果を使いマージして、複雑な処理を行うため
その処理がボトルネックになってきています。メンテナンスもハピタスのインフラの歴史的な背景の理由などで複雑化しています。

そこで DMS を使って、データベースの統合を進めています。

## 元々

![Untitled Diagram-Page-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/218682/474a443e-ba56-f4c8-e1a3-94f9b634

Elastic Beanstalkのデプロイポリシーまとめ

# Elastic Beanstalkのデプロイポリシーまとめ
AWS デベロッパーアソシエイトを勉強中です。

公式がこちらのページで説明していますが、
文章が分かりづらく、整理のために投稿します。
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html

## 前提
– ELBが1つ
– ELBに4つのEC2インスタンスが紐付いている

## ローリングの時に使用するバッチについて説明
設定の画面で、バッチサイズの割合を決めることができると思います。

その割合と、インスタンス数を掛け算したものが、
バッチのインスタンス数になります。

例
バッチサイズ:25%
インスタンス数:4台
0.25(25%) ×　4(台) = 1(台)

## All at once(一度に全て)
### 説明
名前の通り、全てのEC2インスタンスに対して、
同時にデプロイを行います。

### デメリット
短時間ではありますが、サービスが停止する時間が

【初心者】AWS Cloud Practitioner Essentials (Second Edition) をやった

#はじめに
AWSにはトレーニングの一環として[AWS Cloud Practitioner Essentials (Second Edition)][link-1]というコンテンツが用意されています。
[link-1]:https://www.aws.training/Details/Curriculum?id=34408

レベル感は「基礎レベルのコース」であるため、AWSのプラクティショナーを目指して勉強を始めた方向けくらいだと思います。

実際にこちらを一通り視聴し、学習した結果の所感を書いてみようと思います。

# 行ったコンテンツ
– M0-コースの紹介
– M1-AWSクラウドの紹介
– M2-AWSの主要なサービス
– M3-AWSの統合サービス
– M4-AWSのアーキテクチャ
– M5-AWSのセキュリティ
– M6-料金とサポート
– M7-コースのまとめ
– コースの最後の知識の確認

# 前提条件
– **Amazonアカウント**または**APNパートナーセントラルアカウント**を所持していること。

# 注意事項
– **以下の知識があること（推奨）**

せっかく RAML で API ドキュメントを作ってもローカルでしか閲覧できないのは悲しいよねって話

## はじめに

API ドキュメントの管理を Excel や Word などから [Raml](https://raml.org/) のような API ドキュメンテーションツールに切り替えるチームも増えていると思います。しかし作成した API ドキュメントはプロジェクトを `git clone` してローカルで閲覧する、というようなちょっと残念な方法をとっているチームもあるような気がします。

そこで本記事では、作成した API ドキュメントを AWS にサクッと数分でホスティングする方法をまとめました。本記事では API ドキュメントを対象としますが、ホスティング対象は静的コンテンツであれば何でも構いません。

## 注意

本記事では Route 53 のような **無料利用枠のない** サービスを使うため、静的コンテンツを公開したままにしておくと一月あたり 100 円程度ですが課金されます ( [Amazon Route 53 料金表](https://aws.amazon.com/jp/route53/pricing/) ) 。

もし課金されたくない場合は本記事の内容を実施

aws wafv2の動作確認方法

## ルール
– countモードはブロックは行わず記録のみする
– `Override rules action`は、有効化すると、そのルールのみcountモードになる

## NoUserAgent_HEADERルールの場合の動作確認

– HEADERにUserAgentが含まれていない場合はブロックします。というルール

### ブロック

“`
yuta@DESKTOP-PT34LID:~$ curl https://test.vamdemic.black.jp -H “User-Agent:”

403 Forbidden

herokuでホストしてたlaravelアプリをlightsailに移動してドメイン張り替えとかした作業ログ

1.インスタンス立ち上げ

2.documentroot確認

Terraformのディレクトリパターン集

AWSやGCPのみならず、GitHubやDatadog等、様々なサービスをTerraformでコード化して管理できるようになり、世はまさに大Terraform時代となりました。
そんな時代の中、人類誰もが一度は**Terraformのディレクトリ構造で悩んだ**ことがあるのではないでしょうか？

様々なベストプラクティスが提案されてきましたが、デファクトスタンダードと言えるものが未だ登場していないイメージがあります。

## 背景
なかなかスタンダードな構成が決まらない背景には、以下の要因が影響していると思われます。

### 環境ごとの差異がどれだけあるかは人それぞれ
本番環境とステージング環境は完全に同一の構成であることが理想です。
同一の構成をとることで、ステージング環境では発生せず、本番環境でのみ発生する不具合を減らすことができるからです。

しかし、様々な理由でどうしてもステージング環境と本番環境の間に差異が発生してしまうケースがあります。

– コスト的にインスタンスタイプ、インスタンス数を小さくしなければならない
– 連携するシステムの都合でステージング環境と本番環境でネ

AWS マーケットプレイスによる Veritas NetBackup のデプロイメント 前編

## はじめに
Veritas NetBackup はエンタープライズクラスのデータ保護を実現するための大変パワフルなツールです。本稿では データ保護の基本となるバックアップサーバーをマーケットプレイスから超簡単に構築する方法を紹介します。

##データ保護が必要な理由
まずはこちらの動画をご覧ください！
[](http://www.youtube.com/watch?v=lmt9E0neWq4)

AWSではそのサービスに対して”責任共有モデル”という概念が適用されています。
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
こちらのURLにあるように**お客様のデータ、データの整合性、設定内容、暗号化、トラフィックの保護については全てお客様で責任を持つように定義されています。**AWSが担保するのはAWSのインフラストラクチャであってそのデータではありません。

**したがって、

5年たったらAWS CLIの薄いラッパーコマンドが出来ていた

AWSを使い始めた頃からAWS CLIのコマンドを打つのが面倒になると作成していたスクリプトがある。自分のMacでしか動かすつもりがなかったが、Macを交換するタイミングでGitHubに上げた。
今どき使わない機能もあるが1年に1,2つくらい追加してきた感じ。出来はよくないが面倒だと思った時に追加してきたので面倒がなくなった。面倒なときにしか追加されないのでほとんどのawsコマンドが網羅されていない。

同じようなコマンドが同じ名前で存在したのでネーミングセンスがないっぽい。
左手で完結したかっただけなんだ・・・
https://github.com/ryo0301/saw

# 特徴

– awsコマンドと同じような使い方
– bashで書かれている
– コピペ駆動開発なので作り方を思い出す必要がない
– エラー処理が雑で `Ctrl-C` で止まらないことがある
– 自分のことしか考えていないので他人のPCで動かない可能性がある
– `.doc` にヘルプが書けるが自作なので見ない
– コンプリーターがある(bashのみ)
– aws-cli, jq, pecoに極度の依存。コマン

【今日から始めるAWS】S3に静的ウェブサイトをホストする

#はじめに
30代未経験からエンジニア転職をめざすコーディング初学者のYNと申します。お読みいただきありがとうございます。
20年に入ってコーディングの勉強を始め、この記事を書く2時間ぐらい前にAWSアカウントを作成しました。何から勉強すべきか全くわかりませんので、とりあえず目についたチュートリアルを進めて行きます。

#今回やったこと
[チュートリアル](https://aws.amazon.com/getting-started/hands-on/build-modern-app-fargate-lambda-dynamodb-python/module-one/)に従い、とりあえず静的なウェブサイトをS3にデプロイしました。
「20分で終わる」と書かれていましたが、しっかり2時間かかりました。
また、今回は`Cloud9`でなく、自前のPC（mac）上で開発を進めていきます。
awscliでs3バケットの中身を全部ダウンロードする

– `recursive` で再帰的

“`
aws s3 cp s3://aws-bucket . –recursive
“`

ECRでKMSがサポートされるようになった

# アナウンス
https://aws.amazon.com/jp/about-aws/whats-new/2020/07/ecr-supports-encryption-images-aws-kms-keys/#:~:text=Amazon%20Elastic%20Container%20Registry%20(ECR,stored%20in%20your%20ECR%20repositories.&text=When%20this%20feature%20is%20enabled,and%20decrypts%20it%20when%20pulled.

# 仕様
https://aws.amazon.com/jp/blogs/containers/introducing-amazon-ecr-server-side-encryption-using-aws-key-management-system/

# ドキュメント
https://docs.aws.amazon.com/AmazonECR/latest/userguide/encryption-at-rest.html

AWS EC2にNginxをインストールする

# はじめに
## 環境
– EC2インスタンス作成済み
– Amazon Linux 2 AMI (HVM), SSD Volume Type
– 64 ビット (x86)
– タイプ：t2.micro

# やったこと

## EC2サーバーでの操作

### 接続

“`
$ ssh -i xxxx.pem ec2-user@パブリックIP（またはDNS）
“`

### amazon-linux-extrasの確認

amazon-linux-extrasを使ってインストールできるパッケージの確認をします。

“`
$ which amazon-linux-extras
$ amazon-linux-extras

0 ansible2 available [ =2.4.2 =2.4.6 =2.8 =stable ]
2 httpd_modules available [ =1.0 =stable ]
3 memcached1.5

[AWS] NLB経由でFTP接続する際の注意点

# 内容
* AWSにおいて、ロードバランサー配下のEC2でFTPサーバを稼働させて外部からFTP接続する際の注意点
* FTPはパッシブモード、暗号化方式はexplicit(明示的)モードを使用する
* FTPサーバは、vsftpdを使用する

# 構成

# こうしたかった理由
* EC2はウェブサーバとして使用していて、ACMを使用してサーバ証明書を安価に使用したかった（ACMはEC2には使えない）
* NLBをかますことで、EC2に外部IPアドレスを付与させないようにしたかった

# NLBの設定
1. リスナーの追加
制御ポート：21(TCP)
データ転送用ポート：60001(TCP)
データ転送用ポート：60002(TCP)
データ転送用ポート：60003(TCP)

2. ターゲットグループの追加
　1．で設定したリスナーに対し

AWS Lambda with EFS で MeCab, NEologd & CaboCha を動かす （2020年7月時点）

# はじめに
過去に以下のような記事を書きました。
[AWS Lambda で MeCab を動かす (2018年9月時点）](https://qiita.com/rtaguchi/items/e6cb594196fa8186e9a2)

この記事で最後に
>「Neologdも入れたかったけれども、Lambdaのtemp領域の制限でアウト。
>（中略）
> そうこう言っている間にLambdaのtemp領域の制限が一気に3GBくらいになってくれないかな。

と書いて終わりました。それから約2年。Lambda の temp 領域制限は変わりませんが、代わりに（？）Lambda から EFS にアクセスできるようになりました。これでようやく念願の NEologd を手軽に Lambda 上で動かせるようになりましたので、その方法をまとめます。

まぁ、ホントに EFS に MeCab と NEologd を突っ込むだけなので特別なことはしていません。

# NEologdとは
正式には`mecab-ipadic-NEologd`という名称で、多数のWeb上の言語資源から得た新語を追加すること

[AWS] ReactアプリでCognitoユーザープール認証を行ってみる

# Cognitoの基本

「[[AWS] Cognitoの基本まとめ](https://qiita.com/herohit-tool/items/98bdf8bf073259ba208a)」をご覧ください。

# 前提
今回はReactを使用するので、事前に

– Node.js
– npm

をインストールしておいてください。
あと、AWSアカウントの用意もお忘れなく。

# 準備
## ユーザープールの作成
まず、マネジメントコンソールにログインして、サービス「Cognito」の画面を表示します。
まだユーザープール、IDプールともに未作成のはずなので、下記のような画面になると思います。

ここで「ユーザープールの管理」ボタンを押します。

ドメイン駆動設計のミッション層を設計する手法を紹介

今回の記事では、前回の**「エリック・エヴァンスが提唱したアーキテクチャの4層モデルを拡張する」**の記事で紹介した
5層アーキテクチャモデルの**ミッション層**を設計する方法について紹介する。

前回の記事について以下のURLを参照
https://qiita.com/aLtrh3IpQEnXKN7/items/b7fe2014ccefcbb9e458


#ミッション層を理解する鍵は抽象表現主義
**抽象表現主義**とは人間の心象世界を絵画に表現することを目指した表現技法。
現実の世界に基づい絵画を描写する**写実主義**とは対極に位置する心象風景をモチーフに絵画を記載する手法。
**抽象表現主義**は**オートマティスム**と呼ばれる「何か別の存在に憑依されて肉体を支配されているかのように、自分の意識とは無関係に動作を行ってしまう現象

AWS IAM メモ

後で書き直す

IAM:AWS全体の認証認可基盤

IAM user
アカウント作成時のルートユーザーとは異なる作成されたユーザー
権限を制限したIAM userを付与するのが基本
policyやroleをアタッチできる
しかしIAM groupへpolicyやroleをアタッチして使うのがベストプラクティス

IAM group
roleやpolicyをアタッチ可能な集合
ここにユーザーを所属させるのがベストプラクティス

IAM policy
デフォルトで用意されているAWSへのアクセス権限

IAM role
EC2やlamdaにアタッチして権限付与ができる
内部的には使い捨てのキーとパスを発行しているらしい

AWSの監視入門したのでCloudWatchについてざっくりまとめ

ブログからの転載です

—-

最近こちらのハンズオンをちらほら進めております.
https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/:embed:cite

今日は監視編をやってみましたが, CloudWatchって色々機能あって驚いたのでメモしておきます.
全て網羅しているわけではないです.

# まとめ

| サービス | 用途 | 備考 |
| —- | —- | —- |
| メトリクス | ちょい調べたい ときに使える | |
| ロググループ | インサイトでクエリの対象になる. mysqlでいうテーブル的な. | ロググループへログを集める設定が別途必要 |
| インサイト | クエリ書いてログをより好きなように見れる.(4xx系のエラーだけにフィルタしたり)||
| アラーム | 何か異常起きたら知らせれる. | SNS使って知

Prisma CloudでAWSリソースの脆弱性管理（Lambda編）

Palo Alto社のセキュリティ製品、Prisma CloudをでAWSリソースの脆弱性管理を行ってみます。
今回は、Lambdaに対して、脆弱性診断をかけてみます。

# 準備
Prisma Cloudアカウントがない方は、以前の投稿をご参照ください。
https://qiita.com/Hiroyama-Yutaka/items/0c5205749bc54e3ec056

# 脆弱性診断
Computeメニューに存在します。
今回は、（AWS Lambda）に対して、実施してみます。

### 準備
手順はこちら。
https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/vulnerability_management/serverless_functions

適当にLambdaファンクションを作成。今回はSAMでPythonベースのファンクションを作りました。
今回は、意図的に脆弱性のあるライブラリバージョン（numpy1.16.0, request2.2.1）を使用して