20191004のAWSに関する記事は13件です。

投稿日：2019-10-04T23:53:40+09:00

【AWS KMS】ローカル・lambda上で、それぞれKMSを用いてencrypt&decryptを行う

【AWS KMS】ローカル・lambda上で、それぞれKMSを用いてencrypt&decryptを行う

AWS初心者で既存のlambdaプロジェクトに入り、コード改変を行う必要が出てきた。
aws-cliもよくわからん状態で色々やってみたので、その備忘録的。

KMSって何？？

Key Management Service.
暗号化がスムーズにできるやつ。

ローカルでencrypt&decrypt

encryptするためのkeyIdを取得
command
$ aws list-aliases | grep -1 "<使いたい鍵のalias>"
<使いたい鍵のalias>を含む前後1行が表示される。
result
{
    "AliasName": "alias/<使いたい鍵のalias>",
    "AliasArn": "arn:aws:kms:ap-northeast-1:***********:alias/<使いたい鍵のalias>",
    "TargetKeyId": "~~~~~~~~~~~~~~~~~~~~~~~~~"
変数に結果を格納

上記の結果のうち、AliasArnかTargetKeyIdのいずれかを環境変数に格納する。　
command
# AliasArn
$ export KEYID=arn:aws:kms:ap-northeast-1:***********:alias/<使いたい鍵のalias> 

# TargetKeyId
$ export KEYID=arn:aws:kms:ap-northeast-1:***********:key/~~~~~~~~~~~~~~~~~~~~~~~~~ 
KeyIdを用いてencrypt
command
aws kms encrypt --key-id $KEYID --plaintext 'password'
result
{
  "CiphertextBlob": "AQICAHhPD3PY32D6FMhjkfVLRA+NeKc4i9PzZnuvVW+gVfdbZgH91eCL1o/eTMdUI4KM2NSIAAAAZzBlBgkqhkiG9w0BBwagWDBWAgEAMFEGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQM7yY+K+tyCS+dwvwWAgEQgCSpZgm/KnrB7KeVQw3eqCYBlJP/hxUt5/q6J3eIaBe+/IRvx5k=",
  "KeyId": "arn:aws:kms:ap-northeast-1:351540792571:key/13dc2c62-05fa-425e-9910-3fb450610d93"
}
結果からわかるように、encryptされた文字列とその際に用いたKeyIDが出力される。
このencryptされた文字列だけを取り出し、base64デコードしてファイルに保存する。
command
aws kms encrypt --key-id $KEYID --plaintext 'password' --query CiphertextBlob --output text | base64 --decode> encrypted.txt
バイナリファイルになってる。
encrypted.txt
0102 0200 784f 0f73 d8df 60fa 14c8 6391
f54b 440f 8d78 a738 8bd3 f366 7baf 556f
a055 f75b 6601 31d8 9d55 e417 1e8e 0e0d
d04b d4cb 9524 0000 0067 3065 0609 2a86
4886 f70d 0107 06a0 5830 5602 0100 3051
0609 2a86 4886 f70d 0107 0130 1e06 0960
8648 0165 0304 012e 3011 040c a991 30c4
8984 f22c 1912 f3aa 0201 1080 24ac 20a7
5d08 b799 ac6b 2d09 7f42 5f9c 287e ae93
f9ac b7e2 6298 cdf9 fb58 9824 1a1a 3c49
c5
decrypt
command
aws kms decrypt --ciphertext-blob fileb://encrypted.txt
result
{
    "KeyId": "arn:aws:kms:ap-northeast-1:***********:key/~~~~~~~~~~~~~~~~~~~~~~~~~",
    "Plaintext": "cGFzc3dvcmQK"
}
decryptした結果として返されるPlaintestはbase64でエンコードされているので、base64でデコードして表示させると、
command
aws kms decrypt --ciphertext-blob fileb://encrypted.txt --query Plaintext --output text | base64 --decode
result
password
元に戻った。

リモートからlambda上で、encrypt&decrypt

環境変数を設定
command
$ aws lambda update-function-configuration --function-name <関数名> --environment Variables={ORIGIN='password'}
encryptするためのkeyIdを取得
command
$ aws list-aliases | grep -1 "<使いたい鍵のalias>"
<使いたい鍵のalias>を含む前後1行が表示される。
result
{
    "AliasName": "alias/<使いたい鍵のalias>",
    "AliasArn": "arn:aws:kms:ap-northeast-1:***********:alias/<使いたい鍵のalias>",
    "TargetKeyId": "~~~~~~~~~~~~~~~~~~~~~~~~~"
encrypt&decrypt
lambda_function.py
import os

# for decryption
from base64 import b64decode
import boto3

ORIGIN = os.environ.get('ORIGIN')
# ここに、さっきのkeyId情報を入力
KeyId = 'arn:aws:kms:ap-northeast-1:***********:alias/<使いたい鍵のalias> '
kms = boto3.client('kms')
ENCRIPTED = kms.encrypt(KeyId=KeyId,Plaintext=ORIGIN)['CiphertextBlob']

def lambda_handler(event, context):
    print("--------------------------------------------------------")

    print('origin = ' + ORIGIN)
    ENCRIPTED = base64.b64encode(ENCRIPTED).decode('utf-8')
    print('enc='+ENCRIPTED)

    dec = kms.decrypt(CiphertextBlob = b64decode(ENCRYPTED))['Plaintext']
    print('dec = ' + dec) 
command
$ zip lambda-function.py.zip lambda-function.py
$ aws lambda update-function-code --function-name <関数名> --zip-file fileb://lambda-function.py.zip
lambda上で、testを実行。きちんと表示されれば成功

参考記事

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T22:05:56+09:00

【AWS lambda】update-function-configurationしようとして謎のエラーに焦った話

環境変数を指定しようとして
$ aws lambda update-function-configuration --function-name <関数名> --environment Variables={Key1=value1,Key2=Value2}
このコマンドを使おうとしたら、次のエラーが。
Unknown options : Variables=Key2=Value2
aws cliでは複数の環境変数の設定ができないのか....！！
と焦ったのですが、
ってか、カンマが正しく認識されていない.....???
そこでカンマの前にバックスラッシュを入れたらエラーが出ずに通りました。
何故かはわからないけど、役にたつかもしれないお話。
$ aws lambda update-function-configuration --function-name <関数名> --environment Variables={Key1=value1\,Key2=Value2}

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T19:41:20+09:00

【AWS IAM】グループ、ユーザー、ロール、ポリシーの関係性の理解

【AWS IAM】グループ、ユーザー、ロール、ポリシーの関係性の理解

はじめに

初めてAWSを触るのですが、自分に与えられたユーザーがどういう権限を持っていて何ができて、みたいなことがわからずあたふたしているので、とりあえず概念を勉強して行こうかなと思い、調べた結果を自分の言葉でまとめてみました。

そもそもAWS IAMとは

AWS Identity and Access Management, 通称IAM。

そもそもAWSには、二つのアカウントが存在する。

・AWSアカウント
- ルートアカウントで、最強のアカウント。
- 全てのサービスを操作(起動/削除/変更etc...)出来る。
- 取扱に注意が必要。
- 普段からの利用は極力避ける。

・IAMアカウント
- マネジメントコンソール上で操作する時、APIで操作する時に使うアカウント。
- IMAアカウントは、それ毎に細かくどのサービスをどの程度設定出来るかを定義することが出来る.

IAMは、AWS上のサービスを使う際における、AWSアカウントを直接使う代わりの、ユーザー認証・許可の制御サービス。

AWS IAMの機能　　

機能に関しては、とりあえずこの二つ理解してればいいかなぁって。

・AWSアカウントへの共有アクセス
パスワードやアクセスキーを共有しなくても、AWSアカウントリソースの管理・利用のためのアクセス許可を他者に付与できる。

・詳細なアクセス権限
リソースごとに、ユーザーごとに、さまざまなアクセス権限を付与できる。例えば、このIAMユーザーはこのサービスの管理画面は入れるけどこっちはだめ、見るだけならオッケー、みたいな。

要は開発側のユーザー権限の管理が簡単にできちゃうよってことだと思う。

使っていてよくわからなかった概念

使っていて混乱したことをまとめます。

とりあえず、関係性を図にすると、こんな感じ。

ユーザー

AWSを利用するユーザー。
ユーザーには、（複数の）ポリシーが適用される。
ユーザーは0個以上のグループに所属することができる。
所属するグループのポリシーは、ユーザーに引き継がれる。

グループ

似た性質をもつユーザをまとめたグループ。
グループには、（複数の）ポリシーを適用される。
グループに適用されたポリシーは、グループに所属するユーザーにも引き継がれる。

ポリシー

サービスへのアクセス権を管理するもの。
AWSの多様なサービスとそれに対する動作（アクション）に対して、3つのルールに基づいて許可するかどうかをポリシーとしてまとめる。

　　Action - どのサービス
　　Resource - どういう機能の範囲を(起動/削除/変更etc...)
　　Effect - 許可 or 拒否

このポリシーには2種類ある。
　　・AWS Managed Policies　：　AWSが最初から設定しているポリシー
　　・Customer Managed Policies　：　ユーザが独自に作成したポリシー
　

ロール

AWSのリソースの、他のリソースへのアクセス権を管理するもの。
ロールには、(複数の)IAMポリシーが適用される。
一つのリソースには、一つのロールが付与される。

例えば、あるEC2には一つだけIAMロールが付与出来るが、そのロールに様々なポリシーを付与する事で、そのEC2は様々なAWSリソースにアクセスする事が出来るようになる。
(AWSCliコマンドから、S3バケットにアクセスしたり、Lambdaを実行したり出来る。)

ロールは、ユーザーにも付与することがあるらしいが、よくわからなかったので割愛。

参考サイト

これ読んで全部理解できればいいんだろうなぁ
AWSドキュメント：IAMとは

まとまっていてわかりやすかった
qiita : Amazon AWSのIAMのPolicy、Roleの理解

概念の話というよりは手順の話だったけど、いざ使うってなったら参考になりそうな
qiita : GWも明けたし、AWSのIAMについてちゃんと理解しとく

もうちょっと勉強してから読み直したい
qiita : 【AWS】IAMまとめ

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T17:57:11+09:00

AWS DevDay TOKYO 2019 day1 参加レポと個人的な感想

（株）いい生活サーバープラットフォームチームの多田 (@es-y-tada)です。
サーバサイドエンジニアとして、 EKS を基盤とした新規APIの開発・運用を行っています。
今回は先日行われた
AWS DevDay Tokyo 2019 の1日目に参加させていただいたので、
個人的に印象的だったセッションのいくつかについてレポートします。

第一回AWSFargate簡単デプロイ選手権

原康紘（アマゾンウェブサービスジャパン株式会社）

https://aws-seminar.smktg.jp/public/session/view/215)

概要

本セッションは、AWS のオフィシャルツールを筆頭に、各種 OSS を使った Fargate へのコンテナのデプロイを考察し、みなさまの探究心をくすぐることをゴールとしています。

コンテナに限らず、デプロイに関わるツールを選定するとき、人々は以下のようなことを考慮・検討します。

簡単に利用できること

既存の開発・運用ワークフローやツール群とマッチすること

デプロイの仕組みを作り込む際に、必要十分なカスタマイズ性があること

その上で、利用シーンもツールの選定に影響を与えます

単にテスト的にコンテナをデプロイしたいのか、それともプロダクション環境に継続的にデプロイすることを前提としているのか

Web サーバーのような常駐プロセスをデプロイしたいのか、単発のジョブを実行したいのか

誰(人間、CDサーバー)がデプロイを実行するのか

噛めば噛むほど味の出るデプロイメントの世界に本セッションを通して一緒に飛び込みましょう！

期待

私自身は普段は Kubernetes (EKS) をメインに利用していますが、弊社内では AWS Fargate を活用しているサービス¹もあり、良し悪しについて度々疑問に思うことがあります。

「簡単」とよく聞く AWS Fargate 、もう一度学び直してみたいと思い（また、現在の動向知りたいと思い）聴講しました。

内容メモ

なぜ AWS Fargate なのか

ECS の場合を想像してみる

EC2 でコンテナを運用する場合、 EC2 の運用業務が発生する

ISやエージェントのパッチ当て・更新

コンテナ・ホストマシンのリソース最適化・スケーリング

この部分の運用コストが二重化してしまっている

運用業務は企業競争力に必ずしも繋がらない。どの会社でも当たり前にやっていることだから

AWS Fargate

仮想マシンを意識する必要がなくなる

コンテナを仮想マシンと同じレイヤの実体として扱える

ex. VPC の CIDR や SecurityGroup を直接コンテナにアタッチして扱える

Fargate を使ったデプロイ

概念的には

Task Definition（コンテナイメージ、URL、CPU、メモリ、環境変数など）と Cluster を準備

Task, Service を run する
$ docker push ..
$ aws ecs register-task-definition ..
$ aws ecs create-service ..
もっとも簡単に Fargate でコンテナをデプロイする方法: awslabs/fargatecli

例： docker hub にある nginx:latest を Fargate で動かす

VPC にポート80を開放するSGを作る

fargate task run ..

fargate service create ..

例：ローカルのコンテナイメージを動かす

Fargate CLI の実行ディレクトリの Dockerfile をビルド -> デプロイまで自動でできる

Fargate CLI が内部でやっていること

デフォルトVPCにサプネット等を作成

ECRレジストリの作成

ECSクラスタの作成

ECSタスク実行IAMロール作成

ECSタスク定義

ECSサービス定義

SGはユーザが自分で準備やっておく必要がある

Pros

各種必要リソースが自動生成されるので、それを見て概念や各リソース定義の中身を勉強しやすい

細かい設定も可能だが、とにかく簡単

Cons

本番環境で使うには少々アドホック過ぎる

Infrastructure as Code や CI/DI パイプラインについてはもう少し考えて環境が作りたいところ

turnerlabs/fargate の CLI のほうがもう少し運用に配慮したインターフェースになっている

Fargate に対応したデプロイサービス

ECS 以外のAWSリソースもある

どのようにロールバックするか

Fargate へのデプロイツールは fargatecli 以外にも多数ある¹
* AWSのサービスは MVP から始めて、ローンチ後に後方互換性を保ちつつ機能追加していくやり方なので、UCに合わせてユーザ側がうまく取り計らう必要がある

AWS Management Console

閲覧目的には良いが、継続的デプロイには向かない

 AWS CLI

Pros

新サービスにも必ず対応、APIの呼び出しパラメータもほぼ全て利用可能

Cons

CI/DI パイプラインの実体がシェル芸に

リソースの依存関係がコマンド実行順になる、ロールバックを書こうとすると複雑化しがち

 ecs-deploy

Pros

1つのシェルスクリプトの中で AWS API を読んでいるだけなので理解しやすい

コミュニティで揉まれているので自前で作るよりも安全

Cons

Fargete 以外のリソースのプロビジョニング方法によっては折り合いが悪いことがある

実体が単なるシェルなので魔改造したくなってしまう

 ECS CLI

Pros

docker compose を利用できる

ECS固有機能もサポート

Cons

Fargete 以外のリソースのプロビジョニングを管理は自分でやる必要がある

 AWS CloudFormation

Pros

全てのAWSリソースを用意できるため1つのツールで済む

Infrastructure as Code

予定される変更差分も見られる

AWSリソース間の依存関係も定義できる

CI/DI との相性も良い

Cons

AWSリソースを十分に知る必要

最新のパラメータがサポートされるまでには時間がかかることもある

ライフサイクルの異なるリソースの管理は難しい

 AWS CDK

Pros

プログラムを書いているようにかける

ユニットテスト書きやすい

Cons

抽象度が高いことは良し悪しあり

 ecspresso

Pros

薄いラッパ

must_env とかができる

Cons

AWS CLI と同様

プラグイン

VSCode の ECS 用プラグインがちょうど利用可能になっている

https://aws.amazon.com/jp/about-aws/whats-new/2019/10/amazon-elastic-container-service-now-supports-intellisense-in-visual-studio-code/

所感

コンテナ化したアプリケーションをとりあえず動かしてみたい！という用途であれば fargatecli すごく良さそうに感じました。
ただセッション中も言われてましたが、プロダクションで使うものではなさそう。

特に EKS 使っている身としては、EC2 と Fargate どちらがよりおいしいかというのは聞いていて気になったところ。
EC2インスタンスのサイジングを考えなくて済むメリットもわかる一方、見えているからこそ柔軟にカスタムできる良さもあるので、唯一解はなく構築したいシステムの状況やフェーズに合わせて選択していくもの、ということなのだと思います。

また、現状 ECS Fargate では永続ストレージ(ブロックデバイス/ファイルシステム)が使えないことや、EC2 ECS に比べるとタスク起動オーバーヘッドが大きいことも気になります（いずれ解消されていくのかもしれませんが）。

EKS か ECS かという点で考えたことも記載しておきます。

ECS であってもプロダクションレベルのシステムを準備しようとすれば、 CloudFormation 含めたテンプレートファイルの記載は避けては通れない

EKS のほうが考慮事項や記述量は増えるので、この手間の差とカスタマイズ可能というメリットを天秤にかけてどちらをとるか

デプロイの手間で言っても、結局テンプレートは書かねばならないことを思うと変わらないと思われる。むしろ EKS (Kubernetes) なら kubectl apply -f/-k で一発ではある

ECS Fargate 選択した場合、特に永続ストレージ使えないとなるとクラスタの中で立てられるアプリケーション/ミドルウェアに制約ができるので、そのあたりまで含めてマネージドサービスで賄うという判断ができるかどうか

例えば ElastiCache でなく自前で Redis 立てるほうがコスト的に優位という場合でもその選択肢がとれない（ Fargate では立てられない）

マルチテナント時代におけるテスト・ベストプラクティス

清水毅（アマゾンウェブサービスジャパン株式会社パートナーソリューションアーキテクト）

https://aws-seminar.smktg.jp/public/session/view/263

概要

「WEBアプリケーションにおけるテストは非常に悩ましい問題ですが、テストコードやCIツールでのテスト、あわせてTestサービスのSaaSを利用するなどされていると思います。最近では、さらにマルチテナントにおけるテストが更に実施に悩まれている状況をよくお聞きします。どのようにテストをしていけばいいのかをおさらいとなるような初歩的な内容を含めてまとめます。特にSecurity観点とPerformance観点でどのような考慮点があってどのようなテストが求められるのかについて検討していきます。」下記コンテンツをベースに負荷テスト・セキュリティテストについてまとめる予定です。（下記はAWSサービスは関係がないのですがAWSセキュリティサービスなど絡めることを考慮します） Testing SaaS Solutions on AWS https://aws.amazon.com/blogs/apn/testing-saas-solutions-on-aws/

期待

弊社はまさにマルチテナントに向けた SaaS を提供しており、セッション概要はまさしくドンピシャでした。

特に、「マルチテナント × テスト」という（一般にはおそらく）珍しい組み合わせに興味を持ち、聴講しました。

内容メモ

マルチテナントの基本

このセッションでは「マルチテナント ≒ SaaS」と定義する。

マルチテナントの特徴

使用量やユーザ数で課金

オンデマンドでセルフサービス

マルチテナントでインフラを共有

柔軟な使用量

そもそも、マルチテナントは運用コスト・インフラコストをダブルダウンするのが重要な目的。
インフラ・運用コストは抑えないと競争力が弱まるので、SaaSでは規模やステージに合わせたインフラや運用方法が大事。

マルチテナントのパフォーマンス

需要に対してインフラの供給をスケールさせたい（コストをマッチさせる）

マルチテナントのセキュリティ

マルチテナント固有のセキュリティというものがありこれを意識する必要がある

SaaSアプリケーションの典型的なアーキテクチャ

認証

ユーザ・テナント登録、ユーザ管理、テナントレベル別システムサポート（ティア とも。ライセンスによる使える機能の違いなど）

テナント分離

動作させるマシンやアプリケーション自体を分離するかどうか

分離するほどセキュアな一方、コストは増加

データパーティショニング

データを分離するかどうか、分離するとしてもどのレベルでやるか

分離するほどセキュアな一方、コストは増加

RDB の限界との戦いでもある

テスト

マルチテナントに限らず、パフォーマンステスト・セキュリティテストに強いエンジニアというのは意外と少ない。

パフォーマンステスト

どこに基準・目標を定めるか？が非常に重要

UX に基づき レイテンシ・スループット などの目標を設定

限界性能テスト・耐久テストも忘れない

長時間走行時のメモリリークでアプリケーションがクラッシュするなどはよくある話

セキュリティテスト

ブラックボックステスト

ホワイトボックステスト

グラスボックステスト

マルチテナントテスト

マルチテナントに固有と言えるのはサービステストのレイヤ

ユニットテスト、一般的なウェブアプリケーションのテストだけでなく、継続的テスト・モニタリングが必要

SaaS Operations: A higher DevOps bar

次のようなサイクルをうまく回していく必要がある

Speed

Rapid delivery

Scale

Security

Zero downtime

Collaboration

ベストプラクティス

テナント負荷

マルチテナントの予測不能な負荷によるパフォーマンス問題を表面化させる

ex. あるテナントAのオペレーションによってテナントBのパフォーマンスが悪化する

テナント分離

認証認可のような ビジネス要件 にまつわる脆弱性は一般のwebアプリケーションセキュリティテストでテストできない

テナントライフサイクル

テナントのユーザ体験としてのテスト

テナント内のユーザの一貫した体験・ワークフローがうまく回っているか

ティア境界

契約レベル=ティア

ポリシー通りかどうかをティア毎に分類したモニタリングと合わせて実施

フォールトトレランステスト

本番で実測 しておく こと

GameDay を設けられると最良

Tips

そもそも可観測性を持ったシステムにしておかないと、いくらテストしても原因特定に至らない可能性がある

「たまに遅い」は GC を疑う

本番環境でのテストをやること

AWS SaaS Portal

パッケージベンダー向けのサポート・プラクティスなどがまとめられている

所感

Webサービスに必要な基本的なテストの復習と、そこに加えてマルチテナントの SaaS 事業者として必要なテストとは？というところまで踏み込んだ素晴らしいセッション。
セッション中は「本当に徹底的にテストできていますか？」という講演者の思いがビシバシと伝わってくる感じがしました。

引き合いに出されていた課題はまさしく自分のことのように腑に落ちました。
日頃立ち向かっている課題が改めて言語化され、対応していくためのプラクティスとして整理されたことで非常にすっきりとした気持ちになりました。

テナント分離レベルとコスト・パフォーマンスリスク/セキュリティリスクとの間でのトレードオフは避けては通れないし、悩ましい部分

非機能観点がテストから漏れやすいことは度々課題になる話。エンジニアの習熟度の問題と片付けるのは簡単ですが、非機能テストの観点を Webサービス、 SaaS ではどのように定めるべきかがわからない（難しい）というのが本質的にはあるのかもしれません *「パフォーマンス目標は UX 目標を元に定める」、当たり前ですが改めて心に刻んでおくべき考え方

個人的には1日目の ベストセッション 。もっと早く聞きたかった・・・

AWS の隙間を埋めるOSS開発

藤原俊一郎（株式会社カヤック）

https://aws-seminar.smktg.jp/public/session/view/549

概要

AWSのマネージドサービスは運用の省力化に大変ありがたいものですが、各サービス間の連携が完璧なものばかりではありません。AWSにおける長年のシステム運用を通じて、各サービスの隙間を埋めるOSSや公式にサポートされていないSDKを開発することで、よりよい運用を目指してきました。なぜOSSにするのか、どのような思想で設計、開発、運用をしているのかを、実例をもとにご紹介します

期待

AWS のサービス間連携に悩むのは使い始めるとあるあるなのではないでしょうか。
普段は OSS は使う側の立場ですが、どのように思考して作られているのか気になり、聴講しました。

また、原さんのセッションでおすすめされたセッションでもあります。

AWSの「隙間」とは

AWSのマネージドサービスはローンチ時はコア機能のみの状態から成長していく

追いつくまでは足りない部分がある

例：10年前にリリースされたサービスだが、RDSのログが CloudWatchLogs に流れるようになったのは結構最近

パッチ運用・バージョンアップなどの人的コストを払えないのなら、多少不便でもマネージドサービスを利用すべき

隙間家具を作る

小さく、そのUC内で適切な汎用度を持ったものを、マネージドサービスが対応したら 捨てる つもりで作る

「隙間家具」OSSの実例と設計思想

以下の OSS は藤原さんの作成物であり、 GitHub で公開中

 Rin

Redshift へデータを取り込むためには Redshift へ S3 にコピーするリクエストを発行する必要がある

S3 への put イベントをフックしてコピーを発行

fluentd の plugin に Redshift のコピーを発行するものがあったので使っていたが、 Redshift がメンテナンスで停止するときにコピーが失敗してしまう

このときのリトライ処理で、 S3 への put と Redshift のコピー全体をリトライしてしまうため使いづらかった

S3->Redshift の部分の小さな隙間を埋める思想で Rin を開発

Firehose が登場して元々の用途では要らなくなったが、 ELB/ALB のログを送るのには使えている（適度な汎用性だった）

マネージドになったときにきれいに取り外せる設計が大事

リトライ設計が大事

 s32cs

CloudSearch にデータを継続的に取り込む方法が現状もマネージドにない

S3のイベントをフックして、データの変換+CloudSearchへ投入

json を配列形式に変換しなくてはいけなかった

firehose -> S3のイベントフック（データドリブン）は結構便利（定期実行バッチよりも可用性が高まる、分散処理などもやりやすい）

firehose は吐き出しを秒数とサイズの両方で指定でき、サイズの制御ができるので、安心してオンメモリに積んだりできる

状態はマネージドサービスに起き、状態を持たない処理だけ書くとスケールが簡単

 ssmwrap

SSM Parameter Store の値を環境変数に設定してコマンドを exec する wrapper

類似品はたくさんある

ECS task に SSM の値を渡すために開発

コンテナのエントリポイントに使える、パラメータストアがエラーの場合のリトライが設定可能、変数を指定ファイルに書き出す機能

パラメータストアの RPS が 1000 で割とすぐ死ぬので

ECS はすぐに対応したが、 EC2 や AWS外でも使えるので便利に使っている

Go のライブラリとしても使える

将来マネージドになりそうなものでも、アプリケーションベタ書きで解決せずに小さいコード・ツールに切り出したほうが良い

直書きすると密結合するので改修しづらい

ライブラリになっていないコードをコピペして別プロジェクトで使われると・・・

OSS として作る

自分たちしか使わなくても OSS にしてしまったほうがよい

OSSにするならどうなるか考えるようになってよい

ドキュメントを書く気にもなる

社内事情の混入を防ぐ

責任分界点を見極めることで設計きれいになる

魔改造を防ぐ

ツールを作って隙間が解決したとしても、AWS にサポートケースに要望をきちんと伝えること

所感

「うまい抽象度でツール化する」というのが、センスが要求される難しいところだと思いながら聞いていました。

コピペによって、オリジナルの開発者が認知していない謎の fork が増えていく現象はありがちなので、（社内的な事情もあるでしょうから） OSS までいかなくとも、社内に公開して、使い方を定める活動は進めていくべきなのかもしれません。

本筋ではありませんが、このようなツールをバイナリで配布できる Go が少しうらやましく感じました。普段は Python ばかり書いているので・・・

40分でわかるDynamoDBでのApp開発

成田俊（アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト）

https://aws-seminar.smktg.jp/public/session/view/556

概要

Amazon DynamoDBはフルマネージドサービスで提供されるkey-value およびドキュメントデータベースです。世界中でもAmazonを始め多くのユーザーに利用されており、是非このセッションでDynamoDBを利用した開発の導入部分を学んで頂きたいと考えています。本セッションではpythonで書かれたサンプルアプリを例として主要なデータ操作、よく比較されるRedisとのユースケースでの使い分けなどを解説します。是非アプリケーション開発でDynamoDBを導入する手助けになれば幸いです。

期待

普段は主に RDB （MySQL や Aurora for MySQL）を使ったサービスの開発をしているのですが、クラウド化/クラウドネイティブ化の流れの中で、 DynamoDB を始めとするサーバレスデータストアには興味がありました。

今回は DynamoDB を使ったアプリケーション開発をなんと 40分で理解できるということで、聴講しました。

内容メモ

Introduction

"You build it, you run it" - Werner Vogels

作った人が運用もやる

メンテナンスフリーなマネージドサービスを使えることはプログラマにとってうれしいこと

Table構造

Table, items(行), attributes(列), PartitionKey(主キー), SortKey（relationship,query）

PartitionKey と SortKey 以外は attribute に抜けがあっても良い（スキーマレス）

NoSQL Workbench for Amazon DynamoDB が preview で公開されている

一通りの操作が可能

作ったクエリを発行するための python などのコードを生成可能

demoアプリを作ってみる

API GateWay -> Lambda(Chalice) -> DynamoDB

DynamoDB でモデリングするには？

Redis の Stream型やSortedSet型とはまた違ったモデリングをする

PertitionKey+SortKey と GSI にわける

書き込みをスケールさせるためには、キーが集中しないものを PertitionKey にするほうが効率的

一度書いてから、 DynamoDB Stream と組み合わせる（ElasticSearch なども裏で使える）

put時のオプションで消費したユニットの取得やデータが存在するかどうかのチェックなども行える

クエリ時に利用するインデックスを指定

LastEvaluatedKey でページング

DynamoDB streams

Lambda で DynamoDB のイベントをフックし、 Redis の cache に積んだり

Lambda -> Kinesis という技もある

CI・テストをどうするか

AWS内で解決できるならやはりCodeBuildなど

テーブル名が conflict する可能性があるので毎回 table 名をユニークに新規作成するのが楽

並列数が大きすぎると DynamoDB の API の limit に引っかかる可能性もある

DynamoDB Local を活用するのも手（コンテナ or jar）

CodeBuild の場合は同一コンテナ内で DynamoDB-local のプロセスとアプリケーションプロセスの両方を実行する必要あり

所感

DynamoDB はキー設計がキモ、かつ従来のデータストアとは違うところも多いので、ずっと RDB やってきたゆえに難しいところだな、と思いました。
NoSQL Workbench for Amazon DynamoDB はまたプレビュー版だそうですが、大変使いやすそうですしさっそく触ってようと思います。

「とりあえずサーバサイドの App 作ってみたい」という場面で、 DynamoDB + Chalice は最良に近い選択肢かもしれません。
Chalice が Lambda から API Gateway 、必要な IAM Role まで含めてコマンド一発で作ってくれるのは、初学者には大変ありがたいことだと思います（僕の場合普段から Python, Flask を使っているからこその贔屓目もあるんですが）。

全体所感

General Session でも触れられていましたが、 AWS Summit に比べるとセッションがエンジニア向けの内容にフォーカスされていると確かに感じました。

すでに利用していてより使いこなしたいもの

まだ利用していないがこれから試してみたいもの

など、バランスよく学ぶことができたのもよかったと思います。

個人的な総括

クラウドを前提とした世界観では、利用する技術やアーキテクチャもサービスのフェーズに合わせて変化させたほうが良い。どのフェーズにも完全にマッチするという技術はそうそうありえない

AWS のサービスも変化・改良が進んでいくため、柔軟に取り入れられるようなアーキテクチャにしておくと恩恵を受けやすい

システムのモダン化・開発サイクルの高速化していくうえで、徹底的にテストする仕組みは最重要とも言える。従来のテスト項目も漏れなく行いつつ SaaS 特有の事情についてもテスト項目に加えて、本番環境含めたテストを継続的に行うべし

次回以降も楽しみなイベントになりました。

さいごに

株式会社いい生活では「不動産テック」領域で共に成長し、付加価値を生み出す仲間を募集しています。

https://jobs.qiita.com/postings/197

弊社の AWS 利用事例については https://speakerdeck.com/akipom/awswozui-da-xian-huo-yong-sitabu-dong-chan-ye-xiang-keb2bsabisufalsekuraudosihutoshi-li で詳しく解説しています ↩

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T15:43:39+09:00

【AWS：節約】使ってないElasticIPは月額400円掛かるので解放しましょう

AWSのElasticIPはインスタンスに紐づけてないとお金がかかる

1ヶ月3.6$なので400円ほどですね、積極的に消していきましょう。

公式ドキュメントに記載があります。

https://aws.amazon.com/jp/ec2/pricing/on-demand/
0.005USD: 実行中のインスタンスと関連付けられている追加の IP アドレス/時間あたり（比例計算）
0.005USD: 実行中のインスタンスと関連付けられていない Elastic IP アドレス/時間あたり（比例計算）
0USD: Elastic IP アドレスのリマップ 1 回あたり – 1 か月間で 100 リマップまで
0.1USD: Elastic IP アドレスのリマップ 1 回あたり – 1 か月間で 100 リマップを超える追加分

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T15:03:19+09:00

AWSで構築したWebサイトがiPhoneで開けないときに試すこと

AWS で EC2 + RDS + ELB などで構成したWebサイトをiPhoneで開こうとすると
なぜか「ページを開けません。サーバーが見つかりません。」と表示されて開けない問題に直面しました

端末側の問題だと思い、以下のことを実施しましたが解決せず。

「ホーム画面」→「設定アプリ」→「スクリーンタイム」→「コンテンツとプライバシーの制限」をオンにし、
「コンテンツとプライバシーの制限」画面にて「コンテンツ制限」を選択し、
「許可されたWebサイトのみ」から「無制限アクセス」を選択します

「ホーム画面」→「設定アプリ」→「Safari」→「履歴とWebサイトデータを消去」を選択します

「ホーム画面」→「設定アプリ」→「Safari」→「Safari検索候補」をオフにします

「ホーム画面」→「設定アプリ」→「Safari」→「コンテンツブロッカー」をオフにします

端末を再起動します

結果的にこちら（ https://qiita.com/ameyamashiro/items/8d4be0f11ffe12472052 ）のページに辿り着き、
ELB における HTTP/2 の設定が有効となっているのが原因のようだったので、
HTTP/2 を無効にしたら無事 iPhone からページを表示することが出来ました。

設定手順は、
EC2 → ロードバランサーへ遷移し、説明タブの下方にある「属性の編集」ボタンを押し、
HTTP/2 の「有効化」チェックボックスのチェックを外して保存すればOKです。

HTTP/2 を使うことで画像、Javascript、CSSなどのファイルを並列処理で受け取れるのでページの表示速度は上がりますが、このような落とし穴もあるので、皆様お気をつけください。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T14:53:09+09:00

AWS workspacesを使用して、開発担当者からの情報漏洩を防止したガッチガチの開発環境を作る（2）

はじめに

今回は、VPCの作成と関連するルートテーブル等の設定について記載します。
以後の章で設定を変更する箇所があるはずですので、ここでは最初の段取りが中心になります。
調べながら設定を行った際の手順をベースにまとめていますので、ひょっとしたらこの箇所いらんやんってところがあるかもしれません。

基本はAmazonの解説を基準に進めていますので以下が参考リンクとなります。
[Amazon WorkSpaces での VPC の設定]
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/amazon-workspaces-vpc.html

(1)NATゲートウェイ用 Elastic IPの取得

VPCと外部との通信を行うNATゲートウェイに使用するElastic IPを予め取得します。
実は、最終的にはSquid(プロキシ)を外部とのアクセスゲートウェイとして設置して許可対象のみアクセス可能となるよう管理を行い、NATゲートウェイは使わない状態になるので実は不要な工程かもしれません。ただ、Amazonの解説に沿う流れでやった方がわかりやすいかもしれませんのでこのまま進めます。

Elastic IPの取得方法自体は説明不要かと思いますので詳細割愛します。
[EC2ダッシュボード→ネットワーク＆セキュリティ→ElasticIP→新しいアドレスの割り当て]

(2)VPCの作成

さて、VPCを作成します。
[サービス→ネットワーキングとコンテンツ配信→VPC]
を選択します。
VPCダッシュボードに遷移したら「VPCウイザードの起動」ボタンを選択。

次に「パブリックとプライベートサブネットを持つ VPC」を選択。

必要な内容を入力します。
今回は以下の内容で指定します。
CIDRブロックはVPCで必要とするIPアドレスの数を見込んで設定ください。
今回は特にシビアに設定を行う必要はないので、サブネット毎に251個も使用できれば無問題として若干適当な指定になっています。
NATゲートウェイの詳細指定では、「Elastic IP 割り当てID」に先ほど取得したElastic IPのアロケーションIDを指定します。

「VPCの作成」を選択し、次に進めます。
作成の処理が開始します。なんか表示崩れてますね。

VPCが作成されました。

(3)プライベートサブネットの追加とルートテーブルの確認

この時点で作成したVPCにはパブリックサブネットとプライベートサブネットがそれぞれ１つ存在しています。

次にAmazonの解説通りにプライベートサブネットを一つ追加します。
[VPC→サブネット→サブネットの作成]

次に、作成した各サブネットのルートテーブル設定を確認します。
まずはパブリックサブネットのみを選択状態にし、下部のタブにて「ルートテーブル」を選択します。
ローカル(10.0.0.0/16)と外部(0.0.0.0/0)の設定が既にされています。
外部向けはインターネットゲートウェイ(igw-xxxxxxx)が割り当てられていますね。

解説に従いますと、ここでルートテーブルに名前を付けておきます。
ルートテーブルのID(rtb-0xxxxxxxxxx)がリンクになっていますので、クリックしてルートテーブル画面に遷移します。
Nameが空白になっているので名前を付けます。パブリック用かプライベート用かを判別できるような名前がいいと思います。

サブネット画面に戻り、一つ目のプライベートサブネットを選択して確認します。
ローカル(10.0.0.0/16)と外部(0.0.0.0/0)の設定が既にされています。
外部向けはパブリックと異なり、VPC作成時にElastic IPを割り当てたNATゲートウェイに指定されています。
パブリックと同じ手順でルートテーブルに名前を付けておきましょう。

次に、追加した２つ目のプライベートサブネットを選択して確認します。
一つ目のプライベートサブネットと異なるルートテーブルが指定されている場合は、同じルートテーブルに変更します。
「ルートテーブルの関連付けの編集」をクリックし、一つ目のプライベートサブネットと同じルートテーブルを指定して保存します。

(4)ここまでの進捗

ここまでの設定状態を図示しますと以下になります。

とりあえずVPCとサブネットを作成して土台ができたところですね。

「AWS workspacesを使用して、開発担当者からの情報漏洩を防止したガッチガチの開発環境を作る（序章）」にある完成状態のシステム構成図と比較してみましょう。

はい、全然まだまだですね・・・・・
今回はここまでにしたいと思います。

次回は、作成したVPC内でディレクトリ管理を行うworkspacesの構築について記載したいと思います。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T13:58:06+09:00

CodeCommit用のIAMユーザを作成する流れ

今までGithubやBitbucketを使ってきましたが、AWSにも同様のGit管理システムがあると知り、使ってみようとした記録です。

IAMユーザを作成する

https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/setting-up-gc.html

コンソールへログイン後、IAM設定を開きます。

今回は新たにCodeCommitを行う用のユーザを作成しようと思います。
すでにあるユーザに権限を追加する場合はこのプロセスは必要ありません。
２ステップ後に出てくる"AWSCodeCommitFullAccess"の権限を追加してください。

ユーザを追加をクリック

ユーザ名を入力し、アクセスの種類でプログラムによるアクセスを選択します。

次にアクセス許可を設定します。
「既存のポリシーを直接アタッチ」を選択し、AWSCodeCommitFullAccessを選択します。

タグの追加は必要に応じて設定してください。

確認して作成を押すと、このようにユーザが作成されます。

Git認証情報と関連づける

先ほど作成したユーザを開き、認証情報をクリックします。

下にスクロールすると、 "AWS CodeCommitのHTTPS Git認証情報"という項目があるので「生成」をクリックします。

すると、Gitの認証情報が生成されます。後ほど必要になってくるので、メモするか、証明書のダウンロードを選択します。

これでユーザの登録は完了です！
あとは、普段のgitと同様、ユーザ名とパスワードの部分に先ほど作成したユーザを登録すれば完了です。

(番外)AWS-CLI をダウンロードする

私はMacなので、下記の情報を参考にDLしました。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-macos.html

うまくいくと、ちゃんとバージョン情報が表示されます。
$ aws --version
aws-cli/1.16.252 Python/3.6.5 Darwin/18.7.0 botocore/1.12.242
GUI的にはGithubやBitbucketの方が好きですが(←) AWS-CLIを使ってコマンドライン上からいろんな操作ができそうなこと、AWSのCIツールを使うならいいかもしれない。
使い勝手がわかってきたらまた投稿します。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T11:23:30+09:00

【AWS】AWSセキュリティ診断サービス概要（Well-Architected Toolが東京リージョンで使えるようになった）

2019/9/26に「AWS Well-Architected Tool」が日本語のサポートとアジアパシフィック(東京)リージョンでの提供を開始しました。
（参考：AWS Well-Architected Toolが日本語をサポートしました(東京リージョンでご利用いただけます)）
セキュリティやコストなどの様々な面についての、ベストプラクティスを提案してくれるようなのですが、他にもそのようなAWSサービスがあったような・・と思い、他のAWSセキュリティ関連サービスもついでに調べてみました。

AWS Well-Architected Tool

現在利用中の構成をAWSのベストプラクティス（いわゆるWell-Architectedな構成）と比較して、「運用の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コストの最適化」の5つを診断してくれるツール。後述のTrusted Advisorでもベストプラクティスの比較は行われるが、Well-Architected Toolはさらにユーザごとに定義するワークロードに従ったフレームワーク検討が実施されるため、よりユーザのポリシーに沿った評価をしてくれそうである。

以下は公式ドキュメントからの引用
AWS Well-Architected Tool とは

AWS Well-Architected Tool (AWS WA Tool) は、AWS のベストプラクティスに照らしてアーキテクチャを測定するための一貫したプロセスを提供するクラウド内のサービスです。AWS WA Tool は、製品ライフサイクル全体を通して以下のことを支援します。

・決定事項のドキュメント化を支援する
・ベストプラクティスに基づいてワークロードを改善するための推奨事項を提供する
・ワークロードの信頼性、安全性、効率性、費用対効果の向上

今日では、AWS WA Tool を活用し、AWS Well-Architected フレームワークのベストプラクティスを使用してワークロードのドキュメント化および測定ができます。これらのベストプラクティスは、AWS ソリューションアーキテクトによって、さまざまなビジネスでのソリューションの構築における長年の経験に基づいて開発されました。このフレームワークは、アーキテクチャを測定するための一貫したアプローチを提供します。また、時間の経過とともにニーズに応じてスケーリングする設計を実装するのに役立つガイダンスも提供します。

Trusted Advisor

現在利用している環境のリソース、設定情報をもとに推奨プラクティスを「コスト最適化」「パフォーマンス」「セキュリティ」「耐障害性」「サービスの制限（利用上限）」について、ダッシュボードで提示してくれるツール。Trusted AdvisorはあらかじめAWS側で定められたルールと一律かつシンプルに比較される。ここでアラート対象になったからといって急を要するとは限らないが、環境改善対策を見つける手段のひとつとしては有用である。特にセキュリティ面は、Well-Architected Toolと重複する箇所もある認識ではあるがこちらの分析結果と比較して漏れがないようにしたい。

公式ドキュメント　
AWS Trusted Advisor

Amazon GuardDuty

自アカウント内のVPC フローログ、AWS CloudTrail イベントログ、DNS ログを分析して処理する継続的なセキュリティモニタリングサービス。いわゆる侵入検知、IDSに近い。
導入に関しては、特に難しい設定をする必要はなく、ワンクリックでサービス用のポリシーを有効化すれば自動的にCloudTrailやVPCフローログを分析開始してくれる。CloudTrailを有効化しているものの、うまく検知・監査へ活用できていない方にはぜひ導入をおススメしたい。
※30日無料で利用することができ、その間にコストの想定も教えてくれる

以下公式ドキュメントより抜粋　（ Amazon GuardDuty とは）

悪意のある IP やドメインのリストなどの脅威インテリジェンスフィードおよび機械学習を使用して、AWS 環境内の予期しない潜在的に未許可なアクティビティや悪意のあるアクティビティを識別します。このアクティビティには、権限昇格や、公開されている認証情報の使用、悪意のある IP や URL、ドメインとの通信などの問題も含まれます。たとえば、GuardDuty はマルウェアやマイニングビットコインに使われている侵害された EC2 インスタンスを検出できます。また、AWS アカウントのアクセス動作をモニタリングして、未許可のインフラストラクチャのデプロイ (これまで使用されたことのないリージョンへのインスタンスのデプロイなど) や、異常な API コール (パスワードポリシーがパスワードの強度が下がるものに変更されるなど) など、侵害の兆候を探します。

AWS Security Hub

ドキュメントからすると以下の機能を提供してくれるらしい。

複数のAWSセキュリティサービスの統合ビューの提供
＞AWS Security Hub は、ユーザー環境で有効になっている AWS セキュリティサービスから検出結果、たとえば Amazon GuardDuty からの侵入検知、Amazon Inspector からの脆弱性スキャン、Amazon Macie からの S3 バケットポリシー検出結果などを収集、統合します。

AWS 環境全体にわたって自動コンプライアンスチェックを実行
＞AWS Security Hub は、AWS のセキュリティ設定のベストプラクティスセットである Center for Internet Security (CIS) AWS Foundations Benchmark を自動化します。AWS アカウントまたはリソースのいずれかがベストプラクティスから逸脱した場合は、AWS Security Hub はその問題にフラグを付け、改善手順を推奨します。

改善アクションの自動化
＞Amazon CloudWatch Events との統合を利用して、カスタマイズされたアクションを構築し、チケット発行システム、チャットシステム、E メールシステム、自動改善システムに検出結果を送信します。AWS System Manager Automation ドキュメント、AWS Step Functions、AWS Lambda 関数を使用して、Security Hub から実行できる自動改善ワークフローを構築することもできます。

すでにAWS上で複数のセキュリティサービスを利用しているユーザは、ビューが統合される利点を享受できるし、CISベンチマークとの比較でフラグ付けと改善手順を推奨してくれるのは魅力的である。また、指摘事項をアクションと紐づけて、対策漏れがないようにできるところも実効性を高めている（もちろん出力に関してはカスタマイズが必要ではあるが）。

公式ドキュメント　AWS Security Hub とは?

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T10:34:28+09:00

AWS Lambda + SSM Parameter Store でカウンターを作る

事の発端はこのツイートを見たこと。

目的外利用な気はしますが SSM Parameter Store はどうでしょう
— fujiwara (@fujiwara) September 19, 2019

今まで Lambda を使っていて「データベースを用意するほどじゃないけどちょっとした情報を保存したい」と思うケースが多々あって、もっともカジュアルな方法はなんだろうかと考えていたところだった。

「ちょっとした情報の保存先」として SSM Parameter Store を使うアイデアは面白そうだと思ったので、試しに AWS Lambda + SSM Parameter Store でカウンターを作ってみた。

Lambda Function の実装

SSM Parameter Store に値を保持してカウントアップするだけの素朴な Lambda Function を作った。ランタイムは Python 3.7。
import boto3

ssm = boto3.client('ssm')

def get_param(key: str) -> str:
    global ssm
    try:
        return ssm.get_parameter(Name=key)['Parameter']['Value']
    except ssm.exceptions.ParameterNotFound:
        return None

def set_param(key: str, value: str):
    global ssm
    ssm.put_parameter(Name=key, Value=value, Type='String', Overwrite=True)

def lambda_handler(event, context):
    key = 'counter'
    count = int(get_param(key) or 0)
    count += 1
    set_param(key, str(count))
    return count
Role の設定

このままでは Lambda Function から SSM Parameter Store にアクセスする権限がないので、以下のようなポリシーを持つ IAM Role を作成して Lambda Function に割り当てる。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:PutParameter",
                "ssm:GetParameter"
            ],
            "Resource": "arn:aws:ssm:*:*:parameter/counter"
        }
    ]
}
権限を最小限にするために counter という名前のパラメータの読み書きのみができるようにした。

実行

Lambda Function を実行するたびにカウンターの値が 1 ずつ増えていくことが確認できると思う。

DynamoDB や S3 に保存するよりもはるかに簡単にできたので、「ちょっとした情報の保存先」として SSM Parameter Store を使うアイデアはかなりアリだなと思った。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T09:00:14+09:00

Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #8 (マネジメントとガバナンス)

Amazon Web Services (AWS)のサービスで正式名称や略称はともかく、読み方がわからずに困ることがよくあるのでまとめてみました。

Amazon Web Services (AWS) - Cloud Computing Services
https://aws.amazon.com/

まとめルールについては下記を参考ください。

Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #1 (コンピューティング) - Qiita
https://qiita.com/kai_kou/items/a6795dbab7e707b0d1a6

間違いや、こんな呼び方あるよーなどありましたらコメントお願いします！

Management & Governance - マネジメントとガバナンス

AWS Auto Scaling

正式名称: AWS Auto Scaling

https://docs.aws.amazon.com/autoscaling/?id=docs_gateway

読み方: オートスケーリング

略称: なし

俗称: なし

AWS Chatbot

正式名称: AWS Chatbot

https://docs.aws.amazon.com/chatbot/?id=docs_gateway

読み方: チャットボット

略称: なし

俗称: なし

AWS CloudFormation

正式名称: AWS CloudFormation

https://docs.aws.amazon.com/cloudformation/?id=docs_gateway

読み方: クラウドフォーメーション

略称: なし

俗称: CFn

AWS CloudTrail

正式名称: AWS CloudTrail

https://docs.aws.amazon.com/cloudtrail/?id=docs_gateway

読み方: クラウドトレイル

略称: なし

俗称: なし

Amazon CloudWatch

正式名称: Amazon CloudWatch

https://docs.aws.amazon.com/cloudwatch/?id=docs_gateway

読み方: クラウドウォッチ

略称: なし

俗称: なし

AWS Command Line Interface (AWS CLI)

正式名称: AWS Command Line Interface

https://docs.aws.amazon.com/cli/?id=docs_gateway

読み方: コマンドラインインターフェース

略称: AWS CLI

俗称: なし

AWS Config

正式名称: AWS Config

https://docs.aws.amazon.com/config/?id=docs_gateway

読み方: コンフィグ

略称: なし

俗称: なし

AWS Control Tower

正式名称: AWS Control Tower

https://docs.aws.amazon.com/controltower/?id=docs_gateway

読み方: コントロールタワー

略称: なし

俗称: なし

Amazon Data Lifecycle Manager (Amazon DLM)

正式名称: Amazon Data Lifecycle Manager

https://docs.aws.amazon.com/dlm/?id=docs_gateway

読み方: データライフサイクルマネージャ

略称: Amazon DLM

参考: https://docs.aws.amazon.com/en_pv/AWSEC2/latest/UserGuide/snapshot-lifecycle.html

俗称: なし

AWS Health

正式名称: AWS Health

https://docs.aws.amazon.com/health/?id=docs_gateway

読み方: ヘルス

略称: なし

俗称: なし

AWS License Manager

正式名称: AWS License Manager

https://docs.aws.amazon.com/license-manager/?id=docs_gateway

読み方: ライセンスマネージャ

略称: なし

俗称: なし

AWS Management Console

正式名称:

https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html?id=docs_gateway

読み方: マネジメントコンソール

略称: なし

俗称: なし

AWS OpsWorks

正式名称: AWS OpsWorks

https://docs.aws.amazon.com/opsworks/?id=docs_gateway

読み方: オプスワークス

略称: なし

俗称: なし

AWS Organizations

正式名称: AWS Organizations

https://docs.aws.amazon.com/organizations/?id=docs_gateway

読み方: オーガナイゼーションズ or オーガニゼイションズ

参考: https://licenseonline.bbss.co.jp/know/rule/ms-medical.shtml

略称: なし

俗称: なし

AWS Resource Groups

正式名称: AWS Resource Groups

https://docs.aws.amazon.com/ARG/?id=docs_gateway

読み方: リソースグループ

略称: なし

俗称: なし

AWS Service Catalog

正式名称: AWS Service Catalog

https://docs.aws.amazon.com/servicecatalog/?id=docs_gateway

読み方: サービスカタログ

略称: なし

俗称: なし

AWS Service Quotas

正式名称: AWS Service Quotas

- 参考: https://aws.amazon.com/jp/blogs/news/aws-service-quotas/

https://docs.aws.amazon.com/servicequotas/?id=docs_gateway

読み方: サービスクォータ

略称: なし

俗称: なし

AWS Systems Manager

正式名称: AWS Systems Manager

https://docs.aws.amazon.com/systems-manager/?id=docs_gateway

読み方: システム(ズ?) マネージャ

略称: なし

俗称: なし

AWS Trusted Advisor

正式名称: AWS Trusted Advisor

https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/?nc2=h_m1

読み方: トラステッドアドバイザ

略称: なし

俗称: なし

AWS Well-Architected Tool

正式名称: AWS Well-Architected Tool

https://docs.aws.amazon.com/wellarchitected/?id=docs_gateway

読み方: ウェルアーキテクチャ? ツール

略称: なし

俗称: なし

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T08:55:42+09:00

SAMでAPIにIP制限をかける

以下の構文でいけます。

この辺みながらコツコツいじりました
https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md

# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
  Function:
    Timeout: 3
  Api:
    Auth:
      ResourcePolicy:
        CustomStatements:
        - Effect: Allow
          Principal: "*"
          Action: execute-api:Invoke
          Resource: "*"
          Condition:
            IpAddress:
              aws:SourceIp: "221.250.87.66"

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-04T08:47:36+09:00

パラメータストアからEC2に環境変数を設定する

AWS Systems Manager パラメータストア
で階層構造で登録したパラメータをEC2で利用する方法のメモです

前提

EC2インスタンスのtagにName=MyApp, Env=Devが設定されている

roleにパラメータストアの権限が付与されている

roleにEC2のreadonly権限が付与されている

aws cli設定済み

jqがインストール済み

パラメータストアに登録
aws ssm put-parameter --name "/MyApp/Dev/S3_BUCKET_NAME" --value "MyAppBucket" --type String
aws ssm put-parameter --name "/MyApp/Dev/AWS_ACCESS_KEY_ID" --value "dummy_s3_access_key" --type String
aws ssm put-parameter --name "/MyApp/Dev/AWS_SECRET_ACCESS_KEY" --value "dummy_s3_secret_key" --type "SecureString"
確認
aws ssm get-parameters-by-path --path "/MyApp/Dev"  --with-decryption
EC2上でパラメータストアの情報を利用
#!/bin/sh

# ssm parameter-store settings
INSTANCE_ID=$(curl 169.254.169.254/latest/meta-data/instance-id)
ZONE=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone)
REGION=$(echo ${ZONE/%?/})
APP_NAME=$(aws --region ${REGION} ec2 describe-instances --instance-ids ${INSTANCE_ID} --query "Reservations[0].Instances[0].Tags[?Key=='Name'].Value" --output text)
APP_ENV=$(aws --region ${REGION} ec2 describe-instances --instance-ids ${INSTANCE_ID} --query "Reservations[0].Instances[0].Tags[?Key=='Env'].Value" --output text)
FILENAME="/var/www/${APP_NAME}/.env"

# put .env file
SSM_PARAMS=$(aws --region ${REGION} ssm get-parameters-by-path --path "/${APP_NAME}/${APP_ENV}"  --with-decryption)
for params in $(echo $SSM_PARAMS | jq -r '.Parameters[] | .Name + "=" + .Value'); do
    echo ${params##*/}
done > ${FILENAME}

echo "APP_ENV=${APP_ENV}" >> ${FILENAME}
EC2のinstanceIdとregionを取得

describe-instancesでタグ情報からNameとEnvを取得

パラメータストアからget-parameters-by-pathで階層化されたパラメータをまとめて取得

Key=Valueの形に整形して出力

です。
S3_BUCKET_NAME=MyAppBucket
AWS_ACCESS_KEY_ID=dummy_s3_access_key
AWS_SECRET_ACCESS_KEY=dummy_s3_secret_key
APP_ENV=Dev
このような内容で.envが作られます

最後に

LambdaやECSでの記事はあったのですが、EC2で汎用的に利用する例が見つからなかったので試してみました
このスクリプトをCodeDeployのBeforeInstallに登録して、デプロイすると.envファイルが最新の状態になるようにしています。
ユーザーデータに登録してEC2の初期化に利用したり、export命令に変えて環境変数を設定したりもできると思います
EC2のtagとパラメータストアの名称を合わせることで環境にあったパラメータを設定できるのは楽ですね

　 Tweet
Qiitaで続きを読む