※2021/6/6時点での情報になります。 Amazon SageMaker Ground Truthとは 公式の説明 Amazon SageMaker Ground Truth はフルマネージド型のデータラベル付けサービスで、機械学習のための高精度なトレーニングデータセットを簡単に構築することができます。カスタム、または組み込み済みのデータラベル付けワークフローを使用して、SageMaker Ground Truth コンソールから数分でデータのラベル付けを開始することができます。 利点 データラベルの精度向上 使いやすい コストを最大70%削減 人的リソースの選択 上記説明が公式ドキュメントにありますが、どう使えるのかがわからなかったので実際に使ってみました。 流れ ざっくりで以下の流れでラベリングが行われます。 ラベリング対象の画像や動画をS3に用意 ラベリングジョブの作成 ラベリングジョブに対してワーカーの割り当て ラベリングポータルでのラベリング ラベリング対象の画像や動画をS3に用意 任意のバケットにラベリング対象の画像を用意します。現状、サポートされている形式は以下のようです。 種類 ファイル形式 画像 .jpg, .jpeg, .png テキスト .txt, .csv 動画（フレーム抽出） .mp4 動画（動画分類） .mp4, .ogg, .webm 動画（フレーム抽出）はmp4形式の動画を元に指定したフレーム数毎に画像を抽出、ラベリングを行います。動画（動画分類）は動画自体のラベリングを行います。 ラベリングジョブを行うにあたり、manifestファイルが必要になります。対象ファイル群が入っているS3のフォルダを指定することで、ラベリングジョブ作成時に自動生成してもらえますが、用意しても良いです。 試しに自動生成したmanifestファイルは以下です。対象となるファイルの一覧と思って貰えば良いです。 {"source-ref":"s3://xxxxx/train/prefix/prefix_01.png"} {"source-ref":"s3://xxxxx/train/prefix/prefix_02.png"} {"source-ref":"s3://xxxxx/train/prefix/prefix_03.png"} {"source-ref":"s3://xxxxx/train/prefix/prefix_04.png"} {"source-ref":"s3://xxxxx/train/prefix/prefix_05.png"} {"source-ref":"s3://xxxxx/train/prefix/prefix_06.png"} ラベリングジョブの作成 ラベリング自体をジョブとして作成します。ジョブには対象の画像や動画をS3においたmanifestファイルを指定し、対象の画像を特定します。または、S3のフォルダを指定し、対象のファイルを洗い出しmanifestファイルを自動生成します。 ラベリングジョブではさらに以下を指定します。 ラベリング結果の出力先。インプットと同一の指定も可能 ラベリングデータセットの設定 ラベリングタスク ラベリングデータセットの設定では、対象のファイルからランダムに30%のみ利用するということが可能です。ラベリングタスクでは画像でも、以下のタスクを指定することができます。 単一ラベル。画像に一つのラベルを設定 マルチラベル。画像に複数のラベルを設定 境界ボックス。 セグメンテーション ラベルの検証。設定したラベルが正しいか確認する 作成したラベリングジョブはAmazon SageMaker > Ground Truth > ラベリングジョブで確認することができます。 ラベリングジョブに対してワーカーの割り当て ラベリングジョブを行うワーカーを選択します。このとき、以下の3つから選択します。 パブリック。Amazon Mechanical Turkによる50万人以上の独立系請負業者に任せる プライベート。自身で用意した作業者に任せる ベンダー管理下。AWS Marketplaceから選択できるベンダーに任せる 今回はプライベートでラベリングを行いました。このとき、ラベリングジョブに対してプライベートチームを割り当てます。 プライベートチームに所属するユーザーは、予めメールアドレスで認証する必要がありますが、Amazon Cognitoを利用して管理します。初めてプライベートチームを作成する場合はGround Truthから自動的に作成されます。 Amazon Cognitoで管理されたユーザーを使用して、ラベリングポータルにログインすることになります。 ワーカーの状況はSageMaker > Ground Truth > ラベリングワークフォースの画面で確認することができます。以下のようにプライベートチームを適切に管理し、タスクに応じてジョブを割り当てることができるようになっています。 ラベリングポータルでのラベリング ラベリングポータルのURLからログインすることで、そのユーザーに割り当てられているジョブの一覧を確認することが可能です。実際にラベリングの動作については以下のリンクから確認することができます。 https://aws.amazon.com/jp/blogs/news/amazon-sagemaker-gt-video/ 実際に画像と動画のラベリングの実施を行ってみましたが、動作が重いと感じることもありますが簡単に実行ができると思いました。特に、動画で領域のラベリングを行った際は、次のフレームに対して領域を保持することができる上に、標準で次のフレームの領域を予測して設定してくれます。 料金について ラベルがつけられた対象物自体に対して料金が発生します。少なくとも1つあたり0.08USDかかるため、1000枚で80USDかかります。さらに、パブリックやベンダーを利用する場合は、ラベル毎や作業者毎対象物毎に課金されます。 個人で利用する場合は高い印象がありますが、単純な外注費用と比べると安い場合もあるかもしれません。 最後に 大量の画像データがある場合には全ての画像データに対して正しくラベリングするのは容易ではないと思います。ラベリングの品質を保つためにはGround Truthのような仕組みで実施できればいいのかなと思いました。 参考 https://aws.amazon.com/jp/sagemaker/groundtruth/ https://aws.amazon.com/jp/blogs/news/amazon-sagemaker-gt-video/ https://aws.amazon.com/jp/sagemaker/groundtruth/pricing/

先日、Amplify ConsoleでNext.jsのSSRアプリがホスティングできる機能が発表された。 公式ブログ Host a Next.js SSR app with real-time data on AWS Amplify 実際はSSR, SSGのどちらかをpackage.jsonから判断するらしい。 Deploy and host server-side rendered apps with Amplify When you deploy a Next.js app, Amplify inspects the app's build script in the package.json file to detect whether the app is SSR or SSG. Next.jsを触ったことがなかったので、サンプルアプリをAmplify Consoleで動かしてみた。基本的に上記のブログに沿ってやってみて、時折上記の公式ドキュメントを参照する。自分が再度試したくなった時にコピペでできるのが理想。 注意点 いずれも上記のドキュメントに書いてある。 - SSRはマニュアルデプロイには対応していないのでレポジトリ連携が必要 - Next.js10には対応していないので、version9に落とした方がいい。10もできはするらしいがフルサポートではないとのこと。 ローカルでサンプルアプリを動かす〜CodeCommitへのpushまで Amazon Linux 2のEC2インスタンスを起動。接続はVSCodeのRemote Developmentで。便利。 CodeCommitのロール作成とかの準備 Nodeを入れる ここから公式ブログの内容に入っていく。npx create-next-appをするとサンプルアプリが出来上がる。 ただし、Next.jsのバージョンが10なので9に落とさないといけない。公式ではないがこちらの記事も参考になり、バージョンを真似させてもらった。サンプルアプリの package.jsonを一部以下のように書き換える。 "dependencies": { "next": "9.5.5", "react": "16.12.0", "react-dom": "16.12.0" } この状態でnpm installしてダウングレード -> npm start。 pages/index.jsのImageという機能がバージョン10からの機能らしくエラーを吐いたので、関連する行を安直に消して再度npm startしたら動いた。 5. push git init git add . git commit -m "comment" git push --set-upstream レポジトリのURL master ホスティング 上記のブランチをAmplify Consoleに接続する。コンソールから新しいアプリを作って上記のブランチを選択するとビルドの設定などが自動生成される。 デプロイに使用するロールを選択する必要があり、今まで使っていた既存のロールを選択したところAccess Deniedのエラーが出てビルドに失敗した。 2021-06-05T04:43:22.686Z [INFO]: Starting SSR Build... 2021-06-05T04:44:29.259Z [INFO]: AccessDenied AdministratorAccessの権限でロールを新規作成してそっちを使ったら成功した。 できたものを確認。 大きな特徴は以下。 CloudFrontが自分のアカウントにできる Lambda@Edgeがサーバーの役割を果たして処理を行う。ドキュメントにも記載あり。そのため、console.log()はLambda@Edgeのログとして出力される (これはLambda@Edgeの特徴) Lambda@Edgeはus-east-1にできるが、CloudWatchログはアクセスされたエッジロケーションがあるリージョンにできる。日本からの場合には大体ap-northeast-1をみとけば良さそう。公式ではないがこの記事に救われた。全く知らなかった。 ちょっと処理足した 処理をどこに書けばいいかわからないので、とりあえずテンプレート化したい。先程の外部記事も参考にして、npx create-next-appでできたコードを以下のようにちょこっと編集すると好きな処理をかけるようになる。 index.js import Head from 'next/head' import styles from '../styles/Home.module.css' import Link from "next/link"; export default function Home() { return ( <div className={styles.container}> <Head> <title>Create Next App</title> <meta name="description" content="Generated by create next app" /> <link rel="icon" href="/favicon.ico" /> </Head> <main className={styles.main}> <h1 className={styles.title}> Welcome to <a href="https://nextjs.org">Next.js!</a> </h1> <p> <Link href="/handler"> <a>処理するボタン</a> </Link>{" "} </p> </main> </div> ) } 以下を新規作成。getServerSideProps（）は文字列を返す決まりなのか？とりあえず試してうまくいったのは以下だけど、JSONをそのまま返した場合にList側でどういういじり方ができるのかはわからない。 handler.js // import AWS from "aws-sdk"; const List = ({data}) => { return( <> list: {data} </> ) } export const getServerSideProps = async () => { const res = // 何かしらJSONが返ってくる処理 const data = JSON.stringify(res); return {props:{data}}; } export default List; まとめ Lambda@Edgeで処理していた Next.jsのサンプルアプリをホスティングして、適当な処理がかけるボタンを置きました。 おまけ: 認証に関して 僕は今回試していないが、withSSRContext()を使えばCognitoの認証情報をサーバー側で使える。これはAmplifyのドキュメントに書いてあり、普通のReactアプリをホスティングするときとほぼ同様の操作で認証情報を使えそう。

これなに？ ローカル環境（Mac）でAWS Step Function / Lambda / DynamoDB を動かす手順をまとめます 以下の記事を参考にしています https://dev.classmethod.jp/articles/stepfunctionslocal-localstack/ 2021/06/06現在、LocalStackのポート指定が変わっているようです ざっくりとした手順 Dockerのインストール Docker HubよりLocalStackと、Step Functions Localのイメージを取得 LocalStack起動 DynamoDBテーブル作成 Lambda関数作成 Step Functions作成 Step Functions起動 Dockerのインストール Dockerが必要なので、ない場合はインストールしてください AWS CLIも、ない場合はインストールしてください Docker HubよりLocalStackと、Step Functions Localのイメージを取得 以下のコマンドでpullしましょう $ docker pull localstack/localstack $ docker pull amazon/aws-stepfunctions-local 取得できたか確認します $ docker images 備考 https://github.com/localstack/localstack をcloneしてきて、 docker-compose でも起動できます こっちのほうが楽かもしれません LocalStack起動 以下のコマンドで起動できます $ docker run --rm -it -p 4566:4566 -p 4571:4571 localstack/localstack 備考 https://github.com/localstack/localstack に記載がありますが、 LocalStackの 0.11.0 から、DynamoDB、Lambdaなどすべてのサービスが同じポート 4566 で起動するようになったそうです 備考2 $ aws configure --profile localstack でプロファイルを適当に定義すると良いかもですが、設定しなくても動作はするようです 設定例） AWS Access Key ID [None]: dummy AWS Secret Access Key [None]: dummy Default region name [None]: us-east-1 Default output format [None]: text DynamoDBテーブル作成 $ aws dynamodb create-table --table-name TestTable \ --attribute-definitions AttributeName=Id,AttributeType=N \ --key-schema AttributeName=Id,KeyType=HASH \ --endpoint-url http://localhost:4566 \ --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1 $ aws dynamodb scan --table-name TestTable --endpoint-url http://localhost:4566 Lambda作成 関数作成 参考サイトから パクって オマージュして来たものをもとに関数を作ります DynamoDBのエンドポイントが記載されているので、LocalStackのエンドポイントを指定します 中身は TestTable に1行だけPUTするものです ファイル名は適当に lambda.py としています import boto3 def lambda_handler(event, context): dynamodb = boto3.resource('dynamodb', region_name='us-east-1',endpoint_url='http://localhost:4566/') table = dynamodb.Table('TestTable') response = table.put_item( Item={ 'Id': 1, 'Name': 'Mayoi' } ) return response Lambda関数を作成 作成した関数をzipにします $ zip lambda.zip lambda.py 次にデプロイします $ aws lambda create-function \ --function-name=TestFunction \ --runtime=python3.6 \ --role=DummyRole \ --handler=lambda.lambda_handler \ --zip-file fileb://lambda.zip \ --endpoint-url=http://localhost:4566 エンドポイントURLはDynamoDBと同一でOKです（LocalStackの 0.11.0 以降） Step Functions作成 設定ファイル作成 $ vi aws-stepfunctions-local-credentials.txt vi で以下の内容のファイルを作成してください LAMBDA_ENDPOINT=http://host.docker.internal:4566 LambdaのエンドポイントをStep Functionsに設定しています 他にも、もろもろ設定する場合は以下を参考にしてください https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/sfn-local-config-options.html#docker-credentials StepFunctions Localコンテナ起動 StepFunctionsのコンテナを起動します docker run -p 8083:8083 --env-file aws-stepfunctions-local-credentials.txt amazon/aws-stepfunctions-local ステートマシン作成 StepFunctionsのステートマシンを作成します ステートマシンとはざっくり言うと、状態管理の定義かと思います StepFunctions君は、横浜駅へ行って高島屋で日本酒買って帰ってくるみたいな指令書を定義します 参考にした記事では defin_statemachine.json というファイルにステートマシンを定義しています { "StartAt": "Shinobu", "States": { "Shinobu": { "Type": "Task", "Resource": "arn:aws:lambda:::function:TestFunction", "End": true } } } ステートマシンの定義ファイルを書いたら、以下のコマンドで実際にステートマシンを作成します aws stepfunctions create-state-machine \ --name TestState \ --definition file://defin_statemachine.json \ --role-arn "arn:aws:iam::000000000000:role/DummyRole" \ --endpoint http://localhost:8083 うまく作成できると、以下のようなのが返ってきます 1622974168.008 arn:aws:states:us-east-1:123456789012:stateMachine:TestState arn:aws:states:us-east-1:123456789012:stateMachine:TestState はARNです ステートマシンを実行するときには、こいつを指定します Step Functions起動 ステートマシンの定義ができたので、実際に実行してみます $ aws stepfunctions start-execution \ --state-machine arn:aws:states:us-east-1:123456789012:stateMachine:TestState \ --endpoint http://localhost:8083 上記を実行すると、ステートマシンが起動し、Lambdaが実行され、DynamoDBに値が書き込まれるはずです 実行すると、以下のように実行のARNが払い出されるので、これを用いて結果確認も可能です arn:aws:states:us-east-1:123456789012:execution:TestState:6a2e5112-6c3e-42d8-9359-426b66e26617 1622975148.062 結果確認は以下のようなコマンドです $ aws stepfunctions describe-execution \ --execution-arn arn:aws:states:us-east-1:123456789012:execution:TestState:6a2e5112-6c3e-42d8-9359-426b66e26617 \ --endpoint=http://localhost:8083 SUCCEEDED が返ってきたら成功やで！ 結果確認 DynamoDBをscanしてみて、データが入っているか確認してみましょう $ aws dynamodb scan --table-name TestTable --endpoint-url http://localhost:4566 値が入っていたら優勝！ 参考にした記事 https://dev.classmethod.jp/articles/stepfunctionslocal-localstack/ https://dev.classmethod.jp/articles/localstack-lambda/

はじめに 2019年9月にAWS認定クラウドプラクティショナー(CLF)を取得しました。勉強期間は約3か月でした。 本記事では取得のために行った勉強方法を共有いたします。 CLFの勉強方法 以下の本で必要な知識を身に着けました。問題演習も同じ本を利用し、問題を繰り返し解きました。 反省点 試験には合格できたものの、上記の参考書だけでは演習量不足だったと感じました。受験される方は別途追加で問題演習されることをお勧めいたします。

はじめに PHPとVue.jsを使った「本のレンタルアプリケーション」を作成した時の話や、構成をまとめてみました。 Web系のプログラミングを大方学んでみて、実際に何か作ってみようと考えている人や、複数のプログラミングや技術を合わせて使ったことのない人に参考にしていただければと思います。 PHPとVue.jsでなくても、RubyやjQueryなどでも代用はできますし、どちらかといえば環境構築やデータベースの構成のほうをメインに書いています。 図書レンタルアプリを作った理由 今回この図書レンタルアプリを作ろうと思ったのは、一から一人だけで、サービスを作る経験を積んでおきたかったからです。 業務では基本的に分業が多く、フロントエンドとバックエンドで別れてサービスを構築するのが基本で、新しくサービスを一から作る機会自体少ないです。 基本は現状あるサービスの改修や、修正がメインのため、一からサービスをコンスタントに作って、場数を踏みたいと思ったのがきっかけです。 そして何を作ろうかと考えたときに、会社の本棚の本の管理ができていなかったので、誰が何をいつまで借りているのかや、本のレンタル履歴を管理できるアプリケーションを作ってみようと思ったのがきっかけです。 使用した技術 使用した技術 PHP Vue.js MySQL Docker アプリを作り始めた時の自分のスキルレベル javascript javascriptは実務でもメインで使っているため、問題なくかけるレベルです。 ライブラリーやフレームワークにつては、jQueryとVue.jsが使えました。 jQueryは結構知識はありましたが、Vue.jsの経験は少なめでした。 Vue.js Vue-CLI、vue-router、VueXの基礎知識をudemyの動画を通して学んだくらいです。 仕事ではVueファイル形式で書いたことはなく、今回Vueファイル形式で、ビルドする書き方ははじめてでした。 PHP PHPも実務での経験は少なく、PHPで一からサービスを作ったことはありませんでした。 実務で、今あるサービスの改修や修正、機能追加などでPHPを触るくらいの経験しか有りませんでした。 Docker Docker関しては、完全に初めてで、素人でした。 それまではVirtualBoxでlinuxの環境を作って、開発を行っていました。 なのでlinuxコマンドなどの知識はある前提です。 スキルレベルのまとめ 一応現役のエンジニアではありますが、基本的に一からのサービス構築の経験は少なく、あってもメインで携わって来たのはフロント側のみで、バックエンドやインフラはすでに構築されているものを少し触るくらいの経験しか積んできませんでした。 キャリア的にももっと経験を積まないとまずいと思い、ここらで一気に経験を積みたいと思い、とりあえず「PHP」「Vue.js」「MySQL」「Docker」この辺の技術を使って、一人で一から簡単なサービスを作るところから始めようと思いました。 図書レンタルアプリの機能 バックエンドとユーザー登録、ログインのページはPHP それ以外のフロントエンドはVue.jsで作成しました。 実装する機能のリスト ・ユーザー登録機能 ・ログイン機能 ・ログアウト機能 ・レンタル機能 ・レンタル状況確認機能 ・返却機能 ・返却期限編集機能 ・ユーザー情報編集機能 ・ランキング機能 ・本の登録機能 アプリのデザインについて 普段の業務で自分であまり使わないのですが、デザインを作成するのにXDを使い、簡単にデザインを作成しました。 今回はXDのスキルではなく、Web開発のエンジニアスキルを高めたかったので、デザインはなるべくシンプルにしました。 もともとミニマムなデザインが好きなので、色もモノトーンベースにしています。 PHPで作成した「ユーザー登録ページ」と「ログインページ」 　　　 Vue.jsで作成したシングルページアプリケーション（SPA） 　　　　 データベースについて データベースはMySQLを使用しました。 MySQLにlibraryというデータベースを作成し、その中に「members」「book」というテーブルを作成しました。 データベースの構成と役割 データベース：library 　 テーブル 　　└book 　　└members book bookには本の情報を保存します。 book_id：本を識別するID title：本のタイトル status：本がレンタル中or在庫あるか rental_id：レンタルされている場合はmemberのid、レンタルされていない場合はNULL date_rimit：レンタルされている場合はレンタル期限、レンタルされていない場合はNULL category：本のカテゴリー tag：本の検索に使うtag count：レンタルされた回数 created_at：本が登録された日付 members membersにはアプリを使用する人のログイン情報や、レンタルしている本のidのリストを保存します。 id：ユーザーを識別するID name：ユーザーの名前 mail：ユーザーのメールアドレス password：ログインするためのパスワード created：ユーザー登録した日付 rental_list：現在レンタルしている本のbook_idのリスト 各ファイルの役割 PHPについて PHPでCRUD機能を実装しました。 ユーザーの登録機能（Create） ユーザのログイン機能（Read） ユーザー、本の管理機能（Read） ユーザー、本の情報書き換え（Update） ※Dleteに当たる機能は今回有りませんでした。 Vue.jsで作成したSPAから、本を検索したり、レンタルしたりするときにPHPを動かす必要がありますが、axiosを使い通信を行いました。 Vue.jsについて ※この話はVue.jsを学んでいる人ならわかると思いますが、Vue.jsに興味がない場合は飛ばしてください Vuejsで作成したSPAのページはタブ構成になっており、タブの切替はVue-routerを使って、urlを切り替えてタブ機能を実装しています。 各タブの中のページの切り替え（例えば、レンタルタブの中で、本を検索したり、本をレンタルする際にページの切り替え）は、動的コンポーネントで表示を切り替えています。 レンタルタブ 　　　　 状況タブ（レンタル状況と返却） Dockerでの環境構築 今回は開発環境としてはDockerでLAMP環境を構築することにしました。 Docker-composeを使って、複数のコンテナをたててLAMPを構築しました。 参考までにymlファイルと、dockerファイルを公開しておきます。 yml version: "3.7" services: mysql: image: mysql:5.7 volumes: - db_data:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: "password" phpmyadmin: depends_on: - mysql image: phpmyadmin/phpmyadmin environment: PMA_HOST: mysql restart: always ports: - "8080:80" php-apache: build: ./php volumes: - ./htdocs:/var/www/html restart: always ports: - "80:80" depends_on: - mysql volumes: db_data: {} ./phpの直下に書きを保存 dockerfile FROM php:7.3-apache COPY ./php.ini /usr/local/etc/php/ COPY ./apache2.conf /etc/apache2/ COPY ./sites/*.conf /etc/apache2/sites-available/ RUN apt-get update \ && apt-get install -y libfreetype6-dev libjpeg62-turbo-dev libpng-dev \ && docker-php-ext-install pdo_mysql mysqli mbstring gd iconv 上記のファイルで下記のコマンドを実行すれば、LAMP環境が立ち上がります。 terminal docker-compose up -d Dockerでの環境構築で困ったこと 今回一番困ったのがDockerで作ったapacheの設定です。 私も初めて知ったのですが、公式で公開されている「php:7.3-apache」などのApacheは、あくまでphpが動くだけのapacheの環境しか用意していないため、普通のapacheの環境でデフォルトで設定されているようなものは、デフォルトで入っていないことがあります。 今回ハマったのが、Rewriteのモジュールです。 Vue-routerを使った時に、historyモードを使用していると、リロードした時に404エラーが出てしまいます。これはVueの公式にも記載されています。 それを回避するために、apacheの設定ファイルか、.htaccessでRewriteの設定をする必要があるのですが、そのためのモジュールがapacheにはありませんでした。 それに気づかずに、設定ファイルにRewriteの記述を書いても問題が解決せずにいました。 今回の場合は、それをphp:7.3-apacheに入り、インストールして解決しましたが、本来であれば、Dockerfileにそれを記載しておく必要があります。 そうしないと次回コンテナを新しく立ち上げた時に、また、同じことをしないといけないからです。 かなり勉強になりました。 アプリケーションを作ってみた感想 今回一番新しい試みだったのが、Vue.js（Vuex、Vue-router）とDockerでの開発でしたが、初めてだったので、ディレクトリ構造などが少し納得できるくらい整理ができず、本当は記事にして、詳細まで説明しようと思っていたのですが、できませんでした。 ただ、一度作ってみることで、ディレクトリ構造以外にも、設計やデータベースの構成など、ワンストップで開発しないと経験できないことを多く学ぶことができました。 やはり部分的に開発しているだけでは、見えていないことや、自分のスキルとして足りていないことが多くあることを発見でき、やってみてよかったと思いました。 AWSの使用について（余談） ちょっと今回の話に関係ないののですが、少し話をさせてください。 このアプリを作る際に、本番のアップロード先について最初はAWSで、VPCとEC2を使ってネットワークとサーバーを立てて、そこで公開しようと思っていました。 ですが、この手のアプリケーションを作る時に、流行っているからというだけでAWSを使うのはちょっと違うと考えました。 特に初学者の人は手を出しやすい場所だと思うのですが、AWSは基本的に従量課金のため、サーバーが動いている分だけ料金が課金されていきます。 lamdaなどを使って、アプリケーションが動くときだけ稼働させるなどの工夫をすればいいのですが、割と初学者にとってはハードルが高いため、最初はおすすめしません。 もちろんAWSの技術をみにつける目的があるのであれば、試すのもありですが、今回はインフラ周りというよりも動くものを作るのが目的だったので、さくらサーバーなどのレンタルサーバーを使用しました。 というのも会社で使うアプリケーションのため、サーバーやAWSは会社のものを使うので、コストは最小限に抑える必要があったからです。 プログラミングを学ぶときにはこういったコストのことも考えながら作ると、より実践向きのエンジニアに成長できると思うので、今回関係ないですが、この話をはさみました。

AWS CLIのバージョン2からDockerでの実行ができます。自分の場合、よくPythonのバージョンが不整合になったりして面倒なので、Dockerを利用しています。 利用方法 公式ドキュメントの記載通り、以下のコマンドでOKです。 $ docker run --rm -it amazon/aws-cli:2.0.6 command さらに、エイリアスを作成することでdockerを気にすることなくCLIを利用できます。.bashrcや.zshrcに設定しておきましょう。 $ alias aws='docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli:2.0.6' 問題 [小ネタ] CloudWatch メトリクスのグラフをローカルに保存しちゃうぞ！の記事を参考にCloudWatchのグラフをPNGで保存してみます。 $ aws cloudwatch get-metric-widget-image --metric-widget file://metrics.json --output-format "png" --output text --query MetricWidgetImage | base64 --decode > metrics.png # aliasを使用していない場合 $ docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli:2.0.6 cloudwatch get-metric-widget-image --metric-widget file://metrics.json --output-format "png" --output text --query MetricWidgetImage | base64 --decode > metrics.png CloudWatchでのグラフのJSONでの設定からAWS CLIでbase64形式で取得し、標準出力で画像ファイルに出力するという仕組みです。 実際に実行してみるとInvalid character in input stream.となり、上手くいきません。 -tはつけない 一旦、取得結果をtemp.txtに出力してみます。 $ docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli:2.0.6 cloudwatch get-metric-widget-image --metric-widget file://metrics.json --output-format "png" --output text --query MetricWidgetImage > temp.txt 実際に出力した文字列を確認すると、[mと余計な文字列が含まれてしまっています。 ...(省略)...[m ...(省略)... [m -iと-tについて -tのオプションはpseudo-TTYを割り当てるオプションであり、実際に以下のようにbash等を利用する際には擬似端末を割り当てることでinteractiveな操作を行うことができます。 $ docker run --rm -it nginx bash root@b929c63b8e08:/# # ↑擬似端末が立ち上がる -iのオプションを利用することで標準入力を受け付けるため、-itの指定で擬似端末による操作が行えます。 回避手段 はっきり、原因が分からないのですが、今回の問題は-tオプションをつけてttyを割り当てた際の出力に問題があるのかなと思いました。そのため、回避手段としてはオプションで指定している-tのオプションを入れないことです。コマンドは以下です。 $ docker run --rm -i -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli:2.0.6 cloudwatch get-metric-widget-image --metric-widget file://metrics.json --output-format "png" --output text --query MetricWidgetImage | base64 --decode > metrics.png 参考 https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-docker.html https://genzouw.com/entry/2019/07/24/143749/1691/ https://dev.classmethod.jp/articles/clw_metrics_graph_export/

今回はAWSのサービスを使ってWordPressを公開したいと思います。 下図が今回の構成になります。 基本知識 VPC（ Amazon Web Service Virtual Private Cloud ） AWS上に作成できるプライベート仮想ネットワーク空間です。AWSアカウント内に専用のネットワークを作成でき、このネットワーク内にEC2などのAWSリソースを配置できます。 インターネットゲートウェイ インターネットゲートウェイとは、VPCとその外のネットワークを繋ぐための接合点のようなものです。 サブネット サブネットは最初にVPCによって作られているCIDRブロックを分割したネットワーク群のことです。サブネットには、主にパブリックサブネットとプライベートサブネットがあります。パブリックネットは外のネットワークと直接繋がっているサブネットで、プライベートサブネットとは、直接は外のネットワークに繋ぐことのできないサブネットになります。 ルートテーブル サブネットを利用するために、各サブネットに対してルートテーブルを作成する必要があります。仮想的なルーターと考えるようにしてください。 セキュリティグループ EC2やRDSなどインスタンス単位の通信の制御に利用します。インスタンスには少なくとも1つのセキュリティグループをアタッチする必要があります。通信の制御としては、インバウンドとアウトバウンドの両方の制御が可能です。 ネットワークACL サブネットごとの通信制御に利用します。制御できる項目はインバウンド/アウトバンドです。デフォルトでは全ての通信を許可しています。 実践編 VPCを作成する MyVPC1という名前で作成し、IPv4 CICRブロックは10.0.0.0/21にします。 サブネットを作成 先ほど作成したVPCを選択してAZ 1aにパブリックサブネット(10.0.0.0/24)、プライベートサブネット(10.0.2.0/24)を作成します。 EC2の作成 パブリックサブネットにEC2を配置します。セキュリティグループ名をWeb-SG-1にしてHTTPの80番ポートで0.0.0.0/0と設定全てのIPアドレスからの接続を許可しましょう。 インターネットゲートウェイをVPCにアタッチ まずインターネットゲートウェイを作成します。名前はMy-internet-GWです。そしてVPCにアタッチします先ほど作成したインターネットゲートウェイを選択して「アクション」をクリックして「VPCにアタッチ」を選択 ルートテーブルの編集 パブリックサブネットのルートテーブルを編集してVPC以外のルートは全てインターネットゲートウェイに向けるように設定しましょう。 サブネットグループとRDS作成する RDSはマルチAZ構成にしなければならないので新しくAZ 1cにパブリックサブネット(10.0.0.1/24)とプライベートサブネット(10.0.3.0/24)を作成します。 そしてサブネットグループを作成します。 いよいよ、RDSを作成していきます。 MySQLを選択し、マスターユーザー名を「wordpress」にし、パスワードを設定します。DBのインスタンスサイズはバースト可能クラス (t クラスを含む)にします。 接続を作成したVPCにしてサブネットグループは先ほど作成したものを選択しましょう。 そして、追加の設定をクリックしてデータベース名をwordpressにします。 RDSのセキュリティグループを変更します 先ほど作成したRDSのインバウンドルールを編集します。もともと設定されているものを削除してwebサーバーに設定されているセキュリティグループに設定します。これによってWebサーバーを持っているリソースからしかアクセスできないようにしました。 起動する 下記のコマンドでSSH接続し、必要なものをインストールします。 $ ls -l 〇〇〇〇.pem $ chmod 400 〇〇〇〇.pem $ ssh -i 〇〇〇〇.pem ec2-user@ パブリック IPv4 アドレス $ sudo su - # yum -y update # amazon-linux-extras install php7.2 -y # yum -y install mysql httpd php-mbstring php-xml gd php-gd # systemctl enable httpd.service # systemctl start httpd.service # wget http://ja.wordpress.org/latest-ja.tar.gz ~/ # tar zxvf ~/latest-ja.tar.gz # cp -r ~/wordpress/* /var/www/html/ # chown apache:apache -R /var/www/html うまくインストールできたらこちらの画面が表示されると思います。 そして、「さあ、始めましょう！」をクリックして次の画面に遷移しましょう。 ユーザー名、パスワードはRDSで設定したものでデータベースのホスト名はRDSのエンドポイントを貼り付けましょう。 インストールして、ログインできればOKです！ 今回の内容 この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com

前段 AWS GlueのノンコーディングツールにはAWS Glue DataBrewとAWS Glue Studioの2種類がある。 この2つのサービスはいずれもデータ分析において80％の時間が費やされるとされるデータ準備を効率化するためのサービスであり、AWSではいずれか一方を二者択一で選択するものではなく併用して利用可能としている。 ここでは両者の特徴を比較して、どのような場合にどちらのツールを使うとスムーズにデータ加工を行うことができるか検討する。 なお、この検討結果は2021/6時点のものである。 *1.Blackbelt Online SminarでのAWSのQA回答 〜AWS Glue StudioのBlackBeltにて〜 Q. 基本的なことなのかもしれませんが、以下のようなユースケースが一般的なのでしょうか？ ①Glue Studio でデータソースから初期のクレンジングやカスタマイズを行って、②①で作成したデータを Glue DataBrew で分析する。 A. はい、Glue Studio と DataBrew は併用可能ですので、初期処理を Glue Studio で実施し、後段で DataBrew を活用いただくことは可能です。 〜AWS Glue DataBrewのBlackbeltにて〜 Q. Glue Studio との違いや、使い分けはどのようなものでしょうか A. AWS Glue DataBrew は非エンジニアの方が組み込み変換機能を使って GUI で直感的に操作することが可能なデータ準備のためのサービスです。一方、AWS Glue Studio はコーディングを行うエンジニアの方が、より柔軟にデータ変換のパイプラインを組むことを容易にするためのサービス(機能)です。AWS Glue DataBrew で対応していない独自の変換処理が必要、カスタムコネクターが必要、といった場合は AWS Glue Studio の使用をお薦めします。これらは二者択一ではなく併用できますので、適材適所でお使いください。 比較 全般の比較 データ加工機能を除いた全般的な比較は以下の通り。 項目 AWS Glue DataBrew AWS Glue Studio コンセプト データのクリーンアップ及び正規化を最大80％高速化するビジュアルデータ準備ツール ETLジョブの作成・実行・監視を容易にする視覚的なインターフェース 想定ユーザ データアナリスト・データサイエンティスト ETLデベロッパー コーディング可否 不可 可(Spark) インプットデータの場所 1.ローカルファイル 2.s3上のファイル 3.Glueデータカタログ 4.AWS DataExchange 1.s3 2.Kinesis 3.JDBCソース インプット対象データの形式 コンマ区切り値 (.csv)、JSON とネストされた JSON、Apache Parquet とネストされた Apache Parquet、Excel シートなど、一般的に使用されるファイル形式 Data Catalog Table、JSON、CSV、Parquet アウトプット先 s3 s3,Glueデータカタログ アウトプット対象データの形式 AWS Glue DataBrew は、コンマ区切り値 (.csv)、JSON、Apache Parquet、Apache Avro、Apache ORC、および XML 各種圧縮にも対応 JSON、CSV、Avro、Parquet、Glue Parquet、ORC 各種圧縮にも対応 設定のエクスポート Yaml/JSONでレシピのエクスポートが可能 データ変換内容をSparkで表示が可能 データ変換時のプレビュー 可 不可(*2) データフォーマットの変更 可（プロジェクトの中ではなくジョブの設定） 可 データリネージ（*3） 可 可 *2.具体的なデータの内容はプレビュー出来ないが、変換後の列のキー名やデータタイプを確認することは可能 *3.元のデータから何をどう変換したか、を後追いできるようにすること データ加工機能の比較 主なデータ変換についてDataBrew、Glue Studioそれぞれの対応状況は以下表の通り。 AWS Glue Studioに関してはコーディングによる作り込みで大体の機能は実装できるが、今回の整理ではあくまでノンコーディングでどこまでできるかを比較するものとしてコーディングしないといけない場合には「×」とする。 Glue Studio列のカッコ内は対応しているデータ変換ノード。 # 変換内容 DataBrew Glue Studio 1 欠損値補完 ◯ ◯（ FillMissingValues） 2 データセットの結合 ◯ ◯（Join） 3 列の作成 ◯ × 4 データのフィルタリング ◯ ◯（Filter） 5 データの集計 ◯ × 6 カテゴリ値の処理（*4） ◯ × 7 数値の扱い（*5） ◯ × 8 データの型変換 ◯（*6） ◯（ApplyMapping） 9 列名の変更 ◯ ◯（ApplyMapping or RenameField) 上記No1〜7について、DataBrewでの具体的な実装方法に関しては以下を参照。 https://aws.amazon.com/jp/blogs/big-data/7-most-common-data-preparation-transformations-in-aws-glue-databrew/ *4.One-Hot-Encodeやカテゴリマッピングなど。 *5.正規化などデータ分析を行うにあたってよりよく数字を扱うための加工。 *6.DataBrewでの型変換について、GUI上でテキストからdate/timeに変換する方法は見つかったが例えばStringからIntに変換する方法は見つからなかった。 ここの対応方法として、レシピをJSONでダウンロードしCHANGE_DATA_TYPEを追加、そのJSONファイルをインポートすることで対応可能。 現時点（2021/6)で出来ないこと 現時点で出来ないこととして以下のようなものがある ・全角/半角の変換 ・和暦/西暦の変換 使いどころ 〜Amazon Glue DataBrewの利用が適している場面〜 ・AWS自体の見識があまりないユーザがデータの中身に対して変換を行いたい場合 ・データの傾向を確認をAWSマネジメントコンソール上で完結させたい場合 〜Amazon Glue Studioの利用が適している場面〜 ・同様のデータ形式のファイルに対して繰り返し同じ処理を定期的に行いたい場合 〜DataBrew、Glue Studioの両方を併用する場面〜 ・細かいデータ変換を行なった上で最終的にGlue Data Gatalogに反映させたい場合 　→ソースデータをDataBrewで加工、その結果ファイルをs3に格納、その結果ファイルをGlue Studioに取り込んで必要に応じて加工の上でOutputとしてGlue Data Catalogに反映させる ・変換処理の大部分はDataBrewで賄えるが一部の処理はコーディングによる作り込みが必要な場合 　→DataBrewで必要な処理を実装、その後にコーティングを求められる部分のみGlue Studioで実装 比較してみての感想 DataBrewとGlue Studioでは単に想定ユーザ（DataBrew→データアナリスト・データサイエンティスト、Glue Studio→ETLデベロッパー）が違うという以上に「データ変換」の意味合いが違うように感じられる。 DataBrewはデータの中身を対象にした操作に強みを持っているのに対してGlue Studioはデータの列定義などデータファイルの形を整えるという点がメインの機能であるように思われる。 またGlue　Studioではコーディングとの組み合わせがシームレスにできることが強みで、自社のユースケースに合わせて細かい作り込みが必要なユースケースにおいてはGlue Studioを使うべき場面はありそう。 さらに今回あまり対象としていないがジョブ関連の機能についてはGlue Studio側が充実していそうに見えるので、データ分析の流れを確立して日々運用を回していきたい場合にはGlue Studioの活躍の場面が増えるのではないかとも思える。 また実際の現場において事業企画担当・データアナリスト・サイエンティスト・ETLデベロッパーなどのように担当者を役割分担できているケースは少なく、多くは「事業担当者」と「システム担当者」程度の区分けなのではないかと推測した場合、データ分析に関してはDataBrewを企画担当者及びシステム担当者の両方が利用しその内容でコミュニケーションを実施、そこから更に追加で細かい対応が必要な場合や、外部のサービス（Ex.QuickSightやApache SuperSetなどの外部のBIツールなど）と連携が必要な場合はシステム担当者がGlue Studioで実装するといった流れが良いのではないかと考える。 参考URL AWS Glue全般 AWS Glue DataBrew関連 AWS Glue Studio関連

・前提 　AmazonLinux2のインタンスを作成してSSHで接続できる。 　セキュリティグループに 　　タイプ：HTTPS 　　プロトコル：TCP 　　ポート範囲：443 　　ソース：0.0.0.0/0 　が追加されている。 ・http24の導入 sudo yum update -y sudo yum install httpd sudo service httpd start sudo service httpd status sudo systemctl enable httpd.service httpd -v ※ ブラウザから確認。apacheの画面が表示されればOK ・スーパーユーザになっておく sudo su - ・timezone設定 timedatectl set-timezone Asia/Tokyo ll /etc/localtime ※ dateで確認 ・mod_sslインストール yum install --enablerepo=remi,remi-php74 mod_ssl.x86_64 ・snapdが入っているリポジトリの追加 cd /etc/yum.repos.d/ wget https://people.canonical.com/~mvo/snapd/amazon-linux2/snapd-amzn2.repo ※/etc/yum.conf に以下の設定を追加。[main] の最後に追加する vi /etc/yum.conf ↓追加する文 exclude=snapd-*.el7 snap-*.el7 snapdインストール yum install snapd snapd自動起動設定 systemctl enable --now snapd.socket パスを通す ln -s /var/lib/snapd/snap /snap core インストール ※ 実行するとエラーになるけど、もう１度実行するとなぜか成功する snap install core 全てのパッケージをアップデート snap refresh core cerbotのインストール snap install --classic certbot snapパス通し ln -s /snap/bin/certbot /usr/bin/certbot httpd.confの編集 vi /etc/httpd/conf/httpd.conf ↓一番下の行に追記 NameVirtualHost *:80 <VirtualHost *:80> ServerAdmin メールアドレス DocumentRoot ドキュメントルート ServerName ドメイン </VirtualHost> ・証明書を取得 & インストール certbot --apache ※初めにメールアドレスを求められたり、 　　Yes/Noを求められるので答えていくと証明書の取得とインストールが始まる 証明書の期限確認 openssl x509 -in /etc/letsencrypt/live/ドメイン/fullchain.pem -noout -dates 番外 　　うまくいかないで何回も試してたら怒られてしばらくドメインが使えなくなったので、 　　まず、お試しでやるならサブドメイン作ってからやった方が良いかもw There were too many requests of a given type : : Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168 hours: ドメイン: see https://letsencrypt.org/docs/rate-limits/

動画5：IAM (ポリシー、グループ、ロール)について学ぶ　4min IAMについて深堀りを行う → IAMポリシー・IAMグループ・IAMロールの説明 IAMポリシー アクセス許可の定義 を行うJSONドキュメント IAMユーザーやグループ、ロールに紐付けて扱う AWSが予め所持するポリシーに加え、独自に定義することも可能（IAMジェネレーターを使用する） IAMグループ IAMユーザーの集合 を定義 複数のユーザーへのアクセス許可を容易にする IAMロール AWSリソースに割り当てる。（ユーザーではなく、特定のEC2やS3に 動画6：IAM ポリシーと IAM グループを作ってみる…　12min 実際にハンヅオンでIAMポリシーの作成・割り当て、IAMグループの作成・割り当てを行う 具体的に... まず新しいIAMポリシーを作成する、以下の権限を許可 EC2インスタンスの参照 EC2インスタンスのスタート EC2インスタンスのストップを許可する このポリシーを付与されたIAMユーザーの作成とIAMグループの作成を行う 動画7：IAM ロールを試してみる…　7min 実際にリソース（EC2）にIAMロールをアタッチする。 具体的には... 何も許可しないIAMロールを作成（何も許可しない）。そのIAMロールをEC2にアタッチ。 確認作業のためにコンソールがコマンドを叩く → 許可されていないと表示 次にIAMロールの内容を適切に変更 確認作業のためにコンソールがコマンドを叩く → 表示可能（IAMロールを変更したから。 最後にこれまで作成したユーザーやロール、グループを削除する 動画8：まとめ + Next Action としてオススメのコンテンツを紹介　4min まとめ これまでの学習をまとめる。IAMの概要からIMAポリシーやグループなどについて学んだ。 今後のオススメのアクション スケーラブルハンヅオン サーバーレスWebAPI編 サーバーレス × AIサービス編 感想 初めてのAWSハンヅオン学習。とても初歩的な事であると思うが、公式が作成したハンヅオンは正確であり、わかりやすくとても勉強になった。AWS学習の導入としては最適と思いました。 最後までお読み頂きありがとうございました！！

はじめに 今回ビデオチャットSDKを利用してみようと思い、AWS Chime SDKを利用してみました。 AWS Chime SDKについてはこちらをご覧下さい。 社内の勉強会で発表したところ、意外と評判が良かったので是非作ってみて下さい( ^ω^ ) 大まかな流れ こちらのRead Me通りにすれば直ぐに出来るかと思います。 1.Github for android をクローン 2.Github for backend をクローン 3.AWSにデプロイをして「https: ~.com/prod/」のURLを受け取る 4.端末にAWSから受け取ったURLを設定 5.接続確認 事前に必要な事など AWSのアカウント AWS IAMユーザーの設定 S3バケットの作成 端末 サーバーレス構築をした事ない方向けに参考になる動画 & サイト サーバーレスについて（AWS公式） AWS Chime SDKを使ったサーバーレス構築 デモアプリを使って出来る事 下記を見る限り基本的なビデオチャットアプリの機能は用意されている印象です。 会議の準備、参加 会議タイトル（会議URL）の作成 URLを使用した会議招待 自分の会議参加者名の設定 クライアントが接続するメディアリージョンの自動選択・手動選択 メディア入出力の準備 音声入力デバイス（マイク）の選択 映像入力デバイス（カメラ、画像）の選択 映像入力クオリティ（幅、高さ、フレームレート、最大通信帯域幅）の調節 音声出力デバイス（スピーカー、イヤホン）の選択 音声・映像入出力のプレビュー 音声出力のテスト 会議の実施 Web会議（音声、ビデオ） 音声入力のミュート 会議参加者の一覧の表示 会議参加者のステータスの表示（「発言中」「ミュート」など） 画面共有（デスクトップ、コンテンツ） テキストチャット メディアメトリクス（送信・受信可能帯域幅）の確認 会議の退出 会議の終了 その他 サイマル配信 Web Audio SIPによる会議参加 ZOOMとの比較 英語サイトで音声チャットSDKについて調べるとAWS Chime SDKとZOOM SDKがよく比較されていたので、機能を比較してみました。 AWS Chimeが100名以上の通話が可能である事、通信障害がZoomに比べて少ない点以外はZOOMに軍配が上がるのではないかと思います。 最後に 最後まで見て頂き有難うございます。 Kotlin初学者向けの情報や勉強になった事等を呟いていきますのでTwitterのフォローもお願いします( ^ω^ )

AWSを学ぶ上で、情報収集源となる記事やイベントについてまとめてみた。 随時アップデート中。 AWSクラウドサービス活用資料集 AWSとは？から始まり、AWSを活用するための日本語資料や動画コンテンツが公開されている。 初心者向けの資料も豊富なので、いきなりドキュメントを読むよりはまずはサービスの概要を把握するという点で活用できる。 トップページ 直近のWebinar、JAWS-UG発表資料がアップされている。 後述のサービス別資料などはいずれもこのトップページのリンクからたどれる。 AWS初心者向け資料 AWSで最低限知っておきたい10のことシリーズがアップされている。 サービス別資料 サービス別の解説スライドと動画がアップされている。 AWS初心者向けハンズオン 初心者向けに解説資料を見ながら自分のペースで進められる。 無料かつオンデマンドでいつでも始められるが、フォームからの申込みが必要。

AWS CloudFormationテンプレートで、SecurityGroupルールの CidrIp 指定についてちょっと誤解してたので、メモ。 対象範囲指定がないとルールが作成されない 「AWS::EC2::SecurityGroup Ingress - AWS CloudFormation」を見ると CidrIp は省略可能（Required: No）となっています。ここで、省略すればAWSコンソールでいうところの「任意のIP」（0.0.0.0/0と::0）になるのかな、と思ったのが私の勘違い。 CidrIp The IPv4 address range, in CIDR format. Required: No Type: String Update requires: No interruption 実際には「 CidrIp を含むいくつかのパラメータのうち1つを必ず指定しなければいけない」とIngressルールのドキュメント先頭近くに書かれています。 You must specify only one of the following properties: CidrIp, CidrIpv6, SourcePrefixListId, SourceSecurityGroupId, or SourceSecurityGroupName. (AWS::EC2::SecurityGroup Ingress - AWS CloudFormation) Egressルールのドキュメントにも類似のどれか一つ指定必須の注意書きがあり、こちらにははっきりと「これらのパラメータのうち一つを指定しなかった場合、スタックの作成には成功しますが、ルールはセキュリティグループに追加されません」と付記されていました。 You must specify a destination security group (DestinationPrefixListId or DestinationSecurityGroupId) or a CIDR range (CidrIp or CidrIpv6). If you do not specify one of these parameters, the stack will launch successfully but the rule will not be added to the security group. （AWS::EC2::SecurityGroupEgress - AWS CloudFormation） つまりほかのパラメータも指定していない状態で「省略すれば『任意のIP』になる」という期待は的外れで、このルールが作成されません。 省略と !Ref "AWS::NoValue" と "0.0.0.0/0" 実際に次のようなCloudFormationテンプレートで、スタックを作成してみました。 IsRemoteAccessCIDR は今回 false になるようにスタック作成時のパラメータを指定しています。このため各プロトコルに対するルールで、 CidrIp は以下が指定されたことになります。 プロトコル FromPort CidrIP SSH ingress 22 "0.0.0.0/0" RDP ingress 3389 !Ref "AWS::NoValue" NICE DCV ingress 8443 （指定省略） EC2SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: EC2SecurityGroup VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: !If [IsRemoteAccessCIDR, !Ref RemoteAccessCIDR, "0.0.0.0/0"] Description: "SSH ingress" - IpProtocol: tcp FromPort: 3389 ToPort: 3389 CidrIp: !If [IsRemoteAccessCIDR, !Ref RemoteAccessCIDR, !Ref "AWS::NoValue"] Description: "RDP ingress" - IpProtocol: tcp FromPort: 8443 ToPort: 8443 Description: "NICE DCV ingress" 作成されたセキュリティグループのインバウンドルールは CidrIp に 0.0.0.0/0 を指定したSSHのルールだけが作成されており、 !Ref "AWS::NoValue" を指定したRDPと指定を省略したNICE DCV用のルールは作成されていませんでした。 指定時と省略時の動作はドキュメントの記載通り、 !Ref "AWS::NoValue" 指定時も、これは「指定すると、対応するリソースプロパティを削除」するので省略時と同等になり、ドキュメントの記載通りの動作でした。 参考 AWS::EC2::SecurityGroup Ingress - AWS CloudFormation AWS::EC2::SecurityGroupEgress - AWS CloudFormation AWS::NoValue - 擬似パラメータ参照 - AWS CloudFormation

概要 AWS EBSのストレージ/ボリュームのサイズに対する料金は秒単位で課金されます。料金は月額で設定されていますが、月額÷その月の日数÷86,400秒（24時間）が1秒当たりの料金になります。月によって1秒当たりの料金は少しだけ上下します。 AWS EBSの料金設定と課金の単位 AWSには料金設定と課金単位の粒度が違うサービスがあります。例えばEBSの料金は次のように「GB 月」と月額で設定されています（金額は2021年6月1日時点の東京リージョン）。 ボリュームタイプ 料金 汎用SSD（gp3）-ストレージ 0.096USD/GB 月 汎用SSD（gp2）ボリューム 1か月にプロビジョニングされたストレージ1GBあたり0.12USD しかしEBSのデータ量に課金は、実は秒単位です（ただし最小で60秒分は課金されます）。次のように書かれています。 gp3 ボリュームのプロビジョンドストレージ、プロビジョンド IOPS、およびプロビジョンドスループットは、1 秒ごとに課金されます (最小課金時間は 60 秒)。 gp2 ボリュームのプロビジョニング済みストレージは、1 秒ごとに課金されます (最小課金時間は 60 秒)。 実際に適用される「秒単価」 この時、料金計算には「今月の1秒当たりの料金（秒単価）」が必要になります。秒単価は、その月の秒数によって、つまりその月の日数によって変わります。次のように書かれています。 例えば、お客様が 1 か月 30 日間の期間に 12 時間 (43,200 秒) 2000 GB のボリュームをプロビジョニングしたとします。GB/月につき 0.08 USD 課金されるリージョンでは、そのボリュームに対して 2.667 USD (GB/月につき 0.08 USD x 2000 GB x 43,200 秒 / (86,400 秒/日 x 30 日/月)) が課金されます。 0.096USD/GB 月で1,000GBを使用した時、次のような単価になります。 1月など31日までの場合 … (0.096USD/GB 月)÷（86,400秒/日 × 31日/月）=0.000000035842USD/GB 秒 4月など30日までの場合 … (0.096USD/GB 月)÷（86,400秒/日 × 30日/月）=0.000000037037USD/GB 秒 うるう年の2月で29日までの場合 … (0.096USD/GB 月)÷（86,400秒/日 × 29日/月）=0.000000038314USD/GB 秒 それ以外の2月で28日までの場合 … (0.096USD/GB 月)÷（86,400秒/日 × 28日/月）=0.000000039683USD/GB 秒 月によって微妙に秒単価は上下します。 実際の料金計算 実際の料金計算は、秒単価を使うより次のような式で行う方がよいでしょう。 サイズ × 月額 × 利用秒数 ÷ 86400 ÷ その月の日数 利用期間を秒数ではなく日数で計算するなら、もっと簡単です。 サイズ × 月額 × 利用日数 ÷ その月の日数 利用しない期間はEBSボリュームを削除して利用開始時にデプロイするなど、一定サイズで利用時間を短くする場合の概算なら、月額に割合を掛けてしまう方が考えやすいことが多いです。 平日だけ（週7日のうち5日だけ）利用 … サイズ × 月額 × 5/7 定時内だけ（1日24時間のうち8時間だけ）利用 … サイズ × 月額 × 8/24 まとめ AWS EBSのストレージ/ボリュームのサイズに対する料金は秒単位で課金されます。料金は月額で設定されていますが、月額÷その月の日数÷86,400秒（24時間）が1秒当たりの料金になります。月によって1秒当たりの料金は少しだけ上下します。AWSの料金を考えるうえで、以下の二点は意識しておきたいと思いました。 時間課金の料金確認時には、料金設定単位、課金単位、最小課金時間の情報を揃える 料金設定は月間（月額）だけど、課金単位は時間単位や秒単位などのサービスがある 課金単位は秒だけど、最小課金時間が60秒などのサービスがある 日割り計算をする際は、当月の日数を意識する（1月なら31日、4月なら30日など） 料金設定単位、課金単位、最小課金時間が揃わないものとしては、例えば身近なものにEC2のオンデマンドインスタンスの料金があります。料金は時間単価で設定されています。課金も基本的には時間単位ですが、一部のLinuxインスタンスでは秒単位になります。この時、最小課金時間も別の数字になります。 オンデマンド、リザーブド、スポット形式で起動したLinuxベースのインスタンスによるAmazon EC2の使用において、請求が1秒単位 (最低60秒) で行われるようになりました。Amazon EC2 Elastic GPUとAmazon EBSボリュームも、1時間ごとの請求モデルから1秒あたり (最低60秒) の請求モデルに変更されます。（略）時間単位による請求が課せられているMicrosoft WindowsやLinuxディストリビューションを実行しているインスタンスには、秒単位による請求が適用されません。 （Amazon EC2 で 1 秒あたりの請求が可能に） 他のサービスについても、利用期間に対する料金を確認する際には、上記の3項目を見つけることを意識するとよさそうです。 参考 Amazon EBS の価格 – アマゾン ウェブ サービス オンデマンドインスタンスの料金 - Amazon EC2 (仮想サーバー) | AWS Amazon EC2 で 1 秒あたりの請求が可能に

事前にローカルで作っておいたwebサイト（Django）を、aws のサーバーを使って公開するまでにやったことをまとめました。 ウェブサーバは Nginx, アプリケーションサーバは gunicorn を使いました。 ウェブサーバ、アプリケーションサーバの概念の理解には https://view-s.co.jp/product/webapp/concept/ がとても役に立ちました。 まとめるとやったこととしては - EC2 インスタンスを作成して、IPアドレスにアクセスするとサイトが表示されるようにする - ドメインを購入して、http://hogehoge.com にアクセスするとサイトが表示されるようにする - SSL証明書を発行して、https://hogehge.com からサイトにアクセスできるようにする - その他雑多なもの AWS アカウントを作って、いろいろな初期設定をする 自分は適当な人間なので、この辺をおろそかにしたら後で後悔した。 AWS EC2 インスタンスを起動し、環境を構築 下URLを参照して、EC2インスタンス起動と環境構築を行った 前に作ったインスタンスのキーがあったので、ssh key は「既存のキーを利用する」を選択した PostgreSQL は入れなかった EC2 セキュリティグループのインバウンドに自分のIPアドレスを設定 途中で急に ssh できなくなった。 $ ssh -i "aws-ubuntu.pem" ubuntu@****.compute.amazonaws.com ssh: connect to host ****.compute.amazonaws.com port 22: Operation timed out 下を参考にセキュリティグループに編集を加えてみた。 しかし後から、インスタンスのパブリックDNSを間違えて指定して ssh しようとしていたことが原因だったと気づいた。なので、多分このセキュリティグループへの編集はいらなかったが、上の記事設定はそのままにしておいた。パブリックDNSはインスタンスの再起動で更新されるので、毎回取ってくる必要がある。Elastic IP を取得して紐付けたらその必要は多分ない。 .gitignore を追加 作ったwebアプリケーションのコードは git でバージョン管理をしていたが、基本的に個人で進めており雑な運用をしていたため、.gitignore を置いていなかった。サーバーにもコードを置いて、ローカルでコードを編集するとデータベースあたりでコンフリクトが起きて面倒なことになりそう。なので、.gitignore をしっかり置いてやることにした。 https://www.toptal.com/developers/gitignore で Django のための .gitignore コードを生成して使った。 一度 git add されたファイルはそのままだと .gitignore を無視してしまうので、下のようにキャッシュを全てクリアしてプッシュした。 git rm -r --cached . git add -A git commit -m "removed all cache to use .gitignore and reregistrated all files" git push SECRET_KEY を隠した settings.py に記載されている SECRET_KEY は本来隠さないといけないものなので、おのおののローカルのみで管理されるように設定した。今更感はある。 EC2 サーバーで github に鍵認証 次の記事を参考に ssh 接続を長持ちさせる ssh 接続がわりとすぐ切れて面倒だったので、待機できる時間を長く設定した 上の記事は効かなかったので下を試した、機能している気がする Django admin のユーザー登録をする 管理者ユーザを登録する ドメインを取得して使えるようにする お名前.comを使った これにより、ブラウザに取得したドメイン名を打ち込むと自分のサイトが表示されるようになった。 設定をした直後は、welcome nginx みたいな画面が出るが数分待つと自分のサイトが表示されるようになる。 SSL証明を使う ドメインにアクセスしたときに「安全ではありません」と出るのが気になった これで https://*** からアクセスできるようになり、「安全ではありません」の代わりに鍵のマークがついた。google は http ではなく https を推奨しており、SEO 対策としてもこれをやっておくのは大事らしい。 vscode でサーバー上のコードを編集できるようにする SSH remote の方がメジャーなようですが、SSH FS を使っています（理由はない）。

sshからEC2に接続の際にタイムアウトして接続できなかった問題。 結論 何故かVPCのインターネットゲートウェイがDetattchされていました。故に切できるはずもなく。 解決策 Attachedにて再度試して接続出来ました。