20190929のAWSに関する記事は12件です。

投稿日：2019-09-29T23:47:47+09:00

ChromeでAWS Cloud9に接続できないときの対象方法

はじめに

Ruby On Railsの学習のため、AWS Cloud9を使っています。
その学習中にCloud9に接続できなくなってしまいました。

その際に試した対処法をまとめます。

環境

OS：MacOS Mojave バージョン 10.14.6

ブラウザ：Chrome バージョン76

事象

Cloud9を開いていたタブを閉じて、数分後にまたCloud9にアクセスしたときに発生しました。
表示されたメッセージは以下になります。
This is taking longer than expected. If you think there might be an issue, contact AWS Support.
It might be caused by VPC configuration issues. Please check documentation.
※ スクショはとっていませんでした…

やったこと

Chromeのキャッシュを削除（変化なし）

Chromeのバージョンアップ確認（そもそもバージョンアップなし）

EC2の再起動（変化なし）

使用するブラウザを変更

使用するブラウザを変更

Chromeではなく、Safariを使用したら正常にアクセス、使用することができました。
Firefoxでも正常にアクセスできました。

ちなみに、後日Chromeで接続しても、正常にアクセスすることができました。

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T23:46:42+09:00

Elastic Beanstalk 利用時に httpでのアクセスを https にリダイレクトする方法

Elastic Beanstalk側でコンソール使用して設定できる項目がなさそうだったので、nginx側で下記のような設定を行った。
server {
  listen 8080;

  location / {             
    return 301 https://$host$request_uri;          
  }
}  
Elastic Beanstalkのコンソール側では、下記のように80番ポートがnginxの8080番ポートに行くように設定してやれば良い模様。

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T21:02:39+09:00

AWS cloud9 でEC2を使わずにAzureを利用する方法

Cloud9を利用するのときは通常EC2ですが、MSDNを契約している場合はAzureのサブスクリプションの無料枠を使いたくなるときがあります。

Azureで仮想マシンを作成する

仮想マシン名：_(アンダーバー）は利用できません
イメージ：Ec2に合わせてCentOSを利用しました。

管理アカウント

認証の種類：SSH公開キー
ユーザー名：任意
SSH公開キー：ここではWindowsPCで作成します

DNSラベルを設定する

WindowsPCで公開キーを作成します

サービスでOpenSSHクライアントを実行させる

続く...

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T17:31:45+09:00

【AWS】これだけ見れば理解できるCognito〜認証機能つきサーバレスアーキテクチャの作成〜

はじめに

クライアントアプリケーションを作成するにあたって、Cognitoの闇にハマってしまったため、備忘録として学習した内容を残します。
LambdaやSQSなどその他のAWSサービスと同じように公式ドキュメントを読み進めると確実に闇落ちします。(少なくとも私は落ちました。。)

理由として、Oauth 2.0、OpenID Connectの前提知識が必要になり、公式ドキュメントはそれを前提として書かれているからです。

図とスクリンショットを駆使して、概念と作成まで一気に説明します。
初心者にも一撃で理解いただけるよう、各設定内容のユースケースを細かく注釈を入れたので、これだけ見れば大枠は理解できると思います。

Cognitoとは

アプリケーションの認証認可を行うサービス
アカウント管理・認証認可の付与をAWS側で行ってくれる、フルマネージドサービス
Google・Amazon・Facebookなどの外部IDプロバイダーと連携可能で、Googleのアカウントを使用したログイン機能の作成や多要素認証などの拡張機能を備えています。

ユースケース

使い道としては、当たり前ですが以下になります。
・アプリでのログイン機能を追加したい場合
・データのアクセス制御を行いた場合

Cognitoの提供機能

Cognitoはユーザープール・フェデレーティッドアイデンティティ・Cognito Syncの機能を提供しています。

それぞれの機能概要は以下です。
※ちなみに今回はユーザープールのみを使用します。

ユーザープール

認証・認可を制御するためのメイン機能
Cognitoユーザーの管理・サインインサインアップ機能・外部IDプロバイダーやcognito発行のトークン管理などを行う。
シンプルな認証・認可の仕組みだけ実装したいなら、この機能のみで充足する。

フェデレーティッドアイデンティティ(別名：IDプール)

ユーザープールのアカウントに対して、IAMロールの付与を行う機能
ここで作成されるアカウントはIDプールと言い、前述のユーザープールとは別物という点に注意
アカウントごとに細かなアクセス制御や、後述のCognito Syncを使用したい場合に使用する。

Cognito Sync

IDプールで管理されるユーザー単位に、デバイス間でアプリケーションデータを同期する機能
新規で開発する場合、AWS AppSyncという新機能ができたので使用は推奨されない。

そもそもの話

長々と機能の概要を話しましたが、そもそもの認証・認可の解説をします。

認証・認可とは

だいたい以下の理解でいいと思います。

用語説明標準化(RFC)

認証相手の身元を明らかにすること
→ユーザーの認証の仕組み OpenID Connect 1.0

認可相手に適切な権限を付与すること
→認証したユーザーに対するデータアクセス制御の仕組み OAuth 2.0

OAuthとは

国際的な認可に関する標準化仕様のこと
クライアントと認可プロバイダーとのやりとり(インターフェイス)を定めている。
処理の大枠についてはこちらを参照してください。

OpenID Connectとは

国際的な認証に関する標準化仕様のこと
クライアントとOpenIDプロバイダーとのやりとり(インターフェイス)を定めている。
OAuthの仕様を拡張し作られた背景があるため、データフローが似ている。
処理の大枠についてはこちらを参照してください。

Cognitoの認証・認可について

上記OAuth・OpenID Connectの仕組みを利用して、認可・認証の仕組みを実現しています。
ところどころ出てくる用語は、この仕様上の用語とマッピングされているため、気になる方は調べてみてください。

トークンについて

先程までの説明でIDトークンとアクセストークンという用語が出てきましたが、
それぞれこのような特性を持ちます。
※更新トークンについては触れてませんでしたが、ここで解説します。

用語説明

IDトークン OpenIdにより規定されたユーザー情報
ヘッダー・ペイロード・署名で構成されており、ログインユーザーのクレーム(メールアドレスなど)が含まれる

アクセストークン OAuthにより規定されたアクセストークン
通常このトークンを使用して認可の処理を行う

更新トークン各トークンには有効期限が存在する。(長くて1時間とか)
そのため、本トークンを使用して、新規トークンの取得を行う(再びユーザー認証を行わなくても、本トークンを用いることで、新規トークンの発行が行える)

今回のアーキテクチャー図

フルマネージドサービスのみを使用した、よくあるWebアプリケーションを作っていきます。
ログインのUI画面はCognitoがホストするサービスを使用します。
ユーザーごとの細かな認可制御を行わないため、Cognitoはユーザープールのみ使用します。
※respose_type=tokenに設定し、ApiGatewayのオーソライザーを使用した認可制御を行います。

Cognitoの設定

それでは早速ユーザープールの作成から行なっていきましょう。

名前

好きな名前を設定してください。
今回は「ステップに従って設定する」を選択します。

属性

サインアップ・サインインの設定になります。

→ログインIDをメアドにするかどうかの設定です。
好きな設定を選んでください。

→サインアップ時に、ユーザーに要求する属性に関する設定です。
こちらの情報はIDトークンから取得可能なため、アプリ側で欲しい情報があればチェックを入れましょう。
また、選択肢にない項目はカスタム属性として定義できます。

ポリシー

パスワードに関する設定です。

→ユーザーに自己サインアップを許可させるかどうかは、自社内限定のサービスの場合は「管理者のみにユーザーの作成を許可する」を設定しましょう。

MFAそして確認

MFAと確認メッセージの設定です。

→多要素認証は毎回行う場合(必須)と、ログインに指定回数ミスった場合など(省略可能)、利用しない(オフ)から選択可能です。
また、サインアップ時の登録内容確認として、Eメールまたは電話番号の確認メッセージを飛ばすことができます。(どの属性を確認しますか？のチェックボックス)
各送信処理にはIAMロールが必要ですが、デフォルトの指定で問題ありません。

メッセージのカスタマイズ

メッセージ送信の内容・送信元の設定です。

→SESを使用してメッセージを送る場合は、リージョンの設定が必要です。
※現在(2019/09末)の段階では東京リージョンを選択できないみたいです。

→MFAのメッセージ内容として、確認コードとリンクの2種類から選択可能です。

→Cognitoのユーザーは仮パスワードが発行され、初回ログイン時に変更することでアカウントが有効になります。

タグ、デバイス、トリガー

タグとデバイス、トリガーの章は省略します。
デバイス設定では、ユーザーのログインした端末を記憶してくれるよう設定できるみたいです。
トリガーの設定では、認証前後にLambdaロジックを挟むことができ、通常の認証フローをカスタムできるそうです。
今回特に使わないので、デフォルトのままで進みます。

アプリクライアント

Cognitoを利用するアプリケーションに関する設定です。
「アプリクライアントの追加」をクリックし、作成しましょう。

→重要なポイントは以下になります。

・クライアントシークレットの作成有無
シークレットの作成を行う場合は、クラアント側で厳重に管理する必要があります。
例えばクライアントがWebアプリの場合、シークレット漏洩の危険性があるため生成はしないべきです。

・サーバーベースか・アプリベースか
認証の依頼者がエンドユーザー側にあるアプリかバックエンドのサーバーかを選択します。
バックエンドのサーバーの場合、「ADMIN_NO_SRP_AUTH」を選択、
エンドユーザー側にあるアプリの場合、「USER_PASSWORD_AUTH」を選択しましょう。

確認

設定を見直し、プールの作成をします。

アプリの統合

もう少し設定をします。
作成したプールの情報から、アプリの統合 > アプリクライアントの設定を選択します。

ドメイン名の選択をクリックし、

CognitoがホストするログインUIの設定をします。

→S3のバケット作成と同様、世界中で一意になるのドメインを入力してください。

続いてアプリクライアントの設定をします。

→有効なIDプロバイダを全て選択し、ログイン後のリダイレクト先を入力します。
※まだ、S3のwebページを作成していないため、とりあえずamazonとかのページを指定してみましょう。

OAuthの設定は、トークンを直接取得する「Implicit grant」を選択します。
もし、MVCモデルのようなアプリケーションを構築して入りのであれば、OAuthの理想的な形「Authorization code grant」を選択してください。
※「Authorization code grant」を選択した場合、エンドポイントにはトークンの代わりに認可ーコード(トークンと交換可能な手形)がクエリーパラメータとして渡されます。
エンドユーザーは認証コードをアプリサーバーに送ることで、サーバー側で認証コードとそれを使用して取得したトークンを管理することが実現でき、よりセキュアな設計になります。

「許可されている OAuth スコープ」については、どの情報を参照可能にするかの設定になります。
特にこだわりがなければ全て選択しましょう。

ユーザーの作成

最後にユーザーを作成します。
今回は「管理者のみにサインアップを許可する」を選択したため、コンソール上でアカウントを作成します。
全般設定 > ユーザーとグループから「ユーザーの作成」をクリックします。

→必要項目を入力したら設定完了です。

Cognito動作確認

Webブラウザから以下のURLを入力してみましょう。
ログインURL
https://{ドメイン名}.auth.{リージョン名}.amazoncognito.com/login?response_type={レスポンスタイプ※}&client_id={クライアントID}&redirect_uri={リダイレクトURL}

※レスポンスタイプは"token"か"code"を選択します。(今回の設定ならtokenを設定)
こんな入力画面が表示されたら成功です。

ログインに成功するとリダイレクトページに遷移します。
URLを見てみると、以下のようになっていると思います。
https://{リダイレクトURL}#id_token={IDトークン}&access_token={アクセストークン}&expires_in=3600&token_type=Bearer
→あとはJavaScriptから各パラメーターを取得すれば、だいたいのやりたいことができます！

Lambda・APIGatewayの設定

Lambda側の設定は特にありません。
APIGatewayについては、オーソライザーを使用し認証の機能を付与します。
ささっと作っていきましょう。

Lambdaの設定

関数の作成 >「一から作成」を選び、好きな関数名と環境を選択後、作成をクリック

「トリガーを追加」をクリックし、APIGatewayを作成します。

以下のように入力し、追加を押します。
これでLambda側の設定は終了です。
※細かい設定は後ほどします。

APIGatewayの設定

コンソールから、先ほど作成したAPIGatewayの設定画面に飛びます。
※この方法で作成した場合、APIGatewayの名前は「関数名 + -API」という名前になっています。

オーソライザーの作成

オーソライザーを選択し、

「新しいオーソライザーの作成」をクリック、以下のように入力しましょう。
※「Cognitoユーザープール」の箇所は先ほど作成した、ユーザープール名を選びましょう。

→「トークンのソース」で指定する名前はAPIGatewayにリクエストを投げる際のヘッダーフィールドに定義されます。
このフィールドにトークン(IDまたはアクセス)を設定することで、APIGatewayがCognito側に認証を自動で行ってくれるようになります。
※ここで指定する名前は好きな名前でいいです。
一般的に「Authorization」が使われるようです。

オーソライザーの設定

メソッドに対して、オーソライザーを設定します。
リソース > 設定したいメソッド(今回はANY) > メソッドリクエストを選択
認可の箇所を先ほど作成したオーソラーザーを設定しましょう。
※オーソラーザーの選択肢が出ない場合は、一度画面の更新をした方がいいです。

マッピングテンプレートの設定

リソース > 設定したいメソッド(今回はANY) > 統合リクエストから
「Lambda プロキシ統合の使用」のチェックボックスを外します。
下にスクロールし、「application/json」のテンプレートを作成しましょう。
※ここで設定した値は、Lambdaのevent変数に設定されます。
とりあえずパラメータの設定はしないので、下の画面のよう設定してください。

※APIGatewayとLambdaの設定とパラメーターの受け渡しは、ここが一番わかりやすいので気になる方は見てください。

CROSの設定

今回はS3のドメインからアクセスを行うため、CROSの設定が必要になります。
アクション > CROSの有効化から、設定をそのままの設定で「ヘッダーを置換」します。

デプロイ

これらの設定を反映させるには、デプロイが必要になります。
アクション > デプロイから、「デプロイ」をクリックしてください。
※ここで指定したステージ名はエンドポイントのURLの一部になります。

→ここで作成したエンドポイントは以下のようになります。
https://〇〇〇〇.execute-api.{リージョン名}.amazonaws.com/{ステージ名}/{lambda関数名}

Webページ(呼び出し元)の作成

これまで作成したAWSリソースたちを呼び出すwebページを作成します。
ライブラリはJQueryのみ使います。

トークン・ユーザー情報の取得

Cognito動作確認で使用したドメイン名を使用し、ログインユーザー情報の取得を行います。
アクセスを行うエンドポイントは以下です。
ログインURL
https://{ドメイン名}.auth.{リージョン名}.amazoncognito.com/oauth2/userInfo
※GETリクエストのみ許容しており、リクエスト時はヘッダー情報にアクセストークンを設定する必要があります。

公式の説明を参考にアクセスを行い、localStrageに必要情報の格納を行います。

アクセストークン・IDトークンの取得

URLの#(シャープ)以降に付与されているため、JSから取得を行います。
関数はこちらの内容を拝借させていただきました。
index.js
    //指定パラメータ取得処理(貰い物)
    function getParameterByHash(name, url) {
      let wHash = window.location.hash; //ハッシュ(#)以降をとる
      wHash = wHash.replace('#', '&'); //↓の処理を使いたいがために#を&に変換するorzorz
      name = name.replace(/[\[\]]/g, "\\$&");
      let regex = new RegExp("[?&]" + name + "(=([^&#]*)|&|#|$)"),
        results = regex.exec(wHash);
      if (!results) return null;
      if (!results[2]) return null;
      return decodeURIComponent(results[2].replace(/\+/g, " "));
    }
ユーザ情報取得

先ほどの関数を使用して、メインの処理を行うコードは以下になります。
※この関数はログイン後のユーザーが正しく認証できたかチェックを行う関数になります。

<処理の内容>
1.各種トークンの取得
2.トークンの取得に失敗した場合、ログインページに遷移させる。
3.ユーザー情報の取得
4.localStrageに保存
index.js
    //認証済みか検証を行い、ユーザー情報を取得する(認証未済の場合はログインページにリダイレクトする)
    function checkSession() {

      //パスパラメータの取得
      let idToken = getParameterByHash('id_token');
      let accessToken = getParameterByHash('access_token');

      //エラーならログインページに遷移
      if (idToken == null || accessToken == null) {
        window.location.href = 'ログインページのURL';
      }

      //ユーザー情報取得
      const requestAws = axios.create({});
      requestAws.get('https://{ドメイン名}.auth.{リージョン名}.amazoncognito.com/oauth2/userInfo', {
          headers: {
            Authorization: " Bearer " + accessToken
          }
        })
        .then(function(response) {
          responseJson = JSON.parse(JSON.stringify(response));

          //localStorageに各種情報取得
          let storage = localStorage;
          storage.setItem("idToken", idToken);
          storage.setItem("accessToken", accessToken);
          storage.setItem("name", responseJson.data.family_name + ' ' + responseJson.data.given_name);
        });
    }
APIGatewayへのアクセス

先ほど作成したAPIGatewayのエンドポイントに向けて、リクエストを投げます。
※オーソライザーを使用しているため、ヘッダーにIDトークンまたはアクセストークンを設定します。
index.js
    //APIGatewayにリクエスト
    function requestGateway() {

      let idToken = localStorage.idToken;
      let headers = {
        headers: {
          'Authorization': idToken
        }
      };

      let url = 'APIGatewayのエンドポイント';
      const request = axios.create({});
      request.get(url, headers)
        .then(function(response) {
          console.dir("結果：" + response);
        });
    }
ユーザー情報表示

せっかくなので先ほど保存した氏名を画面に表示できるようにします。
index.js
    // ログイン認証完了後画面表示処理
    function showView() {
      //名前表示
      $("#yourName").text(localStorage.name);
    }
Webページ読み込み時に起動する関数

JQueryの関数を使用して、ページ読み込み時に先ほどの関数を呼び出すように設定しましょう。
※ページ読み込み時にこれらの関数を呼ぶことで、正しい認証ユーザーか制御することができます。
index.js
    //初期処理(ページ読み込み時にロードされる)
    $(function() {
      console.log("Start");

      // 認証チェック
      console.log("Start:checkSession");
      checkSession();

      //ログイン後のUI表示処理
      //※ログイン成功時にのみ行いたいページ表示などを本関数で実装すると便利です。
      console.log("Start:showView");
      showView();

      //APIGatewayにリクエスト
      console.log("requestGateway");
      requestGateway();
    });
HTMLの作成

シンプルでいいです。
とりあえずテンプレ的な内容です。
index.html
<!DOCTYPE html>
<html lang="ja">

<head>
  <meta charset="utf-8" />
  <title>Sample Cognito</title>

  <script src="https://unpkg.com/axios/dist/axios.min.js" defer></script>
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
  <script src="S3のURL/index.js"></script>
</head>

<body>
   <h2>ようこそ<span id="yourName"></span></h2>
</body>

</html>
S3の設定

先ほど作ったhtml・JSファイルを公開バケットにアップロードします。
内容がかぶるので設定はこちらを参考に進めてください。

微修正

一通りのリソースの準備が整いましたので、微修正を行います。

Cognitoユーザープールの修正

CognitoのコールバックURLをS3のindex.htmlのURLに修正します。
Cognito > ユーザープール > 作成したユーザープール > アプリクライアントの設定からコールバックURLの内容を変更しましょう。

index.htmlの修正

読み込むJSファイルの格納先と認証エラー時に遷移するログインページのURLの内容を書き換えましょう。

実行

以下のログインURLからアクセスし、ログイン後のページで登録した氏名が表示できれば成功です！
ログインURL
https://{ドメイン名}.auth.{リージョン名}.amazoncognito.com/login?response_type=token&client_id={クライアントID}&redirect_uri={s3のindex.htmlのURL}
注意点(エラーが起きた場合)

私が少しハマった内容を残しておきます。。。

・各トークンは有効期限が1時間に設定されています。
有効期限切れのトークンを使用した場合は、認証エラーになりますので再ログインしましょう。
・APIGatewayの呼び出しに失敗する場合、大抵はデプロイ忘れです。
APIGatewayの設定が少しでも漏れていると、ブラウザ上ではCROSのエラーと表示されます。
騙されずに設定を見直し、再デプロイを行いましょう。
・APIGatewayのテストでは成功し、webからの呼び出しに失敗する場合、
エンドポイントの指定、ヘッダー情報の指定があっているか見直しましょう。

まとめ

かなり長い記事になってしまいましたが、概要から作成まで説明しました。
Cognitoは様々な記事があったのですが、図解している記事があまりなかったため、私は苦労しました。
この記事をベースにしていただければ、あとはやりたいことに特化した記事を参考に素晴らしいCognitoライフが過ごせると思います!

用語	説明	標準化(RFC)
認証	相手の身元を明らかにすること →ユーザーの認証の仕組み	OpenID Connect 1.0
認可	相手に適切な権限を付与すること →認証したユーザーに対するデータアクセス制御の仕組み	OAuth 2.0

用語	説明
IDトークン	OpenIdにより規定されたユーザー情報ヘッダー・ペイロード・署名で構成されており、ログインユーザーのクレーム(メールアドレスなど)が含まれる
アクセストークン	OAuthにより規定されたアクセストークン通常このトークンを使用して認可の処理を行う
更新トークン	各トークンには有効期限が存在する。(長くて1時間とか) そのため、本トークンを使用して、新規トークンの取得を行う(再びユーザー認証を行わなくても、本トークンを用いることで、新規トークンの発行が行える)

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T16:59:53+09:00

AngularプロジェクトとAWS Lambdaプロジェクトをいっぺんにビルド＆デプロイしたい

はじめに

これは頭の中を整理するための試行錯誤的なメモです。
ちゃんとしたオチまでたどり着くかは不明です。
ブラウザバックするなら今のうちです。

もし先に進まれる方は、固有名そのままのところは、薄目で見てやってください。

達成したいこと

2つのプロジェクトがあります。

Angularでできたフロントエンド → S3にアップロードしています。

AWS Lambdaで動かすバックエンド

2つのプロジェクトをいっぺんにビルドしてデプロイしたいです。

統合前の各プロジェクトの構成

各プロジェクトのディレクトリ構成と、ビルド＆デプロイ方法はこのようになっています。

ディレクトリ構成

Angular
.
├── angular.json
├── browserslist
├── dist/              # ビルド結果はここ
├── e2e/
├── karma.conf.js
├── node_modules/
├── package-lock.json
├── package.json
├── src/
│   ├── app/
│   ├── assets/
│   ├── environments/
│   ├── favicon.ico
│   ├── index.html
│   ├── main.ts
│   ├── polyfills.ts
│   ├── styles.scss
│   └── test.ts
├── tsconfig.app.json
├── tsconfig.json
├── tsconfig.spec.json
└── tslint.json
AWS Lambda

TypeScriptを使っています。
.
├── .aws-sam/
│   └── build/  # ビルド結果はここ。CloudFormationのテンプレートも作成される
├── coverage/
├── event.json
├── karma.conf.js
├── node_modules/
├── package-lock.json
├── package.json
├── src/
│   └── google-suggest-proxy/  # プログラムはここ 
├── template.yaml              # CloudFormationテンプレートのテンプレート
├── tsconfig.app.json
├── tsconfig.json
├── tsconfig.spec.json
└── webpack.config.js
ビルド＆デプロイ方法

Angular

ビルドはngコマンドを使います。
ng build --prod
デプロイはawsコマンドを使います。S3へアップロードしています。
aws s3 sync dist/hokanchan s3://hokanchan/
AWS Lambda

ビルドはwebpackです。
./node_modules/.bin/webpack-cli
デプロイはsamコマンドを使います。パッケージングと実際のデプロイの2段階です。
sam package --template-file ./aws-sam/build/template.yml --s3-bucket ラムダ置き場 --output-template-file /tmp/packaged.yml
sam deploy --template-file /tmp/packages.yml --stack-name hokanchan --capabilities CAPABILITY_IAM
まずビルドについて

いっぺんにビルドしたいので、2つのプロジェクトが一緒のディレクトリに入っていると嬉しいような気がします。
（難しいこと考えないで、シェルスクリプトかMakefileでまとめたほうが簡単かもしれないけど、あえてやります）。

悩みどころ

各プロジェクトのディレクトリ構成でコンフリクトしているものがあります。

srcディレクトリ

tsconfig.json

tsconfig.app.json

tsconfig.spec.json

karma.conf.js

これらをどう統合、あるいは分けて使えばよいか。。。

解決案

方針

こんなふうに考えました。

設定ファイルを統合するのはまたにして、まずは分けた状態でまとめよう。
ngコマンドの設定に手を出すと道のりが長そうなので、AWS LambdaをAngular側に寄せよう。
Angularはgenerate applicationしてprojectsディレクトリへ移そう。

考えたディレクトリ構成
.
├── .aws-sam/          # AWS Lambdaビルド結果
├── dist/              # Angularビルド結果
├── prjects/           
│   ├── frontend-hokanchan/    # Angularのもの
│   │   ├── src/               # Angularのプログラムソース
│   │   ├── karma.conf.json
│   │   ├── tsconfig.app.json
│   │   └── tsconfig.spec.json
│   └── backend-google-suggest-proxy/  # AWS Lambdaのもの 
│   │   ├── src/                       # AWS Lambdaのプログラムソース
│   │   ├── karma.conf.json
│   │   ├── tsconfig.app.json
│   │   └── tsconfig.spec.json
├── template.yaml              # モトイキ
├── tsconfig.json              # Angular用
├── tsconfig.sam.json          # AWS Lambda用
└── webpack.config.js          # モトイキ
この構成に合わせて、webpack.config.js angular.js tsconfig.*.json karma.conf.json を書き換えました。

期待通りにビルドやテストができるようになりました。

さてデプロイについて

ビルドができるようになったので、次はデプロイです。

悩みどころ

Lambdaへのデプロイと、S3への静的コンテンツアップロードを同時にやりたい

Lambdaへのデプロイは2段階

1段階目は、パッケージングとS3へのアップロード

2段階目は、実際にLambdaへのデプロイ

2段階目と同時に、静的コンテンツのアップロードはできる？

できそう？ → How to use CloudFormation to deploy Frontend Apps to S3 and Serverless Application Repository

いったんLambdaにアップロードしたファイルを、あとからS3に入れるっぽい。なかなかトリッキー

他に、S3へアップロードするLambdaを作って使うという手もあるらしい。これもまた搦め手のような。

SAM(Serveless-applicatin-model)でLambdaを作ると、API Gatewayも作られる

このAPI Gatewayに独自ドメインを割り当てたい

このAPI GatewayからS3に入れた静的コンテンツも配信させたい

解決（あるいは諦め）案

CloundFormationによる静的コンテンツのアップロードは諦める。

静的コンテンツをアップロードする素直なやり方はなさそう。

静的コンテンツとLambdaは別々にデプロイする。

API Gatewayのルートに、S3 WebサイトをGETするメソッドを追加する。

CloudFormationテンプレートに追加するリソース

samコマンドで生成したテンプレートには、あらかじめ AWS::Serverless::Function が入っています。

これ以外に追加するリソースです。

S3バケットとポリシー

公開WebサイトとしてS3バケットを作ります。
AWSのテンプレートスニペットからコピペして作りました。

S3バケット
  StaticContentBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref bucketName
      AccessControl: PublicRead
      WebsiteConfiguration:
        IndexDocument: index.html
        ErrorDocument: error.html
ポリシー
  BucketPolicy:
    Type: AWS::S3::BucketPolicy
    DependsOn: StaticContentBucket
    Properties:
      Bucket: !Ref StaticContentBucket
      PolicyDocument:
        Id: StaticContentBucketPolicy
        Version: '2012-10-17'
        Statement:
          - Sid: PublicReadForGetBucketObjects
            Effect: Allow
            Principal: '*'
            Action: 's3:GetObject'
            Resource: !Join
              - ''
              - - 'arn:aws:s3:::'
                - !Ref StaticContentBucket
                - /*
API Gatewayドメイン名とマッピング

独自ドメイン名を使えるようにします。

ドメイン名
    Type: AWS::ApiGateway::DomainName
    Properties:
      CertificateArn: !Ref certificateArn
      DomainName: !Ref domainName
      EndpointConfiguration:
        - REGIONAL
マッピング

ServerlessRestSApiは、AWS::Serverless::Functionの中で作成されるAPI Gatewayの論理名です。
  DomainNameMapping:
    DependsOn:
      - RestApi
      - CustomDomainName
    Type: AWS::ApiGateway::BasePathMapping
    Properties:
      DomainName: !Ref CustomDomainName
      RestApiId: !Ref ServerlessRestApi
      BasePath: ''
静的コンテンツのリソースとメソッド

API Gatewayのルート直下にHTTP Proxyを設定してS3バケットへ向けます。

API Gatewayリソース
  StaticContentResource:
    Type: AWS::ApiGateway::Resource
    Properties:
      ParentId: !GetAtt RestApi.RootResourceId
      RestApiId: !Ref ServerlessRestApi
      PathPart: '{path}'
API Gatewayメソッド
  StaticContentResourceMethod:
    DependsOn: StaticContentResource
    Type: AWS::ApiGateway::Method
    Properties:
      HttpMethod: GET
      ResourceId: !Ref StaticContentResource
      RestApiId: RestApi
      AuthorizationType: NONE
      RequestParameters:
        method.request.path.path: true
      Integration:
        IntegrationHttpMethod: GET
        Type: HTTP_PROXY
        Uri: !Join
          - ''
          - - !GetAtt StaticContentBucket.WebsiteURL
            - '/{path}'
        PassthroughBehavior: WHEN_NO_MATCH
        IntegrationResponses:
          - StatusCode: 200
        CacheKeyParameters:
          - 'method.request.path.path'
        RequestParameters:
          integration.request.path.path: 'method.request.path.path'
コマンドをpackage.jsonにまとめる

よく使ったコマンドはpackage.jsonにまとめました。
これで忘れても安心。

AWS S3へビルドしたAngularをアップロード
    "s3:sync": "aws s3 sync dist/frontend-hokanchan  s3://hokanchan.uart.dev",
AWS S3コンテナの中身を削除
    "s3:delete": "aws s3 rm s3://hokanchan.uart.dev --recursive",
Lambdaをビルド
    "sam:build": "webpack-cli",
Lambdaをテスト
    "sam:test": "karma start projects/backend-google-suggest-proxy/karma.conf.js",
Lambdaをパッケージング
    "sam:package": "npm run sam:build;sam package --template-file .aws-sam/build/template.yaml --s3-bucket lambdastash-ap1 --output-template-file /tmp/packaged.yaml",
Lambda等をデプロイ
    "sam:deploy": "npm run sam:package;sam deploy --template-file /tmp/packaged.yaml --stack-name hokanchan --capabilities CAPABILITY_IAM",
Cloudformationの失敗内容を出力
    "sam:failed": "aws cloudformation describe-stack-events --stack-name hokanchan --query 'StackEvents[?ResourceStatus==`CREATE_FAILED`]'",
できあがったAPI GatewayのURLを出力
    "sam:apiurl": "aws cloudformation describe-stacks --stack-name hokanchan --query 'Stacks[].Outputs[?OutputKey==`GoogleSuggestProxyApi`]' --output table",
Cloudformationスタックを削除
    "sam:undeploy": "aws cloudformation delete-stack --stack-name hokanchan;aws cloudformation wait stack-delete-complete --stack-name hokanchan"
参考リンク

aws cloudformation package コマンドで自動的にS3にアップロードしてくれるリソース一覧

How to use CloudFormation to deploy Frontend Apps to S3 and Serverless Application Repository

AWS SAMドキュメント

リソース種別

生成されるリソース

AWS Cloudformationリソースリファレンス

AWS::S3::Bucket

AWS::S3::BucketPolicy

AWS::ApiGateway::Resource

AWS::ApiGateway::Resource Integration

AWS::ApiGateway::Method

Setting up an Api Gateway Proxy Resource using Cloudformation

テンプレートスニペットカスタムドメインを使用した静的ウェブサイトの作成

もしかしたらダメかも？

長々と書いてきましたが、成功していません。

AWS::Gateway::RestApiリソースを作成したら、API::Gateway::Deploymentリソースも作成しないと、実際に使えるようにはなりません。
API::Gateway::Deploymentは、AWS::Serverless::Functionの中で暗黙的に作成されます。
したがって、API::Serverless::Functionが作成された後にAWS::Gateway::ResourceやAWS::Gateway::Methodを追加しても使えません。

AWS::Serverless::*をやめて、すべて手書きするしかないかなー？

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T16:28:40+09:00

AWS ロードバランサー運用のポイント

はじめに

AWSのロードバランサーはマネージドサービスですが、AWSに任せっきりでいいの？という方向けに
運用する際に注意すべきこと、監視すべき項目をまとめました。

目次

1.cloudwatchで監視すべき項目
2.スパイクトラフィックがある場合の対応
3.トラブルシューティング

1.cloudwatchで監視すべき項目

特に見るべき項目をピックアップしています。

項目説明

HTTPCode_ELB_5XX LBが生成したHTTPステータスが5XXの数。インスタンスまで転送されずにエラーとなっているため、発生しているエラーを調査する必要があります。

SurgeQueueLength healthyなインスタンスへの転送がPending中のリクエスト数。キューの最大長は1024

SpillOverCount 前述のSurgeQueueがフルのためリクエスト転送に失敗したリクエスト数

2.スパイクトラフィックがある場合の対応

AWSのLBはトラフィック量に合わせて徐々にスケールします。
そのため、スパイク的なトラフィックが発生した場合(目安10倍のトラフィック)エラーとなります。
対策としてAWS-Supportへ暖気申請(Pre-warming)を行います。

3.トラブルシューティング

HTTP 503 Unavailableが発生する場合

healthyなインスタンスがあるか調査します。

HTTP 504 Gateway Timeoutが発生する場合

EC2のweb(Apache/Nginx等)でkeep-aliveを設定している場合は
LBのidle timeout > keep-aliveになっているかを確認します。

終わりに

間違い等ありましたらご指摘のほどよろしくお願い致します。

項目	説明
HTTPCode_ELB_5XX	LBが生成したHTTPステータスが5XXの数。インスタンスまで転送されずにエラーとなっているため、発生しているエラーを調査する必要があります。
SurgeQueueLength	healthyなインスタンスへの転送がPending中のリクエスト数。キューの最大長は1024
SpillOverCount	前述のSurgeQueueがフルのためリクエスト転送に失敗したリクエスト数

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T13:07:20+09:00

macOS: TimeMachine バックアップを AWS 上に保全する

将来、家に隕石が落ちてきた時の最後の砦として、自分の PC にある日々の運用データ一式をクラウド上に保全して枕を高くして寝たい。また、超強力な太陽嵐が地球上に降り注いでも、データの整合性は可能な限り担保したい。

そんな夢を見たのでどこまで実現可能かを考えてみた。思考実験以上、運用実験未満。

ゴール

AWS 上に macOS の TimeMachine 機能を使ってデータを保管したい。また、手元の Mac のディスクが壊れた時のリカバリー元としても使えるようにしたい。可能な限り高い信頼性を確保し、できるだけセキュアに。

要件

ネットワーク

通信経路をセキュアに保つこと

macOS の標準機能だけで VPN 接続を確立できること

データ

データは自分で暗号化・復号化できること

信頼性の高い（ビット反転等に強い）ディスク環境を構築すること

可能な限り高い冗長性を確保できる（コントロールできる）こと

バックアップだけでなく、リカバリモードで起動した Mac から OS の復元ができること

方針

特別な機器（ルータ等）を利用せず、ソフトウェアのみで実現する。

信頼性の高いツールを組み合わせて実現する。がんばりすぎない。

サーバは１インスタンスで済ませる。

ソリューション

検討した結果、ソリューションとして以下のソフトウェアを組み合わせることとした。

VPN 環境: Algo

Algo は、クラウドサービス上に IPSec を使った VPN インスタンスを簡単に構築できるツール。PC の設定ファイルも生成してくれるので便利。

OS は Ubuntu の最新版がインストールされる。

ファイルシステム: ZFS

みんな大好き ZFS には同一データの複数コピーを保持する機能がある。複数のコピーがあると、ビット反転（腐敗）などが起きた時にメンテナンスコマンドにより整合性を回復できる。

またソフトウェア的に RAID を組める機能を利用し、ディスクのエラーや操作ミス等もカバーする。

データ暗号化: LUKS によるディスク暗号化

ディスクの暗号化機能は ZFS にも搭載されているが、Linux 上での安定性や可用性を考えて今回はこちらとした。

ディスクデバイス: Amazon EBS

ディスク系のソリューションとなると EFS も候補に挙がるが、（AWS に任せず）自前で暗号化したいとなるとブロックデバイスである EBS 一択となる。ただし、コストパフォーマンスを高めるためにタイプは低速だが低コストの Cold HDD (sc1) を指定する。ネット越しのバックアップはネットワーク速度がボトルネックとなるのでディスク自体は低速でもまったく構わない。

また、必要に応じて EBS ボリュームのスナップショットを定期的に取得してもよいだろう（ただし費用はけっこうかかる）。

通信プロトコル: netatalk

TimeMachine は AFP プロトコルで動作するので netatalk サーバを稼働させる。なお現代では SMB (CIFS) でも可能なので samba を利用してもよさそうだ¹。

Algo のセットアップ

iptables の設定を追加

netatalk を通す設定を公式に追加する方法がわからないので、次のようなパッチを当ててごまかすこととした。
--- roles/vpn/templates/rules.v4.j2.orig    2019-02-23 12:38:36.000000000 +0900
+++ roles/vpn/templates/rules.v4.j2 2019-02-23 12:40:57.000000000 +0900
@@ -69,6 +69,11 @@
 # Accept DNS traffic to the local DNS resolver
 -A INPUT -d {{ local_service_ip }} -p udp --dport 53 -j ACCEPT

+# Netatalk
+-A INPUT -p tcp --dport 548 -m conntrack --ctstate NEW -j ACCEPT
+-A INPUT -p udp --dport 5353 -j ACCEPT
+
 # Drop traffic between VPN clients
 {% if BetweenClients_DROP %}
 {% set BetweenClientsPolicy = "DROP" %}
patch < iptables.patch
設定ファイルの書き換え

config.cfg を編集する。

Algo のセットアップは詳しい記事がネットにたくさんあるので省略。いくつかポイントだけ。

IAM 作成と権限設定

専用の IAM を作成しておくとよい。インストラクションにあるように、権限の欄に指定された JSON を記述すること。

Python

python2 系が必要。macOS のシステムに最初から入っているものを使えばよい。

ユーザリスト

デフォルトで３つ指定されているが１つあればいいので、適当に減らしたりリネームする。

インスタンスタイプ

デフォルトでは t2.micro が指定されているが、t2.nano で十分なので変更しておくとよい。

インスタンスの立ち上げ

実際に algo を実行しインスタンスを作成する。
./algo
無事に作成されたら ssh でログインする。
ssh -i configs/algo.pem ubuntu@xx.xx.xx.xx
sudo su -
自動作成された EC2 インスタンスの削除保護を有効にし、シャットダウン動作を「停止」に変更しておこう。

ネットワークとマシンの準備

最新版にアップグレードしておく。
apt-get update
apt-get upgrade -y
必要なライブラリを入れる。
apt install -y cryptsetup zfsutils-linux netatalk
ディスク領域の準備

方針

ZFS の機能を使って RAID を組む。

可能なら raidz2 オプションを採用し RAID6 を組みたいが、EBS (Cold HDD (sc1)) を４台も使うと最低でも $60/month がかかる。ディスク構成はあとから変更できるので、まずは２台で構築してみる。

ちなみにここでは EBS 自体の暗号化機能は使用しない。独自に暗号化する。

セットアップ

ディスク設計

今回は EBS ボリュームごとに ZFS のストレージプールを作成し、それらを raid として束ねることとした。

EBS ボリュームを用意する

EBS は EC2 インスタンスと同じアベイラビリティゾーンに作成すること。

通常なら /dev/sdf にアタッチされ、インスタンスからは /dev/xvdf として見えるはずだ。
２つめ以降は /dev/xvdg, /dev/xvdh ... などと振られる。
ls -lF /dev/xvd[f,g,h,i]
暗号化ボリュームをセットアップする

次のようにして暗号化ボリュームをセットアップする。もちろん既存のファイルは全消去されるので注意すること。パラノイアなひとはすべて違うパスフレーズにするのも良いかもしれない。
cryptsetup --verbose --verify-passphrase luksFormat --cipher aes-cbc-essiv:sha256 --key-size 256 /dev/xvdf
cryptsetup --verbose --verify-passphrase luksFormat --cipher aes-cbc-essiv:sha256 --key-size 256 /dev/xvdg
...
それぞれ tmdisk1, tmdisk2 ... としてマウントする（名前は任意）。
cryptsetup luksOpen /dev/xvdf tmdisk1
cryptsetup luksOpen /dev/xvdg tmdisk2
...
ZFS プールに登録する

ここでは２台なので mirror を指定する。３台なら raidz1、４台なら raidz2 ... というように設定できる。
zpool create -o ashift=12 -O normalization=formD tmdisk mirror \
    /dev/mapper/tmdisk1 \
    /dev/mapper/tmdisk2
状態を確認する。
zpool list
zpool status
NAME     SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tmdisk  1008M   408K  1008M         -     0%     0%  1.00x  ONLINE  -
  pool: tmdisk
 state: ONLINE
  scan: none requested
config:

    NAME         STATE     READ WRITE CKSUM
    tmdisk       ONLINE       0     0     0
      mirror-0   ONLINE       0     0     0
        tmdisk1  ONLINE       0     0     0
        tmdisk2  ONLINE       0     0     0
ファイルシステムオプション

いくつか有用なオプションを付けておく。
zfs set compression=on tmdisk    # ディスク圧縮
zfs set copies=2 tmdisk    # 複数のコピーを保持
ここでは copies=2 を設定している。もちろんそれだけ容量（と書き込み時間）を消費するので注意すること。ちなみに指定できる最大値は 3 となっている。

以下はお好みで。
zfs set atime=off tmdisk    # noatime 相当（ディスクのアクセス速度を上げたい）
zfs set relatime=on tmdisk    # relatime 相当（バランスがよさそうなので）
zfs set exec=off tmdisk    # noexec 相当（バイナリの実行を禁止。安全性を上げたい）
現在のオプション値を確認することもできる。
zfs get all tmdisk
書き込みテスト

ここでは 1GB のディスクで copies=2 を指定しているので、圧縮が効かない場合にはせいぜい 500MB 程度しか書き込めないはずである。確かめる。
head -c 600m /dev/urandom > /tmdisk/data
head: error writing 'standard output': No space left on device
ls -lh /tmdisk/data
rm -f /tmdisk/data
これで secure かつ robust な /tmdisk を準備できた。

ユーザ

netatalk へ接続するための Unix 実ユーザアカウントを適当に作成する。ここでは tmuser とした。
useradd -d /home/tmuser -g backup -m -s /usr/sbin/nologin -u 340 tmuser
passwd tmuser    # これが macOS からアクセスするときのパスワードとなる
ディスクの所有権を調整しておく。
chown -R tmuser:backup /tmdisk
chmod 750 /tmdisk
netatalk

/tmdisk ボリュームを netatalk に登録する。TMDisk の名前は任意。macOS 上で見えるディスク名となる。
vi /etc/netatalk/AppleVolumes.default
/tmdisk "TMDisk" allow:tmuser cnidscheme:dbd options:usedots,upriv,tm
もしユーザ名を変えた場合は tmuser の部分を変更するのを忘れないように。また、デフォルトとして有効になっている ~/ の行が必要なければオフにしてもよいだろう。
vi /etc/netatalk/afpd.conf
# for TimeMachine
- -tcp -noddp -uamlist uams_dhx.so,uams_dhx2_passwd.so -nosavepassword
もし afpd のログを出したければ次も追記するとよい。
- -setuplog "default log_debug /var/log/afpd.log"
起動する。
systemctl restart netatalk
lsof -i:548
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
afpd    7239 root    4u  IPv4  39717      0t0  TCP *:afpovertcp (LISTEN)
接続の準備

hosts ファイル

利便性向上のため、手元の macOS の /etc/hosts に例えば次のように書いておくとよい。
sudo vi /etc/hosts
10.19.49.1      tmdisk-aws.local
この IP アドレスは Algo の roles/vpn/defaults/main.yml にハードコードされている。

実行する

VPN

まず VPN に接続する。「ネットワーク」環境設定に Algo VPN xx.xx.xx.xx IKEv2 が追加されているはずなのでこれを選び、「接続」をクリックする。

正しく接続されているかどうか確認する。
ping tmdisk-aws.local
マウントする

Finder の「サーバへ接続 (cmd+K)」へアドレスを入れて接続する。

afp://tmuser@tmdisk-aws.local/TMDisk

試しになにかファイルを書き込んでみると次のように反映されるはずだ。
ls -l /tmdisk/
drwxr-x--- 3 root   backup     3 Sep 28 08:02 'Network Trash Folder'
drwxr-x--- 3 root   backup     3 Sep 28 08:02 'Temporary Items'
-rw------- 1 tmuser backup 59601 Sep  5 05:15  test.jpg
あとは通常通り、TimeMachine 環境設定を開いて TMDisk をバックアップ先に指定するだけだ。

運用

ディスクの冗長化

費用に余裕があれば、数 TB の EBS ボリュームを４つ用意し ZFS の raidz2 を指定して RAID6 相当を組むと万全だろう。

ただ、（物理ディスクとは違って）EC2 上の仮想ディスクが壊れる可能性は相対的にかなり低いと思われるので、ヒューマンエラーを加味した落としどころとしては、３台で raidz1 の RAID5 構成で十分だとは思う。

定期的なディスクのチェック

通常は /etc/cron.d/zfsutils-linux で定期的に zpool scrub コマンドが実行され、不整合は自動修復されるはずだ。デフォルトで月に１度だが、もう少し頻度を上げてもいいかもしれない。

EBS スナップショットの定期作成

費用に余裕があれば、１日それぞれひとつのスナップショットを撮っておくとさらに安心だろう。ただし、かなり費用がかかる富豪的手法ではある。

仮に４つの 1TB ディスクを使用し、ディスクの使用量を各 50% とし、１日にひとつ、５つのスナップショットを保持した場合、現状では $500/月程度かかるだろう。

OS 環境

細かいこといろいろ。

ホスト名
hostnamectl set-hostname tmdisk1.example.com
タイムゾーン

Algo デフォルトでは UTC なので JST にしておく。
timedatectl set-timezone Asia/Tokyo
時刻同期

ntp を起動しておく。
apt-get install -y chrony
IP 制限

可能なら、EC2 (VPC) のセキュリティグループで自宅/自社からのアクセスのみに制限しておこう。
ssh は hosts.allow へ記述する方法もある。

念のため netatalk も hosts.allow で制限したいなら次のように書ける。
afpd : 10.19.48.1 : allow
afpd : ALL : deny
運用サイクル

一度セットアップすれば次のようなフローになる。

OS 起動時

暗号化ディスクをマウントする。複数のディスクを使う場合は繰り返す。
cryptsetup luksOpen /dev/xvdf tmdisk1
cryptsetup luksOpen /dev/xvdg tmdisk2
...
ZFS 領域をマウントする。
zpool import tmdisk
zpool list
もしマウントされていなかったら手動で。
zfs mount tmdisk
OS シャットダウン時

ふつうにマシンを shutdown/reboot しても問題ない。あえて手順を踏むなら次のようになる。

ZFS 領域をアンマウントする。
zfs unmount tmdisk
zpool export tmdisk
test -e /tmdisk && rmdir /tmdisk    # 次回マウント時に失敗するので消しておく
ディスクの暗号化を解除する。
cryptsetup luksClose /dev/mapper/tmdisk1
cryptsetup luksClose /dev/mapper/tmdisk2
...
課題

実効容量を正しく認識してくれるか

ZFS の圧縮や複数コピーオプションを有効にしている関係上、実効領域が伸び縮みして見えている実ディスク容量と合わない。この差違を TimeMachine が正しく認識して消し込みを行ってくれるか不明。心配なら次のような対処法があり得るか。

netatalk の設定で TimeMachine 領域の容量を明示的に指定する (volsizelimit:512000)

ZFS 上で quota をかける (zfs set quota=500G tmdisk)

可能であれば、使用したい容量の 2.5 倍以上を確保しておくと安心かもしれない。

ファイル名の大文字小文字の区別問題

macOS 自体は case-insensitive なので、ZFS 上もそれに合わせておくほうが安全かもしれない。また、SMB を使う際にはまた話が変わってくるようだ。
zfs set casesensitivity=caseinsensitive tmdisk
ファイル名の UTF8 正規化問題

macOS のファイル名正規化は NFD なので、ZFS create 時に -O normalization=formD などと指定できるようだ。macOS に準拠させたいならどうすべきか。あるいは netatalk が差違を吸収してくれると期待してよいものか。

クラウドからの OS リカバリは成功するのか

理論上は成功しそうだが、試せていない。実効的な速度が出るものなのかも不明。

試した方はレポートをお待ちしています。

回線速度

うちの ADSL 12M という化石のような回線だと、計算上、初回のフルバックアップに４０日ほどかかるのが難点といえば難点だ。少なくとも初回実行時は高速かつ従量課金されないネットワーク環境を用意したい。

発展

複数のサーバで別の TimeMachine バックアップを運用する

マルチ AZ 化やマルチリージョン化を試すと冗長性が高まってより安心か。

他のクラウドサービス上でも構築する

もし Google Cloud でも同等のシステムが構築できれば、マルチクラウド化して一段レベルの高い冗長性を確保できそうだ。

コールドストレージとして

定期バックアップするときだけサーバを立ち上げればセキュリティ上も安心な上に費用も安く上がる。例えば週に一度だけ labmda 等で自動でインスタンスが立ち上がるようにしておく手もありそうだが、結局 cryptsetup へパスフレーズを渡さねばならない問題は残る。

検討事項

どの段階でデータを暗号化するか

今回は LUKS を用いたが、いくつかの方針が考えられる。

TimeMachine に暗号化させる

そもそも TimeMachine に「バックアップを暗号化」するオプションがあるのでこれを使用する。ただし、サーバ上で実ファイルが見られなくなってしまうのが難点だが、お手軽確実ではある。

また、ディスクをマウントする時にパスフレーズを打たなくて済むので、サーバの自動起動・シャットダウンをプログラマブルにコントロールできるのは魅力だ。

LUKS で暗号化する

今回説明した方法。サーバ上から実ファイルが参照できるので、便利な場面は多いだろう。反面、サーバを稼働中にクラックされた場合の秘匿性に劣る。将来的に（プロプライエタリ製品である） macOS が使用できない環境を想定するのであれば、妥当なソリューションだと言えそうだ。

複数の手段で暗号化する

基本的に暗号の重ねがけは速度的にもセキュリティ強度的にも悪手ではある。個人的には上記のうちどれかを単体で採用すべきだと考えている。

まとめ

IPSec による VPN 接続と netatalk、それに ZFS の機能をフルに生かしたディスク構成により、クラウド事業者にメモリを直接覗かれない限り安全に TimeMachine バックアップを可逆的にクラウド上に置くことができた（理論上は）。

Apple はむしろ SMB へスイッチしたがっているようだ。 ↩

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T12:48:01+09:00

2019.7 AWS ソリューションアーキテクト 20日で合格やったことまとめ

はじめに

はじめまして。
普段はネットワークの運用などを担当しているtotonobeです。

2019年7月にAWSソリューションアーキテクトアソシエイト（以下SAA）に合格しました。
約20日で合格にこぎ着けることが出来たので、これから受験を検討している方向けに
情報を共有したいと思います。

ここにはスマートな手法は書いてありません。量を頭にブチ込むやり方です

私がやったことをまとめると
・AWS SAAという試験について情報収集する
・書籍を通しで1周する
・問題集をひたすらやる
・実際にAWSを触る
・試験範囲の各種BlackBeltを読む
・書籍をもう1周して細かいところをおさえる。自信がない問題の分野について調べる

教材やツール

書籍

 AWS認定資格試験テキスト AWS認定ソリューションアーキテクト-アソシエイト
・AWS SAAの試験範囲について網羅的に書いてあり、また読み進めやすい書籍でオススメです。

徹底攻略 AWS認定ソリューションアーキテクト – アソシエイト教科書徹底攻略シリーズ
・問題が多めに記載されているので、上記の書籍で学んだことを復習するのにも良いです。

Amazon Web Services 基礎からのネットワーク&サーバー構築改訂版
・AWSを実際に動かしてAWSの代表的なサービスについて学ぶことができます。これは余裕があれば。

Web
・AWS WEB問題集で勉強しよう（有料）
700問以上の問題と解説があり、PCやスマホどちらからでも利用することができるサイトです。
解説をコピーすることができないので、やや不便なのですが問題の量はピカイチです。

ツール
・Scrapbox（無料）
利点
・無料
・PCやスマホで使えて、ネットさえあればどこでも使用できる
・とにかく素早くメモすることができる。文字や画像の貼り付けが楽(ping-tで活躍）
・コードブロックを使用できる

スケジュール

6月28日 AWS SAAについて情報収集　書籍購入読み始める
6月29日 AWS WEB問題集で勉強しよう契約 https://aws.koiwaclub.com/exam/
6月30日書籍1周
7月9日 WEB問題集 1周試験範囲のBlackbeltOnlineセミナーを見始める
7月13日 WEB問題集 2周
7月15日合格

私の試験勉強方法

・AWS SAAという試験について情報収集する。スケジュールを立てる。（1日〜2日）
情報収集は重要です。試験で何が出題されるのか、合格者はどんな対策していたのか、実際にはどんな問題があったかなど、情報をまとめます。だいたい何をいつまでにやるかざっくりと計画を立てます。

・書籍を通しで1周する（3日）
最初分からないところが多いですし、とても眠くなりますが、1周することで試験範囲の全体像がつかめてきます。サービスがどのように連携するのか、使用されることが多いのか、ざっくりでいいので目に入れます。

・問題集をひたすらやる
書籍同様、最初はとても眠くなるのですが、量をこなしているうちに、これはこういうことだったなと分かるようになってきます。めげそうになりますが頑張る。
　
・実際にAWSを触る（1日〜2日）
問題集と平行して、実際にAWSアカウントを取得してAWSのサービスに触ります。VPC、EC2やS3などを起動してみて、実際にどんな感じなのか試してみると問題集の理解も進みます。

・試験範囲の各種BlackBeltを読む
書籍や問題集には載っていない情報もあるので、こちらも一通り目を通してください。AWS開いたオンラインセミナーをまとめた資料が無料で公開されています。動画版だと1時間ぐらいあり、だいたいはPDFでスライドがまとめられています。
　　
・書籍をもう1周して細かいところをおさえる。自信がない問題の分野について調べ
問題集をやったあとに書籍を見ると、あやふやに覚えていたものがまとまり理解が進みます。

今後

直近ではLPIC 102を試験勉強しています。合格したらまた記事にまとめたいと思います。
AWS システムアドミニストレータアソシエイトもそのうちまとめます。

参考資料

ブログ記事
[2019/2版]AWSソリューションアーキテクト-アソシエイト試験に20日で合格する方法

15日間勉強してAWS ソリューションアーキテクトアソシエイト試験に合格した

AWS公式
AWS Well-Architected フレームワーク 2018 年 6 月

AWS 認定ソリューションアーキテクト - アソシエイト SAA-C01 試験ガイド

AWS サービス別資料（BlackBeltはこちら）

記事作成時間 90分

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T12:28:01+09:00

おめでとうございます。これであなたもAWS ソリューションアーキテクトアソシエイトに合格です。〜主要サービス編〜

はじめに

先日、AWSソリューションアーキテクトアソシエイトに合格しました。
試験勉強の際にこれ重要だな、これ知らなかったなと思ったものを纏めていたので共有します！！
少しでも皆様の合格のお役に立てれば。

量が少し多かったため、主要サービス編とその他サービス編で2回に分けて公開します。

(合格ギリギリでしたが。。w)

ちなみに使った教材は？

①徹底攻略 AWS認定ソリューションアーキテクト – アソシエイト教科書徹底攻略シリーズ
→黒本。主要なサービスの概要が載っており、初めてAWSを勉強する方にオススメ！

②これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（初心者向け21時間完全コース）
→Udemyの講座。ハンズオンが多く、①を勉強した後にやると効率良いです。
　テストも3回分付いており、良質な問題が多い！！(テストだけやるために購入する価値あり)
　セール中だと1400円ほどで購入できます。
　アプリからも講座を見れるので、通勤中にもできるので非常にオススメ！

③合格対策 AWS認定ソリューションアーキテクト－アソシエイト
→青白本。個人的に①の下⚪︎互換。(初期に出版されたのでやむなしか。。)
　とりあえず１周はしましたが、あとはほとんど見てないです。

ということで①と②だけで合格できます！BlackBeltや他の教材は使っていません。
また②にテストが付いているので、公式模擬試験も受けてないです。
最速で試験合格が目標なら、①と②のテストだけやれば個人的にいけます！

それでは、本題に入っていきます！

アジェンダ

全般

EC2

VPC

ELB

Route53

CloudFront

Lambda

S3

RDS

DynamoDB

1.全般

・AWS well-architectured フレームワーク
①運用上の優秀性
②セキュリティ
③信頼性
④パフォーマンス効率
⑤コスト最適化

・グローバルサービス
IAM, CloudFront, Route53 など

・リージョンサービス
VPC, DynamoDB, Lambda, S3, SQS など

・アベイラビリティーゾーンサービス
VPCのサブネット, EC2, RDS, EBS, ELB, Redshift など

2.EC2(Elastic Compute Cloud)

安全でサイズ変更可能なコンピューティング性能をクラウド内で提供するウェブサービス
公式ページ_EC2

memo

オンデマンドインスタンスはインスタンスファミリー、OS、テナンシー、支払いオプションの変更ができない。リザーブドは可能。

インスタンスストアは、EC2の一時的なデータが保持される。インスタンスが停止または終了した場合、インスタンスストアボリューム上のデータはすべて失われるため。
EBSは他の物理ハードドライブと同じように使用可能。インスタンスが停止または終了した場合でも、データは失われない。

タグを使用すると、目的、所有者、環境など、さまざまな方法でAWSリソースを分類可能。
EC2インスタンスの開発用タグで分類分けを行い、そのタグが設定されているEC2インスタンスのみに操作できるようにIAMポリシーを設定することで、本番用への削除権限を与えない設定が可能。

AWSでは初期の制限によって、リージョンあたり20インスタンスという制限設定がある。
Auto Scalingで立ち上げが失敗した際は限度引き上げ申請を行い、承認されたら失敗した要求を再試行を行うことで立ち上げ可能。

EC2インスタンスを立ち上げたばかりのときにステータス情報がデータ不足の場合は、ボリューム上でチェックがまだ進行中である可能性がある。

起動設定においてソフトウェアがインストールされた最新の状態のAMIを作成するか、Bashスクリプトでソフトウェアのインストールを仕込んでおくことで自動で同じEC２インスタンスを起動できるようになる。

EBSのバックアップを取得することで、S3にデータが保存されるためEBSを復元することは可能だが、EC2インスタンスの設定自体は回復することができない。

Elastic IPは、起動しているEC2インスタンスにアタッチされている場合には料金発生なし。

プレイスメントグループとは、単一のアベイラビリティーゾーン内のEC2インスタンスを論理的にグルーピングしたもの。より高速に処理可能。

EC2インスタンスはステートレスなアプリ開発には向いてない。
ステートレスアプリケーションとは以前のシステム上のやり取りについての状態情報が不要なため、セッション情報が格納されていないアプリケーションのこと。
ステートレスな処理をサービス化するならば、Lambdaを利用する方がコスト最適できる可能性が高い。

3つのボリュームすべてのスナップショットを取るためにには、EC2インスタンスを停止して静止点を設けた上で、各EC2インスタンスのスナップショットを個別に作成する必要がある。

Dedicated Host:ユーザー専用のホスト。

スティッキーセッション:セッション中に同じユーザーから来たリクエストを全て同じEC2インスタンスに送信する機能。

3.VPC(Virtual Private Cloud)

AWS クラウドの論理的に分離されたセクションをプロビジョニングし、お客様が定義した仮想ネットワーク内の AWS リソースを起動することができます。自分の IP アドレス範囲の選択、サブネットの作成、ルートテーブルやネットワークゲートウェイの設定など、仮想ネットワーキング環境を完全に制御できます。
公式ページ_VPC

memo

ルートテーブル内のデフォルトゲートウェイ(0.0.0.0/0)へのルーティングに、インターネットゲートウェイを指定するとパブリックサブネット。
指定していないサブネットがプライベートサブネット。

NATゲートウェイをパブリックサブネットに配置し経由するとプライベートサブネットからインターネットへ接続可能。

サブネットはAZに跨って作成不可。

VPC内のすべてのサブネット間の通信はデフォルトのルーティングルールで許可されており、変更削除は不可

VPC内のCIDRは/16から/28までが利用可能。

VPCのDNS hostnamesオプションがYesに設定されていないと、サブネットで起動されたインスタンスはDNS名を取得できない。VPC構成の設定を変更することで解決可能。

VPゲートウェイ: direct connect やインターネットVPN接続するためのゲートウェイ。オンプレミス環境と接続するVPCにアタッチ。

VPCピアリング接続: VPC同士はインターネットを経由せずに、プライベートネットワーク内で直接通信が可能。これ無しだと、VPC同士は直接通信は行えない。異なるAWSアカウント間でも可能だが、ネットワークアドレスが一致または重複する場合は接続不可。接続する２つのVPCが同一リージョンに存在する必要がある。

VPCエンドポイント: プライベートサブネットからS3やDynamoDBへアクセスする際、インターネットを経由せずにプライベート接続可能。ルートテーブルでアクセスするIPアドレスをVPCエンドポイントへ向けるように設定する。

セキュリティグループ: インスタンス単位に適用可能なファイアウォール機能。デフォルトはインバウンドは全て拒否。アウトバウンドは全て許可。
ステートフルなので、戻りのトラフィックを考慮しなくてよい。設定後すぐルール適用される。
指定は許可のみ、拒否の指定不可。インバウンドは必要最低限、アウトバウンドは基本全て許可する。

ネットワークACL: サブネット単位に適用可能なファイアウォール機能。デフォルトはイン・アウトバウンド共に全て許可。ステートレスなので、インだけでなくアウトバウンドのトラフィックも明示的に許可設定する。

4.ELB(Elastic Load Balancing)

アプリケーションへのトラフィックを複数のターゲット (Amazon EC2 インスタンス、コンテナ、IP アドレス、Lambda 関数など) に自動的に分散します。
Elastic Load Balancing は、変動するアプリケーショントラフィックの負荷を、1 つのアベイラビリティーゾーンまたは複数のアベイラビリティーゾーンで処理できます。
公式ページ_ELB

memo

【重要な特徴】
高可用性 (→複数のAZへ分散自動スケーリング)
セキュリティ機能(→SSL復号の機能を備える)
ELB自体にセキュリティグループの設定可能
ヘルスチェックとモニタリング
外部ELBと内部ELB
クロスゾーン負荷分散

3種類のロードバランサーが用意されている。
①NLB(Network Load Balancer)は高性能で複雑な設定をする際に利用。
②ALB(Application Load Balancer): 通常のWEBアプリケーションに利用。
③CLB(Classic Load Balancer): クラシックタイプのELBで、現在は使用することは稀。

NLBはPre-warming申請(暖気運転)は必要ない。
Pre-warming申請とは、急激なアクセス増加が見込まれる場合は、事前にELBをスケールアウトさせておくこと。

ELBは負荷に応じてELB自体を動的にスケーリングすることにより、ボトルネックにならないように設計されている。

5.Route53

可用性と拡張性に優れたクラウドのドメインネームシステム (DNS) ウェブサービスです。
Amazon Route 53 は、www.example.com のような名前を、コンピュータが互いに接続するための数字の IP アドレス (192.0.2.1 など) に変換するサービスで、開発者や企業がエンドユーザーをインターネットアプリケーションにルーティングする、きわめて信頼性が高く、コスト効率の良い方法となるよう設計されています。
Amazon Route 53 は IPv6 にも完全準拠しています。
公式ページ_Route53

memo

外部向けDNSのパブリックホストゾーンと、VPC内DNSのプライベートホストゾーンがある。

複雑なルーティングはトラフィックフローを用いて設定する。

ルーティングポリシーを作成して加重ルーティングを使用すると、複数のリソースを単一のDNS名に関連付けることが可能。

地理位置情報ルーティングを使用すると、ユーザーの地理的位置に基づいてトラフィックを処理するリソースを選択可能。

加重ルーティングポリシーは、指定した比率で複数のリソースにトラフィックをルーティングする場合に使用する。

CNAMEレコード: DNSで定義されるそのドメインについての情報の種類の一つで、あるドメイン名やホスト名の別名を定義するレコード。
自ドメインの特定のサブドメインやホスト名について、それと同等とみなす別の名前を任意に設定することが可能。
自動フェイルオーバーをルーティングする際はCNAMEレコードに設定する。

TXTレコード: ホスト名に関連付けるテキスト情報（文字列）を定義するレコード。

MXレコード: 対象ドメイン宛のメール配送先ホスト名を定義するレコード。

A(Address)レコード: ホスト（FQDN）とサーバーを識別するグローバルIPアドレスの関連づけを定義するレコード。ドメイン名からIPアドレス。

DNAME: 別のドメインに対してDNS名の部分木全体をマッピングする機能を提供するレコード。

ALIASレコード: AWS独自のレコード方式。CNAMEレコードと同じように機能するが、CNAMEレコードでは対応できないZone Apexの名前解決をサポートする。Zone Apexとは、ゾーンの頂点のこと。

フェールオーバールーティングポリシー(アクティブ): Route５３に設定された複数のリソースへ通信をルーティング

フェールオーバールーティングポリシー(パッシブ): 通常利用しているシステムへの通信が正常に行われない場合に、待機系のシステムへ通信をフェールオーバー

6.CloudFront

データ、動画、アプリケーション、および API をすべて開発者にとって使いやすい環境で、低レイテンシーの高速転送により視聴者に安全に配信する高速コンテンツ配信ネットワーク (CDN) サービスです。
公式ページ_CloudFront

memo

オリジンとしてELB EC2 S3などを指定できる。
オリジンとはCloudFrontへキャッシュするコンテンツの提供元を指す。

地域制限の機能があり、アクセス制御も可能。特定の地域の人にコンテンツを配信したり、逆にブロックすることも可能。

マネージド型サービスでユーザーから最も近いエッジにデータをキャッシュするコンテンツ配信システム。ユーザーに近いエッジを自動で調整してくれるため、データ取得の待ち時間を短縮する。
データがエッジロケーションに存在しない場合、最初にデータをオリジンサーバーから取得・配信される可能性があるが、次回以降はキャッシュされたエッジから処理される。

Lambda@Edgeを使い、画像処理を任せることも可能。
Lambda@Edgeとは、Amazon CloudFrontの機能で、アプリケーションのユーザーに近いロケーションでコードを実行できるため、パフォーマンスが向上し、待ち時間が短縮可能。

7.Lambda

AWS Lambda を使用することで、サーバーのプロビジョニングや管理をすることなく、コードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。
公式ページ_Lambda

memo

実行時間に制限があるため時間を要する処理には不向き。

処理結果は全てCloudWatch Logsに保存。

SDKを利用してアプリケーションに組み込むことが可能。

PushモデルではS3、cognito、SNSなどのAWSサービスとカスタムイベントが直接実行する。3回リトライを実施する。
PullモデルではDynamoDB, kinesis と連携ができる。

EC2インスタンスを利用する場合よりも安価に実行環境を作ることが可能。

100ミリ秒単位でコード実行時間に対しての課金される。

512MBが一時ボリュームの最大制限。

8.S3(Simple Storage Service)

業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。つまり、あらゆる規模や業界のお客様が、ウェブサイト、モバイルアプリケーション、バックアップおよび復元、アーカイブ、エンタープライズアプリケーション、IoT デバイス、ビッグデータ分析など、広範にわたるユースケースのデータを容量に関係なく、保存して保護することができます。Amazon S3 では使いやすい管理機能を使用するため、データを整理して、細かく調整されたアクセス制御を設定することで、特定のビジネスや組織、コンプライアンスの要件を満たすことができます。
公式ページ_S3

memo

以下の機能を備えている。
・高耐久性
・大容量ストレージ
・バージョニング機能
・静的WEBサイトホスティング
・暗号化
・アクセス制御→IAMポリシー、バケットポリシー、ACL
・柔軟なライフサイクルポリシー
・オブジェクトレベルのログ保管

サービスとしてはグローバルで、データはリージョンに配置される。

バケットポリシーでもアクセス制御ができるが、特定のユーザー単位でのアクセス制御を主としており、特定IPアドレスが付与されたEC2インスタンスからのアクセス制御にはIAMロールの方が最適。

URL例(http://バケット名.s3-website-リージョン名.amazonaws.com/モジュール名)

処理要求が高い場合は、オブジェクト名の前(プレフィックス)にハッシュキーまたはランダムな文字列を使用可能。そのすることで、オブジェクトを格納するために使用されるパーティションはより良く分散され、オブジェクトに対する読み書き性能を向上させる。
主にGET要求を送信しているときは、キー名にランダム性を追加することで、データ処理を改善することが可能です。

ストレージオプション種類
①S3-Standard: 頻繁に利用するデータに使用する。
②S3 One Zone-IA: は、アクセスが頻繁ではないデータをレジリエンス(回復力)が低い単一アベイラビリティーゾーンに保存することによってコストを節約。データ消失の恐れがあるデータには向いていない。
③S3 Standard-IA: アクセスが頻繁ではないマスターデータの長期保存に適している。読み込みはすぐにできるため突然の利用にも対応でき、Standardよりも安価に利用可能。
④RRS(Reduced Redundancy Storage): 一時的なデータを保存するときに利用。動画変換など。

S3 Glacier: アーカイブを目的としたストレージで大容量のデータを安価に保管可能。ただデータへアクセスするには時間がかかる。
新しい Glacier Deep Archive ストレージクラスは、耐久性があり、セキュアな大量のデータ向けの長期ストレージを、オフプレミスのテープアーカイブサービスに負けない価格で提供するよう設計されている。データは 3 つ以上の AWS アベイラビリティゾーンにまたがって保存され、12 時間以内に取りだすことが可能。

Glacierの取り出しオプションは以下３つ。
①標準：取り出し3〜5時間で完了。デフォルトで適用される。
②大容量: 取り出し5〜12 時間で完了。最も安価な取り出しオプション。
③迅速: 取り出し通常1～5 分で完了。一番高い。

バケットポリシーでCloudfrontからのアクセスだけを許可するには、CloudFrontユーザを意味するOAI (original Access identity)を作成し、OAIからのアクセスのみ許可する。

署名付きURLを使用してS3に直接アップロードすると、Webサーバーを経由せずに直接S３に格納可能。

S3バケットに対してMFA認証を有効化すると削除に対して認証情報を問われることになり作業ミスを防ぐことが可能。
またバージョニング機能を有効化することで削除されたファイルを戻すことが可能。
初期設定で削除できないようにすることも可能。

S3は結果整合性モデル。したがって、オブジェクトの更新が同じキーに対して行われると、次の読み取り要求が行われたときに更新されたオブジェクトがユーザーに返されるときにわずかな遅延が生じる可能性がある。

SSE-S3: サーバーサイド暗号化。AWSが管理する鍵をつかって暗号化する方法で、ユーザが鍵について意識する必要が無い。データとマスターの暗号化キーを管理する方式であるため、暗号化と複合化はS3によって自動で管理される。

SSE-KMS: サーバーサイド暗号化。AWS KMSで管理されている鍵を使って暗号化。SSE-S3と違い、ユーザごとに別の鍵を利用することも可能。鍵のアクセス権限の管理や、利用履歴などを確認することも可能。

SSE-C: サーバーサイド暗号化。ユーザが作成した鍵をAWSに送信し、AWSで暗号化する方式。

CSE-C: クライアントサイド暗号化。クライアント内で暗号化したオブジェクトをS3に登録する方式。暗号化されたオブジェクトはユーザー以外に複合化が不可能。

マルチパートアップロード: 大容量のオブジェクトを複数のパートに分割してアップ

クロスリージョンレプリケーション: 異なる Amazon S3 バケット間でオブジェクトを自動的に非同期コピーすること。バージョニングが有効化されている必要がある。

9.RDS(Relational Database Service )

ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップなどの時間がかかる管理タスクを自動化しながら、コスト効率とサイズ変更可能なキャパシティーを提供します。
公式ページ_RDS

memo

標準設定の場合、1日一回バックアップ実施される。保存期間は最大35日。トランザクションログは5分ごとにS3に保存。

復元方法は2種類。通常のスナップショットから復元する。
ポイントインタイムリカバリというバックアップとトランザクションログが残っている範囲のデータを復元。

SSL接続可能。

リードレプリカは、マルチAZや異なるリージョン間で構築できる。またマスターデータベースと異なるインスタンスタイプやストレージで構築することができる。読み込み処理の負荷を下げることが目的で、冗長性は上がらない。

ストレージサイズは拡張はできるが縮小不可。

インスタンス作成時のみ暗号化設定可能。

マルチAZ構成は一方のAZのRDSが停止した際にもう一方のRDS DBに移行することが出来るという冗長化の構成。読み取り速度の性能が向上することはない。

レプリケーションラグ: リードレプリカは非同期的にレプリケートされる個別のデータベースインスタンスであるため、レプリケーションデータは遅れを受けやすく、最新のトランザクションのいくつかを表示できない可能性があること。

10.DynamoDB

規模に関係なく数ミリ秒台のパフォーマンスを実現する、key-value およびドキュメントデータベースです。完全マネージド型マルチリージョン、マルチマスターで耐久性があるデータベースで、セキュリティ、バックアップおよび復元と、インターネット規模のアプリケーション用のメモリ内キャッシュが組み込まれています。DynamoDB は、1 日に 10 兆件以上のリクエストを処理することができ、毎秒 2,000 万件を超えるリクエストをサポートします。
公式ページ_DynamoDB

memo

完全マネージド型NoSQLデータベースサービスであり、シームレスでスケーラビリティを備えた高速かつ予測可能なパフォーマンスを提供。バックアップ、高可用性。結果整合性モデル。

利用負荷があらかじめ予想できる場合はプロビジョンドスループットを選択する。

クロスリージョンレプリケーションを実行するにはDynamoDB streamを有効化する。

DynamoDBストリームを有効化すると、DynamoDBへの登録・変更などのイベントをトリガーにしてLambda関数を動作させるなどを実行することが可能。

テーブル作成→項目→属性で作成。

メタデータや一連のストリームデータを蓄積することでビッグデータ解析などに利用可能。またユーザー設定などを格納するための理想的なデータ層。

DynamoDBのスキーマレスなNoSQLデータベースであり、セッションデータを大量に保存するのに適している。

DynamoDB accelerator (DAX): DynamoDb 用のインメモリキャッシュ。高速に処理できる。１秒あたり１００万回単位のリクエスト処理でも数ミリ秒のレイテンシー。

終わりに

試験合格するだけならば各サービスを動かさなくても教科書のみでも十分可能です！
がしかし、やはり実際に手を動かすべきですね。
資格取得が目標にならないように。実際にAWSサービスの構築・設定ができるのを目標にしましょう！

近いうちにその他サービス編も投稿致します。
ご覧いただきありがとうございます!

memo
オンデマンドインスタンスはインスタンスファミリー、OS、テナンシー、支払いオプションの変更ができない。リザーブドは可能。
インスタンスストアは、EC2の一時的なデータが保持される。インスタンスが停止または終了した場合、インスタンスストアボリューム上のデータはすべて失われるため。 EBSは他の物理ハードドライブと同じように使用可能。インスタンスが停止または終了した場合でも、データは失われない。
タグを使用すると、目的、所有者、環境など、さまざまな方法でAWSリソースを分類可能。 EC2インスタンスの開発用タグで分類分けを行い、そのタグが設定されているEC2インスタンスのみに操作できるようにIAMポリシーを設定することで、本番用への削除権限を与えない設定が可能。
AWSでは初期の制限によって、リージョンあたり20インスタンスという制限設定がある。 Auto Scalingで立ち上げが失敗した際は限度引き上げ申請を行い、承認されたら失敗した要求を再試行を行うことで立ち上げ可能。
EC2インスタンスを立ち上げたばかりのときにステータス情報がデータ不足の場合は、ボリューム上でチェックがまだ進行中である可能性がある。
起動設定においてソフトウェアがインストールされた最新の状態のAMIを作成するか、Bashスクリプトでソフトウェアのインストールを仕込んでおくことで自動で同じEC２インスタンスを起動できるようになる。
EBSのバックアップを取得することで、S3にデータが保存されるためEBSを復元することは可能だが、EC2インスタンスの設定自体は回復することができない。
Elastic IPは、起動しているEC2インスタンスにアタッチされている場合には料金発生なし。
プレイスメントグループとは、単一のアベイラビリティーゾーン内のEC2インスタンスを論理的にグルーピングしたもの。より高速に処理可能。
EC2インスタンスはステートレスなアプリ開発には向いてない。ステートレスアプリケーションとは以前のシステム上のやり取りについての状態情報が不要なため、セッション情報が格納されていないアプリケーションのこと。ステートレスな処理をサービス化するならば、Lambdaを利用する方がコスト最適できる可能性が高い。
3つのボリュームすべてのスナップショットを取るためにには、EC2インスタンスを停止して静止点を設けた上で、各EC2インスタンスのスナップショットを個別に作成する必要がある。
Dedicated Host:ユーザー専用のホスト。
スティッキーセッション:セッション中に同じユーザーから来たリクエストを全て同じEC2インスタンスに送信する機能。

memo
ルートテーブル内のデフォルトゲートウェイ(0.0.0.0/0)へのルーティングに、インターネットゲートウェイを指定するとパブリックサブネット。指定していないサブネットがプライベートサブネット。
NATゲートウェイをパブリックサブネットに配置し経由するとプライベートサブネットからインターネットへ接続可能。
サブネットはAZに跨って作成不可。
VPC内のすべてのサブネット間の通信はデフォルトのルーティングルールで許可されており、変更削除は不可
VPC内のCIDRは/16から/28までが利用可能。
VPCのDNS hostnamesオプションがYesに設定されていないと、サブネットで起動されたインスタンスはDNS名を取得できない。VPC構成の設定を変更することで解決可能。
VPゲートウェイ: direct connect やインターネットVPN接続するためのゲートウェイ。オンプレミス環境と接続するVPCにアタッチ。
VPCピアリング接続: VPC同士はインターネットを経由せずに、プライベートネットワーク内で直接通信が可能。これ無しだと、VPC同士は直接通信は行えない。異なるAWSアカウント間でも可能だが、ネットワークアドレスが一致または重複する場合は接続不可。接続する２つのVPCが同一リージョンに存在する必要がある。
VPCエンドポイント: プライベートサブネットからS3やDynamoDBへアクセスする際、インターネットを経由せずにプライベート接続可能。ルートテーブルでアクセスするIPアドレスをVPCエンドポイントへ向けるように設定する。
セキュリティグループ: インスタンス単位に適用可能なファイアウォール機能。デフォルトはインバウンドは全て拒否。アウトバウンドは全て許可。ステートフルなので、戻りのトラフィックを考慮しなくてよい。設定後すぐルール適用される。指定は許可のみ、拒否の指定不可。インバウンドは必要最低限、アウトバウンドは基本全て許可する。
ネットワークACL: サブネット単位に適用可能なファイアウォール機能。デフォルトはイン・アウトバウンド共に全て許可。ステートレスなので、インだけでなくアウトバウンドのトラフィックも明示的に許可設定する。

memo
【重要な特徴】高可用性 (→複数のAZへ分散自動スケーリング) セキュリティ機能(→SSL復号の機能を備える) ELB自体にセキュリティグループの設定可能ヘルスチェックとモニタリング外部ELBと内部ELB クロスゾーン負荷分散
3種類のロードバランサーが用意されている。 ①NLB(Network Load Balancer)は高性能で複雑な設定をする際に利用。 ②ALB(Application Load Balancer): 通常のWEBアプリケーションに利用。 ③CLB(Classic Load Balancer): クラシックタイプのELBで、現在は使用することは稀。
NLBはPre-warming申請(暖気運転)は必要ない。 Pre-warming申請とは、急激なアクセス増加が見込まれる場合は、事前にELBをスケールアウトさせておくこと。
ELBは負荷に応じてELB自体を動的にスケーリングすることにより、ボトルネックにならないように設計されている。

memo
外部向けDNSのパブリックホストゾーンと、VPC内DNSのプライベートホストゾーンがある。
複雑なルーティングはトラフィックフローを用いて設定する。
ルーティングポリシーを作成して加重ルーティングを使用すると、複数のリソースを単一のDNS名に関連付けることが可能。
地理位置情報ルーティングを使用すると、ユーザーの地理的位置に基づいてトラフィックを処理するリソースを選択可能。
加重ルーティングポリシーは、指定した比率で複数のリソースにトラフィックをルーティングする場合に使用する。
CNAMEレコード: DNSで定義されるそのドメインについての情報の種類の一つで、あるドメイン名やホスト名の別名を定義するレコード。自ドメインの特定のサブドメインやホスト名について、それと同等とみなす別の名前を任意に設定することが可能。自動フェイルオーバーをルーティングする際はCNAMEレコードに設定する。
TXTレコード: ホスト名に関連付けるテキスト情報（文字列）を定義するレコード。
MXレコード: 対象ドメイン宛のメール配送先ホスト名を定義するレコード。
A(Address)レコード: ホスト（FQDN）とサーバーを識別するグローバルIPアドレスの関連づけを定義するレコード。ドメイン名からIPアドレス。
DNAME: 別のドメインに対してDNS名の部分木全体をマッピングする機能を提供するレコード。
ALIASレコード: AWS独自のレコード方式。CNAMEレコードと同じように機能するが、CNAMEレコードでは対応できないZone Apexの名前解決をサポートする。Zone Apexとは、ゾーンの頂点のこと。
フェールオーバールーティングポリシー(アクティブ): Route５３に設定された複数のリソースへ通信をルーティング
フェールオーバールーティングポリシー(パッシブ): 通常利用しているシステムへの通信が正常に行われない場合に、待機系のシステムへ通信をフェールオーバー

memo
オリジンとしてELB EC2 S3などを指定できる。オリジンとはCloudFrontへキャッシュするコンテンツの提供元を指す。
地域制限の機能があり、アクセス制御も可能。特定の地域の人にコンテンツを配信したり、逆にブロックすることも可能。
マネージド型サービスでユーザーから最も近いエッジにデータをキャッシュするコンテンツ配信システム。ユーザーに近いエッジを自動で調整してくれるため、データ取得の待ち時間を短縮する。データがエッジロケーションに存在しない場合、最初にデータをオリジンサーバーから取得・配信される可能性があるが、次回以降はキャッシュされたエッジから処理される。
Lambda@Edgeを使い、画像処理を任せることも可能。 Lambda@Edgeとは、Amazon CloudFrontの機能で、アプリケーションのユーザーに近いロケーションでコードを実行できるため、パフォーマンスが向上し、待ち時間が短縮可能。

memo
実行時間に制限があるため時間を要する処理には不向き。
処理結果は全てCloudWatch Logsに保存。
SDKを利用してアプリケーションに組み込むことが可能。
PushモデルではS3、cognito、SNSなどのAWSサービスとカスタムイベントが直接実行する。3回リトライを実施する。 PullモデルではDynamoDB, kinesis と連携ができる。
EC2インスタンスを利用する場合よりも安価に実行環境を作ることが可能。
100ミリ秒単位でコード実行時間に対しての課金される。
512MBが一時ボリュームの最大制限。

memo
以下の機能を備えている。・高耐久性・大容量ストレージ・バージョニング機能・静的WEBサイトホスティング・暗号化・アクセス制御→IAMポリシー、バケットポリシー、ACL ・柔軟なライフサイクルポリシー・オブジェクトレベルのログ保管
サービスとしてはグローバルで、データはリージョンに配置される。
バケットポリシーでもアクセス制御ができるが、特定のユーザー単位でのアクセス制御を主としており、特定IPアドレスが付与されたEC2インスタンスからのアクセス制御にはIAMロールの方が最適。
URL例(http://バケット名.s3-website-リージョン名.amazonaws.com/モジュール名)
処理要求が高い場合は、オブジェクト名の前(プレフィックス)にハッシュキーまたはランダムな文字列を使用可能。そのすることで、オブジェクトを格納するために使用されるパーティションはより良く分散され、オブジェクトに対する読み書き性能を向上させる。主にGET要求を送信しているときは、キー名にランダム性を追加することで、データ処理を改善することが可能です。
ストレージオプション種類 ①S3-Standard: 頻繁に利用するデータに使用する。 ②S3 One Zone-IA: は、アクセスが頻繁ではないデータをレジリエンス(回復力)が低い単一アベイラビリティーゾーンに保存することによってコストを節約。データ消失の恐れがあるデータには向いていない。 ③S3 Standard-IA: アクセスが頻繁ではないマスターデータの長期保存に適している。読み込みはすぐにできるため突然の利用にも対応でき、Standardよりも安価に利用可能。 ④RRS(Reduced Redundancy Storage): 一時的なデータを保存するときに利用。動画変換など。
S3 Glacier: アーカイブを目的としたストレージで大容量のデータを安価に保管可能。ただデータへアクセスするには時間がかかる。新しい Glacier Deep Archive ストレージクラスは、耐久性があり、セキュアな大量のデータ向けの長期ストレージを、オフプレミスのテープアーカイブサービスに負けない価格で提供するよう設計されている。データは 3 つ以上の AWS アベイラビリティゾーンにまたがって保存され、12 時間以内に取りだすことが可能。
Glacierの取り出しオプションは以下３つ。 ①標準：取り出し3〜5時間で完了。デフォルトで適用される。 ②大容量: 取り出し5〜12 時間で完了。最も安価な取り出しオプション。 ③迅速: 取り出し通常1～5 分で完了。一番高い。
バケットポリシーでCloudfrontからのアクセスだけを許可するには、CloudFrontユーザを意味するOAI (original Access identity)を作成し、OAIからのアクセスのみ許可する。
署名付きURLを使用してS3に直接アップロードすると、Webサーバーを経由せずに直接S３に格納可能。
S3バケットに対してMFA認証を有効化すると削除に対して認証情報を問われることになり作業ミスを防ぐことが可能。またバージョニング機能を有効化することで削除されたファイルを戻すことが可能。初期設定で削除できないようにすることも可能。
S3は結果整合性モデル。したがって、オブジェクトの更新が同じキーに対して行われると、次の読み取り要求が行われたときに更新されたオブジェクトがユーザーに返されるときにわずかな遅延が生じる可能性がある。
SSE-S3: サーバーサイド暗号化。AWSが管理する鍵をつかって暗号化する方法で、ユーザが鍵について意識する必要が無い。データとマスターの暗号化キーを管理する方式であるため、暗号化と複合化はS3によって自動で管理される。
SSE-KMS: サーバーサイド暗号化。AWS KMSで管理されている鍵を使って暗号化。SSE-S3と違い、ユーザごとに別の鍵を利用することも可能。鍵のアクセス権限の管理や、利用履歴などを確認することも可能。
SSE-C: サーバーサイド暗号化。ユーザが作成した鍵をAWSに送信し、AWSで暗号化する方式。
CSE-C: クライアントサイド暗号化。クライアント内で暗号化したオブジェクトをS3に登録する方式。暗号化されたオブジェクトはユーザー以外に複合化が不可能。
マルチパートアップロード: 大容量のオブジェクトを複数のパートに分割してアップ
クロスリージョンレプリケーション: 異なる Amazon S3 バケット間でオブジェクトを自動的に非同期コピーすること。バージョニングが有効化されている必要がある。

memo
標準設定の場合、1日一回バックアップ実施される。保存期間は最大35日。トランザクションログは5分ごとにS3に保存。
復元方法は2種類。通常のスナップショットから復元する。ポイントインタイムリカバリというバックアップとトランザクションログが残っている範囲のデータを復元。
SSL接続可能。
リードレプリカは、マルチAZや異なるリージョン間で構築できる。またマスターデータベースと異なるインスタンスタイプやストレージで構築することができる。読み込み処理の負荷を下げることが目的で、冗長性は上がらない。
ストレージサイズは拡張はできるが縮小不可。
インスタンス作成時のみ暗号化設定可能。
マルチAZ構成は一方のAZのRDSが停止した際にもう一方のRDS DBに移行することが出来るという冗長化の構成。読み取り速度の性能が向上することはない。
レプリケーションラグ: リードレプリカは非同期的にレプリケートされる個別のデータベースインスタンスであるため、レプリケーションデータは遅れを受けやすく、最新のトランザクションのいくつかを表示できない可能性があること。

memo
完全マネージド型NoSQLデータベースサービスであり、シームレスでスケーラビリティを備えた高速かつ予測可能なパフォーマンスを提供。バックアップ、高可用性。結果整合性モデル。
利用負荷があらかじめ予想できる場合はプロビジョンドスループットを選択する。
クロスリージョンレプリケーションを実行するにはDynamoDB streamを有効化する。
DynamoDBストリームを有効化すると、DynamoDBへの登録・変更などのイベントをトリガーにしてLambda関数を動作させるなどを実行することが可能。
テーブル作成→項目→属性で作成。
メタデータや一連のストリームデータを蓄積することでビッグデータ解析などに利用可能。またユーザー設定などを格納するための理想的なデータ層。
DynamoDBのスキーマレスなNoSQLデータベースであり、セッションデータを大量に保存するのに適している。
DynamoDB accelerator (DAX): DynamoDb 用のインメモリキャッシュ。高速に処理できる。１秒あたり１００万回単位のリクエスト処理でも数ミリ秒のレイテンシー。

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T10:15:39+09:00

AWS Batchについて調べてみた。

ECSでバッチ処理を作成したことがあります。
そこで、”AWS Batch”が気になったため、調べてみました。
今頃。。。

ブラックベルトより

https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/

AWS Batch
①フルマネージドのバッチ処理実行システム（ECSを使用している）
②ジョブとして登録したアプリケーションやコンテナイメージをスケジューラから実行

1.システム管理者が使用するジョブ管理システム

夜間バッチのような、予めジョブの起動や順序を定義し、ジョブの実行・管理するシステム

2.システム利用者が使用するジョブ管理システム

ユーザが任意に投入したジョブをキューイングして、リソース状況に合わせて効率よく実行するシステム

★AWS Batchは、"2."らしい。大規模なスケール、ジョブの依存定義が可能なマネージド並列分散処理基盤。
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-aws-batch/10

一番の疑問

スケジュール起動型のバッチ処理にAWS Batchは向いているのか？

Ans.
肝心のスケジュール起動は出来なく、あくまでもジョブキュー系の処理をするためのもの
大規模データのバッチ処理みたいな使い方を想定されたサービスで、cron代わりといった用途には向かないとの事。

であれば、やはりスケジュール起動系は、下記かな。

①Amazon ECSのScheduleTask
②Lambda（スケジュール起動）※①より制約多し（メモリ、CPU、言語、処理時間15分）

なので、軽微なバッチ処理しか作らないのであれば、管理も簡単なLambdaもありかと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T05:46:49+09:00

EC2でunicorn接続した際に`ArgumentError: Already running on PID〜`エラーになった時の対処法

はじめに

EC2で次のようにunicorn接続を行った際に起こり、接続できなかったので、そのエラー理由と対処法を備忘録として残しておきます。
[ec2-user@ip-10-0-0-133 twitter_clone_2019]$ bundle exec unicorn_rails -E development -c config/unicorn/development.rb -D
master failed to start, check stderr log for details
このエラーは何か？？

check stderr log for details（詳細はstderrlogを確認するように）とあるので調べてみると以下のような結果が出ました。ここで注目するのがAlready running on PID:17739となります。unicornは接続する度にプロセスIDが割り当てられます。そのため、このエラーは以前に行ったunicorn接続のプロセスが残っており、それが実行中のため再度接続できません、という意味です。
[ec2-user@ip-10-0-0-133 twitter_clone_2019]$ sudo vi log/unicorn.stderr.log
bundler: failed to load command: unicorn_rails (/var/www/twitter_clone_2019/vendor/bundle/ruby/2.6.0/bin/unicorn_rails)
ArgumentError: Already running on PID:17739 (or pid=/var/www/twitter_clone_2019/shared/tmp/pids/unicorn.pid is stale)
  /var/www/twitter_clone_2019/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:207:in `pid='
  /var/www/twitter_clone_2019/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/lib/unicorn/http_server.rb:139:in `start'
  /var/www/twitter_clone_2019/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.1/bin/unicorn_rails:209:in `<top (required)>'
  /var/www/twitter_clone_2019/vendor/bundle/ruby/2.6.0/bin/unicorn_rails:23:in `load'
  /var/www/twitter_clone_2019/vendor/bundle/ruby/2.6.0/bin/unicorn_rails:23:in `<top (required)>'
エラー対処法

unicornを再起動させたり、停止させたい場合は、動作中のプロセスに対してkillというシグナルを送信することででプロセスを停止させることができます。ec2-user 17978等がプロセスになります。これらの動作中のプロセスを停止させた後、grepと書かれているプロセスのみ残っていればOKです。これで、unicorn接続を改めて行うことが可能となります。
[ec2-user@ip-10-0-0-133 twitter_clone_2019]$ ps aux | grep unicorn  #プロセスの確認
ec2-user 17978  5.4  7.3 776516 74064 ?        Sl   14:14   0:00 unicorn_rails master -E development -c config/unicorn/development.rb -D
ec2-user 17985  0.0  6.6 776516 66500 ?        Sl   14:14   0:00 unicorn_rails worker[0] -E development -c config/unicorn/development.rb -D
ec2-user 17986  0.0  6.6 776516 66500 ?        Sl   14:14   0:00 unicorn_rails worker[1] -E development -c config/unicorn/development.rb -D
ec2-user 18020  0.0  0.0 119484   896 pts/1    S+   14:14   0:00 grep --color=auto unicorn
[ec2-user@ip-10-0-0-133 twitter_clone_2019]$ kill 17978  #プロセスの停止
[ec2-user@ip-10-0-0-133 twitter_clone_2019]$ ps aux | grep unicorn　#再度プロセスの確認
ec2-user 18023  0.0  0.0 119484   936 pts/1    S+   14:16   0:00 grep --color=auto unicorn　
上記の方法だと、毎回停止させるプロセス番号の確認が必要となりますが、以下の方法だと確認作業を省略することができます。-3は中止シグナルとなっており、バッククオート内で実行されているプロセスを停止させることができるコマンドです。
[ec2-user@ip-10-0-0-133 twitter_clone_2019]$ kill -3 `cat shared/tmp/pids/unicorn.pid`  #unicorn.pidがあるpathをバッククオートで囲む
参考資料

https://wa3.i-3-i.info/word11040.html
https://qiita.com/Coconew5/items/2f4ba976e58da9c1ec22
https://www.k-tanaka.net/unix/kill.php

　 Tweet
Qiitaで続きを読む

投稿日：2019-09-29T00:50:07+09:00

初学者のためのAWS入門(1)

ここでは、AWSを基礎から学ぶ人向けに必要な情報をまとめていきます。

初学者のためのAWS入門シリーズ

初学者のためのAWS入門(1) -> この記事です。

初学者のためのAWS入門(2) - CloudFormation入門1

初学者のためのAWS入門(3) - CloudFormation入門2

初学者のためのAWS入門(4) - S3でBasic認証を設定してリポジトリを公開

・AWSの概略を把握する（サービス一覧把握、クラウドとオンプレの比較、AWSの基礎用語把握、課金体系を把握、ストレージコストの把握）
・EC2でインスタンスを作ってみる
・IAMユーザを作ってみる
・S3を触ってみる
・S3にデータをおいて、EC2にマウントしてみる
・AWS CLIを導入してみる
・ファイアウォールの設定を触ってみる

1. AWSの主なサービス一覧

コンピューティング

Amazon EC2

正式名称は Amazon Elastic Compute Cloud で、AWSのIaaSのひとつ。さまざまなスペックの仮想マシンを作成して実行できる。EBS（Elastic Block Store）やELB（Elastic Load Balancing）と統合されている。

Amazon Lightsail

VPSサービス。EC2とは料金プランが異なり、ほとんど設定をすることなくWordPressやRedmineなどがインストールされたサーバを起動できる。

Amazon Elastic Container Service

Dockerコンテナのクラスタ管理サービス。従来クラスタはEC2で管理されていたが、２０１８年AWS Fargateが発表され、EC2を起動せずにコンテナを実行できるようになった。

AWS Lambda

サーバ不要でアプリケーションコードのみをデプロイすることで、イベント駆動でコードが実行できるサービス。他のサービスとのハブとなり、サーバレスアーキテクチャの中核となるサービス。

AWS Batch

バッチ処理を実行できるサービス。サーバ不要・処理の実行という点でLambdaと似ているが、Lambdaにはリクエストあたりの最大実行時間が300秒という制限があるため、時間のかかる処理や複雑な処理をしたい時に使用する。処理はジョブという単位で登録し、ECSコンテナクラスタで実行される。

AWS Elastic Beanstalk

アプリケーションのデプロイ・管理サービスで、AWSのPaaSのひとつ。EB単体のものではなく、実態はEC2やS3、RDSやELBなどをプロビジョニングするサービス。

AWS Multi-Factor Authentication (MFA)

ユーザー名とパスワードに加えて保護のレイヤーを追加できる、簡単なベストプラクティス。
MFA を有効にすると、ユーザーが AWS ウェブサイトにサインインするときに、ユーザー名とパスワード (第 1 の要素、つまりユーザーが知っているもの) の他に、AWS MFA デバイスからの認証コード (第 2 の要素、つまりユーザーが持っているもの) を入力することが必要になる。このように複数の要素を組み合わせることによって、AWS アカウントの設定とリソースのセキュリティが強化される。

ストレージ

Amazon S3

正式名称は Amazon Simple Storage Service で、年間で99.99%の可用性と99.999999999%の耐久性を実現するよう設計されたオブジェクトストレージ。アクセスポリシー、データの暗号化、バージョニング、MFA削除、ライフサイクル管理ポリシー、イベント通知。さらに、静的Webサイトホスティング、タグ付け、クロスリージョンレプリケーションなど、およそSimpleとは言えない豊富な機能を備えている。

Amazon EFS

正式名称は Amazon Elastic File System で、フルマネージドなNFSサーバサービス。最大数千のEC2インスタンスからの同時アクセスが可能で、ペタバイト単位まで自動的にスケールする。

Amazon Glacier

頻繁に使用されないデータ（コールドデータ）に最適化された低コスト、高耐久性を備えたストレージサービス。アーカイブ、バックアップ用途に向いており、S3のライフサイクル管理を利用することで自動的にデータを移行したりできる。

AWS Storage Gateway

オンプレミスのアプライアンスからクラウドベースのストレージに接続できるサービス。ファイルベース、ボリュームベース、テープベースという異なったインタフェースでの接続がサポートされている。

データベース

Amazon RDS

正式名称は Amazon Relational Database Service で、フルマネージドなRDBサーバサービス。Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle、Microsoft SQL Serverの6つのデータベースエンジンから選択できる。

Amazon DynamoDB

フルマネージドなNoSQLデータベースサービス。セカンダリインデックスやスループットキャパシティによるパフォーマンスの調整ができる。

Amazon ElastiCache

フルマネージドな分散型インメモリデータストアサービス。キャッシュエンジンとしてmemcachedとRedisがサポートされている。

Amazon Redshift

フルマネージドなデータウェアハウスサービス。PostgreSQL互換のインタフェースを備えるため、PostgreSQLの管理ツールが使用できる。

移行

AWS Migration Hub

各種移行ツールの、アプリケーションの移行状況を追跡できるダッシュボードサービス。Migration Hub自体はオレゴンリージョンのみサポートしている。

AWS Application Discovery Service

オンプレミスのサーバの基本情報、使用状況、設定などのデータ収集サービス。Migration Hubに統合されている。

AWS Database Migration Service

同一DB製品間でのデータ移行、別DB製品への移行サービス。ソースとしてRDB以外にMongoDBがサポートされていたり、ターゲットとしてRDB以外にS3やDynamoDBがサポートされている。Migration Hubに統合されている。

AWS Server Migration Service

オンプレミスのVMwareまたはHyper-Vの仮想マシンをAWS クラウド環境に移行するサービス。Migration Hubに統合されている。

AWS Snowball

オンプレミスのサーバとS3との間で、オフラインでデータを移行するサービス。ペタバイトクラスのデータ移行が主なユースケースのひとつ。

ネットワーキング＆コンテンツ配信

Amazon VPC

正式名称は Amazon Virtual Private Cloud で、AWS クラウドに作成できる仮想ネットワークサービス。サブネット、Elastic IP、セキュリティグループ、ネットワークACL、ゲートウェイ、ルートテーブルといったリソースが用意されている。

Amazon CloudFront

静的および動的Webコンテンツを配信するCDNサービス。HTTP/HTTPS経由でのWebコンテンツとRTMPを使用してのメディアファイルのストリーミングがサポートされている。

Amazon Route 53

フルマネージドなDNSサーバサービス。リソースのヘルスチェック（＋DNSフェイルオーバー）、多様なルーティングポリシーとトラフィックポリシー、通常のレコードタイプのほかエイリアスレコードもサポートされている。

Amazon API Gateway

RESTful APIを作成、デプロイできるサービス。エンドポイントとして、Webサイト、Lambda関数、その他のAWSサービスがサポートされている。Swaggerファイルによるインポート／エクスポートがサポートされている。

AWS Direct Connect

オンプレミスのネットワークとAWSのネットワーク（VPC）を接続するプライベートネットワークサービス。一般的にDXと略される。

機械学習

Amazon Amazon SageMaker

フルマネージドな機械学習サービス。調査、クレンジング、前処理に対してセットアップなしで利用可能なJupyterノートブックを実行するインスタンスが提供される。機械学習モデルを早く簡単に構築、トレーニング、ホスティングできる。

Amazon Amazon Comprehend

フルマネージドな自然言語処理サービス。テキストの中から場所や人物、キーフレーズ、感情（肯定的／否定的／混在／中立）などが検出できる。

AWS DeepLens

ディープラーニングに対応したプログラム可能なビデオカメラ。Kinesis Video StreamsやRekognition Video、SageMakerやLambdaと統合、連携できる。

Amazon Lex

Chatbotなどの、音声やテキストに反応する対話型インタフェースを構築するサービス。自然言語処理にAlexaと同等のディープラーニング技術を使用できる。

Amazon Machine Learning

機械学習のモデルを構築し、予測を生成するサービス。モデルのデータソースとして、S3に保存されたデータセット、RedshiftまたはRDSのMySQLが使用できる。

Amazon Polly

テキストを自然な音声に変換するテキスト読み上げサービス。SSML（Speech Synthesis Markup Language）を使用して発音、ボリューム、話す速度など、音声のさまざまな要素をカスタマイズできる。また、レキシコンによる単語の発音のカスタマイズも可能。

AWS Rekognition

画像の検索と分析サービス。画像内の物体、シーン、テキスト、顔の検出、有名人の認識、および不適切なコンテンツの識別ができる。また動画でも使用可能となるRekognition Videoも発表された。

Amazon Transcribe

音声をテキストに変換する文字起こしサービス。電話音声など不鮮明なものも可能で、すべての単語へタイムスタンプ付与、複数話者の認識などの機能も予定されている。なお執筆時点でプレビュー版です。

Amazon Translate

テキストベースのコンテンツを多言語へ変換できるニューラル機械翻訳サービス。既存のテキストを大量に翻訳するバッチ翻訳と、オンデマンドで翻訳するリアルタイム翻訳の両方に対応している。なお執筆時点でプレビュー版です。

分析

Amazon Athena

標準SQLを使用してS3のデータを分析できるインタラクティブクエリサービス。Prestoで構築され、CSV、JSON、ORC、Avro、Parquet などのさまざまな標準データフォーマットに対応し、自動で並列的に実行される。

Amazon EMR

正式名称は Amazon Elastic MapReduce で、フルマネージドな（HadoopやSparkなどの）ビッグデータフレームワークサービス。ストレージとしてHDFS、S3を直接利用できるEMRFS、ローカルファイルシステムがある。

Amazon CloudSearch

フルマネージドなカスタム検索サービス。スケーラブル、高い信頼性とパフォーマンス、豊富な検索機能などを備える。Solrベース。

Amazon Elasticsearch Service

フルマネージドなElasticsearchクラスタサービス。KibanaやLogstashがサポートされ、S3、Kinesis、DynamoDBとの統合も可能。

Amazon Kinesis

リアルタイムでストリーミングデータを処理できるサービス。高速かつ継続的にデータの取り込みと集約を行うことができる Kinesis Data Streams 。S3、Redshift、Elasticsearch Serviceなどの送信先にリアルタイムのストリーミングデータを提供する Kinesis Data Firehose 。標準SQLを使用してストリーミングデータの処理や分析ができる Kinesis Data Analytics といったサービス群からなる。

Amazon QuickSight

簡単に高速にデータを分析・可視化できるクラウドBIサービス。データソースとしてRDB（RDSやオンプレのRDBなど）やS3、AthenaやRedshift、ExcelやCSVなどのファイル、SaaS（Salesforce）が使用できる。アドホック分析やダッシュボードを作成しデータを可視化できる。

AWS Data Pipeline

サービス（ノード）間のデータの移行および変換を行えるサービス。連携可能なサービスとしてDynamoDB、RDS、Redshift、S3がサポートされている。定義した処理はEC2またはEMRで実行され、スケジュール機能と組み合わせることでジョブスケジューラとしても利用できる。

AWS Glue

フルマネージドなETL（Extract、Transform、Load）サービス。RDSやS3といったデータソースをクロールしてデータカタログを構築、次にETL処理をジョブとしてトリガ登録（スケジュール／連結／オンデマンド）することで処理を実行する。

セキュリティ、アイデンティティ、コンプライアンス

AWS IAM

正式名称は AWS Identity and Access Management で、ユーザー認証やアクセス許可によって、AWSリソースへのアクセスを安全に制御するためのサービス。ユーザー、グループ、ロールといったリソースにアクセス許可を定義したポリシーを紐付けることでアクセス制御を行う。また、STS（Security Token Service）を使用することで、一時認証情報を利用したクロスアカウントアクセスやIDフェデレーションが可能となる。

Amazon Cognito

ユーザー認証（IDの発行）とアプリケーションデータの同期を行えるサービス。ユーザーディレクトリを作成、管理し、モバイルアプリおよびWebアプリに、サインアップとサインインを追加できる Cognito User Pools 。フェデレーテッドIDプロバイダで認証し、STSによる一時的な認証情報を作成できる Cognito フェデレーテッドアイデンティティ。アプリケーション関連のユーザーデータのオフラインでのアクセスとデバイス間の同期をサポートする Cognito Sync といった機能がサポートされている。

Amazon GuardDuty

VPCフローログ、CloudTrailイベントログおよびDNSログを監視・分析する、継続的なセキュリティモニタリングサービス。GuardDutyが生成した結果はCloudWatch Eventsとの連携が可能（執筆時点ではCLIのみ設定可能）。

Amazon Inspector

AWSリソース（執筆時点ではEC2インスタンスのみ）の動作を分析する自動化されたセキュリティ評価サービス。評価ターゲットの各インスタンスにはInspectorエージェントをインストールする。エージェントは、安全な通信の使用、プロセス間のネットワークトラフィック、AWSリソースの動作や設定といったデータ（テレメトリー）を収集・分析し、セキュリティルールと比較を行う。

Amazon Macie

S3に保存されているデータを、機械学習によって自動的に検出、分類、保護するフルマネージドなセキュリティサービス。個人情報（PII）や知的財産などの機密データを認識し、さらにアクセスパターンとユーザーの動作を分析することで、不正アクセスの危険や不注意によるデータ漏洩などを監視する。

AWS Single Sign-On

Microsoft Active Directoryの認証情報を使用してシングルサインオンを管理するサービス。AWS Organizationsで管理されているAWSアカウントやビジネスクラウドアプリケーション（Office 365、Salesforce、Boxなど）、SAML 2.0をサポートするアプリケーションにSSO可能となる。クラウドのAD（Microsoft AD）あるいはオンプレミスのAD（Microsoft ADと信頼関係またはAD Connector）がサポートされるが、Simple ADはサポートしていない。

AWS Certificate Manager

AWSの各種サービスで使用するSSL/TLS証明書のプロビジョニング、管理、およびデプロイができるサービス。Webサイトやアプリケーションに直接証明書をインストールすることはできず、サポートされているサービスにインストールして使用する。発行される証明書の有効期限は13ヵ月で、自動的に更新される。執筆時点でサポートされているサービスはELB、CloudFront、EB、API Gateway、CloudFormationとなっている。

AWS CloudHSM

フルマネージドなハードウェアセキュリティモジュール（HSM）管理サービス。FIPS 140-2 レベル3に準拠しており、高いセキュリティ要件が求められるサービスでも利用できる。CloudHSMクラスタの作成には、リージョン内の各AZにHSMを作成したHA（高可用性）構成にすることが推奨されている。

AWS Directory Service

フルマネージドなディレクトリサーバサービス。執筆時点では、クラウドネイティブなグラフベースのディレクトリストアである Amazon Cloud Directory 。モバイルアプリまたはWebアプリにサインアップとサインインを追加するユーザーディレクトリ Amazon Cognito Your User Pools 。マネージド型Microsoft Active Directoryである Microsoft AD 。Samba 4を搭載したAD互換のディレクトリ Simple AD 。そして、オンプレのADと連携する AD Connector の、5種類のディレクトリタイプが提供されている。

AWS WAF

CloudFrontまたはALBに転送されるHTTP/HTTPSのリクエストをモニタリングし、悪意のあるリクエストを検出・防御できるWebアプリケーションファイアウォール。条件、ルール、Web ACLを作成することで、コンテンツへのアクセスを制御できる。また、先日マネージドルールが利用可能となった。

AWS Shield

DDoS攻撃からAWSリソースを保護するためのサービスで、 Standard と Advanced の2つの異なる保護レベルが提供されている。Standardは無料で自動的に適用され、SYN/UDPフラッド攻撃やリフレクション攻撃といったL3/L4レベルの攻撃を緩和する。AdvancedはELB、CloudFront、Route 53を対象とするアプリケーション保護を強化する有料サービスで、L3/L4/L7レベルのDDoS攻撃を緩和する。

AWS Artifact

ISO、PCI、SOCレポートなどの、AWSクラウドでのコンプライアンスとセキュリティに関するドキュメントをオンラインでダウンロードできるサービス。ダウンロードしたドキュメント（監査アーティファクト）は信頼している相手のみと、セキュアなドキュメント共有サービスを使用して共有することが推奨されている。

2. クラウドとオンプレの比較

項目クラウドオンプレ

準備期間 ◎　即時利用可能 △　初期契約/設定に時間かかる

初期費用 ◎　なし △　初期費用が必要な場合もある

維持費用 ◯　従量課金(上限設定可能) ◯　基本固定　&　追加費用

障害対 ◎　クラウド事業者が対応 △　原則自社対応

セキュリティ ◎　クラウド事業者が対応 ◯　原則自社対応で強化できる

カスタマイズ △　設定変更&連携で対応 ◎　柔軟にカスタマイズできる

3. VPC

3-1. VPC (Virtual Private Cloud)とは

VPCはAWS専用の仮想ネットワーク。
家庭内でインターネットを利用する際、ルーターやゲートウェイなどのネットワーク機器が必要となる。
一方、VPCはそれらの機器を仮想的に用意し、ネットワーク環境を構築できるサービス。

3-2. リージョン

AWSのグローバルなバックボーンは、「リージョン」と呼ばれる地理的に離れた領域がそれぞれ接続されることで構成されている。
各「リージョン」ではAWSのサービスがそれぞれ独立して提供されており、言い方を変えると「リージョン」はお互いに完全に分離されるよう設計されたAWSのネットワークとサービスの「集合」となる。

リージョン一覧
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions

たとえば、日本には東京リージョン（"ap-northeast-1"）があり、米国にはバージニア北部リージョン（"us-east-1"）、オレゴンリージョン（"us-west-2"）などがあります。
また、政府の業務に関わる米国連邦政府、州、各地方自治体等が利用する GovCloud（米国）リージョン（"us-gov-west-1"）なんていうものもある。

「リージョン」が完全に分離されていることによって、AWS全体としては最大限の耐障害性と安定性が実現されている。

3-3. アベイラビリティ・ゾーン

AWSにおけるリージョンは2つ以上の「アベイラビリティーゾーン」から成り立っており、「アベイラビリティーゾーン」は1つ以上の独立したデータセンターで構成されている。

AWSの東京リージョン（"ap-northeast-1"）では、2つのアベイラビリティーゾーンを利用いただくことができ、各アベイラビリティーゾーンには"ap-northeast-1a"や"ap-northeast-1c"といったIDがつけられています。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones

コード名前

ap-east-1 アジアパシフィック (香港)

ap-northeast-1 アジアパシフィック (東京)

ap-northeast-2 アジアパシフィック (ソウル)

ap-northeast-3 アジアパシフィック (大阪)

ap-southeast-1 アジアパシフィック (シンガポール)

ap-southeast-2 アジアパシフィック (シドニー)

ap-south-1 アジアパシフィック (ムンバイ)

me-south-1 中東 (バーレーン)

3-4. VPCの基本コンポーネント

AWS VPCには様々なコンポーネントが用意されており、それらを組み合わせることで自由にネットワーク環境を構築できる。ここでは現場でもよく使われるコンポーネントについて簡単に説明する。

IGW(インターネットゲートウェイ)

VPCをインターネット接続できるようにするコンポーネント。

Subnet(サブネット)

VPCという大きなネットワークのくくりの中に、小さいネットワークの集まりを作ることができるコンポーネント。

例えばVPCで全体のネットワーク空間を、下記のアドレス範囲で設定したとする。
10.0.0.0 /16
このアドレスの範囲内で、インターネットと通信できるパブリックなネットワークと、外部から遮断したいプライベートなネットワークを定義する。
　　10.0.1.0/24…パブリックサブネット
　　10.0.2.0/24…プライベートサブネット

このようにサブネットを利用することで、ネットワークごとに役割を与えることができ、管理しやすくなる。

Route Table(ルートテーブル)

ネットワークの経路を設定するコンポーネントです。

サブネット内の通信がどの宛先のネットワークに対して、どのコンポーネント（IGWとかEC2とか）に転送されて欲しいかを設定する。
一つのサブネットに一つのルートテーブルを用意できる、指定がない場合はVPC作成時に自動生成されるメインルートテーブルがサブネットに割り当てられる。

Elastic IP(固定IP)

EC2のインスタンスに対して固定IPを割り当てるコンポーネント。独自ドメインのWebサイトを外部公開する場合などに使用する。

NGW(NATゲートウェイ)

アドレス変換を行うためのコンポーネント。パブリックサブネットに設置し、プライベートサブネットから外部への通信ができるようにNATする時に使用する。

実際のVPC設計例

プライベートサブネットから外部へ通信させたいときはNAT GWをパブリックサブネットに設置。合わせてルートテーブルの設定も行う。

AZ-Aで障害が起きた時のことを考え、AZ-Cに同じ内容でインフラを構築し、冗長構成とする。

4. IAM(Identity and Access Management)

「どのサービス（リソース）に対する」「どのような操作を」「誰に」
許可するか・許可しないかを定義出来る

4-1. IAM を用いてユーザに権限を付与するまでの流れ

操作権限定義
AWSサービスやAWSリソースに対する操作権限を「IAMポリシー」として定義する。

ポリシーのアタッチ
IAMポリシーを「IAMユーザー」や「IAMグループ」にアタッチする。

4-2. IAMポリシー

AWSサービスやAWSリソースに対する操作権限をJSON形式で定義したもの。
IAMポリシーの定義項目は以下のとおり。

項目内容

Version IAMポリシーの文法バージョン（2017年12月現在は「2012-10-17」）

Effect ここで定義するポリシーが許可を与えるポリシー（Allow)か拒否するポリシー（Deny)かを設定

Action 「どのAWSサービス」に対する「どのような操作」を許可(拒否)するかを設定

Resource 「どのAWSリソース」に対する操作を許可(拒否)するかを設定

4-3. IAMポリシー例

EC2リソースの閲覧

EC2インスタンスの開始

EC2インスタンスの停止

上記権限を付与するポリシーは以下
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:Describe*",
                "ec2:StartInstances",
                "ec2:StopInstances*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
Action

Action にEC2関連の全ての参照権限を示す ec2:Describe*
EC2のインスタンスの開始と停止権限の ec2:StartInstances ec2:StopInstances を設定
* を用いることで ec2:Describe* から始まる全ての権限を許可している

Resouce

Resouce に * を設定することで全てのリソースに対して権限を付与している
Resouce に Amazonリソースネーム(ARN) を設定することでAWSリソース個別指定することも可能
ARNは arn:aws:ec2:region:account:instance/instance-id のように指定できる
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:Describe*",
                "ec2:StartInstances",
                "ec2:StopInstances*"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:ec2:region:account:instance/i-xxxxxxxxx",
            "Resource": "arn:aws:ec2:region:account:instance/i-yyyyyyyyy"
        }
    ]
}
Effect

Effect に Allow Deny を設定することで許可 / 拒否を設定できる

4-4. IAMユーザーとIAMグループ

AWSの操作を行うためのユーザーを IAMユーザー と呼ぶ

IAMユーザーは主にマネジメントコンソールにログインする用途で使用される

IAMユーザーにIAMポリシーをアタッチすることで操作権限を付与できる

アクセスキーとシークレットキーのキーペアを払い出しIAMユーザーと同等の権限をプログラムに付与することもできる

IAMグループは同じ権限を付与すしたいIAMユーザーをひとまとめに管理する

IAMグループにIAMポリシーをアタッチすることでIAMユーザーへ一律に権限を付与することができる

4-5. ルートユーザーの扱い

AWSアカウント作成時に設定したアドレスとパスワードでログインできる ルートユーザー　が存在する

ルートユーザーはAWSアカウントに対する全ての操作が可能

更に下記の操作はルートユーザーのみが実行可能

AWSアカウント全体の設定変更（メールアドレス / パスワード変更など）

AWSサポートのプラン変更

EC2からのメール上限緩和申請

逆引きDNS申請

侵入テスト申請

AWSアカウントの停止

Admin権限を付与したIAMユーザーでも上記操作はできない

これらからルートユーザーは日常の開発/運用では使用しない

初めにAdmin権限を付与したIAMユーザーを作成しそのユーザーで作業を行うようにする

AWSアカウントは 二要素認証 をかけ上記のようなルートユーザでしかできない作業以外で使用しない

5. AWSの基礎用語

5-1. AMI(Amazon Machine Image)

AMIとはインスタンスの起動に必要なイメージファイル。
AWSにおいては各種OSのインストールや設定が済んだ状態のものがイメージファイルとして用意され、好きなOSをコピーしてインスタンスを作ることでサーバーとして動かすことができる。

イメージファイル
イメージファイルとはDVDなどのハードディスクに保存されたデータをファイルやフォルダの構造を保ったまま保存、コピーしたデータのこと。
DVDの中身そっくりそのままなので仮想ドライブ(ハードコピーと異なり実体がないので読み込みも仮想のドライブ)で再生が可能。

5-2. AWS CLI(Command Line Interface)

AWS CLIは、AWSのサービスをコマンドラインから操作し、管理するためのツール。
このツールはプラットフォームや開発言語の制限がなく、Linux、Mac、Windowsなど様々なOSで利用可能。

シェルスクリプトと組み合わせることで、AWSの作業を自動化できる点は非常に魅力的。

6. EC２の課金体系

AWS には、コンピューティング、ストレージ、およびデータ転送 (アウト) と
いう、支払い対象となる 3 つの基本的特性があります。

・これらの特性は、使用している AWS 製品に応じてわずかに異なります。
・データ転送 (アウト) は有料ですが、インバウンドデータ転送、または同じリー
ジョン内のその他アマゾンウェブサービス間でのデータ転送は無料。
・アウトバウンドデータ転送は、Amazon EC2、Amazon S3、Amazon RDS、
Amazon SimpleDB、Amazon SQS、Amazon SNS、および Amazon VPC 全体で
集約されてから、アウトバウンドデータ転送の料金が課されます。

7. ストレージのコスト

課金ポイントは3つ

7-1. ストレージ容量

保存容量に対して課金されます。低冗長化ストレージを指定すると2割くらい安くできる。
容量でかいけど殆どアクセスしないものはライフサイクル設定でGlacierに移動しましょう。

7-2. データ転送

課金されるのは(S3からの)送信だけ。受信（S3へのアップロード）は無料。

あとAWSでは同一リージョン内の(AZ非依存な)AWSサービスとの通信は無料です。
例えば同一リージョンのEC2とS3間の通信は送信も受信も無料。
一番高いインターネットへのデータ送信だけと考えておけばよい。

7-3. リクエスト数

S3ではGET/PUT/POST/LIST/COPYなどのリクエスト数に対しての課金もある。

GET は安い（$0.0037/10,000req、OPTION/HEADとかも、全部この料金）
PUT/POST/LIST/COPY は高め（$0.0047/1,000req、GETの12.7倍）
DELETE は無料

例えば1日100万GETされると月に3千万リクエストで課金は$11.1。

7-4. 関連リンク

Amazon S3 料金表
http://aws.amazon.com/jp/s3/pricing/

Amazon Web Services Simple Monthly Calculator
https://calculator.s3.amazonaws.com/calc5.html?lng=ja_JP

8. EC2でインスタンスを作成する

Step.1 AWSにログイン

AWS マネジメントコンソールにてログイン
https://console.aws.amazon.com/

Step.2 EC2のインスタンスを作成する

Amazon EC2 ダッシュボードに移動
https://us-east-2.console.aws.amazon.com/ec2/v2/home

右上の「サポート」の左をクリックしてリージョンを選択する（画面では「オハイオ」）

画面中央の「インスタンスの作成」を選択する

Step.3 インスタンスを設定する

Step 3-1. AMIの選択 - ソフトウェア構成を選択する画面

今回は「Ubuntu18.04」を採用

Step 3-2. インスタンスタイプの選択

仮想サーバーのスペックを選択する画面（今回は「t2.micro」を採用）

「確認と作成」を押すと一気に 3-7. まで飛ばされますが、ここは丁寧に見ていきます。

Step 3-3. インスタンスの詳細の設定

ネットワークを選択。デフォルトで良いならそのまま。
サブネットを選択。ここは「-1a」を選択。（1aはパグリックサブネットです）
自動割り当てパブリックIPは「有効」を選択。(これを有効にしないとインスタンス起動時に接続可能なパブリックIPが割り当てられない)

Step 3-4. ストレージの追加

ストレージのサイズを指定します。初期状態では8GBです。

Step 3-5. タグの追加

ここは必須ではないので、スキップ。

Step 3-6. セキュリティグループの設定

既存の設定を再利用する際には「既存のセキュリティグループ」を選択。今回は「新しいセキュリティグループ」を作成しています。
実際の詳細設定は後ほど実施することにします。

Step 3-7. 確認 - 作成するかの確認画面

確認して「起動」を押下する。

キーペアの作成をするか問われる画面が出てくる。

今回は「新しいキーペアの作成」を行う（既存のキーペアを使用したい場合は「既存のキーペア選択」から選択）

キーペア名を入力し、「キーペアのダウンロード」から.pemファイルのダウンロードを行う
（再度ダウンロードは不可なので大切に）

インスタンスの作成を押したら、画面が切り替わりインスタンス作成中の画面に遷移します
（数分かかります）

Step 3-8. インスタンス一覧へ

Amazon EC2 ダッシュボードに戻り左側の、「インスタンス」を選択。
作成したインスタンスを確認する。

インスタンスを選択した際の詳細情報。

Step 3-9. インスタンス名設定

作成したインスタンスの「Name」欄を編集し、インスタンス名を設定する。
「Name」欄にマウスホバーすると編集アイコンが表示されるので、クリックして編集する。

Step.4 インスタンスへの接続

Tera Term,PuTTy,Xshell等クライアントソフトを使い、先ほどのIPに接続。
ここでは「Secure Shell App」を使用。

Secure Shell App

Secure Shell App - Chrome ウェブストア
https://chrome.google.com/webstore/detail/secure-shell-app/pnhechapfaindjhompbnflcldabbghjo?hl=ja

ChromeのURL欄に「chrome://apps/」を入力
→「Secure Shell App」を選択。

実際の接続

IP : インスタンスの「IPv4 パブリック IP」
User : ubuntu
PORT : 22
「インポート」をクリックして、キーペアの.pemファイルを指定する。

9. S3を使ってみる

サービスから「S3」を入力して検索。

「バケットを作成する」を押下。ここではバケット名「bkt-sampledomain01」を作成

バケット名を入力して、「次へ」

特に設定変更なしで「次へ」

特に設定変更なしで「次へ」

「バケットを作成」を押下

バケットが作成されたことを確認する。

10. S3をマウントしてみる

以下の手順でEC2にS3をマウントしてみます。
1. S3 Bucket の準備　→　上記で済
2. IAMロールの準備
3. IAMロールをEC2インスタンスに割当て
4. s3fs-fuse のインストールと設定
5. マウントの自動化

※ １と２はAWSコンソール画面での操作
※ ３と４はインスタンスにSSH接続してから操作

10.1 IAMロールの準備

IAMサービスを選択

IAMを検索して、

「ロールの作成」を押下

サービス選択

ロールを利用するサービスとして「EC2」を選択→「次のステップ」押下

ポリシー設定

ポリシー名「AmazonS3FullAccess」を選択

タグの追加

そのまま「次のステップ」押下

ロール名設定

ロール名を入力して「ロールの作成」押下

確認

ロール名：access-s3-role

ロールの説明：access to S3 FullAccess を確認する。

10-2. IAMロールをEC2インスタンスに割当て

作成したロールをインスタンスに割り当てる。

EC2のインスタンス一覧で、該当EC2インスタンスの右クリックでメニュー表示。
「インスタンスの設定」→「IAMロールの割り当て/置換」を選択。

作成したIAMロールを選択して、「適用」押下

10-3. s3fs-fuse のインストールと設定

1. gitなど必要なものをインストールする
$ sudo apt-get install automake autotools-dev g++ git libcurl4-gnutls-dev libfuse-dev libssl-dev libxml2-dev make pkg-config
2. s3fsをgitからインストールする
$ git clone https://github.com/s3fs-fuse/s3fs-fuse.git
もろもろの設定（これでs3fsが /usr/local/bin 下におかれる）
$ cd s3fs-fuse
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
3. マウントポイントの作成

※root権限のディレクトリとして作成されるがマウント時にownerを設定するのでOK
$ sudo mkdir /mnt/s3
マウント時のownerのuid, gidを確認する
$ id ubuntu
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),110(lxd)
マウントする：s3fs 「バケット名」「マウント先ディレクトリ」　の書式。
バケット名「bkt-sampledomain01」を指定。マウントディレクトリは「/mnt/s3」を指定。
$ sudo s3fs bkt-sampledomain01 /mnt/s3 -o rw,allow_other,uid=1000,gid=1000,default_acl=public-read,iam_role=access-s3-role
allow_other: root 以外（マウントしたユーザー以外）も利用可能とする。
これでS3のbucketをインスタンスにマウント出来た。
しかし再起動するとマウントは解除されてしまうので、再起動しても自動マウントされるように設定しておく。

10-4. マウントの自動化

インスタンスを再起動しても自動でマウントされるように設定を行う。
/etc/rc.local にマウントコマンドを書き込んでおけば起動時に自動で実行してくれる。
$ sudo vi /etc/rc.local
s3fs bkt-sampledomain01 /mnt/s3 -o rw,allow_other,uid=1000,gid=1000,default_acl=public-read,iam_role=access-s3-role
$ sudo chmod u+x /etc/rc.local 
$ ls -l /etc/rc.local
-rwxr--r-- 1 root root 60 Feb 20 13:25 /etc/rc.local
systemd で管理されていていて、その内容は以下の通り。
$ sudo vi /lib/systemd/system/rc-local.service
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
Documentation=man:systemd-rc-local-generator(8)
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no
これでインスタンスを再起動しても自動でS3のバケットがマウントされる。
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           395M  760K  394M   1% /run
/dev/xvda1       49G   40G  8.5G  83% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/loop1       18M   18M     0 100% /snap/amazon-ssm-agent/1455
/dev/loop0       89M   89M     0 100% /snap/core/7396
/dev/loop2       66M   66M     0 100% /snap/google-cloud-sdk/99
/dev/loop4       90M   90M     0 100% /snap/core/7713
/dev/loop5       66M   66M     0 100% /snap/google-cloud-sdk/100
tmpfs           395M     0  395M   0% /run/user/1000
s3fs            256T     0  256T   0% /mnt/s3
/dev/loop6       18M   18M     0 100% /snap/amazon-ssm-agent/1480
11. AWS CLI を利用する

11.1 AWS CLIを利用するための準備

AWS CLIを利用するシーンとしては下記の2つが考えられる。

自分のPCやAWS以外のサーバーから利用
専用のIAMユーザーを作成し、アクセスキーの発行が必要

EC2のインスタンス上から利用
必要な権限を有したIAMロールを作成し、EC2インスタンスにアタッチする（推奨）またはアクセスキーを利用する

→ EC2インスタンスから利用する方法は2種類ありますが、「IAMロールを作成してインスタンスへ割り当てる方法」が推奨されている。
→ その理由は、アクセスキーが万が一流出した場合、外部から不正利用される可能性があるため。
→ ここではIAMロールをEC2インスタンスへアタッチするやり方で設定を進める。

11.2 AWS CLI のインストール
$ curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
$ sudo python get-pip.py
$ sudo pip install awscli     # インストール
$ sudo pip install -U awscli  # 最新バージョンにアップデート
11.3 コマンド補完を有効に

AWSコンプリータを見つけて、有効にする。
aws_completer　のフルパスを　~/.bash_profileファイルの行末に追加する。
$ find / -name aws_completer 2> /dev/null
/usr/local/bin/aws_completer
$ sudo vi ~/.bash_profile
# ファイルの行末に以下を追記
complete -C '/usr/local/bin/aws_completer' aws
補完の確認
$ aws ec2 describe-i <-ここでtab　下記のように出力される
describe-iam-instance-profile-associations   describe-images                              describe-instance-credit-specifications 
describe-id-format                           describe-import-image-tasks                  describe-instance-status 
describe-identity-id-format                  describe-import-snapshot-tasks               describe-instances 
describe-image-attribute                     describe-instance-attribute                  describe-internet-gateways
12. ファイアウォールの設定

12.1 セキュリティグループとは

AWSのファイアウォール機能の一つ。（他には、後述するACLなどがある）
プロトコル、ポート範囲、送信元／送信先IPアドレスによるパケットフィルターが可能。

インスタンス単位に適用することができる。

セキュリティグループを作って何も設定しなければ何も通信を通さない。
→ 許可したい通信に応じて許可ルールを作成することでそこに穴を開ける。（拒否ルールは設定できない）

12.2 セキュリティグループに関連する基礎用語

インバウンドルール

そのセキュリティグループに関連付けられたインスタンスにアクセスできるトラフィックを規制するルール

アウトバウンドルール

そのセキュリティグループに関連付けられたインスタンスからどの送信先にトラフィックを送信できるか（トラフィックの送信先と送信先ポート）を制御するルール

ステートフル

サーバーがクライアント側アプリケーションの状態(セッション状態)を覚えていること。
セキュリティグループはインバウンド/アウトバウンド通信の際に、「このサーバー(/ポート番号/プロトコル)での通信は許可されているんだな」と覚えているので、それに対するアウトバウンド/インバウンド通信はセキュリティグループで設定がされていなくても許可される。
このように往復のやり取りが必須となる通信において自動的に応答の通信を許可する仕組みを「ステートフル・インスペクション」という。

ステートレス

ステートフルの反対でサーバーがセッション状態を覚えていないこと。
AWSにはセキュリティグループ以外にもネットワークACL(アクセスコントロールリスト)というファイアウォールがあり、こちらはステートレス。そのためインバウンド/アウトバウンド両方の設定が必要。

12.3 セキュリティグループの設定方法

マネジメントコンソールから作成する場合

1.「AWSマネジメントコンソール」に入り、「EC2」を選択する。
2.「セキュリティグループ」を選択→「セキュリティの作成」を選択する

3.セキュリティグループ名をつけ、VPCを選択し、「インバウンド」タブを選択。
「編集」ボタンを押下。

以下は設定例。
①ソース「0.0.0.0/0」は任意のクライアントからアクセス可能。SSHログイン可能にするのは通常は制限すべき。
②８０８０番ポートは「50.100.200.0/24」のネットワークからのみアクセス可能にされている。
③８０番ポートはHTTP(Webサーバ)として利用するので、通常は全通しにする。
④443番ポートはHTTPS(Webサーバ)として利用するので、通常は全通しにする。
⑤3306番ポートはMySQLの標準ポート。通常はポート番号を変更したうえで、特定ホストからのみアクセス可能にする。

マネジメントコンソールからセキュリティグループを割り当てる場合

「AWSマネジメントコンソール」に入り、「EC2」を選択する。

セキュリティグループを追加したいインスタンスを選択して右クリックでメニュー表示。

「ネットワーキング」→「セキュリティグループの変更」を選択する

適用したいセキュリティグループを選択する

AWS CLIから設定する場合

セキュリティグループの作成

$ aws ec2 create-security-group --description ＜value＞ --group-name ＜value＞ [--vpc-id ][--dry-run | --no-dry-run][--cli-input-json ][--generate-cli-skeleton ]

セキュリティグループの確認

$ aws ec2 describe-security-groups --group-id ＜value＞

セキュリティグループのルール追加

インバウンドのSSHポート22を開けるとき

$ aws ec2 authorize-security-group-ingress --group-id ＜value＞ --protocol tcp --port 22 --cidr 0.0.0.0/0

12.4 ACL

ネットワークアクセスコントロールリストの略。
セキュリティグループとの違いは
・サブネットレベルで動作する
・ルールの許可と拒否設定が可能である
・ステートレスである

項目	クラウド	オンプレ
準備期間	◎　即時利用可能	△　初期契約/設定に時間かかる
初期費用	◎　なし	△　初期費用が必要な場合もある
維持費用	◯　従量課金(上限設定可能)	◯　基本固定　&　追加費用
障害対	◎　クラウド事業者が対応	△　原則自社対応
セキュリティ	◎　クラウド事業者が対応	◯　原則自社対応で強化できる
カスタマイズ	△　設定変更&連携で対応	◎　柔軟にカスタマイズできる

コード	名前
ap-east-1	アジアパシフィック (香港)
ap-northeast-1	アジアパシフィック (東京)
ap-northeast-2	アジアパシフィック (ソウル)
ap-northeast-3	アジアパシフィック (大阪)
ap-southeast-1	アジアパシフィック (シンガポール)
ap-southeast-2	アジアパシフィック (シドニー)
ap-south-1	アジアパシフィック (ムンバイ)
me-south-1	中東 (バーレーン)

項目	内容
Version	IAMポリシーの文法バージョン（2017年12月現在は「2012-10-17」）
Effect	ここで定義するポリシーが許可を与えるポリシー（Allow)か拒否するポリシー（Deny)かを設定
Action	「どのAWSサービス」に対する「どのような操作」を許可(拒否)するかを設定
Resource	「どのAWSリソース」に対する操作を許可(拒否)するかを設定

　 Tweet
Qiitaで続きを読む