AWS LambdaとAPIGatewayのミニマム構築

サーバレスでweb apiを構築できるLambdaとAPIGateway。
これをミニマムな構成で構築してみる

とはいえ認証もなにもない状態だとアレなのでAPI keyを発行した認証は実装する

Lambda

aws consoleからLambdaに入り、Node.jsの6.10を選択、Blank Functionを選択

今回はNodeを選択しているけど、もちろんPythonでもいい

Kobito.XZSrgA.png

ひとまずトリガーはとりあえず作らないで次へ

Kobito.FgA1X1.png

Lambdaの名前を入力し、コードを入力する。
今回はコードはデフォルトのままで進める。

Kobito.R1y4r2.png

スクロールするとさらに設定画面が出てくる
ロール割当だけすれば最小限OK

Kobito.1G5h7o.png

これでLambda関数の作成はOK

API Gateway

APIを定義

aws consoleからAPI gatewayを開く

新しいAPI を選択し、適当な名前を入力

Kobito.46WF6B.png

リソース -> アクション -> メソッドの作成を選択

Kobito.hdwTH2.png

メソッドにPOSTを追加し、Lambda関数を追加する

Kobito.qTpcmT.png

なんかフローみたいのが出てくる。

メソッドリクエストを選択

Kobito.HPvhHq.png

APIキーの必要性にtrueを設定

Kobito.ZD35fr.png

アクション -> デプロイを選択

デプロイするステージを選択(なければ作る)してデプロイ実行

Kobito.tepBZg.png

APIキーの作成

APIキーを選択 -> アクション -> APIキーの作成

Kobito.ilVIPU.png

APIキーの名前、説明を入力。
対象のAPIとステージも一緒に選択。
ここでランダムな文字列のAPIキーが発行されるのでメモしておく(API実行時に必要になる)

Kobito.Xsx7CS.png

使用プランの作成

使用プランを選択 -> 作成を選択

適当な値を入力して使用プランを作成

Kobito.0kronG.png

使用プランにAPIキーを割り当てる
作成したAPIキーをセットする

Kobito.3S94mx.png

実行テスト

postman等からAPIのURLを叩く

headerに x-api-key という名前でAPIkeyを設定すると認証が通り、実行される(はず)

Kobito.IGiR2w.png

続きを読む

AWS独学メモ

頑張って学んでいきます。

サービス俯瞰

コンピューティング関連

サービス名 概要
EC2 仮想サーバー
EC2 Container Service Doker(アプリ実行環境構築ツール)運用サービス
EC2 Container Regstry Dokerイメージ保存・共有サービス。
Elastic Beanstalk .NET/PHP/Python/Ruby/Node.jsアプリを自動でAWSにデプロイ。
Lambda クライアントからのリクエスト発生時に任意プログラミング起動。イベント駆動型サービス。
Auto Scaling CPU使用率等、事前決定条件に応じ、EC2インスタンス増減
Elastic Load Balancing トラフィックに応じ、複数EC2インスタンスに負荷分散

ストレージ・コンテンツ配信

サービス名 概要
S3 ファイルサーバ。画像格納したり。
CloudFront コンテンツ配信ネットワーク。利用者から近い場所から効率よく配信
EBS EC2データを保持するストレージ。EC2のHDD,SSDのような役割。
Elastic File System EC2共有ファイルストレージ
Glacier 低価格ストレージ。仕様頻度低いけど長期保存のバックアップ用。
Import / Export Snowball ペタバイト級の大容量転送サービス。
Storage Gateway オンプレミスとAWSを接続

DB関連

サービス名 概要
RDS DB(MySQL/Oracle/SQL Server/PostgreSQL/Aurora)が利用できる
Database Migration Service 最小限停止時間でDBを移行。オンプレミスのDBサーバからの移行等に用いる
DynamoDB NoSQLデータベスサービス構築/運用。
ElastiCache クラウドでのメモり内キャッシュの管理サービス
Redshift ビッグデータを分析

ネットワーク

サービス名 概要
VPC プライベートネットワーク構築サービス。
Direct Connect オンプレミスのネットワークとAWSのVPCネットワークを直接接続。
Route 53 DNS(ドメイン名とIPアドレスを対応)

開発者用ツール

サービス名 概要
CodeCommit プライベートGit
CodeDeploy 開発アプリを実行環境に自動配置
CodePipeline 継続的デリバリ使用したアプリのリリース

開発ツール

サービス名 概要
CloudWatch AWSリソース監視サービス
CloudFormation テンプレート利用したリソースの作成と管理
CloudTrail ユーザアクティビティとAPI使用状況確認
Config リソースのイベントリ変更の追跡
OpsWorks Chef利用し操作の自動化
Service Catalog 標準化製品の作成と使用
Trusted Advisor パフォーマンスとせきゅりてぃの最適化

セキュリティ

サービス名 概要
IAM AWS認証
Directory Service Active Directoryのホスティングと管理
Inspector アプリのセキュリティ分析
CloudHSM 暗号鍵管理の専用ハードウェア
Key Management Service 暗号鍵作成と管理
WAF 攻撃から保護するファイアウォール

分析

サービス名 概要
EMR Hadoopフレームワーク
Data Pipeline オーケストレーションサービス
Kinesis リアルタイムストリーミングデータとの連携
Machine Learning 機械学習
QuickSight 高速ビジネスインテリジェンスサービス

モバイルサービス

サービス名 概要
Mobile Hub モバイルアプリの構築/テスト/監視
API Gateway RESTful APIの構築/管理
Cofnito ユーザID及びアプリデータの同期
Device Farm iOS/Android/FireOSアプリのテスト
Mobile Analytics アプリ分析の収集/表示/エクスポート
Mobile SDK モバイルソフトウェアの開発キット

アプリケーションサービス

サービス名 概要
AppStream ストリーミングサービス
CloudSearch マネージド型検索サービス
Elastic Transcorder メディアと動画変換
SES Eメール送受信
SNS プッシュ通知サービス
SQS メッセージキューサービス
SWF アプリ同士を連携ワークフローサービス

大企業向け

サービス名 概要
WorkSpaces クラウド上仮想デスクトップパソコンサービス
WorkMail セキュリティ保護、企業向けEメール及びカレンダー
WorkDocs ファイル共有サービス

S3について

用語

用語 意味
バケット データの入れ物
オブジェクト 格納ファイル

ステップ

  1. バケット作成
  2. オブジェクト格納

EC2について

用語

用語 意味
EC2 仮想サーバ。オンプレミスのWindowsサーバやUNIXサーバに相当。
インスタンス 1台の仮想サーバ
EBS(Elastic Block Store) サーバのHDDに相当する仮想ディスク
AMI(Amazon Machine Image) サーバにインストールするOSやミドルウェアやアプリのイメージ。新インスタンスを複数生成時、AMIを利用。
yum パッケージ管理システム
scp(secure copy) SSH機能を用いて、安全にファイル転送する

EC2にSSH接続した

参考ページ1
参考ページ2

ミドルウェアをインストール

yum更新
$ sudo yum -y update
httpdインストール
$ sudo yum  install -y httpd
httpd起動
$ sudo service httpd start
httpd自動起動を確認
$ sudo chkconfig --list httpd
httpd自動起動を設定
$ sudo chkconfig  httpd on
$ sudo chkconfig  httpd off

scp(コンテンツをアップロードする)

【現在ここで躓き中!】
→ 突破!!

参考ページ1

HTTPコンテンツをコピー

HTTPコンテンツのコピー

$ sudo cp /home/ec2-user/index.html /var/www/html/

【現在ここで躓き中!】index.htmlへアクセスできない

続きを読む

Amazon API Gateway+Cognito+JavaScriptでちょっと気をつけること

(2017.6.23現在の情報です)
Amazon API Gatewayを、cognito認証で使うときの注意点です。

リソース設定後、ステージから「SDKの生成」を選ぶことができます。
ただ、このSDK、Cognito認証を想定してないっぽいです。
(認証なし=NONEか、AWS_IAMの認証しか想定してない)

Cognitoで認証する場合、こんな感じです。
※すでにサインイン済みの想定です。

sample.js
AWS.config.region = 'ap-northeast-1'; // Region

var poolData = { UserPoolId: 'ap-northeast-1_xxxxxxxx',
              ClientId: 'xxxxxxx'
};

var userPool = new AWSCognito.CognitoIdentityServiceProvider.CognitoUserPool(poolData);

if (cognitoUser != null) {
    cognitoUser.getSession(function(err, sessresult) {
         if (sessresult) {
             var idToken = sessresult.getIdToken().getJwtToken();

             var apigClient = apigClientFactory.newClient ();

             var params = {};//必要なら設定
             var body = {};//必要なら設定
             var additionalParams = {
                 headers: {
                    Authorization:idToken //ここが大事
                 }
             }

             apigClient.methodName(params, body, additionalParams)
             .then(function(result){
                  //成功
             }).catch( function(result){
                  //失敗
             });
         }

    });
}


ヘッダーにちゃんとIDトークンを入れるってだけですが。。。
わかんなかったので書いておきます。

最初、IAMのほうの設定の問題かなぁ。。。とか思って色々やってたけど、
そっちはとくに関係なさそうでした。
cognitoとても便利だけど、ちょっとまだ追いついてない感じもしました。

README.mdに書いといて欲しいな。

続きを読む

IAMでクロスアカウントスイッチロール設定メモ

軽くテストしたので個人的な備忘録です。

★クロスアカウントスイッチロールすると嬉しいこと

複数のAWSアカウント間を認証画面介さず行き来できる
個人用IAMアカウント作るのは一か所でよくアカウント毎でなくなる
SDKつかってるような一部のツールではスイッチできないものもあるがawscliくらいならスイッチロールでいける
スイッチ先で権限を限定してスイッチ元でアカウントの増減を制御できるので
別会社間のメンバーの増減のアカウント管理のやり取りが生じなくてたぶんべんり

アカウント番号はサポート画面の右上に出てる。

★参考

Swith Roleで複数のAWSアカウント間を切替える – Qiita
超簡単!今すぐ使える「クロスアカウントアクセス」 | Developers.IO
AWS Black Belt Techシリーズ AWS IAM
【小ネタ】複数のSwitch Roleでのクロスアカウントアクセスをブラウザのブックマークで管理する | Developers.IO

一番したのやつ履歴が5こくらいまでできえることに憤慨している人は幸せになれそう。

★実際のクロスアカウントスイッチロール実装手順の簡易なメモ

0.テストするアカウントを2つようい

アカウント1
※スイッチ元
Account Number 1234zzzzzzzz

アカウント2
※スイッチ先
アカウント番号 5678xxxxxxxx

1.スイッチ先でロールを作成する

※お客様先にスイッチする場合お客様作業

IAMサービスを選択してロールを作る

新しいロールの作成
 >ロールの選択(クロスアカウントアクセスのロールで外部IDの使用を許可しないほうを選択)
  (※外部ID許可とはldapやadなどのIAMクレデンシャルでないID連携を許可するものと思われ)
  >このアカウントにアクセスできる IAM ユーザーの AWS アカウントの ID を入力(スイッチ元のIDを入力)
   (MFAが必要にチェックはデバイスやアプリの用意が可能な場合に入れる)
   >ポリシーのアタッチ(既存から選ぶのでカスタムにしたいならあらかじめ調べておく)
    (とりあえず試験用なので適当な権限にする(arn:aws:iam::aws:policy/AdministratorAccess ))
    >ロール名を入力:mygroup-admin

2.スイッチ元でロールを設定する

とりあえずユーザとグループを作る

グループ:mygroup
ユーザ:とりあえず二人くらいを作成

グループのインラインポリシーを作成しスイッチ先のアカウントとロールを設定する
ポリシー名:switch-to-otheraccount-name

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::5678xxxxxxxx:role/mygroup-admin"
  }
}

3.スイッチ元で自分のユーザで入りなおしてから右上からスイッチロールを選択してスイッチする

アカウント:5678xxxxxxxx
ロール:mygroup-admin

お客様先にスイッチする場合、
・スイッチ元のアカウントIDをお伝えする
・作成したロール名とわたる先のアカウント名とアカウントIDを聞いて設定
・スイッチロールしてみる
・スイッチ履歴は5個くらいしか残らないので便利なリンクを作っておく

ということになります。

★証跡を追えるようにするためにスイッチ元でCloudTrailの設定

見た感じすでに設定済みな模様でござったのでリンク先をどうぞ。S3もみたところ数年前からログがあった。
Amazon Web Services ブログ: 【AWS発表】 AWS CloudTrail – AWS APIコールの記録を保存
AWSの操作履歴を記録するCloudTrailを試してみた « サーバーワークス エンジニアブログ

★アカウントのエイリアスの設定

あんまり関係ないがIDだと視認性が微妙なので設定したほうがよさそう(なくてもいい)

AWS アカウント ID とその別名 – AWS Identity and Access Management

変えたたらサブドメインがアカウント番号からエイリアス名になる(アカウント番号でもアクセスできるまま)
https://my-alias.signin.aws.amazon.com/console

★アカウント設定(パスワードポリシー)

ISMS的なアレ(または顧客要望)にのっとって適宜。
Account settingsから実施。

Minimum password length: x(x文字を要する)
Require at least one non-alphanumeric character(記号を要する)
Allow users to change their own password (自分で更新する)
Enable password expiration
Password expiration period (in days): xx(xx(日)で期限がきれる)

★ルートアカウントでアクセスしない

スイッチロールの設定時にrootアカウントにアクセスできるように設定しなければ
メニューにスイッチロールでないので物理的にルートアカウントにアクセスは不可能。
クラスメソッドのリンクが詳しい(rootでも設定するといけるけどやらないほうがいい))
単に運用上パスワード変えて限定共有する、クレデンシャル無効化する、MFAデバイス用意等。
あとCloudTrail的に個人IAMで操作したほうが証跡が追いやすい。

★クレデンシャルの書き方

たぶん以下のようになる。

[account2]
role_arn = arn:aws:iam::5678xxxxxxxx:role/mygroup-admin
source_profile = account1
region=us-xxxx-x

★スイッチロールのポリシーアタッチされてるグループにいるユーザをcliでだす

$ aws iam get-group --group-name mygroup --profile account1|jq -c -r '.Users[].UserName'

以上

続きを読む

Amazon Elasticsearch Serviceでcluster_block_exceptionがでたら

症状

こんなエラー。
読み込みは出来るが、書き込みやインデックス作成は全て失敗するようになる。

"error": {
  "type": "cluster_block_exception",
  "reason": "blocked by: [FORBIDDEN/8/index write (api)];"
}
"error": {
  "type": "index_create_block_exception",
  "reason": "blocked by: [FORBIDDEN/10/cluster create-index blocked (api)];"
}

原因と対策

原因は主に2つある模様。

ディスク容量不足

AmazonESのメトリックスでFreeStorageSpaceを見ると0になっているはず。
インスタンスタイプかEBSの容量を上げればいいはず。

Amazon ES ドメインの設定 – AmazonES 開発者ガイド
EBS ベースのストレージの設定 – AmazonES 開発者ガイド

メモリ容量不足

AmazonESのメトリックスでJVMMemoryPressureが92%を超えているはず。
超えているというか92%をキープしている。

スクリーンショット 2017-06-20 14.35.10.png

t2特有の現象というわけでなく他のインスタンスタイプでも同じことが起きたので、単純にスケールアップしてメモリ増やせということだと思う。
この状態でもClusterHealthは青いままなので要注意。
JVMMemoryPressureは監視対象にしたほうがよさそう。

参考

AWS サービスエラー処理 – AmazonES 開発者ガイド
elasticsearchを利用するときは容量を管理しようという話 – Qiita

続きを読む

転ばぬ先のAWSセキュリティ

サービスが大きくなればなるほど、セキュリティは重要になってくる


じゃあ最初から強固なものにしよう


  1. 強固なパスワード
  2. グループメール
  3. MFA(多要素認証)
  4. ルートアカウントのアクセスキーは使わない
  5. CloudTrail有効化
  6. git-secrets導入
  7. IAMユーザー、グループ、ロール

■ 参考
AWSリソースについてセキュリティベストプラクティスに従った設定をしよう!
git-secretsでAWSの不正利用を防ぐ


  1. 強固なパスワード
  2. グループメール
  3. MFA(多要素認証)
  4. ルートアカウントのアクセスキーは使わない
  5. CloudTrail有効化 ← これ
  6. git-secrets導入 ← これ
  7. IAMユーザー、グループ、ロール ← これ

これの部分を今日は話します


CloudTrail

AWSの操作履歴がすべて取得できるようになる戦犯発見サービス。
グラフとかにもできるっぽい。ログはS3に保存される。

■ 参考
TrailDashでCloudTrailを可視化する


git-secrets

リポジトリにアクセスキーなどが混入しないようにするためのAWS謹製Gitプラグイン。
アクセスキーやシークレットキーはgit管理すんなよというAWSからのお達し。


使い方(インストール)

$ brew update
$ brew install git-secrets

使い方(設定)

  1. gitconfigにアクセスキーの標準パターンを登録
    => これだけだと無効なまま。一応ファイル内のスキャンはできる
  2. gitコミット時のhookに設定
  3. 例外があれば設定

具体的な設定方法はこちらの記事が参考になります


IAMユーザー、グループ、ロール


Identity and Access Management


それぞれの役割

  • ユーザー

    • コンソールサインイン、APIまたはCLIのリクエストを行うのに使用
  • グループ
    • ユーザーの集合。グループに属するユーザーに一括で権限付与できる
  • ロール
    • 特定タスクに応じてユーザーやサービスに権限付与できるもの
    • 認証情報(アクセスキー等)は関連付けられない

問題

IAMロールのユースケースをひとつあげてください


  • EC2インスタンスから他のAWSサービスにアクセスする必要がある時に権限を与えるためアタッチする

■ 参考
Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス権限を付与する


  • ルートアカウントだと権限が強すぎるので、必ずIAMユーザーを作成して適切な権限を付与
  • アクセスキーはできるだけ作成せず、IAMロールで利用することを推奨

しましょう


さらにIAMのベストプラクティスを知りたい場合はこちらへどうぞ

IAM のベストプラクティス


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

続きを読む