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

SysOps試験対策

#ECインスタンス関連
– InstanceLimitExceeded　⇒　あなたは地域で起動できるというインスタンスの数の上限に達してる（リージョン単位）
– InsufficientInstanceCapacity　⇒　AWSにはリクエストを処理するのに十分なオンデマンド容量がない
– EC2インスタンスがpendingからterminated
– EBSボリューム制限に達してる
– EBSスナップショットが破損
– ルートEBSボリュームは暗号化されており、復号化のためにKMSキーにアクセスする権限がない
– インスタンスの起動に使用したインスタンスストアにバックアップされたAMIに必要な部分（image.part.xxファイル）がない
– CacheNodeTypeパラメータ　⇒　EC2インスタンスタイプ指定
– CreateCacheCluster　⇒　新しいクラスタ作成

#CloudWatch
– DiskQueueDepthメトリック　⇒　使用可能なストレージスペースではなく、ディスクへのアクセスを待機している未処理のIO（読み取り/書き込み

AWSスナップショット管理の決定版！！Veritas CloudPointを、ガッツリご紹介します！！

#はじめに
今回は、Vertias CloudPointの紹介です。

紹介資料のフル版はSlideShareに公開していますので参照ください。
「Vertias CloudPoint（AWS スナップショット管理）マーケットプレイスから導入してみた」もご覧ください。
ダイジェスト版の動画（説明つき）と資料についても、別途公開予定です。

本記事では、下記の内容を抜粋して紹介します。

1. クラウド上で、バックアップって必要なの？
2. クラウドのスナップショットって、バックアップ用途に使えるの？
3. Veritas CloudPointって何？
4. CloudPointは、AWS Backupと何が違うの？

※スライド画像の下に、説明を記載しています。
※画面右側の目次もご使用ください。

#クラウド

AWS Amplify　はじめてみる編

`AWS Apmlify`は、モバイルアプリケーションとウェブアプリケーションを構築するためのAWSがOSSで公開する開発プラットフォームです。
簡単に言えば、AWSでもFirebaseみたいにバックエンドはお任せでフロントだけ開発できるようにしてくれるフレームワークみたいなやつです。
あくまでもプラットフォームなので、`AWS Amplify == Firebase`ではないです。

↓AWSのページ
[https://aws.amazon.com/jp/amplify/](https://aws.amazon.com/jp/amplify/)

↓公式ドキュメント
[https://aws-amplify.github.io/docs/](https://aws-amplify.github.io/docs/)

今回は、Apmlifyの概要とプロジェクトの作成からデプロイまで軽く触ってみます。

## AWS Apmlifyとは

AWSのサービスを用いた、Web・モバイルアプリを最速でリリースするための開発プラットフォームです。
React, Vue, AngularなどでのS

Oracle Cloud Infrastructure Data Scienceを使って、OCI Object StorageとAWS S3のファイルデータにアクセスしてみる

#本記事の狙い
2020/2に、Oracle Cloud Infrastructure Data Science(OCI-Data Science)がリリースされました。
前回、OCI-Data ScienceからOracle Autonomous Database(ADW)上のデータにクエリしてみたので（[Qiita記事：Oracle Cloud Infrastructure Data Scienceを使ってOracle Autonomous Database(ADW)のデータにアクセスしてみる](https://qiita.com/maato/items/d946e83facad12faf184)）、本記事では、実際にOCI-Data Scienceを使って、Oracle Cloud Infrastructure Object Storage（OCI-Object Storage）と、AWS S3上のファイルからデータを取得する手順を、実際に実施してみたいと思います。

#参考文献
###実施に参考になるリンク
– [Oracle Cloud Infrastructure Data

Aurora Serverless が起きるまで待つ

例えば AWS Lambda + Amazon CloudWatch Events で定期的にどこかからデータをひっこ抜いてきて適当に Amazon RDS にでも突っ込んでおくかという場合に、普通の Provisioned インスタンスだと少なくとも数千円/月はかかってしまうが Aurora Serverless にすれば使っていないときは勝手に寝てくれるので格安で済むのではないか。[^pricing]

[^pricing]: [Amazon Aurora Serverlessの利用費を試算してみた | Developers.IO](https://dev.classmethod.jp/articles/calculate-amazon-aurora-serverless-costs/)

ただしこのアイデアにはひとつ問題があって、**Aurora Serverless が起きるのが遅い**ということ。

DB クライアントから接続を試みると寝ていた Aurora Serverless は起動し始めるが、接続を受け入れられるようになるまでの間にクライアントがタイムアウトしてしまうな

チャットアプリにAWSのS3（ストレージサービス）を導入

# チャットアプリにストレージサービスを導入します。

**進める上での注意点**

手順を間違えると悪用され、高額請求される可能性があります。

S3を使用する上でどうなると被害が出るのかというと
悪意を持ったユーザーにAWSのIDとパスワードが漏れてしまうことで被害が発生！

AWSは従量制のサービスのため、他人がなりすましでログインして膨大な処理を行うと、それに対する支払いが発生してしまう(^◇^;)

#### 今回は下記の3つの手段を取ります。

##二段階認証

##IAMユーザーの利用

##git-secrets

【AWS】IAMユーザーのMFAの設定をマストにする

# 概要
* AWS IAMのドキュメントのチュートリアルで[MFAのマスト化](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html)は（ベストプラクティス的にも）最低限行なっておいたほうが良いと感じたので、その手法をまとめました
* 対象読者はIAM管理、IAMのベストプラクティスにのっとったセキュリティ管理に興味のある方です

# 0. 事前準備
[IAMのダッシュボード](https://console.aws.amazon.com/iam/)で、AWSマネジメントコンソールへのアクセスのみ許可されたテストユーザー(test_user)を作成し、ポリシーやアクセス許可が一切行われていないテストグループ（TestGroup)を作成してください

# 1. MFAサインインを強制するポリシーの作成
1. 管理者権限のあるIAMでAWSマネジメントコンソールにサインインしてください。（ルートユーザでのサインインはベストプラクティス上非推奨

API Gateway のカスタムドメイン設定方法と困った話 ( CONNECTION_REFUSED )

#API Gateway のカスタムドメイン設定で困った話
AWS(Amazon Web Service)の[API Gateway](https://aws.amazon.com/jp/api-gateway/)で、カスタムドメインを設定した時に色々トラブったのでメモを残します。
原因はかなりクダらないのですが、私のような初心者には割とありがちなのかも…？

##カスタムドメイン設定手順
メモがてら。route53に該当する独自ドメインが登録済みであることを前提とします。
独自ドメインを**hoge.com**、API用のサブドメインを**api.hoge.com**として説明します。
また、APIは東京リージョンで稼働するものとします。
それぞれ該当箇所を変更しながら作業してください。

####Certificate Managerで証明書を作る
セキュリティ、ID、およびコンプライアンスの項にあります。

1. 右上のリージョンを東京に変更
2. 証明書のリクエストをクリック
3. パブリック証明書のリクエストを選択
4. ドメイン名の追加　ドメイン名を入力する(api.h

Boto3（AWS SDK for Python）の利用する認証情報

Boto3の利用する認証情報は「[Credentials — Boto 3](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)」にまとめられており、8か所から規定の順序で認証情報が検索されます。

# 認証情報の検索順序

Boto3はパラメーターやプロファイルなど複数の方法で認証情報を取得しようとする。その方法と順序は「[Configuring Credentials – Credentials — Boto 3](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#configuring-credentials)」にあって、該当部分の拙訳は以下の通り。

> boto3の資格情報検索メカニズムは、以下のリストに沿って検索し、資格情報を見つけたらそこで停止することです。Boto3が資格情報を検索する順序は:
>
> 1. `boto.client()` メソッド

複数のディレクトリ内のファイルをaws cliでs3へアップロード

### aws cli でのエラー

findで、現在のディレクトリ以下に存在するディレクトリ内のファイルをまるっとs3にあげたいなと。
そこで再帰的に

“`
find . -type d | aws s3 cp – s3://${S3_BUCKET} –recursive
“`

のようにしたら `Reason: exit status 255` でエラー。
ドキュメントによると、エラー内容は↓とのこと。
> 255: コマンドが失敗しました。リクエストが送信された AWS CLI または AWS サービスのいずれかでエラーが生成されました。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-usage-returncodes.html

### –debugオプションをつける

CodeBuildには正しい権限を付与しているはず。。。
`–debug`オプションで検証。

“`
Streaming currently is only compatible with non-recursive c

AWSで設計する SAP NetWeaver 可用性と災害対策 その２

#はじめに
前項（[その１](https://qiita.com/vxse_japan/items/0c398cd8647d9f55fcfa)）ではSAPで可用性を担保しなければならないコンポーネントと概要、そしてVeritas InfoScale の役割について紹介しました。ベリタスの災害対策モデルを使って手堅くクラウド移行を実現することでミッションクリティカルなシステムを安心してパブリッククラウドへ移行することが可能ですし、**全てのコンポーネントをAWSで構成する場合もベリタスは安心して業務が継続できるシナリオをご用意しています。**

#サポートされる構成例は？
InfoScale は次のシナリオでSAP NetWeaverベースのアプリケーションインスタンスを監視および制御できます。

•１つのAZにすべてのSAPインスタンスを構成するケース
•複数のAZで構成するSAPインスタンスを構成するケース
•InfoScale エージェントを使用した SAP Web Dispatcher HA 構成
•SAPインスタンスのオンプレミスからAWSへのフェールオーバー
•クロスリージョ

AWSサーバレス環境における必要最低限の監視設定 ( ECS + Fargate 編 )

AWSでちょっとしたプロダクト（MVP）をECS+Fargateが開発したようなケースでアプリケーションを運用開始したときに、とりあえずそこまで手間はかけたくないけど最低限の監視はしたいという場合のために、箇条書き程度ですが、必要設定項目を整理してみました。

もしこういういった観点も必要だよねというのがありましたらご指摘いただけますと幸いです。

# 前提条件

– ECS + Fargate 環境でアプリケーションを運用する環境
– EC2を利用したサーバー運用がないこと
– ECS Serviceに対してAuto Scaling Groupが適用されていること
– アプリケーションの要件的に 24/365監視を専属のインフラチームが対応するほどではないこと
– 夜間にアラートがなったら PagerDuty等のインフラチームのメンバーの電話を鳴らすような仕組みは今回は対象外です
– インフラの監視にはあまりコストはかけたくなく、監視に関するツールはAWS内になるべく閉じたいこと
– [CloudTrail](https://aws.amazon.com/jp/clo

Fargate 導入概要 メモ

Fargate のメモ

# Fargate

AWS で簡単に Docker コンテナを動かせるサービス。
ただし、独自の概念が多く、慣れる必要がある。

筆者は以前に導入を試みて、挫折した。今日（2020/03/23）試してみたら、ドキュメントが良くなったのか、オンボーディングが良くなったのか、意外とすんなり理解できたので、記録しておく

# なぜ Fargate なのか

前提として

– PV 換算すると 月20万PVほどのアクセスのWebサービスを運用している
– インフラエンジニアが不在なので、あまり煩わしい作業はしたくない
– かといって、 EC2 はプロビジョニングとか面倒だし、ElasticBeanstalk はデプロイに時間かかるし小回りが効かない（経験談）
– とりあえず動けばOKなサービスに適用する（本サービスではなく、LP + アルファな感じ。Next.js利用）

AWS には EKS など魅力的なサービスがあるが、意外と高い。コントロールパネルを動かしているだけで、15000円くらいかかるらしい（と、AWS の方に言われた）

さくっとサービス動かすだけな

CloudFormationテンプレートを1からしっかり理解しながらECS on Fargateなアプリを自動構築する(中編)

# 前提条件
[前編](https://qiita.com/neruneruo/items/06b073f3846803f415e5)で作ったECSのサービスに対してCodePipelineを使ってCI/CDパイプラインを作るので、前編を理解しておく。

記事中には、備忘のためにリファレンスに書かれていないデフォルト値を整理しておくが、2020年3月時点の情報であり、後でAWSが仕様を変えたとしても追従する予定はないので、挙動が違ったらリファレンスを見直してほしい。あと、今回の構成(ECS on FargateのBlue/Greenデプロイメント)以外の構成以外のデフォルト値まで調査はしていないのであしからず。

# CodeDeployでBlue/Greenデプロイメントのアプリケーションを作る
## アプリケーションの設定
ここはそんなに悩むことはない。以下のような感じで設定しておけばOK。

“`YAML
APPLICATION:
Type: AWS::CodeDeploy::Application
Properties:
Applicatio

AWS認定ソリューションアーキテクト – アソシエイト 1回落ちて2回目で合格

AWS認定ソリューションアーキテクト – アソシエイト 受験の感想です。

## はじめに

今まで、AWSを使う機会は全く無かったのですが、
転職を機会きっかけにAWSに関わることが増えたため、知識の底上げとして受験することにしました。

実は、半年くらい前に一度受験したのですが、その時は落ちてしまい、再受験の機会を伺っていました。
そんな時、新しいバージョン(SAA-C02)が、2020/3/23から始まるとのことで、急遽受験することにしました。

## 1回目（落ちた）

#### 勉強
みなさまの合格記録を参考に勉強をはじめました。

– [黒本](https://www.amazon.co.jp/%E5%BE%B9%E5%BA%95%E6%94%BB%E7%95%A5-AWS%E8%AA%8D%E5%AE%9A-%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%88-%E2%80%93-%E3%82

DjangoアプリをローカルからAWSに上げたらCSSが適用されなくなった話

# 経緯
DjangoやAWSの学習のため、以下の記事を元にローカルでDjangoアプリを作成したあと、githubからAWSにclone。
[Django(Python)でシステム開発できるようになる記事_入門編](https://qiita.com/Saku731/items/ed64190a12a4498b9446)
[【20分でデプロイ】AWS EC2にDjango+PostgreSQL+Nginx環境を構築してササッと公開](https://qiita.com/tachibanayu24/items/b8d73cdfd4cbd42c5b1d)

AWS上で`python3 manage.py runserver`した後、ローカルでは管理画面に適用されていたCSSが適用されていないことに気づく。
【AWS初心者】×【対策本１冊のみ】×【 平日＋休日２日のみ（50時間）】でSAA（ソリューションアーキテクト アソシエイト）を取得する方法

## この記事の構成
▶合格するのに必要なもの３点（無駄を究極にそぎ落としました）
　①：対策本１冊
　②：”受けるからには **絶対に** 受かる”という強い意志
　③：50時間
▶これから始める人へのエール

## ①：対策本

本屋に並んでる対策本全部見て、以下の観点で決めました。
ポイントは**１冊に絞る**こと。複数冊買いたくなりますが、
９割以上重複してるので学習効率が悪いです。

– ページ数が少ない（重要！量より質を大事に）
– 図解が好み（超重要！色とかテイストは集中力に直結）
– 模擬試験の解説が教科書とリンクしている（最重要！！学習効率が爆上がり）


## ②：”受けるからには **絶対に** 受かる”という強い意志

なんのために試験を受けるか？

なん

EC2で稼働するECSのタスクにFirelensを適用する

# Firelensとは
– ECSタスクのログ出力を管理する仕組み
– サイドカーとしてFluent Bit、またはFluentdのコンテナをタスクに追加する
– サイドカーのためアプリケーションに変更を加える必要がない
– EC2、Fargateどちらのタスクでも使用可能
– ログの出力先はCloudwatch LogsやKinesis Data Firehoseなどのマネージドサービスはもちろんのこと、PapertrailやDatadogなどのSaaSの製品にも適用できる

# 目標
– ログの出力先をCloudWatch Logsから[Papetrail](https://www.papertrail.com/)に変更する

# 前提
– EC2で稼働するECSタスクを使用する
– Container Instanceで稼働するECS Agentのバージョンは、**1.30以降である必要があります**

# Firelensを使用せずにCloudWatch Logsへ出力する
– これはTask Definitionの設定のみで行えます
– Containerの

AWS障害は全て通知されると思ってた話

# 結論からいうと
アカウント固有のリソース障害であっても、全ては通知されません。

# 背景
EC2のシステムステータスチェック失敗や、VPNのトンネルステータスがダウン時に、Personal Health Dashboardやメールにて通知されていないことに気づいたので、サポートに問い合わせてみた。

# 問合せ結果
以下、問合せ結果の抜粋です。
>Personal Health DashboardにはAWSアカウント固有のリソースに対するメンテナンス情報や、お客様が影響を受ける可能性のあるAWS大規模障害の情報などが通知されます。
あらかじめ予定されているイベント情報や事前に予兆を検知することのできた障害情報、および広範囲に渡って発生した障害情報などは適宜通知されますが、現時点では個別のリソースにおいて一時的に発生した障害情報などは通知されません。

# 障害に対してどうすべきか
今回のようなEC2やVPNの障害については、Cloudwatchのメトリクスを監視するアラームを作成し、Amazon SNS トピックへの通知、EC2アクション、EC2 AutoScalingアクション

EC2上でvue+expressの環境構築からAPI通信実装まで

# バックエンド
EC2インスタンス上でexpressを動かし、アプリケーションのbackend環境を構築する。
ここでは例としてアプリケーション`app`を作る

## 環境構築
__AMI:Ubuntu18.04、IP:x.x.x.x の場合__

“`
$ sudo apt-get update
$ sudo apt-get install nodejs
$ sudo apt-get install npm
$ sudo update-alternatives –install /usr/bin/node node /usr/bin/nodejs 10
$ sudo npm install -g express
$ sudo npm install -g express-generator
$ express –view=pug app
$ cd app
$ npm install
$ npm start
> app@0.0.0 start /home/ubuntu/app
> node ./bin/www

“`

__AMI:AmazonLinux2、IP:x.x.