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

Serverless Frameworkのアプリにカスタムドメインを付与する

[前回作成したLaravelのサーバレスアプリ](https://qiita.com/umihico/items/64fcf159f68ebd866170)にカスタムドメインでアクセスできるようにします。
ACMを取得します。Route53経由の方はDNS経由で簡単に取得できます。サブドメインはワイルドカードで申請するのみです。
**Lambda関数がEdgeの場合は、`us-east-1`(バージニア北部)のACMである必要があります。東京のACMは関係ありません。**

発行済になったら`serverless-domain-manager`のインストールします。[a4e6e25d](https://github.com/umihico/l

Lambda@Edgeを完全に理解する?‍♀️

# 何者だお前は
2017年7月17日に正式リリースされたサービス。
[Lambda@Edge の一般提供を開始](https://aws.amazon.com/jp/about-aws/whats-new/2017/07/lambda-at-edge-now-generally-available/)

>AWS Lambda にコードをアップロードし、Amazon CloudFront イベント (ビューワーリクエスト、ビューワーレスポンス、オリジンリクエスト、オリジンリクエストなど) によってトリガーされるように設定するだけです。関連するリクエストが CloudFront によって受信されると、ビューワーに近い最適な AWS のロケーションに実行のためルーティングされます。次に、Lambda@Edge はコードを実行し、CloudFront のグローバルなネットワーク間のリクエストのボリュームに応じてスケールします。Lambda@Edge により、コードを実行して各個別のリクエストに基づいてウェブページをカスタマイズし、グローバルに実行されるカスタム認証ロジックを作成して、安全な

iOSデバイスでプログラミング環境構築

### 今時机やPCの前だけで作業できる環境はナンセンスでしょ？！
スキマ時間の有効活用や職場にラップトップ、タブレットを持ち込めないとき、旅行などのための環境構築です。
PCが壊れても別の端末ですぐ作業開始できる環境が大事。
布団の中でゴロゴロしながらもプログラミングできますし
旅先で重たいラップトップなんか持ちたくない

### 用意するアイテム
– iOSデバイス
– モバイルキーボード（なくても可）
– [Working Copy（GitHub用）](https://apps.apple.com/jp/app/working-copy-git-client/id896694807?l=en)
– [Textastic](https://apps.apple.com/jp/app/textastic-code-editor-9/id1049

Laravelのサーバレス用ライブラリbrefを使い、lambdaでhello world

プロジェクトを作ってから少し手を加えるだけで、Laravelのサーバレス化ができました。
AWS上のデプロイはServerless Frameworkが全てやってくれます。

[本家のドキュメントはこちら](https://bref.sh/docs/frameworks/laravel.html)
[Githubはこちら](https://github.com/umihico/laravel-demo)

“`bash
composer create-project –prefer-dist laravel/laravel laravel-demo #プロジェクト作成
cd laravel-demo
composer require bref/bref #肝のbrefインストール
“`

以下の編集を加えます。[b508b15](https://github.com/umihico/laravel-demo/commit/b508b15edf5d1f0a0a7b51e2360e4f390da3dac1)

“`diff:.env
– SESSION_DRIVER=file
+

【#awscli】管理者権限を持たないWindows環境に「AWSコマンドラインインターフェイス(AWS CLI v2)」をインストールする #AWS #awscliv2 #jawsug #環境構築 #環境設定

AWS CLI v2では「Pythonがなくてもインストールできるようになった！」というのがウリなのですが、 相変わらずWindows MSI インストーラ形式で提供されているので管理者権限を持たないWindows端末にインストールすることができません。

というわけで管理者権限を持たないWindows端末に「AWSコマンドラインインターフェイス(AWS CLI v2)」をインストールした際の内容を自分用のメモとしてまとめました。

#### 環境情報
|OS/ソフトウェア |バージョン |入手元 |
|:—|:—|:—|
|Windows 10 pro |バージョン1903(May 2019) |Microsoft Corporation |
|Python3 |3.8.2 |https://www.python.org/downloads/windows/ |
|pip |20.0.2 | |
|botocore |2.0.0dev6 |https://github.com/boto/botocore/archive/v2.tar.gz |
|aws-cli |2.0.

時々忘れるので「MFA前提でAWS CLI を使う方法」をメモ

# 概要
MFAを有効にしている前提でAWS CLIを使うときの方法を忘れて、ハマる事象の回避のためのメモとリンク

# 要するに
1. aws sts get-session-tokenでキーを取得
2. exportでキーを設定
3. aws xxを打てる状態に

# 手順
AWS公式ページを見て実行するのみ。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/authenticate-mfa-cli/

【#awscli】あらかじめ指定した接続元IPアドレス以外からの「AWS CLI v2」実行時はMFA(ワンタイムパスワードでの認証)が必要になるようIAMを設定する #AWS #awscliv2 #jawsug #環境構築 #環境設定

特定の接続元IPアドレス以外からの「AWSコマンドラインインターフェイス(AWS CLI v2)」実行時のみMFA(Multi-Factor Authentication)が必要になるようにIAMの設定をしたので、その際の手順を自分用のメモとしてまとめました。

# MFA(Multi-Factor Authentication:多要素認証)とは

**参考: Wikipedia – 多要素認証**
https://ja.wikipedia.org/wiki/多要素認証

簡単に説明すると次の4つの要素のうち2要素以上を使用して認証を行うことです
1.知る要素
2.持つ要素
3.備える要素
4.場所の要素

認証を多段階で実施しても(多段階認証をしても)、同じ要素での認証ではセキュアではないとされています(例: ”印鑑”と”通帳”など)

ちなみに、
天空の城ラピュタにおける崩壊の呪文は、

* **”バルス”** という呪文を【←知る要素】
* **飛行石の結晶** を持った状態で【←持つ要素】
* **王族の人間** が【←備える要素】
* **ラピュタ内の聖域と呼ばれる場所**

CloudFront×S3で403 Access Deniedが出るときに確認すべきこと

# 前提
– S3をオリジンとしたCloudFrontディストリビューションを作成している
– HTMLや画像ファイルをCloudFront経由で配信したい
– 独自ドメインのCNAMEを登録している

CloudFrontのドメイン、またはCNAMEで登録している独自ドメインにアクセスすると以下のような画面が表示される

これをアクセスできるようにすることがゴールです。

# 確認すべきこと

## バケット内のオブジェクトが公開されているかどうか
まずCloudFront抜きのS3単体で考えます。

特に制限をかけておらず、バケットのパブリックアクセスが可能になっている状態であれば、
`パブリック` という黄色のラベルが表示されているはずです。

AWS で無料のサーバーを 30 分で立てる

しばらく前に AWS の知識をゲットしたはずだったんだが、記憶力が悪いせいですっかり忘れた。

インターネット上に自分用の Linux サーバーが欲しかったので、AWS を使おうとしたのだが、ほとんど何も覚えてない。ゼロから始めてサーバーを立てるまで、を復習がてら記事にする。

AWS はユーザー登録から 1 年間の無料枠があるとはいえ、ユーザー登録にクレジットカード番号が必要。これは済んでいることとする。

# まずはじめに
トップサイトからログインすると、画面遷移して「AWS マネジメントコンソール」に連れていかれる。ここが異世界の入口だ。タダでもらえる初期装備はなかなか豪華で、小さいサーバーならタダで使わせてもらえる。マネジメントコンソールのメニューを探して「Billing」と「VPC」と「EC2」とを確認する。この 3 つが主な活動場所だ。

# Billing

課金の状況を知るところ。

まず最初はここを知らないと安心して使えない。ここには「今月はいくらかかったか」の金額が表示されている。無料枠の中で使っていれば $0 と表示されているはず。

# VPC ダッシュボード

AppSyncでLambdaを呼び出す

# AppSyncでLambdaを呼び出す

## はじめに
先日「[API Gatewayでリクエストして、Lambdaで処理させて、AppSyncで受け取る](https://qiita.com/w2or3w/items/227465969ecbbef21787#lambda%E3%81%AE%E4%BD%9C%E6%88%90)」という記事を書きました。この記事のあとがきにも書いたのですが、フロントエンドからLambdaを実行させるために何の迷いもなくAPI Gatewayを利用していたのですが、どうやらAppSyncでも出来そうだぞということで。

データソースにDynamoDBを指定しているAppSyncへ、LambdaをデータソースとするIFを追加します。

## スキーマへIFの追加
AppSyncのスキーマに、モザイク処理を実行するためのIFを追加します。
AWSコンソール > AppSync > 目的のAPI > スキーマ
MutationへprocessApplyMosaicという関数、そして入出力用のデータ型を定義します。
入出力用のデータ型はAPI Gatewa

【Laravel】CloudFront+S3で署名付きURLを使いプライベートコンテンツを配信する

# 環境
– PHP 7.4.1
– Composer 1.9.3
– Laravel Framework 6.14.0
– league/flysystem-aws-s3-v3 1.0.24
– aws/aws-sdk-php 3.133.40
– aws/aws-sdk-php-laravel 3.5.0

# 手順
長いのでだいぶ雑です。

## 1. S3アップロード実装

まず[公式ドキュメント](https://readouble.com/laravel/6.x/ja/filesystem.html)に則り、Flysystemを使ってS3に画像をアップロードするところまで進めます。
AWSアカウントの作成, S3バケットの作成, IAMポリシー/ユーザの作成などは、ググれば良い資料が沢山出てくるのでそちらを参照してください。

“`shell

composer require league/flysystem-aws-s3-v3
“`

`config/filesystems.php`には既にS3用の記述が存在するため、編集する必要はありません。
`.env`ファイル

Elastic Beanstalkの.ebextensionsでApacheのDocument Rootを変更する方法

Elastic BeanstalkでEC2を立ち上げる際、ApacheのDocument Rootは

“`httpd.conf

DocumentRoot “/var/www/html/”

“`
となっています。
これを変更しようとしたのですが、ちょっとトリッキーなことをしたので、残しておきます。

## 環境
64bit Amazon Linux/2.9.3
Apache/2.4.41

## やり方
.ebextensionsのフォルダ内に以下のファイルを入れます。

“`apache.config
files:
/etc/httpd/conf/myhttpd.conf:
content: |
##以下にDocment Rootを変更したconfファイルの内容を記載する
##例えば↓↓
DocumentRoot “/var/www/html/public”

#### End of AWS Settings ####
container_commands:
00-rm-httpd-conf:

ELB(ALB)の設定・接続・確認

# 内容
Application Load Balancerの設定を行う。
以下のような構成を構築する。

# 前提
・下記構成が既に配置されていること。
・セキュリティグループの通信許可設定がされていること
・EC2にApacheがインストールされていて起動していること

“`
# yum install -y httpd
# systemctl start httpd.service
# systemctl status httpd.service
# ps -ef | grep -v grep | grep apache
“`
![ALB2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/510919/50427889-b3b2-b94a-4919-97d

AWS Backup定時備份RDS

– [0. Intro](#0-intro)
– [1. 認識AWS Backup](#1-%e8%aa%8d%e8%ad%98aws-backup)
– [2. 透過Web console來建立AWS Backup](#2-%e9%80%8f%e9%81%8eweb-console%e4%be%86%e5%bb%ba%e7%ab%8baws-backup)
– [2.1 新增Backup Plan](#21-%e6%96%b0%e5%a2%9ebackup-plan)
– [2.2 Assign Backup Resource](#22-assign-backup-resource)
– [3. 透過Cloudformation來建立AWS Backup](#3-%e9%80%8f%e9%81%8ecloudformation%e4%be%86%e5%bb%ba%e7%ab%8baws-backup)
– [4. 使用tags來快速filter需要備份的資源](#4-%e4%bd%bf%e7%94%a8tags%e4%be%86%e5%bf%ab%e9%80%9ffilter

Amplify Consoleで複数バージョンのVueアプリケーションのデプロイとFacebook認証

## やりたいこと

VueとAmplifyを使って以下のアーキテクチャを構築する。

– Facebook認証機能を持ったVueアプリケーションの実装
– production/development の2つのデプロイ環境を作る
– Githubへのプッシュをフックし、それぞれの環境へデプロイするCIの構築

## Vueアプリを作る

`vue create`したあとにCSSフレームワークとしてBulmaを組み込む。
[Vuetify](https://vuetifyjs.com/ja/)とか[vue-bulma](https://github.com/vue-bulma)を使わないのはただのポリシー。

“`bash
$ vue create vue-amplify-facebook
$ cd vue-amplify-facebook
$ npm install –save bulma node-sass sass-loader
$ mkdir src/assets/sass
$ touch src/assets/sass/main.scss
“`

**src/as

PythonモジュールをLambda Layerにアップロードする時のフォルダ構成について

## はじめに
Lambda Layerを使おうとした際にPythonモジュールのフォルダ構成でハマったので、備忘として記事にします。Lambda Layerについては[AWSの公式ドキュメント](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.html)をご確認ください。

## フォルダ構成
プログラミング言語ごとのフォルダ構成については[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.html#configuration-layers-path)でも言及されています。
Pythonの場合、“`python/“`配下にLambda Layerで使用するモジュールを配置する必要があります。
例えば以下のようなイメージです。

“`
python
　├─test1.py
　└─common
　　　└─test2.py
　
“`

Layerにアップロードするには、上記`

Excon::Error::Socket: getaddrinfo: Name or service not known (SocketError)というエラー文の対応

## 環境
$ ruby -v
ruby 2.6.5
$ rails -v
Rails 5.2.4

Amazon Linux 2

## 状況
本番環境としてデプロイした後に、画像をCarriorwave,fogを通じてS3にアップロードしようとすると、エラーが発生。
エラー文は以下の2種類。

“`
Excon::Error::Socket: getaddrinfo: Name or service not known (SocketError)
“`

“`
SocketError: getaddrinfo: Name or service not known
“`

## 本件の原因

“`ruby:config/initializer/carrior_wave.rb
if Rails.env.production?
CarrierWave.configure do |config|
config.fog_provider = ‘fog/aws’
config.fog_credentials = {
provider: ‘AWS’,

AWS CDKで快適なクラウド開発

# はじめに

このスライドはどこかでLT発表するためにつくりました。今回は[AWS CDK](https://aws.amazon.com/jp/cdk/)を使うメリットについて改めてお話します。

—

# 自己紹介

– 名前
– @ufoo68
– 出身
– 滋賀県草津市
– 最近やってること
– OSS活動
– [スポーツIoTLT](https://www.facebook.com/groups/1180573312126219/)の主催
– 私のAWS経験
– [SAA](https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/)の取得
– AWSを用いる案件
– [re:invent](http://reinvent.awseventsjapan.com/)の参加

—

# AWS CDKとはなにか？

**AWS CDK**とは、プログラミング言語を使って**AWSのクラウド環境をプロビジョニングする**ためのオープンソースのフ

Route53のバックアップを取得する

# はじめに
Route53のゾーン情報をバックアップする方法を説明します
今回はBINDのゾーンファイル形式で出力されます。
Route53はゾーンファイルのインポートが可能なので、Route53を別アカウントに引っ越すことになった場合にも利用できそうです。
## 手段
cli53を利用します。
https://github.com/barnybug/cli53
## 検証環境
今回の記事を書くにあたり、以下の環境で確認を行いました。

– バックアップスクリプト実行環境
– Linux(CentOS8)
– aws cli 2.0.4
– cli53 0.8.17
– 対象のDNS
– AWS(Route53)
– パブリップホストゾーン
– プライベートホストゾーン

# 事前準備
## AWS側の準備
### IAMユーザの作成
Route53の情報を出力できるユーザを作成します。
今回は「AmazonRoute53ReadOnlyAccess」のポリシーをアタッチしました。
## Linux（バッ

AWS API GatewayのAPIタイプ概要

## 動機

AWS API Gateway を触る機会があったので、メモする。REST API と HTTP API の機能比較を簡単にまとめる。

## REST API と HTTP API の概要

[よくある質問](https://aws.amazon.com/jp/api-gateway/faqs/)から抜粋した内容を下記に記載する。

> HTTP API は次のような場合に適しています。
1. AWS Lambda または HTTP エンドポイント用のプロキシ API を構築する
2. OIDC および OAuth2 の認証を備えた最新の API を構築する
3. 非常に大規模になる可能性があるワークロード
4. レイテンシーに敏感なワークロード用の API

> REST API は次のような場合に適しています。
1. API の構築、管理、公開に必要なすべての機能が含まれているセットに対して単一価格の支払いを希望されるお客様。

HTTP API は REST API と比較して機能を絞っている分、低レイテンシー低コストをウリとしているらしい。レイテンシーの差異