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

【AWS】NLBのターゲット先にオンプレのファイルサーバを指定する時の注意点

## 結論
NLBのターゲット先にオンプレサーバを指定するときは、UDPプロトコルを使用することができないです。

https://aws.amazon.com/jp/about-aws/whats-new/2019/06/network-load-balancer-now-supports-udp-protocol/

“`
Network Load Balancer はインスタンスターゲットタイプをサポートしており、AWS CloudFormation テンプレートで使用できます (IP ターゲットタイプと PrivateLink は現在サポートされていません)。
“`

例えば、オンプレ環境にあるWindowsのファイルサーバをターゲットグループに指定するときは、137~139のUDPプロトコルを含めているかもしれませんが、それができないようです。
※最近のWindows Sever OS(2016以降)であれば445のTCPプロトコルさえあれば十分です。
ただ、それ以前のOSの場合は注意が必要そうですね。

## システム構成
![nlb-for-onprem-fs.jpg

AWS ECS Fargate を選定するシチュエーション、メリット、デメリットを超簡単にまとめてみた(対EC2)

## この記事を書くまでの経緯
herokuにコンテナデプロイしてみたぞ！
次はEC2にデプロイしようかな？
でもAWS Fargateなんてのもあってコンテナデプロイできるみたい。ほー、しかもオートスケーリング機能なんてのもあるのか。
ちょっと採用するメリットデメリットを調べてみようかな？というただのまとめメモ。

## この記事は
主にEC2とFargateを比較した時に生じる差異に関してまとめています。ECSとは？Fargateとは？という点にはあまり触れていません。
(ちなみに筆者は現在進行形でECSの勉強中ですので間違いがあっても悪しからず)

## メリット
– EC2の場合、OSやDocker、ミドルウェアの構築や設定が必要だが、Fargateではその必要がない。開発環境で使用しているコンテナをそのまま本番環境で運用できる。
– EC2インスタンスやクラスターの管理をしなくてもよい。
– オートスケーリング機能があり、コンテナ数をオートスケールしてくれる。

## デメリット
– シェルに入れない。私は開発環境でシェルにいつも入るので不便だと感じます。EC2を意識しない

AWS Cloud Practitioner 合格体験記

## はじめに
先日、AWS Cloud Practitionerを受けてきました。クラウド系の資格は初受験です。
無事に合格できたので、合格につながるであろうノウハウを共有しようと思います。
既に世に出回っている情報が多いかとは思いますが、少しでもどなたかの役に立てば幸いです。

## 経歴
– エンジニア歴は約6年
– 最近は開発はほとんどしていない
– クラウドはGCP、Azureを少々
– ちょっと毛色が違いますがHerokuも触ったことがあります
– AWSは触ったことなし
– 受験までに一切触りませんでした
– 取得済み情報系資格
– 応用情報技術者
– セキュリティスペシャリスト（情報処理安全確保支援士）
– データベーススペシャリスト
– Python 3 エンジニア認定基礎試験

## 受験日程

– 2022年2月19日10:00～
– テストセンターで受験
– その場で合否は発表、当日夜には点数が公開
– 832点で合格

## 試験概要
https://aws.amazon.

一番簡単な CDK Deploy

# はじめに
最近AWS CDKを触り始めたのですが、デプロイまで簡単に行う例が見当たらなかったので、「IAMユーザを作るだけ」を例にして記事にしました。

# 用意する環境

Cloud9を使いましたので、PCはブラウザのみ。
言語はTypeScriptで行いました。

## 環境構築
Cloud9であれば中にすべて入っていましたので、何もインストールする必要ありませんでした。

– Cloud9作成
– デフォルトVPC
– デフォルトIAMロール
– インスタンスタイプはメモリが2GB以上
– Node.jsはインストール済み
– AWS CDKもインストール済み

# やったこと

## CDKのバージョン確認
“`
cdk –version
“`

最新バージョンは以下を確認

https://github.com/aws/aws-cdk/releases

## CDKのアップデート
– 参考

https://www.bioerrorlog.work/entry/cdk-updates#Cloud9%E3%81%A7%E

CloudFormationによる環境構築にCIパイプラインを通す

# 1. はじめに
CloudFormationによるIaC開発を行う時、毎度毎度スタック更新コマンドを打つのはちょっと面倒くさいなーなんて感じてる方。いらっしゃいますよね??
そんな時はCI機能を導入するのがオススメです！
パイプラインを通すことでGitHubへのpushから変更セットの作成までを自動化することができます。

Ciとか聞くと、「CI/CDとかコンテナのやつでしょ?」「なんか難しく感じる..」等と思うかも知れませんが、CIもテンプレート化してしまえば一撃で実装可能ですので、是非この機会にCIに触れてみるのはいかがでしょうか。

本記事ではCoudFormationを利用して、シンプルなWeb環境にCIパイプラインを通してみます。

# 2. 概要
本記事の概要を以下に記載します。

## 2.1 構成図

##

AWS CLIでスイッチロール

CloudShellでスイッチする方法と、ローカルにインストールしたAWS CLIでスイッチする方法をやります。

– 複数アカウントの準備は[おひとりさまOrganizationsやってみた](https://qiita.com/emiki/items/f68bec2ef6f5d3dfe14f)参照。
– スイッチロールするためのユーザ・ロール・権限の準備は[AWSマネジメントコンソールでスイッチロールする](https://qiita.com/emiki/items/bfb900fff199ecdf455d)を参照。

# 0.事前準備
今回はアカウントA（スイッチ元）からアカウントB（スイッチ先）にAWS CLIでスイッチロールする。
– アカウントA（スイッチ元）
– IAMユーザ：AccountA_user
–

【AWS環境構築メモ⑤】EC2インスタンスを作成する

## 0.はじめに

前々回作成した**VPCのパブリックサブネット**に**EC2**を設置していきます。

– **EC2**

「Elastic Compute Cloud」の略称。AWS上に仮想サーバー設置して操作できる。
EC2では仮想サーバの事を「インスタンス」という単位で扱い、
この中にアプリを設置して操作できるようになります。


## 1.前回の記事

**[【AWS環境構築メモ④】セキュリティーグループを作成する](https://qiita.com/yuuichimizuta/items/5d3b9e4872ad8ae1db4f)**

## 2.前提条件

– **AWSアカウント作成済み**
– **リージョンはアジアパシフィック(東京) ap-northeast-1**
–

AWS Cloud9でJupyter labの環境を構築する

# 背景・目的
[AWS Cloud9を試してみた](https://qiita.com/zumastee/items/312d20594b7eecbd533d)で構築した環境にJupyter labをインストールする。

# 内容
## JupyterLabとは
> JupyterLab is the next-generation user interface for Project Jupyter

– Project Jupyterの次世代ユーザーインターフェイスらしい。

> JupyterLab will eventually replace the classic Jupyter Notebook.
– Jupyter Notebookから最終的に置き換わるようだ。

## 実践
### インストール
– [Installation](https://github.com/jupyterlab/jupyterlab#installation)を参考にインストールする。
“`
$ pip install jupyterlab

AWS Cloud9でCodeCommitを利用する

# 背景・目的
[AWS Cloud9を試してみた](https://qiita.com/zumastee/items/312d20594b7eecbd533d)で作成したCloud9環境に、CodeCommit環境を構築する。

# 内容
## 事前準備
### リポジトリを事前に作成する。

### Gitのバージョンを確認する
– CodeCommit は Git バージョン 1.7.9 以降をサポートしている。

“`
$ sudo yum -y update
$ git –version
git version 2.32.0
$
“`
### Git Configで環境を設定する
“`
$ git config –global user.name “XXXXX”
$ git config –global

AWS Cloud9を試してみた

# 背景・目的
– 自分のPCにソフトウェアをインストールしたくないため、クラウドで環境を構築する。

# 内容
## 概要
### Cloud9とは
– AWS上のIDE（統合開発環境）。
– 以下の機能を有する。
– リッチなコード編集エクスペリエンス
– 複数のプログラミング言語、ランタイムデバッガ、および組み込みターミナルをサポート
– クラウドでソフトウェアのコード作成、ビルド、実行、テスト、デバッグに使用するツールが含まれている。
– ウェブブラウザを通じてアクセスする。CLIでもアクセスできる

### 仕組み

1. ブラウザからアクセス
1. コンピュート（EC2 or 独自サーバ）に接続
1. 作業内容はリポジトリ（CodeCommit or 独自リポジトリ）に保存

### Cloud9で

AWS LambdaとAPI Gateway・簡単で早いAPIデプロイ

### Tactico

　私は先日、[趣味とビジネスが半々のプロジェクトTactico](https://www.tactico.jp/)をβリリースしました。
　これは株価の表示とスクリーニングのためのツールで、こんなスクリーンショットです。


　こいつのバックエンドはAWSで、主に **Lambda** と **API Gateway** で構成されてますが、これはAWS入門者向けにちょうどいい記事になりそうなので整理して書いてみることにしました。このグラフィックも自信作なんですがそれは別の話として

AWS Schema Conversion Tool とは

## 勉強前イメージ

DBに関係ある系でconversionやからスキーマを変換するやつ？

## 調査

### AWS Schema Conversion Tool とは

AWS Schema Conversion Tool 略して SCT ということもあります。
こちらはスタンドアローンアプリケーションになっており、Windows Serverにインストールしたりします。

SCTを使用すると、データベースエンジン間で既存のSQLスキーマーを変換できます。
どういうことかというと、データベースの移行を行う際移行にあたりどれくらいの難易度なのか、またDMSと連携すると実際データのコピーも可能です。
特に机上での検討を行う際の資料として評価レポートを作ることができます。
以下のような難易度で評価されます。

– 自動変換
– 簡単なアクションが必要(1h程度)
– 複雑なアクションが必要(4h程度)
– 大規模なアクションが必要(4h以上)

また、それぞれ全体のどれくらいか自動変換できるのか や 自動変換ができない場合は詳細での原因などが提示されます。

変換等はできますが、パ

AWSマネジメントコンソールでスイッチロールする

スイッチしまくってやるよ～

# 1.準備
アカウントAのユーザでアカウントBのロールを引き受け、アカウントAのユーザでアカウントB内のリソースを操作する。


## 1-1.アカウントB側の準備（スイッチ先）
アカウントBにロールを作る。IAMのサービス画面から[ロールを作成]をクリックする。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1723719/81bf3992-a706-9e65-ada1-

[AWS SAM] 1つのtemplate.ymlから複数環境へのデプロイ

# 方針

– 参考にさせて頂いた記事によると、1ソース(1つのtemplate.ymlなど)から複数環境にdeployしたい場合次の通りとしたほうが良いと判断
– 環境ごとのAPI Gateway
– 環境ごとのLambda Application & Function
– (初めは1つのAPI Gatewayで複数ステージを作れば良いと思ってたがSAMがそのやり方に対応していないらしい)

## 参考

[AWS SAMにおける環境管理のベストプラクティス | 株式会社CyberOwl](https://www.cyberowl.co.jp/blog/technology/1634#7mw8fyo9)

# 作業後のイメージ

– devとprodの2つの環境でdeployする想定

## API Gateway

– dev-XXXとprod-XXXの2つが作成される

![Untitled.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/490917/f414e1cd-2b06-8

IAMロールで社外の人へのアクセス権付与

# はじめに
自社のAWS環境のリソースを協力会社などの方に一部委ねて触ってもらう際に利用できる、IAMロールによる権限付与の方法です。
# 概要
社外からアクセスする人それぞれに自社のIAMユーザーを付与する方法もありますが、協力会社のAWSにIAMロールで自社AWSへのアクセス権を提供する方法がお勧めです。IAMユーザーを利用するのに比べて下記のようなメリットがあります。
* IAMユーザーのパスワードやアクセスキーの管理を相手に委ねることができて、ID管理の手間が減る。
* 招かれる側も複数のIDとパスワードを使い分ける必要が無いので手間が減る。

# 設定
下記のような前提でawsが2アカウントがあると仮定します。
| アカウント | ID | 内容 |
|:-:|:-:|:-:|
| aws-a | 111111111111 |　自社のアカウント。外部から招く側。 |
| aws-b | 222222222222 |　他社のアカウント。招かれる側。 |

:::note info
awsのアカウントIDは12桁の数字です。
:::

## aws-aの設定
外部アクセス用

Cloud9上のSAM CLIをアップグレードする

# 概要

過去に作成したCloud9環境のSAM CLIのバージョンが古くなっており新しいバージョンに更新したい場合があります。当記事ではその手順について記載しています。
(といっても、手順自体は下記の公式情報に書いてある内容そのままです)

https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/serverless-sam-cli-install-linux.html#serverless-sam-cli-install-linux-upgrading

# SAM CLIのアップグレード手順

任意のディレクトリ上にSAM CLIのzipファイルをダウンロードして”sam-installation”ディレクトリに解凍
“`shell
wget https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip
unzip aws-sam-cli-linu

AWS Cloud9で実行するAWS CLIの権限について

# はじめに
AWS Cloud9でAWS　CLIの実行や、CDKのデプロイをすることが最近多かったため、実行権限と変更方法について記載していきます。
Cloud9が何なのかは以下をご確認ください。
あまり本筋ではないので、詳細は割愛しますが、一言でいうとマネジメントコンソール上で利用できるIDE環境です。
開発に必要なツールやSDKなどが予め設定されていて、非常に便利です。（実態は裏でEC２が動いています。）
>AWS Cloud9 は、ブラウザのみでコードを記述、実行、デバッグできるクラウドベースの統合開発環境 (IDE) です。これには、コードエディタ、デバッガー、ターミナルが含まれています。Cloud9 には、JavaScript、Python、PHP などの一般的なプログラム言語に不可欠なツールがあらかじめパッケージ化されているため、新しいプロジェクトを開始するためにファイルをインストールしたり、開発マシンを設定したりする必要はありません。Cloud9 IDE はクラウドベースのため、インターネットに接続されたマシンを使用して、オフィス、自宅、その他どこからでもプロジェクトに

AWS メモ

アクセス情報を登録する

“`
$ aws config
$ aws configure –profile other-account
“`
profile 一覧を確認する方法
–profileのあとにタブで一覧を表示できる

“`
aws ec2 describe-instances –profile
“`

ファイルを直接みる
“`
cat ~/.aws/credentials
“`

おひとりさまOrganizationsやってみた

複数アカウントで検証したいことが多々あるのでやってみる。
GmailのエイリアスでOrganizationsのメンバーアカウントを複数作成できる。

# 1.Gmailのエイリアス機能

## 1-1.エイリアスの例
たとえば、次のエイリアス宛に送信されたメールはすべて `janedoe@gmail.com` に届く。

`janedoe+school@gmail.com`
`janedoe+notes@gmail.com`
`janedoe+important.emails@gmail.com`
送信してみる。
受信できた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1723719/3dcdca76-f2a0-4535-2db7-147bd

AWS公式資料で挑むSCS認定(22)-こんな時どうする(分野4:ID及びアクセス管理)

##### [前回] [AWS公式資料で挑むSCS認定(21)-こんな時どうする(分野3:インフラストラクチャのセキュリティ)](https://qiita.com/mingchun_zhao/items/1eb8ca9bd126fd36d705)

## はじめに

引き続き「こんな時どうする」集、
今回は「分野4: ID及びアクセス管理」です。

## 「分野4: ID及びアクセス管理」基本知識のおさらい

### AWS APIエンドポイント

– AWSへのすべての操作は必ずAPIアクセスポイントを経由(APIインタフェース)
– 目的はアクセスポイント数を制限し、モニタリングするため
– APIリクエストの認証/認可は、IAMで行う
– APIリクエストのログ記録は、AWS CloudTrailで行う
– 認証状況、アクセスしたリソース情報など

#### AWS APIの保護

– APIリクエストに対し、署名を使ってチェック
– ID有効性確認
– 有効なアクセスキーを持つ正しいユーザからか
– 中間者攻撃などによる改ざん