バケット作成

マネージメントコンソールからS3を選択し、バケットの作成を押下する。
※一意のバケット名にする必要がある

静的ウェブホスティングに設定

作成したバケットを選択し、プロパティタブから一番下の「静的ウェブホスティング」を編集する。
「有効にする」「静的ウェブサイトをホストする」を選択し、変更を保存する。

アクセス許可設定

アクセス許可タブを押下し、「パブリックアクセスをすべてブロック」の☑を外し、「現在の設定により、このバケットとバケット内のオブジェクトが公開される可能性があることを承認します」に☑を入れる。

バケットポリシーの欄にJSON形式で記述する。
今回の例ではSourceIPが27.142.108.157以外からは、バケット名「test-20210403」に対してS3に関するアクションを全て拒否するという内容。

{
    "Version": "2012-10-17",
    "Id": "SourceIP",
    "Statement": [
        {
            "Sid": "SourceIP",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::test-20210403",
                "arn:aws:s3:::test-20210403/*"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": "27.142.108.157/32"
                }
            }
        }
    ]
}

はじめに

この記事では
AWS Amplify を利用して React を実行してみたハンズオンの記事です。
ベストプラクティスや間違いがあれば
書き直していく予定です。

AWS Amplify とは

ウェブアプリケーションを素早く構築してくれる AWS のサービス
数多くの言語がサポートされている。

Amplify では、一般的なウェブフレームワーク (JavaScript、React、Angular、Vue、Next.js) や
モバイルプラットフォーム (Android、iOS、React Native、Ionic、Flutter) がサポートされています。
AWS Amplify で迅速な市場投入を実現してください。

最近、SPA 化が流行り出したこともあって
脚光を浴びているサービスに見えなくもないので実際どんなもんか
今回はハンズオンしてみた。

結論

めっちゃ使いやすい！！

「嘘でしょ！？」ってくらい簡単にできてしまったのでハンズオンした記録を残しておきたい。

参考にしたページ

モジュール 1

モジュール 2

モジュール 1 をハンズオン

React レポジトリを作成

AWS Amplify で利用するレポジトリを GitHub から取得する為
GitHub に push する用のアプリケーションを作成する。

create-react-app amplifyapp

ディレクトリをチェンジして
ローカルホストで動作確認を行う。

cd amplifyapp
yarn start

しばらくすると、ぬるぬる動く React おなじみの絵が表示される。

React レポジトリを GitHub に push

動作確認が終わったら一旦、アプリケーションを止める。

git init
git add .
git commit -m "initial commit"
git branch -M main
git remote add origin git@github.com:username/amplifyapp.git
git push -u origin main

※username には自分の GitHub アカウント ID を利用

AWS Amplify 開く

GET STARTED をクリックするとスクロールが下に案内される。

Develop と Deliver の 2 つがあるので「Host your web app」の「GET STARTED」をクリック

Host your web app

ホストするアプリケーションを Github から取得する為
「GitHub」を選択

GitHub 認証済みだと以下のようになるが、まだ認証していない人は
ユーザ名とパスワードが聞かれ、アプリケーションを認証するかどうか聞かれます。

ホストするレポジトリ名とブランチ名を選択肢して「次へ」

ビルド設定の構成

これはとりあえずデフォルトでヨシッ。

迷わずに「次へ」

保存してデプロイ

保存してデプロイ

「保存してデプロイ」をクリックすると。。。

プロビジョニング、ビルド、デプロイ、検証というプロセスを踏んで
デプロイ作業が始まる。

デプロイが終わると Amplify が生成した URL から
作成したアプリケーションを実行できる。

AWS Amplify の凄いところ

手軽さに尽きる。
お手元のアプリケーションをサッとデプロイすることで
あとは良しなにやってくれる。

そして、デプロイに成功したアプリ群はすべてのアプリから一覧で見ることができる。
今まで作ったアプリを容易に管理できるってわけ。

さらに、チョット人に見せる程度の用途なら
インフラストラクチャの構築がいらないのは凄い。
※厳密にいえば、AWS Amplify が良しなにやってくれてる。

GitHub との連携も効いているので CircleCI とも疎結合に連携できる。

何でもかんでも出来すぎて。。。出木杉君になったわ。

でも、お高いんでしょ？

お値段はこちら
https://aws.amazon.com/jp/amplify/pricing/

2021/04/03(土) 現在では

Amplify フレームワーク
Amplify フレームワーク (ライブラリ、CLI、UI コンポーネント) を使用する場合は
基盤として使用する AWS のサービスに対してのみお支払いいただきます。
Amplify フレームワークの使用には、追加料金は発生しません。

静的ウェブホスティング
AWS Amplify コンソールでは、2 つの機能に対して料金が設定されています。
ビルド & デプロイ、およびホスティングです。
ビルド & デプロイ機能の場合、ビルド分あたりの料金は 0.01USD です。
ホスティング機能の場合、対象の GB ごとの料金 0.01USD と保存された GB ごとの価格は 0.01USD です。

AWS 無料利用枠を使用すると、無料で使い始めることができます。
サインアップすると、新規の AWS 顧客はビルドとデプロイ機能で 1 か月あたり 1,000 ビルド分、
ホスティング機能で 1 か月あたり 15 GB の提供**と 1 か月あたり **5 GB のデータストレージを受け取ります。

つまりどういうことか

• Amplify フレームワーク とやらを利用すると料金が発生
• ビルドアンドデプロイするとビルド分だけ料金が発生
• 静的ウェブホスティングはGB分だけ料金が発生
• 無料利用枠ならイイ感じに施しを受けられる

おや？これはポートフォリオの公開にうってつけでは？

まとめ

今回は AWS Amplify を使って React アプリケーションをデプロイしました。
使い方を変えればノーコードアプリケーションもデプロイできるんかなこれ。
だとしたら結構優れものだぞ。

おわり

デバイスに接続されたセンサーからのデータをAWS DynamoDBに保存するとき、MQTTでデータを受け取ってDynamoDBに記録する部分を紹介します。

この方法では、デバイスからはJSONで送りさえすれば、JSONのキーごとにバラしてDynamoDBに記録できます。デバイスに埋め込むプログラム側でキーを自由に決められるため、データ確認には便利です。

JSON

{
    "key1": "value1",
    "key2": "value2",
    ...
}

なお、AWSアカウントは開設済みで、AWSコンソールには AdministratorAccess のポリシーがアタッチされたIAMユーザでログインしていることが前提です。

DynamoDBテーブルの作成

センサデータを記録するための DynamoDB テーブルを作成します。

1. DynamoDB コンソール を開き、Create Table をクリックする。

2. Create DynamoDB table において：

   a. Table name を dht22_ddb_table と付ける。
   b. Primary key は次のように入力する。

   • Partition key に device_id と入力し、右側のリストから Stringを選ぶ。
   • Add sort key にチェックの上で server_timestamp と入力し、右側のリストから Number を選ぶ。

   c. ページの最下部の Create をクリックする。

IoT ルールの作成

パブリッシュされたメッセージをキーごとに分解して、DynamoDBテーブルの各列に記録できるようにします。

1. AWS Iot コンソールで、Act > Rules を選ぶ。
2. Create をクリックする。
3. Name をdht22_ddb_rule と付ける。

4. Rule query statement において、以下のように入力する。

   SELECT '01'       as device_id
        ,timestamp() as server_timestamp
        ,*
   FROM 'esp32/pub'
   

JSONのキーを使ってSQLを組み立てています。Partition key の device_id は、ここでは固定値にします。Sort key には、タイムスタンプを取得します。*の部分がJSONのキーを表していますが、次のアクションの指定により、バラしてDynamoDBに記録してくれます。

1. Set one or more actions において、Add action をクリックし、Split message into multiple columns of a DynamoDB table (DynamoDBv2) を選ぶ。

2. Configure action をクリックする。

3. Table name で、先ほど作成した dht22_ddb_table を選ぶ。

4. Choose or create a role to grant AWS IoT access to perform this action において、Create role を選ぶ。

5. Create a new role の画面で、Name を dht22_ddb_role と付けて、Create role をクリックする。

6. Add action をクリックする。

7. Create rule をクリックする。

MQTT test client でのテスト

試しに esp32/pub にパブリッシュして、DynamoDB に記録できることを確認します。

1. AWS Iot コンソールで、Test を選ぶ。
2. Topic name に esp32/pub と入力する。

3. Message payload は、デフォルトのまま：

   {
     "message": "Hello from AWS IoT console"
   }
   

   にして、Publish をクリックする。

4. DynamoDB コンソール を開き、Tables を選ぶ。

5. dht22_ddb_table を選び、Items タブで "message" カラムに "Hello from AWS IoT console" が記録されていることが確認できる。

参考

• DynamoDB テーブルにデバイスデータを保存する
• AWS IoT 開発者ガイド - DynamoDBv2

はじめに

Redshiftにも他のDBMSと同様、統計情報を取得するためのAnalyzeコマンドがある。
ただ、AWSさんの「運用機能を可能な限り自動化し、開発者が本来注力すべき業務処理に注力できるように」との思いによって各種機能が年々Auto化（個人的には分散キーのAuto化が最後の砦だと思っていたので、去年のre:Inventはインパクトが大きかった）されたことで、Analyzeコマンドを発行する機会は減ってきていると思われる。
本記事では2021/4現在における自動で発行されるAnalyzeを整理するとともに、Analyzeを手動で発行した方がよいケースについて個人的な見解を整理する。

実機環境

リージョン：東京
インスタンス：dc2.large × 1ノード
※Redshiftのバージョンは2021/4/3時点での最新バージョンを使用

自動的に発行されるAnalyeze

Redshiftで自動的に発行されるAnalyzeには大きく２種類存在。
①コマンドとセットで発行されるAnalyze
②AutoAnalyze機能により発行されるAnalyze

コマンドとセットで発行されるAnalyze

Analyzeがセットで（自動的に）発行されるコマンドは下記４つ。
①COPY（STATUPDATEオプションとCOPY先テーブルのデータ状態により発行有無が変わる）
②CRETATE TALBE AS
③CREATE TEMP TABLE AS
④SELECT INTO
参考：Redshift開発者ガイド内「テーブルを分析する」

また上記の派生として、下記コマンドについてもAnalyzeが発行される。
⑤CREATE MATERIALIZED VIEW
⑥REFRESH MATERIALIZED VIEW（増分更新の場合は発行されない）
※細かな挙動については記事の後半の「MATERIALIZED VIEWに関する挙動について」に記載

AutoAnalyze機能により発行されるAnalyze

COPYコマンドでtbl1テーブルにデータを格納し、AutoAnalyze機能の動きをSTL_ANALYZEテーブルから観察。

db1=# select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, CONVERT_TIMEZONE('JST',a.starttime) as starttime_j,is_auto,is_background,substring(auto_analyze_phase,1,20) from STL_ANALYZE a join stv_tbl_perm t on t.id=a.table_id order by starttime;
  xid  |  name  |     status      |   rows   | modified_rows |         starttime_j        | is_auto | is_background |      substring
-------+--------+-----------------+----------+---------------+----------------------------+---------+---------------+----------------------
  7027 | tbl1   | Full            | 20000000 |      20000000 | 2021-03-28 08:30:45.877363 | t       | f             | Not Applicable        ---COPYコマンドでデータをLoad
  7711 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 08:43:08.084746 | t       | t             | (Phase 1) Processing
  7711 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 08:43:08.085832 | t       | t             | (Phase 2) Processing
  7711 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 08:43:08.08619  | t       | t             | (Phase 3) Processing
 10959 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 09:43:09.346016 | t       | t             | (Phase 1) Processing
 10971 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 09:43:25.863039 | t       | t             | (Phase 2) Processing
 10971 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 09:43:25.863496 | t       | t             | (Phase 3) Processing
 14338 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 10:43:10.401768 | t       | t             | (Phase 1) Processing
 14351 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 10:43:20.258824 | t       | t             | (Phase 2) Processing
 14351 | tbl1   | Skipped         | 20000000 |             0 | 2021-03-28 10:43:20.259437 | t       | t             | (Phase 3) Processing

8時から10時の間だけではあるが、各時刻の43分にAutoAnalyzeが発行されており、おそらく1時間に1回のペースでAutoAnalyzeが稼働している模様。
上記ログはCOPYコマンド以降、当該テーブルにクエリを発行していないケースだが、別途COPYコマンド後にテーブルに更新クエリを発行するケースも試行したが1時間に1回のペースは変わらなかった。（ただ、数回程度の試行のためAutoAnalyzeが稼働するケースがある可能性はあり）

Analyzeを明示的に発行した方がよいケース

端的にまとめると「Analyzeが自動的に発行されないコマンドにより作成したテーブルを、1時間以内に参照し、かつ、統計情報が最新でないとパフォーマンスが出ないような参照クエリがある場合」。
（全然端的じゃない・・・）

基本的にRedshiftへ大量データを投入するときはCopyコマンド、CTASあたりかと思うが、他にあるとすればINSERT INTO SELECTでのデータ投入か。
※上記で記載した「SELECT INTO」とは別のコマンド。
※ISERT INTO SELECTでデータ投入した場合には、自動でAnalyzeが発行されないことも実機確認済み

MATERIALIZED VIEWに関する挙動について

以下の流れでコマンドを発行し、Analyze関連で内部的に発行されたコマンドをsvl_statementtextテーブルから、テーブルへのAnalyze実績をstl_analyzeテーブルから確認。
　①tbl1にCOPYコマンドで3000万件をLoad
　②CREATE MATERIALIZED VIEW
　③tbl1にCOPYコマンドで2000万件を追加Load（STATUPDATEオプション設定無し）
　④REFRESH MATERIALIZED VIEW（増分更新）
　⑤tbl1にCOPYコマンドで2000万件を追加Load（STATUPDATEオプションON）
　⑥tbl1をtruncata
　⑦tbl1にCOPYコマンドで3000万件をLoad
　⑧REFRESH MATERIALIZED VIEW（全量更新）

①tbl1にCOPYコマンドで3000万件をLoad

空テーブルに対しCOPYコマンドを発行するとセットでAnalyzeが発行される。

db1=# select xid, CONVERT_TIMEZONE('JST',starttime) as starttime,datediff(sec,starttime,endtime ) as secs, substring(text, 1, 300) from svl_statementtext where sequence = 0 and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' ) order by xid,starttime;
 xid  |         starttime          | secs |                                                                                                substring
------+----------------------------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 2616 | 2021-04-03 19:47:24.273663 |   64 | copy tbl1 from 's3://xxx';
 2616 | 2021-04-03 19:48:28.974304 |   20 | Analyze tbl1
 2616 | 2021-04-03 19:48:28.975073 |   14 | padb_fetch_sample: select * from tbl1
 2616 | 2021-04-03 19:48:42.26644  |    6 | padb_fetch_sample: select * from tbl1
 2616 | 2021-04-03 19:48:48.413595 |    0 | COMMIT

db1=# select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, CONVERT_TIMEZONE('JST',a.starttime) as starttime_j ,is_auto,is_background,substring(auto_analyze_phase,1,20) as phase from stl_analyze a join stv_tbl_perm t  on t.id=a.table_id order by starttime;
 xid  | name |     status      |   rows   | modified_rows |        starttime_j         | is_auto | is_background |     phase
------+------+-----------------+----------+---------------+----------------------------+---------+---------------+----------------
 2616 | tbl1 | Full            | 30000000 |      30000000 | 2021-04-03 19:48:28.974304 | t       | f             | Not Applicable

②CREATE MATERIALIZED VIEW

MATERIALIZED VIEWをCreateしたタイミングでAnalyzeコマンドが発行される。

db1=# select xid, CONVERT_TIMEZONE('JST',starttime) as starttime,datediff(sec,starttime,endtime ) as secs, substring(text, 1, 300) from svl_statementtext where sequence = 0 and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' ) order by xid,starttime;
 xid  |         starttime          | secs |                                                                                                substring
------+----------------------------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 2798 | 2021-04-03 19:50:50.25773  |   37 | Create MATERIALIZED VIEW mv_tbl1\nas select * from tbl1;
 2798 | 2021-04-03 19:51:27.151279 |    0 | Create MATERIALIZED VIEW mv_tbl1\nas select * from tbl1;
 2798 | 2021-04-03 19:51:27.15358  |    0 | Create MATERIALIZED VIEW mv_tbl1\nas select * from tbl1;
 2798 | 2021-04-03 19:51:27.165518 |   16 | Analyze mv_tbl__mv_tbl1__0
 2798 | 2021-04-03 19:51:27.165717 |   16 | padb_fetch_sample: select * from mv_tbl__mv_tbl1__0
 2798 | 2021-04-03 19:51:43.301068 |    0 | padb_fetch_sample: select * from mv_tbl__mv_tbl1__0
 2798 | 2021-04-03 19:51:43.847555 |    0 | COMMIT

db1=# select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, CONVERT_TIMEZONE('JST',a.starttime) as starttime_j ,is_auto,is_background,substring(auto_analyze_phase,1,20) as phase from stl_analyze a join stv_tbl_perm t  on t.id=a.table_id order by starttime;
 xid  |        name        |     status      |   rows   | modified_rows |        starttime_j         | is_auto | is_background |     phase
------+--------------------+-----------------+----------+---------------+----------------------------+---------+---------------+----------------
 2616 | tbl1               | Full            | 30000000 |      30000000 | 2021-04-03 19:48:28.974304 | t       | f             | Not Applicable
 2798 | mv_tbl__mv_tbl1__0 | Full            | 30000000 |             0 | 2021-04-03 19:51:27.165518 | t       | f             | Not Applicable

③tbl1にCOPYコマンドで2000万件をLoad（STATUPDATEオプション設定無し）

Analyzeの発行無し。
データ有りのテーブルにSTATUPDATEオプション無しでCOPYを実行した場合はAnalyzeは発行されない。

④REFRESH MATERIALIZED VIEW（増分更新）

Analyzeの発行無し。
増分更新の場合はAnalyzeは発行されない模様。
また、増分更新だったかどうかはリターンメッセージで確認可能。

db1=# REFRESH MATERIALIZED VIEW mv_tbl1;
INFO:  Materialized view mv_tbl1 was incrementally updated successfully.

ちなみに、全量更新の場合のメッセージは下記。

db1=# REFRESH MATERIALIZED VIEW mv_tbl1;
INFO:  Materialized view mv_tbl1 was recomputed successfully.

⑤tbl1にCOPYコマンドで2000万件をLoad（STATUPDATEオプションON）

STATUPDATEオプションONでCOPYコマンドを実行すると想定通りAnalyzeが自動で実行。

db1=# select xid, CONVERT_TIMEZONE('JST',starttime) as starttime,datediff(sec,starttime,endtime ) as secs, substring(text, 1, 300) from svl_statementtext where sequence = 0 and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' ) order by xid,starttime;
 xid  |         starttime          | secs |                                                                                                substring
------+----------------------------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 3503 | 2021-04-03 20:02:57.423461 |   46 | copy tbl1 from 's3://xxx';
 3503 | 2021-04-03 20:03:43.525802 |   33 | Analyze tbl1
 3503 | 2021-04-03 20:03:43.526022 |   28 | padb_fetch_sample: select * from tbl1
 3503 | 2021-04-03 20:04:11.532643 |    5 | padb_fetch_sample: select * from tbl1
 3503 | 2021-04-03 20:04:16.641362 |    0 | COMMIT

db1=# select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, CONVERT_TIMEZONE('JST',a.starttime) as starttime_j ,is_auto,is_background,substring(auto_analyze_phase,1,20) as phase from stl_analyze a join stv_tbl_perm t  on t.id=a.table_id order by starttime;
 xid  |        name        |     status      |   rows   | modified_rows |        starttime_j         | is_auto | is_background |     phase
------+--------------------+-----------------+----------+---------------+----------------------------+---------+---------------+----------------
 2616 | tbl1               | Full            | 30000000 |      30000000 | 2021-04-03 19:48:28.974304 | t       | f             | Not Applicable
 2798 | mv_tbl__mv_tbl1__0 | Full            | 30000000 |             0 | 2021-04-03 19:51:27.165518 | t       | f             | Not Applicable
 3503 | tbl1               | Full            | 70000000 |      40000000 | 2021-04-03 20:03:43.525802 | t       | f             | Not Applicable

⑥tbl1をtruncata

（MATERIALIZED VIEWを全量更新するため一度tbl1をtruncate）

⑦tbl1にCOPYコマンドで3000万件をLoad

再度、tbl1に3000万件を投入。

db1=# select xid, CONVERT_TIMEZONE('JST',starttime) as starttime,datediff(sec,starttime,endtime ) as secs, substring(text, 1, 300) from svl_statementtext where sequence = 0 and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' ) order by xid,starttime;
 xid  |         starttime          | secs |                                                                                                substring
------+----------------------------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 3782 | 2021-04-03 20:08:08.798301 |   60 | copy tbl1 from 's3://xxx';
 3782 | 2021-04-03 20:09:08.044916 |   12 | Analyze tbl1
 3782 | 2021-04-03 20:09:08.045211 |   10 | padb_fetch_sample: select * from tbl1
 3782 | 2021-04-03 20:09:18.211502 |    2 | padb_fetch_sample: select * from tbl1
 3782 | 2021-04-03 20:09:20.301491 |    0 | COMMIT

db1=# select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, CONVERT_TIMEZONE('JST',a.starttime) as starttime_j ,is_auto,is_background,substring(auto_analyze_phase,1,20) as phase from stl_analyze a join stv_tbl_perm t  on t.id=a.table_id order by starttime;
 xid  |        name        |     status      |   rows   | modified_rows |        starttime_j         | is_auto | is_background |     phase
------+--------------------+-----------------+----------+---------------+----------------------------+---------+---------------+----------------
 2616 | tbl1               | Full            | 30000000 |      30000000 | 2021-04-03 19:48:28.974304 | t       | f             | Not Applicable
 2798 | mv_tbl__mv_tbl1__0 | Full            | 30000000 |             0 | 2021-04-03 19:51:27.165518 | t       | f             | Not Applicable
 3503 | tbl1               | Full            | 70000000 |      40000000 | 2021-04-03 20:03:43.525802 | t       | f             | Not Applicable
 3782 | tbl1               | Full            | 30000000 |      30000000 | 2021-04-03 20:09:08.044916 | t       | f             | Not Applicable

⑧REFRESH MATERIALIZED VIEW（全量更新）

元テーブルがまるっと入れ替わった状態でREFRESHコマンドを発行すると、CTASで内部テーブルを作成し当該テーブルをMATERIALIZED VIEWに置き換えるような内部クエリが発行され、合わせてAnalyzeも発行。

db1=# select xid, CONVERT_TIMEZONE('JST',starttime) as starttime,datediff(sec,starttime,endtime ) as secs, substring(text, 1, 300) from svl_statementtext where sequence = 0 and xid in (select xid from svl_statementtext s where s.text like 'padb_fetch_sample%' ) order by xid,starttime;
 xid  |         starttime          | secs |                                                                                                substring
------+----------------------------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 3903 | 2021-04-03 20:10:24.456465 |   50 | REFRESH MATERIALIZED VIEW mv_tbl1;
 3903 | 2021-04-03 20:10:24.457537 |   50 | CALL public.mv_sp__mv_tbl1__0_1(0, 3902, 1, '(0)');
 3903 | 2021-04-03 20:10:24.46982  |   39 |  CREATE TABLE "public"."mv_tbl__mv_tbl1__0_recomputed" BACKUP YES DISTSTYLE KEY DISTKEY(2) COMPOUND SORTKEY(1, 2) AS (SELECT "tbl1".xxx
 3903 | 2021-04-03 20:11:03.50325  |   11 | Analyze mv_tbl__mv_tbl1__0_recomputed
 3903 | 2021-04-03 20:11:03.503481 |   11 | padb_fetch_sample: select * from mv_tbl__mv_tbl1__0_recomputed
 3903 | 2021-04-03 20:11:14.327198 |    0 | padb_fetch_sample: select * from mv_tbl__mv_tbl1__0_recomputed
 3903 | 2021-04-03 20:11:14.825666 |    0 | CREATE OR REPLACE VIEW "public"."mv_tbl1" AS (SELECT "derived_table1".xxx
 3903 | 2021-04-03 20:11:14.827848 |    0 | DROP TABLE "public"."mv_tbl__mv_tbl1__0"
 3903 | 2021-04-03 20:11:14.831234 |    0 | ALTER TABLE "public"."mv_tbl__mv_tbl1__0_recomputed" RENAME TO "mv_tbl__mv_tbl1__0"
 3903 | 2021-04-03 20:11:14.832263 |    0 | CREATE OR REPLACE VIEW "public"."mv_tbl1" AS (SELECT "derived_table1".xxx
 3903 | 2021-04-03 20:11:14.835738 |    0 | COMMIT

db1=# select distinct a.xid, trim(t.name) as name, a.status, a.rows, a.modified_rows, CONVERT_TIMEZONE('JST',a.starttime) as starttime_j ,is_auto,is_background,substring(auto_analyze_phase,1,20) as phase from stl_analyze a join stv_tbl_perm t  on t.id=a.table_id order by starttime;
 xid  |        name        |     status      |   rows   | modified_rows |        starttime_j         | is_auto | is_background |     phase
------+--------------------+-----------------+----------+---------------+----------------------------+---------+---------------+----------------
 2616 | tbl1               | Full            | 30000000 |      30000000 | 2021-04-03 19:48:28.974304 | t       | f             | Not Applicable
 3503 | tbl1               | Full            | 70000000 |      40000000 | 2021-04-03 20:03:43.525802 | t       | f             | Not Applicable
 3782 | tbl1               | Full            | 30000000 |      30000000 | 2021-04-03 20:09:08.044916 | t       | f             | Not Applicable
 3903 | mv_tbl__mv_tbl1__0 | Full            | 30000000 |             0 | 2021-04-03 20:11:03.50325  | t       | f             | Not Applicable

終わりに

記載が誤っている点や、わかりづらい点がありましたらコメントいただけますと幸いです。

はじめに

皆様、CloudTrailをうまく活用出来てますかー？^^
今回は、勝手にシリーズ化しようと思っているCloudTrail証跡ログ解説編の第二弾になります！

「CloudTrailを活用しようと思っているけど、具体的にどう見れば良いのか分からない」
という話はよく漏れ聞こえてきます。

それにお応えできるものが続けられれば良いなと思っています。
以下は第一弾の記事になります。

【参考】
・ 【CloudTrail証跡ログ解説編】AWSマネージメントコンソールのログインの見張り方

今回実施したこと

今回は、マネージメントコンソールでのVPCに関する操作に特化した内容になっています。
よく利用する下記のサービスを中心に解説したいと思います。

• VPC
• サブネット
• ルートテーブル
• インターネットゲートウェイ (以下、IGW)
• Elastic IP
• NATゲートウェイ (以下、NATGW)
• ピアリング接続
• ネットワークACL
• セキュリティグループ

テストシナリオ

具体的には以下の32個のシナリオで動作テストしてみました。

#	サービス名	分類	テストシナリオ	eventName (=API名)
01	VPC	作成	VPCを新規作成する	CreateVpc
02	VPC	変更	VPCに新しいCIDRを追加する	AssociateVpcCidrBlock
03	VPC	削除	VPCを削除する	DeleteVpc
04	サブネット	作成	VPCにサブネットを新規作成する	CreateSubnet
05	サブネット	変更	「自動割り当てIP設定の変更」をオンにする	ModifySubnetAttribute
06	サブネット	削除	VPCからサブネットを削除する	DeleteSubnet
07	ルートテーブル	作成	VPCにルートテーブルを新規作成する	CreateRouteTable
08	ルートテーブル	変更	デフォルトルート(0.0.0.0/0 via IGW)を追加する	CreateRoute
09	ルートテーブル	変更	デフォルトルート(0.0.0.0/0 via NATGW)を変更する	ReplaceRoute
10	ルートテーブル	変更	デフォルトルート(0.0.0.0/0 viq NATGW)を削除する	DeleteRoute
11	ルートテーブル	削除	ルートテーブルを削除する	DeleteRouteTable
12	IGW	作成	IGWを新規作成する	CreateInternetGateway
13	IGW	変更	VPCにIGWをアタッチする	AttachInternetGateway
14	IGW	削除	VPCからIGWをデタッチする	DetachInternetGateway
15	IGW	削除	IGWを削除する	DeleteInternetGateway
16	Elastic IP	作成	Elastic IPを割り当てる	AllocateAddress
17	Elastic IP	変更	EC2にElastic IPを関連付ける	AssociateAddress
18	Elastic IP	変更	EC2からElastic IPの関連付けを解除する	DisassociateAddress
19	Elastic IP	削除	Elastic IPを解放する	ReleaseAddress
20	NATGW	作成	NATGWを新規作成する	CreateNatGateway
21	NATGW	削除	NATGWを削除する	DeleteNatGateway
22	ピアリング接続	作成	VPCにピアリング接続を作成する	CreateVpcPeeringConnection
23	ピアリング接続	削除	ピアリング接続を削除する	DeleteVpcPeeringConnection
24	ネットワークACL	作成	VPCにネットワークACLを作成する	CreateNetworkAcl
25	ネットワークACL	変更	ネットワークACLのアウトバウンドルールを追加する	CreateNetworkAclEntry
26	ネットワークACL	変更	ネットワークACLをサブネットに割り当てる	ReplaceNetworkAclAssociation
27	ネットワークACL	変更	ネットワークACLのアウトバウンドルールを削除する	DeleteNetworkAclEntry
28	ネットワークACL	削除	ネットワークACLを削除する	DeleteNetworkAcl
29	セキュリティグループ	作成	VPCにセキュリティグループを作成する	CreateSecurityGroup
30	セキュリティグループ	変更	インバウンドルールに許可ルールを追加する	AuthorizeSecurityGroupIngress
31	セキュリティグループ	変更	EC2にセキュリティグループを割り当てる	ModifyNetworkInterfaceAttribute
32	セキュリティグループ	削除	セキュリティグループを削除する	DeleteSecurityGroup

eventNameとは

イベントの内容であるAPI名が記録されるCloudTrail証跡ログのフィールドの1つです。
マネージメントコンソールで操作する際、URLにパラメータとしてAPI名が埋め込まれています。
https://us-east-2.console.aws.amazon.com/vpc/home?region=us-east-2#CreateVpc:

CloudTrailは、AWS内の各サービスを操作したAPIコールログを記録するサービスになります。
eventNameを理解することで、AWSで何が起きているか理解できると言っても過言ではありません。

共通するフィールド

以下、CloudTrail証跡ログのサンプルになります。形式はJSONになります。
requestParametersとresponseElements以外のフィールドはどのイベントにも存在します。

共通するフィールド

{
    "eventVersion": "<ログイベント形式のバージョン>",
    "userIdentity": {
        "type": "<イベントの種類>",
        "principalId": "<呼び出しを行ったエンティティの一意の識別子>",
        "arn": "<操作したIAMユーザのARN>",
        "accountId": "<AWSアカウント(12桁)>",
        "accessKeyId": "<AWSアクセスキー>",
        "userName": "<操作したIAMユーザ名>",
        "sessionContext": {
            "sessionIssuer": {"<認証情報がどのように取得されたかに関する情報>"},
            "webIdFederationData": {"<IDプロバイダーに関する情報>"},
            "attributes": {
                "mfaAuthenticated": "<MFAデバイスによる認証有無(true/false)>",
                "creationDate": "<一時的セキュリティ認証情報が発行された時刻(ISO8601形式)>"
            }
        }
    },
    "eventTime": "<イベント発生時刻(ISO8601形式)>",
    "eventSource": "<リクエストが行われたAWSサービス>",
    "eventName": "<イベント名(=API名)>",
    "awsRegion": "<ログインしたAWSリージョン>",
    "sourceIPAddress": "<送信元IPアドレス>",
    "userAgent": "<接続元のユーザーエージェント(マネージメントコンソールだとconsole.ec2.amazonaws.comになる)",
    "requestParameters": {
        "<リクエストとともに送信されたパラメータ(後述しますが、APIに応じて内容が異なる)>"
    },
    "responseElements": {
        "<変更を行うアクションのレスポンスの要素(後述しますが、APIに応じて内容が異なる)>"
    },
    "requestID": "<リクエストを識別するID>",
    "eventID": "<CloudTrail証跡ログの中で一意となるイベントID>",
    "readOnly": <読み取り専用の操作であるかどうか(falseになる)>,
    "eventType": "<イベントレコードを生成したイベントのタイプ(AwsApiCallになる)>",
    "managementEvent": <管理用イベントかどうか(trueになる)>,
    "eventCategory": "<イベントのカテゴリ(Managementになる)>",
    "recipientAccountId": "<イベントを受信したAWSアカウント(12桁)>"
}

【参考】
・ CloudTrail レコードの内容
・ CloudTrail userIdentity要素

各イベントごとのログ内容と見張るポイント

ここからは、シナリオごとに出力された証跡ログの中でも
個々に異なるrequestParametersとresponseElementsに絞って解説します。

1. CreateVpc

test_vpcという名前のVPCを新規作成した時に出力されたログになります。
CIDRはIPv4の10.1.0.0/16のみのデフォルトテナンシーです。

CreateVpc

    "requestParameters": {
        "cidrBlock": "10.1.0.0/16",
        "instanceTenancy": "default",
        "amazonProvidedIpv6CidrBlock": false,
        "tagSpecificationSet": {
            "items": [
                {
                    "resourceType": "vpc",
                    "tags": [
                        {
                            "key": "Name",
                            "value": "test_vpc"
                        }
                    ]
                }
            ]
        }
    },
    "responseElements": {
        "requestId": "7ef273c6-a35e-4b94-b3d9-4aa7e68839b4",
        "vpc": {
            "vpcId": "vpc-0cadedb1948e67f9d",
            "state": "pending",
            "ownerId": "123456789012",
            "cidrBlock": "10.1.0.0/16",
            "cidrBlockAssociationSet": {
                "items": [
                    {
                        "cidrBlock": "10.1.0.0/16",
                        "associationId": "vpc-cidr-assoc-04636d42262eb0800",
                        "cidrBlockState": {
                            "state": "associated"
                        }
                    }
                ]
            },
            "ipv6CidrBlockAssociationSet": {},
            "dhcpOptionsId": "dopt-f9138391",
            "instanceTenancy": "default",
            "tagSet": {
                "items": [
                    {
                        "key": "Name",
                        "value": "test_vpc"
                    }
                ]
            },
            "isDefault": false
        }
    }

2. AssociateVpcCidrBlock

1.で作成したtest_vpcに対して
新しいCIDR10.2.0.0/16を追加した時に出力されたログになります。

AssociateVpcCidrBlock

    "requestParameters": {
        "AssociateVpcCidrBlockRequest": {
            "VpcId": "vpc-0cadedb1948e67f9d",
            "CidrBlock": "10.2.0.0/16"
        }
    },
    "responseElements": {
        "AssociateVpcCidrBlockResponse": {
            "xmlns": "http://ec2.amazonaws.com/doc/2016-11-15/",
            "cidrBlockAssociation": {
                "cidrBlock": "10.2.0.0/16",
                "cidrBlockState": {
                    "state": "associating"
                },
                "associationId": "vpc-cidr-assoc-09af3e1641bb40a37"
            },
            "requestId": "c0616704-7bbe-46a4-86d3-7257a5a70512",
            "vpcId": "vpc-0cadedb1948e67f9d"
        }
    }

3. DeleteVpc

1.で作成したtest_vpcを削除した時に出力されたログになります。

DeleteVpc

    "requestParameters": {
        "vpcId": "vpc-0cadedb1948e67f9d"
    },
    "responseElements": {
        "requestId": "05855acc-fcbf-4b1f-b5be-cac7e9cef331",
        "_return": true
    }

4. CreateSubnet

1.で作成したVPCにtest_subというサブネットを新規作成した時に出力されたログになります。
AZ名はus-east-2a、AZIDはuse2-az1に作成されていますね。

CreateSubnet

    "requestParameters": {
        "vpcId": "vpc-0cadedb1948e67f9d",
        "cidrBlock": "10.1.1.0/24",
        "availabilityZoneId": "use2-az1",
        "tagSpecificationSet": {
            "items": [
                {
                    "resourceType": "subnet",
                    "tags": [
                        {
                            "key": "Name",
                            "value": "test_sub"
                        }
                    ]
                }
            ]
        }
    },
    "responseElements": {
        "requestId": "bc989990-24e8-40d2-b805-239ead83b9d8",
        "subnet": {
            "subnetId": "subnet-09e76b27bf9f41841",
            "subnetArn": "arn:aws:ec2:us-east-2:123456789012:subnet/subnet-09e76b27bf9f41841",
            "state": "available",
            "vpcId": "vpc-0cadedb1948e67f9d",
            "cidrBlock": "10.1.1.0/24",
            "ipv6CidrBlockAssociationSet": {},
            "availableIpAddressCount": 251,
            "availabilityZone": "us-east-2a",
            "availabilityZoneId": "use2-az1",
            "ownerId": "123456789012",
            "defaultForAz": false,
            "mapPublicIpOnLaunch": false,
            "assignIpv6AddressOnCreation": false,
            "tagSet": {
                "items": [
                    {
                        "key": "Name",
                        "value": "test_sub"
                    }
                ]
            }
        }
    }

5. ModifySubnetAttribute

4.で作成したtest_subの自動割り当てIP設定の変更をオンにした時に出力されたログになります。
mapPublicIpOnLaunchの値がtrueにセットされていますね。

ModifySubnetAttribute

    "requestParameters": {
        "subnetId": "subnet-09e76b27bf9f41841",
        "mapPublicIpOnLaunch": {
            "value": true
        }
    },
    "responseElements": {
        "requestId": "a3e37d56-eb0e-4d5f-a2bc-b3763e1784fb",
        "_return": true
    }

6. DeleteSubnet

4.で作成したtest_subのサブネットを削除した時に出力されたログになります。

DeleteSubnet

    "requestParameters": {
        "subnetId": "subnet-09e76b27bf9f41841"
    },
    "responseElements": {
        "requestId": "23915c2c-8632-44ae-b355-bc23d229f404",
        "_return": true
    }

7. CreateRouteTable

1.で作成したVPCにルートテーブルを新規作成した時に出力されたログになります。
VPCに含まれる2つのCIDRに対して、ローカルでルーティングする経路がアサインされてますね。

CreateRouteTable

    "requestParameters": {
        "vpcId": "vpc-0cadedb1948e67f9d"
    },
    "responseElements": {
        "requestId": "173e741e-9853-4528-8a5d-18e9eb89e0d2",
        "routeTable": {
            "routeTableId": "rtb-0ae9547160a79eed8",
            "vpcId": "vpc-0cadedb1948e67f9d",
            "ownerId": "123456789012",
            "routeSet": {
                "items": [
                    {
                        "destinationCidrBlock": "10.1.0.0/16",
                        "gatewayId": "local",
                        "state": "active",
                        "origin": "CreateRouteTable"
                    },
                    {
                        "destinationCidrBlock": "10.2.0.0/16",
                        "gatewayId": "local",
                        "state": "active",
                        "origin": "CreateRouteTable"
                    }
                ]
            },
            "associationSet": {},
            "propagatingVgwSet": {},
            "tagSet": {}
        }
    }

8. CreateRoute

7.で作成したルートテーブルに新規ルートとして
12.で作成したIGWをターゲットにデフォルトルートを追加した時に出力されたログになります。

CreateRoute

    "requestParameters": {
        "routeTableId": "rtb-0ae9547160a79eed8",
        "destinationCidrBlock": "0.0.0.0/0",
        "gatewayId": "igw-00ec58b652195d8a3"
    },
    "responseElements": {
        "requestId": "edea8f3d-f3e6-484b-8d76-54114368b0f5",
        "_return": true
    }

【補足】
AWSマネージメントコンソールに不正ログインされるような攻撃を受けた場合
許可していない宛先へのルートが作られていないか見張る上で活用することができます。

9. ReplaceRoute

8.で作成したデフォルトルートのターゲットについて
20.で作成したNATゲートウェイに変更した時に出力されたログになります。

ReplaceRoute

    "requestParameters": {
        "routeTableId": "rtb-0ae9547160a79eed8",
        "destinationCidrBlock": "0.0.0.0/0",
        "natGatewayId": "nat-02d3aba70e2c742c2"
    },
    "responseElements": {
        "requestId": "73ad380d-00b7-4657-a230-574cf06276ad",
        "_return": true
    }

10. DeleteRoute

8.で作成したルート(デフォルトルート)を削除した時に出力されたログになります。

DeleteRoute

    "requestParameters": {
        "routeTableId": "rtb-0ae9547160a79eed8",
        "destinationCidrBlock": "0.0.0.0/0"
    },
    "responseElements": {
        "requestId": "f649ab57-92cb-46a2-852b-7a2a6870d4ae",
        "_return": true
    }

11. DeleteRouteTable

7.で作成したルートテーブルを削除した時に出力されたログになります。

DeleteRouteTable

    "requestParameters": {
        "routeTableId": "rtb-0ae9547160a79eed8"
    },
    "responseElements": {
        "requestId": "74a18b25-7036-4d3d-a424-30a5bfe98146",
        "_return": true
    }

12. CreateInternetGateway

test_igwという名前のIGWを新規作成した時に出力されたログになります。

CreateInternetGateway

    "requestParameters": {
        "tagSpecificationSet": {
            "items": [
                {
                    "resourceType": "internet-gateway",
                    "tags": [
                        {
                            "key": "Name",
                            "value": "test_igw"
                        }
                    ]
                }
            ]
        }
    },
    "responseElements": {
        "requestId": "1b245752-d0b1-4073-b3b3-01c46c3a1584",
        "internetGateway": {
            "internetGatewayId": "igw-00ec58b652195d8a3",
            "ownerId": "123456789012",
            "attachmentSet": {},
            "tagSet": {
                "items": [
                    {
                        "key": "Name",
                        "value": "test_igw"
                    }
                ]
            },
            "association": {}
        }
    }

13. AttachInternetGateway

12.で作成したIGWを1.で作成したVPCにアタッチした時に出力されたログになります。

AttachInternetGateway

    "requestParameters": {
        "internetGatewayId": "igw-00ec58b652195d8a3",
        "vpcId": "vpc-0cadedb1948e67f9d"
    },
    "responseElements": {
        "requestId": "be367983-bbdb-4348-a5a7-b0e718acfa0a",
        "_return": true
    }

【補足】
AWSマネージメントコンソールに不正ログインされるような攻撃を受けた場合
インターネットとの経路を勝手に作られていないか見張る上で活用することができます。

14. DetachInternetGateway

13.でVPCにアタッチしたIGWをでアタッチした時に出力されたログになります。

DetachInternetGateway

    "requestParameters": {
        "internetGatewayId": "igw-00ec58b652195d8a3",
        "vpcId": "vpc-0cadedb1948e67f9d"
    },
    "responseElements": {
        "requestId": "ec125fa8-3641-432e-b2ed-52d2170fe6ef",
        "_return": true
    }

15. DeleteInternetGateway

12.で作成したIGWを削除した時に出力されたログになります。

DeleteInternetGateway

    "requestParameters": {
        "internetGatewayId": "igw-00ec58b652195d8a3"
    },
    "responseElements": {
        "requestId": "3efbdbb4-306b-4ed8-8c99-6e4c0513e873",
        "_return": true
    }

16. AllocateAddress

Elastic IPをtest_eipという名前で新規作成した時に出力されたログになります。
オハイオリージョンus-east-2で利用できるIPアドレス3.141.213.252が割り当てられました。

AllocateAddress

    "requestParameters": {
        "domain": "vpc",
        "tagSpecificationSet": {
            "items": [
                {
                    "resourceType": "elastic-ip",
                    "tags": [
                        {
                            "key": "Name",
                            "value": "test_eip"
                        }
                    ]
                }
            ]
        }
    },
    "responseElements": {
        "requestId": "58a30bb4-5e25-4688-ad48-84c698186027",
        "publicIp": "3.141.213.252",
        "domain": "vpc",
        "allocationId": "eipalloc-019faf9a13318ac20",
        "publicIpv4Pool": "amazon",
        "networkBorderGroup": "us-east-2"
    }

17. AssociateAddress

16.で割り当てられたElastic IPをEC2インスタンスに関連付けした時に出力されたログになります。
該当のEC2のインスタンスIDはi-0b82f7b0f0c2e3c0eですね。

AssociateAddress

    "requestParameters": {
        "instanceId": "i-0b82f7b0f0c2e3c0e",
        "allocationId": "eipalloc-019faf9a13318ac20",
        "allowReassociation": false
    },
    "responseElements": {
        "requestId": "68d66732-c49d-4dda-99fc-7cc298d3e5c9",
        "_return": true,
        "associationId": "eipassoc-0b3422d49dd4e34c5"
    }

【補足】
AWSマネージメントコンソールに不正ログインされるような攻撃を受けた場合
インターネットとの通信できないEC2にElastic IPが関連付けられていないか
見張る上で活用することができます。

18. DisassociateAddress

17.で関連付けたElastic IPを解除した時に出力されたログになります。

DisassociateAddress

    "requestParameters": {
        "associationId": "eipassoc-0b3422d49dd4e34c5"
    },
    "responseElements": {
        "requestId": "a69caa2b-51ed-4d0c-85a8-e1d60c6c5b9a",
        "_return": true
    }

19. ReleaseAddress

16.で新規作成したElastic IPを解放した時に出力されたログになります。

ReleaseAddress

    "requestParameters": {
        "allocationId": "eipalloc-019faf9a13318ac20"
    },
    "responseElements": {
        "requestId": "e45658a4-114f-4985-8d4b-39e4271e4d06",
        "_return": true
    }

20. CreateNatGateway

test_natgwという名前のNATGWを新規作成した時に出力されたログになります。
NATGWに関連付けしたElastic IPは16.で作成したIPアドレスになります。
NATGWは4.で作成したサブネット(subnet-09e76b27bf9f41841)に作成しています。

CreateNatGateway

    "requestParameters": {
        "CreateNatGatewayRequest": {
            "AllocationId": "eipalloc-019faf9a13318ac20",
            "SubnetId": "subnet-09e76b27bf9f41841",
            "TagSpecification": {
                "ResourceType": "natgateway",
                "tag": 1,
                "Tag": {
                    "Value": "test_natgw",
                    "tag": 1,
                    "Key": "Name"
                }
            }
        }
    },
    "responseElements": {
        "CreateNatGatewayResponse": {
            "xmlns": "http://ec2.amazonaws.com/doc/2016-11-15/",
            "natGateway": {
                "connectivityType": "public",
                "subnetId": "subnet-09e76b27bf9f41841",
                "tagSet": {
                    "item": {
                        "value": "test_natgw",
                        "key": "Name"
                    }
                },
                "natGatewayAddressSet": {
                    "item": {
                        "allocationId": "eipalloc-019faf9a13318ac20"
                    }
                },
                "createTime": "2021-03-31T23:22:22.000Z",
                "vpcId": "vpc-0cadedb1948e67f9d",
                "natGatewayId": "nat-02d3aba70e2c742c2",
                "state": "pending"
            },
            "requestId": "7e55bbce-e95a-4cb3-86da-3ead71285982"
        }
    }

21. DeleteNatGateway

20.で作成したNATGWを削除した時に出力されたログになります。

DeleteNatGateway

    "requestParameters": {
        "DeleteNatGatewayRequest": {
            "NatGatewayId": "nat-02d3aba70e2c742c2"
        }
    },
    "responseElements": {
        "DeleteNatGatewayResponse": {
            "xmlns": "http://ec2.amazonaws.com/doc/2016-11-15/",
            "requestId": "2ac357ab-14dd-4081-9cf5-ed9ea9f6c835",
            "natGatewayId": "nat-02d3aba70e2c742c2"
        }
    }

22. CreateVpcPeeringConnection

1.で作成したVPCにVPCピアリングを新規作成した時に出力されたログになります。
ピアリングのリクエストを承認した際にはCloudTrailの証跡ログは発見できませんでした。

CreateVpcPeeringConnection

    "requestParameters": {
        "vpcId": "vpc-0cadedb1948e67f9d",
        "peerVpcId": "vpc-09be24b8533330c11"
    },
    "responseElements": {
        "requestId": "b7a8fa3f-3db2-4e35-bc6d-b15d97bb529c",
        "vpcPeeringConnection": {
            "vpcPeeringConnectionId": "pcx-0fa806d53eb4264f5",
            "requesterVpcInfo": {
                "ownerId": "123456789012",
                "vpcId": "vpc-0cadedb1948e67f9d",
                "cidrBlock": "10.1.0.0/16",
                "region": "us-east-2",
                "cidrBlockSet": {
                    "items": [
                        {
                            "cidrBlock": "10.1.0.0/16"
                        },
                        {
                            "cidrBlock": "10.2.0.0/16"
                        }
                    ]
                },
                "peeringOptions": {
                    "allowEgressFromLocalClassicLinkToRemoteVpc": false,
                    "allowEgressFromLocalVpcToRemoteClassicLink": false,
                    "allowDnsResolutionFromRemoteVpc": false
                }
            },
            "accepterVpcInfo": {
                "ownerId": "123456789012",
                "vpcId": "vpc-09be24b8533330c11",
                "region": "us-east-2"
            },
            "status": {
                "code": "initiating-request",
                "message": "Initiating Request to 123456789012"
            },
            "expirationTime": 1617838496000,
            "tagSet": {}
        }
    }

【補足】
AWSマネージメントコンソールに不正ログインされるような攻撃を受けた場合
攻撃者の用意したVPCとピアリングされてデータを盗まれないことを見張る上で
活用することができます。

23. DeleteVpcPeeringConnection

22.で作成したVPCピアリングを削除した時に出力されたログになります。

DeleteVpcPeeringConnection

    "requestParameters": {
        "vpcPeeringConnectionId": "pcx-0fa806d53eb4264f5"
    },
    "responseElements": {
        "requestId": "50cdc2c4-890a-4896-92d4-9a0484758160",
        "_return": true
    }

24. CreateNetworkAcl

1.で作成したVPCにネットワークACLtest_naclを新規作成した時に出力されたログになります。

CreateNetworkAcl

    "requestParameters": {
        "vpcId": "vpc-0cadedb1948e67f9d",
        "tagSpecificationSet": {
            "items": [
                {
                    "resourceType": "network-acl",
                    "tags": [
                        {
                            "key": "Name",
                            "value": "test_nacl"
                        }
                    ]
                }
            ]
        }
    },
    "responseElements": {
        "requestId": "d3ba4ccd-e147-4136-b2e9-10df3b1174a6",
        "networkAcl": {
            "networkAclId": "acl-0ad5205baab7d5322",
            "vpcId": "vpc-0cadedb1948e67f9d",
            "ownerId": "123456789012",
            "isDefault": false,
            "entrySet": {
                "items": [
                    {
                        "ruleNumber": 32767,
                        "aclProtocol": "-1",
                        "ruleAction": "deny",
                        "cidrBlock": "0.0.0.0/0",
                        "egress": true,
                        "icmpTypeCode": {},
                        "portRange": {}
                    },
                    {
                        "ruleNumber": 32767,
                        "aclProtocol": "-1",
                        "ruleAction": "deny",
                        "cidrBlock": "0.0.0.0/0",
                        "egress": false,
                        "icmpTypeCode": {},
                        "portRange": {}
                    }
                ]
            },
            "associationSet": {},
            "tagSet": {
                "items": [
                    {
                        "key": "Name",
                        "value": "test_nacl"
                    }
                ]
            }
        }
    }

25. CreateNetworkAclEntry

24.で作成したネットワークACLのアウトバウンドルールに対して
全ての通信、全ての宛先に対する通信許可ルールを追加した時に出力されたログになります。

CreateNetworkAclEntry

    "requestParameters": {
        "networkAclId": "acl-0ad5205baab7d5322",
        "ruleNumber": 1,
        "egress": true,
        "ruleAction": "allow",
        "icmpTypeCode": {},
        "portRange": {},
        "aclProtocol": "-1",
        "cidrBlock": "0.0.0.0/0"
    },
    "responseElements": {
        "requestId": "796c9f8b-e0ff-4c6f-bcc6-d2d511aa96f5",
        "_return": true
    }

26. ReplaceNetworkAclAssociation

24.で作成したネットワークACLを4.で作成したサブネットに関連付けた時に出力されたログになります。

ReplaceNetworkAclAssociation

    "requestParameters": {
        "associationId": "aclassoc-53fcc036",
        "networkAclId": "acl-0ad5205baab7d5322"
    },
    "responseElements": {
        "requestId": "069245c7-26a2-483e-b420-75e0da5f354c",
        "newAssociationId": "aclassoc-009f98f53c372eba8"
    }

27. DeleteNetworkAclEntry

25.で追加したアウトバウンドルールを削除した時に出力されたログになります。

DeleteNetworkAclEntry

    "requestParameters": {
        "networkAclId": "acl-0ad5205baab7d5322",
        "ruleNumber": 1,
        "egress": true
    },
    "responseElements": {
        "requestId": "02473d41-f3e7-420b-9dfb-19867529e033",
        "_return": true
    }

28. DeleteNetworkAcl

24.で作成したネットワークACLを削除した時に出力されたログになります。

DeleteNetworkAcl

    "requestParameters": {
        "networkAclId": "acl-0ad5205baab7d5322"
    },
    "responseElements": {
        "requestId": "f8a56f1e-5bee-410c-a130-9b95ef0f76aa",
        "_return": true
    }

29. CreateSecurityGroup

1.で作成したVPCにセキュリティグループtest_sgを新規作成した時に出力されたログになります。

CreateSecurityGroup

    "requestParameters": {
        "groupName": "test_sg",
        "groupDescription": "test",
        "vpcId": "vpc-0cadedb1948e67f9d",
        "tagSpecificationSet": {
            "items": [
                {
                    "resourceType": "security-group",
                    "tags": [
                        {
                            "key": "Name",
                            "value": "test_sg"
                        }
                    ]
                }
            ]
        }
    },
    "responseElements": {
        "requestId": "73770429-2956-4bb3-b9a5-430deb5bf2ae",
        "_return": true,
        "groupId": "sg-07ead3b5afa105744",
        "tagSet": {
            "items": [
                {
                    "key": "Name",
                    "value": "test_sg"
                }
            ]
        }
    }

30. AuthorizeSecurityGroupIngress

29.で作成したセキュリティグループのインバウンドルールとして
10.1.0.0/16宛のICMP通信を追加した時に出力されたログになります。

AuthorizeSecurityGroupIngress

    "requestParameters": {
        "groupId": "sg-07ead3b5afa105744",
        "ipPermissions": {
            "items": [
                {
                    "ipProtocol": "icmp",
                    "fromPort": -1,
                    "toPort": -1,
                    "groups": {},
                    "ipRanges": {
                        "items": [
                            {
                                "cidrIp": "10.1.0.0/16",
                                "description": "test"
                            }
                        ]
                    },
                    "ipv6Ranges": {},
                    "prefixListIds": {}
                }
            ]
        }
    },
    "responseElements": {
        "requestId": "7ffc5e80-0e85-41cb-ac8b-d462bab14470",
        "_return": true
    }

【補足】
AWSマネージメントコンソールに不正ログインされるような攻撃を受けた場合
EC2で許可していない通信が勝手に追加されていないことを見張る上で活用することができます。

31. ModifyNetworkInterfaceAttribute

29.で作成したセキュリティグループをEC2に割り当てた時に出力されたログになります。
eni-01078c68e9e75ad3dはEC2のネットワークインターフェースIDですね。

ModifyNetworkInterfaceAttribute

    "requestParameters": {
        "networkInterfaceId": "eni-01078c68e9e75ad3d",
        "groupSet": {
            "items": [
                {
                    "groupId": "sg-07ead3b5afa105744"
                }
            ]
        }
    },
    "responseElements": {
        "requestId": "d6f30c00-b835-4749-bbd7-0f371828699b",
        "_return": true
    }

32. DeleteSecurityGroup

29.で作成したセキュリティグループを削除時に出力されたログになります。

DeleteSecurityGroup

    "requestParameters": {
        "groupId": "sg-07ead3b5afa105744"
    },
    "responseElements": {
        "requestId": "60e1fb9e-5fcf-4c31-b098-2f9847f5b114",
        "_return": true
    }

まとめ

さて、いかがでしたでしょうか？

ここまで細かくVPCに関するAPIコールログを見ることないんじゃない？って言われそうですよね。
はい、そうだと思います。ですが、どのような新たな攻撃が来るかわかりません。
ビジネスアプリケーションに必要な通信に対して、少しでも違和感がないかを見極めるには
必要になることもあります。

AWS Config Rules¹でも見張れるものもあります。
restricted-sshやeip-attached、ec2-security-group-attached-to-eni
などを利用する感じですね。

しかしマネージドルールにない要件を検知したい場合は、カスタムルールを作成するか
CloudTrailを活用した検知ルールをCloudWatchで作成していくことになります。

いずれにしてもAPIコールログを理解できるに越したことはないと思います。
皆様にとっても役に立つナレッジになっていれば良いなと思う次第です^^

---

1. AWS Config マネージドルールのリスト ↩

CloudFormation

これから使用するリソースをテンプレートと呼ばれるCloudFormationで用いるテキストファイルに記述することで、マネジメントコンソールやCLIを用いなくとも自動で作成してくれるサービス。例えば、VPCとサブネットを作成する場合、CIDRなどの必要事項を記述すれば、VPC → サブネットの順に依存関係まで考慮して作成してくれる。

特にクライアントVPNではACMを利用したりネットワークの関連付けをしたりするなど、あちこち行ったり来たりするのでリソースをまとめて管理するメリットは大きいと思われる。

また、削除も一括で行ってくれるのでリソースの消し忘れも防ぐことができる。

クライアントVPNエンドポイント

インターネットから分離したVPCに安全にアクセスするためのサービス。例えば、EC2インスタンスにログインするためには通常パブリックサブネットにインスタンスを置く必要があるが、その状況ではインターネットからの不特定なアクセスを許してしまう可能性がある。クライアントVPNエンドポイントを使うことで、プライベートサブネットに配置したインスタンスにアクセスすることが可能である。

テンプレートについての注意点

• 今回のテンプレートではACMに証明書をあらかじめ用意しておき、そのARNを指定している

• 認証方法には、相互認証・ディレクトリ認証を使用している

• テンプレートは、JSONまたはyaml形式で作成する

今回はJSONで書いたがこれをyaml形式に変換するには次の手順を踏めばよい。

変換手順
１. スタックの作成をクリック

２. デザイナーでテンプレートを作成をクリック

３. YAMLを選択

変換できればメッセージに表示される。

テンプレート

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Resources": {
      "VPC": {
          "Type": "AWS::EC2::VPC",
          "Properties": {
              "CidrBlock": "10.0.0.0/16",
              "EnableDnsSupport": true,
              "EnableDnsHostnames": true
          }
      },
      "Subnet1": {
          "Type": "AWS::EC2::Subnet",
          "Properties": {
              "VpcId": {
                  "Ref": "VPC"
              },
              "CidrBlock": "10.0.0.0/24",
              "AvailabilityZone": "ap-northeast-1d"
          }
      },
      "Subnet2": {
          "Type": "AWS::EC2::Subnet",
          "Properties": {
              "VpcId": {
                  "Ref": "VPC"
              },
              "CidrBlock": "10.0.1.0/24",
              "AvailabilityZone": "ap-northeast-1c"
          }
      },
      "ClientVpnAuthorizationRule": {
          "Type": "AWS::EC2::ClientVpnAuthorizationRule",
          "Properties": {
              "ClientVpnEndpointId": {
                  "Ref": "ClientVpnEndpoint"
              },
              "AuthorizeAllGroups": true,
              "TargetNetworkCidr": "0.0.0.0/0"
          }
      },
      "ClientVpnEndpoint": {
          "Type": "AWS::EC2::ClientVpnEndpoint",
          "Properties": {
              "ServerCertificateArn": "arn:aws:acm:ap-northeast-1:012345678912:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
              "AuthenticationOptions": [
                  {
                      "MutualAuthentication": {
                          "ClientRootCertificateChainArn": "arn:aws:acm:ap-northeast-1:012345678912:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
                      },
                      "Type": "certificate-authentication"
                  },
                  {
                      "ActiveDirectory": {
                          "DirectoryId": {
                              "Ref": "SimpleAD"
                          }
                      },
                      "Type": "directory-service-authentication"
                  }
              ],
              "ClientCidrBlock": "10.1.0.0/22",
              "ConnectionLogOptions": {
                  "Enabled": false
              },
              "SplitTunnel": true
          }
      },
      "ClientVpnTargetNetworkAssociation": {
          "Type": "AWS::EC2::ClientVpnTargetNetworkAssociation",
          "Properties": {
              "ClientVpnEndpointId": {
                  "Ref": "ClientVpnEndpoint"
              },
              "SubnetId": {
                  "Ref": "Subnet1"
              }
          }
      },
      "SimpleAD": {
          "Type": "AWS::DirectoryService::SimpleAD",
          "Properties": {
              "Name": "example.com",
              "Password": "Ab12345!",
              "Size": "Small",
              "VpcSettings": {
                  "SubnetIds": [
                      {
                          "Ref": "Subnet1"
                      },
                      {
                          "Ref": "Subnet2"
                      }
                  ],
                  "VpcId": {
                      "Ref": "VPC"
                  }
              }
          }
      },
      "DHCPOptions": {
          "Type": "AWS::EC2::DHCPOptions",
          "Properties": {
              "DomainName": "example.com",
              "DomainNameServers": {
                  "Fn::GetAtt": [
                      "SimpleAD",
                      "DnsIpAddresses"
                  ]
              }
          }
      }
  }
}

参考記事

はじめに

以前S3+CloudFront+Route53構成でSSLの独自ドメインサイトを書きました。
SSLの独自ドメイン静的Webサイトを低コストで15分で立ち上げる (Route53 + S3 + CloudFront + AWS Certificate Manager)
CloudFront + S3 構成でのリダイレクト設定

もっと簡単で楽に運用する方法を探していたらAmplifyで超簡単にできたので書いていこうと思います。

注意

自分はAmplifyについては知ったばっかりの超ど素人ですので、
これはアンチパターンかもしれません。
使うかどうかの判断はご自分で判断お願いします。

前提

• AWSアカウント
• 独自ドメインの取得
• 独自ドメインのNSをRoute53に向けている
• 静的サイトはGitで管理している

構築

Amplifyにアプリをデプロイ

サービス一覧からAmplifyに入り、New App -> Host web app 選択

使っているGitを選択（今回はGitHub）

リポジトリとブランチを選択して次へ
※Organizationsのリポジトリが出てこない場合は、
https://github.com/settings/applications
にアクセスし、awsの認証情報を削除し、再度アクセスすると権限付与画面が出てくるので、そこで組織を選択すればできるようになります。

任意のアプリ名を入力して次へ

そのままデプロイ

カスタムドメインの設定

作成したアプリを選択している状態で左のメニューからドメインの管理を選択
※Route53でホストゾーンを作成していること

好きなようにカスタマイズして保存（スクショはデフォルト）

このようにSSL証明書の作成が始まります。

同時にRoute53の設定もしてくれます。全部終わるまで5分前後です。

以上です。独自ドメインのURLでアクセスできるか見てみましょう。

料金

めちゃくちゃデプロイしなければS3+CloudFront構成と変わらないんじゃないかな？
まあ、安い

最後に

大阪リージョンはまだ無いようです。

【気に入ったところ】

• S3+CloudFront構成も簡単だけどこいつはもっと簡単
• 特に何もしなくてもデフォルトでGit連携の自動デプロイになっているところ
• リダイレクト設定も簡単
• ブランチも簡単に管理対象に含めることができる
• ブランチ毎にBesic認証がつけられるところ
• モニタリングがついている

【気にいらないところ】

• デプロイがちょっと長い（手動でS3に上げるよりは早い）

【気になったところ（無知故に）】
Amplifyが多機能すぎて(本来バックエンドで力を発揮するサービスっぽい）
ググると開発者向けの記事がかなりヒットするので、
静的Webサイトだけの為に使うのって、ありなのかな？

【その他】
キャッシュの設定はどこ？

勉強のためにWebアプリをEC2にデプロイしてAPIを叩いたりしてたら、突然EC2に入れなくなった。

とりあえずまあいっかと放置していたら・・・・・・

ある日こんなメールがAWSから届いた

Hello,
We've received a report(s) that your AWS resource(s)
has been implicated in activity which resembles scanning remote hosts on the internet for security vulnerabilities. Activity of this nature is forbidden in the AWS Acceptable Use Policy (https://aws.amazon.com/aup/). We've included the original report below for your review.
Please take action to stop the reported activity and reply directly to this email with details of the corrective actions you have taken. If you do not consider the activity described in these reports to be abusive, please reply to this email with ?details of your use case.
If you're unaware of this activity, it's possible that your environment has been compromised by an external attacker, or a vulnerability is allowing your machine to be used in a way that it was not intended.

上記訳

こんにちは、
AWSリソースに関するレポートを受け取りました
インターネット上のリモートホストのセキュリティの脆弱性のスキャンに似たアクティビティに関係しています。 この種のアクティビティは、AWSの利用規定（https://aws.amazon.com/aup/）で禁止されています。 レビュー用に、以下の元のレポートを含めました。
報告された活動を停止するための措置を講じ、講じた是正措置の詳細をこの電子メールに直接返信してください。 これらのレポートに記載されている活動が悪用されていると思わない場合は、このメールにユースケースの詳細を添えて返信してください。
このアクティビティに気付いていない場合は、外部の攻撃者によって環境が侵害されているか、脆弱性により、意図しない方法でマシンが使用されている可能性があります。

つまり
「このEC2に報告が入ったで。なんかこのEC2で悪用しているんちゃうか？攻撃されているかもしれんがな。
とりあえずなにしたか急いで返信してくれや」

とのこと。

訳もわからずとりあえずEC2を一旦停止

そして、AWSに急ぎ以下の内容を返信
(日本語と英語を書いた。しかしたら日本語で対応してくれる可能性があるため）

こちら身に覚えがないため、一度インスタンスを停止いたしました。

報告されたアクティビティ：ポートスキャン
とのことですが、具体的な情報が欲しいです。

I'm sorry. The reply was delayed.
I don't remember this, so I stopped the instance once.

Reported activity: Port scan
However, I would like specific information.

そしたら以下の返信が帰ってきた

※（英語でめちゃくちゃ長文がきたので日本語に簡易的に訳したのを載せます）

このインスタンスは起動したら暴れる(目的は知らんがポートスキャンしてるので違反している)から終了しろってこと。
暴れる原因に心当たりがないなら誰かに悪用されている事が考えられ、それはあなたの責任なのでしっかりしてください。
こういった事象を防ぐために色々用意してるからちゃんと調べて使ってね。
で、このインスタンスを復活したいなら
このインスタンスはおそらく完全にクリーンには出来ないので同じものを別に0から作ってね。
よろしく

EC2に入って中のログをしらべたところ、、

知らないIPからの接続を大量に確認！！
中国からアクセスがあった模様
kthreaddiというアプリがめちゃくそCPUを食ってて一瞬で使用率が100%に
（ビットコインをマイニングするツールらしい）

結論＋対応策

勉強用のEC2だったのでまあまた立てれば良いと思い、インスタンスを終了しました。

対応策
セキュリティグループを絞る
ファイアウォールを入れて守る

ウイルスが入ってしまうともうEc2のCPUが暴れ続けるらしい

みなさんもお気をつけて！！では！！！

勉強前イメージ

初めて聞いたサービス名・・・わからない

調査

Amazon Lightsail とは

VPS(仮想プライベートサーバー)サービスになります。
コンピューティング環境やストレージ、ファイアウォール、DNS機能などWebサービスに必要な機能をまとめてパッケージで提供されています。
手軽にwebアプリケーションを構築したいときなどの用途に向いています。

特徴

• 低価格

月額 3.50 USDからと謳ってる通り、低価格になります。
気軽に使うことが出来ます。

• 簡単なサーバをすぐに作成することが出来る

予め用意されているOSから、アプリケーションまでワンクリックで作成することが出来ます。
比較的知識がなくても使うことが出来ます。

• 細かくカスタマイズが出来ない

ある程度用意荒れているので、細かくカスタマイズできないので、柔軟度は低いです。

EC2との違い

同じようなサービスでEC2があります。
EC2との違いは以下になります。

• Amazon Lightsail と違い、コンピューティング環境のみなのでアプリケーションは自分で設定しないといけない
  • EC2は自分でアプリケーションの設定やインストールが出来るので、自由度が高いです。
• EC2は従量課金制なので、稼働した時間で費用がかかります。

勉強後イメージ

このサービス初めて知った！
めっちゃ便利やん・・・
Wordpressとかする人にはかなりいいかもしれない(まだやったことないけど)

参考

• 「Amazon Lightsail の特徴」
• Amazon Lightsailとは？4つの特長やEC2との違い
• 【VPS】Amazon Lightsailとは？

ユーザーを追加する

AWSアカウント自体を普段から利用ことは、パスワードが漏洩などした場合に契約や支払いを含め全権限があるため危険です。
普段利用としては、そう言った情報を扱わないアカウントを作成し、利用することが一般的です。

前提条件

AWSアカウントの取得が完了している状態
まだ、アカウントを追加していない方はこちら

IAMユーザーを作成する

サインインすると下記の画面が表示されます

画面上部の検索欄、もしくはサービスからIM検索し「IAMダッシュボード」を開きます

[ユーザー]を選択

ユーザー詳細の設定

[ユーザーの追加]を選択し、表示された画面を以下のように入入力し、[次のステップ]を選択

アクセス権限の設定

[既存のポリシーを直接アタッチ]を選択し、ポリシーを選美、[次のステップ]を選択
今回は全権限を持ったユーザーを追加するため、[AdministratorAccess]にチェックを入れる

タグの追加

何もせず、[次のステップ]を選択

作成の確認

内容に間違えがなければ、[ユーザーの作成]を選択

パスワードとサインインのURLの確認

[表示]を選択
この画面で先ほど自動生成したパスワードを確認し、保存します
※注意：以降再確認はできない
記載されているURLでコンソールへサインインができるので、こちらも保存します

IAMユーザーでのサインイン

作成したIAMユーザーで初めてサインインすると、パスワードの変更が求められます
任意のパスワードを設定してください
パスワードの変更ができたら、コンソール画面に戻ります
右上のユーザーの表示が切り替わっていることを確認してください

AWSでWebアプリをデプロイする方法③

請求情報を管理する

ユーザーを追加する

AWSアカウント自体を普段から利用ことは、パスワードが漏洩などした場合に契約や支払いを含め全権限があるため危険です。
普段利用としては、そう言った情報を扱わないアカウントを作成し、利用することが一般的です。

前提条件

AWSアカウントの取得が完了している状態
まだ、アカウントを追加していない方はこちら

IAMユーザーを作成する

サインインすると下記の画面が表示されます

画面上部の検索欄、もしくはサービスからIM検索し「IAMダッシュボード」を開きます

[ユーザー]を選択

ユーザー詳細の設定

[ユーザーの追加]を選択し、表示された画面を以下のように入入力し、[次のステップ]を選択

アクセス権限の設定

[既存のポリシーを直接アタッチ]を選択し、ポリシーを選美、[次のステップ]を選択
今回は全権限を持ったユーザーを追加するため、[AdministratorAccess]にチェックを入れる

タグの追加

何もせず、[次のステップ]を選択

作成の確認

内容に間違えがなければ、[ユーザーの作成]を選択

パスワードとサインインのURLの確認

[表示]を選択
この画面で先ほど自動生成したパスワードを確認し、保存します
※注意：以降再確認はできない
記載されているURLでコンソールへサインインができるので、こちらも保存します

IAMユーザーでのサインイン

作成したIAMユーザーで初めてサインインすると、パスワードの変更が求められます
任意のパスワードを設定してください
パスワードの変更ができたら、コンソール画面に戻ります
右上のユーザーの表示が切り替わっていることを確認してください

環境

• macOS
• EC2
• AMIは、Deep Learning AMI (Ubuntu 16.04) ← ここがミソ

問題

• ローカルのターミナルから、EC2インスタンスにログインする際に、

$: ssh -i keypair_for_xxxx.pem ec2-user@xx.xx.xx.xx
ec2-user@xx.xx.xx.xx: Permission denied (publickey).

とエラーが出てログインできない。

• なお、プライベートキーへの権限やpathなどは問題ない

原因

ユーザー名がec2-userではなく、ubuntuだった。
今まで、Railsで開発したアプリケーションを動かしていたため、AMIとしてAmazon Linux 2 または Amazon Linux AMIを用いてきた。そのユーザー名がec2-userだったため、デフォルトでユーザー名はec2-userだと思っていた。
しかし、AMIが異なるとユーザー名が異なることが分かった。

Amazon Linux 2 または Amazon Linux AMI の場合は、ユーザー名は ec2-user です。
CentOS AMI の場合、ユーザー名は centos です。
Debian AMI の場合は、ユーザー名は admin です。
Fedora AMI の場合、ユーザー名は ec2-user または fedora です。
RHEL AMI の場合は、ユーザー名は ec2-user または root のどちらかです。
SUSE AMI の場合は、ユーザー名は ec2-user または root のどちらかです。
Ubuntu AMI の場合は、ユーザー名は ubuntu です。

参考: https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/managing-users.html

解決

以下のようにユーザー名を変えたら接続できた。

$: ssh -i keypair_for_xxxx.pem ubuntu@xx.xx.xx.xx

概要

ビットコイン（や他の暗号資産）を定期的に購入するようなアプリケーションを開発しました。暗号資産取引所(bitflyer)のAPIを定期的にコールするようなアプリケーションを開発し、クラウドインフラ（AWS）上で運用を行っています。

ソースコードは以下です。
↓↓↓
https://github.com/Kohei-Sato-1221/reserve-bitcoin-lambda

アプリケーションのアーキテクチャ

• AWSのクラウドインフラを用いて以下のようなアプリケーションを構築しました。

技術スタック

名称	説明
AWS Lambda	サーバーレスアプリケーションを実現。Lambda関数で取引所のAPIをコールします。
Golang	Lambda関数はGolangで実装を行いました。
SAM(Serverless Application Model)	ローカルでLambdaの開発を行う際に使用。関数の雛形作成・関数のローカルでのエミュレート・関数のデプロイを行います。
Event Bridge	Lambda関数を定期的に実行する役割。
System manager（パラメータストア）	アプリケーションが使用するパラメータを格納。Lambdaがパラメータを取得します。

アプリ開発の経緯

2021年にビットコインの価格は６００万円台に達し、暗号資産は投資の対象として非常に注目度が高まっています。しかし、暗号資産のボラティリティは大きいので、一回の注文で多額の暗号資産を購入してしまうと、大きな含み損が発生してしまう可能があります。

そこで、少額の暗号資産を定期的に購入することで、価格変動のリスクを避けるような購入をしたいと考えました。まさに、ドルコスト平均法の考え方を適応したわけです。

なぜ既存の積立機能を使わないのか？

bitflyerやCoinCheckなどでは、ビットコインの積立機能を提供しています。しかし、私はあえてこのようなアプリケーションを実装しました。理由は、価格の点です。既存の積立機能は、基本的に販売所の価格となっており、板取引で購入できる金額よりも手数料が上乗せされています。取引所で暗号資産を取引したほうが安く入手できるのです。

技術的な解説

以下ではアプリケーションをどのような手順で構築したか解説します。

SAM(Serverless Application Model)の導入

SAMとはLambdaのようなサーバーレスアプリケーションの開発する際に役に立つ便利ツールです。これを使えば、Lambda関数の雛形を作成したり、Lambda関数をローカルでエミュレートしたりする（わざわざデプロイしなくても挙動が確認できる）ことができます。

AWS SAM CLIをローカルPCにインストールして、Lambdaの実装を開始しました。

新規注文APIをコールするLambda関数の実装

bitflyerのAPIをコールする機能をLambdaに実装しました。

func (client *APIClient) PlaceOrder(order *Order) (*OrderRes, error) {
    method := "POST"
    path := "/v1/me/sendchildorder"
    url := baseURL + path
    data, err := json.Marshal(order)
    if err != nil {
        return nil, err
    }

    header := client.getHeader(method, path, data)

    res, err := utils.DoHttpRequest(method, url, header, map[string]string{}, data)
    if err != nil {
        return nil, err
    }

    var orderRes OrderRes
    err = json.Unmarshal(res, &orderRes)
    if err != nil {
        return nil, err
    }

    if len(orderRes.ChildOrderAcceptanceId) == 0 {
        return nil, errors.New(string(res))
    }

    return &orderRes, nil
}

APIキー・APIシークレットキーの扱い

取引所の注文を行うには取引所のAPIキー・APIシークレットキーが必要になります。Lambda関数にはハードコーディングせずに外部に格納するようにしました。AWSにはSystems Manager パラメータストアという機能があります。このサービスに取引所のAPIキーやAPIシークレットを格納し、アプリケーション実行時にパラメータを取得しています。

    apiKey, err := getParameter("buy-btc-apikey")
    if err != nil {
        return getErrorResponse(err.Error()), err
    }
    apiSecret, err := getParameter("buy-btc-apisecret")
    if err != nil {
        return getErrorResponse(err.Error()), err
    }

Event Bridgeによるスケジューリング

Event BridgeというサービスではCron式を指定して、Lambdaの起動スケジュールを設定できます。 1日に１回、特定の時間にLambdaが起動するように設定しました。

 Udemyで講座を公開しました

こちらのアプリケーションの構築方法をUdemyの講座として公開しています。
暗号資産（仮想通貨）の基礎の解説や環境構築のハンズオン・ライブコーディングがまとまった教材となっております。

プロモーションコード欲しい方は、気軽にご連絡ください！