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

AWS関連のことを調べてみた2021年05月27日
目次

AWS ご利用開始時に最低限おさえておきたい10のこと

**AWS ご利用開始時に最低限おさえておきたい10のこと**

https://pages.awscloud.com/JAPAN-event-OE-At-least-10-basic-2020-confirmation-639.html

> 初心者には難しい
初回はざっくりで良いので目を通す程度でOK
何度も見返すべき資料
AWS Well-Architected Frameworkがどんなものなのか理解できていればOK

概要

– toB向けの利用における注意点の紹介ウェビナー
– AWS Well-Architected Frameworkは何か
– AWS Well-Architected Frameworkに基づくベストプラクティスに即して注意点を紹介

## はじめに

AWSを利用する上で最低限抑えておきたい設定などを理解する
↑ その為にAWSのベストプラクティス集を活用する
= それはつまり ” AWS Well-Architected Framework ” の集大成
→ ビジネスの成功率を上げる

### 目次

1. AWS Well-Architected

元記事を表示

AWS ALBでの流量制限を実装してみました

#はじめに
キャンペーン等でWebサーバに対して想定数以上のアクセスが発生した場合に、Webサーバが高負荷となりレスポンスが悪化することがあると思います。そのような場合には、負荷を低減するために、一定数以上のアクセスを抑止する方法が考えられます。(他には、”Webサーバの前段に高機能のロードバランサを導入しアクセスを抑止”したり、”Webサーバをスケールアウトする”方法もあります)
今回、AWS ALB(Application Load Balancer)及びAWSマネージメントサービスのみでこれを実装してみました。
なお、調査した限り、実際には”一定数以上のアクセスを抑止する”といったことはできませんでした(AWS SA様へも確認済)。代わりの方法として、特定パスに対するアクセスを一時的に抑止することで、Webサイト全体のレスポンス悪化を回避する方法を採用しています。

#環境
構成と抑止の挙動は以下の通りです。
####前提
– (キャンペーン等で)アクセスの増加が見込まれるコンテンツが事前に把握できている。今回の対象コンテンツを「campaign.html」とする。
– 抑止をト

元記事を表示

Go Gin爆速入門 (REST API)

## はじめに

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/407956/098fbaef-c096-599e-c163-aced79706c75.png)

Goで圧倒的人気を誇るWebフレームワークのGinを使ってREST APIを爆速で構築するための入門です。
コードはginのREADMEドキュメントを元にしています。
Ginで基本的なREST APIを構築するための最低限の知識はカバーできているはずですので、参考にしてみてください。

https://github.com/gin-gonic/gin

### Ginの導入方法

“`bash
mkdir test-app && cd test-app
go mod init test-app
go get -u github.com/gin-gonic/gin
“`

## Quick Start
`/pin`というエンドポイントにアクセスすると`pon`と表示する簡単な例

“`main.go
package ma

元記事を表示

Terraformで AWS App Runner + CodeCommit + CodeBuild + CodePipeline のデプロイ環境を構築する

#はじめに
本記事では、Terraform で AWS App Runner + CodeCommit + CodeBuild + CodePipeline のデプロイ環境を構築する手順を記載しています。

下記の記事を読ませていただいて、自分も試行してみようと思いたって、この環境を構築してみました。

[TerraformでAWS App Runnerを爆速構築してみる](https://qiita.com/neruneruo/items/e75b19b945acfd2ae56c?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items)

#Terraform で構築する全体構成図
![00_terraform_apprunner.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/283246/e2f60de9-7b07-3b44-8837-817e89912c0e.png)

#Terraform のコードと構成

htt

元記事を表示

【新サービス】AppRunnerの留意点

## AppRunnerについて
App Runnerの基本的な説明に関しては既に良い記事がありましたので、紹介させて頂きます。

**かなり便利そうなサービスなのですが、いくつか留意点を紹介します。**

##プライベートサブネット内のリソースにアクセスできない
FARGATEではサービス単位やタスク単位でVPCやセキュリティグループの設定ができますが、
AppRunnerではそもそもVPCと紐づける設定が存在しない為、プライベートサブネット内のリソースにアクセスできません。
プライベートサブネット内のDBにアクセスできないのがやはり痛いと思います。
プライベートサブネット内のリソースへのアクセスはAppRunnerのロードマップでも1番要望が大きいようです。

https://github.com/aws/apprunner-roadmap/projects/1

##VPC内のAWSリソースからAppRunnerにアクセスする際にインターネットへトラフィ

元記事を表示

AWS S3 双方向クロスアカウントレプリケーション 暗号化したオブジェクトのレプリケーション

# 初めに

1~5はセイムリージョンレプリケーションの手順です。6はクロスリージョンレプリケーションをする際、セイムリージョンレプリケーションと異なる点について触れています。

設定は以下の通りです。

アカウントAのバケット名・・・`account-a-bucket-0525`
アカウントBのバケット名・・・`account-a-bucket-0525`

アカウントAのバケット、アカウントBのバケットはともに以下の3つの設定をしているものとします。

– バージョニングを有効化
– デフォルト暗号化
– 暗号化キーはKMSのマネージド型キー(カスタマー管理型のキーではなくAWSによって作成されるキー)
– バケット所有者は「希望するバケット所有者」

# 1. レプリケーション用にカスタマー管理型のキーを作成する

**注意点1**

なぜマネージド型キーを使用せず、カスタマー管理型のキーを使用するかという点ですが、**マネージド型キーのキーポリシーは変更できない**からです。

>AWS が管理する CMK または顧客が管理する CMK のキー ポリシーを表示することはで

元記事を表示

はじめてのアマゾン ウェブ サービス

**AWS の基礎 ~ 主要概念 ~**

https://aws.amazon.com/jp/getting-started/fundamentals-core-concepts/?e=gs2020&p=fundoverview

## はじめに

クラウドネイティブパラダイムは大変だよね、

この記事で得られるもの

1. 全てのサービス当てはまる AWS の 5 本の柱
2. クラウドについて考えるときに使用するメンタルモデル
3. クラウドについて考えるときの重要な概念

### 5本の柱

[AWS_Well-Architectedフレームワーク](https://aws.amazon.com/jp/architecture/well-architected/?e=gs2020&p=fundcore&wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc)に由来する、クラウドでのスケーラブルなアプリケーションの構築を可能にする主要素。

1.

元記事を表示

アクセス許可の境界とは何なのか【IAM Permissions boundary】

#アクセス許可の境界とは

IAMにはアクセス許可の境界という機能があります。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html

Aさんに以下のポリシーをアクセス許可の境界として設定します。

“`json:アクセス許可の境界
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“s3:*”,
“cloudwatch:*”,
“ec2:*”
],
“Resource”: “*”
}
]
}
“`

>
ポリシーを使用してユーザーのアクセス許可の境界を設定する場合、このポリシーではユーザーのアクセス許可は制限しますが

元記事を表示

学びのメモ

* 「わからないことは必ず調べてノートにメモり、毎日数週間分の学びを見返す」ことを2020年5月にエンジニアになってから続けています。
* 1年で3冊になりました。
* ノートに書くと
* きれいに書きたい気持ちが出るので、ちゃんと理解と頭の整理ができる
* 手を動かすので記憶に残りやすい
* 図を描きやすい
* 見返しやすい

という利点は感じていたのですが、やはり過去の学びを検索したりリンクを残したい気もしてきたので試しにこちらに書いてみます。

* ジャンル分けはせず、とにかく時系列で書いていくだけです。
* 自分が分かっていなかったことだけを書くので、参考にしないでください。。

1. =========最新が一番上==========
* Q: 二重レンダリングエラーを避けるには?
* [`render hogehoge and return`という書き方もある](https://railsguides.jp/layouts_and_rendering.html#%E4%BA%8C%E9%87%8D%E3%83%AC%E3%83%B3

元記事を表示

amplify mock api での DynamoDBへの接続(amplifyのワークショップ)

AWSが提供する、NoSQLWorkbench があり、それを使うとAWSの`クラウド側のDynamoDB`、自身の端末に入れた`DynamoDB Local`に接続ができる。そのため、workbenchを使って接続したが、テーブルが見られなかった。そのため代替手段を探してみた
調査不足であるが、Workbenchが読み込む何らかの設定でキー(region、accessKeyId、secretAccessKey)が指定できれば接続できるとは思う。

## 環境
Windows10でDocker WSL2と `amplify` を VSCodeのリモートコンテナを使っている

– Windows10
– Docker WSL2
– Amplify
– VSCodeのリモートコンテナを使っている
– ホスト:自身の端末PC
– リモートコンテナは https://github.com/toricls/aws-amplify-sns-workshop-in-vscode を使っている

## 状況
– コンテナの中で、amplify(とDynamoDB Local相当)は動いている
– am

元記事を表示

【AWS】EBSのボリュームタイプ

#プログラミング勉強日記
2021年5月26日

#EBSのボリュームタイプ
 EBSには5つのボリュームタイプがある。ユースケースに応じて性能やコストが異なるので5つの中から選択する。
 SSD形式は汎用SSDとプロビジョンドIOPS、HDD形式はスループット最適化HDDとコールドHDDの2種類ずつある。
 
##汎用SSD
 最もよく使われるもので、一般的なアプリを作るときになど「まず」選ぶことが多い。
 ユースケース:仮想デスクトップ、低レイテンシを求めるアプリ、小・中規模のデータベース、開発環境
 サイズ:1GB ~ 16TB

##プロビジョンドIOPS
 非常に性能が高く値段も高く、I/O性能非常に高いEC2インスタンスを作る際に使用する。スループット最適化HDDよりもスループット性能は高い。
 ユースケース:高いI/O性能が必要なNoSQLやアプリ、10,000IOPSや160MB/sを超えるワークロード大規模データベース、NitroシステムAmazon EC2インスタンス・EBS最適化インスタンスタイプで高速化
 サイズ:4GB ~ 16TB

##スループット最適化H

元記事を表示

AWS Batchは並列分散処理も、順次処理も書きやすい

## 概要
![actual_run.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/57898/0a681b06-6388-92d8-25b4-4767ce6c36fb.png)

### 課題・状況
– 大量データの処理を、決まった時間かつ短め(40分とか)に処理したい
– 並列処理のあとにも順番で動かしたいjobがある
– 並列化の仕組みの導入にあまり時間をかけたくない、
– AWS Batchは導入済みだった

### 結果

– AWS Batchの「並列job」と「job依存関係」を使ったらかんたんに解決できた
– 後述: [並列jobをAWS Batchで動かす](https://qiita.com/NaoyaIchikawa/items/c0911553f4f3153ccfd6#%E4%B8%A6%E5%88%97job%E3%82%92aws-batch%E3%81%A7%E5%8B%95%E3%81%8B%E3%81%99)
– 後述: [順序のあるjobをAWS Ba

元記事を表示

【個人開発】マンガを楽しむWebアプリを支える技術の共有:インフラアーキテクチャおよび技術選定

## はじめに
– 各出版社さんがWebでマンガを公開しているのをご存知でしょうか?かなり大量のタイトルを読むことができるので、私はひたすら読ませてもらっています。
– ただしネックがあり、**各Webサイトはバラバラに運営されているため、マンガの新着確認が面倒**でした。また**公開日が限定されているため、読み逃すこともしばしば**ありました。
– このような課題を解決するために、**複数サイトを横断してチェック可能で、かつ公開日を簡単に把握できる**サービスを作ることにしました。
– ちまちま作っていましたが、ようやく人様にも見せられそうなレベルになったので、それまでに技術的につまったところ、発見したことなどを記事にして公開していこうと思います。
– 完璧独学で取り組んだので、「おいおい…」というような実装もあるかもですが…。

作成したWebアプリ:

https://www.comiclake.net/

APIのキャパシティをかなり絞ってあるので、その状態でまともに動作するかは様子見です…。

## インフラ構築
– AWSの基礎を学んだことがあったため、AWSを活用すること

元記事を表示

Former2を使って既存のAWSリソースからテンプレートを生成

既存のAWSリソースからCloudFormationやTerraformのテンプレートを生成できるツール「Former2」を試してみました。

# 環境構築
Former2はWebベースで動作するので、[former2](https://former2.com/) にアクセスすれば利用できます。
自分のAWSリソースにアクセスするための認証情報を登録する必要がありますが、サードパーティのツールに機密情報を入力したくない場合はDockerを使ってローカルにサクッと環境構築できます。

“`bash
git clone https://github.com/iann0036/former2.git
cd former2/
docker-compose up -d
“`

`docker-compose.yml`をのぞいてみると以下のような感じでした。

“`yaml:docker-compose.yml
version: ‘3’
services:
former2:
image: nginx:1.17.8-alpine
ports:
– “127.0.

元記事を表示

pemファイルを紛失してEC2にログインできない時の対処法 AWS Systems Manager

##はじめに
EC2の秘密鍵を紛失してしまい、EC2にログインできなくなってしまったの対処法について記載します。
僕の場合、今までpemファイルを置いていたディレクトリを変更したところなぜかそのディレクトリからpemファイルが消えてしまいログインできなくなってしまいました。
AMIと新しいキーペアを作成して適用させる方法もあるそうですが僕は上手くいかなかったので、ここではAWS Systems Managerを使用した方法を紹介します。
なおこのやり方は既存のインスタンスに対して秘密鍵の追加というイメージになるかと思います。
またmacのPCを使用しているため、windowsの方は若干表示や手順が異なる箇所があるかもしれません。ご了承いただければ幸いです。

##対処法

まず以下の流れとなります。
①AWS Systems Manager自動化の実行
②AWS Systems Managerパラメータストアから秘密鍵を取得
③新しいキーペアを作成
④秘密鍵情報をpemファイルに記載
⑤EC2にログイン

####①AWS Systems Manager自動化の実行
まずはAWS S

元記事を表示

S3 + CloudFront をCMSとして使うときにPageSpeedInsightにキャッシュポリシーを怒られた場合の対処メモ

## この記事は何
自作中のwebシステムの画像配信にS3+CloudFrontを使っているのですが、サイトパフォーマンス可視化のためにPageSPeedInsightを試した際、良く見かけますが ↓ の感じで怒られました。その対処です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621288/119af2dc-2f00-2482-418d-fbd2aa37d9ab.png)

## 結論
– CloudFrontでTTL設定をしても、それはCloudFront側のキャッシュ設定なだけで、クライアント側のキャッシュ設定はファイルにメタデータを付与する必要がある。
– バケット内の既存ファイルのメタデータ編集はAWSマネジメントコンソールから簡単に実行できる。
– 今後追加するファイルへの対処方法はケースバイケースだが、自分の場合はLambdaでバケットにファイルを追加するシステム構成のため、そのアップロードときに適切なメタデータを付与するようにLambdaを修正することで対処した。

元記事を表示

AWS SES(sandbox) をfreenomで取得したドメインで作成

前提

テストでAWS SESを使ってみたい。

教材

こちらのサイト

https://note.com/dafujii/n/n12bb564081f1

https://note.com/dafujii/n/n0365dc0a89af

https://dev.classmethod.jp/articles/amazon-ses-build-and-practice/

用意するもの

freenomドメイン
送信受信ができるメールアドレス

実作業

– Route53にホストゾーンを追加する

①AWSコンソールからRoute53を選択し、DNS管理からホストゾーンを追加する
freenomで作成したドメインを入力する。
タイプを「パブリックホストゾーン」にする。
レコード → NSとSOAが作成されるので、NSの4つの値をFrenomのネームサーバにコピペする。

– SESにドメインを作成する

②AWSコンソールからSESを選択し、リージョンをオレゴンにする。
「Domains」→「Verify a New Domain」
ドメインを入力し

元記事を表示

git-secretsでgit経由の情報漏洩を防ぐ

AWSの学習を始めたので、`git-secrets’で安全な運用ができるように
学習しました。忘れないようにまとめておきます。

## `git-secrets`とは
https://github.com/awslabs/git-secrets
>Prevents you from committing passwords and other sensitive information to a git repository.

パスワードやその他センシティブな情報をコミットから貴方を守ります。
コミット時や任意のタイミングで、コミット内容やmessageに機密情報が含まれないかをチェックすることができます。
情報漏洩が何かと問題に上がる昨今、こういったツールで管理することは大切ですね。

## インストール

“`shell
$brew install git-secrets
“`

## コマンド概要(Synopsis)

“`shell
git secrets –scan [-r|–recursive] [–cached] [–no-index] [–untra

元記事を表示

Google SpreadSheetのデータをHTTP(GAS)で抜いて、AWS S3へ格納するlamdba処理(メモ)

# 目的

GASにHTTPアクセスすると、必ず1度リダイレクトされるため、HTTPアクセス元のシステムによってはデータを取得できない。
(iOS Podcastでは、Google SpreadSheetとGASで用意した自前のRSSを食ってくれない)

lamdbaでGASを叩き、テキストファイルをS3へ格納する(実装方法は趣味です)

# lamdbaコード

“`javascript:index.js

const gas_url = “GAS_URL”; //要編集
const backet = “S3_backet_name”; //要編集
const file = “file_name”; //要編集

const AWS = require(‘aws-sdk’);
const https = require(‘https’);

// リダイレクト先 URL を取得する関数
function get_redirect_url(src_url) {
console.log(“Call get_redirect_url”);

元記事を表示

NuxtをコンテナにしてLambdaでデプロイするのが超簡単になった2021年

以前書いた[LaravelをコンテナにしてLambdaでデプロイするのが超簡単になった2021年](https://qiita.com/umihico/items/514cf792d30bf3706ef5)のNuxtバージョンです。[Djangoバージョンはこちら](https://qiita.com/umihico/items/4534e1f84e8de5a62db5)

有名どころで[nuxt-serverless](https://github.com/tonyfromundefined/nuxt-serverless)など色々ありますが、こんな手間・デメリットがあったかと思います。

– 静的ファイル用にS3を用意、同期対応
– API GatewayのURLに付与されるステージ変数の対応
– `npx create-nuxt-app`を使ったセットアップを行えない

そんな中、[それらのデメリットを脱却できそうな記事](https://www.serverless.com/examples/aws-node-vue-nuxt-ssr/)を見つけたので、create-next-

元記事を表示

OTHERカテゴリの最新記事