AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～2. コスト管理～

Organizationsシリーズ第二弾です。今回はコスト（利用料）管理についてです。

Organizationsの紹介（はじめに編）はコチラ

前回はコチラ

シングルアカウントの場合

シングルアカウントでは、コストの可視化のために以下の設定を行います。

• IAMユーザーの請求情報アクセス許可
• Cost Explorerの有効化
• 予算およびアラートの設定（AWS Budgets）

Organizationsを使用している場合はどうなるのか見ていきます。

IAMユーザーの請求情報アクセス許可

デフォルトではIAMユーザーは請求情報にアクセスできず、ルートユーザのみアクセスが可能です。

右上のアカウント名＞マイアカウントを順に選択してアカウント設定ページへ遷移し、ページ下部にある「 IAM ユーザー/ロールによる請求情報へのアクセス」をアクティブ化することで、IAMユーザーが参照可能になります。

Organizationsを使用している場合は、マネジメントアカウントでこの設定を行うことで、Organizations配下のすべての連結アカウントで請求情報へのアクセスが有効になります。そのため、最初にマネジメントアカウントで有効にすればOKです。

マネジメントアカウントから請求の画面を確認すると、以下のようにアカウント単位の利用料も確認できます。

連結アカウント内で請求情報を確認すると、シングルアカウント運用時と同様に、自アカウントの利用料のみ表示されます。

Cost Explorerの有効化

Cost Explorerは、AWS利利用を月別、日別やサービス別で確認できるツールです。IAMユーザーの請求情報アクセス許可同様に、マネジメントアカウントで有効にすることで配下の連結アカウントでもCost Explorerが使用できるようになります。

請求同様に、マネジメント（親）アカウントから見ることで、アカウント単位のコスト確認も可能です。もちろん組織全体としてのコスト分析も可能です。

また、マネジメント（親）アカウントのCost Explorer＞設定では、配下の連結アカウント内で表示できる情報を設定できます。

たとえば、マネジメント（親）アカウントで利用料割引となるクレジットや返金が適用されると、それらの割引はOrganizations全体に渡って各アカウントに分配されますが、これらの割引情報を連結アカウント内では表示できないように設定できます。割引情報はマネジメント（親）アカウントで管理し、配下の連結アカウントでは実際に利用料としてかかっているコスト（割引なし）を管理するといった運用が可能になります。

予算およびアラートの設定

あらかじめ想定した利用料を決めておき、想定した利用料を超えたらアラートを行うといった設定がAWS Budgetsで可能です。

このBudgetsの設定は、マネジメントアカウントで組織全体として設定も可能ですし、連結アカウント内でアカウント単体としてのBudgetsも設定可能です。

マネジメントアカウント（組織全体）と各連結アカウントでコスト管理担当がそれぞれいる場合は、組織全体、アカウント単体それぞれで設定して管理していくと良いでしょう。

マネジメントアカウントの予算設定で、特定のアカウントを指定した設定も可能です。

OUの指定はできませんでしたが、組織内のいくつかのアカウントをまとめたコストを管理したいといった場合に利用できそうです。

さいごに

マネジメントアカウントと連結アカウントという言葉が頻繁に出てきて、ちょっと混乱しますが、まとめると以下のとおりです。

• コストサービスの有効化はマネジメント（親）アカウントで有効にすればOK
• 有効化後のコスト管理は、組織全体でもアカウント単体でも可能

コスト管理はクラウドではとても重要な運用項目となりますので、これらのサービスを使用してうまく管理していきたいですね。

次回はCloudTrailについて見ていく予定です。

次回はコチラ

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～1. IAM、AWS SSO～

Organizationsを活用したセキュリティサービスの活用、第一弾は認証・認可にかかわるIAMとAWS SSOについて見ていきたいと思います。

Organizationsの紹介（はじめに編）はコチラ

シングルアカウントの場合

AWSアカウントを1つで運用する場合、ユーザーの認証・認可では以下の対応が必要になります。

• ルートユーザの保護
• 管理者および利用者のIAMユーザーの作成

それぞれマルチアカウントになるとどうするのが良いのか見ていきたいと思います。

ルートユーザの保護

ルートユーザとは、AWSアカウント作成時に設定したメールアドレスとパスワードでログインできるユーザのことを指します。Organizations経由でAWSアカウントを作成した場合も、ルートユーザは同じく存在します。

このルートユーザを保護するために、「強力なパスワードの設定」と「多要素認証（MFA）の有効化」を行いますが、現時点でOrganizationsから複数アカウント一括でこの設定をする方法はありません。そのため、各アカウントのルートユーザーでログインしてパスワードおよびMFAの設定を行う必要があります。

Organizationsからアカウントを作成した場合、AWS側でランダムにルートユーザーのパスワードが設定されます。利用者にこのパスワードは通知されないため、パスワードの初期化を行ってログインを行います。

ログイン後、MFAの有効化を行います。

MFAの設定以外にもルートユーザのみ設定可能な以下のような項目は合わせて設定しておくと良いでしょう。

※追記：請求情報、Cost Exploerはマネジメントアカウント側で有効にすることで組織内のアカウント全てで有効になります。

• IAMユーザーの請求情報アクセス許可　→マネジメント（親）アカウントのみでOK
• Cost Explorerの有効化 　→マネジメント（親）アカウントのみでOK
• サポートプランの変更

ここまではシングルアカウントでやっていた作業を各アカウントそれぞれで実施するだけですね。

Organizationsを使用してルートユーザの保護方法として、Service Control Policy（SCP）を使用する方法もあります。

SCPは前回の記事でも記載のとおり、複数のアカウントにまとめてIAMポリシーのような形でポリシーを記載して、実行できる操作を制限できる機能です。

AWSの公式ドキュメントにも以下のような例があり、この例ではルートユーザのEC2操作をDenyしています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictEC2ForRoot",
      "Effect": "Deny",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:root"
          ]
        }
      }
    }
  ]
}

ただし、すべてのルートユーザの操作を拒否できるわけではないため注意が必要です。拒否が効かない内容は以下のドキュメントに書いてあります。

docs.aws.amazon.com

ルートユーザの保護はここまでです。

IAMユーザの作成、管理

シングルアカウントの場合、アカウント内の利用用途に応じて、用途ごとにIAMグループを作成し、個人ごとのIAMユーザーをグループに適用していくのが良いかと思います。 複数アカウントになった場合、アカウントごとにIAMユーザーを作成していくと、認証情報（ID、パスワード、アクセスキー）が多くなり、管理も煩雑になります。 認証情報が多くの場所にできると、セキュリティリスクにもなります。

そこで認証情報の一元管理ができ、Organizationsとも連携できる機能がAWS SSO（AWS Single Sign-On）です。概要と開始方法を書いていきます。

AWS SSOとは

AWS SSOは、複数AWSアカウントの認証情報を一元管理してシングルサインオンの機能を提供するサービスです。 ID、パスワードはもちろん、認可の情報（IAMポリシー、どのActionができるか）も合わせて一元管理できるすばらしいサービスです。

実際の設定と画面を見たほうがわかりやすいと思いますので、開始方法をまずは書いていきます。

AWS SSOの開始方法

以下のような構成で試していきます。マネジメント配下に2アカウントあり、それぞれ別のOU（組織単位）に属しています。 OUには複数アカウント所属することも可能です。

AWS SSOは、アカウントの委任には対応していないため、マネジメントアカウント上で設定する必要があります。

なお、AWS SSOで管理するIDはMicrosoft Active Directoryなど、外部のIDプロバイダーを指定することも可能です。今回はAWS内でできる限り完結するために、AWS SSO内でIDの設定を行いたいと思います。

Azure ADでの設定方法は以下の記事で書いていますので、参考にしてもらえればと思います。（一部設定作業は今回と同様になります。）

fu3ak1.hatenablog.com

それでは設定していきます。 マネジメント（親）アカウントのIAMユーザーでログインします。

AWS SSO画面に遷移し、有効にします。

Organizationsの組織が作成されていない場合は、以下のとおり表示されます。 AWS組織の作成を押すことで、組織が自動作成されます。

Organizations側から組織を作成済みであればこの画面は出ないかと思います。

組織の新規作成時は、メールの検証が必要となるため、アカウントのメールアドレスに届いたメールを確認して青いボタンを押しておきます。

30秒ほどでSSOの設定は完了すると思います。

ユーザー、グループの作成

ユーザー単独ではなくグループ単位で権限管理するため、まずはグループを作成します。

管理者用にadminというグループを作成します。

続いてはユーザーです。

必須項目であるユーザー名、メールアドレス、氏名情報のみ入力します。

先ほど作成したadminグループに所属させ、ユーザーを追加します。

以下のように登録したメールアドレスにメールが届くので青いボタンを押しておきます。

パスワードを設定してログインはできますが、まだAWSアカウントの設定をしていないためアプリケーションが無いと表示されます。

アクセス権限セットとアカウントの設定

AWSアカウントにログインできるよう設定していきます。まずは権限を設定するアクセス権限セットです。

今回はAWS側で職務単位で用意されている職務機能ポリシーを使用します。

※本番運用時は、必要な権限を決めて最低限の権限となるように付与しましょう。

管理者用にAdministratorAccessを付与します。

タグは特に設定せず、内容確認して作成します。

作成できました。

続いてログインする対象のアカウントを選択します。 アカウント一覧はOU単位で表示されます。今回はsystem01アカウントとauditアカウントの2つを選択して、ユーザーを割当します。

作成しているグループadminに割当します。

作成した権限セットを選択して完了します。

しばらくするとアカウント側の設定が完了します。詳細を見ると、アカウント側でIAMロールが作成されていることがわかります。

MFAの設定

ログイン時にMFAを強制するよう設定します。ここも一括でできるのがAWS SSOの魅力ですね。

サインインのたびに要求し、登録がない場合は登録を要求するようにして保存します。

ログイン確認

SSOの設定が完了したので、作成したユーザーでログインしてみます。 ログイン用のURLはAWS SSOのTopにも表示されています。

ユーザー名、パスワードを入力すると以下のようにMFAを設定する画面が表示されます。 指紋認証も可能な「組み込みの認証アプリ」を使用しようとしたのですが、私のPCが対応してないようだったので、今回は認証アプリを使用します。

※スマホでログイン画面を見た場合は、指紋認証も設定できそうでした。

認証アプリでQRコードを読み取って、表示された番号を入力して設定します。

なお、私だけ、たまたまなのかもしれないですが、初回は以下のようにエラーとなりました。 再度ログインURLにアクセスすることでログインできました。

ログインが完了すると、以下のようにアクセス可能なAWSアカウントが一覧で表示されます。 system01アカウントのマネジメントコンソールへアクセスします。

ログインできました。

AWS SSOの設定は以上です。

AWS SSOのポイント

利用方法が理解できたところで、あらためてAWS SSOのポイントです。

認証・認可の管理を一ヵ所で行える

これが一番大きなポイントかと思います。MFAの強制もAWS SSO1ヵ所で設定してすべてのSSOユーザーに有効にできるのはとても良いですね。

CLIが使用できる

本記事の手順では紹介しませんでしたが、マネジメントコンソールへ入るときに、「Command Line or …」を選択すると一時的なアクセスキーを発行できます。 より安全な形でキーの発行、CLIの利用が可能になります。

AWS以外のアプリも使用できる

AWSアカウントへのログインをメインとしてAWS SSOがよく利用されますが、他のアプリへのログインも可能です。随時使用できるアプリは増えているようです。設定はSSO＞アプリケーションから可能です。

AWS SSOをIDのベースにして他アプリへのログインといった管理もできますね

外部IDプロバイダとの連携も可能

設定手順の最初にも書きましたが、外部IDとの連携機能も嬉しいですね。たとえば普段の業務ではActive Directoryの認証を使用している場合、その認証でAWSへログインするといった運用も可能です。

さいごに

本記事ではマルチアカウントのセキュリティサービス紹介の第一弾としてAWS SSOをメインに紹介しました。

認証・認可のところはAWSの使用開始にも必要であり非常に重要な部分でありますので、できるだけ早く検討、設定することをおススメします。

次回はコスト管理のサービスをまとめていきたいと思います。

次回はコチラ

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～はじめに～

AWSのセキュリティサービス、活用できていますでしょうか。

私も過去に以下のような発表を行ったり、

以下のような記事を書いております。

www.nri-net.com

記載内容は、AWSアカウントは作成した時点でリスクを持つので、最低限有効化すべきサービスを有効にして、セキュアな状態を保ちましょうというものになります。

ただし、この内容はあくまでAWSアカウントを1つ作成するときの内容となっています。最近では開発、本番など環境に応じて複数のアカウントで1システムを運用することも多くなってきていると思います。

そこで複数アカウントの場合はAWSのセキュリティサービスをどう使用できるのか書いていきたいと思います。 すべてのサービスを1記事で書くと長くなるので、連載形式で順々に書いていこうと思います。

今回は「はじめに」ということでマルチアカウント管理の要である、Organizationsの機能についてざっと整理します。

AWS Organizationsとは

Organizationsは、複数のAWSアカウントを管理して、各種サービスをアカウント間で連携できる機能を持つサービスです。いくつかポイントを紹介します。

一括請求ができる

通常（Organizationsを使用しないで）AWSを利用する場合は、AWSアカウントごとにクレジットカード情報を登録し、アカウント単位で請求が発生します。

AWSにはコストを可視化できるCost Exploerなどコスト管理のサービスがいくつかありますが、これらのサービスもアカウント単位で利用することになるため、システム全体としてコストを管理していく場合に難しくなります。また、アカウントの追加ごとにカード情報を入力する必要があるため、手間もかかりますし、セキュリティ面でもカード情報が多く登録されることは好ましくないかと思います。

Organizationsを使用すると、請求およびコストの管理をマネジメントアカウントという全アカウントの親にあたるアカウントで一元管理が可能になります。

マネジメントアカウント上でシステム全体、またアカウントごとのコスト管理も可能になり、請求情報も1ヵ所で管理できるようになります。

他のAWSサービスを組織単位で使用できる

Organizationsで作成したAWSアカウントの集まりを組織と呼びますが、組織単位（＝全アカウント）でまとめてAWSサービスの設定が行えます。 使用できるサービスは限られますが、例えばAWSの操作履歴を残すCloudTrailの証跡設定では、組織単位でCloudTrailの証跡を有効にすることで、全アカウントの操作履歴を1つのアカウントで見れるようになります。

管理アカウントの委任

複数のアカウントに分ける場合、役割ごとにアカウントを分けるのが一般的であり、AWSもそれをベストプラクティスとする場合が多いです。役割ごとに分ける＝1アカウントに1つの役割を持たせるということになります。

Organizationsのマネジメントアカウントは請求管理の役割を持つので、セキュリティ情報の集約は別途セキュリティアカウントを用意してそこに集める構成を取ることも多いです。ただし、組織単位でサービスを使用すると、デフォルトではマネジメントアカウントに情報が集約されます。たとえばAWSの設定情報履歴を保存する AWS Configでは、CloudTrailのときと同様デフォルトでマネジメントアカウントに情報が集約されます。

この情報集約の役割を別アカウントに移せるのがアカウントの委任機能です。 委任が使用できるサービスは限られますが、アカウント委任を使用してセキュリティ集約アカウントに情報を集めることができます。

OU(Organizational Unit)とSCP(Service Control Policy)

OrganizationsにはOUという機能があり、組織内のアカウントをOUという単位でグループ化することができます。たとえば以下のように複数のシステムアカウントをまとめて一つのOU、セキュリティアカウントは別のOUという形でグループ化しておくことができます。

このOUと組み合わせて使用できる強力なセキュリティ機能がSCPです。SCPは複数アカウント（OU単位）に設定できるIAMポリシーのような機能で、「指定したOUに所属するアカウントではアクセスキーの作成を禁止する」といったセキュリティガードレールの設定も可能です。OUとSCPの具体的な設定方法については、以前私が発表した資料に書いておりますので、合わせてみていただけると幸いです。

そのほか指定のOUに所属するアカウント全てにCloudFormation（StackSets）を実行するといった、別サービスとの連携機能も一部あります。

AWS SSOとの連携

AWS SSO はOrganizationsと組み合わせて使用できるシングルサインオンのサービスです。1箇所で利用者の認証・認可の管理ができます。 こちらはOrganizationsの機能というよりは別のサービスになりますので、次回以降の記事で解説していこうと思います。

各セキュリティサービスの利用方法

Organizationsの機能をざっくり整理できたところで、これを活用して各セキュリティサービスがどう利用できるのか、以下のポイントで見ていきたいと思います。

• サービス有効化、マルチアカウントでの集約手順
• 組織単位で利用可能か
• アカウントの委任は可能か

見ていくサービスは以下のとおりです。各サービスの詳細は次回以降の記事で順々に書いていこうと思います。

1. ルートユーザの保護、IAMの管理（AWS SSO）
2. コストの可視化（Cost Explorer、Budgets）
3. CloudTrail
4. AWS Config
5. Amazon GuardDuty
6. IAM Access Analyzer
7. AWS Security Hub
8. Amazon Detective
9. AWS Personal Health Dashboard
10. AWS Trusted Advisor

各サービスの記事ができたら、この記事にもリンクを貼っていく予定です。 ひととおり書けたら、まとめと、CloudFormationでコード化するところも書いてみたいと思います。

マイペースで進めますので、完成は未定です・・1月上旬くらいには・・

→ひととおり書いてまとめました

re:Invent2020セッションレポート ：(DOP309) Test twice, deploy once: Testing infrastructure code on AWS

概要

インフラコードのテストに関するセッションです。タイトルの「Test twice, deploy once」は、英語のことわざ（？）である「measure twice and cut once」（2回測って、1回切る＝慎重に）から来ているようです。どのように正確に、インフラをテストできるのか。といった観点ですね。

AWSさんのセッションなので、AWS標準のツールであるCloudFormationとCDKを使用する場合の話になります。（TerraformなどAWS外のIaCツールについての説明はありません）

セッション内容

Why infrastructure as code?

• 背景

  • 昔はオンプレミスのサーバー数百台にそれぞれJavaなどのソフトウェアをインストールしていた。時間がかかる
  • 2000年代前半にIaCという言葉が出てきてブームになってきた
  • 現代ではインフラはコード前提で考えるべき。クリックではなくLovelyなインフラのコードを

• なぜIaCなのか？

  • 再利用可能で、何がデプロイされるのか予測できる
  • 共通のツールで変更リリースをコード変更として実行できる、テストもできる
  • 本番やステージングなど、環境のコピーがしやすい

Testing AWS CloudFormation

• コードには何をするか？

  • テストをする、アプリケーションと同様
  • 本番環境にリリース前にテストを実行しておきたい

• CloudFormationの概要

  • AWSのIaCフレームワーク
  • YAML or JSONで記載
  • テストの実施手法もたくさんある

• テストはどこから始めれば良いか
  • Editorでまずできる
  • 例えばVS Codeであればテスト用のプラグインが用意されている
  • 例えばCloudFormation nag、セキュリティ的な警告も出してくれる（強い権限のIAMなど）

• cfn-nag
  • rubyのgemパッケージ
  • セキュアでないコードを見つけて警告を出してくれる

• cfn-lint
  • linter
  • コードの静的解析ツールで、文法チェックを行ってくれる
  • リージョン単位でサポートしていないEC2などのケイパビリティも含めてチェックしてくれる

• TaskCat
  • 実際にテンプレートをデプロイしてテストできるツール
  • 複数のパラメータ入力に対応
  • 設定したパラメータで、実際にテンプレートがデプロイできるかチェックできる
  • デプロイが正常に完了したら、リソースは削除される

Testing AWS Cloud Development Kit (AWS CDK)

• なぜCDKなのか？
  • CloudFormationはパラメータを書くので読みやすい、JSON or YAML
  • Pythonコードで開発を行っているチームの場合、なぜPythonでIaCを書かないのか？となる
  • CDKを使うとPythonで書ける
  • JavaやC#など他の言語にも対応している
  • 開発も盛んに行われており、ライブラリも多い
  • CloudFormationよりも複雑になることもある、なのでテストをする

• CDKをどうテストしていくか
  • jest というツールを使用してテストができる
  • Snapshot tests、Fine-grained assertions、Validation tests３種のテストができる

• Snapshots
  • CDKでデプロイした状況をSnapshotとして状態保存しておき、変更がされたら検知ができる
  • 一度CDK経由でデプロイして、リソースの変更が行われると、テストがfailとなる
  • テストがfailした場合はスナップショットを更新して対応する

• fine-grained assertions
  • Snapshotsではできなかった機能単位の細かなテストを実施したい
  • fine-grained assertionsを使用して実行できる
  • 例えばメッセージ保持期間がXXXのSQSリソースがあるかチェックするいった書き方ができる
  • チェックする内容から書くテスト駆動開発な進め方もできる

• SQSキューの保持期間が誤っていると以下のようにエラーになる

• validation tests
  • 時間がないので資料なし、説明でさらっと
  • 値の最小、最大といった少し複雑な書き方ができる。

Pipeline

• IaCもアプリ同様にパイプラインにいれましょう

• GitリポジトリにIaCテンプレートをコミット

• Buildフェーズではテストに必要なパッケージを用意してlintやnagといったコード解析テストを実行
• CDKの場合はjestを使用

• Testフェーズではどこかの環境にデプロイを行い、Lambda等を使用して環境チェックを行うテストを実行する
• テストが正常終了したらProduction環境へリリース

• CloudFormationの場合は以下のようなパイプライン構成となる

CDK Pipelines デモ

※デモ見たいかたはこちらのセッション動画をご覧ください（28:50頃～）

↓デモより一部説明を抜粋↓

• CDK Pipelinesはマルチリージョン、マルチアカウントにパイプラインの整備ができる
• パイプラインリソースとアプリケーションリソース（デモではLambda＋API GW）をCDKの中で管理
• stageという概念を使って、同じAWSリソースを複製できる
• cdk deployコマンドでパイプラインをデプロイできる
• test用のステージおよび処理もCDKの中に書ける（CurlコマンドによるURLチェックなど）
• デモで使ったコードは以下Githubにある

GitHub - darko-mesaros/cdk-pipelines

Homework

• 宿題（まとめ）
  • インフラコードに色々なツールを入れて書き方デバッグ、テストをしてみよう
  • インフラをCI/CDしよう
  • 素晴らしいセキュアなインフラコードを書くことを楽しもう

感想

今やっている私がやっている業務にドンピシャな内容でした。現在はCloudFormationをメインにIaCの管理を行っていますが、パラメータを全て書くというところにツラさを感じているところです。パラメータの可読性は高くて良いのですが。

また、パイプラインも合わせてCloudFormationで作っているのですが、パイプラインの数も多くなりここも中々ツラくなってきているところです。CDK Pipelinesはパイプラインの整備や管理に大いに役立ちそうです。できるところから、CDKも試していきたいと思います。

IaCのテストにフォーカスしたセッションは過去に見たことがなく、悩んでいるところでもあったのでとても有益なセッションでした。インフラもテスト駆動で開発していきたいですね。

Azure AD と AWS SSOの連携

はじめに

AWSアカウントがたくさん増えて、アカウントごとにIAMユーザーがいて、それぞれにMFAを設定して、、もう大変！ となった経験はありますでしょうか。

私は今もそういった経験をしておりますが、そんなマルチアカウントのログインの助けになるのがAWS SSOです。 マイボス佐々木さんが構成の整理と説明を以下の記事でわかりやすくしてくれています。

blog.takuros.net

↑の記事でもおススメの構成となっている、IdP + AWS SSOのパターンを今回は試してみたいと思います。

IdPはAzure上でマネージドで作成できる、Azure Active Directoryを使用します。 AWSと同じくクラウド環境のため、画面上からポチポチするだけでADおよびユーザーが作成できるので検証に便利です。

それではやっていきましょう。

AWS SSOの設定

SSOはOrganizationsの組織情報を使用した機能となるため、Organizationsの親アカウントで設定する必要があります。

AWS SSO画面に遷移し、有効にします。

Organizationsの組織が作成されていない場合は、以下のとおり表示されます。 AWS組織の作成を押すことで、組織が自動作成されます。

組織の作成時、メールの検証が必要となるため、アカウントのメールアドレスに届いたメールを確認して青いボタンを押しておきます。

外部のAzureADをIDソースとして利用します。 IDソースを選択を押下して設定画面へすすみます。

IDソースの変更を押します。

メタデータファイルをダウンロードしておきます。

Azure ADの設定

新規テナント、ユーザーの作成

Azureのテナントとは不動産のテナントと同様で、ユーザーやグループ、オブジェクトなどをひとまとまりで管理できる部屋のようなものです。Azureアカウント作成時にデフォルトで1つのテナントがあるのですが、今回は新規でSSO用の専用テナントを作成します。

Azure Active Directoryの画面へ遷移し、テナントを作成をおします。

デフォルトのAzure ADでOK。

任意の組織名、ドメイン名を入力します。

確認して作成します。

テナントの作成が完了したら、作成したテナント上で、ログイン確認用のユーザーを作成しておきます。

（もともとのテナントがダークモードONだったので色が変わりました）

testという名前で作成しておきます。名と姓を入力しておかないとAWS側でエラーになるため注意です。

アプリケーションの作成

AWSへ連携するために、エンタープライズアプリケーションを作成します。

新しいアプリケーションを作成を選ぶと、以下の通り各種サービスが選択できます。 AWSが一番最初に大きく出てくるので押したくなりますが、今回はAWS SSOなので独自のアプリケーションを作成をおします。

名前は任意でOKです。今回はAWS SSOとして作成します。

作成後以下のような画面になるので、シングルサインオンの設定をおします。

SAMLを選択

さきほどAWS SSOの画面からダウンロードしたメタデータを使うので、メタデータファイルのアップロードを選択します。

アップロードすると右側に以下の画面が表示されます。そのまま保存を押せばOKです。

Testするのか表示されますが、AWS側の設定がまだ完了していないため、ここはいいえにします。

このあとブラウザのリロードを行うと、以下のようにSAML署名証明書にメタデータのダウンロードリンクが表示されるので、そこからダウンロードします。

AWS SSOの設定（つづき）

AWS側に戻ります。

IDプロバイダーのメタデータのところから、Azure側でダウンロードしたメタデータファイルをアップロードします。

ACCEPTと入力し、IDソースを変更します。

完了！

今回はADのユーザーが自動的にAWS側にも連携されるよう、自動プロビジョニングを有効化しておきます。

SCIMエンドポイントとアクセストークンの情報はメモしておきます。

Azure 側プロビジョニング設定

またAzureに戻ります（行ったり来たり・・）

さきほど作成したアプリケーションからプロビジョニングの設定をしていきます。

プロビジョニングモードを自動に変更して、さきほどメモしたURLとトークン情報を入力し、テスト接続を行います。無事接続できると右上に成功の旨が表示されます。

その後、左上の保存を押します。

一度保存すると下部のプロビジョニング状態を変更できるので、オンにして保存します。

ユーザー属性のマッピング情報を変更します。

「mobile」と「facsimileTelephoneNumber」を削除します。

「mailNickname」を「objectId」に変更します。2つの削除と1つの変更が終わったら左上の保存を押します。

エンタープライズアプリケーションのページに戻り、ユーザーを追加します。

先ほどADで作成したtestユーザーを追加して割り当てます。

※本来の運用を考えると、グループ単位で割り当てたほうが良いでしょう。今回は検証用途のためユーザー単独で割り当てます。

プロビジョニングの実行間隔は40分になっているため、手動で再開して追加したユーザーを反映させます。

しばらくするとプロビジョニングが完了してユーザー1と表示されます。

AWSのSSO画面にもユーザーが追加されています。

アクセス権限セット、対象AWSアカウントの決定

ログインするAWSアカウントのユーザーに付与する権限（IAMポリシー）を決定します。

アクセス権限セット

まずはアクセス権限セットの作成からです。

今回は検証用途のためAWS側で職務単位で用意されている職務機能ポリシーを使用します。

※本番運用時は、必要な権限を決めて最低限の権限となるように付与しましょう。

閲覧権限のみ与えるViewOnlyAccessを使用します。

タグは特に設定せず、内容確認して作成します。

できました。

対象AWSアカウントの選択と割り当て

次はログインするAWSアカウントを選んでいきます。

Organizations配下に2アカウントあるため2つ共選んでユーザーを割り当てます。

プロビジョニングされたTestUserを選択します。

先ほど作成したアクセス権限セットを作成して完了します。

完了！

ログイン確認

設定がすべて終わったので、SSOのTOPに表示されているデフォルトのポータルURLへアクセスしてログインしてみます。

作成したAzure ADのユーザー名、パスワードを入力します。

AWS Account(2)と表示されています！クリックすると一覧でアカウントが一覧で出るのでログインしたい方を選択します。

今回はマネジメントコンソールで入ります。CLI用のキーも表示できますね。

ログインできました！まっさらな状態のアカウントなのでリソースは特にない状態ですが・・。

検証は以上です。

CLIやMFAなどまだまだ試したいことはありますが、今回の記事はAzure ADでユーザーを作成してSSOと連携するところを主目的として書いていますので、ここまでとしておきます。

まとめ

ただ試してみたかっただけですｗ SSOが便利で重要なことは知っていたのですが、やはり自分で試してみないとわからないという主義なので、実際に触ってみました。 触ってみて改めてですが、以下のポイントが良いですね。

• ID/パスワードの管理がAWS外で一元管理できる。元々業務で使用しているIDがあればそれも流用できる
• アクセス権限セットを使用して、アカウント単位の権限ではなく、必要な権限セットを複数のアカウントに適用できる
• CLIもイケる

AWS SSOの管理がOrganizationsの親アカウント限定なので、これがOU単位であったり、もう少し細かい単位で制御できると最高かと思います。今後に期待です。

これから作ろうと思っている方何かの参考になれば幸いです。

re:Invent 2020 サービスアップデート 2週目（12/7～12/11）のまとめ

社内勉強会でしゃべったネタの一部なのですが、特に隠しておく情報でもないため、ブログに書いておこうと思います。 先週発表されてAWSのアップデートを、個人的にまとめて社内で紹介しました。 深さはあまりなく各発表の内容をざっくり書いています。

本日開催されたAWSさん公式のBlackBeltのほうが詳しい気がしますが、セルフメモ的な意味もこめて書いておきます・・

Compute

ECR cross region replication

コンテナイメージのリージョン間コピーが可能に。アカウント間コピーも可能

EC2に新たなネットワークメトリクス追加

新たに5個追加。帯域上限を超えたIN/OUTパケット数、コネクション上限を超えたパケット数、 DNSやメタデータなどのlinklocalへの上限を超えたパケット数、PPSの上限超えパケット数。

Network

VPC Reachability Analyzer

AWSサービス間のネットワーク経路を可視化できるサービス。画面上で通過するENIやSGが一目で見れるため、ネットワークが繋がらない場合に役立つ。1分析あたり$0.10

Developer tools

Amplify CLIがFargateへのコンテナデプロイへ対応

ソースコードを用意して、amplify init、configure、add、pushの数回のコマンドを実行するだけで、Fargateのサービスを公開できる。パイプラインも自動作成される

CodeGuru Profilerのメモリおよびヒープメモリ対応

CPU、レイテンシーベースだったのがメモリも対応。ヒープメモリも対象

Security

AWS Audit Manager

監査を簡略化するためのサービス。GDPR、HIPPA、PCI DSSなど主要なコンプライアンスに対応 AWSアカウント内のリソース状況を既存のサービスを使用して取得する。エビデンスを自動収集し、 コンプライアンス標準に合わせた言葉も使用される。監査レポートの出力も可能。マルチアカウントにも対応

Analytics

Amazon Redshift ML

SQLコマンドで学習モデルの作成、学習、デプロイが可能。 CREATE MODEL文でモデルが学習、デプロイされる。TARGETでラベルのカラムを指定する。 その後SELECT文で予測結果を取得可能。裏ではSageMaker（autopilotベース）が動き、アルゴリズムは自動選定

Amazon Redshift Automatic Table Optimization

クエリの状況を監視し、機械学習を使用してソートキーなどを自動選定、データの再配置も実施する

Amazon Redshift federated queryがRDS（MySQL）をサポート

PostgreSQLだけでなくMySQLも追加

Amazon Redshift native console integration with partners

パートナー企業とのやり取りがやりやすく

Amazon Redshift が JSON と semi-structured dataのサポート

半構造化データやJSONもOKになった

Amazon Redshift data sharing

Redshiftクラスター間でデータを共有するサービス

Amazon Redshift RA3.xlplus node

小さいノードができた。これまでは4xlと16xl

Amazon Neptune ML

グラフDBのNeptuneでもRedshift ML同様の仕組みで機械学習が使用可能に 不正検知やレコメンデーションなどのユースケースで使用可能

Amazon EMR Studio

EMR用のIDE。SageMakerでも使われているJupyter notebooksが使用されている。 処理コードの開発がやりやすくなる

Amazon EMR on Amazon EKS

EKS（Kubernetes）上でEMRのデータ処理を実行可能に

QuickSightがElasticsearchをサポート

データソースとしてElasticSearchの指定が可能に

ML/AI

Amazon HealthLake

多種多様な医療データをAWS上に集約し、機械学習を使用して標準化、分析が可能。HIPPAにも対応

Amazon Lookout for Metrics

CloudWatch Anomaly Detectionの他サービス対応版。数値データの異常なふるまいを機械学習を使用して検知 CW、S3、RDS、Redshiftに加え、外部のSaaSにも対応（Salesforce, Google Analyticsなど） SNS経由で通知

Amazon Forecast Weather Index

天気予報

Amazon SageMaker Edge Manager

エッジデバイス上にデプロイされた学習モデルを管理、監視するためのサービス

Amazon SageMaker Clarify

学習データの偏りを検知するサービス。 たとえば画像の年齢判定のモデルを学習する場合に、データが特定の年代に偏ってないかなど

Deep Profiling for Amazon SageMaker Debugger

昨年発表されたDebuggerの新機能。ハードウェアリソースの分析や処理の稼働状況を分析できる

Amazon SageMaker JumpStart

目的に合わせて、学習済みのさまざまな既存のモデルを選択してデプロイ可能 不正検知や数値予測、自然言語処理や画像認識などさまざまなモデルあり そのままデプロイもできるが、既存の学習モデルを*ファインチューニングして、自分のモデルも開発可能。 たとえば一般的な画像分類のモデルから商品分類のモデルを学習してデプロイすることが可能 ※「ファインチューニング」既存のモデル全体を再調整して新たなモデルを学習すること。転移学習は既存の出力に追加学習

Amazon Kendra incremental learning

検索結果に応じて、継続的に増分のデータを使用した学習が可能

Amazon Kendora のcustom synonymsサポート

ユーザ独自の特定の用語を登録可能

Amazon Kendra の Google Drive connector対応

Google Driveをデータソースとしてサポート

さいごに

一番アップデートの多かった1週目ではなく2週目ピンポイントのまとめとなりました。 先週1週間でどんな感じでアップデートがあったのか、全体感はみれるかなと思います。

MLキーノートがあったこともあり、ML/AI、Analytics系のアップデートが多かったですね。

re:Invent2020セッションレポート ：(EMB023) Amazon Aurora Serverless v2: Instant scaling for demanding workloads

概要

2020 re:Inventで新しく発表された、Amazon Aurora Serverless v2のセッションです。もともとAurora Serverlessは機能としてありましたが、今回パワーアップしてv2としてリリースされました。

セッション内容

Auroraの概要

通常の（サーバーレスじゃない）Auroraの概要です。ここらへんはBlackBeltや公式ドキュメントも（特に日本の方は）わかりやすいと思います。

AuroraはAWSがクラウド環境用に開発した独自のリレーショナルデータベースサービスで、MySQLとPostgreSQLに互換性があります。通常のRDSよりもクラウドに特化した機能が多く備わっています。独自となっていますが、接続するアプリケーションから見ると従来のMySQLやPostgreSQLと同様になりますので、特別アプリケーションの変更は不要です。

• コンピュート機能とストレージ機能は分離されていて、データは3AZに分散されている

• ストレージは分離されているため、Writer（書き込み）またはReader（読み込み）ノードにアタッチするという形でノードを生成
• Writerは1ノード、Reader（リードレプリカ）は最大15個作成可能です。指定のReaderでカスタムリードエンドポイントの作成も可能

• 「クラスター」という単位でAuroraを設計、構築していく
• アプリケーションの内容がデータベースのIOスループットやレイテンシの要件に影響する
• マルチAZ等可用性の設計も行う
• ストレージの拡張やフェイルオーバーやAWS側で自動実行される

• DBのキャパシティ管理は難しい
• ３つの例を紹介、スパイキー（たまに高い）、不規則（開発など）、一定の傾向があるもの
• ピーク時に合わせて用意すると料金が高くなる
• ピークよりも低く設定するとユーザー影響が出る
• 自前でモニター、キャパシティ管理は大変
• そこでAurora Serverless!!

Aurora Serverless v2

• キャパシティをオートスケールしてくれる Serveless v2
  • 素早くスケールするので急なアクセス増にも耐えられる
  • きめ細かく的確にキャパシティを設定してくれる
  • 通常のAuroraの機能もフルで使用できる。マルチAZやグローバルDBなど
  • 最大90%のコスト削減

• 読み書き（Read-Write）のスケーリング
  • 最初は特にノードはなく、アプリからアクセスがあると、Router fleetという部分がそれを処理し、Writerを起動する
  • 起動の単位はAurora Capacity Unit（ACU）と言う
  • アクセス数、クエリ数が多くなるとACUを自動で増やしていく
  • 最低キャパシティを指定して、常時稼働させておくことも可能。初回接続時のインパクトを抑える

• 読み込み（Read-Only）のスケーリング
  • Write同様にアクセスに応じて自動スケールする
  • 読み込み専用のアクセスに応じてスケール

• 通常のAuroraとMixも可能
• この例ではReaderのみServerless v2

デモ

※デモは動画のほうが見やすいと思います。気になる方は是非直接セッション動画をご覧ください

• CloudWatchメトリクスの画面。オンラインストアを例とし、青がオーダー数でオレンジがAuroraのキャパシティ
• スクリプト処理でSQLを継続実行
• スケールダウンはスケールアップよりも緩やかに行われる。バックグラウンドプロセスの動きも見ながら、影響がないように

セッションまとめ（re:Cap）

• サーバーレスなオートスケーリングAurora
• 本番環境もOK
• 数千トランザクション/秒にも耐えられる
• 必要なリソースだけ用意する、安い

感想

高機能すぎて、本当にここまでキレイに動いてくれるのかという感じですね。まだプレビュー段階ですので、今後に期待です。 このセッションを見る前は、通常のAuroraと同様に裏でノード（インスタンス）が稼働してそれをAWSが自動管理してくれるのかと思っていましたが、Lambdaのような小さなVMが稼働し、それをスケールアウト/インしてきめ細やかなキャパシティ管理を実現しているということでうね。驚きました。

RDSのノードタイプの決定や、そのサイズ、レプリカ個数の管理は難しい、というか構築したら基本はそのまま稼働させるという考えが多かったので、そこを動的に変えてくれるなら任せてみたいですね。使用前の金額見積が難しい部分はありますが、基本は安くなると思うので期待です。