CloudWatchでメトリクス数値を四則演算する

サーバー1のCPU使用率　と　サーバー2のCPU使用率

これらの平均が80%を超えた時、Auto Scalingが発動する…
よくある設計だ。

CPU使用率のメトリクスを2つ選択した後、

[グラフ化したメトリクス]タブで
[+数学式の追加]を押下しよう。

すると、ラベルが [式1] となったメトリクスが現れる。

詳細欄に四則演算を書いてみよう。

(m1 + m2) /2

（サーバー1のCPU使用率 + サーバー2のCPU使用率）/ 2

　※m1やm2はメトリクスの[Id]のラベルの名前に紐づく

完成。

まとめ

アイディア次第によっては色々な数式を試せる。

↓冗長化サーバーのCPU使用率平均。AutoScalingの発動目安になる

(CPUUtilization + CPUUtilization) /2

↓500エラー（リクエストに対するサーバー側のエラー）発生率

100 * HTTPCode_Target_5xx_Count ÷ Request_Count

↓RDSの読み込み使用率

100 * ConsumedReadCapacityUnits ÷ ProvisionedReadCapacityUnits

参考
https://aws.amazon.com/jp/blogs/mt/amazon-cloudwatch-metric-math-simplifies-near-real-time-monitoring-of-your-amazon-efs-file-systems-and-more/
英語OKな方ならこちらも参照して頂きたい。

ありがとうございました。
少しでもお役にたちましたら「いいね」をよろしくお願いします。

はじめに

AWS Single Sign-On (SSO) は、複数の AWS アカウントおよびビジネスアプリケーションへの SSO アクセスの一元管理を簡単にするクラウド SSO サービスです。
https://aws.amazon.com/jp/single-sign-on/

AWS SSOを使用するメリットはとしては、今までSSOを組む場合は、例えばActive Directoryを使う場合は、Active Directoryのユーザに対して、AWSの権限を付与するためのマッピングルール(Claim rule)
を記述する必要があり、記述内容がが複雑でした。AWS SSOは、このマッピングを直接記述する必要がなく、AWS SSO側でよろしくやってくれるといったメリットがあります。

Claim ruleの例

Vcenterと連携するパターン
https://docs.aws.amazon.com/ja_jp/amp/latest/userguide/configure-trust-with-aws.html

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => 
issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", 
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = 
"urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");

AWS SSO

準備している既存ルールを選択する or カスタムで定義することが可能です。
準備してある既存のルールの一覧は以下になります。

• AdministratorAccess: Provides full access to AWS services and resources.
• Billing: Grants permissions for billing and cost management. This includes viewing account usage and viewing and modifying budgets and payment methods.
• DataScientist: Grants permissions to AWS data analytics services.
• DatabaseAdministrator: Grants full access permissions to AWS services and actions required to set up and configure AWS database services.
• NetworkAdministrator: Grants full access permissions to AWS services and actions required to set up and configure AWS network resources.
• PowerUserAccess: Provides full access to AWS services and resources, but does not allow management of Users and groups.
• SecurityAudit: The security audit template grants access to read security configuration metadata. It is useful for software that audits the configuration of an AWS account.
• SupportUser: This policy grants permissions to troubleshoot and resolve issues in an AWS account. This policy also enables the user to contact AWS support to create and manage cases.
• SystemAdministrator: Grants full access permissions necessary for resources required for application and development operations.
• ViewOnlyAccess: This policy grants permissions to view resources and basic metadata across all AWS services.

カスタムパーミッションについては、AWSの管理IAMポリシーか個別にカスマイズしたIAMポリシーをアタッチすることができます。

セットアップの流れ

前提

AWS OrganizationsでALL FEATURESを有効にする必要があります。
Active Directoryを準備するか、AWS SSOが保持するユーザ管理用の機能を使用する必要ああります。Active Directoryは、AWS MS ADをご使用いただく方法と、オンプレミスのADをご使用いただく方法があります。オンプレミスのADは、AD Connector経由で接続するか、AWS MS ADを別途構築し信頼関係を結ぶ必要があります。

ディレクトリの設定

バージニアリージョンでAWS SSOの管理コンソールにログインします。

DirectoryからConnect directoryをクリックします。

今回はAWS SSOが提供するユーザデータベースを使用します。

確認します。

これで事前準備完了です。

ユーザの追加

Add Userをクリックします。

メールが届く
no-reply@login.awsapps.com no-reply@login.awsapps.com
Invitation to join AWS Single Sign-On

パーミッション設定を実施していないので、このまま放置します。

ユーザにOrgnization配下のAWSアカウントに対するアクセス権限を付与する

パーミッションセットが無いので作成します。

準備してあるセキュリティセットかカスタムのセキュリティセットを選択します。

今回は、準備してるAdministratorAccessを指定する

ログインしてみる

InvitationメールにあったAccept Invitationをクリックします。

パスワードを入力します。

任意のAWSアカウントをクリックします。

Management Consoleをクリックします。

Federated loginされます。

CLI/APIでのアクセス

Command line or programatic accessをクリックする。

アクセスキー、シークレットアクセスキー、セッショントークンが払い出されます。

環境変数をコピーしてターミナルに貼り付けします。
SSMで接続するとセッションIDにメールアドレスが含まれるため、ログ上でどのユーザがログインしたか確認することが可能です。

38f9d34e90ab:~ atsum$ aws ssm start-session --target i-*************


Starting session with SessionId: ******@*******.co.jp-0a44213c1cd30b80f

複数のAWSアカウントを紐づけた状態

以下のように一覧表示されます。

お約束

投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。

前々から思っているんだけど、AWSの日本語ドキュメントってわかりにくいよね…。
AWS CLIを利用してたDynamoDBのfilterexpressionの使い方探してたんだけど、これでわかるのかな。

次の AWS CLI の例では Thread テーブルをスキャンして、特定のユーザーによって最後に投稿された項目のみを返します。

aws dynamodb scan \
     --table-name Thread \
     --filter-expression "LastPostedBy = :name" \
     --expression-attribute-values '{":name":{"S":"User A"}}'

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Scan.html

こんなこと言われてもねえ。TBL定義もわかんないし、何が何やら。勿論、英語版読めばいいんだろうけど。
それでもパッと検索して出てくる英語版ページでわかるかといわれるとやっぱりわからない。

[root@~]$ aws dynamodb scan --table-name server \
{
    "Count": 20, 
    "Items": [
        {
            "ID": {
                "N": "1"
            }, 
            "ip_address": {
                "S": "192.168.1.2"
            }, 
            "start_time": {
                "S": "2018-12-14 01:20:37"
            }, 
            "server_type": {
                "S": "online"
            }
        }, 
(省略)

例えば、↑のようなTBLでserver_typeをベースにfilterかけたいということであれば、↓だよね。

[root@~]$ aws dynamodb scan --table-name server \
>     --filter-expression "server_type = :name" \
>      --expression-attribute-values '{":name":{"S":"online"}}'

--filter-expression でserver_typeを定義。
:nameとして、別名を割り当て、それを--expression-attribute-valuesで引く、みたいな感じと思えばよい(はず)。

で、例えば、これをip_addressでフィルタリングかけたいとかであれば、jq使った方が楽なはず。応答項目をCLIでフィルタリングする方法がどうしてもわからなかった。

[root@~]$ aws dynamodb scan --table-name server \
>     --filter-expression "server_type = :name" \
>      --expression-attribute-values '{":name":{"S":"online"}}' \
>     | jq ".Items[].ip_address"
{
  "S": "192.168.1.2"
}
{
  "S": "192.168.1.5"
}
{
  "S": "192.168.11.1"
}
{
  "S": "192.168.11.10"
}

はじめに

アレクサスキル開発中に受け取ったスロットの検証をしたい場面があり調べました。

このインテントでは{option}スロットが必須の項目となっています。
ユーザーは【水】と【コップ】を頼むか、【水】だけ頼むかの選択肢があります。

{option}なしでインテントが呼び出された場合、アレクサは【コップ】も注文するか聞き返します。

スロットのバリエーションは以下です。
※ここに【コップ】も入っちゃてるのがイケてません。いい方法があればコメントください。。。

alexa developer consoleで検証ルールを設定したが。。。

テストしてみると、、、

２回想定外の回答をするとスキルが強制終了してしまいました。
今回のスキルではユーザーの正しい回答があるまで何度も聞き返してほしかったので困ります。

Lambdaで検証してユーザーに応答を促す

やっと本題です。
Alexa側の検証を外してしまい、Lambda側で検証を行います。

const OrderIntentHandler = {
  canHandle(handlerInput) {
    return handlerInput.requestEnvelope.request.type === 'IntentRequest'
      && handlerInput.requestEnvelope.request.intent.name === 'OrderIntent';
  },
  handle(handlerInput) {
    const { slots } = handlerInput.requestEnvelope.request.intent;

    if (slots.option.resolutions["resolutionsPerAuthority"][0]["status"]["code"] != 'ER_SUCCESS_MATCH') {
      return handlerInput.responseBuilder
        .speak('答えは「はい」か「いいえ」でお願いします。キャンセルする場合は「キャンセル」と言ってください。')
        .addElicitSlotDirective('option')
        .getResponse();
    }
    const option = slots.option.resolutions["resolutionsPerAuthority"][0]["values"][0]["value"]["id"];
    // 本来の処理は省略
    return handlerInput.responseBuilder
      .speak('ご注文を承りました。')
      .withShouldEndSession(true)
      .getResponse();
  }
};

まずslots.option.resolutions["resolutionsPerAuthority"][0]["status"]["code"] != 'ER_SUCCESS_MATCH'でスロットに入った単語が想定しているバリエーションの同義語かどうか判定します。
ユーザーに再度発話を促すには.addElicitSlotDirective('option')を呼び出します。
optionはスロット名です。

また、同義語でIDを設定している場合はslots.option.resolutions["resolutionsPerAuthority"][0]["values"][0]["value"]["id"]で一意のIDを取得できるのでいろいろな言い回しが想定される場合は便利です。

これで何度でもユーザーに発話を促すことができました！

おわりに

もっときれいな形がありそうですがとりあえずは実現したいことができました。
これからもっとガンガン触っていこうと思います。

詳細

ECSのコンテナ内で処理の重いs3 syncコマンドを発行
Cloudwatchログを確認したところ、終了メッセージ付近のログが欠ける現象が発生

原因

AWS側の障害(FARGATEの挙動)

AWS FARGATE タスクの終了時に終了直前付近のログがcloudwatchに送られない
※2019/03/05現在

対策

タスク内の処理終了前に 10 秒から 15 秒ほど sleep 処理を入れる
・・・らしい(AWS回答)ですけど、これは課金額があがるのでは・・・

０．はじめに

先日、こちらの記事の対応を行ったんですが、

• SSL 化済みの WordPress サイトに CloudFront を適用してみる - Qiita

S3 へ出力されたログを解析するのにいい方法が無いかと調べたところ、Athena で解析するのがいいみたいなので試してみました。

基本的には、以下のページの手順に従って進めました。

• Amazon CloudFront ログのクエリ - Amazon Athena

他にこちらの記事なども参考にさせて頂きました。

• Amazon Athena で Amazon CloudFront のアクセスログを分析する - Qiita
• Athenaを使ってS3のログを検索できるようにしたら運用コストが改善されたお話 - Qiita

こういった方々がノウハウをシェアして頂けることは、本当にありがたいですね♪

感謝!! ?‍♂️

１．S3 のログファイルのデータを Athena でテーブルを作成して入れ込む

1. Athena のコンソールを開きます。
   • Athena
2. 以下のクエリを実行して、テーブルを作成し、S3 のログファイルのデータを入れ込みます。
   • ※参考にしたサイトに記載されているクエリそのままです。S3 バケットを変えただけ。
   • 

CREATE EXTERNAL TABLE IF NOT EXISTS default.cloudfront_logs (
         `date` DATE,
         time STRING,
         location STRING,
         bytes BIGINT,
         requestip STRING,
         method STRING,
         host STRING,
         uri STRING,
         status INT,
         referrer STRING,
         useragent STRING,
         querystring STRING,
         cookie STRING,
         resulttype STRING,
         requestid STRING,
         hostheader STRING,
         requestprotocol STRING,
         requestbytes BIGINT,
         timetaken FLOAT,
         xforwardedfor STRING,
         sslprotocol STRING,
         sslcipher STRING,
         responseresulttype STRING,
         httpversion STRING,
         filestatus STRING,
         encryptedfields INT 
) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LOCATION 's3://[S3 のバケット名]/[CloudFront の Log Prefix]/' TBLPROPERTIES ( 'skip.header.line.count'='2' )

２．作成した Athena のテーブルへ、クエリを実行して必要なデータを抽出する

1. 以下の様なクエリを実行して、テーブルから必要なデータを抽出します。
   • 以下のクエリは、
     • [日付(YYYY-MM-DD)] より後の、　※画像では、2019-03-03
     • [URL パス] へのアクセスで、　※画像では、/portal/index.html
     • [IP アドレス] からのアクセス
   • となっています。
   • 

SELECT * FROM default.cloudfront_logs
WHERE date > date '[日付(YYYY-MM-DD)]'
AND uri = '[URL パス]'
AND requestip = '[IP アドレス]'

９９．ハマりポイント

• そこまでハマりはしませんでいたが…、
  
  
• クエリの WHERE 句の、DATE 条件がわからなくてちょっと困りました…。

ＸＸ．まとめ

CloudFront の導入で、運用や管理のやり方も変わってくるので、正直不安もありますが、こういったサービスがしっかりと用意されているのが、AWS の強みかと思います。

本当は、CloudWatch Logs に出力されると嬉しい気もしますが…、データ量が多すぎるとコスト量むし、このやり方がいい落としどころなのかもしれないですね。

何かご参考になれば嬉しいです!!

では♪

０．はじめに

先日、こちらの記事の対応を行ったんですが、

• SSL 化済みの WordPress サイトに CloudFront を適用してみる - Qiita

ちょっとしたトラブルが発生したので、シェア♪

９９．ハマりポイント

• ある Windows アプリで該当サイトのページを　Inline Frame で表示していたんですが、CloudFront 適用後にページへのアクセスが出来なくなってしまいました。
• 結構わからなくて色々調べたところ、アプリが TLS1.0 でアクセスしていた為に CloudFront で弾いていたので、以下の設定をしてアクセスできる様になりました。
  • Security Policy : TLSv1_2016
  • 
• ただ、先々 TLS1.0 や 1.1 を廃止して、TLS1.2 以上にしよう、という流れがあるみたいなので、アプリ側の対応を行い、CloudFront の再設定を行った方がいいみたいですね。
  • マイクロソフト、ブラウザーのTLS 1.0 / 1.1サポート終了へ。TLS 1.2以降への移行を推奨 - Engadget 日本版
  • 大手4社のWebブラウザ、2020年にTLS 1.0と1.1を無効化 - ITmedia エンタープライズ
  • 「Chrome」「Edge」「IE」「Firefox」「Safari」で TLS 1.0と1.1を2020年に無効化 - ZDNet Japan

ＸＸ．まとめ

今回は結構ハマって大変でした…。

新しいことをすると何かと問題が発生するには、世の常…。

少しでもご参考になれば幸いです!!

では♪

はじめに

「スマートスピーカーを遊びたおす会 Vol.5」

https://kotodama.connpass.com/event/120483/
呼んでいただいてありがとうございます。

Attention

本日のスライドはQiitaのスライドモードで作っており、説明の中で画面が下スクロールします。

---

本日のゴール

今日は時間も短いので、AIとAlexa って なんか楽しそうで、なんかできそうだなと思ってもらえることがゴールです。

---

Who are you?

Tomoharu Itoh（オランダ在住）
https://hugtech.io

• Alexa Champion.
• Assisted By Alexa Certified Skill Builder as Subject Matter Expert.

コミュニティ AAJUG(えーじゃぐ)
https://aajug.connpass.com/
（開発してるひともそうでないひとも、機会と話したいひと、みなさん Welcome です）

---

鯖を監視するに至った背景

• 海外在住だと日本食が恋しい。
• 幸いなことに毎週土曜、家の近くに市場が出て、新鮮なお魚が買える。
• １週間保存がきくように、干物にしておきたい。

---

そしてあいつがやってきた。

Version1 自作物干し機（ボール＋網）

流石に無防備すぎた。

Version2（オランダでよく見る自転車のカゴ）

匂いは防ぎようがなく、あいつがやってきた。

鯖の天敵

---

そして、うみねことの戦いが始まった。

---

鯖を安全に見守るために必要な課題を整理しよう

• 干してる間、カゴを見とくの辛い。
• あいつが来たら呼んで欲しい。
• ちょっと僕を焦らせて欲しい。（SNSで通知来るだけでは私は性格的にスルーする可能性がある）

---

実現できそうか考えてみよう。

1. そこにあったの。Deeplens。

AWSの提供するAIカメラ。あくまで初心者用。トレーニングすみのモデルが用意されているので、簡単にAIのパワーを体感できる。

もちろん、ラズパイとかObnizとか、サードパーティのマイコンにカメラくっつけて、オリジナルのモデルを動かしてもOKです。
（これはまた機会があれば、、、）

2. ころがるスマートスピーカーの山

焦らせてくれそうな声で話してくれれば、、、

3. ワタシAWSチョットデキル

AWS Lambdaでだいたいなんでもつながるでしょ。。

---

設計

アクティビティ図

使うもの的にはこう

---

さあ、作ってみよう。

Deeplens Object Detection Model

Deeplens にはすでに定義されたモデルがあります。Object Detectionモデルを使ってデプロイします。

証明書を入れ込んだりするのが多少面倒ですが、チュートリアルとドキュメントを読んでがんばりましょう。

MQTT

MQTTはデバイス間でメッセージを軽量にやり取りするサブスリプション型のしくみです。
Deeplensにプロジェクトがデプロイされると、MQTTのメッセージバッファ（トピックといいます）も勝手にデプロイされます。

鳥（ではないかもしれないが）を検知すると、以下のようなメッセージが飛びます。

{ bird: <percent of confidence> }


AWS IoT Rules

デプロイしたモデルはその他にも、Person（人間）とか、Dining（テーブル）とか、いろいろなものを通知してくるので、鳥だけフィルタしたいのです。そういうときには、AWS IoT Rules が使えます。

先ほどのメッセージをSQLクエリでフィルタできます。今回は 「８０％くらいの自信があって鳥だって言ってるなら」 と、設定しました。

そして、クエリにマッチした場合Lambda関数を呼ぶということも同じ画面でポチポチ設定できます。

AWS Lambda

AWS IoT Rules から呼ばれるLambda関数です。
後述のAlexa Proactive API をCallするコードです。Callするには、このAPIが許可されたスキルのClientIdとClientSecretが必要です。これは後述します。

コードはこちら
https://github.com/haruharuharuby/bird-detect-message-handler

Alexa Proactive API

Proactive APIは、定型句（スキーマといいます） をAlexaデバイスに通知できる機能です。

「荷物が届きました」 とか 「今日はXXXゴミの回収日です」 とか。

定義済みスキーマの一覧
https://developer.amazon.com/ja/docs/smapi/schemas-for-proactive-events.html

Proactive APIでは、通知をカスタマイズできないので、今回は 嵐 が来たことにします。

AMAZON.WeatherAlert.Activated

なければここからリクエストを送りましょう。みんなが希望していれば届くかもしれません。
https://alexa.uservoice.com/forums/906892-alexa-skills-developer-voice-and-vote

Alexa Skill

Alexa Skill で、Proactive API を使うように構成します。

Alexaのデベロッパーコンソールで、「アクセス権限」 のところに、ClientIdとClientSecretがあります。
前の章で出てきたLambdaのコードで利用します。

一回何かしらの情報取得を有効にしないとメッセージングの項目が出て来ないことがあります。

Skill Manifest

通知は、SkillのマニフェストにPermissionブロックとEventsブロックを記載して、許可してあげる必要があります。

後日談として、当初 AWS CodeStarというサービスの中にAlexa Skillのテンプレートがあり、それでスキルを作ろうとしていたのですが、Manifest がデプロイされないので、やむなくASK CLIでやっています）

Note:
JAWS DAYS 2019 において 「CodeStarでアレクサ スキルでTwillioで電話かけてお金を払わせる」 ハンズオンの資料があります。 CodeStarに興味があればどうぞ。
https://qiita.com/motchi0214/items/a95335679ee7e9d0b660

Alexa App

Alexa の DeveloperConsoleでの作業を終えて、Skillをデプロイして、Alexa Appを見ると、「設定」→「通知」のところに該当するスキルが出てきます。　通知を有効にします。 （開発中だったので、名前がhello nodeになってます）

モバイルアプリでは、画面遷移しないことがあります。そのときは、Webブラウザからアクセスします。

スキルで通知を許可

最後にスキル側でも、通知を許可します。（開発中だったので、名前がhello nodeになってます）

コードはこちら
https://github.com/haruharuharuby/server-room

---

実際の映像はこちら

https://www.youtube.com/watch?v=LAIqYFEcx1E

テストように、フィルタのパラメータを以下としています。

select person from '<<topic-filter>>' where person > 0.400

実際はこうです。

select bird from '<<topic-filter>>' where bird > 0.800

英語で試していますが、もちろん日本語でもできます。

---

Alexa Day 2019

それでは４月６日に神戸でお会いしましょう！（ちがうって）
https://alexaday2019.aajug.jp/

---

ありがとうございました！

タイトルの通りです。

恒例（？）のmysqlslapをやってみました。

※前回（R4）の結果はこちらです。

• 「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap）

mysqlslapの内容（前回までと同じです）

mysqlslap

$ mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u 【ユーザ名】 -h 【クラスタエンドポイント】 -p

結果

いずれも暗号化あり、です。

なお、今回のテストで、バイナリログの有無が性能に（ほぼ）影響を与えなくなっていることを確認しましたので、結果はバイナリログなしのものを掲示します。

また、MySQL 5.7 互換版については、テストを行った時点で最新のバージョン 2.03.4 では R5 インスタンスの選択ができませんでしたので、1 つ前のバージョン 2.03.3 で試しています。

バージョン	R4 / R5	large	xlarge	2xlarge
5.6(1.19.0)	R4	55.466	40.199	28.859
5.6(1.19.0)	R5	42.397	26.761	24.254
5.7(2.03.3)	R5	41.895	27.040	22.964

単位は秒です。

全体的に伸びています。特に xlarge の伸びが大きいようです。2xlarge ではそれほどでもありませんが、これは必ずしも「大きなインスタンスほど性能の伸び率が小さい」ということではなく、負荷の掛け方の問題（＝インスタンスのサイズに対して十分な負荷を掛けていない）の可能性があります（すみません、前回までと合わせているもので…）。

5.6 互換版と 5.7 互換版の差は誤差の範囲のようです。

※前回の結果と比較すると、R4 の性能が若干落ちています。前回の結果をベースにして R5 と比較すると、large・xlarge は伸び率がさほど変わらず、2xlarge は R4・R5 の結果がほぼ同じ、となります（必ずしも性能向上していないことを示すものではない、というのは前述の通りです）。

おわりに

EC2 と違って R4 と同額ですが、性能は向上していますので、乗り換えメリットはありそうです。

なお、このタイミングで R5 インスタンスとともに T3 インスタンスにも対応したようです（ちなみに CPU クレジットについて無制限モードも利用できる模様）。

---

• Qiitaに投稿したAmazon Aurora関連記事

はじめに

各社によって IAM ユーザの発行とクレデンシャルの付与については色々なフローがあると思いますが、「極力インフラ側で初期パスワードの受け渡しなどを行いたくない(面倒だし)」という場合は、 IAM Role 上で初期パスワードの設定を有効にしておき、実際の各ユーザには AWS CLI 経由で初期パスワードの有効化を行ってもらいたいということがあります。
その手順になります。

クレデンシャルの設定

• aws-cli を導入してください。 Python の実行環境さえあれば pip install awscli で入ります。
• aws-cli に、発行された IAM User のクレデンシャル情報を設定しましょう。 aws configure コマンドを実行すれば、対話的にアクセスキーやシークレットキーを設定する事が出来ます。オプション無しだと default というプロファイルに保存されますし、他のクレデンシャルも保持したい場合は aws configure --profile <任意のプロファイル名> を実行すると、異なるプロファイルとしてクレデンシャルを保持してくれます。

$ aws configure --profile helloaws
AWS Access Key ID [None]: <アクセスキーID>
AWS Secret Access Key [None]: <シークレットキー>
Default region name [None]: ap-northeast-1
Default output format [None]: None

• 複数の IAM User を使う必要がある人は、ここで ~/.aws 以下を Git で管理することををおすすめします。決してパブリックなリポジトリに push してはいけません。
• AWS CLI 経由でコンソールログイン用の初期パスワードを入力してください、

$ aws iam --profile helloaws create-login-profile --user-name <IAMのユーザ名> --password <32文字以上のパスワード> --password-reset-required

• AWS のログイン画面から、<組織ID> と <IAMのユーザ名> と <任意の初期パスワード> を入力してログインしてください。再度パスワードの再設定を求められるので、極めてセキュアなパスワードを設定してください。

• (推奨)AWS IAM の画面に訪れて、 自分の IAM User を選び、二段階認証の設定をしてください。

以上です。何も難しいことはありませんね

各人に配布されたクレデンシャルの扱いについては、慎重を期しましょう！