WAFのログをCloudWatchとS3に直接出力する際には、命名に注意する。 以下の２つの名前を、「aws-waf-logs-」から始まるようにしなければならない。 Cloudwatchのロググループ名 S3バケット名 参考サイト：https://dev.classmethod.jp/articles/aws-waf-log-support-s3-and-cloudwatch-logs/

概要 AWSのRDSにてMySQLインスタンスを作成する。 ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 前提 下記のすべての作業が完了していること。 AWS VPCの作成 AWS VPCの中にサブネットを作成する AWS RDS用のサブネットグループを作成する AWS RDS用のパラメータグループを作成する AWS RDS用のオプショングループを作成する AWS Webサーバー用のセキュリティグループを作成 AWS DBサーバー用のセキュリティグループを作成 作るものの情報 別記事で作成済みのサブネットグループを指定して2つをRDSのインスタンスを設置する。 AWS VPCの作成 AWS VPCの中にサブネットを作成する AWS RDS用のサブネットグループを作成する 別記事で作成済みのセキュリティグループを作成するRDSインスタンスに割り当てる。 AWS Webサーバー用のセキュリティグループを作成 AWS DBサーバー用のセキュリティグループを作成 別記事で作成済みのパラメータグループを作成するRDSインスタンスに割り当てる。 AWS RDS用のパラメータグループを作成する 別記事で作成済みのオプショングループを作成するRDSインスタンスに割り当てる。 AWS RDS用のオプショングループを作成する 項目 情報 備考 データベースの作成方法を選択 標準作成 エンジンのオプション MySQL バージョン 8.0.28 テンプレート 無料利用枠 AntekuAWSでDev環境を立てる時は「開発/テスト」を選択 DBインスタンス識別子（名前） dev-db マスターユーザー名 root マスターパスワード ******** DBインスタンスクラス バースト可能クラス（tクラスを含む） ストレージタイプ 汎用SSD デフォルト ストレージ割当 20GiB デフォルト ストレージの自動スケーリング 無し マルチAZ配置 スタンバイインスタンスを作成しないでください Virtual Private Cloud (VPC) dev-vpc サブネットグループ dev-subnet-group パブリックアクセス 無し デフォルト VPCセキュリティグループ 既存の選択 既存のVPCセキュリティグループ dev-dbを選択 defaultを✕で消す アベイラビリティゾーン ap-northeast-1a データベース認証 パスワード認証 デフォルト 最初のデータベース名 空欄 デフォルト DBパラメータグループ dev-mysql80 先に作成したやつ オプショングループ dev-mysql80 先に作成したやつ バックアップ 「自動バックアップを有効にします」にチェック デフォルト バックアップ保持期間 30日 バックアップウインドウ 選択ウインドウを選択 開始時間 → 19:00（JST 04:00）期間 → 0.5 スナップショットにタグをコピー チェックする デフォルト 拡張モニタリング有効化 チェックしない デフォルト ログのエクスポート チェックしない デフォルト IAMロール 入力しない デフォルト マイナーバージョン自動アップグレード チェックする デフォルト メンテナンスウインドウ 選択ウインドウを選択 開始日 → 日曜日開始時間 → 20:00（JST 05:00）期間 → 0.5 削除保護の有効化 チェックしない デフォルト 作成 AWSにログインしてRDSの画面に遷移する。 画面上の「データベースの作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 入力完了すると下記の様になる。 問題なさそうなら「　データベースの作成」をクリックする。 RDSのインスタンスが作成され、一覧に作成したものが表示される。

AWS CLIでaws configureを実行した際に自動生成される、default profile の名前を変更するとどうなるのか検証してみました。 前提 AWS CLI 情報：aws-cli/2.2.7 Python/3.8.8 Windows/10 exe/AMD64 prompt/off IAMユーザーを作成済み 結論 Unable to locate credentials. You can configure credentials by running "aws configure". というエラーが発生しました。 検証 1. aws configureを実行して default profile を自動生成 まずは、作成済みの IAM ユーザーの認証情報でaws configureを実行し、default profile を自動生成します。 aws configure AWS Access Key ID [None]: <Access Key ID> AWS Secret Access Key [None]: <Secret Access Key> Default region name [None]: region Default output format [None]: json 実行後に、credentials ファイルと config ファイルに以下の内容が記載されます。 [default] aws_access_key_id = <Access Key ID> aws_secret_access_key = Secret Access <Key> [default] region = ap-northeast-1 output = json ここまでで default profile を自動生成できました。 2. default profile でアクセスしてみる default profile の名前を変更する前に、default profile で S3 のバケット一覧を取得するコマンドを実行してみます。 aws s3 ls 実行結果は IAM ユーザーにアタッチしているポリシーによって変わりますが、僕はスイッチロール以外のポリシーはアタッチしていないので、アクセス拒否のエラーが返ってきました。 結果 An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied ここまでは想定通りです。 3. default profile の名前を変更してみる credentials ファイルの default profile の名前を test に変更してみます。 [test] aws_access_key_id = <Access Key ID> aws_secret_access_key = Secret Access <Key> 名前を変更した状態で再度 S3 のバケット一覧を取得するコマンドを実行してみます。 aws s3 ls 結果 `Unable to locate credentials. You can configure credentials by running "aws configure".` 「クレデンシャルが見つかりません。"aws configure"を実行してクレデンシャルを設定できます。」というエラーが返ってきました。 再度 default という名前に戻してからaws s3 lsを実行すると、 An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied のエラーが返ってきたので、default という名前を変更したことで発生したエラーのようです。 4. config ファイルを編集してみる credentials ファイルに加えて、config ファイルの profile 名も編集してみます。 [test] region = ap-northeast-1 output = json profile 名を default から test に変更し、aws s3 lsを実行してみます。 aws s3 ls 結果 Unable to locate credentials. You can configure credentials by running "aws configure". 3 と同じエラーが返ってきました。 検証により、以下のことがわかりました。 ・credentials ファイルの default profile がないとエラーになる ・credentials ファイルと config ファイルの profile 名を「default」以外で統一してもエラーになる ドキュメントには記載がない ドキュメントには、デフォルトで default profile を使用することは明記されていますが、default profile がないとどうなるのかということは記載されていませんでした。 設定ファイルと認証情報ファイルの設定 - AWS Command Line Interfaceより ファイルは profiles に分割されます。デフォルトで、AWS CLI は default という名前のプロファイルにある設定を使用します。替わりの設定を使用するには、追加のプロファイルを作成して参照できます。 まとめ AWS CLI でaws configureを実行した際に自動生成される、default profile の名前を変更するとどうなるのか検証してみました。 検証の結果、 Unable to locate credentials. You can configure credentials by running "aws configure" というエラーが出るということがわかりました。 解決策として、default という profile を記載しておく必要があることもわかりました。 参考にして頂ければ幸いです。

どんな状況？ RDSにEC2から接続したい。 keypairを使って接続する。 EC2に接続し、そこからRDSに接続する。 RDSでEC2のセキュリティグループを許可することでRDSに接続できるように設定済み。 テーブルの追加 右クリック→New→connectionでDBの種類を追加 では、sshトンネルで接続してみる Name: わかりやすいテーブルの名前 Status color: 好きな色 Host: RDSのエンドポイント Port: 3306 User: RDS作成時設定したユーザー名 Password: RDS作成時設定したパスワード Database: RDS作成時設定したDatabase名 Server: ec2のパブリックIPアドレス Port: 22 User: ec2-user Use SSH key: keypairのファイル 接続できた。

概要 AWSにてRDS用のオプショングループを作成する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 項目 情報 備考 名前 dev-mysql80 説明 dev-mysql80 エンジン mysql メジャーエンジンバージョン 8.0 作成 AWSにログインしてRDSの画面に遷移する。 サイドバーの「オプショングループ」をクリックする。 画面上の「グループを作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 入力完了すると下記の様になる。 問題なさそうなら「作成」をクリックする。 オプショングループが作成され、一覧に作成したものが表示される。

概要 AWSにてRDS用のパラメータグループを作成する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 項目 情報 備考 パラメータグループファミリー mysql8.0 タイプ DB Parameter Group グループ名 dev-mysql80 説明 dev-mysql80 作成 AWSにログインしてRDSの画面に移動する。 サイドバーの「パラメータグループ」をクリックする。 画面上の「パラメータグループの作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 入力完了すると下記の様になる。 問題なさそうなら「作成」をクリックする。 パラメータグループが作成され、一覧に作成したものが表示される。 一覧にデフォルトのパラメータグループも表示されているが、こちらは自動で作成されたものなので気にしない。

概要 AWSにてRDS用のサブネットグループを作成する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 前提 下記の作業が完了していること。 AWS VPCの作成 AWS VPCの中にサブネットを作成する 作るものの情報 下記で作成したプライベートサブネット2つを使ってグループを作成する。 AWS VPCの中にサブネットを作成する 項目 情報 備考 名前 dev-subnet-group サブネットグループが所属するVPC dev-vpc グループ化するサブネットの詳細 dev-private-subnet-1a と dev-private-subnet-1cのグループ化 作成 AWSにログインしてRDSの画面に移動する。 サイドバーの「サブネットグループ」をクリックする。 画面上の「DBサブネットグループを作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 入力完了すると下記の様になる。 問題なさそうなら「作成」をクリックする　。 サブネットグループが作成され、一覧に作成したものが表示される。

概要 最近CloudWatachでRDSのストレージ残り空き容量を監視したいことがあったので、手順を残します。 細かく画面の画像を用意しているので、初見の方でも設定しやすいように致しましたので、ご参考下さい。 アラーム作成 CloudWatchの画面から「アラームの作成」をクリック 「メトリクスの選択」をクリック 「RDS」クリックし、次に 「データベース別メトリクス」をクリック ↓↓↓↓↓↓↓↓ 該当するデータベースメトリクスを選択 該当するデータベースの「FreeStorageSpece」にチェックし、メトリクスの選択をクリックしてます この「FreeStorageSpece」がデータベース内のストレージ空き容量のことになります。 メトリクス設定 メトリクス部分はそのままでもOK 条件の設定 ここが重要です。 今回は例として、空き容量が3GBをより下回ったらアラートを出すようにしたいので、下記のように設定します。 しきい値の種類：静的 アラーム条件：以下 数値：3221225472（バイトで入力する必要があるので　3GB = 3221225472バイト　） 通知設定 アラートが発動した時の連絡手段を設定します。 アラーム状態トリガー：アラーム状態 SNSトピックの選択：※今回は「新しいトピックの作成」を選択します 新しいSNSトピックを作る場合は、以下を設定します。 トピック名：任意の名称（何でもいいですがメールグループ名みたいなものなので、汎用的使える名称の方が望ましい） エンドポイント：通知先のメールアドレス アクションについて 下スクロールしていくとアクション設定が出てきます。 しかし、今回はRDSなのでこの当たりは設定不要ですので「次へ」をクリックします アラーム名を入力 アラーム名はCloudWatachのアラート一覧に表示されるので、わかりやすい名称を入力します。 ※後から名称変更できないので注意 これでアラート作成を作成すると CloudWatachのアラート一覧にアラームの内容が表示されます。 新しいSNSトピック作った場合はまだやることがあるので、その場合は次に進みます。 SNS側の受け取り設定 SNSの画面を開く SNSの画面を開くと先ほど設定したメールアドレスがまだ保留中になっています。 これは通知先のメールアドレスの確認がまだできていないからです。 SNSからのメールを開いて受け取り承認を行う アラートを作成してしばらくするとAWSから以下のような確認メールが届きます。 メール本文にある「Confirm Subscription」のURLをクリックします。 URLを開くと以下のような画面になって承認が完了します。 改めてSNSページを見るとステータスが「確認済み」になっていればOKです。 これで全ての設定が完了しました。 もし設定した条件になったらアラートメールが飛ぶようになります。 ちなみに アラートが飛ぶと以下のようなメールが飛んできますので、ご参考までに。 以上となります。 参考になれば幸いです。

概要 AWSにてS3でバケットを作成する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 項目 情報 備考 バケット名 dev-bucket-example バケット名がかぶらないために苦し紛れの命名 リージョン ap-northeast-1 オブジェクト所有者 ACL無効（推奨）を選択 デフォルト このバケットのブロックパブリック・アクセス設定 「パブリックアクセスをすべてブロック」のチェックを外す バケットのバージョニング 無効にする デフォルト タグ 追加無し デフォルト デフォルトの暗号化 無効にする デフォルト 作成 AWSにログインしてS3の画面に移動する。 「バケットを作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 完了すると下記の様になる。 問題なさそうなら「バケットを作成」をクリックする。 バケットが作成され、一覧に作成したものが追加される。

概要 AWSにてWebサーバー用の基本的なセキュリティグループを作成する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 作成するセキュリティグループに別記事で作成したdev-vpcを割り当てる。 AWS VPCの作成 下記のセキュリティグループを作成する。 項目 情報 備考 セキュリティグループ名 dev-db 説明 dev-db セキュリティグループを割り当てるVPC dev-vpc タイプ MYSQL/Aurora インバウンドにルール追加 プロトコル TCP インバウンドにルール追加 ポート範囲 3306 インバウンドにルール追加 ソース dev-web ソースの隣の欄の虫眼鏡マークをクリックセキュリティグループ（web用）のセキュリティグループを指定 作成 AWSにログインしてEC2の画面に移動する。 サイドバーの「セキュリティグループ」をクリックする。 画面上の「セキュリティグループを作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 入力完了すると下記の様になる。 問題なさそうなら「セキュリティグループを作成」をクリックする。 セキュリティグループが作成され、一覧に作成したものが追加される。

概要 AWSにてWebサーバー用の基本的なセキュリティグループを作成する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 作成するセキュリティグループに別記事で作成したdev-vpcを割り当てる。 AWS VPCの作成 下記のセキュリティグループを作成する。 項目 情報 備考 セキュリティグループ名 dev-web 説明 dev-web セキュリティグループを割り当てるVPC dev-vpc 追加するインバウンドルール No タイプ プロトコル ソース 備考 1 SSH TCP 22 Anywhere-IPv4 0.0.0.0/0 2 HTTP TCP 80 Anywhere-IPv4 0.0.0.0/0 3 HTTPS TCP 443 Anywhere-IPv4 0.0.0.0/0 作成 AWSにログインしてEC2の画面に移動する。 サイドバーの「セキュリティグループ」をクリックする。 画面上の「セキュリティグループを作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 入力完了すると下記の様になる。 問題なさそうなら「セキュリティグループを作成」をクリックする。 セキュリティグループが作成され、一覧に作成したものが追加される。 一覧で作成されたセキュリティグループを選択し、下部の「インバウンドルール」のタブを選択し、「インバウンドのルールを編集」をクリックする。（※こちらの作業の手順が抜けていたのでこれ以降は後から追記） 「ルールを追加」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 入力完了すると下記の様になる。 問題なさそうなら「ルールを保存」をクリックする。 セキュリティグループdev-webにインバウンドルールが追加される。 これだけだとまだ22番ポートを使ってssh接続するインバウンドルールしか存在しないので、80番ポートを使ってhttp、443番ポートを使ってhttpsの通信をするルールを記載する。 一覧で作成されたセキュリティグループを選択し、下部の「インバウンドルール」のタブを選択し、「インバウンドのルールを編集」をクリックする。 「ルールを追加」をクリックする。 「作るものの情報」に記載したインバウンドルールのHTTPとHTTPSの内容に沿って入力を行う。 入力完了すると下記の様になる。 問題なさそうなら「ルールを保存」をクリックする。 セキュリティグループdev-webにインバウンドルールが追加される。

概要 EC2 → S3の接続に必要な権限を持ったIAMユーザーを作成する方法をまとめる ご注意 AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 項目 情報 備考 名前 dev-admin AWSアクセスの種類 プログラムによるアクセス アクセス許可の設定 既存のポリシーを直接アタッチ → AmazonS3FullAccess 作成 AWSにログインしてIAMの画面に移動する。 サイドバーの「ユーザー」をクリックする。 画面上の「ユーザーを追加」をクリックする。 「作るものの情報」に記載した内容に従って入力を行う。 1ページ目の入力は下記の様になる。 2ページ目の入力は下記の様になる。 確認画面は下記の様になる。（タグは特に設定しなかった） 問題なさそうなら「ユーザーの作成」をクリックする。 最後のページでcsvのダウンロードが行えるのでダウンロードし、大切に保管する。

概要 AWSでルートテーブルを作成しインバウンドルールを追加する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 下記の情報でルートテーブルを作成し、0.0.0.0/0のアクセスを別記事で作成したインターネットゲートウェイに紐付けるルールを定義する。 AWS インターネットゲートウェイの作成 項目 情報 備考 名前 dev-route 関連付けするパブリックサブネット dev-public-subnet-1a タグ 入力する キー → Name値 → dev-route デフォルトルートとigwの紐付け 0.0.0.0/0 → dev-igw 作成 AWSにログインしてVPCの画面に移動する。 サイドバーの「ルートテーブル」をクリックする。 画面上の「ルートテーブルを作成」をクリックする。 「作るものの情報」に記載した内容に従って入力を行う（0.0.0.0/0とインターネットゲートウェイの通信の紐付けはルートテーブル作成後に実施） 入力完了すると下記の様になる。 問題なさそうなら「ルートテーブルを作成」をクリックする。 ルートテーブルが作成されルートテーブル一覧に作成したものが追加される。 一覧で只今作成したルートテーブルを選択し、下部の「ルート」タブをクリックし、「ルートを編集」をクリックする。 「ルートを追加」をクリックする。 送信先を「0.0.0.0/0」を選択、ターゲットを別記事で作成したdev-igwを選択、「変更を保存」をクリックする。 ルートの追加後下記の様になっていればOK

CDKとかCloudFormation使うときにたまに使いますが、いちいち調べに行くのも面倒なので、調べ方＋現時点におけるManagedPolicyのリストを載せて起きます。 リストアップするコマンド aws iam list-policies --only-attached |\ jq -r '.Policies[] | select(.Arn | startswith("arn:aws:iam::aws:policy") ) | .PolicyName' jqでPolicyNameのみとりだしてるので、全情報ほしければ aws iam list-policies --only-attached |\ jq -r '.Policies[] | select(.Arn | startswith("arn:aws:iam::aws:policy") )' 特定の名前のものだけフィルターしたければ aws iam list-policies --only-attached |\ jq -r '.Policies[] | select(.Arn | startswith("arn:aws:iam::aws:policy")) | select(.PolicyName | contains("S3"))' PolicyNameとArnのみ残したJson化 aws iam list-policies --only-attached |\ jq -r '[ .Policies[] | select(.Arn | startswith("arn:aws:iam::aws:policy")) | { PolicyName: .PolicyName, Arn: .Arn} ]' \ > policies.json 現時点のManagedPolicyの一覧 2022/3/3時点のManagedPolicy 補足 ManagedPolicyのNameを指定するときに、ARNのpolicy/の後が、arn:aws:iam::aws:policy/aws-service-role/XXXやarn:aws:iam::aws:policy/service-role/YYY となっている場合は、aws-service-role/XXXやservice-role/YYYと指定する必要があります。名前だけを渡すとそんなManagedPolicy存在しないと怒られるので、AWS Consoleとかからコピペって来た場合は、ARNの前部分を確認してみてください。

概要 AWSでインターネットゲートウェイを作成する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 別記事で作成したdev-vpc用にインターネットゲートウェイを作成する。 AWS VPCの作成 下記のインターネットゲートウェイを作成する。 項目 情報 備考 名前 dev-igw タグ 入力する キー → Name値 → dev-igw アタッチするVPC dev-vpc 作成 AWSにログインしてVPCの画面に移動する。 サイドバーの「インターネットゲートウェイ」をクリックする。 画面上の「インターネットゲートウェイの作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う（VPCとのアタッチはインターネットゲートウェイ作成後に実施） 入力完了すると下記の様になる。 問題なさそうなら「インターネットゲートウェイの作成」をクリックする。 インターネットゲートウェイが作成され、インターネットゲートウェイ一覧に作成したものが追加される。 一覧で只今作成したインターネットゲートウェイを選択し、右上の「アクション」をクリックし「VPCにアタッチ」をクリックする。 「dev-vpc」を選択して「インターネットゲートウェイのアタッチ」をクリックする。 dev-vpcにアタッチされた。

概要 AWSにてVPCの中にパブリックサブネットとプライベートサブネットを作成する ご注意!!! AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 別記事で作成したdev-vpcの中にパブリックサブネット1つとプライベートサブネット2つを作成する。 AWS VPCの作成 パブリックサブネット 項目 情報 備考 VPC ID（所属VPC） dev-vpc サブネット名 dev-public-subnet-1a アベイラビリティゾーン ap-northeast-1a IPv4 CIDRブロック（IPアドレスの範囲） 10.0.10.0/24 タグ 入力する キー → Name値 → dev-public-subnet-1a プライベートサブネット_1 項目 情報 備考 VPC ID（所属VPC） dev-vpc サブネット名 dev-private-subnet-1a アベイラビリティゾーン ap-northeast-1a IPv4 CIDRブロック（IPアドレスの範囲） 10.0.20.0/24 タグ 入力する キー → Name値 → dev-private-subnet-1a プライベートサブネット_2 項目 情報 備考 VPC ID（所属VPC） dev-vpc サブネット名 dev-private-subnet-1c アベイラビリティゾーン ap-northeast-1c IPv4 CIDRブロック（IPアドレスの範囲） 10.0.21.0/24 タグ 入力する キー → Name値 → dev-private-subnet-1c 作成 AWSにログインしてVPCの画面に移動する。 サイドバーの「サブネット」をクリックする。 画面上の「サブネットを作成」をクリックする。 「作るものの情報」に記載した内容に沿って入力を行う。 入力完了すると下記の様になる。 パブリックサブネット プライベートサブネット_1 プライベートサブネット_2 問題なさそうなら「サブネットを作成」をクリックする。 合計3つのサブネットが作成され、サブネット一覧に作成した各サブネットが追加される。

目的 s3 のバージョニング有効化後の見え方を確認 バケット新規作成 S3 トップ画面から "バケット作成" を選択 バケット名と AWS リージョンを指定 オブジェクト所有者はそのまま パブリックアクセスをすべてブロックを有効(デフォルト) バージョニングを有効化 タグは適宜 サーバ側の暗号化(テストなので無効) オブジェクトロック(オブジェクトを誤って上書き防止する機能)もそのまま 設定値を確認して "バケットを作成" を選択 数秒待って作成完了 フォルダ作成後、ファイルをアップする すぐ削除するのでスタンダートクラスでアップ 対象ファイルを更新してアップロード。その後バージョン確認 ファイル保存後、複数の操作が可能 ストレージクラス編集 その他メタデータやタグ編集 クエリ生成など 最後のバケット削除 ※ パケットは空でないと削除不可 バケットを空にしてから削除実施 おしまい s3 ストレージクラスの特徴はもう少し理解する必要がある

概要 AWSにてVPCを作成する ご注意！！！ AWSは従量課金です。 本作業で料金が発生する可能性があります。 筆者は本作業で発生するいかなる料金も負担する事ができません。 ご自身の責任の下作業をお願いいたします。 作るものの情報 項目 情報 備考 リージョン ap-northeast-1 名前 dev-vpc IPアドレスの範囲 10.0.0.0/16 IPv6の紐付け 無し テナンシーの設定 デフォルト 作成 AWSにログインしてVPCの画面に移動する。 現在のリージョンが東京リージョンになっている事を確認する。 画面上の「VPCを作成」をクリックする。 下記のように設定する。 項目 情報 備考 リージョン ap-northeast-1 作成するリソース 「VPCのみ」を選択 デフォルト 名前タグ dev-vpc IPv4 CIDRブロック 「IPv4 CIDR ブロックの手動入力」を選択 デフォルト IPv4 CIDRブロック（IPアドレスの範囲） 10.0.0.0/16 IPv6 CIDRブロック（IPv6の紐付け） 無し テナンシーの設定 デフォルト タグ 入力する キー → Name値 → dev-vpc 下記の様になる。 問題なさそうなら「VPCを作成」をクリックする。 VPCが作成され、VPC一覧に作成したVPCが追加される。

はじめに 認証にAmazon Cognitoを使うと、ユーザログインのログはどこに出るのか。確認したいと思います。できれば、簡単に安く見たい。 よくありませんか？ 「この時間帯（○○：○○〜○○：○○）にログインしたユーザを知りたい。教えてー」 なんてこと。 認証にCognito使ってるからどこかにログ出てるよねーっと思ったら、AWSマネジメントコンソールを見てもパッとわからないのですよね。 で、どこなんだ？？ 公式ドキュメント 公式ドキュメントのログ出力について見てみます。 AWS CloudTrail – CloudTrail では、Amazon Cognito コンソールからの API コール、および Amazon Cognito API オペレーションへのコードコールをキャプチャできます。例えば、ユーザーが認証すると、CloudTrail はリクエストの IP アドレス、リクエストの実行者、および実行日時などの詳細を記録できます。 上記の通り、ログはAWS CloudTrailに出力されます。 よしよし、見れそうです。 では、CloudTrailでユーザログインを確認できるのか確認します。 CloudTrail CloudTrailでイベント名「InitiateAuth」を検索します。 1イベント選択して、イベントの詳細を見てみます。 Cognitoのユーザ名は出てきませんが、ログインが行われ、アクセストークン、IDトークン、リフレッシュトークンが発行されていることがわかります。（responseElementsの箇所です。） このイベントでは、 "additionalEventData": { "sub": "e04c2fc8-1cc8-4255-92ec-b6304e9d6291" } のsubがCognitoユーザを表しています。 Cognitoのsubは、ユーザーを一意に識別するための識別子となります。 ユーザ名を取得するには、subを利用してAWS CLIで実行することが必要になります。 AWS CLIで取得してみる 一発のコマンドでは確認できないことがドキュメントを見てわかりました。 コマンドをいくつか利用して取得できますので、少し応用してスクリプトを作りました。 CloudTrailのイベントログを取得し、その中にあるsubからユーザ名を取得し、一覧化するものになります。 ※jqコマンドを使っていますので、インストールが必要です。AWS CloudShellはインストールされていますので、簡単に実行することができます。 #!/bin/sh # ※　Cognito UserPool IDを設定します。 export user_pool_id=ap-northeast-1_XXXXXX # ※　確認したい時間範囲の開始、終了時刻を指定します。 export start_time=2022-03-01T22:00:00.000+09:00 export end_time=2022-03-02T00:00:00.000+09:00 # 結果出力ファイル echo '"eventTime","eventName","requestParameters.clientId","responseElements.challengeName","sourceIPAddress","additionalEventData.sub","CognitoUsername","errorMessage"' > result.csv # CloudTrailのイベント取得 events=`aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=InitiateAuth --start-time $start_time --end-time $end_time \ | jq -r '[.Events[].CloudTrailEvent]'` events_length=`echo $events | jq length` for i in `seq 0 $(($events_length - 1))` do echo No.$(expr $i + 1) element=`echo $events | jq -r .[$i]` cognito_user_sub=`echo $element | jq -r '.additionalEventData.sub'` # ユーザ名取得 echo get user_name. cognito_user=`aws cognito-idp list-users --user-pool-id $user_pool_id --filter "sub = \"$cognito_user_sub\""` cognito_user_name=`echo $cognito_user | jq -r '.Users[0].Username'` # Cgonito - Username追加 element=`echo $element | jq ". |= .+ {\"CognitoUsername\": \"$cognito_user_name\"}"` # 出力 echo $element | jq -r '[.eventTime, .eventName, .requestParameters.clientId, .responseElements.challengeName, .sourceIPAddress, .additionalEventData.sub, .CognitoUsername, .errorMessage] | @csv' >> result.txt done スクリプトを実行するとresult.csvが出力されます。項目などを調整すると、他の項目も出力できます。 出力結果を確認する スクリプトを実行し、出力した結果は以下です。（マスキングしている箇所あり） ログイン時刻、Cognitoのユーザ名、エラーメッセージが確認できます。エラーメッセージがあれば、ログイン失敗となります。 "eventTime","eventName","requestParameters.clientId","responseElements.challengeName","sourceIPAddress","additionalEventData.sub","CognitoUsername","errorMessage" "2022-03-01T14:00:42Z","InitiateAuth","XXXXXXXXXXXXXXXXXXX",,"XXX.XXX.XXX.XXX","e04c2fc8-1cc8-4255-92ec-b6304e9d6291","cog-log-user", "2022-03-01T14:00:35Z","InitiateAuth","XXXXXXXXXXXXXXXXXXX",,"XXX.XXX.XXX.XXX","e04c2fc8-1cc8-4255-92ec-b6304e9d6291","cog-log-user","Incorrect username or password." "2022-03-01T14:00:25Z","InitiateAuth","XXXXXXXXXXXXXXXXXXX",,"XXX.XXX.XXX.XXX","e04c2fc8-1cc8-4255-92ec-b6304e9d6291","cog-log-user", まとめ CloudTrailのログでCognnitoのユーザ名まで判別することは難しいので、AWS CLIを駆使してユーザログインのユーザ名を含むログを取得することができました。 また、少し費用がかかりますが、アドバンストセキュリティ（高度なセキュリティ）の機能を使うとAWS CLIを駆使しなくともユーザのログイン履歴が確認できます。←こちらの方が見やすいですね（笑）

AWSのCloudFrontと連携させてLambdaを動かすことのできるLambda＠Edgeについて、先日初めてちゃんと使ったのですが、その時に少し困ったことがあったのでその内容を備忘もかねて記載しておきます。 困った内容 Lambda＠Edgeをバージニア北部リージョンで新規作成（Edge用のLambdaはバージニア北部リージョンで作成する必要がある）し、Lambdaのバージョンを作成してデプロイ＆CloudFrontトリガーを追加してディストリビューションとの紐付けまで行った。 ここまで行うことでCloudFrontにアクセスがされる都度対象のLambda関数が実行されるはず。 ということで実際にCloudFrontに対して通信を行なってから以下で確認を行った。 バージニア北部リージョンを指定した状態でマネジメントコンソールでLambdaを選択 対象のLambda関数の「モニタリング」タブを選択 メトリクス及びログを確認 上記を行ったところ、いくら待ってもメトリクス・ログともデータが全くない状態のままであった。 解決方法 Lambda＠Edgeの情報についてはLambda関数側ではなく以下を確認することでメトリクスとログが確認が可能 マネジメントコンソールでCloudFrontを選択 テレメトリーの「モニタリング」を選択 Lambda＠Edgeタブを選択 対象のLambda＠Edgeを選択して「メトリクスを表示」を選択 上記でメトリクスが表示される。2022/3時点のマネジメントコンソールではこの画面の右上に「関数ログを表示」というボタンがあり、そこから接続していると思われるリージョン（日本の場合は多くは東京リージョン？）を選択すると対象のログも表示される。 ロググループ名の命名規則は以下のような感じ。 /aws/lambda/us-east-1.(Lambda関数名) よく探したら以下のページにLambda＠Edgeのメトリクスの確認手順は書いていました。 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html Lambdaに慣れていると当たり前のようにLambdaのメトリクスを見て何も来ないな〜と思ってしまうかもしれないので参考になればと思います。

概要 AWSにてベーシックなWebサービスをデプロイする際に必要な内容をリストにしてまとめてみる ご注意 筆者はAWS初心者です。もっと良い構築方法は必ずあります。抜け漏れもあるはずです。 仕様 AWS　EC2 AmazonLinux2インスタンスを用いてWebサービスを提供する。データはRDSのMySQLに格納する。 専用のVPCを作成する。 VPCの中にパブリックサブネット1個とプライベートサプネットを2個を定義する。 EC2インスタンスはパブリックサブネット内に設置 2個のプライベートサブネットはサブネットグループとしてグルーピングする。 プライベートサブネットのサブネットグループはパブリックサブネットからのみ接続できる。 EC2で提供するサービスはパブリックIPアドレスを用いてブラウザからアクセスするものとする（Route53でのドメインとIPの紐付けはしない） デプロイするアプリケーションでアップロードされるファイルなどはS3に格納する やること ネットワーク部分の設定 VPCの作成 作成前に決めておく内容 リージョン VPCの名前 IPアドレスの範囲（例: 10.0.0.0/16） IPv6の紐付け有無 特別必要にならない限り無し（IPv6 CIDRブロックなしを選択） テナンシーの設定 特別必要にならない限りデフォルト（デフォルトを選択） サブネットの作成 作成前に決めておく内容 パブリックサブネット サブネットの名前（例: XXX-public-subnet-アベイラビリティゾーン名） このサブネットを所属させるVPCの名前 アベイラビリティゾーン IPアドレスの範囲（例: 10.0.10.0/24） プライベートサブネット１つ目 サブネットの名前（例: XXX-private-subnet-アベイラビリティゾーン名） このサブネットを所属させるVPCの名前 アベイラビリティゾーン IPアドレスの範囲（例: 10.0.20.0/24） プライベートサブネット2つ目 サブネットの名前（例: XXX-private-subnet-アベイラビリティゾーン名） このサブネットを所属させるVPCの名前 アベイラビリティゾーン IPアドレスの範囲（例: 10.0.21.0/24） インターネットゲートウェイの作成 作成前に決めておく内容 インターネットゲートウェイの名前（例: XXX-igw） 作成したインターネットゲートウェイと既に作成されているVPCのアタッチ ルートテーブルの作成 作成前に決めておく内容 ルートテーブルの名前（例: XXX-route） 作成したルートテーブルと既に作成されているパブリックサブネットとの関連付け 作成したルートテーブルにデフォルトルート（0.0.0.0/0）と先に作成したインターネットゲートウェイと紐付けルートを追加 IAMユーザー作成（S3アクセスで使用） 作成前に決めておく内容 名前（例: XXX-admin） AWSアクセスの種類 プログラムによるアクセス（S3アクセスで使うので） アクセス許可の設定 既存のポリシーを直接アタッチ AmazonS3FullAccessを選択 作成時に取得できるcsvファイルは大切に保管する EC2部分の設定 EC2インスタンスの作成 作成前に決めておく内容 AMI（OSの種類など） インスタンスタイプ（スペック） ストレージ（EBS or インスタンスストア） 特別必要にならない限り汎用SSDを選ぶ 合わせて削除にチェックを入れる 当該EC2設置するVPC 当該EC2を設置するサブネット 自動割当パブリックIPの有無 Webからアクセスしたいので「有効」 割り当てるプライベートIP（例: 10.0.10.10） インスタンスの名前 タグの追加でキー → name、値 → インスタンス名 セキュリティグループ 名前（例： XXX-web） 設定 設定を割り当てるVPC RDS部分の設定 MySQLのRDSインスタンスの作成 作成前に決めておく内容 セキュリティグループ名と設定 名前（例: XXX-db） 設定 設定を割り当てるVPC インバウンドにルールを追加（既に存在するEC2からのみ接続できるようにする。） タイプ MYSQL/Aurora プロトコル TCP ポート範囲 3306 ソース EC2のセキュリティグループ サブネットグループ 名前（例: XXX-subnet-group） グループ化するサブネットが所属しているVPC グループ化するサブネットの詳細（名前とアベイラビリティゾーン） パラメータグループ グループファミリー お使いのバージョンに合わせて決定 名前（例： XXX-mysql80 ←MySQL8.0を使う場合） オプショングループ 名前（例: XXX-mysql80 ←MySQL8.0を使う場合） エンジン お使いのDBエンジンに合わせて決定 メジャーエンジンのバージョン お使いのDBエンジンのバージョンに合わせて決定 インスタンス DBエンジン DBエンジンのバージョン テンプレート（本番稼働用？開発テスト用？無料利用枠？） 名前「DBインスタンス識別子」（例: XXX-web ←web用のDBなので） マスターユーザー名 基本はroot マスターパスワード 忘れない かつ セキュリティが高いものに設定 インスタンスサイズ（標準mクラス？ メモリ最適化rクラス or xクラス？ バースト可能tクラス？） ストレージタイプ 特別必要にならない限り汎用ssd ストレージの自動スケーリング有無 マルチAZ配置有無（料金安くしたいなら「スタンバイインスタンスを作成しないでください」） RDSインスタンスを設置するVPC RDSインスタンスを設置するサブネットグループ パブリックアクセス可否 セキュリティグループ 先に作成したセキュリティグループ（DB用） アベイラビリティゾーン ポート 特別理由が内限り3306 割り当てるパラメータグループ 割り当てるオプショングループ 自動バックアップの有無 有効に設定 →　30日くらいの保持期間がおすすめ バックアップ取得時の時間（UTCで設定） マイナーバージョン自動アップグレードの可否 有効がおすすめ バージョンアップの時間（UTCで設定） S3部分の設定 バケットの作成 作成前に決めておく内容 名前（例: 任意のわかりやすい名前） リージョン バージョニング 特別必要がなければ不要 サーバーアクセスのログ記録 本番環境では必要かも？ デフォルト暗号化 本番環境では必要かも？ アクセス権限 画像や動画配信する場合はパブリックアクセス許可しておく

こんにちは、技術的な話を書くことで技術警察に怒られてコメント欄が炎上して、令和のジャンヌダルクになるのが怖いむっそです。 先日書いた記事がなんだかトレンドに入ってしまって、LGTMをもらう度に 「もっと...LGTMください」 みたいな感じになってます。 これは禁断症状寸前です。 これでTikTokで承認欲求丸出しで踊りまくってる女子高生やベンチャー広報社員の気持ちが分かるようになって、ブログを書く楽しさに気づけました。 読んでいただいた方、ありがとうございます！我多大感謝！ 今回はN=1のスタートアップ転職あるある を書いていくのですが、技術ゴリゴリな話よりかはもっとソフトな話をしたいと思います。 お昼休みのあいだで頭使わないで読むのに最適です。ただし今回は文章が多く脱線も時々するので、好きなところから、つまんで読んでもらっても良いですね。 はじめに なんだか最近は 転職するならスタートアップか？大企業か？ みたいな選択肢を持つエンジニアが増えてる気がします。スタートアップの自由度や働き方は楽しそうだけど 「スタートアップに踏み出すのが怖いなぁ」 というエンジニアの方とかに読んでもらえれば嬉しいです。 全体的なテーマとしては、スタートアップ転職する前の自分が読んだらちょっと安心できるだろうなというのがテーマです。 それちゃうねん的なコメントもお待ちしてます。 個人ブログなのでポジショントークも、意味不明なマウントも、キラキラした意識高い言葉も無いはず...です。 ご安心ください！ そうは言っても君は何者や 私自身の話をすると2017年くらいに大きめの企業の新規事業の開発をしてて、訳あって2021年8月あたりにダイレクトリクルーティングを中心に転職活動をしていました。そのときは思った以上にスタートアップからのスカウトがくるなぁ というのが印象でした。 そんなこともあって、スタートアップという選択肢もアリなのかもと思い始めて、カジュアル面談をたくさんした結果、ご縁をいただいて2021年10月くらいにスタートアップに正社員で転職して、今もそこで働いています。 正社員エンジニア3人、業務委託5人くらいの開発体制でやってて営業なども含めて全員で10人弱くらいの会社です。 前職が1000人以上いるような会社なのでまぁ転職怖かったですね... スタートアップ転職して良かったか 多分一緒に働いている人と性格的に合うかどうかが8割くらいだとは思いますが、結論的には転職して良かったです。 良いことと悪いことは表裏一体なのでメリット/デメリットという軸ではなく、スタートアップあるあるを書いていきます。 あとは企業に属するという部分は大企業とかでも変わらず、企業ガチャや上司ガチャはもちろんありますので、こういう世界線があるんだなぁ程度に読んでいただくと良いかと... あるあるとか言いつつ、織田裕二がレインボーブリッジを封鎖できるくらいには予防線を張りまくっております スタートアップ転職活動中あるある 書類選考は前職/現職の仕事内容を詳細に書くと受けが良い 大きめの企業にいるときもエンジニア採用にちょっと関わっていたので、面接する側の知見を存分に生かしまくって、出汁をふんだんに取り尽くして転職しました。面接する側の時に思ったのは 「職務経歴書とかにもっと詳細な情報書けば良いのに」 と思うことは多かったです。 多分ビ〇リーチとかのフォーマットで綺麗に箇条書きで書いてるのはわかりやすいのですが、 AWS3年 とか書かれても読み手はふぁぁ？？ なんですよね。IT3年やってましたくらいに情報量が不足しています。 転職って 「私はこれができます！」っていうシグナルをだす場なので、どういう経緯でシステムを作っていてその仕事はマネージャーだけをしたのか、ガッツリ現場で開発してたのか、大変だった苦労話とか課題をどうテクニカルに解決したのかみたいなのは知りたいと思うわけです。 なので私は職務経歴書に具体的な課題やらどんなAWSサービスを使ったかとか書けることは書きまくりました。 (話すのだるいから察してくれという気持ちもありますが) 特にスタートアップは人やスキルの不一致を大変恐れているので書類選考は詳細に書きまくる作戦のおかげで通過率は割と良かったのではないかと思ってます(自慢ぽいのはここだけです) もっとこの辺の話を理論的にやってるのは情報の経済学とかで出てくる情報の非対称性 あたりの話ですね。 一応経済学部出身なので、ちゃんと使えそうなうんちくみたいなのは書いておきます ざっくり言うと、売り手(転職する人)は自分のことをよく知っているので、自分が使えないク〇人間と分かっていても相手に対して自分を大きく見せたり知識人ぶったりできるのですが、買い手(企業側)は面接時間などでの短さではそれがハッタリなのか、実力なのか判断できないため騙されてしまう。みたいなやつです。 これを解決するためには 売り手側では「自分の実力はこんなんですよ」と情報を開示する(シグナリング) 買い手側は売り手に対して情報を開示させたり試験をさせることで真の実力を把握する(スクリーニング) とかをちゃんとすることで情報の非対称性をなくしていこうぜ！って感じです。 職務経歴書に自分の情報を書きまくるのはめっちゃシグナリングです。 ちなみに技術ブログもめっちゃシグナリングです。 シグナルを出すのは大事ですが、変なシグナルを出して社会からSIGKILLされないように頑張らねば... (なぜか分からないSIGTERMで、どん詰まった過去の記憶を唐突に思い出す) カジュアル面談するだけで企業の色が結構見えてくる スタートアップ怖いのでカジュアル面談は20社くらいはしました。ダイレクトスカウトのメールを80通くらいは読んで、 日本スタートアップ多すぎですやん 、と思ったくらいです。業務内容とか知って良さそうと思ったところはすぐカジュアル面談をしたのですが、会社によってカジュアル面談の色が違うんですね、これが。 どんな感じのやつがあったのか例を出すと スカウトメールでは「CTOから直接スカウトしてるんですよ」みたいな文面だったのにカジュアル面談は人事担当のみ、使ってる技術スタックの話が全くできない CTOっぽい人は出てきたけど、カジュアル面談をあまり知らないのか志望動機聞いてきた。 (CTOさんさー、まだ御社に志望すらしてないからねー、あともう少し笑顔の練習してくださいね、面接じゃないのでね。あとそこの人事担当、お前もだぞ？) プロジェクトマネージャーと現場エンジニアという組み合わせは良かったものの現場エンジニアのクセが強すぎて意思疎通できずマネージャーが苦笑いしてて、あっ察しってなるやつ めちゃくちゃ高齢な技術力強そうな人出てきたけど技術スタックを聞くとEC2ばかり出てくる (EC2はクラウドではないです、コンテナ化頑張ってください(クラウド過激派)) 普通に現場エンジニアからワクワクする技術スタックの話とかするのを期待してても、それができるのは思った以上に少なかった印象ですね。カジュアル面談してない現場の人たちは多分クラウド技術やアジャイルばりばりでやってるのかもしれん のだがね、カジュアル面談に出てきておくれよ。 まぁ悪い例ばかり目にはつきましたが、すごく刺激になったカジュアル面談もあるのでそういう会社に出会えるのは良い経験でした。 脱線しますが、カジュアル面談ってマッチングアプリ使い慣れてる人はうまい気がする んですよね。 いきなり家に連れ込もうとする(例:あなたの志望動機はなんですかと面接みたいなこと聞いてくる)のは普通に引くわけですよ。 最終目的がベッドだとしても、ちょっとお互いのためにスタバで軽くお茶ししましょうっていう隙間が大事ですよね。 そういうやつですよ つまりマッチングアプリをうまく活用してる人は多分カジュアル面談がうまいということです、知らんけど コーディング試験失敗しがち(私の能力不足10割) これは私のエンジニア人生の盲点でしたが、コーディング試験は対策なり日頃からアルゴリズムの勉強した方が良さそうです。 書類は割とつよつよだったのですが、コーディング試験よわよわでした笑 ホワイトボーディング試験とかやらされた時は頭がホワイトアウトしてましたよ。繊細さんには辛い試験です。 日頃の仕事デバッガ無しでやってるの君ら？って憤慨です 言い訳するとフレームワークやら標準ライブラリの恩恵を受けてるので、アルゴリズム試験でその人の力を見るのははうーんって感じです。1日職業体験とか、副業から初めて仕事のマッチングが良さそうだったら正社員みたいな方が多分お互い良いと思いますけどねぇ。 アルゴリズム力というか技術力が高いことと、仕事できるかどうかはあんま関係ない気がします。 (また過去の思い出が走馬灯のようによぎる) もちろん計算量とか裏側のCPUなどに想いを馳せるのは大事ですし、アルゴリズムゴリゴリな仕事ならそういう試験が適切です。 決して競プロは仕事に役に立たないとかそういう批判はしてないですからね、ほんとですよ。許してクレメンス 企業によるが年収はあまり期待しない方が良いのかも スタートアップで内定をもらってオファー面談をするわけですが、まぁ前職よりマイナスにはなりました。 スタートアップのフェーズがまだ初期段階ってのもありますし私自身の成長を優先してとりあえず受諾しましたが、 個人の実力とか企業によって年収なんてコロコロ変わりますからね、と思います。 よく言われる、スタートアップのストックオプションの話ですが前もって調べてみると良いかもですね。 スタートアップなんで数年で上場する可能性はありますし、ストックオプションを行使したら数10倍も儲けられるみたいなことを想像すると、夢がありますよね。 50兆円欲しい！！ いつまで今の会社にいるか分からないですがw スタートアップ転職後あるある 技術の幅が広がる これは企業のステージとか役割次第ですがフルスタックエンジニアという募集で採用されると、とりあえずフロントエンドもバックエンドもデザインの話し合いも基本参加します。 なので バックエンド、ウェブアプリ、モバイルアプリ、プロジェクトマネジメント、ランディングページ作成、デザイン、設計アーキテクチャなどいろんなことに触れる機会はあるんではないでしょうか。 私自身がバックエンドとかインフラ寄りのキャリアだったので、 デザイン作成から開発チケット作成、実装、ユーザーの声を聞くまでをまるっと追える ので、やりがいは感じやすい気はします。 特にデザインは 「この他社のモバイルアプリのデザイン良さそうだから弊社でもどうすか」 みたいなのも話せたりしてデザインが人に与える印象って大事やなぁと思います。 ちょっと脱線しますが、デザインの本で好きなのは 「オブジェクト指向UIデザイン」 ですね。React NativeとかでToDoアプリ作ったあとくらいにこの本を読むと心に染みます。 特に旧石器時代からの人と道具の関係にまで言及してて、オブジェクト指向が持つ壮大な歴史を感じさせてくれます。ぜひ読んでみてください。まぁわたしは相変わらずCSSでつまづいておりますが笑 最新技術に触れやすい 経理システムとかの話だと情シスなどもないので、SmartHR、クラウドサインなどを導入していてその恩恵があったりします。 開発の話だとJavaScriptからTypeScriptに書き換えようとか、この言語面白そうみたいな感じで、新しい技術への適応力は高いですね。 若い開発者が中心だと新しい技術への順応性も高く、大企業でよくあるような学習しない人によって起こされる幼稚な弊害も基本的には起きないかなぁと思ってます。それだけでも大きな福利厚生かもしれないですね。 コードから読み取る力が必要 ドキュメント化するだけのリソースもなくドキュメント化は後回しにされがち。 アジャイルソフトウェア開発宣言では「包括的なドキュメントよりも動くソフトウェアを」と書いてますが、 包括的なドキュメント 5 : 動くソフトウェア 80 : よくわからんけど動いてるorバグ 15 くらいな感じですかね(そろそろ怒られるぞ) そのためコードから察するようなエスパー力?はある程度必要。 だがslack上で質問チャンネルなどを作って、有識者に質問できればサポートしてくれるはず。質問を恐れない力が必要かも。 非効率なコーディングと出会う確率は高い スタートアップだと市場からのニーズにすぐ対応する速度が求められたりするため「非効率やなぁ」というコードに出会うことはあります。あまり品質が高くないということもありますが、過去の経緯が積み重なってスパゲッティ化してるという話も出てくる可能性があります。 多分入社する前に会社の経緯を聞いてみたほうが良いと思いますが、 CTOが会社やめたばかりだとか、スタートアップ設立当初に頼ってた外注による秘伝のミートソーススパゲッティコードが残されたりという話もあったりします。まぁこれはどこの企業でもある話か。 最初の1-2か月は多分つらい 若い人の多い開発チームだと最新技術のキャッチアップが早かったりして、前職で使っていた技術スタックのはるか最先端の技術を使うことになったりします。(シニア級が多いとたぶんもっとVMチックな開発/デプロイとかが多くなるのかもしれないですがいったんそういうのは置いときます。) エンジニア基礎力が高いひとであればそういう環境でもすぐ順応できると思いますが、マイペースにやりたい人や経歴が浅めなひとだとつらい環境になることも想定できます。 入社1日目でバグ修正させられたり、多要素認証実装しろとか言われたり、なんなんってなります。(経験談) さらに泣きっ面に蜂なことを言うと、経験の浅い若いチームだとコーディングスタイルにムラがあったりテスト書いてないためバグばっかりだとか、フォルダ構成がやばかったり、設計哲学とかそういう視点が抜けてることによるコーディングの見にくさもついてきたりしますね。ここらへんのつらさが最初の1-2か月で来ます。そして成果を出さなければ!! という焦りも合わさったりします。 そのままのきみでええんやで 自信はつく この少ない人数で会社できるんやな　というのが正直な感想です。 AWSなどのクラウドサービスやコモディティ化されてきてるAIフレームワークなどのおかげで、昔の人たちが一から作ってたものをいまはある程度ショートカットできる時代なのかなと思います。 (どの技術にしろパフォーマンスチューニングの世界になれば、深い技術の沼に入らないといけないですが) そういう恩恵を今の時代の私たちが享受できるのは良いですよね。 私なんかはまだ下っ端ですが、少人数でもサービスを作れるというのはやはり自信につながります。 技術以外の視点の幅が広がる 全社会議なんかでマーケティング、カスタマーサクセス、プロダクト、セールス、資金調達などの話が出るので、縦割りがすごい大企業出身エンジニアは衝撃を受けつつ新鮮な感じになるかも。ビジネスサイドも全部知りたいエンジニアなどは良い環境だと思います。 出資のおかげでなんとか食えてる 売上がなくてもベンチャーキャピタルからの出資だったり、良くしてくれるエンジェル投資家様のおかげで食えてます。 上様、頭が一生上がりませぬ。 ただこの出資が切れる前になんとか PMF(プロダクトマーケットフィット：プロダクトが市場にフィットしてるということ) して売上を上げねばという焦りはありますね。 よく分からん単語飛びがち 先程のPMFやらPLGといったキラキラした人が言いそうな単語は出てきます。IT系のサービス名やマーケティング用語、営業用語など結構飛びます。慣れてないフロントエンド技術についてもモーダルとかトグルとかの単語が出てくるので、最初は 「普通に日本語話せやゴラァ」 ってなるかもしれないです。 ただ慣れは怖いですね、この単語たちに耳がもう慣れてきましたよ キャリアプランを考える必要がありそう 売上がコストに追いついてない状態である場合が大概だと思うので、そういう面では不安定な仕事ですので将来のキャリアについて考えないとなぁと思うことはありますね。キャリアプランを考えさせられた結果、フリーランス的な働き方も考慮してエンジニアブログを始めているわけです。 正社員エンジニアが2-3人だと業務委託エンジニアやフリーランスとの仕事とすることが多く、彼らの経験なども吸収できるしフリーランスとして働くという選択肢を考えるようになりましたね。 大きめの企業のエンジニアを経ているとフリーランスという働き方自体がものすごくリスキーで怖い印象でしたが、スタートアップで働いてみると フリーランスという選択肢もアリかも というレベルに思えてくる、絶対大変だけども... あとは企業のフェーズによっては「この短距離走みたいな働き方、ずっとはできんやろ」ってなることもあります。そういう意味でも長くいるという可能性は低いのかなとは思ってます。 スタートアップの正社員エンジニアの難易度は「正社員エンジニア何番目の入社か」で決まりそうな気がする 私は正社員エンジニア1番目ではなかったのである程度ゆとりをもった生活ができてるかなと思います。やはりそれは 正社員エンジニア1番目の頑張りが大きく寄与していると思います。 正社員エンジニア1番目はめちゃくちゃ怖いけれど実際現場には業務委託のエンジニアがいたりして、技術が強い人もいることがあるので踏み出しても良いとは思います。一方で正社員エンジニアには会社の未来を決めるような大きな決断だったり責任、チームマネジメントが必要になるので、正社員エンジニア1番目は私はちょっと荷が重いなぁ と思います。 1番目以降の正社員エンジニアについては1番目が失踪とか、めちゃくちゃ無能みたいな場合を除いて、責任は分散されてくるのでまぁめちゃくちゃ激務ということにはならないかなというイメージです。これはもう会社のフェーズとかによると思います。 あとがき こんな駄文を読んでいただいてありがとうございます。脱線とかしてたら文章がこんなに増えてしまいました。 個人的に転職前にあまり意識してなかったのが「正社員エンジニア何番目か」という視点だったり、意外と業務委託の方に助けられたりして「孤立無援みたいにはまぁならん」というのが驚きだったかなと思います。 エンジニア人生は多分悩むことが多い人生なので、踏み出す勇気がない方だったりキャリアに悩んでいる方の助けになればと思います。フリーランスになる可能性もあるので一緒に仕事したいとか、話してみたいとか要望があればぜひ。 そろそろ、技術ゴリゴリなやつ書かないとなぁ。でも技術的な記事はリサーチが大変なんだよなぁ... とりあえず、ありがとうございました。

【Corporate Site】 [G.U.Labs株式会社] ：https://gulabs.com/ja/ 革新的な発想と技術で、より自由で楽しい世界を。 G.U.Labsは、ブロックチェーンが引き起こす様々な社会変革に対応するためのクラウドツールやソリューションの提供、セキュリティ技術、研究開発力を提供します。 [G.U.テクノロジーズ株式会社]：https://gu-tech.com/ デジタルの力で、人々に自由を。 G.U.Technologiesでは、ブロックチェーンによる金融と情報が融合した新たなデジタル革命時代に向けて、豊かな発想と確固たる技術で誰もが自由で幸せな社会を作っていくことを目指します。 【Product Site】 [G.U.Blockchain Cloud]：https://www.bccloud.net/ja/ 日本初。簡単3ステップで ブロックチェーン基盤を構築。 G.U.Blockchain Cloudは「誰でも簡単・低コスト」に初期導入が可能。Enterprise領域で利用できる機能やセキュリティを備えたEthereum互換ブロックチェーン構築クラウドサービスです。 [G.U.net]：https://www.gu.net/ja/ ブロックチェーンによる 新しいデジタル世界を構築しよう G.U.netは、ブロックチェーン技術の普及を目的としてEthereum互換ブロックチェーン上でのNFTや DeFi（分散金融）などの分散アプリ開発（DApps）を体験できるG.U.Sandbox Chainの提供や情報発信を行うサイトです。 [Lunascape]：https://www.lunascape.org/browser/phoebe シンプル且つ高速で使いやすいDAppsに対応したデスクトップ＆モバイルのタブ型Webブラウザ。 広告ブロック機能やプライバシー保護を重要視し、安心・安全にインターネットを利用可能。 [Lunascape Wallet]：https://chrome.google.com/webstore/detail/lunascape-wallet/nfinomegcaccbhchhgflladpfbajihdf?hl=ja&authuser=0 DApps対応のEthereumウォレット。 Google Chromの拡張機能版。

事前準備：https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-cluster.html def get_task_cnt(): """ ECSタスク数の取得を行う Returns:ECSタスク数(int) """ cloudwatch = boto3.client('cloudwatch') response = cloudwatch.get_metric_data( MetricDataQueries=[ { 'Id': 'm1', 'MetricStat': { 'Metric': { 'Namespace': 'ECS/ContainerInsights', 'MetricName': 'TaskCount', 'Dimensions': [ { 'Name': 'ClusterName', 'Value': ECS_CLUSTER_NAME }, ] }, 'Period': 300, 'Stat': 'Average', 'Unit': 'Count' }, }, ], StartTime=datetime.datetime.now() - datetime.timedelta(minutes=1), EndTime=datetime.datetime.now() ) values = response['MetricDataResults'][0]['Values'] if len(values) != 0: value = int(response['MetricDataResults'][0]['Values'][0]) return value 参考：

環境 2022/03/01現在 $ terraform -v Terraform v1.1.2 on linux_amd64 tfファイル クラスタ設定 rds_cluster.tf resource "aws_rds_cluster" "mysql80" { cluster_identifier = "aurora-mysql80-cluster" engine = "aurora-mysql" engine_version = "8.0.mysql_aurora.3.01.0" // engine_versionをこう指定しないとデフォルトのAurora MySQL2(MySQL5.7互換)で設定されてしまう // 8.0.mysql_aurora.までは共通で、後ろのバージョンはWebコンソールの"利用可能なバージョン"の値だと思われる // 今回は値取得のために新しくクラスタを作成し、terraform importして取得した master_username = "username" master_password = "password" // tfstateに残るので仮置し、webコンソールから書き換える port = 3306 database_name = "database" db_cluster_parameter_group_name = aws_rds_cluster_parameter_group.mysql80.name // カスタマイズしないなら"default.aurora-mysql8.0"でもよいが、 // コンソールで一度クラスタとインスタンスをデフォルトで構築しないと作成されない。 backup_retention_period = 15 preferred_backup_window = "18:00-20:00" // 03:00-05:00(JST) availability_zones = ["ap-northeast-1a", "ap-northeast-1c","ap-northeast-1d"] // RDSクラスタはAZが最低3個になるまで勝手に自動で追加される // ap-northeastを使うなら最初からすべて入れるのが吉 // 実際にインスタンスを置くAZの指定はaws_db_subnet_groupで行う db_subnet_group_name = aws_db_subnet_group.mysql80.name vpc_security_group_ids = [aws_default_security_group.default.id] lifecycle { ignore_changes = [ master_password, // パスワードが変更されていても無視する availability_zones // 書き換えられていても問題ないので無視する ] } } rds_cluster_parameter_group.tf resource "aws_rds_cluster_parameter_group" "mysql80" { name = "aurora-mysql80-cluster-parameter" family = "aurora-mysql8.0" parameter { name = "time_zone" value = "Asia/Tokyo" apply_method = "immediate" } // MySQL8.0からデフォルトの文字コードがutf8mb4になったのでいつもの呪文を書かなくてよくなった } rds_cluster_subnet_group.tf resource "aws_db_subnet_group" "mysql80" { name = "aurora-mysql80-cluster-db-subnet" subnet_ids = aws_subnet.private.*.id // 編注：サブネットは別途作っておくこと } インスタンス設定 rds_cluster_instance.tf resource "aws_rds_cluster_instance" "mysql80" { count = 2 cluster_identifier = aws_rds_cluster.mysql80.id identifier = "aurora-mysql80-cluster-instance-${count.index}" engine = aws_rds_cluster.mysql80.engine engine_version = aws_rds_cluster.mysql80.engine_version instance_class = "db.t4g.medium" // Aurora MySQL3は最低インスタンスがt.mediumになった db_subnet_group_name = aws_rds_cluster.mysql80.db_subnet_group_name db_parameter_group_name = aws_db_parameter_group.mysql80.name // カスタマイズしないなら"default.aurora-mysql8.0"でもよいが、 // コンソールで一度クラスタとインスタンスをデフォルトで構築しないと作成されない。 monitoring_role_arn = aws_iam_role.aurora_monitoring.arn // 編注：Aurora MySQL2と変わらない monitoring_interval = 60 publicly_accessible = false } rds_cluster_instance_parameter_group.tf resource "aws_db_parameter_group" "main_mysql80" { name = "aurora-mysql80-cluster-instance-parameter" family = "aurora-mysql8.0" } TIPS Aurora MySQL2から3への自動移行はできないので3のクラスタを別で立てて、DMSなりmysqldumpしてインポートするなりで移行する必要がある。

概要 Lambdaのローカルテスト環境をDockerで作成しました。本記事ではPythonで書いています。 公式ドキュメントを読んでも上手くいかなかったので、記事にします。 用意するもの Dockerコマンドを実行できる環境 構築手順 ディレトリ構成 （プロジェクトルートディレクトリ）/ ├── Dockerfile ├── requirements.txt (不要なら作成しなくて良い) └── app.py ファイル作成 Dockerfile FROM public.ecr.aws/lambda/python:3.8 COPY app.py ${LAMBDA_TASK_ROOT} COPY requirements.txt . RUN pip3 install -r requirements.txt --target "${LAMBDA_TASK_ROOT}" CMD [ "app.handler" ] app.py import sys def handler(event, context): return 'Hello, This is Lambda Test' ※本記事ではrequirements.txtは空で環境作成します。 何か必要なモジュールがあれば追記して次の動作確認をしてください。 環境構築・動作確認 1. イメージ作成 テストでhello-worldという名前のイメージにしていますが、お好きな名前で問題ございません。 $ docker build -t hello-world . 2. コンテナ作成 ローカルはポート9000で公開していますが、こちらもお好きなポートで大丈夫です。コンテナ内の8080ポートについては変更しないでください。 $ docker run -p 9000:8080 hello-world ~~ 02 Mar 2022 15:57:27,797 [INFO] (rapid) exec '/var/runtime/bootstrap' (cwd=/var/task, handler=) 3. 動作確認 別ターミナルを起動し、curlで作成した関数を実行します。/2015-03-31/functions/function/invocationsのパスについてはDockerfileで指定したイメージによるものなので特に考えずに設定してください。 app.pyで設定したレスポンシブが表示されます。 $ curl -d '{}' http://localhost:9000/2015-03-31/functions/function/invocations "Hello, This is Lambda Test" コンテナ作成を実行したターミナルのログには以下が表示されます。環境などによって表示が異なりますのでご承知おきください。 02 Mar 2022 15:57:27,797 [INFO] (rapid) exec '/var/runtime/bootstrap' (cwd=/var/task, handler=) 02 Mar 2022 16:00:22,977 [INFO] (rapid) extensionsDisabledByLayer(/opt/disable-extensions-jwigqn8j) -> stat /opt/disable-extensions-jwigqn8j: no such file or directory 02 Mar 2022 16:00:22,977 [WARNING] (rapid) Cannot list external agents error=open /opt/extensions: no such file or directory START RequestId: f96f05b2-cf54-4ebf-94d7-d8399c37afcd Version: $LATEST END RequestId: f96f05b2-cf54-4ebf-94d7-d8399c37afcd REPORT RequestId: f96f05b2-cf54-4ebf-94d7-d8399c37afcd Init Duration: 0.21 ms Duration: 65.85 ms Billed Duration: 66 ms Memory Size: 3008 MB Max Memory Used: 3008 MB まとめ Docker+Lambdaのローカルテスト環境が簡単に作成できました。 テストを書く際はapp.pyを編集したり、requirements.txtに必要なモジュールを記載してからビルドしてください。