1. 目的 AWSのデータベース関連サービスの復習をしている。Aurora Serverless について、「使ってない時に勝手に停止するDBらしい」程度の認識しかなかったため、実際に使ってみてもう少し理解を深める。 2. Amazon Aurora Serverless とは（自分の理解） RDSなどと同じく、AWSマネージドのRDBだが、自動でスケールイン・アウトするなどよりマネージドの範囲が増えているもの。 類似サービス(RDS, Aurora)との比較はこちらのサイトを参照。 Aurora Serverlessを実際に使ってみたメリットとデメリット 2021/4現在、GAされているものは「v1」とされており、機能拡張版の「v2」がpreview提供されている。今回は基本を学ぶため、普通の「v1」を使用する。 3. やったこと Aurora ServerlessのDBを作成する。 自動起動／自動停止の動作を確認し、停止状態から何秒くらいで起動するのか測定する。 ユースケースとして、WordPressのバックエンドとして使ってみる。 Data APIを有効化し、Lambda関数からのクエリを実行する。 4. 構成図 5. 設定手順 5.1 Aurora Serverless DBの作成 Aurora ServerlessのDBを作成する。 マネージメントコンソールの「Amazon RDS - データベース - データベース作成」から以下の設定にて作成する。 エンジンのタイプ: Amazon Aurora キャパシティータイプ: サーバーレス　※この選択により、Aurora Serverlessになる。 数分間アイドル状態のままの場合、コンピューティング性能を一時停止する：　チェックを入れる　※このチェックをONにしないと、自動停止機能が有効にならない（初期設定はOFF）。 Aurora Serverless DBを作成したVPC内に、MySQLクライアントをインストールしたEC2インスタンスを用意し、MySQLクライアントを用いて接続する。接続後、動作確認用のテーブルを作成する。 [ec2-user@ip-10-0-0-232 ~]$ mysql -h mksamba-aurora-serverless-qiita.cluster-XXXXXXXXXXXX.ap-northeast-1.rds.amazonaws.com -P 3306 -u admin -p mysql> create database mksambadb; mysql> use mksambadb; mysql> create table mksambadb.mytable(id int, stamp varchar(30)); 5.2 自動起動／自動停止の動作確認 DBが起動中なのか停止しているのか、またいつステータスが変わったのかはマネージメントコンソールで確認できる。 サイズが「0個のキャパシティーユニット」の場合、停止している。（1個以上であれば起動している。） 「ログとイベント」にて、起動／停止、スケールイン／アウトの履歴が確認できる。 DBが停止中に、EC2インスタンスにて、「DBに接続しデータを1行INSERTする」スクリプトを実行し動作を確認する。 起動に要する時間（スクリプトの開始時刻と、DB接続成功時刻の差）が27秒になっている。 connectiontest.py import MySQLdb import datetime num = 0 dt_now = datetime.datetime.now() print("startaccess:",dt_now) connection = MySQLdb.connect( host='mksamba-aurora-serverless-qiita.cluster-XXXXXXXXXXXX.ap-northeast-1.rds.amazonaws.com', user='admin', passwd='password', db='mksambadb') cursor = connection.cursor() dt_now = datetime.datetime.now() print("connectionsuccess:",dt_now) cursor.execute("INSERT INTO mksambadb.mytable VALUES (%s, %s)", (num, dt_now)) connection.commit() connection.close() [ec2-user@ip-10-0-0-232 ~]$ python3 connectiontest.py startaccess: 2021-04-17 05:41:02.592952 connectionsuccess: 2021-04-17 05:41:29.695891 5.3 WordPressバックエンドとしての使用 AWS公式「チュートリアル: Amazon Linux 2 での WordPress ブログのホスト」に従い、WordPressサイトを構築する。 上記の手順ではEC2インスタンス内にMySQLをインストールしているが、その部分の手順のみAurora Serverless DBを使用するよう変更する。 自前のMySQLやRDS同様、普通にバックエンドDBとして使うことができ、サイトにアクセスがない場合に自動停止が、停止中に再びアクセスした場合に自動起動が発生した。 5.4 Data APIの利用 5.4.1 Data APIとは Data APIは、セッションを張らずにAurora Serverless DB内のデータにアクセスできるAPI。以下の手順をふめば利用可能となる。 DB側でData APIを有効化する。 DB接続用のID/PasswordをSecret Managerに登録する。 クライアント(例: Lambda関数) で、Secret ManagerからID/Passwordを取得し、Data API経由でAurora Serverlessにアクセスする。 5.4.2 Data APIの有効化 DBの設定を変更し、Data APIを有効化する。 5.4.3 マネージメントコンソールからのData API動作確認 マネージメントコンソールからData APIの動作を確認する。Amazon RDS - Query Editor を選択すると、DBへの接続情報を求められるため、今回作成したAurora Serverless DBの情報を入力する。 マネージメントコンソール上でSQLのクエリを実行することができる。 5.4.4 Lambda関数からのData API利用 Lambdaなど外部からのData API経由でのアクセスを行うため、Secret ManagerにDBのID/Passwordを登録する。手順は別記事「【初心者】AWS Secrets Manager と AWS Systems Manager Parameter Store を使ってみる」参照。 以下の内容を含むLambda関数を作成する。 Secret Managerから、Aurora Serverless DBに接続するためのID/Passwordを取得 Data API経由でAurora Serverless DBに接続し、select文を実行 コードはAWS公式「Aurora Serverless の Data API の使用」内のサンプルをそのままコピペする。 Lambda関数に対して、SecretManager、KMS、RDS DataServiceの権限付与が必要（今回は検証なのでPoweruser相当の権限を付けている）。 dataapi-test.py import json import boto3 def lambda_handler(event, context): rdsData = boto3.client('rds-data') cluster_arn = '[Aurora Serverless DBクラスタのARN]' secret_arn = '[SecretManagerのSecretのARN]' response1 = rdsData.execute_statement( resourceArn = cluster_arn, secretArn = secret_arn, database = 'mksambadb', sql = 'select * from mytable') print (response1) 実行結果は以下の通り。少し見にくいが、JSON形式でレコードの取得を行うことができた。 {'ResponseMetadata': {'RequestId': '4e69e984-c5b1-4f53-ac9a-dca6c1f37ce8', 'HTTPStatusCode': 200, 'HTTPHeaders': {'x-amzn-requestid': '4e69e984-c5b1-4f53-ac9a-dca6c1f37ce8', 'content-type': 'application/json', 'content-length': '103', 'date': 'Sat, 17 Apr 2021 06:40:52 GMT'}, 'RetryAttempts': 0}, 'numberOfRecordsUpdated': 0, 'records': [[{'longValue': 0}, {'stringValue': '2021-04-17 05:41:29.695891'}]]} 6.所感 自動停止後、最初にアクセスする人が数十秒待たされるくらいであれば、開発・検証用途であれば許容範囲かなと思った。

何回やっても忘れるのでメモ。 結論 アーキテクチャーや名前などの検索条件は適宜調整する。 ## aws ec2 describe-images --owners amazon --filters "Name=architecture,Values=arm64" "Name=name,Values=amzn2-ami-hvm-*" --query "sort_by(Images, &CreationDate)[-1]" | yq eval -P Architecture: arm64 CreationDate: "2021-03-26T22:38:04.000Z" ImageId: ami-03888b30ba5826eed ImageLocation: amazon/amzn2-ami-hvm-2.0.20210326.0-arm64-gp2 ImageType: machine Public: true OwnerId: "137112412989" PlatformDetails: Linux/UNIX UsageOperation: RunInstances State: available BlockDeviceMappings: - DeviceName: /dev/xvda Ebs: DeleteOnTermination: true SnapshotId: snap-0106c0756363a552d VolumeSize: 8 VolumeType: gp2 Encrypted: false Description: Amazon Linux 2 LTS Arm64 AMI 2.0.20210326.0 arm64 HVM gp2 EnaSupport: true Hypervisor: xen ImageOwnerAlias: amazon Name: amzn2-ami-hvm-2.0.20210326.0-arm64-gp2 RootDeviceName: /dev/xvda RootDeviceType: ebs SriovNetSupport: simple VirtualizationType: hvm 参考文献 Find a Linux AMI - Amazon Elastic Compute Cloud Query for the latest Amazon Linux AMI IDs using AWS Systems Manager Parameter Store | AWS Compute Blog どっとはらい。

やってみる系の記事でございます。 業務でAmplifyを使っておりますが、とある検索フォームがありまして、そのフォームでは地域とか商品のカテゴリとかを選択できます。 そしてAmplifyではPinpointを簡単に使う仕組みがあります。 これにユーザーIDをキーにした複数の条件をぶち込んでってみたらどんな感じで表示できるのだろうか、と思ったので深く考えずに試してみます。 Analytics.recordってやるだけでいいので、DB作ってほにゃららってやるよりは楽そうなんですよね。 やってみる事 Amplify + Analyticsを使う AnalyticsにはユーザーIDを含めたjsonをpushする 管理画面で確認してみる Amplify + Analyticsを使う ではさっくりと準備していきます。 さっくりやりたいので、simpleにvueでいきます。ただ、vue3に対応してるとの事なので3で。 amplify cliのインストール 入ってる前提で進めてしまいます。 プロジェクト生成 $ npm install -g @vue/cli $ vue create analiticsExample Invalid project name: "analiticsExample" Warning: name can no longer contain capital letters km@kenoMacBook-Pro ~ % vue create analitics-example ? Your connection to the default npm registry seems to be slow. Use https://registry.npm.taobao.org for faster installation? Yes Vue CLI v4.5.12 ? Please pick a preset: Default (Vue 3 Preview) ([Vue 3] babel, eslint) Vue CLI v4.5.12 ✨ Creating project in /Users/km/analitics-example. ? Initializing git repository... ⚙️ Installing CLI plugins. This might take a while... added 1285 packages in 1m ? Invoking generators... ? Installing additional dependencies... added 77 packages in 9s ⚓ Running completion hooks... ? Generating README.md... ? Successfully created project analitics-example. ? Get started with the following commands: $ cd analitics-example $ npm run serve analytics追加 これだけでいけるはず。 $ cd analitics-example $ npm install --save aws-amplify $ amplify init Note: It is recommended to run this command from the root of your app directory ? Enter a name for the project analiticsexample The following configuration will be applied: Project information | Name: analiticsexample | Environment: dev | Default editor: Visual Studio Code | App type: javascript | Javascript framework: vue | Source Directory Path: src | Distribution Directory Path: dist | Build Command: npm run-script build | Start Command: npm run-script serve ? Initialize the project with the above configuration? Yes Using default provider awscloudformation For more information on AWS Profiles, see: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html ? Please choose the profile you want to use default ... $ amplify add analytics ? Select an Analytics provider Amazon Pinpoint ? Provide your pinpoint resource name: analiticsexample Adding analytics would add the Auth category to the project if not already added. ... $ amplify push Do you want to allow guests and unauthenticated users to send analytics events? の所をYesにしてもAuthのリソースが作られます。 Signin関係なしに使いたいんだけどな。 AnalyticsにはユーザーIDをキーとしたjsonをpushする 簡単な画面を作りつつ、Pinpointにpushしてみます。 ただ、Signinしないとうまくいかなかったので先にSigninフォームを生やす。 なお、Vue３のsignIn周りはちょっと変わってました。 一旦、main.jsとApp.jsは上記と同じやつにします。 @aws-amplify/ui-components これで　SignIn画面が作られるので、適当にユーザー作ってログインしておきます。 次に、App.vueを変更します。 src/App.vue <template> <div> <img alt="Vue logo" src="./assets/logo.png"> <div v-if="authState !== 'signedin'">You are signed out.</div> <amplify-authenticator> <div v-if="authState === 'signedin' && user"> <div>Hello, {{user.username}}</div> </div> <amplify-sign-out></amplify-sign-out> <p> <label>userId: </label> <input v-model="userId" /> </p> <p> <select v-model="pref"> <option v-for="pref in prefList" v-bind:key="pref.value"> {{ pref.text }} </option> </select> <select v-model="item"> <option v-for="item in itemList" v-bind:key="item.value"> {{ item.text }} </option> </select> </p> <p> <button @click="sendData">sendData</button> </p> </amplify-authenticator> </div> </template> <script> import { onAuthUIStateChange } from '@aws-amplify/ui-components' import { Analytics } from 'aws-amplify'; export default { name: 'App', created() { this.unsubscribeAuth = onAuthUIStateChange((authState, authData) => { this.authState = authState; this.user = authData; }) }, data() { return { user: undefined, authState: undefined, unsubscribeAuth: undefined, userId: "", pref: "山形県", item: "マグロ", prefList: [ { text: "山形県", value:1 }, { text: "山梨県", value:2 }, { text: "山口県", value:3 }, { text: "その他", value:9 }, ], itemList: [ { text: "マグロ", value:1 }, { text: "はまち", value:2 }, { text: "えんがわ", value:3 }, { text: "わかめ", value:4 }, ], } }, methods: { sendData: function () { const val = { name: "searchHistory", attributes: { userId: this.userId, pref: this.pref, item: this.item, } } Analytics.record(val); console.log(val); return true; }, }, beforeUnmount() { this.unsubscribeAuth(); }, } </script> inputフォームとSelectボックスを二つつくりました。 ユーザーIDと都道府県と商品名。 これをまとめてPinpointに投げてみてます。 SearchHistoryって名前で検索値がattributesで入ってきてるはず。 管理画面で確認してみる さて、じゃあPinpointの画面でみてみましょう。 なお、Amplifyのコンソールからたどれるかと思いました・・が・・ なぜだかus-east-2に作られてて、リージョンを切り替えないとみれませんでした。 Pinpointの画面 まず、イベント情報のCSVはあっさりとDLできましたが、 日別のイベント数、セッション数、エンドポイント数しか取れてませんでした。 この詳細情報っていうのを有効にしないといけない？ ということで早速有効化してみます。 詳細の有効化後 有効化されるまでに30分程度かかりましたが、無事にフィルターでイベントを選択できるようになってました。 なお、CSVのDLはフィルターで絞り込まれたものが落ちてきます。 んー、一括で属性入りのやつを落としたいんだけど、、そういう事やるにはKinesis Streamとかに垂れながすしかないのかな。 理想を言うと、１つの属性(例えばユーザーID)で絞り込んだ時に、他の属性の選択状況が表示されてほしかったが、だいぶ違った。 まとめ analyticsは今回のような目的で使うもんじゃない。あくまでGA的な使い方。 データを蓄積したいならシンプルにapi叩いてDBに差し込むのが良い？ もし、統計も見たいし、データも貯めたいのであればPinpoint+EventStream+Lambdaの形がいいかもしれない。 (PinpointがPush通知だとかそういうマーケティングに生きるものだというのは知ってる)

AWSのAurora Severlessを使いAPIを組もうかと思ったのですが、素人過ぎてデータのやり取りすらままならんかったので、その工程を残しました。 執筆時点 2021/04/17 Aurora severless 構築 AmazonRDSのコンソールを開きます 「データベースを作成」を開始 データベース作成方法: 標準作成 エンジンのオプション： Amazon Aurora エディション: MySQL との互換性を持つ Amazon Aurora キャパシティータイプ：サーバーレス バージョン：Aurora(MySQL)-5.6.10a DB クラスター識別子: お好みのDB名（ここではtest-db1) マスターユーザー名: admin (本番はここもadmin以外にすべきか？） マスターパスワード： お好きなパスワード キャパシティの設定： 最小Aurora キャパシティユニット 1, 最大Aurora キャパシティユニット 1 スケーリングの追加設定：「数分間アイドル状態のままの場合コンピューティング性能を一時停止する」にチェック、30分のアイドルで１時停止（開発用につくるため開発時間外の費用を抑えるため） VPC: デフォルトVPC サブネットグループ: デフォルトvpc-〇〇 既存のVPCセキュリティグループ: default 追加の接続設定：Data APIにチェック データベースを作成を押す ここでDataAPIにチェックを入れたのは、Aurora Severlessとの交信にはこのDataAPIが必要になるためです。結構大切なオプションなのに、デフォルトでチェックが入っていないので注意。 Aurora severlessのリソースARNをメモする AmazonRDSのコンソールを開きます データベースを開く 作成したDBをダブルクリック シークレットの作成 DBにアクセスする際、このシークレットを使ってユーザやパスワードの代わりにするらしい。 1. Secrets Managerを開く 1. 「新しいシークレットを保存する」を選択 1. auroraのために設定した「ユーザ名」「パスワード」を記入 1. DBインスタンスに先程作成したauroraを選択 1. 次へ 1. シークレットの名前や説明を適当につける。今回は名前を「test-db1-admin-secret」とした 1. 次へ 1. 自動ローテーションは無効のまま、次へ 1. シークレットを作成する シークレットができたら、出来上がったシークレットを開き、シークレットのARNをメモする データベースに接続してクエリディタを開く データベースを操作するためのエディタを開きます AmazonRDSに戻る 左側「データベース」タブを選択 作成したauroraDBを選択 右上「アクション」→「クエリ」を選択 以下を確認/入力 データベースインスタンスが作成したものになっていること データベースユーザ名に「Secrets Manager ARNと接続する」を選択 前項「シークレットを作成」で作ったシークレットARNを写す 「データベースに接続」します データベースにテーブルやデータを追加 作ったままのauroraには何もデータが入っていないので、テスト用のDBとテーブルを作成し、データも追加します。 とりあえず、デフォルトでエディタに表記されているクエリselect * from information_schema.tables;を実行してみる この時点ではDBが休止状態に入っている可能性があり、エラーが返ってくるかもしれません。数分経ってからもう一度実行してみましょう。 実行できたら、DBを追加するためにcreate database mydb;を実行。mydbはDB名なので好みで変更可 show databases;を実行して、dbが作成できていることを確認 データテーブルを追加しますcreate table mydb.sample_data (id int, name varchar(20), dt datetime);を実行。 show tables from mydbで作成できたことを確認 insert into mydb.sample_data (id, name, dt) values (100, 'inten', now());を実行。適当なデータを挿入する。 自分で複数挿入すると面白いので推奨です。select * from mydb.sample_data;で入力値を確認できます。 僕は最終的に次のようなテーブルを作成しました。 AWS CLI用にIAMユーザを作成 いよいよpythonを使った接続です。 しかし、このためにはAWS CLI用のユーザの作成を先に済ます必要があります。 AWS CLIは今までコンソールで行っていたことを、ローカルのPCなどの他の環境でも行うためのツールです。 pythonでAWSのサービスに接続する際も間接的にAWS CLIを使ってAWSのサービスとやり取りを行っているようです。 awsコンソールにIAMが必要なように、AWS CLIにもIAMが必要です。 awsコンソールでIAMを開きます ユーザを追加を選択 「プログラムによるアクセス」にチェックを入れ、ユーザ名を記入する 権限を付与する 権限はそれぞれ方針があると思います。「AdministratorAccess」あたりを付けるのが楽ですが、注意は必要です。 確認する シークレットアクセスキーを保存する ここで得られるシークレットアクセスキーはこの機会を逃すと二度と取得できません。念の為csvもダウンロードしておきましょう。 AWS CLIのインストールと設定 pip install awscli aws configureを実行。以下のように入力 AWS Access Key ID [None]: [作成したIAMのアクセスキー] AWS Secret Access Key [None]: [作成したIAMのシークレットアクセスキー] Default region name [None]: ap-northeast-1 Default output format [None]: json これでpythonがAWS CLIを使ってauroraと接続するための準備が整いました。 pydataapiを使ってpythonで接続 ここからはpydataapiを使って、ローカル環境からauroraにアクセスしてみましょう。 pip install pydataapi 次のコードをコピー/編集して、実行する from pydataapi import DataAPI, Result database = 'mydb' resource_arn = 'aurora severlessのリソースARN' secret_arn = 'aurora severlessのユーザ情報のシークレットARN' data_api = DataAPI(resource_arn=resource_arn, secret_arn=secret_arn, database=database) result: Result = data_api.execute('select * from sample_data') print(result.all()) きちんと、auroraDBに格納した値が見れたと思います。 data_api_execute.executeの引数のクエリを書き換えればselect以外の命令も実行できます。 pydataapiにはSQLAlchmemyと接続する方法も用意されていますからORMが使いたい方もこれでOK! ここから先は通常のRDB同様に操作可能です。 また、単にpandas.DataFrameをRDBから読み込みたいだけの場合 from sqlalchemy.engine import create_engine engine = create_engine( 'mysql+pydataapi://', connect_args={ 'resource_arn': resource_arn, 'secret_arn': secret_arn, 'database': database} ) pd.read_sql("select * from sample_data", engine, parse_dates=['dt']) のように、read_sql関数にdataapiとsqlalchemyで作られたコネクションengineを渡すことで簡単にRDBからDataFrameを取得できます。 以上。

新しくec2 instanseを作ってremote sshに繋げた際、vscodeのremote sshで ローカルからドラッグアンドドロップしても、権限がないため、できません。 権限付与したいディレクトリに移動して、 sudo chmod -R 777 ./ で権限を与えてやることでできます。 ただ、セキュリティ、管理には気を付けてください。

背景・目的 初めて React を触ってみたのでその備忘録です。 React のチュートリアルでアプリケーションを作成し、AWS でデプロイし公開できるところまで。 完成品の Git Repository はこちら 環境 OS MacOS Catalina 10.15.7 React v17.0.2 ブラウザ Google Chrome 89.0.4389.90（Official Build） （x86_64） アプリの作成 Reactチュートリアル に沿って作成していきます。 チュートリアルの準備 環境構築 今回はローカルへ開発環境を構築していきます。 Node.js をインストール Node.jsの公式サイトへアクセスしインストーラをダウンロードします。 今回は推奨版の v14.16.11 をダウロードしました。 インストーラの手順にしたがってインストール。 React アプリの作成 以下のコマンドでプロジェクトを作成します。 npx create-react-app my-app プロジェクト内の src ディレクト内のファイルを全て削除します。src ディレクトリ自体は削除しないので注意。 cd my-app cd src # If you're using a Mac or Linux: rm -f * # Or, if you're on Windows: del * # Then, switch back to the project folder cd .. src ディレクトリ直下に以下のファイルを作成 index.css body { font: 14px "Century Gothic", Futura, sans-serif; margin: 20px; } ol, ul { padding-left: 30px; } .board-row:after { clear: both; content: ""; display: table; } .status { margin-bottom: 10px; } .square { background: #fff; border: 1px solid #999; float: left; font-size: 24px; font-weight: bold; line-height: 34px; height: 34px; margin-right: -1px; margin-top: -1px; padding: 0; text-align: center; width: 34px; } .square:focus { outline: none; } .kbd-navigation .square:focus { background: #ddd; } .game { display: flex; flex-direction: row; } .game-info { margin-left: 20px; } index.js import React from 'react'; import ReactDOM from 'react-dom'; import './index.css'; class Square extends React.Component { render() { return ( <button className="square"> {/* TODO */} </button> ); } } class Board extends React.Component { renderSquare(i) { return <Square />; } render() { const status = 'Next player: X'; return ( <div> <div className="status">{status}</div> <div className="board-row"> {this.renderSquare(0)} {this.renderSquare(1)} {this.renderSquare(2)} </div> <div className="board-row"> {this.renderSquare(3)} {this.renderSquare(4)} {this.renderSquare(5)} </div> <div className="board-row"> {this.renderSquare(6)} {this.renderSquare(7)} {this.renderSquare(8)} </div> </div> ); } } class Game extends React.Component { render() { return ( <div className="game"> <div className="game-board"> <Board /> </div> <div className="game-info"> <div>{/* status */}</div> <ol>{/* TODO */}</ol> </div> </div> ); } } // ======================================== ReactDOM.render( <Game />, document.getElementById('root') ); チュートリアルに沿ってアプリケーションを作成 書かれた通りに三目並べゲームを作成します。内容に関しては後から追記予定 デプロイ 手動でデプロイ AWS マネジメントコンソールにアクセスし AWS Amplify を選択 Deliver の 「Get started」 をクリック 連携先を選択します。今回は Github を選択。 デプロイ対象のリポジトリ/ブランチを選択して「次へ」をクリック デフォルト設定で「次へ」をクリック 内容を確認し「保存してデプロイ」をクリック 検証まで全てチェックが付けばデプロイ完了。左下のリンクから公開されたアプリケーションへアクセスできます。 自動デプロイ src 直下へ以下のファイルを作成し、リポジトリへ Push する。 App.js import React from 'react'; import logo from './logo.svg'; import './App.css'; function App() { return ( <div className="App"> <header className="App-header"> <img src={logo} className="App-logo" alt="logo" /> <h1>Hello from V2</h1> </header> </div> ); } export default App; 感想 とりあえずアプリケーションを公開するところまで完了しました。 DB がない分 Rails なんかに比べるとデプロイは非常に簡単ですね。(AWS Apmlify 様々です) 書き方のお作法なんかは理解できましたが HTML の描画周りはまだまだ勉強の予知がありそうです。 ここから見た目や機能追加なんかしながら理解を深めていければと思います！

まだまだEC2を扱うことが多い EC2は管理する範囲が広いので利用するには大変なのですが、クラウド移行の文脈ではまだまだ多く利用されているのが事実です。そこでEC2を利用することを揶揄するのではなく、また諦めるのでもなく、できる範囲で効率化をしていきたいと考えています。 ということで、Systems Managerを利用 今回は、EC2にClamAV(アンチウイルスソフト)をインストールするという作業をSystems ManagerのRun Commandを利用してなんとか効率化していこうという試みをしてみました。 Run Commandとは？ Run CommandはEC2インスタンスに対して特定のコマンドを実行することができるSystems Managerの機能の1つです。 上の画面はコマンドを実行するための画面で、実際に実行されるコマンドは共有リソース>ドキュメントとして登録する必要があります。 今回はこのドキュメントにClamAVをインストールしConfigファイルを修正してServiceを有効化する内容を仕込んでみました。 設定方法 まずはドキュメントの設定をします。 コンテンツにYAMLを指定して、その中に以下の内容をコピペします RunCommand.yaml --- schemaVersion: '2.2' description: Software Inventory Policy Document. mainSteps: - action: aws:runShellScript name: install #ここでClamAVをインストール inputs: runCommand: - amazon-linux-extras install epel - yum install -y clamav clamav-update clamd - action: aws:runShellScript name: makelogs #ログの出力先を作成 inputs: runCommand: - mkdir /var/log/clamav - cd /var/log/clamav/ - touch clam.log - chmod 666 clam.log - action: aws:runShellScript name: configmodify #Configファイル(/etc/clamd.d/scan.conf)の修正 inputs: runCommand: - cp /etc/clamd.d/scan.conf /etc/clamd.d/scan.conf.org - sed -i -e 's%#LogFile /var/log/clamd.scan%LogFile /var/log/clamav/clam.log%g' -e 's/#LogFileUnlock yes/LogFileUnlock yes/g' -e 's/#LogFileMaxSize 2M/LogFileMaxSize 2M/g' -e 's/#LogTime yes/LogTime yes/g' -e 's/#LogVerbose yes/LogVerbose yes/g' -e 's/#LogRotate yes/LogRotate yes/g' -e 's/#TCPSocket 3310/TCPSocket 3310/g' -e 's/#TCPAddr 127.0.0.1/TCPAddr 127.0.0.1/g' -e 's%#ExcludePath ^/proc/%ExcludePath ^/proc/%g' -e 's%#ExcludePath ^/sys/%ExcludePath ^/sys/%g' -e 's/#User clamscan/User root/g' -e '$ a OnAccessIncludePath /home/ec2-user' /etc/clamd.d/scan.conf - sed -i -e 's%#UpdateLogFile /var/log/freshclam.log%UpdateLogFile /var/log/freshclam.log%g' /etc/freshclam.conf - action: aws:runShellScript name: start #Serviceの開始と有効化 inputs: runCommand: - systemctl start clamd@scan - systemctl enable clamd@scan - systemctl start clamav-clamonacc.service - systemctl enable clamav-clamonacc.service - systemctl start clamav-freshclam - systemctl enable clamav-freshclam - action: aws:runShellScript name: cronsetting #定期スキャンのcron設定 inputs: runCommand: - (crontab -l; echo "40 * * * * clamdscan /home/ec2-user -l /var/log/clamav/clam.log") | crontab - 以上で設定完了です。 ClamAVのConfigの修正については以下を参照しています。 ClamAVによるリアルタイムスキャンの設定 | 稲葉サーバーデザイン Run Commandの実行 ドキュメントの準備ができたのであとはRun Commandを実行するだけです。設定対象のEC2が1台であればいいですが、数台に増えてくると1台ずつOSに乗り込んでコマンドを実行するのは大変です。これがRun Commandであれば1回実行すればいいだけなので便利ですね！ 今回ターゲットとなるインスタンスは手動で設定していますが、ここをタグで指定したりすればより便利です。 以下の画像が実行結果です。成功したのが分かります。 ドキュメントに登録したYAMLでnameのところにつけた名前がステップとして分かれて表示されており、ステップ毎の結果を見ることができます。エラーがあった場合は「▶Error」のところにその内容が表示されます。(今回エラーは出てないです) YAMLの書き方次第で色々できそう 今回は、ClamAVのインストールだけをドキュメントとして保存し実行しましたが、この前段階であるHostnameの設定や言語・時刻設定などOSを作成したら実行する基本的なこともドキュメントにしRun Commandで実行できます。以下のような使い方です。 Amazon Linux 2用 AWS Systems ManagerでOSの簡易設定ドキュメントを作ってみた | DevelopersIO 上記の例もそうですし、今回のClamAVインストールもsedでconfigを書き換えたりしていて、何でもできることが魅力的なのですが、一方で冪等性とかは慎重に見極めたほうがいいと思いました。 今回の場合だと何度もRun Commandを実行するとcronが複数登録されてしまっていたなんてこともありました。YAMLの書き方次第だとは思いますが、、、 とはいえ、EC2を利用する際には積極的にSystems Managerを利用して設定や運用管理をオンプレの延長のようにさせないようにやっていきたいです。

この記事の目的 aws s3のパブリックアクセス周りの設定がよくわからなかったのでまとめる パブリックアクセスとは s3はバケットを用意してその中にオブジェクト（画像）を入れていく。パブリックアクセス設定はバケットに対しての公開設定 基本的にパブリックアクセスを全部offにしていてもiamで許可しているユーザーは保存できる そもそもの勘違い。 ブロックパブリックアクセス (バケット設定)を設定する上記画面だがそもそもこの画面は設定自体をいじるというよりも許可を勝手にonにしないよという設定。ここを設定することで新しく作った際にonになってたりするのを防ぐ。 3つのアクセス権限編集 ACL(アクセスコントロールリスト) バケットポリシー IAMポリシー s3には上記3つのアクセス権限の編集方法があり、この３つどれかを通ってアクセスされる。基本はIAMで管理されるがawsアカウントのない外部からの処理を上二つで受け、そのアクセス権限をこのブロックパブリックアクセス (バケット設定)で設定している。 参考資料

はじめに 自主制作したwebページをS3にて公開しようとしたところフォルダ内のオブジェクトにアクセス出来なかったため、アクセス出来るようになるまでの手順を記しておきます。 目次 1.バケットの作成 2.静的ウェブサイトホスティングを有効にする 3.パブリックアクセスの設定 4.バケットポリシーの設定 5.オブジェクトの配置 6.オブジェクトの公開設定 7.アカウントのブロックパブリックアクセス設定 8.接続確認 バケットの作成 AWSのマネジメントコンソールにサインインしてS3を開く。 マネジメントコンソールのアドレス(https://console.aws.amazon.com/s3/) S3を開いた後に「バケットを作成」を選択。 「バケット名」「AWSリージョン」の設定。 「バケット名」は任意のもの。 「AWSリージョン」は最も近いものにする。日本なら東京リージョンか大阪リージョンで海外のものを設定するとレイテンシーやコストの問題が発生する。 その他の設定はデフォルトで問題ないです。 ブロックパブリックアクセス設定は後から設定するのでそのままで問題なし。 画面下部の「バケットを作成」を選択 バケットの作成が成功すると画面上部に作成された旨のメッセージが出ます。 2.静的ウェブサイトホスティングを有効にする 作成したバケットの「名前」を選択 「プロパティ」を選択 静的ウェブサイトホスティングの「編集する」を選択 静的ウェブサイトホスティングを「有効にする」を選択 「インデックスドキュメント」は任意 「エラードキュメント」は任意 画面下部の「変更の保存」を選択 3.パブリックアクセスの設定 「アクセス許可」を選択 「ブロックパブリックアクセス「バケット設定」の「編集する」を選択 アクセスの設定を完了する前に下記を確認するように公式からアナウンスされてます (https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-control-block-public-access.html) 「パブリックアクセスをすべて ブロック」のチェックを外す 「変更の保存」を選択 「フィールド」に「確認」を入力 「確認」を選択 4.バケットポリシーの設定 「アクセス許可」を選択 「バケットポリシー」の「編集する」を選択 「ポリシー」に必要な情報を記載する。 ""Resource""以下に「バケットARN」を設定 画像下にテンプレートコード記載あり テンプレート { 　　　　"Version": "2012-10-17", 　　　　"Statement": [ 　　　　{ 　　　　　　　"Sid": "PublicReadGetObject", 　　　　　　　"Effect": "Allow", 　　　　　　　"Principal": "", 　　　　　　　"Action": [ 　　　　　　　　　"s3:GetObject" 　　　　　　　], 　　　　　　　"Resource": [ 　　　　　　　　　"arn:aws:s3:::Bucket-Name/" 　　　　　　　] 　　　　} 　　　　] } 問題なければ「変更の保存」を選択 設定が適用されると「パブリックにアクセス可能」が表示されます 5.オブジェクトの配置 「オブジェクト」を選択 「アップロード」を選択 追加したいファイル、フォルダをアップロードする 「ドラッグ&ドロップ」「ファイルの追加」「フォルダの追加」で追加可能 追加できたら「アップロード」を選択 完了すると画面上部に「アップロードに成功しました」の表示が出ます 6.オブジェクトの公開設定 「オブジェクト」を選択 公開設定を行うとファイル間でアクセス出来るようになり、htmlからcss、jsの読み込みができます 公開したいファイル、フォルダを選択。今回はHTMLを設定する ファイルまで来れたら「オブジェクトアクション」を選択 「オブジェクトアクション」の「公開する」を選択 「公開する」を選択 完了すると画面上部に「パブリックアクセスが正常に編集されました」の表示が出ます ファイルが複数ある場合はファイルごとに「公開する」で設定 7.アカウントのブロックパブリックアクセス設定 S3のメニューにある「このアカウントのブロックパブリックアクセス設定」を選択 「編集する」を選択 「パブリックアクセスをすべて ブロック」のチェックを外します 「変更の保存」を選択 「フィールド」に「確認」を入力 「確認」を選択 完了すると「このアカウントのブロックパブリックアクセス設定が正常に更新されました。」と表示されます 8.接続確認 オブジェクトURLからアクセスし、接続確認 「オブジェクト」を選択 インデックスオブジェクトに設定したファイルまで移動 インデックスオブジェクトに設定したファイルの「オブジェクトURL」を選択 問題なく遷移すれば完了です 参考

プレイスメントグループとは？ インスタンス間の通信速度を高速化させる機能で、 インスタンスをグループ化し、物理的に近い距離に配置するします プレイスメントグループの種類 クラスタプレイスメントグループ 単一AZ内のインスタンスをグループ化したもので、 複数のAZにまたがることはできません。 EC2間で高ネットワークスループットが発生する場合に適しています パーティションプレイスメントグループ 論理的なパーティションに分散されているグループで 複数のAZに分散させることが可能です HDFSなど大規模なワークロードに適しています スプレッドプレイスメントグループ 異なるハードウェアに配置されるグループで 複数のAZにまたがることが可能です EC2がお互いに分離して保持される必要があるアプリケーションに適しています クラスタプレイスメントグループ を試す 構成 EC2の作成 ※EC2の基本的な作成方法は こちら を確認ください インスタンスタイプはm4.largeにしました。 ある程度大きいほうがいいかなと。 変更した箇所は以下のプレイスメントグループの設定です プレイスメントグループの設定を確認 EC2 > プレイスメントグループ で作成したプレイスメントグループを確認することが出来ます。 疎通確認 cluster1からcluster2に疎通確認をしました。 [root@ip-XXX-XXX-XXX-XXX ~]# ping XXX.XXX.XXX.XXX PING XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 56(84) bytes of data. 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=1 ttl=255 time=0.124 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=2 ttl=255 time=0.119 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=3 ttl=255 time=0.129 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=4 ttl=255 time=0.132 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=5 ttl=255 time=0.131 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=6 ttl=255 time=0.130 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=7 ttl=255 time=0.123 ms パーティションプレイスメントグループ を試す 構成 先ほどとほぼ同様でプレイスメントグループ化したサーバを2つ用意しておき、 片方へpingを飛ばします。 EC2の作成 ※EC2の基本的な作成方法は こちら を確認ください 先程同様インスタンスタイプはm4.largeになります。 変更した箇所は以下です。 プレイスメントグループの設定を確認 EC2と同時にプレイスメントグループも作成されました 疎通確認 [root@ip-XXX.XXX.XXX.XXX ~]# ping XXX.XXX.XXX.XXX PING XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 56(84) bytes of data. 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=1 ttl=255 time=0.129 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=2 ttl=255 time=0.142 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=3 ttl=255 time=0.140 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=4 ttl=255 time=0.143 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=5 ttl=255 time=0.131 ms スプレッドプレイスメントグループ を試す 構成 構成特に変わらず、スプレッドプレイスメントグループ化したEC2の片方からpingを飛ばします 32021-04-14 # プレイスメントグループを試してみる - diagrams.net - Go EC2の作成 ※EC2の基本的な作成方法は こちら を確認ください 変更したのは以下の箇所です。 2021-04-142インスタンスウィザードを起動 _ EC2 Management Console - Google C プレイスメントグループの設定を確認 spredのプレイスメントグループが作成されています。 3プレイスメントグループ _ EC2 Management Console - Google Chro 疎通確認 [root@ip-XXX.XXX.XXX.XXX ~]# ping XXX.XXX.XXX.XXX PING XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 56(84) bytes of data. 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=1 ttl=255 time=0.018 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=2 ttl=255 time=0.028 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=3 ttl=255 time=0.029 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=4 ttl=255 time=0.029 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=5 ttl=255 time=0.027 ms ちなみにプレイスメントグループをしていない普通のインスタンスの場合 確かにプレイスメントグループ化してるインスタンスのほうがはやいです [root@ip-XXX.XXX.XXX.XXX ~]# ping XXX.XXX.XXX.XXX PING XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 56(84) bytes of data. 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=1 ttl=255 time=0.192 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=2 ttl=255 time=0.196 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=3 ttl=255 time=0.185 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=4 ttl=255 time=0.183 ms 64 bytes from XXX.XXX.XXX.XXX: icmp_seq=5 ttl=255 time=0.187 ms

皆さん 5G MEC を起こしてみましょう 私は 5G MEC に興味（期待）があり、先日から KDDI の MEC サービスを試し始めています。まずは MEC を構成して、インターネットからアクセスするところまで試せたので、その構成や手順などを共有します。 KDDI MEC を試すのは以下のように超簡単でした！ MEC を用意する作業については、KDDI の窓口を通すことが一切ない つまり AWS コンソールをポチポチするだけで実験環境の構築が完了する あとは 5G 端末があればすぐ試すことができる（see; 実験編 (coming soon!)） 5G 端末は単に KDDI の 5G 契約つきスマートフォンで良い（機器の限定やユーザの限定などは必要ない） 5G MEC に興味がある人は 全員一度試すべき！ と思います。 この文書の目的と構成 先行事例である @mksamba さんの記事「 【初心者】AWS Wavelengthを使ってみる」に大いに助けられました。ありがとうございます。基本的にはこちらを皆さん追いかけて頂ければ何とかなるかと思います。 そこで基本的な手順は上の先行記事で見て貰うとして、この文書では KDDI に関連する事項と、概念的な整理に集中しようと思います。私同様 AWS あるいは Wavelength 初心者の人たちで、私と同じようにハマる傾向のある人たちの助けになれば、と思ってまとめてみます。 全体構成 先に今回構築しようとする KDDI MEC 実験システムの全体構成を示します。（この図も先行記事の冒頭図とほぼ同じものです。） パープルの点線は、システム管理者であるあなたや、MEC 上のアプリケーションにアクセスしようとする 5G 端末のユーザのアクセス経路を示しています。 以下に、今回の構成について注目すべき箇所について列挙します。私は作業を始める前にこのあたりのことが頭に入っておらず迷うことが度々ありました。 Wavelength のアクセス制限 外部から MEC (Wavelength instance) への直接のアクセスは 5G 端末から行うものと考える インターネットから MEC に対する直接アクセスは ICMP 以外は遮断されている そのため MEC のセットアップなどを Internet から行うためには、隣接Subnetの踏み台 (bastion server) から行うことにする Wavelength のこのアクセス制約のため、最低でも上図のように踏み台用とMEC用の 2 つの instance を、Zone 2 つに分けて起こす構成になると思います。 対称性 ところで全体構成を見ると、左右二つの Zone, Gateway, instance の構成がかなり対称的に見えると思います。それぞれの呼び方について表にまとめておきます。AWSの操作経験のある人はこれでコンソールでの表現が読みやすくなるかと。 呼称 Internet(踏み台)側 Wavelength側 Zone Availability Zone Wavelength Zone Gateway Internet Gateway Carrier Gateway Global IP Elastic IP (Public IP) Carrier IP Global Address 驚いたことに MEC のグローバルアドレスが（一つまでなら無料で！）超簡単に割り当てられます。 Wavelength user にはキャリア(KDDI)の保有する global IP address がアサインされる（一つまでは無料） これを Carrier IP Address と呼ぶ Carrier IP は Carrier Gateway にセットされ、Wavelength instance のある Subnet 内アドレスに変換して届けられる Elastic IP Address も一つまでは無料で割り当てられますが、いやあ、簡単でいいですね。 実験環境の構築 この実験環境を構築するための操作について、以下の順で示します。（AWS のアカウント登録は既に行っているものとします） Wavelength Zone のアクセス・リクエストを出す VPCを作成する 踏み台用の（つまり普通の）EC2 インスタンスを作成する Internet Gateway を設定して外部からの到達性を確認する MEC用の（つまりWavelengthの）EC2 インスタンスを作成する Carrier Gateway を設定して外部からの到達性を確認する それぞれの細かな作業については、先行記事 をご覧下さい。以下では私が引っ掛かったところ、悩んだところなどに絞って書いておきます。 1. Wavelength Zone のアクセス・リクエストを出す まずKDDIの5G関連ページなどを見ていると、以下のようなリンクにたどりつくと思います。 このリンク先、https://aws.amazon.com/jp/wavelength/getting-started/ つまり AWS Wavelength 一般の開始方法のページになっています。つまりこの段階では、というか全体を通して KDDI 特有の手続きなどは何もありません。 このページの「(1) Wavelength Zone にオプトインする」からの手順を追いかければおおよそうまくできるようになっています。まず、Wavelength Zone へのアクセスをリクエスト リンクをたどって、申請を行ってください。オプトインする、と書かれているのでちょっとピンと来ないかもしれませんが、単にリクエストを送る、という意味です。 このリクエストを送ると、何日かで承認された、というメイルが届きます。私の場合（2021/4）は二日で承認確認のメイルが届きました。（承認されるまでは、Wavelength 関連のメニューや選択肢が AWS コンソールに現れてきません。） 2. VPCを作成する 手順については先行記事に詳しい説明があります。 ただ一点、注意があります。大阪に MEC を作りたい人も、VPC 作成の際には 東京 Region を指定する必要があります。以下詳細。 ここでいきなりつまづきました。私は関西在住なので大阪の Wavelength instance を作ろうとして、まず大阪 (ap-northeast-3) Region を選択しました。しかし大阪 Region には Wavelength Zone が無いのです。（2021/4 現在の状況です） AWS は2021/2/4に「本日、大阪の KDDI の 5G ネットワークにおける新しい AWS Wavelength Zone の提供を開始します」と発表しているのに。。 右上矢印のところで大阪 Region が指定されていることが確認できます。しかし大阪の全 Availability Zone の表示に、Wavelength Zone がありません。しばらく探し回って、東京 Region に含まれていることを発見しました。 以下に 東京 Region (ap-northeast-1) に含まれる Zone の一覧表示を出しておきます。 右上矢印のところで東京 Region (ap-northeast-1) を指定すると、東京の全 Zone に、Wavelength Zone が存在するのが分かります。また、その Wavelength Zone には、二つの Zone が含まれている事が分かります。特に図で赤丸をつけたところに注目してください。（kix-Osaka, nrt-Tokyo） つまり以下のような内部配置になっているような感じですね。 Wavelength Zone は東京と大阪の二つがあるが、 その両方とも 東京 Region にある つまり 東京 Region の中に東京と大阪の二つの Wavelength Zone が含まれており、 大阪 Region は存在するが、そこには Wavelength Zone は無い これ以降、常に東京 Region を選択して作業をしてください。大阪に MEC を作る場合でも、大阪 Region にはせず、東京 Region です。その中にしか大阪 Wavelength Zone はありません。 （これらはすべて 2021/4 現在の状況です。なお、先述の Wavelength のアクセス・リクエストが承認されていないと、東京 Region でも Wavelength Zone の表示がまったく表示されませんので念のため。） できあがった VPC 3. 踏み台用の（つまり普通の）EC2 インスタンスを作成する やはり手順については先行記事に図があります。 ここは余り悩むところは無いかと。私は無料利用枠の対象である t2.micro タイプを選択しました。そうそう一つだけ。セキュリティグループの設定時に、デフォルトでは SSH しか通さないようになっているので、ICMP に返事をさせる設定を追加しました。 できあがった Instance できあがった Subnet （下のスクリーンショット時点ではもうルートテーブルにデフォルトルート(0.0.0.0/0)が追加されており、そこに Internet Gateway が関連づけられています。） 4. Internet Gateway を設定して外部からの到達性を確認する 余りハマりどころはありません。せいぜい Internet Gateway は VPC に関係づける（アタッチする）ことに注意することくらいでしょうか。後に出てくる Carrier Gateway は VPC 内の Subnet に関係づけられていますからね。 Wavelength Zone は AWS 網の中で無く、キャリアの閉域網の中に設置される Zone ですから、内部構造が幾らか異なることが想像されます。 できあがった Internet Gateway 状態が Attached になっていることが重要です。 ping テスト Internet 上のサイトから、この踏み台となる Instance にめがけて ping を掛けて疎通確認をします。 $ ping 13.231.xxx.xxx PING 13.231.xxx.xxx (13.231.xxx.xxx): 56 data bytes 64 bytes from 13.231.xxx.xxx: icmp_seq=0 ttl=229 time=15.804 ms 64 bytes from 13.231.xxx.xxx: icmp_seq=1 ttl=229 time=12.534 ms 64 bytes from 13.231.xxx.xxx: icmp_seq=2 ttl=229 time=13.521 ms ^C --- 13.231.xxx.xxx ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 12.534/13.953/15.804/1.369 ms $ このとき、作成した踏み台のインスタンスが本当に返答している事を tcpdump で確かめておきます。 $ ssh -i /usr/home/.../secret_rsa.pem -l ec2-user 13.231.xxx.xxx ....(snip).... [ec2-user@ip-10-0-1-41 ~]$ sudo su [root@ip-10-0-1-41 ec2-user]# tcpdump icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 02:26:51.131164 IP host123.example.com > ip-10-0-1-41.ap-northeast-1.compute.internal: ICMP echo request, id 6676, seq 0, length 64 02:26:51.131189 IP ip-10-0-1-41.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 6676, seq 0, length 64 02:26:52.132112 IP host123.example.com > ip-10-0-1-41.ap-northeast-1.compute.internal: ICMP echo request, id 6676, seq 1, length 64 02:26:52.132145 IP ip-10-0-1-41.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 6676, seq 1, length 64 02:26:53.137131 IP host123.example.com > ip-10-0-1-41.ap-northeast-1.compute.internal: ICMP echo request, id 6676, seq 2, length 64 02:26:53.137155 IP ip-10-0-1-41.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 6676, seq 2, length 64 ^C 6 packets captured 6 packets received by filter 0 packets dropped by kernel [root@ip-10-0-1-41 ec2-user]# 正しく到達できていることが確認できました。次に進みましょう。 5. MEC用の（つまりWavelengthの）EC2 インスタンスを作成する 手順については先行記事に詳しい説明があります。先行記事では米国の Zone の中に作っていますが、これが KDDI になります。それによって Subnet を作成する Zone の候補は以下のようになります。  私は以下のように、大阪（つまり kix ）の Wavelength Zone を指定しました。  インスタンス作成では インスタンスのタイプ に注意が必要です。 以下にインスタンス作成直前の確認画面を出しておきます。 ここで、サブネットを Wavelength 向けのもの、自動割り当てパブリックIPは不要、 キャリア IP の自動割り当て を有効、としておきます。（ただ、ここ、ちょっと分かっていません。先行記事 の図では、この「キャリアIPの自動割り当て」の項目がありません。また、自動割り当てにセットしないとインスタンス作成時にエラーが出るようなのですが（後述）、だからといってCarrier IP が自動的に付与されるわけでもありません。はて何か間違えたか。。） できあがった Wavelength Instance インスタンス作成時に出たエラー 私が遭遇したエラーについて出しておきます。 "The requested configuration is currently not supported" このとき私は Wavelength が対応していないインスタンス・タイプを選んでいました。資料 によると、選べるのは t3.medium, t3.xlarge, r5.2xlarge, g4dn.2xlarge だけとなっています（2021/4現在）。t3.medium を選択しなおしたところ、作成に成功しました。 "The Availability Zone does not support associating a public IP address"" 自動割り当てパブリックIPは「なし」、キャリア IP の自動割り当てを「有効」にしていなかった場合、このエラーが出ました。少し上に図示したように合わせてやると、作成に成功しました。 できあがった Subnet （下のスクリーンショット時点ではもうルートテーブルにデフォルトルート(0.0.0.0/0)が追加されており、そこに Carrier Gateway が関連づけられています。） 6. Carrier Gateway を設定して外部からの到達性を確認する 手順については先行記事に詳しい説明があります。 キャリア IP の取得 先行記事 に手順があるのですが、ここ、少しワナ？があります。取得操作では以下のような画面になります。  しかしこの「ネットワークボーダーグループ」は Wavelength Zone のものではありません。この ap-northeast-1 の後ろに「 - （ハイフン）」を書き足す（タイプする）と、Wavelength Zone の候補（先述の kix, nrt）がリストアップされて選択できるようになります。（気がつきにくく、不親切）  ここを指定して割り当てを行うと、今度はこの Carrier Gateway とインスタンスの関連付けを行うよう促されます。以下のようにインスタンスを指定します。 できあがった Carrier Gateway 状態が Available になっていることが重要です。 ping テスト Internet 上のサイトから、この Wavelength Instance にめがけて ping を掛けて疎通確認をします。（繰り返しますが、Internet から MEC に直接アクセスできるのは ICMP だけです。MEC へのアクセスは 5G 閉域網から行うものだ、と思って下さい。） $ ping 106.161.xxx.xxx PING 106.161.xxx.xxx (106.161.xxx.xxx): 56 data bytes 64 bytes from 106.161.xxx.xxx: icmp_seq=0 ttl=239 time=19.278 ms 64 bytes from 106.161.xxx.xxx: icmp_seq=1 ttl=239 time=7.426 ms 64 bytes from 106.161.xxx.xxx: icmp_seq=2 ttl=239 time=30.325 ms ^C --- 106.161.xxx.xxx ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 7.426/19.010/30.325/9.350 ms $ このとき、作成した Wavelength Instance が本当に返答している事を tcpdump で確かめておきます。 （踏み台サーバから Wavelength Instance に ssh login） [ec2-user@ip-10-0-1-41 ~]$ ssh 10.0.2.244 Last login: Fri Apr 16 15:18:07 2021 from 10.0.1.41 ....(snip).... [ec2-user@ip-10-0-2-244 ~]$ sudo su [root@ip-10-0-2-244 ec2-user]# tcpdump icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 03:18:17.884429 IP host123.example.com > ip-10-0-2-244.ap-northeast-1.compute.internal: ICMP echo request, id 12038, seq 0, length 64 03:18:17.884461 IP ip-10-0-2-244.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 12038, seq 0, length 64 03:18:18.887099 IP host123.example.com > ip-10-0-2-244.ap-northeast-1.compute.internal: ICMP echo request, id 12038, seq 1, length 64 03:18:18.887135 IP ip-10-0-2-244.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 12038, seq 1, length 64 03:18:19.890770 IP host123.example.com > ip-10-0-2-244.ap-northeast-1.compute.internal: ICMP echo request, id 12038, seq 2, length 64 03:18:19.890799 IP ip-10-0-2-244.ap-northeast-1.compute.internal > host123.example.com: ICMP echo reply, id 12038, seq 2, length 64 ^C 6 packets captured 6 packets received by filter 0 packets dropped by kernel [root@ip-10-0-2-244 ec2-user]# おわりに 5G MEC は既に docomo も KDDI もサービスインしているのですが、何しろ情報が少ないです。そこで「こんなに簡単に試せるよ」ということを示して、事例が増えることを期待しています。 今回はまず、AWS 側のセットアップまででした。次は 5G 端末からのアクセス実験に進みます。(coming soon!)

初めまして、AWSクラウドエンジニアのルビコンと申します。 突然ですが、CloudFormationを使われているでしょうか？ リソースをコードで作れるのでインフラ構築・管理で毎日使っているサービスです。 初めて学習される際につまずかないよう、Tipsを提供させて頂きます。 Typeとは？ TypeにはAWSリソースの種類を書きます。公式ドキュメント (AWS resource and property types reference - AWS CloudFormation) には service-provider::service-name::data-type-name を書くと定義されています。 例えば下記YAMLではRubiconLinkという名前のユーザーを作成できます。 Resources: UserRubiconLink: Type: AWS::IAM::User Properties: UserName: RubiconLink LoginProfile: Password: ILoveQiita! PasswordResetRequired: true Groups: - !Ref GroupAdministrators Type: AWS::IAM::User や AWS::IAM::Group は抵抗ないでしょう。IAMでUserやGroupを作るということですね。確かにIAMの管理画面でもUserやGroupのメニューがあります。 AWS::EC2::VPC や AWS::EC2::Subnet に違和感 下記YAMLではVPCを作成できます。 Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/19 EnableDnsHostnames: true EnableDnsSupport: true InstanceTenancy: default Tags: - Key: Name Value: awsmaster-prod-vpc AWSを少しでもかじったことがあると、Type: AWS::EC2::VPC や AWS::EC2::Subnet は抵抗ありますね。というのもAWSの管理画面からすると、VPCというサービスの中にVPCやSubnetのメニューがあるので AWS::VPC::VPC や AWS::VPC::Subnet の方が自然に思えるからです。 実はAWSの裏側としてはCFnの方が正解で、VPCやSubnetなど「VPC」の画面にまとめられているリソースは全て「EC2」のリソースなのです。なので Type: AWS::EC2::VPC や AWS::EC2::Subnet となります。 歴史的経緯 AWSでEC2がリリースされた2006年当初、VPCは存在しませんでした。その後、EC2をネットワーキングするための機能として2009年にVPCがリリースされた経緯があるのでしょう。 実はその名残がAWSの画面でも残っており、Security Groupというリソースは全く同じものを「EC2」の画面でも「VPC」の画面でも見ることができます。さらにRDSでは「VPC Security Group」という表記があります。普段「EC2」の画面でSecurity Groupを触っていると違和感がありますが、EC2とVPCの関係を知っていると謎が解けます。 EC2-Classic 蛇足ですが、VPCが存在しない時代のEC2は「EC2-Classic」と呼ばれていました。下記のサイトも参考まで。 EC2-Classic - Amazon Elastic Compute Cloud EC2-Classic からの脱却！ VPC 完全移行 ~ Backlog 編 | 株式会社ヌーラボ(Nulab inc.) おまけ 週4稼働の現役クラウドエンジニアと並行して、毎日AWSの個別相談やグループ指導もお受けしています。もしご興味あればTwitter @RubiconLink のDMまでお問い合わせください。フォローも大歓迎です。

概要 AWS、クラウドシステムを学び、運用する上で重要な概念であるAWS Well-Architectedフレームワークについて簡単にまとめました。本フレームワークは原則であって、厳守するものではないことが注意点です。 AWS CloudTechで学んだことのまとめです。 AWS Well-Architected フレームワークとは AWSの長年の知見が詰まったペストプラクティス集。5つのカテゴリーに分かれる。 1. 運用上の優位 1. セキュリティ 1. 信頼性 1. パフォーマンス効率 1. コスト最適化 運用上の注意 開発をサポートし、ワークロードを効率的に実行し、運用に関する洞察を高め、ビジネス価値をもたらすためのサポートプロセスと手順を継続的に改善する能力 - ログを監視し、モニタリングする - インフラをコード化し、安全に、頻繁にアップデートする セキュリティ セキュリティの柱では、データ、システム、資産を保護し、クラウドテクノロジーを活用し、セキュリティを向上させる機能 - 権限管理、追跡調査ができる仕組み - 全てのレイヤーへのセキュリティを適用 - 継続改善する仕組み - リハーサルや自動復旧の仕組み作り 信頼性 期待されるタイミングで、意図した機能を正確にかつ一貫して実行するワークロードの能力。ライフサイクル全体jを通じてワークロードを運用及びテストする機能を含む - 単一障害点（一箇所の障害で全てがストップする箇所）がないか - 自動的にリソース拡張する仕組み - 障害の影響を軽減する仕組み - 事前テストの実施 パフォーマンス効率 システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力 - 最新テクノロジーのメリットを理解し、選定する - 価値の高い仕事に集中する - 最新テクノロジーの比較、実験を頻繁に行う コスト最適化 最も低い価格でシステムを運用してビジネス価値を実現する能力 - コストを計測し、削減できる取り組みの実施 - 差別化に繋がらない高負荷の作業に費用をかけない - 費用を分析・属性化（タグ付け）を行う 用語 用語 説明 リフト＆シフト オンプレミスからクラウド環境への移管作業 参考 AWS Well-Achitectedフレームワーク AWS CloudTech

最近、仕事でRoute 53に対して数十件のレコードをAWSマネジメントコンソールの画面から手動で登録したんですが、登録したレコードの中にはMXレコードやSPFレコードが含まれていたため、ミスってたら怖いなぁと思い、以前から気になっていたawspecを触ってみるよい機会だと思い使ってみました。 ということで、ここではawspecを使ってRoute 53のレコードが正しく設定されているかを確認する手順を示します。 awspecとは？ awspecのGitHubのページを見ると「RSpec tests for your AWS resources.」とのこと。 RSpecの記法で書けるServerspecのAWS版といったところでしょうか。 今回の実行環境 macOS Catalina バージョン 10.15.5 必要なパッケージ Ruby Bundler RubyとBundlerを利用するため、実行環境にインストール済みか確認します。 $ ruby -v ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-darwin19] $ bundler -v Bundler version 2.2.16 事前準備 awspecではAWSの各リソースの読み取り権限のポリシーが付与されたIAMユーザーが必要です。 別の記事で紹介した「SecurityAudit」というIAMポリシーを利用することでAWSの多くのリソースにアクセスすることが可能ですが、今回はRoute 53に対してのみ読み取り権限があれば十分なので、「AmazonRoute53ReadOnlyAccess」のポリシーを付与してIAMユーザーを作成しました。 ユーザー名は「Route53ReadOnly」としました。マネジメントコンソールでは利用しないため、「プログラムによるアクセス」にのみチェックしておきます。 「既存のポリシーを直接アタッチ」を選択して、「AmazonRoute53ReadOnlyAccess」にチェックします。 「Name」というキー名に「Route53ReadOnly」を設定します。（このステップはスキップしてもOKです） 確認画面で内容がOKだったら作成します。 上記手順で作成したIAMユーザーの認証情報はあとの手順で利用するので控えておきます。 $ cat ~/Downloads/new_user_credentials.csv User name,Password,Access key ID,Secret access key,Console login link Route53ReadOnly,,XXXXXXXXXXXXXXXXXXXX,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,https://XXXXXXXXXXXX.signin.aws.amazon.com/console awspecのインストール インストール作業用のディレクトリを作成し、そのディレクトリ配下にGemfileを作成します。 $ mkdir awspec_r53 $ cd awspec_r53 $ bundle init Writing new Gemfile to /PATH_TO/awspec_r53/Gemfile $ cat <<EOF >> Gemfile gem "awspec" gem "rake" EOF カレントディレクトリ配下にインストールするために「bundle config set --local path」を実行した後に「 bundle install」を行います。 $ bundle config set --local path 'vendor/bundle' $ cat .bundle/config --- BUNDLE_PATH: "vendor/bundle" $ bundle install Fetching rake 13.0.3 Installing rake 13.0.3 ・ ・ ・ Bundle complete! 2 Gemfile dependencies, 290 gems now installed. Bundled gems are installed into `./vendor/bundle` 以前は「bundle install --path」のように実行していたと思いますが、この手順は非推奨になっているようです。 $ bundle install --path vendor/bundle [DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set --local path 'vendor/bundle'`, and stop using this flag awspecの初期設定 awspecの初期設定を行うために、「bundle exec awspec init」でawspecのファイル群を生成します。 今回はawspecをローカル環境にインストールしたので、「bundle exec awspec init」を実行します。グローバルにインストールした場合は「awspec init」でよいはずです。 $ bundle exec awspec init + spec/ + spec/spec_helper.rb + Rakefile + spec/.gitignore + .rspec 事前に控えておいたIAMユーザーの認証情報を以下のように入力し、「spec/secrets.yml」ファイルを作成します。 $ cat <<EOF > spec/secrets.yml region: ap-northeast-1 aws_access_key_id: XXXXXXXXXXXXXXXXXXXX aws_secret_access_key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX EOF これで準備が整いました。 specファイルの書き方について Route 53のホストゾーンに対応するspecファイルの書き方については、ドキュメントがありますので事前に目を通しておきましょう。 Route 53で登録可能なレコードタイプには以下のようなものがあります。 「awspec/lib/awspec/matcher/have_record_set.rb」の以下のコードを見ると、対応しているレコードタイプを確認できます。 %w(soa a txt ns cname mx ptr srv spf aaaa caa).each do |type| chain type do |value| @type = type @value = value @options = {} if @options.nil? end end ホストゾーンの作成 本番環境で実際に登録したレコード群をここで例示することはできないので、今回は個人で管理しているドメインを元に一時的にRoute 53のホストゾーンとして登録し、テストを書いてみようと思います。 Route 53の画面で「fifty-four.rocks」をホストゾーンとして登録します。 初期状態ではNSレコードとSOAレコードが作成されています。 specファイルの作成と実行 上記の初期状態のレコードに対してテストを作成します。 まず、「fifty-four.rocks」のホストゾーンが存在しているかを確認します。 次に初期状態のレコード数は2レコードなので、カウントが合致しているかを確認します。 NSレコードはデフォルトで4行登録されているので、ここでは配列の形式で定義し、引数に渡す際に改行を区切り文字として指定しています。 SOAレコードは文字列なので、そのまま引数に渡します。 $ cat spec/route53_spec.rb require 'spec_helper' describe route53_hosted_zone('fifty-four.rocks.') do it { should exist } its(:resource_record_set_count) { should eq 2 } ns = [ 'ns-1931.awsdns-49.co.uk.', 'ns-296.awsdns-37.com.', 'ns-902.awsdns-48.net.', 'ns-1286.awsdns-32.org.', ] it { should have_record_set('fifty-four.rocks.').ns(ns.join("\n")).ttl(172800) } soa = 'ns-1931.awsdns-49.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400' it { should have_record_set('fifty-four.rocks.').soa(soa).ttl(900) } end それではテストを実行してみます。 今回はrakeをローカル環境にインストールしたので、「bundle exec rake spec」を実行します。グローバルにインストールした場合は「rake spec」でよいはずです。 $ bundle exec rake spec route53_hosted_zone 'fifty-four.rocks.' is expected to exist is expected to have record set "fifty-four.rocks." is expected to have record set "fifty-four.rocks." resource_record_set_count is expected to eq 2 Finished in 1.8 seconds (files took 2.95 seconds to load) 4 examples, 0 failures 4件のテストがすべて成功しました。 次にfifty-four.rocksのAレコードをRoute 53に登録します。 その前に、現状のAレコードをdigコマンドで確認してみましょう。 $ dig fifty-four.rocks a +short 3.0.239.142 104.248.158.121 上記の2レコードが返ってきましたので、このテストをspecファイルに追加します。変更箇所は以下の通りです。 cat spec/route53_spec.rb require 'spec_helper' describe route53_hosted_zone('fifty-four.rocks.') do ・ ・ ・ its(:resource_record_set_count) { should eq 3 } ・ ・ ・ a = [ '3.0.239.142', '104.248.158.121', ] it { should have_record_set('fifty-four.rocks.').a(a.join("\n")).ttl(300) } end テストを実行して、失敗することを確認します。 $ bundle exec rake spec route53_hosted_zone 'fifty-four.rocks.' is expected to exist is expected to have record set "fifty-four.rocks." is expected to have record set "fifty-four.rocks." is expected to have record set "fifty-four.rocks." resource_record_set_count is expected to eq 3 (FAILED - 1) Failures: 1) route53_hosted_zone 'fifty-four.rocks.' resource_record_set_count is expected to eq 3 Failure/Error: its(:resource_record_set_count) { should eq 3 } expected: 3 got: 2 (compared using ==) # ./spec/route53_spec.rb:6:in `block (2 levels) in <top (required)>' Finished in 1.76 seconds (files took 4.06 seconds to load) 5 examples, 1 failure Failed examples: rspec ./spec/route53_spec.rb:6 # route53_hosted_zone 'fifty-four.rocks.' resource_record_set_count is expected to eq 3 Route 53にAレコードを登録します。 テストを再度実行します。 $ bundle exec rake spec route53_hosted_zone 'fifty-four.rocks.' is expected to exist is expected to have record set "fifty-four.rocks." is expected to have record set "fifty-four.rocks." is expected to have record set "fifty-four.rocks." resource_record_set_count is expected to eq 3 Finished in 1.56 seconds (files took 4.11 seconds to load) 5 examples, 0 failures ５件のテストがすべて成功しました。 こういった感じで、後は「テストを作成 → レコードを登録 → テストを実行」を繰り返すことで安心してDNSの設定変更作業を行うことができるのではないでしょうか。 参考URL awspec awspecを活用して、AWS Route53でのサブドメイン追加業務を堅実に実施する awspecでAWSリソースをテストする bundler(1.17.2)で--path=vendor/bundleつけたら警告出た話

Lambda編の記事ではPythonのコードをLambdaに登録してCloudWatchEventsから呼び出してEC2起動/停止のスケジューリングを実現しました。一昔前まではこの手法が王道だったようですが、現在はコードを書かずともCloudWatchEvents + SystemsManager(SSM)の組み合わせでできちゃいます。こちらの方法も試してみました。 IAMロールの作成 あらかじめIAMのメニューからロール、ポリシーを作成します。以下の権限が必要となります。 CloudWatchからSSMのオートメーションを実行するための権限 CloudWatchからEC2を停止/起動するための権限 ロール作成時、信頼されたエンティティはCloudWatch Eventsを選択し、以下のポリシーで作成します。 まず、ssm:StartAutomationExecutionでSSMAutomationの実行権限を与えていて、対象のドキュメントをEC2停止/起動に限定しています。<account_id>の箇所は適宜読み替えてください。$DEFAULTはバージョン指定です。 次に、EC2停止/起動の権限を付与しています。ec2:DescribeInstanceStatusは起動/停止後のステータスチェックに使われているようです。この権限がなくともEC2の起動/停止はされますが、SSMAutomationの実行結果は「失敗」となるので付与しておきます。 ※ポリシーの定義が面倒な場合はAmazonSSMAutomationRoleの管理ポリシーを利用しても良いかと思います。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:StartAutomationExecution" ], "Resource": [ "arn:aws:ssm:ap-northeast-1:<account_id>:automation-definition/AWS-StartEC2Instance:$DEFAULT", "arn:aws:ssm:ap-northeast-1:<account_id>:automation-definition/AWS-StopEC2Instance:$DEFAULT" ] }, { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances", "ec2:DescribeInstanceStatus" ], "Resource": "*" } ] } CloudWatch Eventsにスケジュールを登録 Lambda編と違うのはターゲットの選択です。種類は「SSMAutomation」を選択して、AWS-StartEC2InstanceまたはAWS-StopEC2Instanceのドキュメントを選択します。あとは、対象のEC2のインスタンスID、あらかじめ作成したIAMロールを選択すればOKです。（cronのスケジュールは適当です） ちなみに、ドキュメントのパラメータ指定にあるAutomationAssumeRoleは、SSMがドキュメントを実行する場合の権限を個別に割り当てたい場合に利用するようです。 実行結果を確認 Systems Manger → 自動化の画面から履歴を確認することができます。 エラーになった場合は、実行IDをクリックして中身を確認してみましょう。 CloudWatch Eventsにスケジュールしたのにそもそも履歴が出ない場合は、おそらくSSMAutomationの実行権限が不足していますので、IAM設定を見直しましょう。 まとめ 今回はCloudWatchEvents + SystemsManagerでEC2自動起動・自動停止を試してみました。コードを書く必要がなく、簡単に設定できるのでとても便利ですね。個人的には、IAMの理解が深まった検証になりました。 簡単に設定できてコスト削減に直結しますので、積極的に使っていきたいですね。前回のLambda編と合わせて参考になれば幸いです。 参考リンク CloudWatch Events と Systems Manager で EC2の起動/停止をスケジュール化する

IAMの認証方式 大きく分けて4つに分類される。 アクセスキーID/シークレットアクセスキー EC2インスタンス接続などのREST/Query形式でのアクセスやAWS CLI、API利用時の認証に用いる。 X.509 Certificate(公開鍵証明) SOAP形式(リクエスト及びレスポンスをXMLで行う)でのAPIリクエストで用いる。 AWSマネジメントコンソールへのログインパスワード AWSアカウントごとに設定されるパスワード、デフォルトでは未設定 MFA(多要素認証) Google Authenticatorなどを使った認証。 ルートアカウントなどセキュリティリスクが高い場合に用いてセキュリティを強化する。 ユーザーのアクティビティの記録 AWSにおけるユーザーのアクティビティの記録はIAMが担う。 ツールは以下のように様々ある。 IAMAccessAnalyzer 外部エンティティと共有されているS3バケットやIAMロールなどを分析し、セキュリティ上のリスクであるリソースとデータへの意図しないアクセスを特定する。 Access AdvisorのService Last Accessed Data IAMエンティティ(エンティティは実体の意。例えばこの場合はIAMユーザー、グループ、ロールを指す)が、最後にAWSサービスにアクセスした日付と時刻を表示する機能。 Credential Report 利用日時などが記録されたIAM認証情報のレポートファイル AWS Config IAMのユーザー、グループ、ロール、ポリシーの変更履歴、構成変更を管理・確認することができる機能 AWS CloudTrail AWSインフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持することができる機能。 APIに関するログはこちらから。 IAM権限におけるベストプラクティス IAMは権限に関わる機能になるので原則ベストプラクティスに沿った運用をするのが望ましい。 ルートアカウントは必要な場合を除いて通常は使用しない 運用時には個々のIAMユーザーを作成し、管理する IAMユーザーへのポリシーの付与はIAMグループを通して行うようにする IAMユーザーやグループへのポリシーの付与は最小権限に収まるようにする(必要以上に権限を与えない) 新しくポリシーを作るのではなく、まずはAWS管理ポリシーを使用するようにする インラインポリシーではなく、カスタマー管理ポリシーを使用する アクセスレベルを使用して、IAMアクセス許可を確認する ユーザーのために強度の高いパスワードポリシーを設定する MFAの有効化 EC2インスタンスで実行するアプリケーションにはIAMロールを使用する 第三者に一時的に認証を付与する場合はIAMロールを使用してアクセス許可を移譲する アクセスキーの共有はしない 認証情報を定期的にローテーションする 不要な認証情報は削除する AWSアカウントのアクティビティを監視する IAMポリシーについて { "Effect": "Allow", "Action: [ "s3:ListBuckets", "s3:Get *" ], "Resource":[ "arn:aws:s3:::mybucket" ], "Condition":{ "IpAddress":{"aws:SourceIP":["176.32.92.49/32"]} } } 基本的には上記のように表記される。 下から順に読んでいくとわかりやすい。 Conditionが条件。この場合は176.32.92.49/32のIPアドレスのアクセスについてと意訳できる。 ResourceはAWSリソースを指定する。この場合はS3のマイバケット。 ActionはAWSのサービス。この場合はS3のListBucketsとGetアクション全般。 最後にEffectが認可方式(ホワイトリストorブラックリスト)。この場合はホワイトリスト方式(以下のアクションやリソースを許可する)。 つまり 176.32.92.49/32のIPアドレスからのアクセスはS3のMyBucket及びS3のListBuckets、Getアクション全般について認可をする。 という意味になる。 こういうことをユーザーやその集団であるグループに都度付与したり、あるいはどのユーザーやグループにどんなポリシーが付与されているのかという関係性を表したのがIAMになる。 IAMユーザー IAMにおけるユーザーは権限(ポリシー)の強度によって管理される。 例えば ルートユーザー 管理者権限(Administer Accessポリシー持ち) パワーユーザー という例を見てみる。 ルートユーザーはその名の通りすべてのサービスとリソースへの権限を持っているユーザーになる。 当然、普段遣いはその特性上推奨されないので以下のように管理者権限を持つユーザーを作り役割の大半を代行させるようにする。 管理者権限はAdminister Accessというポリシーを付与されたユーザーであり、IAMの操作権限等(新規ユーザーの作成など)ルートユーザーの権限の多くを代行できる権限を持つユーザー。 ただし、ルートユーザーのみ持つ権限に関しては代行できない。 パワーユーザーはIAM以外のすべてのAWSサービスにフルアクセス権限を有するユーザー。 管理者権限との違いはIAMの操作権限を持たないこと。 このように同じユーザーでも持つ権限を変えることができる。 当然、ある特定のサービス及びリソースのみアクセスできるようなユーザーを作ることもできる。 ちなみにIAMユーザーはデフォルトでは全ての権限を持っていない状態で作成される。 IAMグループ 先程の例はユーザー単位で権限を付与していたが、ユーザーをグループにしてそのグループに属する人たちに一括でポリシーを付与することもできる。 その集団をIAMグループという。 利点としてはグループに権限を付与するので、あとから人員(ユーザー)の追加があっても都度ポリシーを付与する必要がないということ。 IAM設計 実際に設計してみる。 設計において大切なことはAWSを利用するユーザーの役割及びそのアクセス権限を自社の組織構造と合わせて設計すること。 以下その観点の例。 IAMユーザーかIAMグループか AWS利用者が誰なのか 利用者の役割とその利用範囲はどこまでなのか 例えばこの3点ならまずポリシーの付与をユーザー単位かグループ単位かにするのをその規模感で決定し、その後利用者は何人いてそれらがどの役割(管理者、PG、運用……etc)を持ち、それ故にどこまでアクセス権限を与えるか……というフローで考える。 結局、権限は必要以上に与えないずに例えばグループであるならば同じ役割や利用範囲でグループ別にし、それぞれに権限を与えることでそれを実現するといったことが肝要になってくるということになる。 アクセス管理 マネジメントコンソールからIAMへ飛び、ダッシュボードへ行く。 アクセス管理の欄から各IAMの設定ができる。 グループ～ポリシーまではいいとして、IDプロパイダは何に使うかというと、IAMユーザーを作成する代わりに、既存の外部IDに対してAWSリソースへのアクセス認可を与えるというものである。 SSO(Single-SignOn)を使うときに用いられる。 要はソーシャルログインを使ってAWSアカウントのリソースに対してアクセスしたい……なんて時に設定するところ。 アカウント設定からはAWSアカウントに設定されているパスワードポリシーの確認、及び変更と一時的な認証に用いるSTS(Security Tokens Service)のエンドポイントの設定を確認できる。 アクセスレポート アクセスに対するモニタリング。 組織アクティビティとSCPはAWS Organizationの部分で触れる Access Analyzers リソースに対して不正なアクセスがないかモニタリングをしている。 認証情報レポート アカウントのすべてのユーザーと、ユーザーのさまざまな認証情報のステータスをリストしてくれている。 ポリシーの作成 実際にポリシーを作ってみる。 ポリシーには3つ種類があり ユーザー管理ポリシー(ユーザーが作ったポリシー) AWS管理ポリシー(プリセット) インラインポリシー(IAMアイデンティティ自体に紐ついて定義されているポリシー) の3つがある。 IAMアイデンティティはIAMユーザー、グループ、ロールを指す。 参考: 管理ポリシーとインラインポリシー なるべくAWS管理ポリシーを使うというのがベストプラクティスであった。 そして権限は最小限に留めるべきというのもベストプラクティスであったので、具体的にポリシーを作成する際には どのサービスに対しての権限を考えるのか → どれくらいの権限を与えるのか というフローが大切になる。 例えばアプリ開発に関わる部分及びログ管理の権限を持ったユーザーを作りたいとする。 このときユーザーありきで考えてしまうと 上記2つの権限を持ったユーザーを作ればいいじゃない → 開発・ログ管理の権限をまとめたポリシーを作成！ という罠にハマってしまう。 繰り返しになるが権限は最小限度でなければいけない。 つまりこの場合開発とログ管理でポリシーを別々に作り、適用時にその2つを権限を持つべきユーザーへ適用するのが正解となる。 さて先程のJsonを見てみる。 { "Effect": "Allow", "Action: [ "s3:ListBuckets", "s3:Get *" ], "Resource":[ "arn:aws:s3:::mybucket" ], "Condition":{ "IpAddress":{"aws:SourceIP":["176.32.92.49/32"]} } } こういったことを定義していこうというのがポリシーの作成だが直接JSONを書かなくてもビジュアルエディタで下記のフローをサービス毎に都度行うことでも設定できる。 サービスの設定 どのサービスに対してのポリシーなのか選択する。 アクション 指定したサービスに対してどのアクションを許可するか選択できる。 例えばEC2インスタンスにおいてタグ付けはできるが、削除はできないといったレベルで細かく設定することもできる。 ただし、上記の通り例えばEC2の場合は約400ものアクションがあるためちゃんと扱えるにはそのサービスのアクションについての理解が問われることとなる。 リソース 指定したサービスに関わるリソースへのアクセス認可を設定できる。 こんな感じでずらっと出てくるが、基本的にはすべてのリソースでということになる。 この部分は例えば複数のグループがある場合などはそれぞれ役割や利用範囲が異なるはずなので、それに対してリソースへのアクセスを適宜制限したほうが良い……というケースもあるが、特に必要がある場合はリソースへのアクセスに制限をかけるという認識で問題はないようだ。 リクエスト条件 ユーザーに対するアクセス認可への条件。 MFA認証なしではそもそもサービスへアクセスできないとかそういうレベルの設定をする。 ポリシーの確認 作ったポリシーを確認してみる。 テキストボックスから検索してもいいし、フィルターにかければユーザー管理かAWS管理かでフィルタリングできる。 こんな感じで表示される。 ポリシー名をクリックすると詳細が見れる。 例えばJsonでみたければ以下のように表示することもできる。 ユーザー作成とグループ追加 あとはユーザー作成をしてそれをグループに入れれば完了となる。 グループ作成は画面の指示に従うだけなので割愛、ポリシーの適用もここでできる。 IAMロール システム設計においてAWSサービス間で連携する必要性があるとする。 その場合連携箇所を割り出して、必要な連携が取れるようにリソースに対して権限設定をしないといけない。 そういうときに用いるのがIAMロールとなる。 おさらいであるがIAMロールは今回のようにリソースに対する権限付与の他に、第三者に一時的に権限を付与する(役割(Roll)を与える)という目的などでも使用される。 ポリシーを作ったあと、ロールの作成からロールを適用するユースケース(サービス)を指定し、ロールに内包するポリシーを選択して作成することができる。 今回はEC2インスタンスがS3に対してバッチ処理ができるようにという想定なので、EC2インスタンスに対してS3への権限を付与するということを下記のように行っている。 あとは以前やったようにSSHでインスタンスにアクセスしてコマンドを打って接続ができているか確認すればOK。 ここまででS3の設定(CloudTrailで証跡を作る等)をしていればaws s3 lsでログの有無を取得できる。 IAMロールでの権限付与 繰り返しになるがIAMロールでは第三者に対して一時的に権限を付与することができる。 ユースケースとしては監査人に対して監査の際にアクセスできるように権限を与えるということが考えられる。 手順例としては下記の通り 実行アカウントで権限移譲用のIAMロールを作成 移譲されるアカウントでIAMポリシーに先程のロールを適用し作成する 作成したIAMポリシー移譲されるアカウントのIAMユーザーに適用する 上記のIAMユーザーで実行アカウントへアクセスする。 ロールの作成へ飛んで、今度は別のAWSアカウントを選択して対象となるアカウントIDを入力してあとは画面の指示に従えば、そのアカウントIDに対して適用できるロールが完成する。 あとはロールの一覧から作ったロールを選択して詳細画面へ行き ロール名 ロールARN(ロールを一意に識別するもの) アカウントID(ロールを作ったアカウントのID) をメモしておく。 あとはロールを適用する側のアカウントでポリシーを作ってもらう。 この時、今回は権限移譲になるのでAWS管理ポリシーからAdministerAccessポリシーをインポートしておく。 あとはビジュアルエディタではなくjsonから直接 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:assumeRole", "Resource": "ロールARN" } ] } としてやれば完成。 sts:assumeRoleは一時的なSTS認証を取得するアクション、つまりSTS認証ができるようにする。 あとは作ったポリシーを該当ユーザーへ付与(既存のポリシーから付与できる)し、作成したユーザーでサインインすればOK。 IAMユーザーは作成した際に、コンソールへのログイン権限を持つならリンクが出るのでそこからできる。 あとはサインイン先のヘッダーにアカウント名があると思うのでそこのプルダウンからロールの切り替えができる。 あとはロールの切り替えから先程メモした 実行アカウントのID(権限を本来持っているアカウントのID) 移譲用ロールのロール名 を入力すると実行アカウントのコンソールへアクセスできるという寸法。 こうすることで監査人に対して監査の時だけ当該アカウントのコンソールへアクセスできるようにすることができた。 Access Analyzerの作成 リソースに対してのユーザーのアクセスに対するアクティビティの分析を行う場所。 要は不正なアクセスがないかどうかをモニタリングしてくれる。 アーカイブルールを作るとそのルールに基づいたアクティビティをアーカイブに保存しておいてくれる。 例えば先程のアカウント移譲の際にアカウントIDを指定することがあったが、そのアカウントID以外のアカウントIDからのアクセスをアーカイブ化しておけばいつどこで不正にコンソールへのアクセスがなされたか証拠が残る……ということもできる。 AWS Organization IAMのアクセス管理を大規模組織で簡素化するためのサービス。 これまではアカウント内のIAMユーザーやグループに対して色々やってきたが、AWS OrganizationはAWSアカウント自体が対象となる。 主にできることとしては AWSアカウントをグループ化してポリシーを一括で適用できる コンソール/SDK/CLIでアカウントの新規作成を行い、作成内容をログ管理できる 複数のAWSアカウントの請求を一括化できる ということが挙げられる。 フローとしては以下の通り マスターアカウントの決定 グループ化するAWSアカウントのうちマスターになるアカウントを決定し、メンバーになるアカウントを招待する 組織単位(OU)に分配 マスターアカウントがルートユーザーアカウントとなり、招待したメンバーアカウントをグループにあたる組織(OU)へ適宜分配する。 機能セットの選択 以下2つから選択 Consolidated Billing Only All Feature 要は支払い一括請求のみ使うか、すべての機能を使うかという選択。 ただし、All Featureにする場合は当然AWSアカウントすべてを統制することになるのでその分人的・運用コストがかかる。 SCP OUにおけるポリシーのようなものがSCP。 つまりOU内メンバーに関する権限境界の設定となる。 ただし、あくまで境界の設定なので別途IAMで権限は付与しないといけない。 例えば SCP側 EC2 RDS ECS IAM EC2 ECS といった場合、権限があるのはEC2とECSのみになる。 SCPはOU内のメンバーに対して権限を与えるならどこまで与えていいかを示しているようなものだろうか ポリシーの設定 AWS Organizationsのポリシー(SCP)には以下の4つがある。 AIサービスのオプトアウトポリシー バックアップポリシー サービスコントロールポリシー タグポリシー うちサービスコントロールポリシーが先程の例における権限領域の設定、タグポリシーがOU内でのタグ付けのルールを統一するためのポリシーとなる。

https://aws.amazon.com/jp/s/dm/landing-page/create-free-account より、AWS アカウントを作成し Amazon EC2 を1年間無料でお試し登録。 https://us-east-2.console.aws.amazon.com/console/home?region=us-east-2 AWS マネジメントコンソール より「仮想マシンを起動する」を選択してEC2を使用開始する。 ステップ 1: Amazon マシンイメージ (AMI) インスタンスの作成に必要なソフトウェア構成 (OS、アプリケーションサーバー、アプリケーション) を含むAmazonマシンイメージ（AMI)を選択する。ここでは一番基本的な「Amazon Linux 2 AMI　64 ビット (x86)」を選択 ステップ 2: インスタンスタイプの選択 インスタンスとは、アプリケーションを実行できる仮想サーバーで、 インスタンスタイプとは、様々なCPU、メモリ、ストレージ、ネットワークキャパシティの組み合わせの構成のこと。 ここでは無料利用枠対象の「t2.micro」 1CPU/1GiBメモリ/NWパフォーマンス[低から中] etc を選択 ステップ 3: インスタンスの詳細の設定 要件に合わせてインスタンスを設定する。ここではすべて初期設定のままとした。 ステップ 4: ストレージの追加 インスタンスのストレージデバイス設定として、無料利用枠の 8GiB 汎用SSD(gp2) /dev/xvda 暗号化なし　を利用 ステップ 5: タグの追加 タグは、大文字と小文字が区別されるキーと値のペアから構成されます。たとえば、キーに「Name」、値に「Webserver」を使用してタグを定義することができます。 とりあえずなしですすめる ステップ 6: セキュリティグループの設定 ポート２２が初期設定されている。 なお自分のPCからインスタンスの設定をSSHで行うのに、接続元を「マイIP」からに限定する。 ここで「起動」を実行すると下記が表示される 既存のキーペアを選択するか、新しいキーペアを作成します。 キーペアは、AWS が保存するパブリックキーとユーザーが保存するプライベートキーファイルで構成され 組み合わせて使用することで、インスタンスに安全に接続できます。 Linux AMI の場合、プライベートキーファイルを使用してインスタンスに SSH で安全に接続できます。 のようなので、キーペア名を入力し、*.pemファイルをダウンロードして自分のPCに保存しておく。 なおPCからSSH接続を試すと、下記のようにpemファイルの権限が弱いとのエラーとなるため、 ssh -i /********.pem ec2-user@xxxxxxxxxxxxxxxxxxxxx @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for '/********..pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "/********.pem": bad permissions ec2-user@xxxxxxxxxxxxxxxxxxxxx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). ダウンロードした pemファイルの権限を下記のように自分からのみ見えるように修正すること。 $ chmod 400 /********.pem 再度SSH接続を試すと接続OKとなった $ ssh -i /********..pem ec2-user@xxxxxxxxxxxxxxxxxxxxx __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ No packages needed for security; 2 packages available Run "sudo yum update" to apply all updates. YUM update してやり、Nginx をインストール $ sudo yum update 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ amazon-ssm-agent.x86_64 0:3.0.161.0-1.amzn2 を 更新 ---> パッケージ amazon-ssm-agent.x86_64 0:3.0.529.0-1.amzn2 を アップデート （略） 更新: amazon-ssm-agent.x86_64 0:3.0.529.0-1.amzn2 aws-cfn-bootstrap.noarch 0:2.0-6.amzn2 完了しました! インストール $ sudo yum install nginx 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd パッケージ nginx は利用できません。 エラー: 何もしません nginx is available in Amazon Linux Extra topic "nginx1" To use, run # sudo amazon-linux-extras install nginx1 Learn more at https://aws.amazon.com/amazon-linux-2/faqs/#Amazon_Linux_Extras $ sudo amazon-linux-extras install nginx1 Installing nginx 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd リポジトリーを清掃しています: amzn2-core amzn2extra-docker amzn2extra-nginx1 12 個の metadata ファイルを削除しました 4 個の sqlite ファイルを削除しました 0 個の metadata ファイルを削除しました 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00 amzn2extra-docker | 3.0 kB 00:00 amzn2extra-nginx1 | 3.0 kB 00:00 (1/7): amzn2-core/2/x86_64/group_gz | 2.5 kB 00:00 (2/7): amzn2-core/2/x86_64/updateinfo | 362 kB 00:00 (3/7): amzn2extra-nginx1/2/x86_64/primary_db | 23 kB 00:00 (4/7): amzn2extra-nginx1/2/x86_64/updateinfo | 76 B 00:00 (5/7): amzn2extra-docker/2/x86_64/updateinfo | 76 B 00:00 (6/7): amzn2extra-docker/2/x86_64/primary_db | 76 kB 00:00 (7/7): amzn2-core/2/x86_64/primary_db | 51 MB 00:00 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ nginx.x86_64 1:1.18.0-1.amzn2.0.2 を インストール --> 依存性の処理をしています: nginx-filesystem = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: nginx-all-modules = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: nginx-filesystem のパッケージ: 1:nginx-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libprofiler.so.0()(64bit) のパッケージ: 1:nginx-1.18.0-1.amzn2.0.2.x86_64 --> トランザクションの確認を実行しています。 ---> パッケージ gperftools-libs.x86_64 0:2.6.1-1.amzn2 を インストール ---> パッケージ nginx-all-modules.noarch 1:1.18.0-1.amzn2.0.2 を インストール --> 依存性の処理をしています: nginx-mod-stream = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-mail = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-http-xslt-filter = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-http-perl = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-http-image-filter = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-http-geoip = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch ---> パッケージ nginx-filesystem.noarch 1:1.18.0-1.amzn2.0.2 を インストール --> トランザクションの確認を実行しています。 ---> パッケージ nginx-mod-http-geoip.x86_64 1:1.18.0-1.amzn2.0.2 を インストール ---> パッケージ nginx-mod-http-image-filter.x86_64 1:1.18.0-1.amzn2.0.2 を インストール --> 依存性の処理をしています: gd のパッケージ: 1:nginx-mod-http-image-filter-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libgd.so.2()(64bit) のパッケージ: 1:nginx-mod-http-image-filter-1.18.0-1.amzn2.0.2.x86_64 ---> パッケージ nginx-mod-http-perl.x86_64 1:1.18.0-1.amzn2.0.2 を インストール ---> パッケージ nginx-mod-http-xslt-filter.x86_64 1:1.18.0-1.amzn2.0.2 を インストール --> 依存性の処理をしています: libxslt.so.1(LIBXML2_1.0.18)(64bit) のパッケージ: 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libxslt.so.1(LIBXML2_1.0.11)(64bit) のパッケージ: 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libxslt.so.1()(64bit) のパッケージ: 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libexslt.so.0()(64bit) のパッケージ: 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86_64 ---> パッケージ nginx-mod-mail.x86_64 1:1.18.0-1.amzn2.0.2 を インストール ---> パッケージ nginx-mod-stream.x86_64 1:1.18.0-1.amzn2.0.2 を インストール --> トランザクションの確認を実行しています。 ---> パッケージ gd.x86_64 0:2.0.35-27.amzn2 を インストール --> 依存性の処理をしています: libfontconfig.so.1()(64bit) のパッケージ: gd-2.0.35-27.amzn2.x86_64 --> 依存性の処理をしています: libXpm.so.4()(64bit) のパッケージ: gd-2.0.35-27.amzn2.x86_64 --> 依存性の処理をしています: libX11.so.6()(64bit) のパッケージ: gd-2.0.35-27.amzn2.x86_64 ---> パッケージ libxslt.x86_64 0:1.1.28-6.amzn2 を インストール --> トランザクションの確認を実行しています。 ---> パッケージ fontconfig.x86_64 0:2.13.0-4.3.amzn2 を インストール --> 依存性の処理をしています: fontpackages-filesystem のパッケージ: fontconfig-2.13.0-4.3.amzn2.x86_64 --> 依存性の処理をしています: dejavu-sans-fonts のパッケージ: fontconfig-2.13.0-4.3.amzn2.x86_64 ---> パッケージ libX11.x86_64 0:1.6.7-3.amzn2 を インストール --> 依存性の処理をしています: libX11-common >= 1.6.7-3.amzn2 のパッケージ: libX11-1.6.7-3.amzn2.x86_64 --> 依存性の処理をしています: libxcb.so.1()(64bit) のパッケージ: libX11-1.6.7-3.amzn2.x86_64 ---> パッケージ libXpm.x86_64 0:3.5.12-1.amzn2.0.2 を インストール --> トランザクションの確認を実行しています。 ---> パッケージ dejavu-sans-fonts.noarch 0:2.33-6.amzn2 を インストール --> 依存性の処理をしています: dejavu-fonts-common = 2.33-6.amzn2 のパッケージ: dejavu-sans-fonts-2.33-6.amzn2.noarch ---> パッケージ fontpackages-filesystem.noarch 0:1.44-8.amzn2 を インストール ---> パッケージ libX11-common.noarch 0:1.6.7-3.amzn2 を インストール ---> パッケージ libxcb.x86_64 0:1.12-1.amzn2.0.2 を インストール --> 依存性の処理をしています: libXau.so.6()(64bit) のパッケージ: libxcb-1.12-1.amzn2.0.2.x86_64 --> トランザクションの確認を実行しています。 ---> パッケージ dejavu-fonts-common.noarch 0:2.33-6.amzn2 を インストール ---> パッケージ libXau.x86_64 0:1.0.8-2.1.amzn2.0.2 を インストール --> 依存性解決を終了しました。 依存性を解決しました ================================================================================ Package アーキテクチャー バージョン リポジトリー 容量 ================================================================================ インストール中: nginx x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 560 k 依存性関連でのインストールをします: dejavu-fonts-common noarch 2.33-6.amzn2 amzn2-core 64 k dejavu-sans-fonts noarch 2.33-6.amzn2 amzn2-core 1.4 M fontconfig x86_64 2.13.0-4.3.amzn2 amzn2-core 253 k fontpackages-filesystem noarch 1.44-8.amzn2 amzn2-core 10 k gd x86_64 2.0.35-27.amzn2 amzn2-core 146 k gperftools-libs x86_64 2.6.1-1.amzn2 amzn2-core 274 k libX11 x86_64 1.6.7-3.amzn2 amzn2-core 606 k libX11-common noarch 1.6.7-3.amzn2 amzn2-core 164 k libXau x86_64 1.0.8-2.1.amzn2.0.2 amzn2-core 29 k libXpm x86_64 3.5.12-1.amzn2.0.2 amzn2-core 57 k libxcb x86_64 1.12-1.amzn2.0.2 amzn2-core 216 k libxslt x86_64 1.1.28-6.amzn2 amzn2-core 240 k nginx-all-modules noarch 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 20 k nginx-filesystem noarch 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 21 k nginx-mod-http-geoip x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 27 k nginx-mod-http-image-filter x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 30 k nginx-mod-http-perl x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 41 k nginx-mod-http-xslt-filter x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 29 k nginx-mod-mail x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 58 k nginx-mod-stream x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 85 k トランザクションの要約 ================================================================================ インストール 1 パッケージ (+20 個の依存関係のパッケージ) 総ダウンロード容量: 4.3 M インストール容量: 14 M Is this ok [y/d/N]: y Downloading packages: (1/21): dejavu-fonts-common-2.33-6.amzn2.noarch.rpm | 64 kB 00:00 (2/21): dejavu-sans-fonts-2.33-6.amzn2.noarch.rpm | 1.4 MB 00:00 (3/21): fontconfig-2.13.0-4.3.amzn2.x86_64.rpm | 253 kB 00:00 (4/21): gd-2.0.35-27.amzn2.x86_64.rpm | 146 kB 00:00 (5/21): fontpackages-filesystem-1.44-8.amzn2.noarch.rpm | 10 kB 00:00 (6/21): libX11-1.6.7-3.amzn2.x86_64.rpm | 606 kB 00:00 (7/21): gperftools-libs-2.6.1-1.amzn2.x86_64.rpm | 274 kB 00:00 (8/21): libX11-common-1.6.7-3.amzn2.noarch.rpm | 164 kB 00:00 (9/21): libXpm-3.5.12-1.amzn2.0.2.x86_64.rpm | 57 kB 00:00 (10/21): libxcb-1.12-1.amzn2.0.2.x86_64.rpm | 216 kB 00:00 (11/21): libxslt-1.1.28-6.amzn2.x86_64.rpm | 240 kB 00:00 (12/21): libXau-1.0.8-2.1.amzn2.0.2.x86_64.rpm | 29 kB 00:00 (13/21): nginx-1.18.0-1.amzn2.0.2.x86_64.rpm | 560 kB 00:00 (14/21): nginx-all-modules-1.18.0-1.amzn2.0.2.noarch.rpm | 20 kB 00:00 (15/21): nginx-mod-http-geoip-1.18.0-1.amzn2.0.2.x86_64.rp | 27 kB 00:00 (16/21): nginx-mod-http-image-filter-1.18.0-1.amzn2.0.2.x8 | 30 kB 00:00 (17/21): nginx-mod-http-perl-1.18.0-1.amzn2.0.2.x86_64.rpm | 41 kB 00:00 (18/21): nginx-filesystem-1.18.0-1.amzn2.0.2.noarch.rpm | 21 kB 00:00 (19/21): nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86 | 29 kB 00:00 (20/21): nginx-mod-mail-1.18.0-1.amzn2.0.2.x86_64.rpm | 58 kB 00:00 (21/21): nginx-mod-stream-1.18.0-1.amzn2.0.2.x86_64.rpm | 85 kB 00:00 -------------------------------------------------------------------------------- 合計 7.6 MB/s | 4.3 MB 00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction インストール中 : fontpackages-filesystem-1.44-8.amzn2.noarch 1/21 インストール中 : dejavu-fonts-common-2.33-6.amzn2.noarch 2/21 インストール中 : dejavu-sans-fonts-2.33-6.amzn2.noarch 3/21 インストール中 : fontconfig-2.13.0-4.3.amzn2.x86_64 4/21 インストール中 : libxslt-1.1.28-6.amzn2.x86_64 5/21 インストール中 : libXau-1.0.8-2.1.amzn2.0.2.x86_64 6/21 インストール中 : libxcb-1.12-1.amzn2.0.2.x86_64 7/21 インストール中 : libX11-common-1.6.7-3.amzn2.noarch 8/21 インストール中 : libX11-1.6.7-3.amzn2.x86_64 9/21 インストール中 : libXpm-3.5.12-1.amzn2.0.2.x86_64 10/21 インストール中 : gd-2.0.35-27.amzn2.x86_64 11/21 インストール中 : 1:nginx-filesystem-1.18.0-1.amzn2.0.2.noarc 12/21 インストール中 : gperftools-libs-2.6.1-1.amzn2.x86_64 13/21 インストール中 : 1:nginx-mod-http-perl-1.18.0-1.amzn2.0.2.x8 14/21 インストール中 : 1:nginx-mod-stream-1.18.0-1.amzn2.0.2.x86_6 15/21 インストール中 : 1:nginx-mod-http-geoip-1.18.0-1.amzn2.0.2.x 16/21 インストール中 : 1:nginx-mod-mail-1.18.0-1.amzn2.0.2.x86_64 17/21 インストール中 : 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2 18/21 インストール中 : 1:nginx-1.18.0-1.amzn2.0.2.x86_64 19/21 インストール中 : 1:nginx-mod-http-image-filter-1.18.0-1.amzn 20/21 インストール中 : 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noar 21/21 検証中 : fontconfig-2.13.0-4.3.amzn2.x86_64 1/21 検証中 : 1:nginx-mod-http-perl-1.18.0-1.amzn2.0.2.x8 2/21 検証中 : 1:nginx-mod-stream-1.18.0-1.amzn2.0.2.x86_6 3/21 検証中 : libX11-1.6.7-3.amzn2.x86_64 4/21 検証中 : gperftools-libs-2.6.1-1.amzn2.x86_64 5/21 検証中 : 1:nginx-mod-http-geoip-1.18.0-1.amzn2.0.2.x 6/21 検証中 : 1:nginx-filesystem-1.18.0-1.amzn2.0.2.noarc 7/21 検証中 : 1:nginx-mod-mail-1.18.0-1.amzn2.0.2.x86_64 8/21 検証中 : libxcb-1.12-1.amzn2.0.2.x86_64 9/21 検証中 : dejavu-sans-fonts-2.33-6.amzn2.noarch 10/21 検証中 : 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2 11/21 検証中 : 1:nginx-mod-http-image-filter-1.18.0-1.amzn 12/21 検証中 : dejavu-fonts-common-2.33-6.amzn2.noarch 13/21 検証中 : fontpackages-filesystem-1.44-8.amzn2.noarch 14/21 検証中 : gd-2.0.35-27.amzn2.x86_64 15/21 検証中 : libX11-common-1.6.7-3.amzn2.noarch 16/21 検証中 : 1:nginx-1.18.0-1.amzn2.0.2.x86_64 17/21 検証中 : libXau-1.0.8-2.1.amzn2.0.2.x86_64 18/21 検証中 : libxslt-1.1.28-6.amzn2.x86_64 19/21 検証中 : 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noar 20/21 検証中 : libXpm-3.5.12-1.amzn2.0.2.x86_64 21/21 インストール: nginx.x86_64 1:1.18.0-1.amzn2.0.2 依存性関連をインストールしました: dejavu-fonts-common.noarch 0:2.33-6.amzn2 dejavu-sans-fonts.noarch 0:2.33-6.amzn2 fontconfig.x86_64 0:2.13.0-4.3.amzn2 fontpackages-filesystem.noarch 0:1.44-8.amzn2 gd.x86_64 0:2.0.35-27.amzn2 gperftools-libs.x86_64 0:2.6.1-1.amzn2 libX11.x86_64 0:1.6.7-3.amzn2 libX11-common.noarch 0:1.6.7-3.amzn2 libXau.x86_64 0:1.0.8-2.1.amzn2.0.2 libXpm.x86_64 0:3.5.12-1.amzn2.0.2 libxcb.x86_64 0:1.12-1.amzn2.0.2 libxslt.x86_64 0:1.1.28-6.amzn2 nginx-all-modules.noarch 1:1.18.0-1.amzn2.0.2 nginx-filesystem.noarch 1:1.18.0-1.amzn2.0.2 nginx-mod-http-geoip.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-http-image-filter.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-http-perl.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-http-xslt-filter.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-mail.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-stream.x86_64 1:1.18.0-1.amzn2.0.2 完了しました! コンソールからバージョン確認し、手動で起動 $ nginx -V nginx version: nginx/1.18.0 built by gcc 7.3.1 20180712 (Red Hat 7.3.1-10) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-stream_ssl_preread_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-http_auth_request_module --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E' $ sudo systemctl start nginx $ sudo systemctl -l UNIT LOAD ACTIVE SUB （略） network.service loaded active runn nginx.service loaded active runn （略） このあとEC2コンソール画面に戻り、「ステップ 6: セキュリティグループの設定」で、ポート２２以外にポート８０を追加設定してやり、HTTP用ポートを開く必要あり。こちらもSSH同様、まずは自分のPCからのアクセス用に開放 AWS_InstanceSecurityGpSetting80 copy.png これでようやくHTTPサーバーNginxにアクセスが成功し、ウェルカム画面を表示させることができた。

https://aws.amazon.com/jp/s/dm/landing-page/create-free-account より、AWS アカウントを作成し Amazon EC2 を1年間無料でお試し登録。 https://us-east-2.console.aws.amazon.com/console/home?region=us-east-2 AWS マネジメントコンソール より「仮想マシンを起動する」を選択してEC2を使用開始する。 ステップ 1: Amazon マシンイメージ (AMI) インスタンスの作成に必要なソフトウェア構成 (OS、アプリケーションサーバー、アプリケーション) を含むAmazonマシンイメージ（AMI)を選択する。ここでは一番基本的な「Amazon Linux 2 AMI　64 ビット (x86)」を選択 ステップ 2: インスタンスタイプの選択 インスタンスとは、アプリケーションを実行できる仮想サーバーで、 インスタンスタイプとは、様々なCPU、メモリ、ストレージ、ネットワークキャパシティの組み合わせの構成のこと。 ここでは無料利用枠対象の「t2.micro」 1CPU/1GiBメモリ/NWパフォーマンス[低から中] etc を選択 ステップ 3: インスタンスの詳細の設定 要件に合わせてインスタンスを設定する。ここではすべて初期設定のままとした。 ステップ 4: ストレージの追加 インスタンスのストレージデバイス設定として、無料利用枠の 8GiB 汎用SSD(gp2) /dev/xvda 暗号化なし　を利用 ステップ 5: タグの追加 タグは、大文字と小文字が区別されるキーと値のペアから構成されます。たとえば、キーに「Name」、値に「Webserver」を使用してタグを定義することができます。 とりあえずなしですすめる ステップ 6: セキュリティグループの設定 ポート２２が初期設定されている。 なお自分のPCからインスタンスの設定をSSHで行うのに、接続元を「マイIP」からに限定する。 キーペアの作成 ここで「起動」を実行すると下記が表示される 既存のキーペアを選択するか、新しいキーペアを作成します。 キーペアは、AWS が保存するパブリックキーとユーザーが保存するプライベートキーファイルで構成され組み合わせて使用することで、インスタンスに安全に接続できます。Linux AMI の場合、プライベートキーファイルを使用してインスタンスに SSH で安全に接続できます。 のようなので、キーペア名を入力し、*.pemファイルをダウンロードして自分のPCに保存しておく。 インスタンスへのSSH接続 なおPCからSSH接続を試すと、下記のようにpemファイルの権限が弱いとのエラーとなるため、 ssh -i /********.pem ec2-user@xxxxxxxxxxxxxxxxxxxxx @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for '/********..pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "/********.pem": bad permissions ec2-user@xxxxxxxxxxxxxxxxxxxxx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). ダウンロードした pemファイルの権限を下記のように自分からのみ見えるように修正すること。 $ chmod 400 /********.pem 再度SSH接続を試すと接続OKとなった $ ssh -i /********..pem ec2-user@xxxxxxxxxxxxxxxxxxxxx __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ No packages needed for security; 2 packages available Run "sudo yum update" to apply all updates. Nginx Webサーバーのインストール YUM update してやり、Nginx をインストール $ sudo yum update 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ amazon-ssm-agent.x86_64 0:3.0.161.0-1.amzn2 を 更新 ---> パッケージ amazon-ssm-agent.x86_64 0:3.0.529.0-1.amzn2 を アップデート （略） 更新: amazon-ssm-agent.x86_64 0:3.0.529.0-1.amzn2 aws-cfn-bootstrap.noarch 0:2.0-6.amzn2 完了しました! インストールは yum install nginx ではなく、amazon-linux-extras install nginx1 で行う必要ありとのこと。 $ sudo yum install nginx 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd パッケージ nginx は利用できません。 エラー: 何もしません nginx is available in Amazon Linux Extra topic "nginx1" To use, run # sudo amazon-linux-extras install nginx1 Learn more at https://aws.amazon.com/amazon-linux-2/faqs/#Amazon_Linux_Extras $ sudo amazon-linux-extras install nginx1 Installing nginx 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd リポジトリーを清掃しています: amzn2-core amzn2extra-docker amzn2extra-nginx1 12 個の metadata ファイルを削除しました 4 個の sqlite ファイルを削除しました 0 個の metadata ファイルを削除しました 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00 amzn2extra-docker | 3.0 kB 00:00 amzn2extra-nginx1 | 3.0 kB 00:00 (1/7): amzn2-core/2/x86_64/group_gz | 2.5 kB 00:00 (2/7): amzn2-core/2/x86_64/updateinfo | 362 kB 00:00 (3/7): amzn2extra-nginx1/2/x86_64/primary_db | 23 kB 00:00 (4/7): amzn2extra-nginx1/2/x86_64/updateinfo | 76 B 00:00 (5/7): amzn2extra-docker/2/x86_64/updateinfo | 76 B 00:00 (6/7): amzn2extra-docker/2/x86_64/primary_db | 76 kB 00:00 (7/7): amzn2-core/2/x86_64/primary_db | 51 MB 00:00 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ nginx.x86_64 1:1.18.0-1.amzn2.0.2 を インストール --> 依存性の処理をしています: nginx-filesystem = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: nginx-all-modules = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: nginx-filesystem のパッケージ: 1:nginx-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libprofiler.so.0()(64bit) のパッケージ: 1:nginx-1.18.0-1.amzn2.0.2.x86_64 --> トランザクションの確認を実行しています。 ---> パッケージ gperftools-libs.x86_64 0:2.6.1-1.amzn2 を インストール ---> パッケージ nginx-all-modules.noarch 1:1.18.0-1.amzn2.0.2 を インストール --> 依存性の処理をしています: nginx-mod-stream = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-mail = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-http-xslt-filter = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-http-perl = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-http-image-filter = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch --> 依存性の処理をしています: nginx-mod-http-geoip = 1:1.18.0-1.amzn2.0.2 のパッケージ: 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noarch ---> パッケージ nginx-filesystem.noarch 1:1.18.0-1.amzn2.0.2 を インストール --> トランザクションの確認を実行しています。 ---> パッケージ nginx-mod-http-geoip.x86_64 1:1.18.0-1.amzn2.0.2 を インストール ---> パッケージ nginx-mod-http-image-filter.x86_64 1:1.18.0-1.amzn2.0.2 を インストール --> 依存性の処理をしています: gd のパッケージ: 1:nginx-mod-http-image-filter-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libgd.so.2()(64bit) のパッケージ: 1:nginx-mod-http-image-filter-1.18.0-1.amzn2.0.2.x86_64 ---> パッケージ nginx-mod-http-perl.x86_64 1:1.18.0-1.amzn2.0.2 を インストール ---> パッケージ nginx-mod-http-xslt-filter.x86_64 1:1.18.0-1.amzn2.0.2 を インストール --> 依存性の処理をしています: libxslt.so.1(LIBXML2_1.0.18)(64bit) のパッケージ: 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libxslt.so.1(LIBXML2_1.0.11)(64bit) のパッケージ: 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libxslt.so.1()(64bit) のパッケージ: 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86_64 --> 依存性の処理をしています: libexslt.so.0()(64bit) のパッケージ: 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86_64 ---> パッケージ nginx-mod-mail.x86_64 1:1.18.0-1.amzn2.0.2 を インストール ---> パッケージ nginx-mod-stream.x86_64 1:1.18.0-1.amzn2.0.2 を インストール --> トランザクションの確認を実行しています。 ---> パッケージ gd.x86_64 0:2.0.35-27.amzn2 を インストール --> 依存性の処理をしています: libfontconfig.so.1()(64bit) のパッケージ: gd-2.0.35-27.amzn2.x86_64 --> 依存性の処理をしています: libXpm.so.4()(64bit) のパッケージ: gd-2.0.35-27.amzn2.x86_64 --> 依存性の処理をしています: libX11.so.6()(64bit) のパッケージ: gd-2.0.35-27.amzn2.x86_64 ---> パッケージ libxslt.x86_64 0:1.1.28-6.amzn2 を インストール --> トランザクションの確認を実行しています。 ---> パッケージ fontconfig.x86_64 0:2.13.0-4.3.amzn2 を インストール --> 依存性の処理をしています: fontpackages-filesystem のパッケージ: fontconfig-2.13.0-4.3.amzn2.x86_64 --> 依存性の処理をしています: dejavu-sans-fonts のパッケージ: fontconfig-2.13.0-4.3.amzn2.x86_64 ---> パッケージ libX11.x86_64 0:1.6.7-3.amzn2 を インストール --> 依存性の処理をしています: libX11-common >= 1.6.7-3.amzn2 のパッケージ: libX11-1.6.7-3.amzn2.x86_64 --> 依存性の処理をしています: libxcb.so.1()(64bit) のパッケージ: libX11-1.6.7-3.amzn2.x86_64 ---> パッケージ libXpm.x86_64 0:3.5.12-1.amzn2.0.2 を インストール --> トランザクションの確認を実行しています。 ---> パッケージ dejavu-sans-fonts.noarch 0:2.33-6.amzn2 を インストール --> 依存性の処理をしています: dejavu-fonts-common = 2.33-6.amzn2 のパッケージ: dejavu-sans-fonts-2.33-6.amzn2.noarch ---> パッケージ fontpackages-filesystem.noarch 0:1.44-8.amzn2 を インストール ---> パッケージ libX11-common.noarch 0:1.6.7-3.amzn2 を インストール ---> パッケージ libxcb.x86_64 0:1.12-1.amzn2.0.2 を インストール --> 依存性の処理をしています: libXau.so.6()(64bit) のパッケージ: libxcb-1.12-1.amzn2.0.2.x86_64 --> トランザクションの確認を実行しています。 ---> パッケージ dejavu-fonts-common.noarch 0:2.33-6.amzn2 を インストール ---> パッケージ libXau.x86_64 0:1.0.8-2.1.amzn2.0.2 を インストール --> 依存性解決を終了しました。 依存性を解決しました ================================================================================ Package アーキテクチャー バージョン リポジトリー 容量 ================================================================================ インストール中: nginx x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 560 k 依存性関連でのインストールをします: dejavu-fonts-common noarch 2.33-6.amzn2 amzn2-core 64 k dejavu-sans-fonts noarch 2.33-6.amzn2 amzn2-core 1.4 M fontconfig x86_64 2.13.0-4.3.amzn2 amzn2-core 253 k fontpackages-filesystem noarch 1.44-8.amzn2 amzn2-core 10 k gd x86_64 2.0.35-27.amzn2 amzn2-core 146 k gperftools-libs x86_64 2.6.1-1.amzn2 amzn2-core 274 k libX11 x86_64 1.6.7-3.amzn2 amzn2-core 606 k libX11-common noarch 1.6.7-3.amzn2 amzn2-core 164 k libXau x86_64 1.0.8-2.1.amzn2.0.2 amzn2-core 29 k libXpm x86_64 3.5.12-1.amzn2.0.2 amzn2-core 57 k libxcb x86_64 1.12-1.amzn2.0.2 amzn2-core 216 k libxslt x86_64 1.1.28-6.amzn2 amzn2-core 240 k nginx-all-modules noarch 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 20 k nginx-filesystem noarch 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 21 k nginx-mod-http-geoip x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 27 k nginx-mod-http-image-filter x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 30 k nginx-mod-http-perl x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 41 k nginx-mod-http-xslt-filter x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 29 k nginx-mod-mail x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 58 k nginx-mod-stream x86_64 1:1.18.0-1.amzn2.0.2 amzn2extra-nginx1 85 k トランザクションの要約 ================================================================================ インストール 1 パッケージ (+20 個の依存関係のパッケージ) 総ダウンロード容量: 4.3 M インストール容量: 14 M Is this ok [y/d/N]: y Downloading packages: (1/21): dejavu-fonts-common-2.33-6.amzn2.noarch.rpm | 64 kB 00:00 (2/21): dejavu-sans-fonts-2.33-6.amzn2.noarch.rpm | 1.4 MB 00:00 (3/21): fontconfig-2.13.0-4.3.amzn2.x86_64.rpm | 253 kB 00:00 (4/21): gd-2.0.35-27.amzn2.x86_64.rpm | 146 kB 00:00 (5/21): fontpackages-filesystem-1.44-8.amzn2.noarch.rpm | 10 kB 00:00 (6/21): libX11-1.6.7-3.amzn2.x86_64.rpm | 606 kB 00:00 (7/21): gperftools-libs-2.6.1-1.amzn2.x86_64.rpm | 274 kB 00:00 (8/21): libX11-common-1.6.7-3.amzn2.noarch.rpm | 164 kB 00:00 (9/21): libXpm-3.5.12-1.amzn2.0.2.x86_64.rpm | 57 kB 00:00 (10/21): libxcb-1.12-1.amzn2.0.2.x86_64.rpm | 216 kB 00:00 (11/21): libxslt-1.1.28-6.amzn2.x86_64.rpm | 240 kB 00:00 (12/21): libXau-1.0.8-2.1.amzn2.0.2.x86_64.rpm | 29 kB 00:00 (13/21): nginx-1.18.0-1.amzn2.0.2.x86_64.rpm | 560 kB 00:00 (14/21): nginx-all-modules-1.18.0-1.amzn2.0.2.noarch.rpm | 20 kB 00:00 (15/21): nginx-mod-http-geoip-1.18.0-1.amzn2.0.2.x86_64.rp | 27 kB 00:00 (16/21): nginx-mod-http-image-filter-1.18.0-1.amzn2.0.2.x8 | 30 kB 00:00 (17/21): nginx-mod-http-perl-1.18.0-1.amzn2.0.2.x86_64.rpm | 41 kB 00:00 (18/21): nginx-filesystem-1.18.0-1.amzn2.0.2.noarch.rpm | 21 kB 00:00 (19/21): nginx-mod-http-xslt-filter-1.18.0-1.amzn2.0.2.x86 | 29 kB 00:00 (20/21): nginx-mod-mail-1.18.0-1.amzn2.0.2.x86_64.rpm | 58 kB 00:00 (21/21): nginx-mod-stream-1.18.0-1.amzn2.0.2.x86_64.rpm | 85 kB 00:00 -------------------------------------------------------------------------------- 合計 7.6 MB/s | 4.3 MB 00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction インストール中 : fontpackages-filesystem-1.44-8.amzn2.noarch 1/21 インストール中 : dejavu-fonts-common-2.33-6.amzn2.noarch 2/21 インストール中 : dejavu-sans-fonts-2.33-6.amzn2.noarch 3/21 インストール中 : fontconfig-2.13.0-4.3.amzn2.x86_64 4/21 インストール中 : libxslt-1.1.28-6.amzn2.x86_64 5/21 インストール中 : libXau-1.0.8-2.1.amzn2.0.2.x86_64 6/21 インストール中 : libxcb-1.12-1.amzn2.0.2.x86_64 7/21 インストール中 : libX11-common-1.6.7-3.amzn2.noarch 8/21 インストール中 : libX11-1.6.7-3.amzn2.x86_64 9/21 インストール中 : libXpm-3.5.12-1.amzn2.0.2.x86_64 10/21 インストール中 : gd-2.0.35-27.amzn2.x86_64 11/21 インストール中 : 1:nginx-filesystem-1.18.0-1.amzn2.0.2.noarc 12/21 インストール中 : gperftools-libs-2.6.1-1.amzn2.x86_64 13/21 インストール中 : 1:nginx-mod-http-perl-1.18.0-1.amzn2.0.2.x8 14/21 インストール中 : 1:nginx-mod-stream-1.18.0-1.amzn2.0.2.x86_6 15/21 インストール中 : 1:nginx-mod-http-geoip-1.18.0-1.amzn2.0.2.x 16/21 インストール中 : 1:nginx-mod-mail-1.18.0-1.amzn2.0.2.x86_64 17/21 インストール中 : 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2 18/21 インストール中 : 1:nginx-1.18.0-1.amzn2.0.2.x86_64 19/21 インストール中 : 1:nginx-mod-http-image-filter-1.18.0-1.amzn 20/21 インストール中 : 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noar 21/21 検証中 : fontconfig-2.13.0-4.3.amzn2.x86_64 1/21 検証中 : 1:nginx-mod-http-perl-1.18.0-1.amzn2.0.2.x8 2/21 検証中 : 1:nginx-mod-stream-1.18.0-1.amzn2.0.2.x86_6 3/21 検証中 : libX11-1.6.7-3.amzn2.x86_64 4/21 検証中 : gperftools-libs-2.6.1-1.amzn2.x86_64 5/21 検証中 : 1:nginx-mod-http-geoip-1.18.0-1.amzn2.0.2.x 6/21 検証中 : 1:nginx-filesystem-1.18.0-1.amzn2.0.2.noarc 7/21 検証中 : 1:nginx-mod-mail-1.18.0-1.amzn2.0.2.x86_64 8/21 検証中 : libxcb-1.12-1.amzn2.0.2.x86_64 9/21 検証中 : dejavu-sans-fonts-2.33-6.amzn2.noarch 10/21 検証中 : 1:nginx-mod-http-xslt-filter-1.18.0-1.amzn2 11/21 検証中 : 1:nginx-mod-http-image-filter-1.18.0-1.amzn 12/21 検証中 : dejavu-fonts-common-2.33-6.amzn2.noarch 13/21 検証中 : fontpackages-filesystem-1.44-8.amzn2.noarch 14/21 検証中 : gd-2.0.35-27.amzn2.x86_64 15/21 検証中 : libX11-common-1.6.7-3.amzn2.noarch 16/21 検証中 : 1:nginx-1.18.0-1.amzn2.0.2.x86_64 17/21 検証中 : libXau-1.0.8-2.1.amzn2.0.2.x86_64 18/21 検証中 : libxslt-1.1.28-6.amzn2.x86_64 19/21 検証中 : 1:nginx-all-modules-1.18.0-1.amzn2.0.2.noar 20/21 検証中 : libXpm-3.5.12-1.amzn2.0.2.x86_64 21/21 インストール: nginx.x86_64 1:1.18.0-1.amzn2.0.2 依存性関連をインストールしました: dejavu-fonts-common.noarch 0:2.33-6.amzn2 dejavu-sans-fonts.noarch 0:2.33-6.amzn2 fontconfig.x86_64 0:2.13.0-4.3.amzn2 fontpackages-filesystem.noarch 0:1.44-8.amzn2 gd.x86_64 0:2.0.35-27.amzn2 gperftools-libs.x86_64 0:2.6.1-1.amzn2 libX11.x86_64 0:1.6.7-3.amzn2 libX11-common.noarch 0:1.6.7-3.amzn2 libXau.x86_64 0:1.0.8-2.1.amzn2.0.2 libXpm.x86_64 0:3.5.12-1.amzn2.0.2 libxcb.x86_64 0:1.12-1.amzn2.0.2 libxslt.x86_64 0:1.1.28-6.amzn2 nginx-all-modules.noarch 1:1.18.0-1.amzn2.0.2 nginx-filesystem.noarch 1:1.18.0-1.amzn2.0.2 nginx-mod-http-geoip.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-http-image-filter.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-http-perl.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-http-xslt-filter.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-mail.x86_64 1:1.18.0-1.amzn2.0.2 nginx-mod-stream.x86_64 1:1.18.0-1.amzn2.0.2 完了しました! Nginx Webサーバーの起動 コンソールからバージョン確認し、手動で起動 $ nginx -V nginx version: nginx/1.18.0 built by gcc 7.3.1 20180712 (Red Hat 7.3.1-10) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-compat --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-stream_ssl_preread_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-http_auth_request_module --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E' $ sudo systemctl start nginx $ sudo systemctl -l UNIT LOAD ACTIVE SUB （略） network.service loaded active runn nginx.service loaded active runn （略） Webサーバー用ポートの開放とWebアクセス開通確認 このあとEC2コンソール画面に戻り、「ステップ 6: セキュリティグループの設定」で、ポート２２以外にポート８０を追加設定してやり、HTTP用ポートを開く必要あり。こちらもSSH同様、まずは自分のPCからのアクセス用に開放 これでようやくHTTPサーバーNginxにアクセスが成功し、ウェルカム画面を表示させることができた。

はまったエラー Lambda上でPillow-SIMDを使用した際に下記のエラーが発生した。 Unable to import module 'app': libjpeg.so.8: cannot open shared object file: No such file or directory エラー内容はPillow-SIMDを使用する際に依存モジュールであるlibjpegが存在しないよというもの 解決方法 1.libjpeg.soなど必要な依存モジュールをまとめたzipを作成する 2.右上のレイヤーの作成をクリック 3.名前に任意の名称を入力し、1で作成したzipをアップロードし作成をクリック 4.レイヤーが作成されるのでarnをコピーしておく 5.コピーしたarnを下記のページを参考にconfig.jsonに設定する。 config.json "automatic_layer": true, "layers": [ "4でコピーしたarn" ] 参考URL https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.html https://qiita.com/t-kigi/items/0b4dd6bd15313faa3d73

概要 AWS EC2に対してSSHでのログインを行う際に、踏み台サーバからのログイン・直接SSH接続などのオンプレライクな接続方法が今更ながらイケてないなと感じ、セッションマネージャー（SSM）を用いたインスタンスへのログインを試してみました。 他の先人の方々の記事を参考に試してみたという自分用メモですので特に目新しい記事にはなっておりません。 そもそもセッションマネージャーとは セッションマネージャーとはなんぞやというあたり、またその利点については詳しく書いてあるリンク貼っておきます。 AWS Systems Manager (SSM) を やってみよう セッションマネージャー越しにSSHアクセスすると何が嬉しいのか 要するに、SSMの機能の一部の「セッションマネージャー」とやらを使うと、以下のような利点がありますよと言うことです。（と理解しています） 踏み台サーバが不要 IAMで認証・認可できる SSH用のインバウンド設定する必要無い 設定手順 手順についても他の方の記事等参考にさせていただきました。 初めてのAWS Session Manager（SSM） EC2インスタンスにWindowsとMacからセッションマネージャーを利用して接続してみた IAMロール作成 SSMを利用するためのIAMロールを作成します。 「IAMロール」 > 「ロールの作成」 「AmazonEC2RoleforSSM」を選択 > ロール名等指定して作成 インスタンス作成 SSH接続対象のインスタンスを作成します。 「EC2」 > 「インスタンスを起動」 > 先程作成したIAMロールを付与 クライアント端末（Mac）の設定 aws-cli はインストール済み、また設定も完了していることを前提とします。ここでは Session Manager plugin のインストール方法のみ記載します。（cli の設定等は 設定手順に貼ったリンク参照） bash $ cd /tmp $ curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip" $ unzip sessionmanager-bundle.zip $ sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin 接続 aws-cli を用いてセッションマネージャー経由で作成したインスタンスにログインを行います。 bash $ aws ssm start-session --target <インスタンスID> 感想 踏み台とか余計な設定とかなくなってラッキー セッション履歴をS3に保存できるみたいでそういった管理もうまくできそう。 以下の点が未検証なので確認したいと思っています。 インスタンス作成時に登録した認証鍵を持っていないユーザでも適切なIAMさえあればログイン可能なのか AWS公式ドキュメント に書いてありました。そもそも鍵の管理をしなくても接続できるということも利点の一つですね。 グローバルIPのないEC2(プライベートサブネット内のEC2)に対してのセッションマネージャーを用いたSSH方法 こちらの記事 にあるようにplivatelinkを用いた方法で実現できるようです

概要 AWSのEC2について学習して理解した内容をまとめた。 EC2 EC2とは 仮想サーバーを作る機能を提供するアンマネージドサービス 仮想サーバーのことをEC2インスタンスという インスタンスタイプ AWSではさまざまな種類のEC2のインスタンスを使うことができる。 EC2インスタンスの種類は用途別に大きく分けられており、これをインスタンスタイプという いろいろなインスタンスタイプがあるが、一般的にサーバー用途としてよく使われるのはT2とM5らしい。 EBS EC2インスタンスには1台以上のディスクが必要 EC2インスタンスで一般的に扱うのはEBSという機能で作られたボリューム 料金 EC2の料金=インスタンス使用量＋EBSの費用＋通信費用＋その他のオプション インスタンス使用量 稼働している秒単位での課金 EBSの費用 EC2インスタンスで利用するEBSの費用 確保した容量単位の課金 通信費用 EC2インスタンスとの通信費用 インターネットからEC2インスタンスに向けた通信は無料で、EC2インスタンスからインターネットに向けた通信のみ費用がかかる。 その他のオプション EC2にはさまざまなオプションが追加でき、そうしたオプションを使う場合は費用がかかる。

概要 AWSのS3について学習して理解した内容をまとめた。 S3 S3とは ストレージサービスを提供するマネージドサービス 簡単にいうとファイル置き場 ファイル置き場のことをS3バケットと呼ぶ。 S3バケットはPCのドライブに相当するものというイメージ Static website hosting Static website hostingという機能を有効にするとWebServerとして使えるようになる。 ただしプログラムの実行ができないのであくまで静的サイトのホスティングしかできない。 料金 保存している容量と転送量(ダウンロード等)に基づいた従量課金制 ちなみにデータのアップロード時には課金はされない。 メリット マネージドサービスのためストレージを自動的に拡張・縮小してくれる。 あとは高い耐久性、安価、データ量無制限、他のAWSサービスとの連携などがある。

概要 AWSのS3について学習して理解した内容をまとめた。 S3 S3とは ストレージサービスを提供するマネージドサービス 簡単にいうとファイル置き場 ファイル置き場のことをS3バケットと呼ぶ。 S3バケットはPCのドライブに相当するものというイメージ Static website hosting Static website hostingという機能を有効にするとWebServerとして使えるようになる。 ただしプログラムの実行ができないのであくまで静的サイトのホスティングしかできない。 料金 保存している容量と転送量(ダウンロード等)に基づいた従量課金制 ちなみにデータのアップロード時には課金はされない。 メリット マネージドサービスのためストレージを自動的に拡張・縮小してくれる。 あとは高い耐久性、安価、データ量無制限、他のAWSサービスとの連携などがある。