AWS関連のことを調べてみた2020年11月11日

AWS関連のことを調べてみた2020年11月11日
目次

保有スキルの可視化

はじめに

投稿時点の自身の保有スキルを確認・再認識するためにまとめました。

保有スキル

[Windows]
OS:
Windows Server 2012R2,2016,2019
タスク:
詳細設計、構築、インフラテスト、運用
基本的な設計やちょっとしたチューニング対応を含めた構築、運用まで対応可能
他に担当したシステム:
ActiveDirectory設計、構築、移行
WSUS設計、構築、運用

[Linux]
OS:
RHEL 6.5,6.7,7.2 ,CentOS: 6.5,6.7,7.2,8.2
タスク:
基本的な設計やちょっとしたチューニング対応を含めた構築対応が可能。運用経験無
他に担当したシステム:
DRBD+Pacemaker 冗長システム設計、構築
OpenStack(Liberty) 構築(PoC)
Zabbix構築
Syslog構築(PoC)

[VMware]
OS:
ESX,VC 5.5,6.0,6.5,6.7,7.0
タスク:
基本的な設計やちょっとしたチューニング対応を含めた構

元記事を表示

AWS EC2 EC2 Instance (Amazon Linux AMI)の作成2

#はじめに
今回は、AWS EC2を使用して、Linuxサーバーを建ててみようと思います。
作成してみたそばから、AWSの画面が変わっていました。
ネットサービスは、いつも急にUIが変わってしまうため、ノウハウとしてQiitaに記載しても、すぐに陳腐化してあっていないということになります。
ということで、もう一度やってみます。この記事の前に書いた記事の焼き直しです。

#今回実施する内容
AWS EC2を使用して、Amazon Linux AMI2を使用したLinuxサーバーを建てます。

#参考
[Tutorial: Getting started with Amazon EC2 Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html?trk=em_a131L000005jw1jQAA&trkCampaign=pac_EC2_docs_GettingStarted_GlobalEM&sc_channel=em&sc_campaign=GLOBAL_PM_AB_ec

元記事を表示

AmazonLinuxでcron実行させる(Linuxで設定)

## やること
AmazonLinuxで、cron設定をして、AWSコマンドを実行させます。
前提としてそのコマンドのIAM RoleがEC2に対して必要です。
今回は詳しい内容までは書きません。

## OS
Linux/Unix, Amazon Linux 2018.03

“`
#cat /etc/os-release
NAME=”Amazon Linux AMI”
VERSION=”2017.09″
.
.
“`

## cronファイルの書き方

“`
# cat /etc/crontab

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# For details see man 4 crontabs

# Example of job definition:
# .—————- minute (0 – 59)
# | .————- hour (0 – 23)
# | | .———- day of month (1 – 3

元記事を表示

AWS CLIでAuto Scaling グループの「希望する容量、最小キャパシティ、最大キャパシティ」を変更する

# はじめに
ローカルPCからAWS CLIを利用して、Auto Scaling グループの希望する容量、最小キャパシティ、最大キャパシティを変更します。
コスト削減のため、利用しない時は値を0にすると思いますが、AWS CLIで変更します。

# スクリプト
**1. オートスケーリングに紐づくEC2インスタンスを起動する**

“`sh:start_auto_scaling_groups.sh
#!/bin/sh

cd `dirname $0`

start_asg () {

ASG_NAME=$1
SIZE=$2
MAX_SIZE=${SIZE}
MIN_SIZE=${SIZE}
DESIRED_CAPACITY=${SIZE}
echo “start auto scaling group: ${ASG_NAME}”

aws autoscaling update-auto-scaling-group \
–auto-scaling-group-name ${ASG_NAME} \
–max

元記事を表示

[AWS] Ubuntu EC2インスタンスのメモリ使用率をCloudWatchに連携する

EC2のメモリ使用率は標準のメトリクスとしては取得されず、CloudWatchで確認するためには追加設定が必要となります。

手順は [公式ページ](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) にまとまっていますが、全ての対象ディストリビューションが同じページに書いてあるので、Ubuntuで設定した手順を本ページにまとめておきます。

以下はそれぞれ、新規に起動したUbuntu 20.04インスタンスで確認した手順です。コマンドラインでインストールする方法と、SSMからインストールする方法があります。

# 1.コマンドラインでインストール

# 1-1. IAMロールを作成してアタッチ

インストール前に、CloudWatchにメトリクスをPUTするためのロールを作成してインスタンスにアタッチする必要があります。コンソールの IAM → ロールから「ロールの作成」を選択。

|![image.png](https://qiita-

元記事を表示

AWSでプロセス、CPU使用率、ディスク使用量を監視→通知する

AWSでプロセス監視とCPU使用率・ディスク使用量の監視を行い、
閾値などを超えた場合にメール通知、電話通知してみます。

監視は以下の方式で行ってみます。これらのパターンを押さえておけば
大体のパターンは対応できるかと思います。
CPU使用率:基本モニタリング
ディスク使用量:CloudWatchエージェント
プロセス監視:procstatプラグイン

**■注意点**
10 個を超えるカスタムメトリクスのモニタリングや
CloudWatchLogsの保存など課金されるポイントが色々あるので
テストで作成したものは放置しないよう注意してください。

## CPU使用率の監視/メール通知
まずはメール通知用にAmazonSNSのトピックを作成しサブスクリプション登録を
行います。エンドポイントには通知したいメールアドレスを指定します。
詳細は以下を参照ください。
[Amazon SNS 通知の設定](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/

元記事を表示

【EC2】scpコマンドでローカルとEC2間でのファイル&フォルダのダウンロード方法

##scpコマンドとは?
scpコマンドはファイルやフォルダをSSHで暗号化しながら転送できるのことコマンドです。

##ダウンロード前に行うこと
###公開鍵(authorized_keys)の設置
公開鍵認証する場合、EC2で作成した公開鍵と秘密鍵のペア(拡張子は.pem)を公開鍵を接続ユーザのホームディレクトリ下~/.ssh/ に設置する必要があります。
###Permissionの設定
公開鍵認証する場合、以下のようにPermissionを適切に設定する必要があります。
きちんと設定していないとscpコマンドの実行時にPermission Errorが発生します。

“`
chmod 600 キーの名前.pem
“`

これで事前準備は完了です。

##ダウンロード方法

###ローカルファイルをEC2へダウンロード
まずは、ローカルファイルをEC2上へダウンロードする方法を見ていきましょう。

“`
$ cd .ssh/
$ scp -i [秘密鍵] [転送するファイルのパス] [EC2ユーザー名]@[パブリックIP]:[EC2上のコピー先のパス]
“`
となります。

元記事を表示

SORACOM LTE-M Button powerd by AWS を使って、玄関の電灯をON/OFF制御してみた(改良版)

#はじめに
本記事は、以前投稿した[記事](https://qiita.com/YSFT_KOBE/items/bbd93c8a72527cfea980)をさらに改良したものです。
また、本記事に記載の手順は、以下のマシンでの実行を想定しています。また、AWSを多少触ったことのある人を想定して記載してます。

+ ホストOS:Ubuntu18.04(LTS) / CentOS 7

#概要

以前投稿した[記事](https://qiita.com/YSFT_KOBE/items/bbd93c8a72527cfea980)では、以下のようなシステムを構築しました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307872/fbf1277b-450f-a7d8-2010-de6ad4023225.png)

左上の装置は、SORACOM LTE-M Button powerd by AWSです。
左下の黒基盤のマイコンはESP32DevkitCで、Amazon FreeRTOSを実装して

元記事を表示

AWS Redshiftで集計クエリを投げてみた

Redshiftで集計のクエリを投げるために、環境構築から取り組んだ。
いろいろ苦労したので、まとめてみる

利用環境はMacです。

## 【背景】
– Redshiftって集計に使えそうだけど、Athenaと比較して性能ってどんなもんなの?
– Redshiftってデータ蓄積するのはS3じゃないんだよね?実際にどうやったら動かせるんだろう
– ただ、やったことないしわからないな〜

今回はこんな課題感で手を動かし始めました。

## 【実際にやったこと】
1. Redshiftでクエリを投げてみた
– Redshiftの環境構築
– Redshiftにテーブルを作成する
– S3からデータをコピーする
– クエリを投げる

これらをどのようにしていったかをまとめます。(いろんな記事を参考にさせていただきました)

## 【Redshiftでクエリを投げてみた】
実際にやっていった手順に沿って書いていこうと思います。

### Redshiftの環境構築, テーブルの作成, S3からデータをコピーする

Redshiftの[公式ドキュメント](http

元記事を表示

AWS Amplify で Next.js アプリを作成する際のビルド設定

#1. 本記事は
“`terminal
create-next-app
“`
で作成したNext.jsの各種ファイルをgithubにアップロードし、AWS Amplifyでデプロイするパイプラインを作成する際に躓いたポイント(ビルド設定)のメモ。

#2. Next.js 各種ファイルを github にアップロード
1. githubで新たにリポジトリを作成する
2. terminalを開きファイルを保存したい場所へ移動(以下terminalでのコマンド)
3. package.json内の”build”に追記する:point_left:ここ注意!

“`json
“scripts”: {
“dev”: “next dev”,
“build”: “next build”,
“start”: “next start”
},
“`

“`json
“scripts”: {
“dev”: “next dev”,
“build”: “next build && next export”,
“start”: “nex

元記事を表示

SignedURLを使ってバージョニングが有効なS3バケットにアクセス

S3は、バージョニングを有効にして、同じオブジェクトキーを持つファイルであっても、バージョンによって異なる内容のファイルをダウンロードすることができます。
S3バケットをインターネットからのアクセスを許可するようパブリックに設定することは強く推奨されないため、通常、S3バケットのファイルアクセスは、CloudFrontか署名付きのURL (SignedURL) を使います。
さらに、プライベートコンテンツである場合は、CloudFront を使う場合でも署名付きURLのみでアクセスを許可することもできます。

ここではデモのためのアプリケーションを作成しました。

![AWS構成図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/83475/61d31957-bbe3-21c2-59ed-dd2fae5c5c94.png)

まず、最初にS3で署名付きURLを発行します:

“`
curl “https:////s3/signedurl

元記事を表示

VPC + EC2 + Docker でアプリケーションをデプロイする。

# はじめに
2019/08/08に開催されたAWSハンズオンの資料を元に、NuxtアプリをAWSを使ってデプロイすることがあったので備忘録的にまとめておきます。
今回初めてAWSに触ったので間違いがあるかもしれませんが、その時は助言をいただけるとありがたいです。
また、今回は例としてNuxtアプリをAWS環境にデプロイすることを目標としています。

# 対象読者
* AWSの基本を学習したい方(AWSアカウントは持っている)

# 全体構造
こんな感じです。

![Qiita AWS構成図-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/412378/d18cf111-d8d1-6b8b-a36c-8511ffde78b7.png)

難しそうに見えますが、一つ一つ見てみたらとてもわかりやすいですので、少しずつみてみましょう。

# VPC
## VPCとは
**VPC**とは **Amazon Web Service Virtual Private Cloud** の略称で、プライベートな仮想

元記事を表示

jestでaws-sdk、aws-xray-sdkをmock化する方法

## jestでaws-sdkのmockを作る
jestとはFacebookによる、jsのユニットテスト用モジュールです。
非常に簡潔なコードでユニットテストを気軽に実装できるので重宝しようと導入したのですが、初心者だと外部モジュールをmock化するには意外と手間取ったりします。

例えば、Lambdaを使用する中でaws-sdkや、それをaws-xray-sdkでラップした構造体を扱ったコードをテストしたい場合、aws-sdkのモジュールをmockにしなければなりません。(SAMを使えば違う書き方もできるはずです。SAMに関しては別記事にてご確認ください。)

そんなわけでmock化するためにいろいろと苦労したのですが、その中で一つ発見があったので記事にしました。
ひとまず細かい解説は抜きにして、手本の一つとしてご覧ください。これでaws-sdkのモジュールは確実にmockにできます。記述にご不明点などあればご質問いただくか、[**Jestのドキュメント**](https://jestjs.io/ja/)をご覧ください。(後者の方が確実です)

## aws-sdkのモジュールをmo

元記事を表示

Autoscalingを利用した簡単自動復旧構成

#あらまし
AWSでは可用性を高める為、オートスケーリングを基本的に利用すること(=Multi-AZ)がベストプラクティスです。

**とはいえ**

オートスケーリングには**スケーリングの構想(発火する為の監視の値など)が必要**だったり、**CLBや最低2台のインスタンス費用**、**浦島コンテンツ対策**などなどなど、考えることが多過ぎてなかなか自社の構築部隊の頭を縦に振らせる提案ができないという難点があります。

また、費用の点でも単純に倍に増えるので、お客様からも**まず省略できないか**と言われてしまう場所でもあります。

#なるべくお金をかけない自動復旧構成
案はこうです。

**オートスケーリンググループで最小インスタンス台数、最大最小スケールインスタンスを全て1にしてしまう**

これであれば必要なのは+CLBの費用だけで済み、インスタンス障害時にはオートスケーリンググループから新しいインスタンスが立ち上がり
**サービスの停止を最低限**で済ませることができます。

#実際にやってみた
細かい設定はドキュメントを見ながらして欲しい。
肝なのは「希望する容量」「最小

元記事を表示

【保存版】AWSのS3で静的サイトをデプロイ&独自ドメイン設定を画像付きで解説

#はじめに
本記事へのアクセスありがとうございます。
投稿主はプログラミング初心者であり、この方法が**「最適解」**かは分かりません。
しかし、動作は検証済みであり同様な記事も確認できたので信憑性はあると思います。

本記事は時系列ごとに記載しているので、デプロイスタートから順番にやっていけば出来ると思います。

#この記事から得られるものは?
・AWSのS3を用いた低コストで簡単な静的サイトのデプロイ方法
・設定中に起きうるエラー対処法
・お名前ドットコムを利用した独自ドメイン設定(好きなURIへの変更)方法
・Certificate ManagerのよるHttps化の設定方法
・Circle CIを用いたS3への自動アップロード方法

#さっそくデプロイスタート
##S3のバケット作成〜設定
AWSのホームページにてログインした状態からの説明となります。

まずはS3のページにアクセスし、バケットの作成ボタンをクリックします。

ここでお好きなバケット名を設定してください。
S3のリージョンは東京リージョン作成でも構いません。後に出てくるCertifacate Managerはバ

元記事を表示

AWSを勉強する – IAM

AWS Identity and Access Management(IAM)は、AWSを使用するユーザーのアクセス権限を管理する。

#AWSのアカウントの種類

###ルートユーザー
AWSアカウント作成時に作られるIDアカウント
ルートユーザーは、ネットワーク上のどこからでも操作できる権限を持っている。(Administrator的存在)
AWSでシステムを構築・運用する際は、このアカウントを使うことは極力避ける!!!

ルートユーザーしかできないこと

– AWSルートアカウントのメールアドレスやパスワードの変更
– IAMユーザーの課金情報へのアクセスに関するactivate/deactivate
– 他のAWSアカウントへのRoute53のドメイン登録の以降
– CloudFrontのキーペアの作成
– AWSサービス(サポートなど)のキャンセル
– AWSアカウントの停止
– コンソリデイテッドビリングの設定(複数アカウントを統合した請求の設定)
– 脆弱性診断フォームの提出(AWSに脆弱性の診断ができる)
– 逆引きDNS申請

###IAMユーザー
AWSを利用する

元記事を表示

猿が管理するElastic BeanStalk

#猿が管理するElastic BeanStalk

ぶっちゃけブラウザ上で一回書いててBackSpace押したら記事が全部消えてやる気が無くなる病が発生中

なんで加筆するけどこんなんをとりあえずはっつけておく

##前提
– ElasticBeanStalk上で複数のApplicationを管理している
– また、その環境内に複数Environmentセットを運用している
– 運用しているEnvironmentは下記の通り
– DEVELOP : DEV :: x-dev-stage-[XXX] という名称のApplication
– DEMO : DEMO :: stage-[XXX] という名称のApplication
– STAGING : STG :: stage-[XXX] という名称のApplication
– PRODUCTION : PROD :: stage-[XXX] という名称のApplication

### 作文例
“`
#!/bin/bash

base_dir=”/home//Components”

case “${1}” in

元記事を表示

忙しい人のためのAWS「IAM」

##はじめに

自分のアウトプットがてら、さくさくとAWSの各種サービスについてまとめていくシリーズです。
今回はIAMについて取り上げます。

##IAMとは

Identity and Access Managementの略称。結論、**ユーザー管理**をしてくれる、もしくは自分でするためのサービスです。

いちばん初めにAWSにサインアップしたときのアカウントを**ルートユーザー**と呼びます。
このユーザーは本当に何でもできる神のような存在なので、普段使いはしないようにすることが推奨されています。

そこで、**IAMユーザー**というものを神によって創造し、普段の操作はそのアカウントを使うことで、変なことをしないようにできます。つまり、安全にAWS操作を実施するための認証や認可の仕組みを作れます。

##主要トピック

**ユーザー**、**グループ**、**ポリシー**、**ロール**の4つがあります。

ポリシーとは、このIAMユーザーは○○と△△のサービスにアクセスできます、などのルールのことです。ルートユーザーはポリシーもクソもないのでまったく別で考えます。何といって

元記事を表示

Route 53を使用し、お名前.comで取得した独自ドメインでWebページを表示させる

前提として
お名前.comで独自ドメインを取得済み、
IPアドレスでWebページが表示されていることとします。
やり方はこちらをご覧ください

[**お名前.comを使い、独自ドメイン取得**](https://qiita.com/tksh8/items/ab3748bcb01316461abe)

[**AWSでのデプロイ手順**](https://qiita.com/tksh8/items/9a8e88a777a3a4ee7a09)

# Route 53を使用し、お名前.comで取得した独自ドメインでWebページを表示させる

## Route 53の設定
### ホストゾーンの作成

Top画面→Route 53を検索
![スクリーンショット 2020-11-10 10.18.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/355517/6e298daa-ba95-f0bd-c727-fd67bd5d9e0f.png)

[ホストゾーンの作成]を押下する

![スクリーンショット 2

元記事を表示

RailsのアプリをEC2へデプロイしてみる-後編(サーバー構築編)-

#この記事について
今回はEC2でサーバー構築をしていきます。
前編の内容が前提となりますのでまだの方はご確認ください。
尚今回はEC2内にnode.jsやRubyといった必須のソフトウェアは既にインストールしたものとして記述していきます。
https://qiita.com/kotobuki562/items/57ffbaadad8ec8d16a4f

#データベースの用意
今回はMariaDBを使用します。インスタンスをAmazonLinux2で起動しているためです。
MYSQLの派生版と考えていただければ相違ありません。

下記コマンドを入力してデータベースをインストールしましょう。
MariaDBはyumコマンドでインストールできます。

“`terminal
[ec2-user@ip-111-11-11-111 ~]$ sudo yum -y install mysql56-server mysql56-devel mysql56 mariadb-server mysql-devel
“`
systemctlコマンドでMariaDBを起動しましょう。

“`termin

元記事を表示

OTHERカテゴリの最新記事