プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

独自ドメインで、メールとhttps化したWebサイトを別サーバーで運用する (2/2)

blog.mori-soft.com

の続きです。 ここから、https でアクセス可能なWebサイトの公開のための作業になります。

Amazon Certificate Manager によるSSL証明書の取得

ドメイン所有者宛てに送られるメールを受け取れるようになったので、SSL証明書の申請を行います。 SSL証明書は、リージョン毎に作成されるようです。

ただし、CloudFront で使用できる証明書は us-east-1 のリージョンのもののみなので、このリージョンに対して証明書の申請をすることに注意してください。

詳しくは、

よくある質問 - AWS Certificate Manager(簡単に SSL/TLS 証明書を作成、管理、配置) | AWS

にある『Q: 複数の AWS リージョンで同じ証明書を使用できますか?』に記載されています。

AWSのコンソールにログインして、Certificate Manager を開きます。 リージョンとして、us-east-1 (米国東部(バージニア北部))を選択します。 『証明書のリクエスト』を押します。

f:id:junichim:20170915102906p:plain

ドメイン名を入力する欄があるので、今回使用する独自ドメイン名を入力します(Zone Apexとして入力します)。 ワイルドカード証明書も取ることができるので、『この証明書に別の名前を追加』ボタンを押して、サブドメインのワイルドカード証明書も申請しておきます(今回の目的には不要なのですが、別件で使うかもしれないので)。

f:id:junichim:20170915103130p:plain

ちなみに、ワイルドカード証明書だけでは、Zone Apex はカバーされないのでご注意ください。

次に進むと確認画面が表示されます。

f:id:junichim:20170915103547p:plain

ここで、『確定とリクエスト』を押すと、ドメイン所有者に対してメールによる確認が行われます。

f:id:junichim:20170915104222p:plain

メール記載のリンクをクリックして、表示される確認内容に問題がなければ、承認します。 承認後、コンソールの画面に戻り『続行』と押すと、問題なければ、証明書一覧の画面が表示され、ステータスが『発行済み』となります。

f:id:junichim:20170915104848p:plain

こんな感じになってれば、証明書が発行できてます。

S3のホスティング

さて、いよいよホスティングするS3の設定をします。

まずは、バケットを作成します。S3で独自ドメインを割り当てる場合は、サブドメインでもZone Apexでもバケット名をそのドメインの形式にする必要があります。

例えば、独自ドメイン名が example.com なら、バケット名も example.com になります。

また、S3でホスティングする場合、誰でも見れる必要があるため、アクセス許可(アクセスコントロールリストやバケットポリシー)を追加しますが、今回は、CloudFront経由でのアクセスのみに制限するので、現時点では、アクセス許可はデフォルトのままとします(パブリックアクセス許可を与えません)。

なので、この時点ではブラウザで確認できないのでご注意ください。

表示するためのファイルをindex.htmlとしてアップロードしておきます。

Hello WOrld!

公開するバケットの『プロパティ』『Static website hosting』を選択して

f:id:junichim:20170915110643p:plain

設定画面で、

f:id:junichim:20170915110934p:plain

『このバケットを使用してウェブサイトをホストする』を選んでおきます。

CloudFront の設定

S3の設定ができたら、CloudFrontでディストリビューションを作成します。

設定内容としては、httpsでのアクセス(httpはhttpsにリダイレクト)とし、必ずCloudFront経由でS3にアクセスするようにしています。

デフォルトの設定値と異なる箇所を以下に示します。

  • Origin Domain Name : S3のバケット名を選択
  • Restrict Bucket Access : Yes
  • Origin Access Identity : Create a New Identity
  • Grant Read Permissions on Bucket : Yes, Update Bucket Policy
  • Viewer Protocol Policy : Redirect HTTP to HTTPS
  • Alternate Domain Names : 独自ドメイン名
  • Default Root Object : index.html

なぜか、この時点で SSL Certificate として Custom SSL Certificate を選択できなかったので、一旦このままディストリビューションを作成します。

なお、CloudFront経由でS3にアクセスする方法については

blog.mori-soft.com

に記載があるので、ご参考にしてください。

Route53 の設定

独自ドメインに対して Alias レコードを設定します。

f:id:junichim:20170915111507p:plain

レコードタイプとして Aレコードを選択して、AliasをYesにします。

Alias Target として、CloudFront のアドレスを選択します。

CloudFront で証明書を指定

最後に、CloudFrontのディストリビューションを再度開き、『General』タブで『Edit』を行います。

f:id:junichim:20170915111932p:plain

SSL Certificate として Custom SSL Certificate を選択し、その下のドロップダウンリストからACMで取得した証明書を選択します。

これで設定完了です。

確認

さて、ブラウザでアクセスしてみましょう。

f:id:junichim:20170915112319p:plain

httpsでアクセスしてもちゃんと表示されています。 ちなみに、http//独自ドメイン/ でアクセスしても表示されます。

さいごに

設定は非常に楽しかったのですが、実際の料金がどれぐらいになるかはちょっと気になるところです。

Route53, CloudFront, S3

でそれぞれ費用が発生するので、アクセス数次第では結構いいお値段になるかもしれません(まあ、そうなったらうれしくもあるんですが)。

これについては、載せたい内容が固まって、本格的にリリースできてから改めて検証したいと思います。

参考

メールの部分以外はこちらを参考にしました。

qiita.com

独自ドメインで、メールとhttps化したWebサイトを別サーバーで運用する (1/2)

独自ドメインで運用するけれども、更新が頻繁にない静的サイトなら、S3でホスティングして費用を抑えられないかな?と考えています。

おまけに、AWSの場合、無料でSSLを利用することができるとのことです(Amazon Certificate Manager (ACM))。もっとも、AWSのサービスで使う用途に限られますけどね。 これをS3で使う場合は、CloudFront経由で設定することで、SSLを無料で利用することができます。

で、Webサイトはこれでいいとしても、独自ドメインのメールサーバーどうしようかというところが悩ましいところです。 個人的には、メールサーバーの運用なんてしたくないので、 メールはさくらインターネットのメールボックスを利用したらいいんじゃないのか?と思い立ちました。 値段も、月額約86円(年1029円)で、比較的お安く運用できそうですしね。

ちなみに、最初は、そんなにアクセス数がない静的サイトであれば、同じくさくらインターネットのレンタルサーバーのライトプラン(月額129円)でもいいかと考えました。 でも、SSLに対応しようとすると、自分でSSL証明書を用意して云々で費用的にもかさむし、RapidSSLがChromeで対応されなくなるという話も気になるので、AWSを使おうと思った次第です。

今回設定した作業をメモ書きとしてまとめておきます。

構成

さて、今回試した構成をまとめると、

  • ドメイン取得:さくらインターネット
  • ネームサーバー:Route53
  • メールサーバー:さくらのメールボックス
  • Webサイト:CloudFront+S3のホスティング
  • SSL証明書:ACM

という感じになりました。

設定の流れとしては、ACM での SSL証明書の発行には独自ドメインのメールアドレスが必要なので、

  1. ドメインを取得する
  2. メールサーバーで独自ドメインのメールの送受信ができるようにする
  3. S3でホスティングする
  4. CloudFront を設定する
  5. ACM で取得したSSL証明書を設定する
  6. https でアクセスできることを確認する

という流れです。Route53は適宜設定していきます。

ドメインの取得

独自ドメインは、どこでとってもいいかと思います。 今回は、たまたま既にさくらインターネットで取得したものがあったのでそれを使いました。

なお、試しで使った際に、ネームサーバー(さくらのネームサーバー)を設定していたので、一旦削除しておきます。

f:id:junichim:20170915090618p:plain

削除方法は、『会員メニュー』にログインして、ドメインメニューを開いて、対象とするドメインの『ゾーン編集』ボタンを押すと現在の設定内容が出てくるので、 左側のカラムにある『削除』ボタンから設定内容を削除しておきます。

さくらのメールボックスの契約

次に、さくらインターネットのメールボックスを契約します。 月額約86円(年額1029円)で運用できるのはありがたいですね。

とりあえず、取得したドメイン名(さくらインターネットのサブドメイン名、xxxx.sakura.ne.jp のやつです)でメールの送受信ができることを確認しておきます。

独自ドメインを Route53 で管理

S3でのホスティング時に、Zone Apex(サブドメインのないドメイン、 example.com のようなやつ。ネイキッドドメインなどとも呼ばれるようです)でのアクセスを行う場合、ドメインは Route53 で管理されている必要があります。

少し横道にそれますが、この理由について考えてみます。この理由の直接的な記述を見つけることができなかったのですが、『例: 独自ドメインを使用して静的ウェブサイトをセットアップする』にあるように、S3での公開名に対して独自ドメインでアクセスするためにCNAMEレコードが必要になり、Zone Apex に対してはCNAMEレコードを追加できないため、Route53独自のレコードであるAliasレコードを使う必要がある、ということだと思います。 いやはや、DNSまわりはややこしいですねー。

S3でのホスティングをサブドメインで行うなら、このステップはなくても大丈夫です。 (上記の理由の裏返しで、サブドメインにならCNAMEレコードを設定が可能なので、ドメインを取得した会社のネームサーバーでCNAMEレコードの編集ができるなら、Route53でなくてもOKです)

具体的な移行方法は次の記事を参考にしました。

既存ドメインの DNS サービスを Amazon Route 53 に移行する - Amazon Route 53

ホストゾーンの作成

AWSのコンソールにログインし、Route53を選んで、Create Hosted Zone を選択します。

f:id:junichim:20170915093948p:plain

管理するドメイン名を入力します。

f:id:junichim:20170915094120p:plain

コメント欄は空欄で大丈夫です。

問題なければ、このようにNSレコードとSOAレコードが登録された状態になります。

f:id:junichim:20170915094214p:plain

レコードセットの作成

次に、Route53にレコードを追加します。追加するのは、MXレコードとTXT(SPF)レコードです。

Create Record Set ボタンを押して、レコードセットを作成します。

まずはMXレコード

f:id:junichim:20170915094411p:plain

MXレコードが指すメールサーバーは、さくらのメールボックスのサーバー名です(xxxx.sakura.ne.jp のやつ)。

次に、TXT(SPFレコード)です。

f:id:junichim:20170915094457p:plain

SPFレコードの内容は

v=spf1 a:wwwxxxx.sakura.ne.jp ~all

としています。ここで、a: のうしろのホスト名としては、さくらインターネットのメールボックスのサーバー名を指定します。 コントロールパネルから『サーバー情報』を表示させると

f:id:junichim:20170915094841p:plain

のようにホスト名が表示されるので、これを使います。

参考

なお、ホストゾーンへのMXレコードとSPFレコードの追加は、以下のサイトを参考にしました。

他社で取得したドメインでさくらのメールボックスを利用する | HappyQuality

独自ドメインのメールアドレスをさくらレンタルサーバーのメールボックスで取得しました。 - estomo Blog

メールボックスに独自ドメインを割り当て

契約したメールボックスのコントロールパネルにログインして作業を行います。

コントロールパネルの『ドメイン設定』を開き、『新しいドメインの追加』を選択します。 いくつか選択肢が表示されますので、 『5. 他社で取得したドメインを移管せずに使う』を選びます。

f:id:junichim:20170915095228p:plain

表示された画面で、ドメイン名を入力します。

f:id:junichim:20170915095333p:plain

問題なく、追加できていれば、下記の様な画面になります。

f:id:junichim:20170915114811p:plain

参考

なお、『詳細設定にすすむ』は行わなくても問題ありませんが、仮にリンクをクリックすると

f:id:junichim:20170915114937p:plain

のようにSPFレコードの設定確認がでてきます。 ここまで行うと、(さくらインターネット側で)追加したドメインのゾーン情報が作成され、 そのDNSレコードが

f:id:junichim:20170915100240p:plain

のように設定されます。 これらは、次のネームサーバーの切り替えにより、参照されなくなるのですがご参考までに。

あと、今回は試さなかったのですが独自ドメインの割り当ての際『2. さくらインターネットで取得したドメインを使う』を選んでも同じだったかなと思ってます。

f:id:junichim:20170915100839p:plain

次に類似の設定を行う機会があれば、試そうと思います。

ネームサーバーを Route53 に切り替え

今回の独自ドメインは、さくらインターネットで取得しているので、ネームサーバーをRoute53に切り替えます。

『会員メニュー』の『ドメインメニュー』から対象とする独自ドメインの『WHOIS情報』のボタンを押します。

f:id:junichim:20170915101238p:plain

画面の下のほうに、ネームサーバー1~4を記入しているところがあるので、

f:id:junichim:20170915101323p:plain

『変更』ボタンを押します。

編集状態になったら、Route53でホストゾーンを作成した際のNSレコードに記載されているサーバー名を4つとも入力します。

f:id:junichim:20170915101535p:plain

この値ですね。

参考

ここの作業では、下記を参考にさせていただきました。

Amazon Route 53と独自ドメインでさくらのレンタルサーバを利用する方法 | Lancork

既存ドメインの DNS サービスを Amazon Route 53 に移行する - Amazon Route 53

メールの送受信テスト

さて、しばらく待ってから、まずはSPFレコードが正しく設定されているか確認します。

SPF Query Tool

上記のサイトを利用して確認します。問題なければ、独自ドメインを使って、メールの送受信ができるかテストしておきます。

問題なければ、ここまでで一段落です。 次は、S3によるホスティングとhttpsでのアクセスのための設定になります。

Cognito ユーザープール使ってみました

以前の書籍を読んだ記事にも書きましたが、その書籍中では Cognito を使いましたが、ユーザープール (User Pools)については紹介だけで、チュートリアルはありませんでした。

blog.mori-soft.com

このユーザープールが気になり、簡単なサンプルを作って試してみましたので、メモにまとめておきます。

Cognito ユーザープールとフェデレーティッドアイデンティティの関係について

最初、ドキュメントを呼んでも、すっきりしなかったので、不正確かもしれませんが、自分なりに理解したユーザープールとフェデレーティッドアイデンティティの関係についてを書いておきます。

Cognito のドキュメントを読むと、ユーザープールは、独自で認証を実装するときの Users テーブルのようなものだとわかります(ディレクトリサービスといったほうがいいのかな)。 ユーザーの登録・管理・認証を提供してくれるサービスというところですかね。

もちろん、ユーザープール単独でも使えるのですが、Cognito フェデレーティッドアイデンティティ (Federated Identities) とつなげることで、

  1. ユーザープールで認証
  2. フェデレーティッドアイデンティティ で AWS アクセス用のロールを割り当て
  3. 割り当てられたロールを使って、AWSのサービスへのアクセスを行う

ということが可能になるようです。

で、わかりにくかったのが、このフェデレーティッドアイデンティティ との連携というところです。

最初の自分の理解だと、フェデレーティッドアイデンティティというと外部のIDプロバイダ(facebookやGoogle+)を利用するためのサービスだと、捉えていました。 でもこれって、外部のIDプロバイダだけじゃなくて、Cognito ユーザープールをIDプロバイダとして利用することができるようです。 そのあたりが分かると話がしっくりきます (あらためてドキュメントを読んでみると、Cognito User Poolsも使えるよとしっかり書ていますね)。

また、フェデレーティッドアイデンティティを利用するためには、 Identity Pools (IDプールとも書かれてます)を作成する必要があります。 ここでも、『プール』、というキーワードが出てくるので、ややこしく感じますね。前述のユーザープールとは別物ですので、気を付けましょう。

このIDプールは、ユーザープールを含むIDプロバイダのアカウントに対して紐づけられる、Identity ID を管理するためのものです。この Identity ID に対してawsのロールを割り当てることになります。 こうすることで、IDプロバイダのアカウントを直接扱わなくても、認証したユーザーを一意に特定・管理できるということのようです。

ネットの記事によっては、ユーザープールの利用という話題について、フェデレーティッドアイデンティティを使う、という表現ではなく、Identithi Pool を使う、とのみ書いている場合があります。 どちらの表現でも、やってることは同じなので、わかってしまえば問題ないのですが、よくわからないうちだと、2種類の用語が出てくるけど、どう違うんだ?となってました。ご参考までに。

Cognito ユーザープール と Identity Pools の作成

上記の関係性さえわかれば、ユーザープルおよび Identity Pools の作成は、今回のようなサンプルだとたいして難しくありません。

ユーザープールの作成と Identity Pools の作成は、下記記事などを参考にしました。

Amazon Cognito User Poolsを使って、webサイトにユーザ認証基盤を作る - Qiita

Cognito User Pools x ログイン認証 x API認証 - Qiita

ユーザープール作成時の注意点としては、『アプリクライアント』を追加する際に、『クライアントシークレットを生成する』のチェックボックスを外すことを忘れないでください(JavaScriptからはクライアントシークレットが利用できないためです)。こちらのドキュメントもご参考に。

ブラウザでの動作サンプル

Identity Pool の作成まで問題なく終われば、コンソールでの作業は終わりです。 次は、ブラウザから、Cognito ユーザープールを利用するサンプルを作ります。

JavaScript からCognito の機能を使うためには、

  • aws-cognito-sdk.js
  • amazon-cognito-identity.js

の2つのSDKが必要です。下記のGitHubページからダウンロードできます。

github.com

とりあえずローカルにダウンロードして、それを指定します(このサンプルを試した時点では v1.19 でした)。

また、ログイン時のサンプルでは、AWS SDK for JavaScript も必要になります。 このGitHubのページにあるように、scriptタグで指定すればOKです。

ダウンロード版がよければ、こちらのページからデフォルトビルドのダウンロードなどを選択すれば、ダウンロードページに行けます。

サンプルコードの動かし方

なお、参考までに、以下で載せているサンプルをGitHubにあげておきましたので、もし興味があればご参考にしてください。

github.com

ローカルで動作させます。サーバーはpythonを利用しています。 (インターネット上のサーバー上が良ければ、S3などで適当にホスティングしてください。)

./run.sh

なお、動作環境は、

  • Windows 10 Pro, 1703, 64bit
  • Bash on Ubuntu on Windows, 16.04.2 LTS

です。

サインアップ

サインアップ用ページはこんな感じにしました。

f:id:junichim:20170906160027p:plain

コードはこんな感じですね(app.jsというファイルにまとめて書いてます)。

'use strict'
var upsample = {};

upsample.poolData = {
    UserPoolId: 'ユーザープールのID',
    ClientId: 'アプリクライアントのID'
};
upsample.UserPool = new AWSCognito.CognitoIdentityServiceProvider.CognitoUserPool(upsample.poolData);

upsample.signup = function() {
    var email = $('#inputEmail').val();
    var username = $('#inputUserName').val();
    var password = $('#inputPassword').val();
    if (!email | !username | !password) { return false; }

    var attributeEmail = new AWSCognito.CognitoIdentityServiceProvider.CognitoUserAttribute({Name: 'email', Value: email});
    var attributeList = [];
    attributeList.push(attributeEmail);

    var message_text;
    upsample.UserPool.signUp(username, password, attributeList, null, function(err, result){
        if (err) {
            console.log(err);
            message_text = err;
        } else {
            var cognitoUser = result.user;
            console.log('user name is ' + cognitoUser.getUsername());

            message_text = cognitoUser.getUsername() + ' が作成されました';
        }
        $('#message').text(message_text);
        $('#message').show();
    });
}

ユーザープールを設定した際に、デフォルト設定のままだと、e-mail のみが必須入力となっているので、ユーザー名、パスワード、メールアドレスを指定しています。

サインアップの確認

画面はこんな感じ。

f:id:junichim:20170906143428p:plain

コードはこちら。

upsample.verify = function() {
    var username = $('#inputUserName').val();
    var vericode = $('#inputVerificationCode').val();
    if (!username | !vericode) { return false; }

    var userData = {
        Username: username,
        Pool: upsample.UserPool
    };

    var message_text;
    var cognitoUser = new AWSCognito.CognitoIdentityServiceProvider.CognitoUser(userData);
    cognitoUser.confirmRegistration(vericode, true, function(err, result) {
        if (err) {
            console.log(err);
            message_text = err;
            $('#message').text(message_text);
            $('#message').append($('再送信')); // 再送信リンクの表示
        } else {
            console.log('call result ' + result);

            message_text = cognitoUser.getUsername() + ' が確認されました';
            $('#message').text(message_text);
        }
        $('#message').show();
    });
}

サインアップページからサインアップの確認ページが表示されないのはご愛敬にしてください。

ログイン

ログインページはこんな感じです。

f:id:junichim:20170906143623p:plain

コードはこんな感じ。

upsample.login = function() {
    var username = $('#inputUserName').val();
    var password = $('#inputPassword').val();
    if (!username | !password) { return false; }

    var authenticationData = {
        Username: username,
        Password: password
    };
    var authenticationDetails = new AWSCognito.CognitoIdentityServiceProvider.AuthenticationDetails(authenticationData);

    var userData = {
        Username: username,
        Pool: upsample.UserPool
    };

    var message_text;
    var cognitoUser = new AWSCognito.CognitoIdentityServiceProvider.CognitoUser(userData);
    cognitoUser.authenticateUser(authenticationDetails, {
        onSuccess: function(result) {
            console.log('access token + ' + result.getAccessToken().getJwtToken());

            AWS.config.region = 'ap-northeast-1';
            AWS.config.credentials = new AWS.CognitoIdentityCredentials({
                IdentityPoolId: 'Identity Pool の ID',
                Logins: {
                    'cognito-idp.リージョン名.amazonaws.com/ユーザープールID': result.getIdToken().getJwtToken()
                }
            });
            
            AWS.config.credentials.refresh(function(err) {
                if (err) {
                    console.log(err);
                } else {
                    console.log("success");
                    console.log("id:" + AWS.config.credentials.identityId);                    
                }

                $(location).attr('href', 'mypage.html');
            });
            //console.log("id:" + AWS.config.credentials.identityId);
            
            //$(location).attr('href', 'mypage.html');
        },

        onFailure: function(err) {
            alert(err);
        }
    });

}

もし、ログイン後、AWSのサービスにアクセスするなど、Identity ID が必要になるならばここでidentityIDを取得することができます。 上記のサンプルだと、コンソールに出力してみて確認しているだけですが。

AWS のコンソールから確認すると、

f:id:junichim:20170906145936p:plain

のように、IDがちゃんと割り当てられているのが分かります。

マイページ

ログインに成功するとマイページが表示されます。

f:id:junichim:20170906143939p:plain

コードはこんな感じ。 現在のユーザーとセッションを確認して、セッションが有効であれば、ユーザー情報を表示しています。

upsample.checkSession = function () {

    var cognitoUser = upsample.UserPool.getCurrentUser();
    if (cognitoUser != null) {
        cognitoUser.getSession(function (err, sessionResult) {
            if (sessionResult) {
                var attrs;
                cognitoUser.getUserAttributes(function (err, attrs) {
                    if (err) {
                        console.log(err);
                        return;
                    }
                    $('#username').text('Username:' + cognitoUser.getUsername());

                    for (var i = 0; i < attrs.length; i++) {
                        console.log('name:' + attrs[i].getName() + ", value: " + attrs[i].getValue() );
                        if (attrs[i].getName() == 'email') {
                            $('#email').text('Email: ' + attrs[i].getValue());
                        }
                    }
                });
            } else {
                console.log("session is invalid");
                $(location).attr('href', 'login.html');
            }

        });
    } else {
        console.log("no user");
        $(location).attr('href', 'login.html');
    }
}

ログアウト

upsample.logout = function() {

    var cognitoUser = upsample.UserPool.getCurrentUser();
    if (cognitoUser != null) {
        cognitoUser.signOut();
        location.reload();
    }

}

その他

実は、ログイン後、 Identity ID を取得するところでずいぶんはまりました。ようは、refreshメソッドを呼び出す必要があったんですが、それに気づかなかったのです。 ドキュメントのサンプルを見ると、ちゃんと書いてました。

きちんと読むべきですね。

あと、Identity ID (フェデレーティッドアイデンティティの Identity Pools の Identity ID)をコンソールで削除後、再度ブラウザからアクセスすると、『リソースがない』という旨のエラーで落ちることがありました。 調べてみると、 Cognito はlocalstorageを使っているようで、そのキャッシュが残っている関係で落ちるそうです。

stackoverflow.com

とりあえず、ブラウザの履歴を削除して、再度アクセスすると問題なく動作しました。

ただこの場合、Identity ID の値は、削除前の値から変更されています。なので、Identity ID を削除する必要があり、かつ、新旧のマッチを取る必要がある場合は、自分でなんとかしないといけなさそうですので、気を付けましょう。

参考

Cognito, Lambda, API Gateway のサンプル。Reactで作ってるので、React分かる人にはよいかも。

Cognito User Pools x ログイン認証 x API認証 - Qiita

Cognito利用時のログインの流れの図がわかりやすい

[ Serverless ] Cognito、S3、Lambdaで認証機能付きのWebサイトを作ってみました - Qiita

コード全般は下記記事を参考にしました。

AWS SDK for JavaScriptを使ってブラウザーからCognito User Poolsへサインアップしてみた | Developers.IO

AWS SDK for JavaScriptでCognito User Poolsを使ったログイン画面を作ってみた | Developers.IO