20200517のAWSに関する記事は17件です。

AWS IAM:権限管理はドーナツと同じくらいシンプル。概念とポリシーについて理解しよう!

こちらの記事は、Anna Korkoshko 氏により2020年01月に公開された『 AWS IAM: Permission Management is as Simple as Donuts. Concepts and Policies 』の和訳です。
本記事は原著者から許可を得た上で記事を公開しています。

AWSでのすべてのプロジェクトの旅は、リソースの作成から始まります。確かに、サーバーレスで強力な高可用性について深く掘り下げたり、もしくは自分のロケットを今すぐにでも作りたい…などあなたがやりたいことは色々とあるでしょう。しかしまず最初に、間違いなく"Identity and Access Management Service (IAM)"にきちんと向き合う必要があります。

AWS IAMはすべてのリソース作成と密接に結びついており、エラーやセキュリティの問題を回避するために賢明にプロビジョニングする必要があります。このシリーズの記事では、基本から始め、次のパートに移っていきます。

この記事では、基本的なIAM概念とIAMのポリシーを、美味しいドーナツを例にして説明します。さあ、先にベーカリーに立ち寄って、それから楽しんでください!

IAMコンポーネントについて

まず、あなたが警官だと想像してみましょう。それであなたは警察署に来て、テーブルの上に沢山のドーナツがあることに気づきました。

あなたは食べてもよいのでしょうか?シェアされているのでしょうか?それとも、誰かがあなたのためだけにそれらを購入したのでしょうか?または、チーフのドーナツであるかもしれないので、あなたはドーナツを見たり嗅いだりさえしないほうがいいかもしれません。どうしたら知ることができるでしょうか?そう、ドーナツのためのポリシーがどこかにあるべきなのです。

ポリシーは行動規範の中にあるかもしれないし、あなたの頭の中にだけあるかもしれません。しかし、誰もが自分がドーナツを食べることが許されているかどうか知っているべきです。

では、ドーナツの観点から見たAWS IAMコンポーネントとは何でしょうか?

AWS IAMリソースは、あなたが食べることができるドーナツです。または、オフィスでやり取りできるその他の物です。

AWS IAMポリシーは、いくつかの許可文を宣言する文書です。これから、AWS IAMポリシーが何をどうやって宣言できるのか見ていきます。

AWSアイデンティティにはいくつかの種類があります。

AWS IAMユーザーはまさにあなたや、あなたの同僚や上司のような人です。

AWS IAMグループは、 権限基準で統一されたIAMユーザーの集まりです。警察署にだって、警察官、刑事、犯罪現場の捜査官などによって構成される、このようなグループがありますよね。(それか、警視、警部、警部補かもしれませんね)。1人のIAMユーザーが異なる複数のグループの一部になることができます。

ここで、AWS IAM ロールという別のアイデンティティタイプを紹介します。この時点では、もう少しあなたの想像力が必要です。

あなたは魅力的な警官の仕事とは別に、ドーナツベーカリーショップを経営しているとしましょう。

ドーナツショップには、クリーナー、シェフ、レジ係の3つの役割(ロール)があります。また、警官の役割もあります。この役割(ロール)を引き受けるには、この役割(ロール)に伴う権限と制限に従って行動する必要があります。それでは、「シェフの役割」を担ったと仮定して、シェフになりましょう。シェフだけがキッチンに行ってドーナツを作ることができますが、ドーナツを販売したり、顧客と話したりすることはできません。人々を逮捕することもできません!したがって、再び警官になるには、「シェフの役割(ロール)」を離れ、「警官の役割(ロール)」を引き受ける必要があります。うわー!これで再びバッジを獲得しました!また、ドーナツも食べられます!ただし、それでもまだ、あなたの役割をきちんと明確に知るためにドーナツポリシーを確認することをお勧めします。

So to assume a role, is like wearing a magic chef’s hat and becoming a chef for a while with all the chef’s privileges and prohibitions.

つまり、役割(ロール)を引き受けることは、魔法のシェフの帽子をかぶって、しばらくの間、すべてのシェフの特権と禁止事項を備えたシェフになるようなものです。

AWS IAMポリシーの構文

それでは、最もエキサイティングな部分であるAWSポリシーに移りましょう。権限を規制するドキュメント(実際には単なるJSON)があることはすでに知っています。自分でjsonポリシーを作成するか、AWSマネジメントコンソールのビジュアルエディターを使用できます。では、詳しく見ていきましょう。

ポリシーはステートメントで構成され、1つのポリシーに1つ以上のステートメントを含めることができます。

次に、簡単なS3バケットポリシーの例を示します。

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
      "Action":["s3:PutObject","s3:PutObjectAcl"],
      "Resource":["arn:aws:s3:::examplebucket/*"],
      "Condition": {
         "IpAddress": {"aws:SourceIp": "54.240.143.0/24"}
      }
    }
  ]
}

「ARN」で始まる部分に注意してください。これは、Amazonリソース名を表し、AWSで作成するリソースの一意の識別子を意味します。

ステートメントの構成要素について説明しましょう

Effect:ポリシーを作成するときに、アクション/リソースへのアクセスを許可または制限するという2つの選択肢があります。したがって、Effect – 「許可」または「拒否」を指定する必要があります。

Principal(NotPrincipal): アクセスが許可または拒否されたエンティティのことです。たとえば、ユーザー、ロール、AWSサービスなどです。Principalはリソースポリシーでのみ必要です(ポリシーの種類については次回の記事で説明します)

Action(NotAction): Actionでは、許可または拒否するアクセスのタイプを宣言します。AWSサービスとこのサービスで利用可能なアクションの2つの部分で構成されています。

オフィスに「food」サービスがあるとします。そのサービスで食べ物を買ったり食べたりすることができます。そのサービスは、フード提供者を変えることもできます。

したがって、オフィスマネージャーは次のアクションが許可されるでしょう。

"Action":["food:buy", "food:changeProvider"]

次に、従業員は次のアクションが許可されます。

"Action":["food:eat"]

次の2つの違いに注意してください。

"Effect":"Deny" 
"Action": ["food:eat"]
"Effect":"Allow"
"NotAction": ["food:eat"]

最初の例では、foodサービスでの「食べる」という行為を明示的に否定しています。ただし、2番目の例では、アクション「食べる」を除く、サービス「food」からのすべてのアクションを許可しています。

Resource:アクションのターゲットであるAmazonリソースのことです。

実際には、ここでのリソースとは、あの美味しいドーナツのことです。これで、リソースとアクションを組み合わせることができます。

"Action":["food:eat"],
"Resource":"pinkDonut"

これは単に、foodサービスを使用してpinkDonutを食べることが許可されていることを意味します。

アクションは、特定のタイプのリソースに対してのみ有効であることに注意してください。アクション ”food: eat” を ”car” リソースで使用することはできません。といっても、それを駆動するサービスがどこかにあるかもしれませんが。

Condition: 定義されたアクセスの条件(condition)は有効です。

ポリシーに使用できるconditionはたくさんあります。conditionはポリシーの作成時に「場合だけに」のフレーズを使用する場合に必要になります。いくつかの実例です:

従業員がピンクドーナツを食べられるようにしたいのです が、彼らが「警部補」である場合だけに許可したいです。(彼らだけピンクドーナツを食べられる)

社員にピンクのドーナツを食べさせたいのですが、午後2時までの場合だけにです。(彼らの健康に気をつかっているようだ)

従業員がピンクのドーナツを食べられるようにしたいのですが、それは彼らが毎日の報告を終えた場合だけに限られます。(迅速な報告を奨励)

ワイルドカード

ポリシーの一部の要素にはワイルドカードを使用できます。いくつかの例を見てみましょう:

"Resource": "arn:aws:s3:::*"

これは、ポリシーがs3のすべてのリソースに適用されることを意味します。

"Resource": "arn:aws:s3:::corporate*"

このポリシーは、「corporate」で始まるすべてのバケットに適用されます。

"Action": "s3:*"

このポリシーは、s3サービスからのすべてのアクションへのアクセスを提供します。

"Action": "ec2:*KeyPair*"

このポリシーは、キーペア(DescribeKeyPairs、CreateKeyPair、DeleteKeyPair、ImportKeyPair)で使用可能なすべてのアクションへのアクセスを提供します。

ワイルドカードには細心の注意を払い、使用する前によく考えてください。ポリシーを具体的にすることは、セキュアな環境を構築するために従うべきベストプラクティスです。

“Action”: ec2:”と書くときに、品質保証エンジニアにインスタンスを終了する権限を本当に与えたいでしょうか?“ Resource”: “arn:aws:s3:::”と書いて、すべてのs3リソースへのアクセスを全員に許可したいでしょうか?バケットの1つに機密データが含まれているのに?現在、ec2サービスには350以上のアクションがあります。あなたはそれらすべてを知っていて、開発者にすべてのアクションへのアクセスを本当に許可したいのでしょうか?そしてさらに重要なポイントがあります。

ワイルドカードを使用すると、既存のアクション/リソースだけでなく 、将来、追加されるアクション/リソースへのアクセスも許可されます。

したがって、「ワイルドカード」は非常に便利な機能ですが、責任を持って使用してください。

少し実世界の練習

次に、シンプルで現実的なポリシーの例を実際に作成してみます。EC2インスタンスとS3バケットがある環境があるとします。私たちの仕事は、開発者向けのポリシーを構築することです。彼らは、すべてのインスタンスを見ることができて、(オフィスからのアクセスの場合だけに)特別なdevタグをもつインスタンスを停止および開始することができて、devリソースを持つS3バケットにアクセスできる必要があります。

最初に、ユーザーがec2サービスを使用して「インスタンスを説明」できるようにします。これは非常に簡単です。

{
  "Effect":"Allow",
  "Action":"ec2:DescribeInstances",
  "Resource":"*"
}

次に、インスタンスの開始と停止を許可する必要がありますが、ユーザーがオフィスのIPからAWSにアクセスする場合だけにです。覚えているでしょうか?「場合だけに」というフレーズは、Conditionを使用することを意味します。さらに、リソースタグの条件を使用して、devインスタンスとのみ対話できるようにします。

{
  "Effect":"Allow",
  "Action":[
    "ec2:StartInstances",
    "ec2:StopInstances"
  ],
  "Resource":"*",
  "Condition":{
    "StringEquals":{
      "ec2:ResourceTag/env":"dev"
    },
    "IpAddress":{
      "aws:SourceIp":"210.75.12.75"
    }
  }
}

最後に、ユーザーがdevバケットのコンテンツを一覧できるようにし、その一覧からPutObjectとGetObjectを行えるようにします。そのためにs3サービスのアクションを使用します。

すべてのdevバケットの名前が「devdata」プレフィックスで始まると仮定しましょう。これは、ワイルドカードをうまく利用するのに適した場所です。

{
"Effect":"Allow",
"Action":"s3:ListBucket",
"Resource":"arn:aws:s3:::devdata*"
},
{
"Effect":"Allow",
"Action":[
 "s3:PutObject",
 "s3:GetObject"
],
"Resource":"arn:aws:s3:::devdata*/*"
}

はい、以上です。これで、すべてのポリシーの内容を確認することができます。ね、簡単でしょ?

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Allow",
      "Action":"ec2:DescribeInstances",
      "Resource":"*"
    },
    {
      "Effect":"Allow",
      "Action":[
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource":"*",
      "Condition":{
        "StringEquals":{
          "ec2:ResourceTag/env":"dev"
        },
        "IpAddress":{
          "aws:SourceIp":"210.75.12.75/16"
        }
      }
    },
    {
      "Effect":"Allow",
      "Action":"s3:ListBucket",
      "Resource":"arn:aws:s3:::devdata*"
    },
    {
      "Effect":"Allow",
      "Action":[
        "s3:PutObject",
        "s3:GetObject"
      ],
      "Resource":"arn:aws:s3:::devdata*/*"
    }
  ]
}

おわりに

ご覧のとおり、AWS IAMの基本コンポーネントは非常に単純で直感的でありながら、強力で柔軟です。多数のリソースとともに、100を超えるサービスの数百のアクションを使用できます。

きめの細かいアクセス管理は、すべてのセキュリティのベストプラクティスに従い、プロジェクトチームにとって便利な環境を実現するのに役立ちます。ポリシー作成の詳細については、IAMユーザーガイドでいつでも確認できます。

後続の記事では、さまざまなポリシータイプとそれらの相互作用について説明します。さらに、ドーナツの観点から分かりやすくポリシー評価プロセスを見ていきます。

翻訳協力

Original Author: Anna Korkoshko

Original Article: AWS IAM: Permission Management is as Simple as Donuts. Concepts and Policies

Thank you for letting us share your knowledge!

この記事は以下の方々のご協力により公開する事が出来ました。
改めて感謝致します。
選定担当: yumika tomita
翻訳担当: @_masa_u
監査担当: Aoi, takujio
公開担当: @_masa_u

私たちと一緒に記事を作りませんか?

私たちは、海外の良質な記事を複数の優秀なエンジニアの方の協力を経て、日本語に翻訳し記事を公開しています。
活動に共感していただける方、良質な記事を多くの方に広めることに興味のある方は、ぜひご連絡ください。
Mailでタイトルを「参加希望」としたうえでメッセージをいただく、もしくはTwitterでメッセージをいただければ、選考のちお手伝いして頂ける部分についてご紹介させていただく事が可能です。
※ 頂いたメッセージには必ずご返信させて頂きます。

ご意見・ご感想をお待ちしております

今回の記事は、いかがだったでしょうか?
・こうしたら良かった、もっとこうして欲しい、こうした方が良いのではないか
・こういったところが良かった
などなど、率直なご意見を募集しております。
いただいたお声は、今後の記事の質向上に役立たせていただきますので、お気軽にコメント欄にてご投稿ください。Twitterでもご意見を受け付けております。
みなさまのメッセージをお待ちしております。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AlexaスキルのHelloWorldテンプレートを日本語化する(Node.js編)

はじめに

Alexa Skills Kitコマンドラインインターフェース(ASK CLI)を使うとテンプレートから新しいスキルを作ることができますが、そのテンプレートの中のHelloWorldスキルは現状US版になっています。
グローバル対応させるつもりがないときは日本語化しておきたいため、変更内容をメモしておきます。

なお本記事では触れませんが、HelloWorld以外のテンプレートは日本語も含め多言語化されているので、そこから日本語以外を削る、という方法でも対応できると思います。

日本語化手順

前提

ask newでスキルのテンプレートが作られているところまでを前提とします。
公式ページ

記事を書くにあたり選択したオプションは以下となります。

ask new
  Please follow the wizard to start your Alexa skill project ->
  ? Choose the programming language you will use to code your skill:  NodeJS
  ? Choose a method to host your skill's backend resources:  AWS with CloudFormation
  ? Choose a template to start with:  Hello world             Alexa's hello world skill to send the greetings to the world!
  ? Please type in your skill name:  skill-sample-nodejs-hello-world
  ? Please type in your folder name for the skill project (alphanumeric):  Helloworld
  Project for skill "skill-sample-nodejs-hello-world" is successfully created at C:\Users\xxx\xxx\Helloworld

  Project initialized with deploy delegate "@ask-cli/cfn-deployer" successfully.

変更箇所一覧

変更箇所の一覧は以下です。

階層 ファイル 変更内容
. ask-resources.json ・AWSのリージョンを修正
skill-package skill.json ・ロケールを日本に修正
skill-package/assets en-US_largeIcon.png
en-US_smallIcon.png
・リネーム
skill-package/interactionModels/custom en-US.json ・リネーム
・発話を日本語化

初回のデプロイは上記変更の後に行うのがよいかと思います。
日本語化前にいきなりask deployをしてしまうとAWSの米国リージョンにデプロイされてしまい、東京リージョンだけ見ていると見つけられない&日本語化後に米国リージョンのリソースを消さなくてはいけない、ということが起きるためです。

変更内容詳細

それぞれの変更内容の詳細は以下です。

ask-resources.json

"awsRegion"をap-northeast-1にしておきます。これにより、東京リージョンにデプロイされるようになります。

ask-resources.json
{
  "askcliResourcesVersion": "2020-03-31",
  "profiles": {
    "default": {
        
      },
      "skillInfrastructure": {
        "userConfig": {
          "runtime": "nodejs10.x",
          "handler": "index.handler",
          "templatePath": ".\\infrastructure\\cfn-deployer\\skill-stack.yaml",
          "awsRegion": "ap-northeast-1"       //  <-- us-east-1から変更
        },
        "type": "@ask-cli/cfn-deployer"
      }
    }
  }
}

skill-package/skill.json

スキルの設定全般を管理するファイルです。localeをja-JPにします。
また、日本だけの対応とするため、isAvailableWorldwideをfalseに、distributionCountriesをJPにします。

skill.json
{
  "manifest": {
    "publishingInformation": {
      "locales": {
        "ja-JP": {    //  <-- en-USから修正
          "summary": "Sample Short Description",
          "examplePhrases": [
            "Alexa open hello world",
            "hello",
            "help"
          ],
          "name": "skill-sample-nodejs-hello-world",
          "description": "Sample Full Description"
        }
      },
      "isAvailableWorldwide": false,  //  <-- trueから修正
      "testingInstructions": "Sample Testing Instructions.",
      "category": "KNOWLEDGE_AND_TRIVIA",
      "distributionCountries": ["JP"]    //  <-- "JP"を追加
    },
    "apis": {
      "custom": {}
    },
    "manifestVersion": "1.0"
  }
}

skill.jsonは、スキルを公開するときにはより詳細に書き直す必要があります(説明や発話例を日本語化するなど)。

skill-package/assets/en-US_largeIcon.png、en-US_smallIcon.png

スキル用アイコンの画像ファイルです。そのままでも支障ないですが一応リネームしておきます。
en-US_largeIcon.png、en-US_smallIcon.png
 ↓
ja-JP_largeIcon.png、ja-JP_smallIcon.png

skill-package/interactionModels/custom/en-US.json

en-US.jsonからja-JP.jsonにリネームした上で内容を書き換えます。
スキルの呼び出し名などを日本語にしています(英語のままでも動きますが一応)。

ja-JP.json
{
    "interactionModel": {
        "languageModel": {
            "invocationName": "ハローワールド",  //  <-- hello worldから修正
            "intents": [
                
                {
                    "name": "HelloWorldIntent",
                    "slots": [],
                    "samples": [
                        "こんにちは"     //  <-- hello などから修正
                    ]
                },
                
            ],
            "types": []
        }
    }
  }

このとき、ファイルをUTF-8で保存しないとデプロイ時にエラーになるので注意が必要です。

デプロイ

ここまで変更できたら、ask deployでのデプロイにより、Alexa Developer ConsoleとAWSの東京リージョン上に反映され、
日本語化されたスキルを利用できるようになるはずです。

・Alexa Developer Console
alexa.png

・AWS
lambda.png

あとはどんどん書き換えていけばOKです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AlexaスキルのHelloWorldテンプレートを日本語化する

はじめに

Alexa Skills Kitコマンドラインインターフェース(ASK CLI)を使うとテンプレートから新しいスキルを作ることができますが、そのテンプレートの中のHelloWorldスキルは現状US版になっています。
グローバル対応させるつもりがないときは日本語化しておきたいため、変更内容をメモしておきます。

なお本記事では触れませんが、HelloWorld以外のテンプレートは日本語も含め多言語化されているので、そこから日本語以外を削る、という方法でも対応できると思います。

日本語化手順

前提

ask newでスキルのテンプレートが作られているところまでを前提とします。
公式ページ

記事を書くにあたり選択したオプションは以下となります。

ask new
  Please follow the wizard to start your Alexa skill project ->
  ? Choose the programming language you will use to code your skill:  NodeJS
  ? Choose a method to host your skill's backend resources:  AWS with CloudFormation
  ? Choose a template to start with:  Hello world             Alexa's hello world skill to send the greetings to the world!
  ? Please type in your skill name:  skill-sample-nodejs-hello-world
  ? Please type in your folder name for the skill project (alphanumeric):  Helloworld
  Project for skill "skill-sample-nodejs-hello-world" is successfully created at C:\Users\xxx\xxx\Helloworld

  Project initialized with deploy delegate "@ask-cli/cfn-deployer" successfully.

変更箇所一覧

変更箇所の一覧は以下です。

階層 ファイル 変更内容
. ask-resources.json ・AWSのリージョンを修正
skill-package skill.json ・ロケールを日本に修正
skill-package/assets en-US_largeIcon.png
en-US_smallIcon.png
・リネーム
skill-package/interactionModels/custom en-US.json ・リネーム
・発話を日本語化

初回のデプロイは上記変更の後に行うのがよいかと思います。
日本語化前にいきなりask deployをしてしまうとAWSの米国リージョンにデプロイされてしまい、東京リージョンだけ見ていると見つけられない&日本語化後に米国リージョンのリソースを消さなくてはいけない、ということが起きるためです。

変更内容詳細

それぞれの変更内容の詳細は以下です。

ask-resources.json

"awsRegion"をap-northeast-1にしておきます。これにより、東京リージョンにデプロイされるようになります。

ask-resources.json
{
  "askcliResourcesVersion": "2020-03-31",
  "profiles": {
    "default": {
        
      },
      "skillInfrastructure": {
        "userConfig": {
          "runtime": "nodejs10.x",
          "handler": "index.handler",
          "templatePath": ".\\infrastructure\\cfn-deployer\\skill-stack.yaml",
          "awsRegion": "ap-northeast-1"       //  <-- us-east-1から変更
        },
        "type": "@ask-cli/cfn-deployer"
      }
    }
  }
}

skill-package/skill.json

スキルの設定全般を管理するファイルです。localeをja-JPにします。
また、日本だけの対応とするため、isAvailableWorldwideをfalseに、distributionCountriesをJPにします。

skill.json
{
  "manifest": {
    "publishingInformation": {
      "locales": {
        "ja-JP": {    //  <-- en-USから修正
          "summary": "Sample Short Description",
          "examplePhrases": [
            "Alexa open hello world",
            "hello",
            "help"
          ],
          "name": "skill-sample-nodejs-hello-world",
          "description": "Sample Full Description"
        }
      },
      "isAvailableWorldwide": false,  //  <-- trueから修正
      "testingInstructions": "Sample Testing Instructions.",
      "category": "KNOWLEDGE_AND_TRIVIA",
      "distributionCountries": ["JP"]    //  <-- "JP"を追加
    },
    "apis": {
      "custom": {}
    },
    "manifestVersion": "1.0"
  }
}

skill.jsonは、スキルを公開するときにはより詳細に書き直す必要があります(説明や発話例を日本語化するなど)。

skill-package/assets/en-US_largeIcon.png、en-US_smallIcon.png

スキル用アイコンの画像ファイルです。そのままでも支障ないですが一応リネームしておきます。
en-US_largeIcon.png、en-US_smallIcon.png
 ↓
ja-JP_largeIcon.png、ja-JP_smallIcon.png

skill-package/interactionModels/custom/en-US.json

en-US.jsonからja-JP.jsonにリネームした上で内容を書き換えます。
スキルの呼び出し名などを日本語にしています(英語のままでも動きますが一応)。

ja-JP.json
{
    "interactionModel": {
        "languageModel": {
            "invocationName": "ハローワールド",  //  <-- hello worldから修正
            "intents": [
                
                {
                    "name": "HelloWorldIntent",
                    "slots": [],
                    "samples": [
                        "こんにちは"     //  <-- hello などから修正
                    ]
                },
                
            ],
            "types": []
        }
    }
  }

このとき、ファイルをUTF-8で保存しないとデプロイ時にエラーになるので注意が必要です。

デプロイ

ここまで変更できたら、ask deployでのデプロイにより、Alexa Developer ConsoleとAWSの東京リージョン上に反映され、日本語化されたスキルを利用できるようになるはずです。

・Alexa Developer Console
alexa.png

・AWS
lambda.png

あとはどんどん書き換えていけばOKです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】The procedure to deploy on EC2

Introduction

I am on my way to get a Ruby developer.
This article is a note for me, but I would be happy if helpful for someone.

Environment

  • macOS10
  • Rails 5.2.3
  • Nginx
  • Unicorn
  • Postgresql
  • Sidekiq
  • Redis

Create a EC2 instance

  • Select Amazon Linux AMI 2018.03.0(HVM,SSD Volume Type.
  • Select t2.micro(for within free tier)
  • Create a key pair.


Public DNS generated.
(This article referred:
https://qiita.com/Quikky/items/2897573a42fd71cfc47f)

Prepare to install rbenv

$ sudo yum install git
$ sudo yum -y install gcc
$ sudo yum -y install gcc-c++
$ sudo yum -y install zlib-devel
$ sudo yum -y install openssl-devel
$ sudo yum -y install readline-devel

Install rbenv

$ mkdir ~/.rbenv
$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
$ mkdir ~/.rbenv/plugins ~/.rbenv/plugins/ruby-build
$ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
$ cd ~/.rbenv/plugins/ruby-build
$ sudo ./install.sh
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ source ~/.bash_profile

Install Ruby

$ rbenv install 2.4.6
$ rbenv rehash
$ rbenv global 2.4.6
$ ruby -v

Install Bundler


$ rbenv exec gem install bundler -v 2.0.1
$ rbenv rehash

Create a project on GitHub

Push to GitHub

On Mac
$ git remote add origin <URL Address>                    
$ git add .                                          
$ git commit -m "1st push"                           
$ git push -u origin master                          

Pull from GitHub to EC2


$ git clone <URL Address>
$ cd <The project's directory>                       

Install Rails

$ gem i -v 5.2.3 rails
$ gem list rails                     
$ bundle install                   

The below command executed due to an error occurred.

$ gem install pg -v '1.1.4' --source 'https://rubygems.org/'

Install postgreSQL


$ yum install postgresql
$ sudo yum install postgresql-devel                   

To avoid the SQLite3's error


$ sudo yum install sqlite-devel                    

Configure instance's security group inbound

  • Configure Custom TCP/IP port 3000 0.0.0.0/0 additionally.

Start PostgreSQL on the EC2 instance


$ sudo yum install -y postgresql-server
$ sudo /sbin/service postgresql initdb
$ sudo /sbin/service postgresql start                    

Configure PostgreSQL on the EC2 instance


Master username:<the project's name>
Master password:<password>
postgres=# create role <username> with createdb login password '<password>';
postgres=# create database [database_name] owner [user_name];

$ sudo -u postgres psql
postgres=# create role <The project's name> with createdb login password '<password>';
postgres=# create database <the project's name>_production owner <The project's name>;
postgres=# create database <the project's name>_development owner <the project's name>;
postgres=# create database <the project's name>_test owner <the project's name>;
postgres=# \q                 

Create DB(Postgres)

.bash_profile
export POSTGRES_USERNAME="<The project's name>"
export POSTGRES_PASSWORD="<Password>"

The project's directory
$ rails db:create                     
 /var/lib/pgsql9/data/pg_hba.conf

local all all peer

     ↓

local all all md5

Modified                     
$ rails db:create
$ rails db:migrate                    

Configure SMTP

Configure the environment variable in .bash_profile.

EMAIL_ADDRESS
EMAIL_PASSWORD

After that, execute the below command to reflect it.

$ source .bash_profile                     
  • Launch Redis server on EC2.
  • Select ElasticCache.
  • Press 'Create'.

Primary endpoint generated.

Select 'security group' for Redis's inbound configuration on VPC configuration.

  • Add it on the inbound edition of sg-694f3715.
  • Custom TCP:TCP
  • port:6379
  • source 0.0.0.0/0

Configure the below files

config/initializers/sidekiq.rb
config/redis.yml                    

Restart the project and start Sidekiq

$ bundle exec sidekiq                      

Install Nginx

$ sudo yum install nginx

Copy /usr/local/etc/nginx/nginx.conf which is on Mac to EC2


$ scp -i ~/.ssh/<The project name名> nginx.conf ec2-user@XXXXXXXXXXXXXXXXXXXXX.amazonaws.com:~/nginx.conf
$ sudo cp ~/nginx.conf /etc/nginx/

Modify the port number and root directory.

Start Unicorn

$ unicorn -c config/unicorn.rb -E production -D                      

Start Nginx

$ sudo service nginx start                     

Add port80(HTTP) for VPS configuration.

Modify the permission of the home directory to 744(drwxr--r--)

$ chmod 755 ~/                     

Restart Nginx

$ sudo service nginx restart

Create DB on the production environment

$ rails db:migrate RAILS_ENV=production                      

Restart Unicorn

$ kill [pid]
$ unicorn -c config/unicorn.rb -E production -D                     

An error occured in the asset pipeline.

Modify config.assets.compile from false to true in config/environments/production.rb                  

↓↓↓↓↓↓↓ My detail
*https://kakuyon.hatenablog.com/entry/2018/07/15/03
3059 referred.
───────
*https://kakuyon.hatenablog.com/entry/2018/07/15/033059 referred.
↑↑↑↑↑↑↑ The detail of the edit request

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS EC2へのpingコマンドを使えるようにする

やりたいこと

パブリックサブネットのEC2にSSH接続をして、プライベートサブネットのEC2にpingで通信ができるかをチェックしたい。

やり方

プライベートサブネットのEC2のセキュリティグループで、
「ICMP(Internet Control Message Protocol)」を許可する。

※pingのプロトコルがICMP

参考

https://a1-style.net/cloud/aws/ping-icmp-setting/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS ネットワークACL「送信元は IPv4 または IPv6 CIDR ブロックにする必要があります。」

やりたいこと

AWSのネットワークACLで特定のIPからのアクセスを拒否する設定をしたい。

起きた問題

インバウンドールールの送信元にグローバルIPを入力したところ、
「送信元は IPv4 または IPv6 CIDR ブロックにする必要があります。」と表示されて保存できない。

解決策

CIDR「/32」(ユニキャスト)を追記する。
※1つのIPを指定する場合、/32(=255.255.255.255)を指定する。

参考

https://www.mrl.co.jp/download/manual-online/gl2000/gl2000_02/manual/docs/netlistc.htm

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SAA資格取得~ネットワークサービス編~

今回はVPCなどのネットワーク関連について!

VPCとは

AWS上に独立したプライベートネットワーク空間を作成できるサービス。
世界中のユーザーが利用するAWSにおいて、特定のユーザーだけ利用できるネットワーク環境を
構築することはセキュリティの観点から重要。

サブネットとは

VPC内に構成するネットワークセグメントのこと。
1つのVPCに対して1つ以上のサブネットで構成される。

ルートテーブル

サブネット内インスタンスに対する静的ルーティングを定義するもので、
設定はサブネット単位で行う。
ルートテーブル内のデフォルトゲートウェイ(0.0.0.0/0)へのルーティングに、
インターネットゲートウェイを指定したサブネットがパブリックサブネット
インターネットゲートウェイを指定してないサブネットがプライベートサブネット

パブリックサブネット
グローバル環境と通信できるサブネット。
通信先:インターネットゲートウェイ
パブリックIP:もつ
プライベートIP:もつ

プライベートサブネット
グローバル環境と通信できないサブネット。
通信先:NATゲートウェイ(※option)
パブリックIP:持たない
プライベートIP:もつ

プライベートサブネットはパブリックIPを持たない代わりに
NATゲートウェイに通信を行うことでパブリックIPに変換をしてもらって
グローバルネットワークに通信できるようになる。
NATゲートウェイはプライベート側からの通信は通すが、
外側からプライベート側への通信は行わない。

インターネットゲートウェイ(IGW)

VPC内のリソースからインターネットへアクセスするためのゲートウェイ。
IGWをVPCにアタッチすることでVPC内のリソースからインターネットへアクセスすることができる。

NATゲートウェイ

VPC内に構成したプライベートサブネットからインターネットに接続するためのゲートウェイ。
NATゲートウェイを利用しない場合、NATインスタンスと呼ばれるEC2インスタンスを利用して、
インターネットへアクセスする。

バーチャルプライベートゲートウェイ(VPゲートウェイ)

Direct ConnectやインターネットVPN接続するためのゲートウェイ。
オンプレミス環境と接続するVPCにアタッチして利用する。

VPCフローログ

VPC内のネットワークインターフェース(ENI)で通信するトラフィック情報をキャプチャするサービス。
キャプチャ情報はCloud Watch Logsへ転送される。

Elastic IP

固定のグローバルIPアドレスを提供するサービス。
EC2インスタンスにアタッチされてない場合やアタッチしているEC2インスタンスが停止されている
場合に料金が発生してします特徴がある。※グローバルIPの枯渇を防ぐため。

VPCピアリング接続

異なるVPC間をプライベート接続するサービス。
通常接続はできないが、VPCピアリング接続をすることによってインターネット接続せず、
プライベートネットワーク内で直せる通信することができる。

VPCエンドポイント

・ネットワークレイヤーのゲートウェイ型
⇨ルートテーブルに指定されたターゲットを追加することでS3やDynamoDBへアクセスする際、
インターネットを経由せずAWS内のプライベート接続を実現することができる。

・アプリケーションレイヤーのインターフェース型
⇨「AWS PrivateLink」とも呼ばれAWSへのAPIコールに対して、
インターネットを経由せずプライベート接続を実現することができる。

セキュリティグループ

EC2インスタンスなどに適用するファイアウォール機能。
EC2インスタンスから出る通信を制御するアウトバウンド、
EC2インスタンスへの通信を制御するインバウンドを設定しる。

主な特徴↓

・許可リストを設定することができますが、拒否リストは設定できません。
・インバウンドルールとアウトバウンドルールを設定することができます
・デフォルトで、インバウンドルールを追加をするまで、全てのトラフィックを拒否する設定になっています。
・デフォルトで、アウトバウンドルールを追加するまで、全てのトラフィックを許可する設定になっています。
・インバウンドのトラフィックに対するレスポンスは、アウトバウンドのルールに関係なく許可されます。
・許可リストを設定しなければ、セキュリティグループ内のインスタンスは互いにやりとりすることはできません。
(ただし、デフォルト状態のセキュリティグループに属する場合を除きます。)
・インスタンスの起動後、どのセキュリティグループに属するか変更することできます。
・セキュリティグループの設定変更・追加は即座に反映される。

ネットワークACL

サブネット単位で設定するファイアウォール機能。
アウトバウンド通信とインバウンド通信を設定する。

主な特徴↓

・VPC内に構成したサブネットごとに1つのネットワークACLを設定可能
・デフォルトは全て許可
・インバウンドとアウトバウンドそれぞれに対して許可または拒否を明示した通信制御が可能。
・ステートレス(セキュリティグループとは異なり、インバウンドとアウトバウンドに対する通信制御が必要)

セキュリティグループとネットワークACLの違いについて※参照

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS ソリューションアーキテクト 合格体験記 ~試験に合格するだけじゃ意味がないんだ!(負け惜しみ)~

今更ですが、AWS SAAに合格しました

スキルバックグラウンド

社会人3年目で入社以来一貫してオンプレミスのインフラエンジニアとして従事してきました。
たまに、サーバーサイドを開発したり、DevOps的なこともやってきました。
そのため、ソリューションアーキテクトの出題分野の技術的知識はありました。

調子に乗って不合格

俺インフラエンジニアだし、アソシエイトレベルの試験なんて余裕だろうと参考書を2日かけて読んで一度目の試験に挑みました。
まさかの不合格...
AWSのサービス名、細かな違いがさっぱりでした。点数が約30点足りませんでした。
付け焼き刃で合格できるほど甘くありませんでしたが、感触として1週間詰め込めば合格は容易だなと感じました。

ちなみに、使った参考書はこれでした。合格を目指すだけならこの参考書を読み込んで、公式ドキュメントで細かなところを確認すれば十分です。

AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト(
SBクリエイティブ)

再受験は最低でも2週間後

AWS認定ブログラムで同一試験を再度受けるには2週間空けなければいけません。
この2週間の間に試験を合格するためだけの勉強はやりたくないと思いAWSを実際にいじってみることにしました。

この技術書を元に簡単なシステムを構築しました。
この技術書はインフラに疎い方に是非一度読んで頂きたいです。
AWSどうこうの前にインフラシステムについて、一通りの知識がつくと思います。

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂3版
(日経BP)

無事合格

2回目の受験で無事に合格できました。
また、会社でUdemyを個人負担なしで受講できるため、以下講座を試験前に受講しました。

合格を経て

試験合格を目指すだけなら、【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問)を周回すれば簡単に合格できると思います。
ただ、合格してもAWSまともに使えないと思います。
AWSをある程度ベーシックな操作はできるようになる&試験合格を目指すなら、以下2つを実施すればいいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MTGカード評価投稿サイトの開発〜5週間でDjangoアプリリリース〜

はじめに

先日、「5週間でwebサービスリリース人集まれ!LTまでする人限定」という勉強会企画に参加し、約5週間の間Webアプリ開発・リリース作業を行った後、LTで成果物を発表しました。
本記事では作成したWebアプリの機能の紹介や開発経緯、企画に参加して感じたことについて記します。

勉強会企画のURL(connpass):
5週間でwebサービスリリース人集まれ!LTまでする人限定(オンライン開催に変更!)
5週間でwebサービスリリース人集まれ !! LT発表会

作成したWebアプリの概要

今回作成したのはトレーディングカードゲーム「Magic:The Gathering(MTG)」のカード評価コメントを投稿するサイトです。

作成したWebアプリのURL:
MTGカード評価投稿サイト

スクリーンショット 2020-05-17 14.41.08.png

構想自体は前々からあり、「DMvault」というデュエル・マスターズ関連のサイトを見たことがきっかけで、その中にある「カード評価集」という機能がMTGにもあったらいいなという思いで制作に挑戦しました。

主な機能として、メールアドレスとパスワードを登録してのサインアップ・ログイン機能と、ログイン者によるコメント投稿、自分のコメントの編集・削除を実装しています。
未ログイン者はコメント閲覧のみが可能であり、コメント投稿・編集・削除はできません。
サインアップ・ログイン機能について、入力されたメールアドレスに認証メールを送信しメール経由で登録完了させる機能や、メールアドレスにパスワード再発行メールを送る機能もあります。

Webアプリ開発の経緯

モダンな技術に触れるためにDjangoの学習を行っている最中にこの企画を知り、習うより慣れろでオリジナルのWebアプリをWeb上にリリースしたいと思って参加させていただきました。
期間中はDiscordの音声通話で週に1度のもくもく会および成果物発表を行い、完成後にDiscordでLT発表を行いました。
開発にあたっては以下の書籍を参考にしており、根本的には書籍中で作成するサンプルアプリを元に改造したものとなっています。

参考書籍:
動かして学ぶ!Python Django開発入門

主な使用技術

•Django
Pythonで動作するWebアプリフレームワークです。
モダンな言語といえばPythonだろうという漠然としたイメージで選んだため、他とは深く比較検討していません。
参考書籍の受け売りですが、会員制のWebアプリを作るなら、認証メール送信などの機能が元々備わっているDjangoの方が向いているようです。

•Bootstrap
Twitter社が開発したCSSフレームワークです。
無料テンプレートを適用しただけですが、手軽にスマホ・タブレット表示対応可能なことに驚きました。

•PostgreSQL
オープンソース系のリレーショナルデータベースです。
Djangoでデフォルトで使われているSQLite3ではデータが巨大になった場合に問題があるためこちらを使用します。

•AWS
Amazonが提供するクラウドサービスで、今回はリリース先仮想サーバとしてEC2インスタンス、メール配信サービスとしてAmazon Simple Email Serviceを使用しています。

企画に参加して良かったこと

  • 約5週間以内に完成させるという期限と、1週間に1回進捗発表というペース管理を設けることで、モチベーションを維持できました。
  • 書籍をなぞるだけでは理解できていなかった点について、オリジナルの画面や機能を盛り込む過程で気づいたり理解したりすることができました。
    • 例えば、データベースの定義を自動的に作成・管理するマイグレーションの概念について理解できておらず、オリジナルのテーブルを用意する際に苦労しましたが、結果的には思い通りに実現することができました。
  • 何より、初めてオリジナルのWebアプリを公開することができました。

今後の課題

  • 画面から画面への値の受け渡しが一部うまくいかず、場合によっては前画面からURLに値を渡してなんとかしている箇所もあるため改善する必要があります。
  • 戻るボタンが無いなど画面遷移が不親切であり、コメント投稿後にかなり前の画面に戻る(そうしないとエラーを吐く)という問題もあります。
  • あったほうがいいけど実装できていない機能が山積みとなっています
    • カードセット一覧、カード一覧のデータを公式APIから取得(現在は一つ一つ手作業でDBに登録しています)
    • カードやコメントの検索フォーム
    • コメント投稿数が多いカードをランキング表示

期限が決まっていたことや、Djangoに関してまだ初心者であるため粗削りな点が多いです。

最後に

DjangoやAWSについてほぼ素人であることから開発にあたって不安もありましたが、今回の企画を通して様々な知識や貴重な経験を身に付けることができました。
本記事内の記述に誤り等ございましたらご連絡をお願いいたします。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CloudFormationで既存IAMロールのポリシーを自動で追加するにはどうしたら良いかを考えた

はじめに

CloudFormationをやっていると大体ハマるのがIAM部分で、最小権限とか考え始めるとかなり頑張ってロールやポリシーの設計をしなければいけない。
CloudFormationで「こうやったらどう動くの?」が分かっていないと正しい設計もできないので、色々試してみる。

ゴールは「CloudFormationで自動構築されたリソースをIAMの最小権限付与のベストプラクティスに従って管理するにはどうやるのが良いか」が考えられることだ。もちろん、人力で管理するのは自動構築の意味がなくなってしまうので、あくまでもCloudFormationテンプレートの中で完結することを考える。

前提条件

  • IAMをなんとなく理解している(グループ、ユーザ、ロール、ポリシーの違いが分かっていれば充分かな……)
  • CloudFormationでIAM関連のリソースを作ったことがある

さすがにこの辺が分からないと読んでもサッパリだと思うので……

IAMへの理解を深めたい人は、BlackBeltオンラインセミナーをちゃんと観ておくと良い。
【AWS Black Belt Online Seminar】AWS Identity and Access Management (AWS IAM) Part1
【AWS Black Belt Online Seminar】AWS Identity and Access Management (AWS IAM) Part2

あと、書籍なら『AWSの薄い本 IAMのマニアックな話』あたりも分かりやすい。

実験① IAMのインラインポリシーへの追記はできるか

まずはIAMロールとベースになるポリシーを作る。

以下の2つのCloudFormationテンプレートを順次実行して、IAMロールとベースになるポリシーを作ろう。省略しているが、それぞれAWSTemplateFormatVersion: "2010-09-09"は先頭に記述すること。ポリシーに設定する値は今回は何でも良いのでテキトーに。

01_IAMRole.yml
Resources:
  IAMPOLICY:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: TestPolicy1
      Roles:
        - !ImportValue TestRoleName
      PolicyDocument: 
        Version: "2012-10-17"
        Statement:
          - Sid: TestPolicySid2
            Effect: Allow
            Action:
              - "codepipeline:GetPipeline"
            Resource: "*"
02_IAMPolicy_Add.yml
Resources:
  IAMPOLICY:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: TestPolicy1
      Roles:
        - !ImportValue TestRoleName
      PolicyDocument: 
        Version: "2012-10-17"
        Statement:
          - Sid: TestPolicySid1
            Effect: Allow
            Action:
              - "sns:Publish"
            Resource: "*"

さて、この状態でTestRoleForIAMのユーザにアタッチされているインラインポリシーを参照すると、以下のようになっている。まあ、そうなるように設定したのだから当たり前だ。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sns:Publish"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "TestPolicySid1"
        }
    ]
}

別のCloudFormationのスタックから同一ポリシーを更新する

以下のCloudFormationテンプレートでスタックを作成して、TestPolicy1を更新してみる。
差分としては、Sidを変えていることと、許可するアクションを変えているところだ。
これをちゃんと差分として検知して追記してくれると良いのだが。

03_IAMPolicy_Upd_AddSid.yml
Resources:
  IAMPOLICY:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: TestPolicy1
      Roles:
        - !ImportValue TestRoleName
      PolicyDocument: 
        Version: "2012-10-17"
        Statement:
          - Sid: TestPolicySid2
            Effect: Allow
            Action:
              - "codepipeline:GetPipeline"
            Resource: "*"

だがしかし、これを実行した後のTestPolicy1のインラインポリシーは以下の様になっていた。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "codepipeline:GetPipeline"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "TestPolicySid2"
        }
    ]
}

つまりは、Sidを変えたところであくまでも「上書き更新」という動作になってしまうようだ。
しかも、スタックを削除したとしてもこの上書きされた内容は戻らなかった。インラインポリシーはバージョンの概念がないので元の値が何だったか、場合によっては分からなくなってしまうだろう。これは気を付けなければいけないポイントになりそう。

今回、インラインポリシー

で実験したから分からないが、管理ポリシーでやってみるとバージョンが上がって、削除時には戻るのだろうか。

実験② IAMの管理ポリシーの場合はどうか

というわけで、今度は管理ポリシーで試してみる。

04_IAMManagedPolicy_Add.yml
Resources:
  IAMPOLICY:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName: TestManagedPolicy1
      Description: ManagedPolicy for test
      Roles:
        - !ImportValue TestRoleName
      PolicyDocument: 
        Version: "2012-10-17"
        Statement:
          - Sid: TestManagedPolicySid1
            Effect: Allow
            Action:
              - "sns:Publish"
            Resource: "*"

で管理ポリシーを作成し、

05_IAMManagedPolicy_Upd_AddSid.yml
Resources:
  IAMPOLICY:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName: TestManagedPolicy1
      Roles:
        - !ImportValue TestRoleName
      PolicyDocument: 
        Version: "2012-10-17"
        Statement:
          - Sid: TestManagedPolicySid2
            Effect: Allow
            Action:
              - "codepipeline:GetPipeline"
            Resource: "*"

で更新を試みる。すると……

キャプチャ.PNG

な、なんだってー!(AA略)

たしかに、ユーザーガイドを見てみると、以下のような差分があり、ManagedPolicyには更新の機能が無いようだ。

・AWS::IAM::Policy

指定の IAM ユーザー、グループ、またはロールに埋め込まれたインラインポリシードキュメントを追加または更新します。

・AWS::IAM::ManagedPolicy

AWS アカウント用に新しい管理ポリシーを作成します。

このオペレーションでは、v1 のバージョン識別子を持つポリシーバージョンが作成され、ポリシーのデフォルトバージョンとして v1 が設定されます。ポリシーのバージョンの詳細については、IAM ユーザーガイドの「管理ポリシーのバージョニング」を参照してください。

つまりは、最小権限をCloudFormationの単独のポリシーのみで実現しようとすると、純粋な更新を行うのは難しいように思える(あえて絞った言い方をしたのは、CLIだったら実現できる可能性が高いため。未検証)。

ではどうするか?

ここまでの検証結果から考えると、権限の付与を自動で行うのであれば、新しいポリシーを追加してロールやユーザにアタッチすることが効率が良いと考えられる。
そうした場合、今度は上限が気になってくる。

【AWS公式】IAM および STS の制限

このドキュメントを確認すると、

リソース デフォルトの制限
AWSアカウントのカスタマー管理ポリシー 1500
IAMロールにアタッチされた管理ポリシー 10

とある。上限緩和は可能なようであるが、つまりはそんなに無闇にアタッチしてくれるなということのような気もする。
また、上記はあくまでも「管理ポリシー」なので、インラインポリシーの話はしていない。
では、インラインポリシはどれだけ追加できるだろうか?

実験③インラインポリシーを追加しまくる

↓あんまりちまちまとやるのも面倒なので、とりあえず一気に100くらいインラインポリシ追加してみるぞ!と思い以下のスクリプトを書いて流す。

#!/usr/bin/python3

print('AWSTemplateFormatVersion: "2010-09-09"');
print('Description:');
print('  Test Policy for IAM');
print('');
print('Resources:');

for i in range(1,101):
  print('  IAMPOLICY%d:' % i);
  print('    Type: AWS::IAM::Policy');
  print('    Properties:');
  print('      PolicyName: TestPolicy%d' % i);
  print('      Roles:');
  print('        - !ImportValue TestRoleName');
  print('      PolicyDocument:');
  print('        Version: "2012-10-17"');
  print('        Statement:');
  print('          - Effect: Allow');
  print('            Action:');
  print('              - "sns:Publish"');
  print('            Resource: "*"');

よし!100個はいけた!実際どこまでいけるかは気になるものの、100あれば充分実用に耐え得るし、マニュアルに記載がないということはひとまず「どこまでも」いけるのだろう。

キャプチャ2.PNG

結論

ということで、CloudFormationの中で自動で最小権限を管理するには、↑に書いたように

  • 新しいポリシーを追加してロールやユーザにアタッチする

が手間がかからずに対応することが可能であると考える。
多少冗長ではあるけど…。
CLIでPolicyDocumentを参照してきて編集してから書き込めばいいじゃんとかはあるかもしれないが、できれば使うサービスは一択で頑張りたいし……。そういう意味ではCDKならもう少し柔軟に対応できる気がしなくもないが、試していないので今回はここまで。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Go言語を1から勉強してアプリを作り、仮想通貨の自動取引で1ヶ月1万円の利益が出た話

概要

元々Javaエンジニアの私がGo言語を1から学習して、仮想通貨の自動売買を行うWebアプリケーションを開発しました。
開発したアプリはクラウド上にデプロイし、1ヶ月弱運用を行った結果、1万円以上の利益が出ました。
その過程を綴った記録になります。

実際に作成したアプリのソースコードは以下
↓↓↓
https://github.com/Kohei-Sato-1221/BitcoinTrading_Golang

Go言語でのアプリ開発をしようと思った経緯

私はJavaがメインスキルだったのですが、「最近Go言語が流行っている!」という話を聞いて、
1から勉強しようと思いました。単に文法を学習するだけだとモチベーションがわかないので、
「GoでWebアプリを作って、Githubに公開する」
を目標に活動をはじめたのです。

なんで仮想通貨の自動取引を選んだのか?

理由は以下です。

  1. 元々仮想通貨やブロックチェーンに興味持っていて、いくつかの取引所にアカウントを保有していた。
  2. 各仮想通貨取引所は売買のためのAPIを豊富に用意していることが多い。
  3. 株などの金融商品に比べてわりと少額から取引できる。bitflyer使えば0.001BTC(執筆時点で約1000円)から注文可能。
  4. ボラティリティ(一日の価格変動)が高い。
  5. 24時間365日取引ができる。

Go言語の文法を学習

文法や環境構築の方法に関しては
ドットインストールの動画
スターティングGo言語の書籍
を使って学習しました。

ドットインストールのGo言語入門の動画に合わせて、実際に手を動かして環境構築や文法を一通り勉強しました。

スターティングGo言語の方がどちらかと言えばリファレンスみたいな使い方をしました。
ちょっと動画ではわかりずらかったり、復習したりしたい場合などは書籍が便利でした。

エディタは無料のVSCodeを使用しました。
デバッグもやりたかったので、GoのプラグインをVScodeに入れました。

Go言語を学習した感想 ~良いところ~

  • シンプルな記述でやりたいことが簡単にできる。数行のコードでWebサーバー作れたりして、すごいなーって思いました。
  • 記述のお作法がGoogle側で指定されていて書き方にあまり困らない。
  • 並列処理が書きやすい(goroutineがめっちゃ便利)

Go言語を学習した感想 ~苦戦したところ~

  • 変数を宣言しても使わないとコンパイルエラーになる。動作確認時とかに不便だった。
  • channel・ポインタの使い方を理解するのに苦労した。
  • 結局GOPATHをどのように設定したら良いかわからなかった(上手くビルドができなくて export GOPATH=xxxxxx を何回も実行した....:joy:)
  • ネットで検索するとき関係ない情報がヒットしがち(ポケモンGOとか笑)
  • Javaと違ってオブジェクト指向じゃないので、ファイルの構成とかどーしたら良いのか悩むことがしばしば...

自動取引アプリの開発に着手

Goの基本をおさえたところで自動売買アプリの開発に着手しました。
この時点で作ろうと思ってたアプリはざっくり以下のような感じ。

  • スケジューラーで定期的に買い注文を入れる。
  • 買い注文が約定したかを定期的にチェックし、約定したら約定価格よりも少し高い価格で売り注文を入れる。
  • 上記のデータをDBで管理し、どれくらいの利益が出たかを日次で把握できるようにする。
  • AWS(EC2) or ラズベリーパイにアプリをデプロイして、運用をしてみる。

基本的にはこのとき思い描いていた通りのアプリが出来上がりました。

取引所の選定

私は複数の仮想通貨取引所のアカウントを持っていたのですが、
このアプリ開発で私はbitflyerを選択しました。

私はZaif、bitbankのAPIを使ってJavaアプリの開発をしたことがあり(※)、APIを使ったことがない取引所を使ってみよう!、という浅い理由でbitflyerを選択しました。

※ Zaif、bitbankのAPIを使って、日次で仮想通貨の積立売買を行うSpringBootのアプリケーションを既に開発済み(https://github.com/Kohei-Sato-1221/CryptoTrading_SpringBoot)

Go言語での開発をスタート

ここからはネットの情報や書籍を利用して、ひたすら開発を進めました。
そこまで苦労した部分はなかったのですが、基本の文法学習では対応できず、ネットで調べて試行錯誤した点は以下です。

(1) configファイルの読み込み
APIキーやDBの接続情報は外部ファイルに記載するようにしたいと思いました。
gopkg.in/ini.v1というライブラリが有効ということで、これを使いました。

(2) Mysqlとの接続
github.com/go-sql-driver/mysqlというドライバーが有名らしいので採用しました。
JavaではもちろんDBの連携をやったことがあるのですが、ちょっと勝手が違う部分もあり、試行錯誤に苦労しました。

(3) 取引所APIのリクエスト
取引APIなどのAPIキーが必要なPrivateAPIを使う場合は、HTTPリクエストヘッダに認証情報を入れないといけません。
bitflyerの場合だと

"ACCESS-KEY":APIキー,
"ACCESS-TIMESTAMP": タイムスタンプ,
"ACCESS-SIGN": ※bodyやタイムスタンプを含めた値をHash化して、キーでSignした値
"Content-Type":"application/json"

が必要になります。
ACCESS-SIGNの値が少しでも間違うと認証されないので、試行錯誤して正しいリクエストを出せるようにしました。

HTTPリクエスト作成、HASH化、SIGNなどは基本的にGoのライブラリでカバーできるので、Go特有の部分での苦労はありませんでした。

自動取引アプリの構成図

最終的には以下のようなアーキテクチャのアプリが完成しました。
スクリーンショット 2020-05-17 11.12.14.png

【TABLE】
(1)買い注文テーブル
買い注文の取引ID、金額、数量、ステータスを管理するテーブルです。

ステータスに関しては、「未約定」、「約定済み」、「売り注文発注済み」の3つのステータスがあります。
注文情報同期JOBにて買い注文の情報をInsertします。この段階ではステータスは「未約定」、
約定確認JOBで買い注文の約定が確認されれば、ステータスは「約定済み」に変更、
売り注文JOBで特定の買い注文に対応する売り注文が発注された場合、ステータスを「売り注文発注済み」に変更します。

(2)売り注文テーブル
売り注文の取引ID、金額、数量、ステータス、親取引IDを管理するテーブルです。

ステータスに関しては「未約定」「約定済み」の2つで、約定確認JOBでステータス変更します。

親取引IDは該当の売り注文に対応する買い注文の取引ID、になります。
買い注文の金額に+αした金額の売り注文を出す、という仕組みなので、このようなカラムを追加しています。

【JOB】
(1)買い注文JOB
一日数回、特定の時間に買い注文を発注するJOBです。成行ではなく指値での注文です。

発注する価格に関しては、
1. 現在価格のxx%低い価格
2. 現在価格と、24時間内の最低価格の平均値
などシンプルなロジックで実装していました。

発注する数量、金額、頻度は運用しながら調整しました。
最終的には以下の通りになりました。

  • 大体2時間おきに買い注文を入れる
  • 注文する通貨は、BTCとETHの現物(レバレッジ取引はやらない)
  • BTCの1回あたり発注数量は0.006BTC or 0.009BTC
  • ETHの1回あたり発注数量は0.2ETH or 0.3ETH

(2)売り注文JOB
買い注文テーブルから「約定済み」のステータスの買い注文の情報一覧を取得します。
その後、bitflyerのAPIを叩いて売り注文を入れます。

売り注文を入れた後、買い注文テーブルのステータスupdate及び、売り注文テーブルに注文情報のinsertを行います。

売り注文の数量は、元々の買い注文の数量と同じで、価格に関しては買い注文価格の+1.5%としました。
この1.5%という数字に明確な根拠はないのですが、日々BTCやETHのチャートを見ていると、数%の上昇・下落が頻繁に見られるので、1.5%くらいならすぐ約定するかな、という想定で決めました。実際に運用してみると想定通りには売り注文が約定しているように思います。

実行頻度は45秒に1回としました。

(3)注文情報同期JOB
買い注文の情報をbitflyerから取得し、買い注文テーブルへデータを同期するJOBです。
この時、買い注文JOBで入れた注文かどうかは区別しません。つまり、手動で入れた買い注文も同期の対象としました。(この仕様にした理由は後述します)

実行頻度は40秒に1回としました。

(4)約定確認JOB
買い注文・売り注文が約定しているかどうかをbitflyerから取得し、買い注文テーブル・売り注文テーブルのステータスを変更します。

実行頻度は45秒に1回としました。

運用実績(2020年4月20日~5月17日)

2020年4月20日から、1ヶ月弱、運用を行ってみました(実際はもっと前から運用していたのですが、利益管理機能を実装していなかったので、2020年4月20日からのデータしか存在しないのです:sweat_smile:

運用実績は以下です(1日あたりの利益は、売り注文が約定した日付でカウントしています)

合計利益:1万6,765円 一日平均:605円

スクリーンショット 2020-05-17 13.51.36.png

スクリーンショット 2020-05-17 13.51.44.png

日付 1日あたり利益(円) 累計(円)
04/20 185.92 185.92
04/21 140.72 326.64
04/22 410.94 737.58
04/23 855.04 1,592.62
04/24 67.15 1,659.77
04/25 130.97 1,790.74
04/26 288.46 2,079.2
04/27 98.28 2,177.48
04/28 161.21 2,338.69
04/29 703.34 3,042.03
04/30 2,223.58 5,265.61
05/01 330.82 5,596.43
05/02 225.37 5,821.8
05/03 244.29 6,066.09
05/04 757.07 6,823.16
05/05 348.14 7,171.3
05/06 277.91 7,449.21
05/07 1,037.3 8,486.51
05/08 685.99 9,172.5
05/09 63.02 9,235.52
05/10 1,953.49 11,189.01
05/11 1,381.77 12,570.78
05/12 731.35 13,302.13
05/13 379.61 13,681.74
05/14 1,374.74 15,056.48
05/15 618.21 15,674.69
05/16 1,090.55 16,765.24
1日平均 605.18

結果的に28日間で1万5000円以上の利益が出ました。1日あたりの利益も600円超とワンコインを超えました。
毎日軽いランチ一食分は浮いてたなー、という気分です。

しかし、本当はもっと利益が出る可能性がありました。というのもの、途中で買い注文の発注数量を増やしたためです。最終的には「自動取引アプリの構成図」で説明した通りの数量になっているのですが、4月20日の時点での購入数量はもっと少なかったのです。

一ヶ月弱運用してみて、結構安定的に利益が出ていることがわかったので、今後はさらに発注数量や買い注文を入れる頻度を高めたいと思います。(単純に購入する数量を2倍にしていれば、利益も2倍になったはずですので、、、、)

工夫した点

(1) Goのプロセスが落ちる
原因が不明なのですが、Goのプロセスが落ちていることがたまーにありました。
Goに対する経験不足で、原因がわからないという状況でした。
苦肉の策として、
「プロセスが動いているか監視して、落ちていたらアプリを再起動する」
というシェルスクリプトを作り、cronで1時間に1回実行するようにしました。

しかし、これは根本的な原因解決ではないので、もう少しGOに関する知見を深め、停止しないようなアプリに改修できればと思っています。

(2) APIの呼び出し制限
bitflyerのAPIでは、Private APIの呼び出し回数が5分間で500回までと制限があるようです。
実装しはじめの頃はこの点を完全に無視して、APIリクエストを投げまくっていたため、注文情報の確認JOBなどで急にエラーが発生する事態が起きました。

注文情報等を取得する際はなるべく一括で取得(個別の注文IDに対してリクエストを一回一回投げない)

JOBの頻度を減らす

といった手段で解決を図りました。

(3) マニュアルで買い注文いれた際の挙動
基本は

JOBによる買い注文 → 買い注文の約定チェック → 約定したら売り注文

をひたすら繰り返すアプリなのですが、買い注文を手動で入れた場合も、約定チェックの対象としたい
と考えました。

つまり、bitflyerの注文画面から買い注文を入れた場合でも、その情報をDBに格納し、その注文を約定確認JOBの対象として、約定後にJOBで売り注文を発注するようにしたい、ということです。

アプリの初回の実装時は、買い注文JOBにてDBに買い注文のデータをinsertするようにしていたのですが、その方法だとJOBで入れた買い注文のみがDBに登録されます。この仕組みを変更し、定期的に注文情報をDBに同期する「注文情報同期JOB」を新規実装することで対応しました。

今後の課題

  • テクニカル分析を用いて売買のタイミング等を判別したい。
  • レバレッジ取引に挑戦(現状は現物取引のみ)
  • バックテストの機能を実装したい。→ 新しい売買ロジック作ったときにシュミレーションできるように。
  • 他の取引所(海外取引所を含む)を使って幅広くAPI取引。→ 最近ではOKEXという海外取引所のAPIを呼び出す機能も実装してみました。
  • 通貨価格が高騰・暴落した際に、買い注文・売り注文が約定せずにずっと残ってしまう。なんらかの対応を考えたい、、、、
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【2020年5月版】AWSのサービスをゆるく大体3行で

はじめに

本記事はAWS SAAの勉強中に、「とりあえず主要なサービスの概要ぐらい知っておいたほうがいいよな...」と思い立ち、自分用にまとめたものです。

2/3ほど記事を作成した後に見つけてしまった(悶絶) クラスメソッド先生の 【2020年】AWS全サービスまとめ がこの上なく、コンパクトで的確にまとまっていた ので、こちらを見たほうがいいと思います(本末転倒)

各サービスの雰囲気を掴むぐらいの温度感で見ていただければ(逃げ道)

対象のサービス

本記事で取り扱うサービスは2020年5月時点のAWSマネジメントコンソールの

スクリーンショット 2020-05-16 11.16.53.png

ここをクリックした際に表示されるサービス群が対象です。

スクリーンショット 2020-05-16 11.17.21.png

結構な頻度でレイアウトが変更されたり、サービスが追加されるので 「おい!!!このサービスが書いてねーぞ!!!」 とかは許してほしいのだ(ハム太郎)

コンピューティング

アプリケーションを動作させるためのマシンリソースを提供するサービス群。

EC2(イーシーツー)

EC2はElastic Compute Cloudの略。

従量課金の仮想サーバー。
実現したいワークロードに応じた必要な性能のインスタンスタイプ、ストレージを選択してすぐ起動、運用ができる。
どう運用するかは自由なのでセキュリティ対策やパッケージの管理なども自分でやる必要がある(つらい)

Lightsail(ライトセイル)

従量課金のVPSサービス。
EC2との違いは固定リソースで他のAWSサービスを利用した拡張などに制限がある。
その分安いので個人開発用途や、そこまで可用性が求められない社内向けのシンプルなアプリケーションの運用などには便利かも。

Lambda(ラムダ)

サーバ管理なしで好きな言語で記述したコードを実行できるサービス。
サーバ管理が不要でコードを書くだけで処理が出来る噂のServerless(言いたいだけ)を実現できる。
AWS API Gatewayと連携してREST APIを構築したり、他AWSサービスと連携したりと多種多様な用途に利用することができる。
いちばんしゅきなAWSサービス

最近RDSプロキシという機能が提供されて、コネクション管理の問題から以前までは推奨されなかったRDBMSとの連携もやりやすくなった。

Batch(バッチ)

AWS Lambdaで処理しきれない規模の大規模計算を処理するサービス。
処理させたいジョブを定義して、EC2からコンテナを起動して分散処理。
Lambdaの制限時間、リソース制約の範疇で対応可能な処理ならLambdaで十分。それ以上の処理をBatchで担当する。

ElasticBeansTalk (エラスティックビーンズトーク)

よくあるWebアプリケーション構成をワンセットで作って管理するサービス。
自前でゼロから環境を作ろうとするとVPCの設計やEC2起動からのパッケージインストールとかを手動でやる必要があるけど、数クリックで作ってくれるすごいやつ。
類似サービスだとherokuとかそこらへんかな?

Serverless Application Repsitory(サーバレス アプリケーション リポジトリ)

サーバレスアーキテクチャ用のリポジトリ。
AWS SAM(※)とコードをセットで管理して、ワンクリックで環境を構築できるリポジトリを作成できる。
他所様が公開しているリポジトリを使って同じ環境も再現できる。

※ AWS ServerlessApplicationModel(サーバレスアプリケーションモデル) ... AWS CloudFormationをよりサーバレスアーキテクチャが定義しやすいようにしたやつ

AWS Outposts (アウトポスツ)

AWSのクラウドインフラと同じシステムをオンプレで構築してくれるサービス。
クラウドはコンプライアンス的にちょっと...、クラウドだとレイテンシーがね...という企業でもクラウド版AWSと同じ感覚でオンプレに構築したAWSサービスを利用できる。
ただし、対応しているサービスは一部のみ。

EC2 Image Builder (イーシーツーイメージビルダー)

EC2で利用するカスタムAMIの生成管理を行ってくれるサービス。
指定したベースAMIに対してインストールするパッケージなどをGUIで選択可能。
めんどくさいイメージ管理を自動化してくれたりするニクいやつ。

ストレージ

データストレージを提供するためのサービス群。

S3(エススリー)

S3とはSimple Storage Serviceの略

容量無制限のデータ保存ができるオブジェクト型ストレージ。
別のサービス拠点のストレージに分散して保存するため安心・安全。
オブジェクトのライフサイクル管理でAWS S3 Glaicierへの移動なども可能なので、「オラ、いっぺぇのデータを安全に安く保存してぇぞ!(悟空)」 という方はお世話になると思う。

S3 Glaicier(エススリーグレイシャー)

大容量、低アクセスのデータを保存するのに適したS3ストレージ。
通常のS3よりも保存料金が安いがデータの取り出しに時間とお金がかかる。
すぐに利用しないビックデータや大量の過去ログなどの格納先として向いている。

ちなみに更に安く保存できる代わり、通常のGlacierよりもデータ取り出しに時間がかかる S3 Deep Archive Glacier(かっこいい) なるサービスもある

EBS(イービーエス)

EBSはElasticBlockStoreの略

EC2用のネットワーク経由でマウントされるブロック型ストレージ。EC2にアタッチして利用される。
原則(※)1つのEBSを複数のEC2にはアタッチできない。(共有ストレージとしては使えない)
パソコンのSSD/HDD的な役割を提供するサービスだと思えばいいかも。

最近特定のEBSタイプ限定で複数EC2にアタッチできるようになったとか...

EFS(イーエフエス)

EFSはElasticFileSystemの略

EC2用のネットワーク経由でマウントされるファイル型ストレージ。EC2にアタッチして利用される。
複数のEC2にマウントが可能であるため、共有ストレージとして利用することができる。
ただEBSよりやっぱり高い(大体3倍)。用途を選んで使うのが吉。

FSx(エフエスエックス)

サードパーティのファイルシステムをフルマネージドで提供するサービス。
Amazon FSx for Windows File ServerAmazon FSx for Lustre の2つが提供されている。
Windows向けのファイルサーバをAWSで構築する場合に利用を検討するといいかも。

Storage Gateway(ストレージゲートウェイ)

S3、GlaicierをNFSとして扱えるようにしたりするサービス。
他にもディスクデータをまるごとS3にスナップショットとしてバックアップする機能やGlaicierをテープ媒体として利用できるようにする機能なんかもある。
「オンプレ環境でもS3にデータを保存してぇよ...」とかの場面で本サービスを使えばNFSのファイルサーバとしてS3を意識しなくてもデータを保存することができちゃう。

Backup(バックアップ)

EBS、EFS、RDS、DynamoDB、Storage Gatewayのデータバックアップを取るサービス。
バックアップのスケジューリング、バックアップの有効期限などを設定して自動でバックアップが取得できる。
バックアップの形式はそのサービスのバックアップ形式に基づく(EBSならEBS Snapshot)
「バックアップ手動で取るのだりぃ...」兄貴の強い味方。

データベース

データを格納するためのデータベースに関するサービス群。

RDS(アールディーエス)

Relational Database Serviceの略

MySQL、PostgreSQL、Oracle...etcといったRDBMSをフルマネージドで利用できるサービス。
自前で構築するとめんどくさいmaster/slave構成やリードレプリカの構築を数クリックでやってくれる。
標準で自動バックアップ機能などもついて至れり尽くせり。

ちなみにMySQLとPostgreSQLはAurora(オーロラ)というクラウドに最適化されたRDSの拡張版のサービスを利用することができる。

DynamoDB(ダイナモディービー)

Amazon独自開発のNoSQLデータベースをフルマネージドで提供するサービス。
データは自動で3箇所のAZに保存されるため安心。
サービス特性を理解しないと落とし穴が多いので、利用の際はまずBlackbeltを要一読。

ElasticCache(エラスティックキャッシュ)

フルマネージドな高速インメモリデータベースを提供するサービス。
memcachedとredisがサポートされている。
RDSの前段に置いてクエリキャッシュとしたり、EC2上のセッションを管理するようにしてインスタンスをステートレスにしたりできまし。

Naptune(ネプチューン)

オブジェクトの関連を直感的に表現できるグラフ型データベースをフルマネージドで管理するサービス。
一般的なグラフモデルである Property Graph と W3C の RDF、それぞれのクエリ言語である Apache TinkerPop Gremlin と SPARQL がサポートされている。(わかってない)

グラフ型データベース勉強します。。。

Redshift(レッドシフト)

高可用性でペタバイト級までスケーラブル可能なデータウェアハウスをフルマネージドで提供するサービス。
SQLライクに蓄積されたデータを処理してことが可能。
Redshift Spetrum(スペクトラム)を利用することでRedshift用にデータを整形して格納しなくても、直接S3上のデータを対象にクエリを投げられるように。

QLDB(キューエルディービー)

QLDBはQuantum Ledger DataBaseの略

フルマネージドな改ざん不可能な台帳データベースを提供するサービス。
ブロックチェーンのように分散的ではなく中央集権的に台帳(テーブル)と操作履歴(トランザクション)を管理する。
SQLライクに操作可能で、一度発行したトランザクションは絶対に改ざんできない。

DocumentDB(ドキュメントディービー)

MongoDB互換のJSONライクなデータを格納するドキュメント型データベースを提供するフルマネージドサービス。
オンプレで動かしていたMongoDBのエコシステムを簡単に移行可能。
トランザクションのサポートはないため、トランザクションが必要な場合はRDS。

Keyspaces(キースペース)

Apache Cassandra互換の分散型KVS NoSQLデータベースをフルマネージドで提供するサービス。
Cassandraの特徴であるRDBMSを操作するようなクエリでKVSでアクセスできるのがウリ。
オンプレで動かしているCassandraのエコシステムの移行にも。

※ 2020/4/23まではプレビュー版としてManagedCassandraService(マネージドカサンドラサービス) という名称だった

移行と転送

オンプレ ⇔ AWSクラウドへの移行とデータ転送などに関するサービス群。

Migration Hub(マイグレーションハブ)

オンプレからAWSへの移行進捗状況をトータルサポートするサービス。
後述する移行関連のサービスで収集した情報を統合的に確認できるダッシュボードを提供している。
オンプレからAWSへの大規模移行などの際にはお役立ち。

Application Discovery Service(アプリケーションディスカバリーサービス)

オンプレミスサーバの情報(負荷状況など)を収集し、移行時に最適なインスタンスタイプなどを提案してくれるサービス。
情報収集の基本パターンは対象サーバにエージェントをインストールする方法が取れる情報も多くて推奨。
VMWare経由仮想サーバであれば、エージェントなしでも収集できるが取得できる情報は少ない。

Server Migration Service(サーバーマイグレーションサービス)

VMWareで動作しているオンプレミスサーバをEC2に簡単に移行する機能を提供するサービス。
移行条件に合致した場合、GUI上で操作が完結してEC2を起動できるAMIを生成する。

Database Migration Service(データベースマイグレーションサービス)

オンプレ⇒RDS、RDS⇒RDSといったRDBMSの簡単なマイグレーションを提供するサービス。
移行だけの用途ではなく、レプリケーション用途としての利用も可能。
異なるRDBMS間での移行も可能。(Oracle ⇒ MySQLなど)

Transfer for SFTP(トランスファー フォー エスエフティーピー)

S3をSFTPサーバとして扱うことができるようにするサービス。
ファイルサーバの用意がかったりーよーと言う時に使える。
ただし結構高い。

Snowball(スノーボール)

ペタ・エクサバイトクラスのデータ転送を物理コンピュータに転送、運搬するサービス。
通常のAWSサービスへのデータ転送はインターネット経由で低速だが、物理コンピュータを持ってきてもらってデータ転送。
その後物理コンピュータを持ち帰ってもらい高速な物理線を利用して取り込ませるというパワー系サービス。

ちなみにいくつか種類がある。

  • 単純にデータ転送を行う通常のSnowball
  • Snowballにエッジコンピューティングなどの追加機能が付与されたSnowball Edge
  • エクサバイト級のデータ転送(トラックが来るらしい)が可能なSnowmobile

DataSync(データシンク)

オンプレ ↔ S3 or EFS or FSx for Windows File Server間での大容量データを高速転送するサービス。
オンプレにDataSync用のエージェントをインストールすることで利用可能。
Task(タスク)という単位でデータ転送ルールを定義して、転送を実施する。

ネットワーキングとコンテンツ配信

AWSでのネットワーキングとコンテンツ配信に関するサービス群。

VPC(ブイピーシー)

VPCはVirtualPrivateCloudの略

AWS上に仮想的なネットワーク空間を定義するサービス。
EC2、RDSなどのAWSリソースの紐付け、インターネットGW、NATの設定なども可能。
既存管理のネットワークとのVPN構築(AWS Site-to-Site VPN、AWS VPN CloudHub)、クライアント-VPC間のVPN構築(AWS ClientVPN)などもできる。

CloudFront(クラウドフロント)

コンテンツ配信の高速化、オリジンサーバへの負荷軽減を実現するフルマネージドなCDNサービス。
オリジンサーバのコンテンツに特別な設定ナシで利用が可能。
S3 + CloudFrontの静的サイトホスティングは鉄板構成。

Route53 (ルートフィフティースリー)

スケーラブルでフルマネージドなDNSネームサーバを提供するサービス。
通常のシンプルなルーティングに加えて、加重方式などの様々なルーティング方式をサポート。
レコード方式ではわかりにくいトラフィックの流れをわかりやすく可視化したビジュアルエディタなどもあり。

API Gateway(エーピーアイゲートウェイ)

簡単にREST APIの構築・デプロイができるようにするフルマネージドなサービス。
バージョン管理、認証認可、多様なバックエンド接続先が用意されている。
Lambdaとセットで使われることが多いが、他のAWSサービス(DynamoDBなど)やオンプレサービスもバックエンドにすることができる。

DirectConnect(ダイレクトコネクト)

オンプレ環境とAWSクラウド環境を専用線で結ぶためのサービス。
ARNパートナーという別の業者が用意した拠点を経由する。
AWS -(専用線)- ARNパートナー拠点 -(専用線 or VPN)- オンプレ みたいな構成。

App Mesh(アップメッシュ)

追加のコードなしでマイクロサービス間の通信を可視化するサービス。
複数のマイクロサービスが連携することでデバッグが複雑化しがちだが、App Meshの導入でデバックが用意になる。
また可視化した通信はメトリクスとして取得可能。

Cloud Map(クラウドマップ)

追加のコードなしでマイクロサービスのサービスディスカバリー(※)を提供するサービス。
マイクロサービス立ち上げ時に自動で登録され、ヘルスチェックまでやってくれる。

※ 新しく立ち上げたコンテナに対して自動でAレコードを割り当てて、ダイナミックにコンテナ間通信をできるようにする。自動検出とも呼ばれたりする。

Global Accelerator(グローバルアクセラレータ)

エニーキャストな固定IPを取得できるサービス。
EC2、ALBに紐付けることでエニーキャストの特性上クライアントから最も近いAWSのアクセスポイントにアクセスが誘導された後、高速なAWSネットワークを経由してエンドポイントまでルーティングされるためアクセスの高速化が見込める。
発行時には2つIPが吐き出されて、1つはメイン、1つは対象のIPネットワークが死んだ時のサブとして利用することでネットワークの冗長構成を組める。

開発者用ツール

IDE、Gitリポジトリ、CI/CDなどの開発者が楽をするためのサービス群。

CodeCommit(コードコミット)

フルマネージドなGitホスティングサービス。(いわゆるGithub的なやつ)
安い、大容量でプルリクエストなどの機能も備える。
何より他のCode系サービスとの連携がヒジョーに楽。

でももう少し差分比較が見やすくなると嬉しいです...Amazon様...

CodeBuild(コードビルド)

独自に定義した処理を実行して最終的なコードをアウトプットするサービス。
buildspec.ymlという設定ファイルに記載された処理(ビルドやテストなど)をDockerコンテナの中で実行する。
後述のCodePipelineと組み合わせてCI/CDを実現する構成が定番。

CodeDeploy(コードデプロイ)

コードの効率的で機械的なデプロイメントを提供するフルマネージドサービス。
appspec.ymlという設定ファイルに記載された設定に従ってコードをデプロイする。
数十台あってAutoScallingしているサーバ群にも多種多様なデプロイ方法で簡単にデプロイ可能。

CodePipeline(コードパイプライン)

リリースまでの一連の流れを管理・自動化・可視化するフルマネージドサービス。
リリースまでのプロセスを定義し、実行のトリガー(リポジトリへのPushなど)を設定することで自動CI/CDが実現可能。
よく使われるパターンとしてコードの入手元(CodeCommit)、ビルド・テスト(CodeBuild)、デプロイ(CodeDeploy)といったCode系サービスを組み合わせて使うことが多い。

もう自動デプロイがない生活には戻れねぇよぉ...(中毒者)

CodeStar(コードスター)

よくあるWebアプリケーションのデプロイ環境とCI/CD環境を数クリックで作るサービス。
実態としてはBeansTalk & Code系サービスを利用したCI/CD環境を提供しているっぽい?
とりあえず試しで開発環境を作りたい時とかにはいいかも。

Cloud9(クラウドナイン)

ブラウザで利用することができる統合開発環境。
パッケージのインストールなどを行われなくてもすぐ使える。
ただSourceTreeなどのGUIアプリケーションは動かせないためCloud9で開発を完結させたい場合は、CLIに慣れた人じゃないと厳しいかも?

X-Ray(エックスレイ)

マイクロサービス群のアクセス分析・デバックを提供するツール。
イメージ的にはブラウザの開発者ツール的な感じで利用しているマイクロサービス(DynamoDBなど)へのアクセス速度やステータスコードなどを可視化して、ボトルネックやトラブル発生箇所の発見を速やかにしてくれる。
利用にはX-Ray SDKの導入と分析用コードの記述が必要。

ロボット工学

ロボット開発に関するサービス群。

RoboMaker(ロボメーカー)

ROS(RobotOperationSystem)ベースのロボットアプリケーションの開発・テスト・デプロイが行える環境を提供するサービス。

ロボット工学について無知すぎて公式ページを読んでも完全に宇宙猫状態。本当に申し訳ない。

AWS 利用サポート(Customer Enablement)

実態を伴ったサービスではなく、AWSを利用する・したいユーザが抱える問題を解決するためのサービス群。

Support(サポート)

AWSサービス利用中に発生したトラブルシュートの支援、アドバイス、相談などのサポート(※)をユーザの言語でAWSの公式サポートチームが対応してくれる有償サービス。
いくつかプランから選択することが可能で、ミッションクリティカルなサービスなどの対応として24時間365日対応のサポートプランも存在する。

※ AWSサービスの技術的なサポートは基本的には行っておらず、なにか技術的な支援・アドバイス・相談を受けたい場合はこのサービスへの加入が必須となる。

IQ(アイキュー)

略称不明

AWSを利用して問題解決ができないかと考えるユーザのニーズを入力するとその問題に対処ができるAWS 認定サードパーティーのエキスパート(※)を紹介してくれるサービス。(マッチングアプリ的な感じっぽい)

※ AWSが定める条件を満たしている個人・企業がエキスパート申請をすることで認可され、IQで表示されるようになる。

Managed Services(マネージドサービスズ)

AWSサービスだけではなく、実際の運用もAWS公式のチームがサポートするサービス。
AWSの知見を持つ人間はいないが、完全なセキュリティでAWSサービスを運用したいという大企業に適している。
ただ運用代行ではなく、実際の責任者の承認が必要な操作などを定義して管理画面から承認させないと操作ができないようにするといったフローなども提供する。
※ 正直資料が見つけられなくてちょっとピンと来ていない

ブロックチェーン

ブロックチェーンに関するサービス群。

Managed Blockchain(マネージドブロックチェーン)

非中央集権で改ざん不可能なブロックチェーンをフルマネージドで提供するサービス。
類似した改ざん不可能な台帳サービスにAWS QLDBがあるが、QLDBは中央集権であるため目的用途によって使い分ける。

衛星

衛星に関するサービス群。

Ground Station(グラウンドステーション)

打ち上げた衛星と通信するための地上の基地局を提供するサービス。

「すまねぇ、衛生のことはさっぱりなんだ」という私でもなぜこのサービスが嬉しいのか?というのが、すんなり理解できたサービスが必要な背景からわかり易くまとまっている素晴らしい記事がこちらです。

AWS Ground Stationについて解説する

量子技術(Quantum Technologies)

量子コンピューティングに関するサービス群。

Braket(ブラケット)

量子コンピューティングのための量子アルゴリズムをシュミレートしたりする環境をフルマネージドで提供するサービス。

量子コンピューティングについて無知すぎて公式ページを読んでも完全に宇宙猫状態。本当に申し訳ない。

管理とガバナンス(統制)

AWSサービスそのものの管理と統制を担当するサービス群

Organizations(オーガナイゼーション)

複数のAWSアカウントの一元管理する機能を提供するサービス。
AWSアカウントをグループ化、グループにポリシー適用して利用機能の制限や複数AWSアカウントの請求を一括化などの複数のAWSアカウントを運用する大組織にはありがたい機能が提供されている。

CloudWatch(クラウドウォッチ)

AWSリソース、その上で動作するアプリケーション、ログの収集、分析、モニタリングなどの機能を提供するサービス。
またモニタリングだけではなく、モニタリングしているサービスのイベントをトリガーに任意の処理を実行するような仕組みも提供する。

Auto Scaling(オートスケーリング)

各種AWSサービスの自動スケーリングを提供するサービス。
EC2のスケールイン・アウト、DynamoDBのキャパシティ...etcをスケーリングする。
ユーザのニーズに応じて適切なスケーリング設定を行うことで、必要最低限のリソース料金でサービスを運用できる。

CloudFormation(クラウドフォーメーション)

AWSサービスのリソース構築及び設定をテキストファイルで管理して、設定ファイルに記載されたリソースのプロビジョニングが行えるサービス。
AWSリソースでのInfrastructure as Code(言いたいだけ)を実現するサービスであり、インフラ環境構築を有識者の知見に委ねず、誰がやっても同じ環境を構築できるようになる。
ビジュアルエディタからの設定テキストファイルの出力もサポートしており、構成図の役割も果たせる。

CloudTrail(クラウドトレイル)

AWSサービスの操作(APIコール)、AWSマネジメントコンソールへのサインイン・アウトなどのAWSに対する操作のロギングを行うサービス。
S3に保存されるログをCloudWatch Logsに連携して監視、特定の操作を行われた時にSNS経由でLambdaを呼び出したりすることも可能。
要するにAWSリソースを消した犯人を見つけたりすることができる。

Config(コンフィグ)

作成したAWSリソースの設定に対する操作をロギングするサービス。
現在のAWSリソースの構成・設定・依存関係を可視化して検索、確認が行えるため、有事のためにとりあえず有効にしておくことが推奨されるサービス。
また、CloudTrailと同様にS3に保存されるログをCloudWatch Logと連携して、特定の構成変更などを行った場合にSNSからLambdaを呼び出してアラートを通知することも可能。

※ CloudTrailはAWSサービスそのものに対する操作、ConfigはAWSリソースの設定・構成に対する操作をロギングする。

OpsWorks(オプスワークス)

chef, Puppetを利用したEC2上のパッケージ導入・設定などの構成管理を行えるようにするサービス。
オンプレ環境で利用していたchef, Puppetを利用した構成管理をAWS環境でも展開できる。

Service Catalog(サービスカタログ)

組織内でのCloudFormationの設定ファイルの管理(バージョン管理など)と運用を行うサービス。
管理者(※1)が作成したCFの設定ファイルを利用者(※2)に提供する形での運用モデルが想定されている。
開発チームとインフラ管理チームの用に分業を行っている際に、インフラ管理チームがService CatalogにCloudFormationを登録することで決まった構成のみを開発チームで使えるように提供できるため、設定ミスによるコンプライアンス違反などを防止できる。

※1 ... 運用に伴うセキュリティ要件などを把握している管理者
※2 ... AWSリソースを必要とする開発メンバー

System Manager(システムマネージャー)

クラウドサーバやオンプレサーバの運用管理(一連の作業の自動化・状態監視・情報収集・操作のロギング・環境変数の管理...etc)を行えるようにするサービス。
一言でまとめると「論理的なグループにまとめたリソース群の情報を一つのコンソールで可視化、操作を行える」わからん
Blackbelt 要確認

AppConfig(アプリコンフィグ)

上述したSystemManagerのサービスの1つ。
EC2やLambda上のアプリケーションの設定変更をSystemManager上から行うことができる。

Trusted Advisor(トラステッドアドバイザー)

利用している全体のAWS環境を分析してコスト最適化、パフォーマンス、セキュリティ、対障害性能、サービス制限(AWSが設けているEC2などの起動台数制限など)の観点で、推奨設定などを提示してくれるサービス。
無料プランでも利用できるが機能制限がかかっており、セキュリティ項目の一部しか評価がされない。
フル機能を利用するには有料のAWS Supportのプランに加入する必要がある。

Control Tower(コントロールタワー)

複数AWSアカウントを運用する際のベストプラクティスパターンを簡単に構築するサービス。
取りまとめの親アカウント、実際のAWSリソースを運用する子アカウントのAWSが推奨するパターンを構築する。
実際のリソース作成にはAWS Organizationsを利用してアカウントの発行などが行われる。

LicenseManager(ライセンスマネージャー)

サーバー導入台数制限などが存在するライセンス情報の管理と、ライセンス違反を侵さないようにマシンリソースの制限(※)を導入できるサービス。
EC2起動時に予め設定しておいた制限をチェックして、上限を超える場合はインスタンスの起動が行えないようにアラームが発生する。

※ 2020年5月 時点で以下のリソースを制限可能

マシンリソース 役割
vCPU 仮想CPU。インスタンスタイプによって割当数が異なる。
コア 実CPU。インスタンスタイプによって割当数が異なる。
ソケット コアとマザーボードを接続する接続口。おそらくインスタンスタイプと同じに考えておけば良さそう。
インスタンス EC2インスタンス。ユーザによって起動された数が相当する。

Well-Architected tool(ウェルアーキテクテッドツール)

AWS公式がこれまでの経験から定義されたサービス運用のベストプラクティスをWell-Architectedと呼び、ホワイトペーパーだったりチェックリストが提供されている。
Well-Architectedはその中でも、AWSのソリューションアーキテクトによるレビューをツールによってセルフレビューを実現するツール。

Personal Health Dashboard(パーソナルヘルスダッシュボード)

自身のアカウントで運用しているAWSリソースに影響する情報(※)を通知するサービス。
何も設定しなくても利用されており、AWSマネジメントコンソールのツールバー上のベルから通知を確認できる。
未解決の問題、予定された変更、その他の通知という3パターンで通知が行われる。
※ 例: 利用中のRDSインスタンスへのメンテナンスによる停止告知など

Chatbot (チャットボット)

AWS ChimeやSlackと連携を行う機能。
各種イベントなどをSNSを通じて通知、Slack上からAWSリソース情報にアクセスできるコマンドの実行が行える。
CloudTrailなどと連携してAWSリソースへの変更操作をSlackに通知、SlackからLambdaの実行なんてこともできる。

Launch Wizard (ランチ ウィザード)

対話形式のウィザードに答えるだけでWell Architectedに沿った環境の構築ができるサービス。
2020年5月現在ではEC2でのMicrosoft SQL Server環境の構築 のみサポートされている。

Compute Optimizer (コンピュートオプティマイザー)

現在利用しているEC2、AutoScalingGroupのCloudWatchメトリクスを参照して、AWSが構築した機械学習が最適なインスタンスタイプなどを提案してくれるサービス。
無料で利用ができる。

メディアサービス

主に動画配信に関するサービス群。
当初よりAWSでも動画系のサービスは開発していたが、もともと動画関連のソフトウェア開発会社であったElemetal Technologies社を2015年9月に買収した以降に追加されたサービスが多い。

Elastic Transcoder (エラスティックトランスコーダー)

動画ファイルを様々なデバイスに対応した動画ファイルに変換するサービス。(料金は変換対象の動画の長さによって増える従量課金)
マシンリソースを多く必要とするエンコード処理の外部切り出し、サムネイルの作成など付随する処理も同時に行うことができる。
類似サービスであるAWS Elemental Media Convertとの相違点はWebM出力、MP3オーディオのみの出力、アニメGIFの出力といった処理だが、変換フォーマットの多彩さやコストではAWS Elemental Media Convertに軍配が上がる。

Kinesis Video Streams (キネシスビデオストリーム)

画像・動画のストリームデータをS3に取り込んで、別の分析処理に配信するためのフルマネージドサービス。
監視カメラ、スマートフォンからのストリームデータを取り込んで格納、AWS RekognitionやEC2上に構築したTensorFlowなどに低遅延で渡すことなんかができる。
画像・動画の機械学習の本質的な作業は解析処理であり、解析までに至るデータの取り込み、配信といった部分をフルマネージドで利用することで解析処理に集中することができる。

Elemental Media Connect(エレメンタルメディアコネクト)

AWS Liveやオンプレミス機器からAWSのネットワークを通じてライブ動画の伝送を行えるサービス。
従来のライブ配信は衛星、ファイバー接続などを利用した大掛かりな機材・契約などが必要だったが、Elemental Media Connectはそういった機材なしで安定した伝送をすぐに利用できる。
また動画配信業界のスタンダードな通信プロトコル(Zixi、RIST...etc)もサポートしている。
※ ライブ配信で必ずしも必須なわけではなく、低遅延、高品質なライブ配信が要件に加わった場合に採用の余地がでてくるらしい。。。

Elemental Media Convert(エレメンタルメディアコンバート)

動画ファイルを様々なデバイスに対応した動画ファイルに変換するサービス。(料金は変換対象の動画の長さによって増える従量課金)
古くから存在する類似サービスであるAWS Elastic Transcoderとの相違点はWebM出力、MP3オーディオのみの出力、アニメGIFの出力ができないという点だが、それ以外の点はAWS Elemental Media Convertに軍配が上がる。(コスト、変換フォーマットの多彩さなどもAWS Elemental Media Convertが強い)

※ AWS公式の動きとしても、AWS Elemental Media ConvertにAWS Elastic Transcoderにしかなかった機能の追加(動画の回転など)も行っているため、AWS Elemental Media Convertを推していきたいっぽい?

Elemental Media Live(エレメンタルメディアライブ)

ライブ動画ストリームのエンコードサービス。
ストリームデータを配信用のファイルサイズの小さいフォーマットにリアルタイムでエンコードしてくれる。

Elemental Media Package(エレメンタルメディアパッケージ)

単一のビデオ入力からマルチデバイス向けの様々な動画を作成することができるサービス。
他にもDRMを利用したリッチコンテンツ保護機能や、不特定多数に配信する際に役立つ機能が提供されている。
AWS Elemental Media Live、AWS CloudFrontと連携することでライブ動画の処理、グローバル配信が可能になる。

Elemental Media Store(エレメンタルメディアストア)

ライブ、VOD動画を保存するサービス。
バックエンドにはAWS S3が利用されており、ライブ動画などの高頻度での書き込みなどを考慮したチューニングがされており、自身で複雑なチューニングを行う必要がない。
ライブ配信のアーカイブ保存、アーカイブからAWS CloudFrontに接続して見逃し配信などに利用できる。

Elemental Media Trailor(エレメンタルメディアトレイラー)

動画配信時に広告をサーバ側で挿入して収益化をサポートするサービス。
どれだけ広告が再生されたか、どんなメディア(iOS、Android...etc)で再生されたか...といった情報のレポートを自動作成してくれる。
サーバ側での挿入になるため、Adブロッカーなどにも邪魔されない。

Elemental Appliances & Software(エレメンタル アプライアンス アンド ソフトウェア)

AWSが提供するMedia系サービスの一部をオンプレミス環境でも利用できるように提供するサービス群。
以下のいくつかのサービスに分けられている。

サービス 詳細
AWS Elemental Live(エレメンタルライブ) ライブエンコーダー。オンプレミス版のAWS Elemental Media Live的なもの。
AWS Elemental Server(エレメンタルサーバー) ファイルベースのエンコーダー。オンプレミス版のAWS Elemental Media Convert的なもの。
AWS Elemental Delta(エレメンタルデルタ) ライブ、VODそれぞれのパッケージング。オンプレミス版の AWS Elemental Media Package的なもの。
AWS Elemental Conductor(エレメンタルコンダクター) AWS Elemental Liveのオンプレミス動画ネットワーク管理システム。スケーリングした際などのクラスタ管理、設定、モニタリングが行える。

機械学習(Machine Learning)

機械学習に関連するサービス群。
提供されるサービスはゼロから機械学習を始めるサービスと、構築・学習済みのサービスが存在する。
前者は機械学習の知識が必要となるが、後者は全く機械学習について知らなくても恩恵を教授できる。

SageMaker(セージメーカー)

ゼロから機械学習モデル(ML)を構築・トレーニング・デプロイの全てに至るまでに必要な機能・コンポーネントを提供するサービス。
フルマネージドで機械学習に必要なリソースが提供されるため、マシンリソースの用意が不要。
SageMakerの中でも用途・機能別にコンポーネントが切り分けられている。

※ 機械学習についての事前知識・理解がないとサービスの利用は困難。
※ 以前はAWS Machine Lerningというサービスが近い役割を担っていたが、新しい顧客はSageMakerの利用を推奨され、AWS Machine Lerningは利用できなくなった。

CodeGuru(コードグル)

AWSによってトレーニング済の機械学習を利用した自動コードレビューを提供するサービス。
ホスティングサービス(※1)で管理されているコード(※2)のコードをレビューして、結果をPullRequestとして通知するCodeGuru Reviewer(コードグル レビュアー)と実行環境にAgentを仕込んでCPU使用率や実行時の遅延などのから修正方法を提案してくれるCodeGuru Profiler(コードグルプロファイラー)の2つサービスが提供される。

※1 2020年5月 現在で対応しているのはGithubとAWS CodeCommit
※2 2020年5月 現在で対応している言語はJavaのみ

Comprehend(コンプリヘンド)

AWSによってトレーニング済の機械学習を利用した自然言語処理サービス。
フルマネージドで適当に渡したテキストから場所、人物、キーフレーズ、感情(肯定的/否定的/中立/混在)などが検出できる。
5000byteまでであれば、お試しでマネジメントコンソールからの利用も可能。

※ サポートされている言語はこちら
2020年5月現在は日本語はサポートされていないっぽい。。。

Forecast(フォアキャスト)

AWSによってトレーニング済の機械学習を利用した過去の時系列データと関連データから未来を予測してくれるサービス。
過去の温度がまとまった時系列のCSVデータとアイスの過去の売上データなどを食わせて、未来のアイスの売上を予測したりできるらしい。(やってない)

Fraud Detector(ファウルドデテクター)

AWSによってトレーニング済の機械学習を利用してオンライン上の支払い詐欺、偽アカウント作成といった不正な操作をの検知をするサービス。
※ 2020年5月現在はプレビュー版。

Kendra(ケンドラ)

AWSによってトレーニング済の機械学習を利用した自然言語による検索サービス。
人が人に場所を聞くように検索して、様々なデータ・リソース(※1)から適切な回答を探して返却する。
またユーザ操作(いいね、検索結果のクリック)によって学習を続けてより、精度を向上していく。

※ 2020年5月現在の対応言語は英語のみ。
※1 予め用意されたデータ・リソースから選択可能。(S3、SMB、各種クラウドストレージ...etc)
またデータ・リソースからのインデックスサイクルも自由自在に設定可能

Lex(レックス)

Alexaと同じ機械学習技術を利用して自然言語でチャットボットが構築できるサービス。
既存のアプリケーションに音声入力でのオペレーションなんかも追加できる。
実際に処理を行うには、Lambdaだったりとの連携が必要。

※ 2020年5月現在の対応言語は英語のみ。

Personalize(パーソナライズ)

Amazon.comと同様の機械学習技術を利用したレコメンデーションサービス(※)。
ユーザ宛に「この商品を購入した方はこんな商品もチェックしてます」といったアイテムリストを提供する。

※ 顧客の好みを分析して、顧客ごとに適すると思われる情報を提供するサービス

Polly(ポリー)

AWSによってトレーニング済の機械学習を利用したテキスト読み上げサービス。
機械学習が常に学習を継続することで、非常に滑らかな読み上げを提供する。
話し方はユーザが独自にカスタマイズすることも可能。(抑揚、声など様々なカスタマイズが可能)

実際にマネジメントコンソールからお試し可能

Rekognition(リコグニション)

AWSによってトレーニング済の機械学習を利用した画像、動画の分析サービス。
食わせた画像、動画の顔ベースのユーザ認証、感情分析、物体検出、有名人の認識、テキスト検出(※1)、シーン検出、安全ではないコンテンツの検出(アダルト、暴力)、ラベル付けなどが可能になる。

※1 2020年5月時点では英語のみ

Textract(テキストラクト)

AWSが独自にトレーニングさせた機械学習を利用して電子ファイル(※1)上のテキストを認識(※2)して、テキストデータとして抽出する。
単純にプレーンのテキストの抽出だけではなく、フォームやテーブルの構造データも認識する。(フォームならキーバリューで抽出、テーブル構造を維持して抽出)
マネジメントコンソールからお試しで利用可能

※1 2020年5月時点でpdf, png, jpegがサポートされている
※2 2020年5月時点では英語とラテン文字のみがサポートされている

Transcribe(トランスクライブ)

AWSが独自にトレーニングさせた機械学習を利用して音声をテキストに変換出力するサービス。
保存された音声ファイル変換(※1)とリアルタイム変換(※2)がある。
カスタム語彙(一般的ではない業界用語などを登録することで変換精度を向上)、話者識別(複数人が会話する音声などで話し手を識別)といった機能も利用することが可能。

※1 対応言語はこちら。(日本語対応済)
※2 対応言語はこちら。(日本語未対応)

Translate(トランスレート)

AWSが独自にトレーニングさせた機械学習を利用して言語翻訳(※1)を行うサービス。
カスタム語彙を利用して一般的ではない業界用語などの翻訳も行える。
マネジメントコンソールからお試しできる。

※1 対応言語はこちら。(日本語対応済)

Deep Lens(ディープレンズ)

Amazonが開発した深層学習対応のプログラミングでカスタマイズ可能なビデオカメラと利用するためのサービス。
AWS Rekognitionを利用した画像分析、何らかの動作をトリガーにAWS Lambdaを実行...といった簡単にカスタマイズを行うこともできる。
更にはSageMakerを利用して独自の学習モデルを利用した画像分析なども可能らしい。

Deep Racer(ディープレーサー)

機械学習モデルで動作する1/18のレーシングマシンを通して、機械学習を学ぶサービス。
3Dレーシングを強化学習をさせて実機マシンにモデルをデプロイして、レーシングを競う。

Augmented AI(オージメンテッド エーアイー)

機械学習の結果が正しいかを判断するワークフローを構築することができるサービス。
機械学習を利用した自動化を目指しても、学習した結果が内容が正しいか?という作業は人間の目によって行う必要があり、通常であれば結果を効率的にレビューできる仕組みの構築が必要になる。
本サービスを利用することで自前でレビューのワークフローを構築しなくても、AWS内で「レビュー作業及び結果のフィードバック」までを完結させること可能。

Deep Composer(ディープ コンポーザー)

Amazonが開発した機械学習を搭載したミュージックキーボードから入力したメロディを機械学習がオリジナルの音楽を作成してくれるサービス。
AWS Deep Racerと同様に機械学習を学ぶためのサービスらしい。

分析

データを分析するためのサービス群。
分析するデータを貯めるためのサービスなども含まれる。

Athena(アテナ)

AWS S3上のデータに対して、SQLを利用してデータ分析が行えるサービス。
これまでのデータ分析はAWS RedshiftなどにデータをETLしていたが、直接S3のオブジェクトからデータ分析が行えるようになった。
基本的に分析できるデータはcsv, jsonなどの定形データであるが、csvのヘッダー列などが含まれる非整形データでもAWS Glueを連携することで分析可能。

EMR(イーエムアール)

Elastic MapReduce(※)の略
MapReduce(マップリデュース) ... Googleが開発した大規模データを分散して処理するためのフレームワーク。

AWS EC2、AWS S3などを利用してAWSリソース上でHadoop環境を構築できるサービス。
通常のHadoop環境の構築よりも簡単に構築することができるらしい...。

Cloud Search(クラウドサーチ)

全文検索をフルマネージドで提供するサービス。
Apache Solr(※)をベースとして構築されている。
AWS SDK経由でアプリに組み込むことで、検索対象としたいデータをJSONやCSVとして整形してCloudSearchにアップロードして解析 > リアルタイムに検索インデックスを生成という手順を踏むことで全文検索機能を提供することが可能。

※ オープンソースの全文検索サーバ。全文検索ライブラリであるApache Lucene(ルシーン)を利用して実装されている

Elasticsearch Service(エラスティックサーチ サービス)

略称 AWS ES(イーエス)

Elasticsearch(※)環境をフルマネージドで構築することができるサービス。
Elasticsearchを普通に利用しようとすると、EC2を起動して手動でインストール・設定...などが必要だが楽ちん導入ができる。

※ Elastic社が開発したApache Lucene(ルシーン)を利用して開発された分散型全文検索エンジンサーバ

kinesis(キネシス)

ストリームデータ(※)を収集・保存・処理・分析といった処理を行う機能をフルマネージドで提供するサービス。
4つのサービス群から構築されており、目的用途に分けてサービスを利用する。
ストリームデータを引き渡すシャードを増やすことでスケールできる。

※ アクセスログ、センサーなどのIoT機器のセンサーデータ、株取引情報などの継続的に発生し、タイムスタンプを含むデータ

サービス 詳細
Kinesis Data Streams(キネシス データストリームス) ストリームデータを取り込んでAWS EC2やAWS Lambdaなど渡して何らかの処理を行う。データを受け取って即時処理が行えるためリアルタイム性が求められる処理に適している。
Kinesis Data Firehose(キネシス データ ファイアホース) ストリームデータをAWS S3、AWS Redshift、AWS ESなどにデータを配信する。取り込みインターバルが最低60秒。即時処理を行いたい場合はData Streamsを利用する。
Kinesis Data Analytics(キネシス データ アナリティクス) ストリームデータをリアルタイムでSQLを利用して分析する
Kinesis Video Streams(キネシス ビデオ ストリーム) Kinesis Video Streamsの項目を参照

QuickSight(クイックサイト)

AWSが提供するブラウザから利用できるフルマネージドなBIツール。
AWS Athenaなどから解析用のデータを渡すことができる。
AWS開発者が利用するBIとしては利便性が高い。

Data Pipeline(データパイプライン)

オンプレミス、AWS EC2, S3, RDS, Redshiftで相互にデータをETLして受け渡しするサービス。
ユースケースとしてS3に格納されるファイルを30分に一度にRedshiftにETLして渡す...といったことが実現できる。
転送失敗時のリトライや実行結果のログ収集などの機能も提供しているため自前で転送処理を実現するよりも楽ちん。

Data Exchange(データエクスチェンジ)

サードパーティーデータ(市場データ、地理情報、金融...etc)を検索・購入することができるサービス。
サードパーティー自体はData Exchangeが認定しているデータブロバイダー認定を持つユーザのみが公開することができる。
購入したデータはS3に保存可能。そのままAWS Athenaを利用して分析なども可能。

Glue(グルー)

フルマネージドで利用できるETLを提供するサービス。
クローラーがデータソース(AWS S3, RDS ... etc)から自動的にデータカタログを作成、ETLジョブを実行という一連の流れを他のAWSリソースを連携して行う。
要するにデータソースからAWS Athena、AWS Redshift Spectrumで利用するデータを整形(ETL)するサービス。

※ AWS LambdaとAWS CloudWatchEventでイベント定義してETLできんじゃねーのかよ?
と思っていたが、AWS公式が推奨する使い分けはこうらしい。

Lake Formation(レイクフォーメーション)

様々なタイプの分析を実行できるデータの貯蔵庫ことデータレイクをスピード構築できるサービス。
AWS S3やAWS RDSなどのデータソースを登録して裏側ではGlueが動いて、AWS AthenaやAWS Redshiftから分析などが可能なデータレイクを作る。
同じようにいい感じのデータレイクを作るには数ヶ月かかるらしいが、いかんせん実際に構築したことがないのでサービスのメリットがピンと来ていない...。

MSK(エムエスケー)

Managed Streaming for Apache Kafka(マネージド ストリーミング フォー アパッチカフカ)の略

Apache Kafka(※)をフルマネージドで利用することができるサービス。
元々オンプレミスでApache Kafkaを利用していた場合などはスムーズに移行ができる。

※ オープンソースのストリームデータ処理用の分散型メッセージキュー。(AWS Kinesis的なやつ)
AWS Kinesisとの使い分けはこうらしい。

セキュリティ、ID、およびコンプライアンス

AWSサービスをセキュアに利用するためのサービス群。

IAM(アイアム)

Identity and Access Management(アイデンティティー アンド アクセスマネジメント)の略

AWSリソースに対するアクセス制限を提供するサービス。
AWS利用時のベストプラクティスである「AWSリソースを利用するユーザ、リソースに対して必要最低限のアクセス制限を行う」の大部分はIAMの機能によって実現される。
大体どのAWSサービスを使っていても意識することになる重要なサービスなので、Blackbeltを読もう(提案)

RAM(アールエーエム)

Resource Access Manager(リソースアクセスマネージャー)の略

自身で作成したAWSリソースを異なるAWSアカウント、AWS Organizations間で共有できるようにするサービス。
わざわざ共有したい外部の組織向けにIAMユーザ作成・設定を行わなくても、共有先はあたかも自分のアカウントが作成したリソースのように共有されたリソースを利用することができる。
2020年5月現在ではまだ一部サービスしか対応していない。

Cognito(コグニート)

モバイル・Webアプリケーションでのユーザ作成・認証・データ同期・管理機能をフルマネージドで提供するサービス。(Firebase Authentication 的なサービス)
よく利用するユーザ登録・変更・管理機能といった一般的な機能からGoogle、Facebookなどのブロバイダと連携してソーシャルログインの機能などもコーディングなしで実現できる。
ログイン時にIAMロールのクレデンシャルをクライアントに提供して、特定のユーザがログインした場合のみ特定のAWSリソースにアクセスさせることも可能。

複雑な印象を受けがちなサービスだけど、活用できるとクッソめんどくさいユーザ認証周りの開発/運用負荷を下げられる素敵なサービス。
Blackbelt、読もう!(提案)

Secrets Manager(シークレットマネージャー)

AWSリソースへのアクセスキー、DBのID/パスワードといったセキュアな情報を管理・取得できるサービス。
Secrets ManegerからAWSリソースへのアクセスキー、DBのID/パスワードといった情報を取得することで、それらの情報をハードコーディング -> Githubなどに公開して不正利用・アクセスといったインシデントを防止できる。

類似サービスとしてAWS Systems ManegerのParameter Storeもある。
内容を比較してくださっていた方の記事がわかりやすかったです。

AWSのParameter StoreとSecrets Manager、結局どちらを使えばいいのか?比較

Guard Duty(ガードデューティー)

AWSリソースの不正利用の自動検知を行ってくれるサービス。
CloudTrailのログをAWSが独自に学習させた機械学習モデルを利用したチェックをかけて、セキュリティ的によろしくない操作(※)などを驚異度別に通知(AWS SNS利用)してくれる。
意図せず行っているセキュリティリスクのある運用なども検知してくれて、利用料自体も大したことないので、とりあえず有効にするのが推奨っぽい。

※ 例:ルートアカウントでのリソース操作、不自然なEC2の乱立(不正に入手されたクレデンシャルを利用したEC2を利用しての仮想通貨マイニングなどの検知) ... etc

Inspector(インスペクター)

運用しているAWS EC2インスタンスへの脆弱性診断を提供するサービス。
EC2に専用のエージェントをインストールして、CVECIS、セキュリティのベストプラクティス...etcの観点で診断して改善案を提供してくれる。

Macie(メイシー)

AWS S3に保存されている機密データをAWSが独自に訓練させた機械学習モデルを利用して自動的に検出・分類・保護・監視するサービス。
監視はAWS CloudTrailを利用して検出した機密情報に対して普段アクセスが行わないユーザが高頻度でアクセスを行っている...などの疑わしい操作を検出して、通知してくれる。
なお2020年5月現在では対応言語は英語のみで、日本語の文書などから個人情報などの機密データを自動検出・分類・保護・監視は行うことができないみたい。

Single Sign-On(シングル・サインオン)

SSOと略される

ActiveDirectory(AWS Directory Service)の既存のID・PASSで別のAWSアカウントやSAMLに対応したクラウドサービス(Box, Slack, Office365...etc)へのシングルサインオン機能を提供するサービス。
対応状況を確認すると2020年5月現在はまだ東京リージョンでサポートはされていないみたい。

Cetificate Manager(サーティフィケート マネージャー)

ACMと略される(AWS Cetificate Manager)

AWSリソースで利用するSSL/TLS証明書の発行・管理を行う。
AWS ELB, AWS CloudFront, AWS API GatewayはACMに統合されており、無料でドメイン認証(DV)証明書を発行・利用することができる。
手動での証明書発行、更新(※)、デプロイ関連のトラブルを防止することができる。

※ ACMが発行した証明書は自動更新に対応しているが、別の機関で発行してインポートした証明書は自動更新に対応していないので注意。

KMS(ケーエムエス)

Key Management Service(キーマネージメントサービス)の略

フルマネージドな暗号鍵の作成、管理を行うサービス。
様々なAWSサービスと統合されており、ユーザが管理する暗号鍵でのデータ暗号化を簡単に実現する。

CloudHSM(クラウドエッチエムエス)

HMSはHardwereSecurityModule(ハードウェアセキュリティモジュール)の略

フルマネージドなHSMを提供するサービス。
期待される役割としてはKMSと同じ暗号鍵の管理であるが、物理的に遮断された領域で暗号鍵を保存するためより厳密な管理となる。(KMSは安全性は保証されているがマルチテナント方式での鍵管理)
業務・契約内容によってマルチテナント方式であるAWS KMSではコンプライアンスを遵守できない場合に利用するのが推奨されている。

Directory Service(ディレクトリ サービス)

色々なディレクトリサービスを提供するサービス。
サポートされているディレクトリサービスは、以下表を参照。

サービス名 詳細
Amazon Cloud Directory(アマゾンディレクトリサービス) クラウドネイティブかつフルマネージドなディレクトリサービス。
Cognito Your User Pool(コグニートユアユーザプール) AWS Cognitoを参照。
Microsoft AD(マイクロソフト アクティブディレクトリ) AWSリソースでマネージドなActiveDirectory環境を提供するサービス。
Simple AD(シンプルアクティブディレクトリ) AWSリソースでマネージドなSamba4搭載のActiveDirectory互換の環境を提供するサービス。
AD Connector(アクティブディレクトリコネクター) オンプレミスのActiveDirectoryサーバと連携するサービス。

WAF(ワフ)

WAFはWebApplicationFirewall(ウェブアプリケーションファイアウォールの略)

フルマネージドなWAFを提供するサービス。
適用対象はAWS CloudFront or AWS ALBの2サービスのみ。
L7層(Webアプリ)に対しての攻撃(XSS、SQLインジェクション...etc)をサーバ運用なしで簡単なルール定義を行うだけで実装できる。

Shield(シールド)

AWSリソースをDDoS攻撃から守る盾(シールド)を提供するサービス。
Shieldには2種類存在し、Standard(スタンダード)は無料で外部に公開されるAWSリソースに対して常時有効になっており、よくあるL3/L4の攻撃(SYN/UDPフラッド、リフレクション..etc)を自動検知して防ぐ。(L7層へのDDoS攻撃は非対応。後述するAdvancedを利用するか、自主的にWAFを入れる必要あり)
Advanced(アドバンスド)は有料だがELB、CloudFront、Route53に対して更に手厚いセキュリティサポートがついてくる。(AWSが擁するDDoS攻撃専門チームのサポート、L7層のサポート...etc)

Firewall Manager(ファイアウォール マネージャー)

AWS Organizationsで管理される複数のAWSアカウントを跨いでAWS WAFルールを設定・管理を行えるようにするサービス。
組織間でAWS WAFを一括で指定したい場合に有用。

Artifact(アーティファクト)

AWSサービスに対してのコンプライアンス監査結果のレポートをダウンロードできるサービス。
ISO、PCIなどの第三者機関によるAWSへの監査結果を誰でも入手できる。
これからAWSに移行したいが、最終決定権を持つ上司や役員を説得する材料として使えそう。

Security Hub(セキュリティハブ)

CIS AWS Foundation Benchmark(※)に基づいた自動チェック機能の提供と、他のセキュリティ関連のAWSサービスとサードパーティー製のアラートの一元管理機能を提供するサービス。
後者のサービスで対応しているAWSサービスはAWS Guad Duty, AWS Inspecter, AWS Macie。これらのアラートを検出して一元管理する。(サードパーティーアプリの対応状況はこちら)
複数のセキュリティサービスのアラートを集約できるため、管理が用意になるのが嬉しいところ。

※ セキュリティ促進を目的とする非営利団体CISが策定したAWSを利用する上で必要となるセキュリティ設定のベンチマーク

Detective(ディテクティブ)

各種AWSリソースのログデータをAWSがトレーニングした機械学習モデル、統計分析...etcで潜在的なセキュリティ問題、不審な操作の根本原因を分析・調査してくれるサービス。
AWS VPC Flow Logs, AWS CloudTrail, AWS GuardDuty, AWS Securtity Hubなどのデータソースから分析を行う。

モバイル

モバイルアプリ開発に関するサービス群。

Amplify(エンプリファイ)

モバイル・ウェブアプリケーションの開発を効率化・高速化するためのツール群を提供するサービス。
提供するサービスは大きく分けて モバイル・ウェブアプリケーション開発でよく使われるAWSリソース(※)に簡単にアクセスするためのライブラリ・AWSリソースを構築するためのCLI・よく使うUIコンポーネント の3つ。

※ 以下機能に対応するAWSサービスに対して簡単にアクセスできる

機能 対応サービス
認証 AWS Cognito
分析 AWS Pinpoint
サーバ処理(REST API) AWS Lambda + AWS API Gateway
データ同期 AWS AppSync
リソースのホスティング AWS S3 + AWS CloudFront
ストレージ AWS S3

Mobile Hub(モバイルハブ)

AWS Amplifyの前身サービス。
新しく利用を始めようとすると、AWS Amplifyに誘導される。

App Sync(アップシンク)

フルマネージドなGraphQL(※)を利用したリアルタイムでのデータ同期サービス。
オンライン・オフラインでも利用することが可能。
対応するフィールドの取得元(データソース)としてAWS DynamoDB、AWS Lambda....etcが利用できる。

※ Facebook社によって開発されたREST APIの欠点を解決するために生まれたAPI規格。
エンドポイント管理の複雑さ、目的以外の余計なデータがついてくることがある...といった問題を解決する。
またデータ更新時にリアルタイム同期のサポートする。

Device Farm(デバイスファーム)

フルマネージドでモバイルデバイスの実機を利用したテスト環境(自動テスト、リモートアクセス、リモートデバック)を提供するサービス。
最新の端末から、数年前の端末まで利用可能(※1)。しかもセキュリティを考慮して、デバイスの専有契約も可能。
必要に応じて必要な端末を従量課金(※2)で使用できるため、わざわざ実機端末を買わなくても特定の端末でしか再現しない問題などの検証にも活用ができそう。

※1 利用可能な端末リスト > http://awsdevicefarm.info/
※2 2020年5月時点で月1000分まで無料で利用可能、ただし専有契約の場合は月々固定の支払いが発生する。

拡張現実 (AR) とバーチャルリアリティ (VR)

AR、VR開発に関するサービス群。

Sumerian(シュメール)

Webブラウザ上でAR、VR、MRコンテンツの開発が行えるフルマネージドな環境を提供するサービス。
WebGL(※)が利用できるブラウザであれば、利用可能。

※ ウェブブラウザで3Dグラフィックを表示させるための標準仕様。大体の主要ブラウザでは対応している。

アプリケーション統合

複数のサービスを疎結合に統合するためのサービス群。

Step Function(ステップ ファンクション)

フルマネージドでいくつかの要素に細分化できる一連の処理をワークフローとして管理することができるサービス。
最も細かい単位をステートと呼び、その単位で各種処理(AWS Lambda, ECS/Fargate, DynamoDB...etc)を呼び出すことができる。

  • ステート1:データの取得(DynamoDB)
  • ステート2 : データの加工(Lambda)
  • ステート3 : データの保存(DynamoDB)

みたいなマイクロサービスの組み合わせで一連の処理を構築することが可能。

AWS LambdaやAWS Batchでワークフローを完結させればいいのでは?と思われるが、各マイクロサービス間の連携用のコードの記述が不要であること、各ステートの追跡・監視・リトライ・ロールバックなどの機能が提供されているため、エラー・デバック対応が簡単なことなどを考慮した上で処理の複雑度、規模感などで使い分けができる。

Event Bridge(イベントブリッジ)

AWSリソース、Event Bridgeに対応したSaaS、独自のサービスを連携してAWS Cloud Watch Eventsのよう(※)にイベント駆動の仕組みを提供するサービス。
自前でイベント駆動に関するコードを実装せず、他サービスを呼び出し、連携することが容易になる。

※ というかAWS Event Bridge自体がAWS CloudWatch Eventsから独立したサービス。内部のイベント通知の仕組みも同じAPIを利用している。
AWSリソース以外のイベントも集約してイベント駆動として利用できるように機能追加されて独立した。
そのうち元のAWS CloudWatch EventsもEvent Bridgeとして完全独立する予定らしい。

MQ(エムキュー)

MQはMesseageQueue(メッセージキュー)の略

Apache ActiveMQ(※)向けのフルマネージドなメッセージキューを提供するサービス。
ActiveMQと互換性が存在するため、オンプレミスではActiveMQを利用していたエコシステムをAWSにマイグレーションする際にはコードの変更を伴わずに行うことができる。
類似サービスにAWS SQSが存在するが、新規開発時にはAWS SQS、既存のActiveMQのエコシステムをマイグレーションするときはAWS MQといった使い分けが推奨されている。

※ オープンソースのメッセージ関連を処理するミドルウェア。

SNS(エスエヌエス)

SNSはSImple Notification Service(シンプルノーティフィケーションサービス)の略

フルマネージドなPush型のメッセージ配信サービス。
Topicという単位でメッセージ配信管理が行われ、パブリッシャー(配信者)がTopicに対してメッセージの送信を行うと、対象のTopicを購読している全サブスクライバー(購読者)に対してパブリッシャーが送信したメッセージを配信する。
サポートされているサブスクライバーは2020年5月現在 HTTP/S、EMail、Email-JSON、AWS SQS、AWS Lambda、SMS、AWS SNSをサポートしているプッシュ通知プラットフォーム(APNS、FCM...etc)。

イベントに応じてメッセージを送るワークロードで活用される。
AWS CloudWatchEventと連携して、EC2インスタンスのCPU利用率が80%を超えた時にSlackとメーリングリストに通知...など。

SQS(エスキューエス)

SQSはSimple Queue Serviceの略。

フルマネージドなPull型のメッセージキューサービス。
Queueという単位でメッセージ配信管理が行われ、プロデューサー(配信者)がQueueに対してメッセージの送信を行うとキューにスタックされ、コンシューマー(取得者)が手動でメッセージを取得する。
スタンダードキューとFIFOキューの2種類のキューが提供されており、前者は重複配信(2回以上キューから配信される可能性有)や配信順序を保証しないが高速、後者はその反対の性質を持つ。

システム間のやり取りに利用することでシステム連携の疎結合化、分散処理などを実現できるシンプルながら強力なサービス。

SWF(エスダブリューエフ)

SWFはSimple Workflow Service(シンプルワークフローサービス)の略

フルマネージドでいくつかの要素に細分化できる一連の処理をワークフローとして管理することができるサービス。
AWS Step Functionsと似たサービスだが、実装が複雑になりがちなため現在は新規実装であればAWS Step Functionsを利用することを推奨(※)しているみたい。

こちらQ: Amazon SWF と AWS Step Functions はどのように使い分ければよいですか?を参照

AWS コスト管理

AWSサービス利用に伴う料金管理に関するサービス群。

Cost Explorer(コスト エクスプローラー)

全AWSサービスの利用料金、及び利用状況のレポートを作成できるサービス。
過去13ヶ月分のAWS利用料金を予め用意されたビュー(※)で確認することででき、更にフィルターやグルーピングで分析も行うことができる。
AWS BillingConsoleはざっくり利用した料金を確認できるが、AWS Cost Explorerは詳細な情報を確認することが可能。

※ AWSサービスの利用状況を可視化する単位。構築済みのものとしてサービス別の月額利用料金や、日次コストなどがある。もちろん自分でビューを定義することも可能。

Budgets(バジェット)

日、週、月次のレポートを自動作成・送信してAWS用の予算の状況をモニタリングできるサービス。
AWSサービスごとに予算を設定して超過したら、アラートの発報(Email, SNSをサポート)を行わせることで使いすぎや不正利用の検知に利用することができる。
実コストだけではなく、予測コストが超過する場合にもアラート発報が可能。

Marketplace Subscriptions(マーケットプレース サブスクリプションズ)

AWS Marketplace上で各ベンダーが提供しているソフトウェアなどがセットアップされたAMIで、購入(サブスクライブ)したコンテンツの管理を行うサービス。

カスタマーエンゲージメント

エンドユーザのサービスに対してのエンゲージメント(愛着・思い入れ)を強めるためのサービス群。

Connect(コネクト)

フルマネージドでクラウド型のコールセンターを提供するサービス。
これまではコールセンターを立ち上げたいとなった場合は、自前で回線を引いたりシステムの構築が必要だったが、構築済みのコールセンター環境を従量課金で利用することができる。
ACD機能(自動振り分け機能)やIVR機能(自動音声再生機能)、リアルタイムでの履歴確認といった機能も利用可能。

Pinpoint(ピンポイント)

ユーザエンゲージメントを促進するためのフルマネージドなCRM的サービス。
論理的なセグメントを設定してユーザの分類、セグメント別のプッシュ配信やキャンペーンの発行といった機能を備える。

Simple Email Service(シンプルイーメールサービス)

SES(エスイーエス)と略される。

クラウドベースでフルマネージドなEメール送受信サービス。
AWS SESのWebコンソール、AWS SES API(HTTP ,SDK, CLI)、SMTPを利用してメールを送信することが可能。
利用にあたってはスパム利用ではないことを証明するためバウンス率(※1)、苦情率(※2)などを低く抑えてメールの信用を確保する必要がある。
そのためSESのコンソールから都度メトリクスを確認したり、バウンス、苦情時の仕組み(※3)を用意する必要がある。

※1 宛先不在のメールを送って差し戻された
※2 送信先からスパム認定をされた(メールクライアントのスパムとして報告ボタンを押下された)
※3 バウンス、苦情発生時にメール・Slackへの通知やLambdaを利用して送信NGリストに追加してアプリから再度メールを送らないようにする...など

ビジネスアプリケーション

ビジネスシーンで業務をサポートするサービス群。

Alexa for Business(アレクサフォービジネス)

会社などの組織規模でAlexaを利用するための管理機能やスキルを提供するサービス。
会議室の予約やカレンダーサービスとの連携や、共有Alexaに対して利用可能なスキル一覧設定などの一斉配信などが可能となる。

Chime(チャイム)

大規模コミュニティ向けのビデオ、音声、テキストコミュニケーションツール。(SlackとかMicrosoft Teamsに近い感じ)
最大100人での同時通話など大規模なコミュニティで利用するのに適している。

WorkMail(ワークメール)

フルマネージドでWebクライアントからアクセス可能なWebメールとカレンダーを提供するサービス。(G-SuiteのGmail, Googleカレンダー的なサービス)
AD連携、独自ドメイン利用といった機能も備えており、モバイルデバイスからの利用も可能であるためビジネスツールを全てAWSサービスに統一して支払い、管理を楽にしたいケースなどでとても有効。

エンドユーザコンピューティング

エンドユーザにマシン・アプリケーション環境などを提供するサービス群。

WorkSpaces(ワークスペースズ)

クラウド経由の仮想デスクトップ環境を提供するサービス(Azure Virtual Desktop的な...)
2020年5月現在、Windows, Linuxの2OSをサポートしている。
アクセス用のクライアントソフトが利用できれば、モバイル、デスクトップ問わずどこからでも同じ環境を利用することが可能であるため、リモートワークでの作業環境として活用することができる。
AWS WorkSpacesの環境構築時に自動でAWS WorkDocsの環境も構築、50GBまで無料で利用できるため、チームメンバー間でのドキュメント共有なども可能。

App Stream2.0(アップストリーム 2.0)

フルマネージドでデスクトップアプリケーションを配信するサービス。
配信サーバとしてWindowsServerを起動して、その中にインストールされたアプリ内から配信するアプリを設定、許可されたクライアントがアクセスすることで配信許可されたアプリの利用がブラウザ経由で行える。
類似サービスであるAWS WorkSpacesはデスクトップ環境をまるごと提供するのに対して、AWS AppStream2.0は特定のアプリ環境のみを配信するという点が異なる。

WorkDocs(ワークドックス)

フルマネージドなオンラインストレージサービス。(AWS版GoogleDrive、DropBox的な...)
ユーザ認証にはAWS Directory Service(Simple AD or AD Connector)を利用しており、グループの定義なども可能。
Webブラウザ、クライアントアプリからの利用が可能で1ユーザ/月7\$で1TBまで利用可能。AWS WorkSpacesを利用しているユーザは無料で50GBまで利用可能(3$追加で1TB利用可能)。

WorkLink(ワークリンク)

AWS上のプライベートなWebサイト、アプリに対してモバイルデバイスから安全にアクセスする仕組みを提供するフルマネージドサービス。
動作の仕組みとしてはSAML2.0に対応したIdPを利用して認証成功後、WorkLink用のインスタンスが代理で対象のプライベートサイトにアクセスを行ってその内容をレスポンスすることで実現。

IoT

Internet of Things(モノのインターネット化)に関連するサービス群。

IoT Core(アイオーティーコア)

IoTデバイス群とAWSサービスをセキュアに双方向接続・管理するプラットフォームを提供するサービス。
大きく大別して5つのコンポーネントから構成されたサービスであり、それぞれのコンポーネントを活用してIoTデバイスをAWSリソースと連携させる。
AWS Kinesisと比較してMQTTのサポートやデバイスシャドウを利用したアプリ構築などでデバイスの種類が増えても柔軟な対応が行えるため、AWS IoT Coreから AWS Kinesisに繋ぐ構成が推奨されている。

コンポーネント 詳細
デバイスゲートウェイ 接続されたIoTデバイス、AWSサービス間でMQTT、HTTPを利用した通信環境を提供するメッセージブローカー。
認証・アクセス許可 IoTデバイスとデバイスゲートウェイの間でセキュアに接続するための仕組み群。
ルールエンジン SQLライクな構文で接続されたIoTデバイスデータを処理して別のデバイスやAWSリソースとの接続を行えるようにする。
デバイスレジストリ 接続されたIoTデバイスに対してユニークなIDの付与、メタ情報の管理を行う。
デバイスシャドウ 接続されたIoTデバイスの最新のステータスを保持する。外部からIoTデバイスのステータスを参照・取得する際に高いコストを掛けてIoTデバイスに接続しなくてもデバイスシャドウを参照すればよい。

Amazon FreeRTOS(アマゾン フリーアールティーオーエス)

RTOSはReal-time Operating Systemの略。

FreeRTOSという組み込みシステム用RTOSを大規模なIoTデバイス運用に耐えるようにするため、「プログラミング」「デプロイ」「保護」「接続」「管理」などの機能を追加で提供するRTOS。
元々FreeRTOSはデバイス単独で動作させることを考慮していたため、「ローカルネットワーク接続機能」や「クラウド接続機能」といった外部と接続するための機能が設けられていなかったがIoTアプリ開発という需要に対応するために開発されたらしい
AWS IoT Coreに統合されており、そちらから利用することが可能。

IoT 1-Click(アイオーティーワンクリック)

こんな感じのデバイスを押下したときAWS Lambdaを実行する仕組みを提供するサービス。
AWS IoT 1-Clickに対応したデバイスを登録して、押下時に呼び出すAWS Lambdaの関数を紐付けるだけですぐに利用が可能。
AWS Lambdaは好きな処理を実行できるので、ボタンクリック1つでAWS Batchを呼び出してバッチ処理の実行、エンドユーザにプッシュ通知の発行...なんてこともできる。

昔「トイレットペーパー取ってくれ!」というメッセージを送るIoT 1-Clickボタンを作ってトイレに置いてました。

IoT Analytics(アイオーティーアナリティクス)

フルマネージドでAWS IoT CoreはもちろんAWS Kinesisなどの外部サービスからIoT Analytics専用の分析用データストアにデータを格納してSQLライクな言語で分析を行えるようにするサービス。(IoTデータを対象としたAWS Athenaのようなサービス)
分析結果はCSVなどの形式でのダウンロードやAWS QuickSightなどのBIツールと連携して可視化させることも可能。

IoT Device Defender(アイオーティーデバイスディフェンダー)

AWSに接続されているIoTデバイスの設定・動作をセキュリティ的に問題があるかを監視してくれるフルマネージドなサービス。
IoTデバイスに対して以下の機能を提供する。
本サービス自体はAWS IoT Coreのダッシュボードに統合されており、そちらから利用することが可能。

機能 詳細
デバイス設定がセキュアであるか監視 IoTデバイスの設定(証明書、アクセスポリシー)がベストプラクティスに沿っているかを自動で監視する。
異常な振る舞いの検知 セキュリティ関連のメトリクスに手動でチェック条件を設定して監視する。
アラートの生成 上記2点の問題検知時に生成されるアラート。トリガーとして何らかの処理を実行することも可能。
問題への対応方法の通知 問題検知に対して推奨される対応方法を提供。

IoT Device Management(アイオーティー デバイス マネージメント)

IoTデバイスの登録・編集・削除・監視・リモート管理...といったデバイス管理機能をフルマネージドで提供するサービス。
大量のデバイスの一括登録、リモート経由での設定管理機能、実行ログの監視、各地に設定しているデバイスをリモート管理で可能。
本サービス自体はAWS IoT Coreのダッシュボードに統合されており、そちらから利用することが可能。

IoT Events(アイオーティー イベント)

IoTデバイスから発生したデータ、アプリ上で発生したイベントを検出するサービス。(IoT用のAWS EventBridgeみたいなもの)
自由にイベント発生条件を定義することが可能で、例えば温度データが80度を超えた場合に過熱状態に移行のイベントを発行して、60度を三回連続で下回った場合は通常状態に移行のイベントを発行。。。といった具合にできる。
イベント発行時にAWS SNS、AWS Lambdaに渡すことも可能。

Greengrass(グリーン グラス)

AWS IoT Coreの主要コンポーネントをローカル環境で利用可能にするソフトウェア。
IoTデバイスが常時ネットワークと接続できない、クラウドへのデータ転送のレイテンシが遅すぎる、セキュアなIoTデータであるためクラウドにアップロードできない、事前にIoTデータを加工して通信費を抑えたい...といった要件がある場合に、Greengrassをインストールしたゲートウェイを用意してAWS IoT CoreのようにIoTデバイスと接続することでローカル環境でデータ収集が可能となる。(いわゆるエッジコンピューティング)

AWSクラウド側で記述したAWS LambdaのコードをローカルなGreengrass上で動作させるLocal Lambdaという機能がエッジ処理のキモらしい。

SiteWise(アイオーティー サイトワイズ)

複数の産業施設から取得できる何千ものセンサーデータを収集、構造化、可視化するサービス。
複数施設で発生するデータを俯瞰的にモニタリングが可能であるため、どの点がボトルネックになっているか...といった気づき・改善に繋がる。
IoT SiteWiseデータ収集用のソフトウェアをゲートウェイにインストールして稼働させることでデータ収集を行う。(AWS Snowball Edgeなどもゲートウェイとして利用可能)

IoT Things Graph(アイオーティー ティングス グラフ)

フルマネージドでIoTデバイスとウェブサービス(AWS Rekognationなど)とGUIで簡単に接続するサービス。
IoTデバイスは接続規格の整備などが十分に進んでおらず、接続のためにデバイスごとに独自の設定を加えたり接続用のコードを記述する必要があった。
本サービスを利用することで本質的ではないデバイスとアプリの接続などの処理を実施せず、本質的なアプリ開発の作業に集中できるようになる。

ゲーム開発

ゲーム開発に関連するサービス群。

GameLift(ゲームリフト)

マルチプレイ用のゲームサーバをデプロイ・管理・スケーリングするためのサービス。
FPS、格闘ゲームなどの低レイテンシーを要求するジャンル向けのカスタムゲームサーバと、数行のスクリプトで利用できるが複雑なネットワーク処理を必要としないジャンル(カードゲーム、ターンベースのゲーム...etc)に向いたリアルタイムサーバの二種類が提供されている。

コンテナ

コンテナサービスに関連するサービス群。

Elastic Container Registry(エラスティック コンテナ レジストリ)

よく略してECR(イーシーアール)と呼ばれる。

フルマネージドでDockerイメージの管理するリポジトリを提供するサービス。(いわゆる自前で管理するDockerHub的な感じ)
Push, Pull, バージョン管理はもちろんのこと、Pullのみを許可...などの詳細なアクセス権限設定なども可能。
AWSサービス内でクローズドかつセキュアに業務用Dockerイメージを管理したい場合に適している。

Elastic Container Service(エラスティック コンテナ サービス)

フルマネージドでAWSリソース上へのDockerコンテナのオーケストレーション(※)を実現するサービス。
デプロイ、コンテナの自動スケール、タスク配置...etcといった機能を提供してくれるため、デプロイするサーバ1つ1つにログインして設定...みたいなことを行わなくても数クリックで自動スケーリングするクラスタ構成のデプロイなどが可能になる。
通常のEC2コンテナにデプロイする方法と、完全にDockerコンテナのみを起動させるだけのAWS Fargateを利用方法が選択できる。(Fargateは自前でセキュリティパッチなど適用といった運用が不要だが少しお高い)

Elastic Kubernetes Service(エラスティック クーべネティス サービス)

正式名称はAmazon Elastic Container Service for Kubernetes。
略してEKSとよく言われる。

フルマネージドでKubernetes(※)を提供するサービス。
Kubernetesを利用して構築されたエコシステムを簡単にAWS環境にマイグレーションができる。
ECSと同様にデプロイ先にAWS EC2とAWS Fargateを選択可能。

※ クーべネティスと呼んでいるんですが、あっているんだろうか...。
めちゃくちゃ多くのサーバでDockerコンテナを動作させる際に各サーバにログインして実行...みたいなことを行わなくてすむようコンテナの自動デプロイ、スケーリングなどのオーケストレーション機能を提供するオープンソースのプラットフォーム。

まとめ

嘘みたいだろ...?これ、まだ書いてないサービスがあるんだぜ...?
AWS Import/Export, AWS Elastic Load Balancing...などなど

でも概要だけでも知っておけば、仕組みを作ったり、フルスクラッチで実装する前にAWSのサービスを使って楽をする。という選択肢を選ぶことができて、車輪の再発明的なことを防止できそうなので頑張って覚えようと思います。

記載内容に誤りがありましたら、優しく編集リクエストやコメントいただけますと嬉しいです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Route53 ドメイン作成〜常時SSL化 設定まとめ

参考文献

1. Route53 ドメイン作成

作業内容

  • ①「ホストゾーンの作成」からドメイン登録

  • ②レコードセットで"レコードタイプ"を確認

2. AWS Certificate Manager "SSL証明書"作成

作業内容

  • ①「証明書のリクエスト」から、ドメイン名に紐づく証明書を作成

  • ②CNAMEレコードがない場合は、"レコードセット"に登録

3. ロードバランサーの作成

作業内容

  • ①ALB(HTTP / HTTPS)を選択

  • ②リスナー(ロードバランサーのプロトコル)に、"HTTPS"を追加

  • ③セキュリティ設定で、"SSL証明書"を登録

  • ④ターゲットの登録で、使用するインスタンスを登録

  • ※EC2のインバウンドルールでも、"HTTPS"を指定する

4. Route53 ロードバランサー紐付け

  • ①Route53から、対象ドメインのレコードセットに移動する

  • ②"Alias"を"Yes"に変更し、"Alias Target"から、ロードバランサーを選択

5. Nginx起動

Nginx起動コマンド

$ sudo systemctl start nginx.service

Nginx起動確認

$ sudo systemctl status nginx.service

Nginx停止コマンド

$ sudo systemctl stop nginx.service
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Security Token Service (AWS STS)

AWS Security Token Service (AWS STS) とは

STSはAWS Security Token Serviceの略である。

AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。

つまり以下ができるようになる。

  • ユーザーに対して AWS ID を定義せずに AWS リソースへのアクセスを許可できる

これによりIDフェデレーションが可能となる。

※IDフェデレーションの概要
IDフェデレーションは、それぞれ独自のID管理システムを持つ複数のセキュリティドメイン間で、それぞれのユーザーIDをリンクさせる。2つのドメインでIDフェデレーションを実現すると、一方のドメインで認証を受けたエンドユーザーは、他方のドメインでもログインしないでそのリソースにアクセスできる。

一時的な認証情報の一般的なシナリオ

シナリオとしては以下がある。

  • 所有している別の AWS アカウントへのアクセスを IAM ユーザーに許可

  • 第三者が所有する AWS アカウントへのアクセス権を付与する

  • AWS サービスへのアクセスの提供

  • 外部で認証されたユーザー(ID フェデレーション)へのアクセスの許可

試験範囲的にはクロスアカウントかフェデレーションかのどちらかがポイントとなる。

外部で認証されたユーザー(ID フェデレーション)へのアクセスの許可

社内のディレクトリなど、AWS 以外の ID をユーザーがすでに持っているとします。それらのユーザーが AWS リソースを使用する (または、それらのリソースにアクセスするアプリケーションを使用する) 必要がある場合、それらのユーザーには AWS セキュリティ認証情報も必要です。IAM ロールを使用して、ID が組織または第三者のプロバイダー (IdP) からフェデレーションされたユーザーのアクセス許可を指定できます。

これには以下の ID フェデレーションがある。

  • Amazon Cognito を使用したモバイルまたはウェブベースのアプリのユーザーのフェデレーション
    • ウェブ ID フェデレーション
  • パブリック ID サービスプロバイダーまたは OpenID Connect を使用したユーザーのフェデレーション
    • ウェブ ID フェデレーション
  • SAML 2.0 を使用したユーザーのフェデレーション
    • エンタープライズIDフェデレーション
  • カスタム ID ブローカーアプリケーションを作成するユーザーのフェデレーション
  • SAML 2.0 フェデレーティッドユーザーが AWS マネジメントコンソールにアクセス可能にする

Amazon Cognito を使用したモバイルまたはウェブベースのアプリのユーザーのフェデレーション

スクリーンショット 2020-05-17 13.02.27.png

不特定多数に長期的な AWS セキュリティ認証情報を配布しないユースケースに適用する。
IdpとAWSで信頼関係を結ぶこと

パブリック ID サービスプロバイダーまたは OpenID Connect を使用したユーザーのフェデレーション

スクリーンショット 2020-05-17 13.29.04.png

SAML 2.0 ベースのフェデレーション

スクリーンショット 2020-05-17 12.19.57.png

このSAML 2.0 ベースのフェデレーションを使用するには、事前に組織の IdP と AWS アカウントを設定して相互に信頼する必要があることだけ注意

カスタム ID ブローカーを使用したフェデレーション

スクリーンショット 2020-05-17 14.01.16.png

SAML 2.0 フェデレーティッドユーザーが AWS マネジメントコンソールにアクセス可能にする

スクリーンショット 2020-05-17 13.45.31.png

ユーザーは組織の内部ポータルから AWS マネジメントコンソールに移動するだけで、AWS 認証情報を指定する必要はありません。

  • ユーザーは組織のポータルにアクセスして、AWS マネジメントコンソール に移動するオプションを選択
  • ポータルが組織内のユーザーの ID を確認
  • ポータルは、ユーザーを識別するアサーションを含む SAML アサーションレスポンスを生成し、ユーザーの属性を含めます。コンソールセッションが有効な期間を指定する SessionDuration という SAML アサーションの属性を含むよう IdP を設定できます。セッションタグとして属性を渡すように IdP を設定することもできます。ポータルはこのレスポンスをクライアントブラウザに送信
  • クライアントブラウザは AWS のシングルサインオンエンドポイントにリダイレクトされ、SAML アサーションを投稿
  • エンドポイントは、ユーザーの代わりに一時的なセキュリティ認証情報をリクエストし、コンソールのサインイン URL を作成
    • エンドポイントが代わりにリクエストしている点がポイント
  • AWS は、サインイン URL をクライアントにリダイレクトとして送信
  • クライアントのブラウザは AWS マネジメントコンソールにリダイレクト

試験に出るトラブルシューティング

アクセスキーを紛失しました。

  • マネコンから確認できます。
  • シークレットキーを無くした場合は新しいキーを作り直してください。

古いアカウントに入りたい

  • ログイン画面からEmail回復手段があるはず
  • 詰んだ場合はAWSサポートに連絡してください

AWS サービスに要求を送信すると "アクセス拒否" が発生します

  • リクエストしたアクションとリソースを呼び出すアイデンティティベースのポリシーのアクセス許可を持っていることを確認
  • リソースベースのポリシーをサポートするサービスにアクセス
    • ポリシーでお客様がプリンシパルに指定されていて、アクセス権限を付与されていることを確認
  • アカウント内のサービスにリクエストする
    • アイデンティティベースのポリシーまたはリソースベースのポリシーを使用して、アクセス許可を付与
  • 別のアカウントのサービスにリクエスト
    • アイデンティティベースのポリシーとリソースベースのポリシーの両方でアクセス許可を付与
  • キー – 値のペアを持つ条件がポリシーに含まれている場合
    • ポリシーを慎重に確認

一時的な認証情報を使用して要求を送信すると "アクセス拒否" が発生します

  • サービスが一時的セキュリティ認証情報を受け入れることを確認
  • 一時的な認証情報が失効していないことを確認
  • IAM ユーザーまたはロールに正しいアクセス権限があるかどうかを確認
    • 一時的なセキュリティ認証情報のアクセス許可は IAM ユーザーまたはロールから取得されます。

ポリシーの変数が機能していません

  • 変数のあるすべてのポリシーで、バージョン番号: "Version": "2012-10-17" がポリシーに含まれていることを確認

参考文献

押さえておきたい機能

自分のリソースがどのように共有されているかを分析できるサービス

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSの請求情報を毎日Slackに投稿してコスト意識を高めることにした

コードの置き場所

以下に置いているので好きに使ってください。Serverless FrameworkとPythonコード合わせて150行も無いので読めば分かると思います。

https://github.com/shogomuranushi/aws-billing-police

何ができるのか

こんな風に費用が発生しているAWSサービスが列挙されて毎日通知されます。

image.png

なぜ作ったのか

コロナの影響もあって今後どうなるか分からないですよね。コスト意識は少しでも改善したいいところ。
で、予実管理はしてるけど月単位なのでスパンが長いので、毎日なら検知もしやすく何にいくらかかってるかもすぐにわかるようになるので、毎日通知する君を作りました。

使い方

GitHubのREADMEにも書いていますが、

  1. SlackのWebhook URLを取得します。

    1. こちらのURLを参考に取得してください。 -> Slack での Incoming Webhook の利用
  2. AWSのパラメータストアにWebhookのURLを入れます。

    bash
    aws ssm put-parameter --region us-east-1 \
        --name "SLACK_WEBHOOK_URL" \
        --description "Slack Webhook URL" \
        --type "String" \
        --value "https://hooks.slack.com/services/xxxxx/xxxxx/xxxxx"
    
  3. envディレクトリの中身を書き換えます。投稿先のSlack ChannelとAWSのアカウント名(表示用)を設定します。

    vim ./env/dev.yaml
    
  4. デプロイします。裏ではServerless FrameworkでLambdaとCloudWatch Eventがデプロイされます。

    bash
    make dev
    

注意事項

  • 前日と言ってもAWS側で集計に少し時間を要するために2日前のAWS利用量を出力しています。
  • ドルから日本円に変換しています。固定で110円にしています。
  • 0円のものも投稿されるので邪魔なので2円以上のサービスのみ表示されるようになっています。この辺りはコード内をお好きに弄りください。
  • 投稿内容の文字列を変更したい場合はこちらを修正ください
  • Slackへの投稿時間を変更したい方はこちらを変更ください。なお、GMTになりますので注意ください。
  • コストエクスプローラーAPIのエンドポイントはバージニアになるためバージニアでデプロイしています
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CDKでCognitoユーザープールを作るとメールアドレスが変更できない問題とその解決策

はじめに

AWS CDK は TypeScript や Python などのプログラミング言語を使って AWS CloudFormation のテンプレートを定義できるツールです。 YAML や JSON で定義するのに比べると可読性が高く、 TypeScript を使って定義がすることで補完が強力に効いたり、間違った値を入れるとエディタ上でエラーが確認できるというメリットがあります。

AWS CDK で Cognito ユーザープールを作成するための @aws-cdk/aws-cognito は現時点では EXPERIMENTAL となっており注意が必要ですが、実際に使用してみたところ初めは問題なさそうに見えたのですがメールアドレスが変更できないという問題が後から発覚しました。

前提

以下がメールアドレスによるログインが可能な Cognito ユーザープールを AWS CDK で作成する際の基本的なコードになります。

import * as cdk from "@aws-cdk/core";
import * as cognito from "@aws-cdk/aws-cognito";

export class AuthStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const userPool = new cognito.UserPool(this, "UserPool", {
      selfSignUpEnabled: true,
      signInAliases: {
        email: true,
      },
      requiredAttributes: {
        email: true,
      },
      autoVerify: {
        email: true,
      },
    });
  }
}

このコードで作成したユーザープールをコンソール上で確認すると以下ような設定になります。

ユーザープール_-_Amazon_Cognito.png

signInAliases: { email: true } を設定したことにより、サインイン方法が Eメールアドレスおよび電話番号 および Eメールアドレスを許可 になっています。
サインイン方法が ユーザー名 の場合ユーザー名はサインアップ時にユーザーが指定したものとなりますが、今回の設定ではサインアップ時に sub (ユーザー作成時に作られる一意な UUID)がユーザー名としてセットされ、登録したメールアドレスに確認メールが届き、確認が完了するとユーザーはメールアドレスを使ってログインできます。

ユーザープール_-_Amazon_Cognito.png

メールアドレスを使ってユーザーにログインさせたい場合、デフォルトの設定よりもこの設定が望ましいのではないでしょうか。ただしコンソール上の画面で選択肢が灰色になっていることからわかるように、サインイン方法はユーザープール作成時にのみ設定でき後から変更することが出来ないため、この設定は慎重に行う必要があります。

何が問題なのか

上記のコードで cdk synth を実行すると、 cdk.out ディレクトリに以下のような CloudFormation テンプレートが確認できます。

    "UserPool6BA7E5F2": {
      "Type": "AWS::Cognito::UserPool",
      "Properties": {
        "AdminCreateUserConfig": {
          "AllowAdminCreateUserOnly": false
        },
        "AutoVerifiedAttributes": [
          "email"
        ],
        "EmailVerificationMessage": "Hello {username}, Your verification code is {####}",
        "EmailVerificationSubject": "Verify your new account",
        "Schema": [
          {
            "Name": "email",
            "Required": true
          }
        ],
        // 長いので省略
      },
      "Metadata": {
        "aws:cdk:path": "auth/CustomMessage/ServiceRole/Resource"
      }
    },

ここで注目するべきは Schema です。 CloudFormation でユーザープールのスキーマを定義するとき、デフォルトでは後から変更できない状態で作られてしまいます。変更可能にするには以下のように "Mutable": true が指定されていなければなりません。

"Schema": [
  {
    "Name": "email",
    "Required": true,
    "Mutable": true
  }
],

参考: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-cognito-userpool-schemaattribute.html

この設定もサインイン方法と同様、ユーザープールの作成時にのみ設定でき、後から変更することはできません。そして、標準属性が Mutable かどうかはコンソール上では確認できません。

解決方法

高レベル API を使いたい場合(その1)

CDKでは cognito.UserPool クラスなどの抽象的な API を 高レベル API と呼びますが、高レベル API とは別に Cfn プレフィックスのついた CloudFormation レイヤーの操作ができる API が必ず提供されています。

今回のように高レベル API がまだ対応していないプロパティをどうしても変更したいときは、高レベルインスタンスから Cfn インスタンスを取得した上でプロパティのオーバーライドが可能です。

https://docs.aws.amazon.com/cdk/latest/guide/cfn_layer.html#cfn_layer_raw

今回のケースでは以下のようなコードを追加することで対応可能です。

const cfnUserPool = userPool.node.defaultChild as cognito.CfnUserPool;
cfnUserPool.addPropertyOverride("Schema.0.Mutable", true);

この方法は Schema.0 を指定していることからわかるように、 email 属性が Schema の1番目に定義されているのを前提としています。CDK の仕様変更やカスタム属性を追加したときに Schema の順番が変わらないことは保証されていませんので、あまりお勧めはできません。
(とはいえ、仮に途中で仕様が変わってもデプロイに失敗するだけですので、ユーザープールの作成時にのみしっかり確認すれば悪くはなさそうです)

高レベル API を使いたい場合(その2)

上記の方法と方針は同じですが Schema.0 で指定してしまっている問題を解消できないか試してみたところ、より手続き的な書き方にはなってしまいますが一応こんな感じで対応可能でした。

const cfnUserPool = userPool.node.defaultChild as cognito.CfnUserPool;
const emailAttribute = (cfnUserPool.schema as cognito.CfnUserPool.SchemaAttributeProperty[]).find(
      (attribute) => attribute.name === "email"
);
if (emailAttribute) {
  // @ts-ignore mutableの型がreadonlyで定義されてしまっているため
  emailAttribute.mutable = true;
}

高レベル API を諦める

上記の高レベル API を使う場合の方法はどうしても無理やり感があり、最初から cognito.CfnUserPool を使うか CDK 以外の方法で CloudFormation を管理したほうが正攻法な気がします。
(この際 "Mutable": true を忘れてしまっては意味がないので気をつけてください!)

CloudFormation での管理を諦める

結局私はこの方法をとり、 Cognito ユーザープールについてはコンソール上で手作業で作成するようにしました。
今回の例のように Cognito ユーザープールは作成時の設定を間違えると詰む項目がいくつかあるため、自分から "Mutable": true を指定しなければいけないという CloudFormation の仕様が危険な気がしたためです。
CDK 管理下にないユーザープールを CDK 内で参照したくなった場合は fromUserPoolArnfromUserPoolId で参照することが可能です。

Tips: CDK 管理下からの外し方

メールアドレスが変更できない状態でユーザープールを作ってしまい既にユーザーが登録されてしまった場合、ユーザープールは CDK の管理化から外して上に挙げたような対策を取った上で作った新しいユーザープールにユーザーを移行する必要があります。
(シームレスなユーザー移行には UserMigration トリガーの Lambda を実装する必要がありますがここでは割愛します)
この場合 "DeletionPolicy": "Retain" を設定してから CloudFormation 上からリソースを外すのですが、 cognito.UserPool のオプションには現状 deletionPolicy がないので、これも Cfn インスタンスを一度取得してから設定をします。

const cfnUserPool = userPool.node.defaultChild as cognito.CfnUserPool;
cfnUserPool.cfnOptions.deletionPolicy = cdk.CfnDeletionPolicy.RETAIN;

まとめ

AWS CDK はとても便利ですが、今回のような問題に直面したときには背後にある CloudFormation や AWS のサービスそのものについての理解が必要になります。
とはいえ今回の根本的な問題は Cognito ユーザープールの設定が作成後に変更できないものがあるというところにあるように思えます。認証という必要不可欠かつ重要な役割を担うサービスですので、 Cognito ユーザープールの今後の改善に期待したいです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSのELB(Elastic Load Balancing) 構成時に Auth0 認証の例外 (Invalid state) に対処する

経緯

  1. ローカル環境 (ロードバランサー無し) ではうまく認証できる。
  2. AWS上 (ロードバランサーあり) だと Invalid state でエラーになる。

    /Auth0.php
    throw new CoreException('Invalid state');
    

    https://github.com/auth0/auth0-PHP/blob/660163b31beae4c550db68022c568b41df75d8e9/src/Auth0.php#L518

  3. エラーの原因を調べる。どうやら xxx.auth0.com 側の認証処理後に callback url に乗せて Get パラメータで戻される state の値とサーバの state の値に相違がある...。

結論

EC2 > ロードバランシング > ターゲットグループ > 属性の編集 > 「維持設定 有効化: on」 にする。

image.png

注: 根本解決ではないが、ひとまずこの対処でいくことにした。
一定負荷を超えた場合に備えてスケーラブルなサービスを提供している場合、この方法ではのちのち問題になるので Amazon ElastiCacheを使うのが定石らしい。

余談

んなことで2時間ちかく時間が...けどこれロードバランサー使うときの常識なんだろうな?
ちゃんと理解しておかないと他のトラブル時に対処できない、まずいな。

参考

スティッキーセッションというらしい。
https://hack-le.com/sticky-session/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む