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

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

[EC2]インスタンスタイプの基本

## 勉強前のイメージ

EC2のインスタンスは大体適当に使うんだったらt2.microとかsmallとか…
あとはCPUとメモリでえいやーで決めてた

## 調査

### EC2インスタンスのネーミングポリシー

![プレゼンテーション1 – PowerPoint 2020-09-29 20.49.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/129517/17c63048-b65f-5d69-5c2c-310c3791b95a.png)

**t3a.2xlarge** : インスタンスタイプ

– t : インスタンスファミリー
– 3 : インスタンス世代
– a : 追加機能
– 2xlarge : インスタンスサイズ

### インスタンスファミリー

特徴を持った、5つのカテゴリに分類される

– 汎用
– コンピューティング最適化
– ストレージ最適化
– メモリ最適化
– 高速コンピューティング

#### 主なインスタンスファミリーの表

| カテゴリ | ファミリー

元記事を表示

AWS SAM CLI で複数のコンフィグを使い分ける

先日 AWS SAM CLI [v1.3.0 がリリース](https://github.com/aws/aws-sam-cli/releases/tag/v1.3.0)され、マルチコンフィグがサポートされました。
このアップデートにより、これまで面倒だった複数コンフィグの使い分けがとても楽になったので紹介してみます。

まず AWS SAM CLI の簡単なおさらいをしてから、アップデート前後でどう変わったかを見ていきます。

# AWS SAM と AWS SAM CLI

AWS SAM (Serverless Application Model) はサーバレスアプリケーション構築用のフレームワークです。
CloudFormation テンプレートを拡張する SAM 構文を使ってテンプレートを記述することで、簡単にアーキテクチャを定義できます。

例えば API Gateway と Lambda だけのシンプルなアプリケーションなら、たったこれだけの行数で書くことができます。

“`yaml
AWSTemplateFormatVersion: ‘2010-09-09’
Tran

元記事を表示

【AWS】Athenaでelbログを絞り込んで取得する

# はじめに
「athenaでelbのログを確認してもらってもいいっすか」って唐突に投げられたので準備と自分の好みのクエリを備忘録的に残しておきます

正直公式ドキュメントがこれでもかっていうくらい読みやすいのでそっちを参考にするべきだと思う
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/application-load-balancer-logs.html

# テーブルの作成
上記の本家様に書いてある通りCREATEクエリを流し込めばテーブルが作成できます
左側に`create table`があるからGUI上からも作成できるけど、設定を元にクエリが作成される+カラムの設定とかRegexをどうせコピペするのでクエリを最初から流し込んだ方がスムーズかと。

GUIから設定したい人向けに一応メモ

– Data Format: Apache Web Logs
– Regex: `'([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0

元記事を表示

AWS IoT フリートプロビジョニング(Fleet Provisioning)

# プロビジョニング方式の選定

以下表を目安に登録方法を選定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/695430/53be0232-5093-822d-5834-1cefa76db4e2.png)

– Amazonが管理するCAで証明書を発行する(独自CAを運用しない)
– 事前に秘密鍵、証明書を発行&登録しない

これらを要件とする場合、フリートプロビジョニング(Fleet Provisioning)を選択することになります。
また、今回は(*1)CSRを用いた場合には触れません。

# 用語

– プロビジョニングテンプレート

デバイスがAWS IoTと通信するために必要なリソース(モノ/証明書/ポリシー等)情報と、
それらリソースにアクセスするためのパラメータ(証明書ID等)を記述したJSONドキュメント
– クレーム証明書(ブートストラップ証明書)

初回接続時に使用するデバイス共通の証明書
個別証明書発行後は使用しない

元記事を表示

【AWS Cloud9】初期化をしてエラーを解決する方法【Rails6】

#Railsチュートリアル中にアプリが動かなくなってしまった場合

Railsチュートリアル中にアプリが動かなくなってしまった時の対処法を実体験から記します。

####はじめに
作成していたアプリを削除する為、
AWS Cloud9 IDEをDELETEしてください。

####次に
pushしていたアプリをGithubからcloneしましょう。

####最後に
ローカル環境(enviroment)と本番環境(production)を再構築しましょう。
コマンドは下記参照

P.S.
本当は初期化せずに環境をアンインストールしてから再インストールするとか、Gitを用いるのがよいと思いますが、初学者の方で訳がわからなくなった場合のチートシートです。

“`
$ cd 開発しているディレクトリ名
$ echo “gem: –no-document” >> ~/.gemrc 
#ジェムのドキュメントがあったらインストールが遅いので拒否

$ gem install rails -v 6.0.3 
#ジェムをインストールするコマンドです、後々エラーが出たら再度試しましょう。

$ s

元記事を表示

AWSことはじめ


### AWSアカウントを作成したらまずやること

– AWS作業用のIAMユーザを作成する
– ルートユーザ
– アカウントの設定変更、サポートプランの変更等可能、通常の作業では使用しない
– IAMユーザ
– Cloud Trail を設定する
– デフォルトで有効、90日間分のログを保存
– 管理イベント・データイベント(S3/lambda)
– 料金アラートを設定する
– 請求ダッシュボード → CloudWatch → 請求アラート作成
– IAMユーザ/ロールによる請求情報へのアクセス → 有効化


### EC2
– OS/Image の選択
– インスタンスタイプの選択
– ストレージの選択
– セキュリティグループの設定
– SSHキーペアの設定

元記事を表示

GitHubを用いた複数人でのサービス開発(備忘録)

# GitHubを用いた複数人でのサービス開発(備忘録)
c2cサービス開発を行った時の記録です
ここでは、サービス開発におけるGitに関連する説明のみ行う(随時更新)
## 環境
AWS Cloud9上でreactをもちいた開発
開発者は複数人
## そもそもGitって何?
### Gitが生まれる前は
開発作業を行う際、毎回ソースコードが記述されたファイル名に日付や変更内容を記載していた
以下のような欠点があった
– ファイル名の命名方式を事前に決定する必要がある
– 開発過程で最新のファイルや一時的に取っておきたいファイル等が乱立
– 複数人で開発すると、ファイル名の命名形式が崩れたり、結合前、結合後のファイルが入り乱れる
### Gitホスティングサービス例
個人で運用する場合、Git運用にかかるコストを考慮すると、以下のホスティングサービスをもちいる方が良い
– GitHub
– GitLab
– Backlog
– BitBucket
### Gitの特徴
– バージョンの管理システム
– local、remoteレポジトリを持つ
– localレポジトリは、各開発者がロ

元記事を表示

新しく作ったCloud9環境でpythonのsam buildに失敗する場合の原因と解決法

# 事の発端

先日(2020年9月某日)、新しく作成したAWSのCloud9の開発環境(platform=AmazonLinux)でsam(ServerlessApplicationModel)のhello worldテンプレート(ランタイムはpython3.8)を出力し、buildやdeployを試そうと”sam build –use-container”コマンドでビルドをしてみたところ、下記のエラーに遭遇しました。
作成したばかりの素の環境でエラー(RuntimeError: Container does not exist)になったので「え??」となりました。

(↓はご参考までに、hello_worldテンプレートを出力するまで)

“`
ec2-user:~/environment $ sam init –runtime python3.8 -n sam-py38

SAM CLI now collects telemetry to better understand customer needs.

You can OPT OUT

元記事を表示

メール便忘れ防止ボタンをAWS IoT ボタンで作ってみた

#若手ならではのメール便担当
僕の会社では若手の仕事として「メール便」というものがあります。
会社からの送付・受取を毎週9時・11時・15時に行うというもので、これがまた結構責任重大。
__ヤッベェェェ忘れてた郵送物を送り損ねた!__なんてことがあったら普通に先輩に迷惑が掛かります。

僕自身も数回メール便を忘れた実績があり、リマインダーをつけてもアラームを消してそのまま忘れることも(ひどい)。
どうにかメール便忘れを防ぐ仕組みを作りたいと思い、AWS IoTボタンを使って実装してみました。


こいつです

#完成デモ
##メール便処理したらボタンを押す
送付したい郵便物をためておくメール便ボックスみたいなものがあり、そこに設置します。
メール便担当はちゃんとメール便を処理したよ!というときにボタンをポチーと押す、という

元記事を表示

CDK で API Gateway の実行ログとアクセスログを有効にする

API Gateway(REST API) で開発するとき、アクセスログと実行ログを出すようにすると、トライアンドエラーが捗りますよね。

CDK(TypeScript) でこれを有効にするには、こんな感じです。

“`TypeScript
const accessLogGroup = new logs.LogGroup(this, ‘AccessLog’);
const api = new apigateway.RestApi(this, ‘Api’, {
deployOptions: {
loggingLevel: apigateway.MethodLoggingLevel.INFO,
dataTraceEnabled: true,
accessLogDestination: new apigateway.LogGroupLogDestination(accessLogGroup),
accessLogFormat: apigateway.AccessLogFormat.clf()
}
});
“`

実行ログに関する設定は、loggin

元記事を表示

InfoScale 7.4.2 for RHEL on AWS パフォーマンステスト結果大公開

# はじめに
InfoScale は、AWS上のRHELでの動作を保証しており、主なメリットとして以下2点が挙げられます。事実、オンプレミスの世界では、下記のメリットを享受する為に多くの企業がInfoScaleを導入しています。
**1.独自のストレージ管理機能により、ストレージ(AWSの場合はEBS)メンテナンス時のダウンタイムや作業工数を削減**
**2.独自のクラスタリング機能により、アプリケーションやOSレベルの障害をカバーできる可用性の向上**
しかし「クラウド上のI/Oパフォーマンス管理はオンプレと違って難しいのに、AWS上にInfoScaleを導入する事によって、さらに複雑になるのでは?」という懸念が根強いのが実情です。本記事では、そのような不安を払しょくするために、InfoScale7.4.2 RHEL版を AWS上に構築した代表的な構成におけるI/Oパフォーマンステスト結果を公開します。また、ストレージ管理やクラスタリングを行う為にInfoScaleを導入する事の妥当性を構成毎に考察します。I/Oパフォーマンスを向上させるための簡単なチューニングについても説明します。

元記事を表示

CDK で API Gateway Mock 統合と Lambda Authorizer を作る

CDK(TypeScript) で API Gateway(REST API) の Mock 統合と、Lambda Authorizer を作ってみました。

ソースコード全体はこちらです。
https://github.com/kazfuku/apigateway-java-lambda-authorizer/blob/master/lib/apigateway-java-lambda-authorizer-stack.ts

## Mock 統合
Mock 統合はこの部分です。

“`TypeScript
const mockIntegration = new apigateway.MockIntegration({
requestTemplates: {
‘application/json’: ‘{“statusCode”: 200}’
},
integrationResponses: [
{
statusCode: ‘200’,
responseTemplates: {
‘application/json’:

元記事を表示

Java Lambda で API Gateway の Lambda Authorizer を実装する

API Gateway(Rest API) の Lambda Authorizer では、Lambda のレスポンスに [指定の JSON を返す](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api-gateway-lambda-authorizer-output.html) 必要があります。

Lambda Authorizer って何?って方は [こちら](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) を。

Node.js だと、こんな感じで、そのまま JSON を返せます。便利ですね。

“`JavaScript
exports.handler = async (event) => {
console.log(JSON.stringify(event, null, 4));
return {
“princi

元記事を表示

NginxとRoute53を使ってドメインでアプリを表示させる

# 問題
アプリを本番環境にデプロイし終えたところ。
Elastic IPアドレスではブラウザにアプリが表示されるが、ドメインでは表示されない。

![スクリーンショット 2020-10-01 午後1.37.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/547640/a2e65d09-aa29-53f9-d570-65d1deebd6d5.png)

# 解決法

vimでNginxの設定ファイルを開いて

“`
// pfc-masterはアプリ名です

[naota@ip-10-0-0-32 ~]$ cd /etc/nginx/conf.d/
[naota@ip-10-0-0-32 conf.d]$ sudo vi pfc-master.conf
“`

“`:アプリ名.conf
//before
server_name Elastic IPアドレス;
 ↓ 
//after
server_name ドメイン名;
“`

Nginxの設定ファイル`アプリ名.conf`の`s

元記事を表示

The asset “application.css” is not present in the asset pipeline.の解決法

# 問題
アプリを本番環境にデプロイする過程で、

“`
$ rake assets:precompile RAILS_ENV=production
“`

アセットパイプラインのエラーが生じた。

# アセットパイプラインとは?
>アセットパイプラインとは、JavaScriptやCSSのアセットを最小化 (minify: スペースや改行を詰めるなど) または圧縮して連結するためのフレームワークです。
アセットパイプラインでは、CoffeeScriptやSass、ERBなど他の言語で記述されたアセットを作成する機能を追加することもできます。

[参考記事:Railsガイド「アセットパイプラインについて」](https://railsguides.jp/asset_pipeline.html)

# エラー
“`
The asset “application.css” is not present in the asset pipeline.
“`

# 解決法

“`ruby:config/environments/production.rb
# config.assets.

元記事を表示

【AWS EFS】 EFS導入と「自動マウントされない問題」や「マウントされたときの表示がいまいち問題」、「帯域制限を掛けながらrsyncでデータを流す」をしたときのメモ

# はじめに

EBSをEC2にマウントしていると、他のサーバからそのEBS内容を閲覧したいときにつらいので、EFSを使ってみました。
その際に、「EFSが自動マウントされない問題」とか「「$ df -h」した際に、表示されるefsが127.0.0.1とかlocalhostとかの表示になっていてわかりづらい問題」、「帯域制限を掛けながらrsyncでデータを流す」の内容も記述します。

自分用メモです。

# 内容

## EFSのマウント

これは、多くの参考記事がありますのでそちらを参考に。

・https://qiita.com/rubytomato@github/items/4a821fc9e07848a15e59
・https://qiita.com/aWdfcfG2jLr73pe/items/adb807df4c4fb305006b

ありがたいですー

## EFSの自動マウントがされない問題

これも、多くの記事がありますので参考に。

https://dev.classmethod.jp/articles/tsnote-support-efs-nfs-utils-re

元記事を表示

シナリオから学ぶ連携テスト

# シナリオ背景
連携API(VPC A)とAPIを使うサービス(VPC B)はAWSの違うVPCに存在する。
2つのシステムは**Peering設定***されて通信できる状況。
連携APIのVPCは***マルチAZ構成***になっている(2つのAZ)

**Peering**:*2つのVPC間の通信を外部ネットワーク経由でなくL3ネットワーク経由で、でVPC間の相互に通信ができるサービスです。*

**マルチAZ構成**:*クラウド上で構築・運用されるシステムの可用性を高めるためのベストプラクティスの一つであり*

![peering-intro-diagram.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108475/7559e09c-cd36-eaa5-a3fa-5c01d9140116.png)
VPCピア機能については[こちら](https://docs.aws.amazon.com/ja_jp/vpc/latest/peering/what-is-vpc-peering.html)を参考

元記事を表示

RDSのログファイルをAWS CLIから確認する

#はじめに
RDSを利用しているとMySQLやPostgreSQLなどのエンジンのバージョンアップによる影響やパフォーマンス改善のためにスロークエリを確認するためにRDSインスタンスのログを確認することがあります。
ブラウザからでもログファイルを確認・ダウンロードすることができますが、対象のログファイル数が多くなると面倒だったのAWS CLIを利用して確認しました。

#環境
* OS:macOS Catalina 10.15.6
* AWS CLI:aws-cli/2.0.43 Python/3.7.4 Darwin/19.6.0 exe/x86_64

#前提
AWS CLIでRDSインスタンスのログを確認するにはポリシーが付与されている必要があり、以下のポリシーが必要になります。

“`
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“rds:DescribeDBL

元記事を表示

IaC から始まる幸せなエンジニアライフ

ここ最近忙しく、久しぶりの投稿になってしまいました。
ちょっと前から書きたかった布教用の記事を書きます。
みんなが IaC すれば、世界がちょっと happy になります。。

## IaC って何?

ここ 2-3 年、僕が注力した分野の一つが IaC です。

IaC は Infrastructure as Code の略です。
つまり、インフラ構成をコードで管理しましょう、っていうことですね。

その対極にあるのは、インフラ構成を CLI や GUI を使って、手動で作成・管理するというものです。
その場合は、しばしば手順書をドキュメントとして残すことになります。

## こんなにあるよ! IaC のメリット

IaC のメリットとして、パッと思いつくだけでも、以下のようなものがあります。
(何か語呂合わせにしたいけど、思いつかないのでいいや…)

– Easy to Reproduce (再現容易性)
– Easy to View (閲覧容易性)
– Easy to Destroy (破棄容易性)
– Easy to Share (共有容易性)

元記事を表示

最もシンプルなAWS Lambdaの実装

#はじめに
「とりあえず、AWS Lambdaを体験してみたい」人用の記事です。
初心者向けに「S3と連携して~」みたいな記事は多いのですが、
意外とシンプルな実装を投稿している人が少なかったので今回やってみました。
早ければ10分程度でAWS Lambdaを体験できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/287677/65b90fb1-e052-96a5-a79f-9748ba0d8ba3.png)

今回作成するシステムの構成図↑

#全体の流れ

①AWS Lambda関数の作成

②API Gatewayの作成、AWS Lambdaとの接続

③テスト

#①AWS Lambda関数の作成
一から作成で、test_funcという名前の関数を作成します。
ランタイムは何でもいいですが、今回はpyhonを選択します。
![image.png](https://qiita-image-st

元記事を表示

OTHERカテゴリの最新記事