Quantcast
Channel: 技術 –サーバーワークスエンジニアブログ
Viewing all 1210 articles
Browse latest View live

Security Hubのワークフローステータスで検出結果を運用しよう

$
0
0

2020年4月16日、Security Hubにワークフローステータスという新しい機能が追加されました。
この機能により、Security Hubの検出結果に対し、NEW(新規)NOTIFIED(通知済み)SUPPRESSED(抑制済み)RESOLVED(解決済み)の4つのステータスのいずれかを割り当てることが可能になりました。

なお、従来はアーカイブという機能がありましたが、現在ではコンソールから消えて、このワークフローステータスに変わりました。

各ステータスの意味は以下のとおりです。

ステータス 説明
NEW レビュー前の検出結果の初期状態。
NOTIFIED セキュリティの問題についてリソース所有者に通知したことを示します。
初回レビュー者がリソース所有者ではなく、リソース所有者の介入が必要な場合に使用されます。
RESOLVED この検出結果はレビューおよび修正され、現在は解決済みと見なされています。
SUPPRESSED 検出結果はレビューされず、対処されません。

Security Hubで何か問題を検出すると、それをコンソールで見ることができますが、放っておくと増えるだけです。
ワークフローステータスを使えば、それがどのような状態にあるのかを整理しやすくなります。

参考ページ

では、やってみましょう。

今回の例では、Inspectorでの2つの検出結果をSecurity Hubに取り込んだものを処理します。

何らかの処理が必要な検出結果への対応

On instance i-0813dde2de2ac645d, TCP port 80 which is associated with ‘HTTP’ is reachable from the internet

インターネットからEC2インスタンスのポート番号80にアクセス可能という検出結果です。
これは意図していなかったので、塞ぐ必要があるとします。
調査の結果、セキュリティグループに問題があるとわかり修正しました。

問題を解決したので、「解決済み」に変更します。

そうすると、デフォルトのフィルタ条件(ワークフローのステータス EQUALS NEW、NOTIFIED)から外れるので、表面上は見えなくなります。
もし後で確認したくなったら、フィルタ条件でワークフローのステータス RESOLVED を追加すれば見れます。

処理が不要な検出結果への対応

On instance i-0813dde2de2ac645d, TCP port 443 which is associated with ‘HTTPS’ is reachable from the internet

インターネットからEC2インスタンスのポート番号443にアクセス可能という検出結果です。
しかし、このEC2インスタンスはWebサーバであり、HTTPS(443)で公開するのは意図したものだったとします。
何も対処する必要はありません。

このEC2インスタンスへのHTTPS(443)は問題ないと確認とれたので、今後は検出されないように「抑制済み」に変更します。

これで再度、Inspectorで検査したとしても「抑制済み」に関しては検出されなくなります。
やっぱり検出されるようにしたいなと思ったら、「抑制済み」から別のステータスに変更すれば、その後は検出対象となります。

感想

ワークフローステータスが付いたことで、Security Hubの運用がやりやすくなる気がしました。
アーカイブだけではやりにくかったので、大助かりです。


わかりやすくてわかりにくい、Amazon Connectの利用料金のこと

$
0
0

Amazon Connect の利用料金はとてもシンプルです。
利用した分だけ課金されます。

シンプルなのですが、そんなにシンプルでもない。
そんな Amazon Connect の料金のことを今日は書きたいと思います。

以下の内容はわかりやすくするために「チャット」は除外して「電話」に絞ってご説明をします。

Amazon Connect 利用料金の基本

Amazon Connece の料金についてはAWSの情報を参照してください。
 

利用料金のポイント

上記が、ながーいページでわかりにくいのでポイントを説明します。
  1. 何秒電話を利用したか
  2. 電話番号をいくつもっていたか

の2要素が課金対象です。
 
どこのリージョンを使っているか
どの電話番号の種類なのか
どの国にかけているのか
などによって料金テーブルがあるので料金表が非常に長くなっています。

 

料金簡易試算ツール

多くの方は東京リージョンで日本国内での利用になるますよね。
この条件に限定した簡単な試算ツールをサーバーワークはご用意しています。
具体的に今のコール量でAmazon Connectを利用したらいくらになるの?がすぐにわかります。
お気軽にご活用ください。
 
Amazon Connect導入支援の中でもう少し細かな料金に関する試算もご対応させていただいてます。
具体的な案件があればご相談くださいませ。
 

こんなとき料金はどうやって計算されるの?

「通話時間」が利用料金に大きな影響があることはここまででご理解いただいたいと思います。
シンプルに受信・発信をした場合はよいのですが、電話をエスカレーションしたりすることもありますよね?
運用シーンごとに通話時間がどのように計算されるかを確認しましょう。

IVR(自動応答処理)を経由して受話した場合

「お電話ありがとうございます。サーバーワークスです」等のメッセージの読み上げや
「XXに関するお問い合わせは1番…」といった分岐を実装することがAmazon Connectでは可能です。
このような自動応答を経てオペレータに電話がつながった場合は
「オペレータとお客様が会話している時間」ではなく、「お客様が電話をかけてAmazon Connectにつながってから会話終了まで」料金が課金対象となります。
自動応答をしている間も料金が発生します。

他のオペレータに転送(とりつぎ)をした場合

エスカレーション等で他のオペレータやSVに転送する運用があるかと思います。
Amazon Connect のユーザー間で転送をした場合は受信通話もそのまま引き継がれます。

 

転送をして3者間で会話をした場合

Amazon Connect は通常の転送(とりつぎ)の他に3者で会話をすることもできます。
Amazon Connect 内部のユーザーであれば3名で会話をしても通話料金はかわりません。

外部の電話番号に転送をした場合

Amazon Connectは外部の電話番号、例えば以下のような電話に転送が可能です。

  • 外出中の担当営業携帯電話
  • 担当の営業店舗

この場合、

  • 受信通話料金=トータルの通話時間
  • 発信通話料金1=転送開始から転送終了までの時間
  • 発信通話料金2=転送受信から会話終了までの時間

が発生します。

デスクフォン転送を利用した場合

Amazon Connect は通常CCPといわれるソフトフォンを利用します。
ソフトフォンの利用ができない状況の場合に、デスクフォンに転送して利用することが可能です。
(本エントリーでは設定方法やメリットデメリットについては割愛します)

この場合の転送も発信扱いになるため発信通話料金が必要になります。

  • 受信通話料金=トータルの通話時間
  • 発信通話料金=転送受信から会話終了までの時間

が発生します。

 

デスクフォンで発信

デスクフォンを利用した場合の発信はざっくりダブルでアウトバウンド料金がかかります。
電話をかける操作と実際に通話する機器が違うので少しわかりにくいですね。
デスクフォンで発信はできなくはないけれど、シンプルにCCPを利用したいところです。

まとめ

課金計算単位については、Amazon Connect の一部料金が秒単位課金になりました!  のエントリーを参考にしてください。
2020年3月から秒課金に仕様が変わっています。
ちょっとわかりにくいのですが料金テーブルの単位は分で、通話時間の計算が秒単位になっています。

さて、Amazon Connect の課金範囲はわかりやすかったですか?わかりにくかったですか?
いろいろなケースで説明をすればするほど書いているわたしも混乱してきますが、まとめるとやっぱり「使った分だけお支払い」ですね。
わかりやすい!

AWS Snowball Edgeに新機能が多数追加されました!

$
0
0

こんにちは、技術1課の小倉です。
2020/4/16にアップデートがあり、AWS Snowball Edgeに新機能が多数追加されました!

以下が追加された機能です。

  • AWS Snowball Edge Storage Optimized now delivers 25% faster data transfer performance
    • ハードウエアが更新され、処理能力が2倍、データ転送速度が最大25%向上しました。性能が上がっても今までのデバイスと同じ料金で使用できます。
  • AWS Snowball now supports local AWS IAM
    • 今まではロック解除したあとは権限などはありませんでしたが、本アップデートによりユーザベースのIAMポリシーを使用して、AWS Snowball Edgeで実行されているサービス、リソースへのアクセス制御ができるようになりました。
  • Introducing AWS OpsHub for Snow Family, a graphical user interface to manage AWS Snowball devices
    • AWS OpsHubというSnowファミリー向けのデバイスが管理できるグラフィカルユーザインターフェースです。デバイスのロック解除とデバイスの構成、ドラッグアンドドロップでデータコピーなどができます。
    • ソフトウェアはこちらからダウンロードし、インストールして使います(2020/4/21現在、英語のサイトからのみダウンロードできます)。インストール後は言語を日本語に変更できます。以下は、インストール後にAWS OpsHubを起動した画面です。

  • AWS Snowball adds task automation with AWS Systems Manager
    • AWS Systems Managerを使用して、Snowballデバイス用のタスクを管理できるようになりました。AWS OpsHubでPython / PowerShellでスクリプトを記述することができます。またスクリプトにはデバイスでサポートされている操作を含められます。

詳細については以下のAWSブログに記載されています。

AWS Snowball Edge の更新 – さらに高速なハードウェア、OpsHub GUI、IAM、および AWS Systems Manager

AWS Snowファミリーとは

AWS Snowball(AWS Snowball Edge Storage Optimized, AWS Snowball Edge Compute Optimized), AWS Snowmobileのサービスがあります。これらのサービスはAWSから物理的なデバイスをデータセンターなどへ送り、データをデバイスにコピーし、AWSへ送り返すことでペタバイトやエクサバイト規模のデータをAWSへ短期間で移行することが可能です。

2018年のre:Inventで展示されていたAWS Snowballです(どういう状況かは覚えていないのですが、水に濡れた状態で展示されていました)。

AWS Snowball Edgeのデータ移行手順が以下のブログにまとまっています。
Snowball Edgeを利用したAWSへのデータ移行 -2019夏-

AWS Snowmobileは以下のブログにまとまっていますが、巨大なトラックです。
【re:Invent 2016 発表】【速報】エクサバイト級のデータも数週間でAWSへ移行できるAWS Snowmobileが発表されました!

以下、AWSの公式サイトのリンクです。

Snowファミリーの料金です。

まとめ

AWS Snowball Edgeで多数のアップデートがありました。大容量のデータをデータセンターなどからAWSに移行するときにはSnowファミリーを活用することで短期間で移行できますので、大容量を移行の際はネットワーク経由ではなく、Snowファミリーを活用してみてはいかがでしょうか。

また、本ブログの内容は2020/4/22(水) 12:00よりYouTube Liveで配信される「30分でわかる AWS UPDATE!」でも取り上げる予定ですので、ぜひご覧ください!
もしリアルタイムで見逃しても、アーカイブ動画から内容を確認できます。

『テスト駆動開発』をPythonで写経するにあたって 演算子のオーバーロードとハッシュテーブル について調べた

$
0
0

こんにちは。
完全リモートワークもそろそろ3ヶ月目に入って、運動不足が深刻になってきた丸山です。
今回は超有名な技術書『テスト駆動開発』をPythonで写経しながら学んでいく途中でわからなかったこと、調べたことなどを記事にまとめてみました。
知識としては基本的な内容かもしれませんが、私と同じように『テスト駆動開発』を読んでいてピンとこなかった方の助けになれたら幸いです。

eqメソッドを再定義する

書籍では序盤にMoneyを値オブジェクトとして表現する方法が登場します。
Moneyを値オブジェクトとして扱うにあたって、例えば以下のようなテストを通す必要があります。

def test_equality_true_dollar():
      """
    5ドルと5ドルは等しいことを確認する
    """
    assert Money.dollar(5) == Money.dollar(5)

ところが、単純に以下のような実装を行なってもテストは通りません。

class Money:
    def __init__(self, amount, currency):
        self.amount = amount
        self.currency = currency

    @classmethod
    def dollar(klass, amount):
        return Money(amount, "USD")

assert Money.dollar(5) == Money.dollar(5)
# AssertionError

pythonの == 演算子はデフォルトではオブジェクトIDを比較するため、値が同じでもオブジェクトIDが違えばFalse返ってしまいます。
そこで、値が同じであれば== でTrueを返すように、__eq__()メソッドを再定義します。(書籍のjavaのコードではequalsメソッドを定義している部分に対応します。)

__eq__()== 演算子が使用された際に、暗黙的に対象のオブジェクトに実行されるメソッドで、これを再定義することで==演算子の動作も再定義できます。

ここでは、amountcurrencyが同じならTrueを返すように実装すると、別のオブジェクトでも値が同じなら同じものとして扱えるようになります。

def __eq__(self, money):
    return self.currency == money.currency and self.amount == money.amount

その他の特殊メソッド

書籍では10章(68ページ)で、エラーメッセージ読みやすくするためにtoStringメソッドを実装しています。
これもpythonでは特殊メソッドにあたり、同じことを実現するためには__str___()メソッドを実装します。

def __str__(self):
        return f"{self.amount} {self.currency}"

__str__()print()関数を実行する際にも対象のオブジェクトに自動的に実行されて出力されます。標準では<__main__.Money object at 0x10c3a16d0>のように出力されてしまうますが、上記のように__str__()を再定義することで、実行時のオブジェクトの状態を把握しやすくなります。

# __str__()を実装しない場合
print(Money.dollar(5))
# &lt;__main__.Money object at 0x10c3a16d0&gt;

# __str__()を実装した場合
print(Money.dollar(5))
# 5 USD

独自オブジェクトを辞書型のキーにするには

また、書籍では14章(106ページ)でPairという通貨のペアを値オブジェクトとして定義し、ratesという通過ペア: 取引レートを表す辞書型のキーとして使う場面があります。
ここでjavaでは、equalsメソッドとhashメソッドを定義していますが、pythonでは__eq__()メソッドと__hash__()メソッドになります。

class Pair:
    def __init__(self, source, to):
        self.source = source
        self.to = to

    def __eq__(self, pair):
        return self.source == pair.source and self.to == pair.to

    def __hash__(self):
        return hash(self.to + self.source)

usd_jpy = Pair("USD", "JPY")
rates = {}

rates[usd_jpy] = 1

assert rates[usd_jpy] == 1
# sourceとtoが同じであれば同じものとして扱いたいので、当然Trueであってほしい
assert rates[usd_jpy] == rates[Pair("USD", "JPY")]
# __hash__メソッドがない場合、TypeError: unhashable type: 'Pair'

独自のオブジェクトを辞書型のキーとして利用するためには、__eq__()だけでなく__hash__()メソッドが定義されている必要があります。

hashメソッドの役割とは…?

ひとまずこれで、独自オブジェクトを辞書型のキーとして使うという目的は達成できましたが、なぜhashメソッドを定義することで、辞書型のキーとして使えるようになるのかがわかりませんでした。
そこで調べてみたところ、pyhton(や他の多くの言語)の辞書型(ハッシュテーブル)の実装に関わった理由であることがわかりました。

まず辞書型がそれぞれの辞書を配列に格納するような形で保管されていると仮定して考えてみます。
この場合、"John"がキーになっている項目を探して取り出すためには、配列を1から順に確認していく必要があります。例になっている辞書型は4つしか項目がありませんが、項目が増えれば増えるほど、項目を探すための計算量が大きくなってしまいます。

-+-------------------+
0|{"Tarou": "male"}  |
-+-------------------+
1|{"John": "male"}   |
-+-------------------+
2|{"Chika": "female"}|
-+-------------------+
3|{"Jane": "female"} |
-+-------------------+

そこで、計算量を減らすためのアイデアを導入します。
辞書に項目を追加する際に、格納する位置をキーをハッシュ関数を利用して計算した値を利用して決定することにします。
(ここでは仮に以下のような結果になったと想定します。キー→格納位置 “Tarou”→0, “John”→1, “Jane”→3, “Chica”→”5”, “Yuta”→7)

-+-------------------+
0|{"Tarou": "male"}  |
-+-------------------+
1|{"John": "male"}   |
-+-------------------+
2|                   |
-+-------------------+
3| {"Jane": "female"}|
-+-------------------+
4|                   |
-+-------------------+
5|{"Chika": "female"}|
-+-------------------+
6|                   |
-+-------------------+
7|{"Yuta": "male"}   |
-+-------------------+

人間が見ると穴ぼこだらけで不自然なテーブルに見えますが、プログラム上では扱いやすい形になっています。
というのは、例えば”Yuta”がキーになっている項目を取得したい場合、再度ハッシュ関数を利用して格納されている位置を計算すれば、取得した格納位置に直接アクセスすることができるようになるためです。

格納位置を計算   "Yuta" → 7 


                -+-------------------+
直接アクセス→    7|{"Yuta": "male"}   |
                -+-------------------+

この方法なら、項目数が1つでも、10000あっても、同じ計算量で項目を探すことができるため、計算量の節約になるのです。
このようなデータ構造をハッシュテーブルと呼ぶようです。

PythonのHash()関数

Pythonの話に戻ると、辞書型のキーからハッシュ値を計算する際、自動的にhash(キーオブジェクト)が実行されます。
hash()は暗黙的に対象のオブジェクトの__hash__()メソッドを実行します。
そのため、__hash__() が実装されていないオブジェクトは辞書型のキーとして扱うことができないのです。
また、__eq__で等しいと判定されるようなオブジェクトの場合、__hash__メソッドの結果も同じになるように実装しないといけません。

値オブジェクトはdataclassを使った方が良さそう

これまで演算子のオーバーライドについて色々と説明してきましたが、Python 3.7から導入されたdataclassesを利用すると、__eq__, __hash__などの再定義を自動的に行ってくれるようです。

from dataclasses import dataclass

@dataclass(frozen=True)
class Money:
    amount: int = 0 # インスタンス変数の型とデフォルト値を設定
    currency: str = "JPY"


a = Money(amount=1)
b = Money(amount=1)

# __eq__()を再定義しなくても、==で比較可能になっている
assert a == b

使い方は上記のように@dataclassデコレータをclass定義の際に利用します。
dataclassを利用すると、自分で__eq__を実装しなくても、インスタンスヘンスの値(今回の場合amountとcurrency)が同じなら同じものとして判断されるようです。

__hash__, __str__に関しても同様で、自動的に実装されるようです。

@dataclass(frozen=True)
class Pair:
    source: str
    to: str

a = Pair("JPY", "USD")
b = Pair("JPY", "USD")

assert a == b

pair_dict = {}
pair_dict[a] = 1
assert pair_dict[b] == 1 
# 同じ値のオブジェクトなら、同じ辞書のキーとして使える

print(a)
# Pair(source='JPY', to='USD') 
# __str__()を再定義しなくても綺麗に出力してくれる

また、クラス定義時に@dataclass(frozen=true)と宣言することで、オブジェクトをイミュータブルにすることができます。
値オブジェクトとして使う場合はイミュータブルにしたい場合がほとんどだと思うのでとりあえずこれを使っておけば良さそうですね。

Organization内のAWS ConfigをCloudFormation StackSetsで一気に設定する

$
0
0

最近は複数のAWSアカウント利用が増えてきました。
AWS Configのようなサービスを有効化する場合、「リージョン数 × アカウント数」の設定が必要になります。
CloudFormationを使ったとしても、これだけの作業をするのは一苦労です。
そこでCloudFormation StackSetsを利用し、複数のアカウント・リージョンに対して一気に設定することにしました。

要件

  • 利用しているアカウント・リージョンが多くても手間をかけずに設定したい
  • AWS Configのログ(設定スナップショット、履歴)を1つのS3バケットに集約したい
  • OrganizationにAWSアカウントを追加した場合も自動的に設定されるようにしたい

前提

  • AWS Organizationsで「すべての機能」が有効化されている

全体的な方針

  • AWS Organizationsに統合されたCloudFormation StackSetsを使う

余談:アグリゲータについて

AWS Configにはアグリゲータという機能があります。
マルチアカウントマルチリージョンのデータ集約と説明されているので、「これを使えば解決?」と思うのですが、実際は上記要件のいずれも解決してくれませんでした。
単一のAWS Configのコンソール画面で、全環境のリソースを検索したりできるので、これはこれで有用なものです。
しかし、AWS Configの有効化、ログファイルのS3バケットへのエクスポート、などはアグリゲータでは設定できません。

手順

1. S3バケットの作成

ログ保存用のS3バケットを作成するために、任意のアカウントの任意のリージョンでCloudFormationを実行します。
これはStackSetsではなく、普通のCloudFormation実行です。

AWSTemplateFormatVersion: 2010-09-09
Description: Create S3 bucket for AWS Config

Parameters:
  ConfigBucket:
    Type: String
  OrgID:
    Type: String

Resources:
  S3Bucket:
      Type: "AWS::S3::Bucket"
      Properties:
        BucketName: !Ref ConfigBucket
        PublicAccessBlockConfiguration:
          BlockPublicAcls: True
          BlockPublicPolicy: True
          IgnorePublicAcls: True
          RestrictPublicBuckets: True

  S3Policy:
      Type: "AWS::S3::BucketPolicy"
      Properties:
        Bucket:
          Ref: "S3Bucket"
        PolicyDocument:
          Version: 2012-10-17
          Statement:
            - Sid: "AWSConfigPrincipalCheck"
              Action: ['*']
              Effect: "Deny"
              Resource:
              - !Join ['', ['arn:aws:s3:::', !Ref 'S3Bucket']]
              - !Join ['', ['arn:aws:s3:::', !Ref 'S3Bucket','/*']]
              NotPrincipal:
                Service: [config.amazonaws.com]
            - Sid: "AWSConfigBucketPermissionsCheck"
              Action: ['s3:GetBucketAcl']
              Effect: "Allow"
              Resource:
              - !Join ['', ['arn:aws:s3:::', !Ref 'S3Bucket']]
              Principal: "*"
              Condition:
                StringEquals:
                  aws:PrincipalOrgID: [ !Ref 'OrgID' ]
            - Sid: "AWSConfigBucketExistenceCheck"
              Action: ['s3:ListBucket']
              Effect: "Allow"
              Resource:
              - !Join ['', ['arn:aws:s3:::', !Ref 'S3Bucket']]
              Principal: "*"
              Condition:
                StringEquals:
                  aws:PrincipalOrgID: [ !Ref 'OrgID' ]
            - Sid: "AWSConfigBucketDelivery"
              Action: ['s3:PutObject']
              Effect: "Allow"
              Resource:
              - !Join ['', ['arn:aws:s3:::', !Ref 'S3Bucket','/AWSLogs/*']]
              Principal: "*"
              Condition:
                StringEquals:
                  s3:x-amz-acl: "bucket-owner-full-control"
                  aws:PrincipalOrgID: [ !Ref 'OrgID' ]

以下を考慮し、バケットポリシーを作成しました。

  • アカウントが増えてもメンテナンスフリーにするため、アカウントIDを埋め込まない
  • config.amazonaws.com以外のアクセスはDenyする
  • aws:PrincipalOrgIDでOrganization内からのみAllowする

2. AWS Configの作成

2-1.マスターアカウントでAWS OrganizationsのStackSetsの有効化

2-2.CloudFormation StackSetsを実行

マスターアカウントの任意のリージョンで実行します。

テンプレートファイルの内容は下記です。

AWSTemplateFormatVersion: 2010-09-09
Description: Enable AWS Config

Parameters:
  ConfigBucket:
    Type: String
  IncludeGlobalResourceTypeRegion:
    Type: String
    Default: ap-northeast-1

Conditions:
  IsIncludeGlobalResourceTypeRegion: !Equals [ !Ref IncludeGlobalResourceTypeRegion, !Ref "AWS::Region" ]

Resources:
  ConfigRecorderRole:
    Type: AWS::IAM::Role
    DeletionPolicy: Delete
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - config.amazonaws.com
            Action:
              - sts:AssumeRole
      Path: /
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSConfigRole
      RoleName: !Sub "config-role-${AWS::Region}"

  ConfigRecorder:
    Type: AWS::Config::ConfigurationRecorder
    DeletionPolicy: Delete
    Properties:
      Name: !Sub "configuration-recorder-${AWS::Region}"
      RoleARN: !GetAtt ConfigRecorderRole.Arn
      RecordingGroup:
        AllSupported: true
        IncludeGlobalResourceTypes: !If [IsIncludeGlobalResourceTypeRegion, true, false]
    DependsOn: ConfigRecorderRole

  ConfigDeliveryChannel:
    Type: AWS::Config::DeliveryChannel
    DeletionPolicy: Delete
    Properties:
      Name: !Sub "delivery-channel-${AWS::Region}"
      ConfigSnapshotDeliveryProperties:
        DeliveryFrequency: One_Hour
#      1hour   : One_Hour
#      3hours  : Three_Hours
#      6hours  : Six_Hours
#      12hours : Twelve_Hours
#      24hours : TwentyFour_Hours
      S3BucketName: !Ref ConfigBucket
    DependsOn: ConfigRecorderRole

パラメータにIncludeGlobalResourceTypeRegionというのを作成しました。
基本的に AWS Config はリージョンごとにリソースを記録します。
しかし、リージョン外のグローバルリソース(IAM等)というものもあります。
これを各リージョンで記録対象にすることも可能ですが、検索時などに重複してしまう可能性を避けるため、1つのリージョンを指定するようにしました。

「組織へのデプロイ」または「組織単位(OU)へのデプロイ」を選択します。
今回は「組織単位(OU)へのデプロイ」を選択したので、OU IDを追加で入力しました。

また、「自動デプロイ」もデフォルトで有効になっています。
アカウント追加時に自動的にデプロイされることになります。

今回は「すべてのリージョンを追加」を選択しました。
個別にリージョンを選択することも可能です。

実行開始すると、オペレーションステータスが RUNNIING になります。

スタックインスタンスのステータスが OUTDATED になっています。

1リージョンずつ実行され、徐々に CURRENT に変更していきます。

最終的には全てのスタックインスタンスが CURRENT になり、オペレーションステータスが SUCCEEDED になります。

余談:なぜ、IAM Roleをリージョンごとに作っているか

AWS Configに割り当てるIAM Roleは、全リージョンで共用できます。
しかし、今回はわざわざ複数作成しています。

ConfigurationRecorderを作成するには、IAM Roleを先に作成する必要があります。
CloudFormation StackSetsを実行すると、デプロイは1リージョンずつ実行されます。
したがって、最初のリージョンでIAM Role作成すればいいのですが、CloudFormationの仕様上、「IAM Roleが存在しなければ作成する」といった書き方はできません。

私が試した限りでは、デプロイ対象として全リージョンを指定すると、必ずus-east-1から実行されました。
しかし、必ずしも全リージョンにデプロイするとも限りません。

なお、IAM Roleだけ別スタックに切り出して事前に作成してもいいと思いますが、今回はスタックを増やしたくなかったのでこのような実装にしました。

感想

StackSetsが使えることで、CloudFormationの価値が上がり、学習するメリットも上がったと思いました。

GuardDutyのマルチアカウント設定がAWS Organizationsで少し簡単になりました

$
0
0

2020年4月21日のアップデートです。
Amazon GuardDuty simplifies multi-account threat detection with support for AWS Organizations

Amazon GuardDutyはAWS組織のサポートを追加して、組織内のすべての既存および将来のアカウントにわたる脅威の検出を簡素化します。今回のリリースにより、新規および既存のGuardDutyのお客様は、GuardDuty管理者として組織内の任意のアカウントを委任し、最大5,000のAWSアカウントのGuardDutyを管理できます。GuardDutyの既存のマルチアカウント機能を使用しているお客様は、既存のGuardDutyオペレーションを中断することなく、AWS組織がサポートするマルチアカウント管理に移行できます。AWS組織でGuardDutyを管理する場合、顧客はGuardDutyの脅威検出を組織に追加された新しいアカウントに自動的に適用できます。

今までもGuardDutyマスターアカウントというのがあり、そこで各アカウントのデータを集約することはできていました。
しかし、AWS Organizationsの組織構造とは関連していませんでした。

今回のアップデートで、AWS Organizationsの組織構造と統合がされました。
基本的にAWS Organizationsを使用している場合は、Organizationsマスターアカウントが最高権限を持ちます。
ただ、何でもかんでもOrganizationsマスターアカウントでやるようにはしたくありません。
おそらくそんな理由でGuardDutyに関する権限を切り離し、別アカウントへ委任できるようになったのだと思われます。

Managing GuardDuty Accounts with AWS Organizations を参考にし、実際にやってみました。

1.Organizationsマスターで、GuardDutyマスターを指定

Organizationsマスター > GuardDuty > 設定 > Organization用のGuardDuty管理者アカウント

Orgazanization内の任意のアカウントを、GuardDutyマスターアカウントに指定し、権限を移譲します。

2.GuardDutyマスターで、GuardDutyメンバーを有効化

GuardDutyマスター > GuardDuty > アカウント

GuardDutyマスター以外のOrganization内のアカウントが表示されます。
Enableを押すと確認メッセージが表示されます。

ステータスが有効に変更されました。
なお、自動有効化はONにチェックが入っているので、今後Organizationにアカウントが追加されれば自動で

GuardDutyマスター > GuardDuty > 結果
実際にGuardDutyメンバーアカウントの検出結果も表示されているのが確認できます。

気になった点

メンバーアカウントでGuardDutyの有効化は必要か?

メンバーアカウントでは、GuardDutyの設定を個別にする必要はありません。
まず、GuardDutyマスターに委任されると、そのアカウントでは自動的にGuardDutyが有効化されます。
GuardDutyマスターアカウントから他のアカウントを有効化すると、メンバーアカウントのGuardDutyが有効化されます。

リージョンごとに設定する必要があるか?

リージョンごとに設定する必要があります。

S3バケットへの結果のエクスポートはどうなるか?

各リージョンのGuardDutyマスターで設定します。
全リージョンで同じS3バケットを指定すれば、1箇所に集約可能です。
その場合はKMSキーも同じものを使います。
また、S3バケット/AWSLogs/アカウントID/GuardDuty/リージョン/YYYY/MM/DD/配下に保存されます。

ちなみにS3バケットへのエクスポートには、KMSキーポリシーやバケットポリシーの設定が必要になります。
設定が上手くいかない場合は、結果のエクスポートを確認しましょう。

OrganizationsのOUごとにGuardDuty設定できないか?

GuardDutyをOUごとに管理はできません。
Organization内でアカウントごとにGuardDutyマスターを変えたい場合は、自動有効化を停止し、個別に設定していく必要があります。
ただ、そのようなことが必要になるケースは少ない気はします。

AWS Chatbot が一般公開されました!

$
0
0

はじめに

こんにちは、技術一課の山中です。
惜春真っ只中です。

それはそうと、2020/04/22 に遂に AWS Chatbot が一般公開となりました!!!!

https://aws.amazon.com/about-aws/whats-new/2020/04/aws-chatbot-now-generally-available/

これよさそう!と思っては「まだベータ版か…」と何度夜な夜な枕を濡らしたことか…
というわけで、試しに AWS Chatbot を使って Slack 連携をしてみました。

AWS Chatbot とは

AWS Chatbot を利用するとサポートしている AWS サービスの通知を Amazon SNS 経由で Slack や Amazon Chime に簡単に通知することができます。
現在対応しているサービスは以下のとおりです。 (2020/04/27)

  • AWS Billing and Cost Management
  • AWS CloudFormation
  • Notifications for AWS Developer Tools
  • Amazon CloudWatch Alarms
  • Amazon CloudWatch Events
    • AWS Config
    • Amazon GuardDuty
    • AWS Health
    • AWS Security Hub
    • AWS Systems Manager

https://docs.aws.amazon.com/chatbot/latest/adminguide/related-services.html

また、 Slack や Amazon Chime から AWS Chatbot を経由してコマンドを実行することも可能です。

料金

AWS Chatbot は追加料金なしですぐにご利用いただけます。
発生する料金は AWS Chatbot と一緒に利用する AWS リソース (SNS トピックや CloudWatch アラーム) に対してのみです。

作ってみる

CloudWatch アラームを Slack に送ってみましょう。

Amazon SNS トピックの作成

あらかじめ、通知に使用する SNS トピックを 1 つ作っておきましょう。
今回は東京リージョンに chatbot という名前で作成しました。

Slack ワークスペースと AWS Chatbot の連携

AWS マネジメントコンソールから AWS Chatbot を選択します。管理とガバナンスの中にありますね。

チャットクライアントの設定画面がでてくるので、今回は Slack を選びましょう。
Betaの文字が確かになくなってますね。

Slack への権限リクエストを求める画面が出るので、 AWS Chatbot を利用したいワークスペースを選び許可します。

これで連携は完了しました。

AWS Chatbot の設定

引き続き設定をしていきます。

先ほどの画面から 新しいチャネルを設定 を選択します。

設定に名前をつけます。今回は test-configuration としました。
オプションで Amazon CloudWatch Logs にログも流せるみたいですねー。

続いて、どの Slack チャンネルに流すか設定します。
今回は times-yamanaka を選んでいます。

続いて、アクセス許可の設定です。
今回は AWS Chatbot から CloudWatch メトリクスにアクセスできればよいので、デフォルトのまま新しい IAM ロールを作成します。
AWS Chatbot から AWS Lambda を実行したい場合などは、ポリシーテンプレートから Lambda 呼び出しコマンドのアクセス許可 を選ぶ等、必要なポリシーを与えましょう。
必要なポリシーの詳細については以下に記載されています。

Running AWS CLI Commands from Slack Channels

最後に、あらかじめ作成しておいた SNS トピックを選択してください。

これで AWS Chatbot の設定は完了です。

チャットボットを Slack チャンネルに呼ぶ

AWS Chatbot の設定で選択したチャンネルに @aws を招待しておいてください。

CloudWatch アラートを設定

SNS トピックに通知するための CloudWatch アラートを設定しましょう。
今回は Amazon EC2 の画面から特定のインスタンスを選び、以下の条件で SNS トピックに通知されるように設定しました。

確認してみる

アラートを設定したインスタンスに接続し、 CPU 負荷をあげてみましょう!!

$ yes > /dev/null

しばらく経つと Slack に以下のメッセージが!!!

AWS Chatbot のメトリクスを見ても、イベントが一回起きたことを確認できました。

おわりに

AWS Chatbot を利用すると Slakc や Amazon Chime との連携がすぐにできますね!
今度は Slack から AWS Lambda 実行にチャレンジしてみようと思います。

また、本ブログの内容は2020/4/30(木) の YouTube Live でも話しますので、是非ご覧ください!!

参考

macOSのスリープ時に一時ファイルを削除しよう

$
0
0

サーバーワークスのBYOD制度

CI部の千葉です。
サーバーワークスではBYOD制度が普及していて、過半数の社員がPCやスマートフォンは個人所有のものを利用しています。
参照: サーバーワークスホームページ – はたらきかた

BYOD制度の注意点

BYOD制度の利用にあたり、いくつかの注意点があります。

  1. MDMソフトのインストール
  2. アンチウィルスソフトのインストール
  3. ローカルディスクの暗号化
  4. IDaaS(OneLogin)の利用
  5. OSの自動ロック

これらについては、ソフトウェアの設定といった仕組み側で解決できる課題なので初期セットアップさえしてしまえば、その後は気にすることはありません。

ローカルファイルの取り扱い

前記の注意点に加えて『ローカルにファイルを残さない』為の工夫が必要です。
サーバーワークスでは、ファイル共有に Box を使っているので BoxDrive を利用することでローカルにダウンロードすることなくBoxのファイルを利用することが可能です。

一方で、Box 以外で共有されたファイルの取り扱いについてはローカルにダウンロードして扱うことになります。(e.g. 顧客からBacklog / Slack / メール等で共有頂いたファイル)
これらについては、Boxにアップロードする等の処理がおわったらローカルからファイルを削除する。運用が必要です。
消し忘れがないように注意をしているのですが、やっぱり人間がやっていることなので忘れちゃうことってあるんです。

これって、仕組みで解決しちゃって良いモノなのかな?

ひとがやるから忘れるワケで、自動化しちゃえば良いんだな。と考えました。
とは言え、ファイルを自動的に強制削除するって、かなりの勇気がいりませんか?
それで改めて良く考えてみました。

ローカルのダウンロードフォルダの中身って、すべてが何処かからダウンロードしてきたファイルなので『必ず別の場所にオリジナルが存在するもの』なんです!(フォルダ名からして当然なんですが…)
もし作業途中のファイルを紛失してしまったとしても、何かしらのルートで再取得できるんだな。って分かると気がラクになりました。

取得元が思い出せないファイルについて考えてみましたが、そもそも取得元を思い出せないファイルがローカルに残っていたとしても、そんな恐ろしいファイルを使っちゃダメでしょ?

これで気持ちが強く持てました、自動的に強制削除やっちゃいましょう!

ここで活躍するのが sleepwatcher です。
macOS の Sleep / WakeUp をトリガーにスクリプトを仕込むことが可能なツールです。
これをつかって、MacBookを閉じた際にローカルのダウンロードフォルダの中身を削除しちゃいます。

1. インストール

HomeBrew コマンドからインストールします。

$ brew install sleepwatcher

2. 起動設定

インストール後は $ brew info sleepwatcher の内容に従って、設定していきます。

$ cp /usr/local/opt/sleepwatcher/de.bernhard-baehr.sleepwatcher-20compatibility-localuser.plist ~/Library/LaunchAgents/sleepwatcher.plis

手動起動する場合は $ brew services start sleepwatcher を実行してください。

3. スクリプトの作成

今回は Sleep 時の設定なので ~/.sleep ファイルを作成します。

$ touch ~/.sleep
$ chmod +x ~/.sleep

このスクリプトでは『土日』もしくは『19時以降』にスリープした際にダウンロードフォルダを空にしています。
平日の業務時間内では、作業の途中で会議 / 休憩等でOSをスリープにすることがあるので反応しないようにしました。

#!/bin/bash

if [ 5 -gt `date +%u` -o 18 -lt `date +%H` ]; then
  # Remove Download files
  if [ -e ~/Downloads/* ]; then
    rm -rf ~/Downloads/*
  fi
fi

exit 0

まとめ

これで、ローカルファイルを消し忘れて、なんとなく後ろめたい気持ちになることが無くなりました。

よしっ!


S3にあるオブジェクトを異なるアカウントと共有する3つの方法 part1

$
0
0

こんにちは、CI部技術5課の村上です。

今回は、S3にあるオブジェクトを異なるアカウントと共有する方法を紹介します。3パターンほど検証したのですが、全部を紹介すると長くなってしまうので、この記事ではレプリケーションによって実現する方法を紹介します。

やりたいこと

図にすると、以下のような感じです。

前提として、アカウントAのIAMユーザーであるuser-aがS3にオブジェクトを保存しているとします。このオブジェクトをアカウントBのIAMユーザーであるuser-bが参照または取得する方法を3つ検証してみましたので、手順と検証してみた所感について紹介します。

検証した3つの方法

  1. バケットのレプリケーションで実現する
  2. バケットポリシーとIAMポリシーで実現する
  3. IAMロールで実現する(スイッチロール)

この記事では1の方法を紹介します。

1.バケットのレプリケーションで実現する

【手順】

①user-aがbucket-aのバージョニングを有効化する。

②user-bはレプリケーション先となるバケット(bucket-b)を作成し、バージョニングを有効化する。

③レプリケーションを実行する。

【特徴・所感】

  • 簡単な操作で実現可能
  • bucket-aにオブジェクトを保存すると、数秒程度でbucket-bへの同期が開始

設定手順

レプリケーションを実行するためには、前提としてバケットのバージョニングを有効化しておく必要があります。

バケットのプロパティの画面から「バージョニングの有効化」を選択します。この設定はレプリケーション元のbucket-aだけでなく、レプリケーション先のbucket-bでも必要です。忘れずに設定してください。

 

次にbucket-aのレプリケーションを実行します。管理タブのレプリケーションから「今すぐ始める」を選択します。

ソースの設定ですが、今回はbucket-aのすべてのコンテンツをレプリケートします。

次に送信先の設定で「別のアカウントのバケット」を選択し、アカウントBのアカウントIDとバケット名(bucket-b)を入力します。

次に、規則のオプションの構成です。ここではオブジェクトをレプリケートできるようIAMロールを設定します。

また、ここでbucket-bへ設定すべきバケットポリシーが参照できるので、後でこれをbucket-bに設定します。

最後に全体を確認し、「保存する」を選択します。

ちなみに、レプリケーション先であるbucket-bのバージョニングが有効化されていないと、ここで以下のようなエラーが表示されてしまいます。

アカウントBでは、bucket-bにバケットポリシーを設定する必要があるので、アクセス権限タブからバケットポリシーを選択し、先ほどコピーしたバケットポリシーをそのまま貼り付けます。

設定したバケットポリシーは以下のとおりです。principal要素のアカウントIDのみ変更していますので、ポリシー作成の際は適宜、設定してください。

{
    "Version": "2008-10-17",
    "Id": "S3-Console-Replication-Policy",
    "Statement": [
        {
            "Sid": "S3ReplicationPolicyStmt1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::アカウントID:root"
            },
            "Action": [
                "s3:GetBucketVersioning",
                "s3:PutBucketVersioning",
                "s3:ReplicateObject",
                "s3:ReplicateDelete"
            ],
            "Resource": [
                "arn:aws:s3:::bucket-b",
                "arn:aws:s3:::bucket-b/*"
            ]
        }
    ]
}

実行結果

以上の手順を終えると、bucket-bへのレプリケーションが実行されます。

 

まとめ

今回はレプリケーション機能を使った方法をご紹介しました。ポリシーを直接編集することもなく、簡単な操作で実現できるのがこの方法のメリットだと思います。

また別の記事では、今回と違った方法でS3にあるオブジェクトを共有する方法を紹介しますので、ぜひご覧ください。

Serverless Framework で Amplify Console を使えるプラグインで SPA(Vue.js) をデプロイしてみる –準備編

$
0
0

こんにちは、技術1課の加藤です。
みんな大好き Serverless Framework。 とてもよくできたサーバーレス環境のデプロイツールな訳ですが、SPAサイトを作りたい時、ホスティングをするのがなかなかやりづらくて困ったことがあります。

と思ったら、それを一発で解決してくれそうなプラグインを発見。
早速使ってみました。

※ 長くなりそうだったので準備編とデプロイ編で分けます。今回は Serverless Framework を使ったシンプルな API の作成と、API を叩くフロントエンドコードの作成のみ行います。

serverless-amplify-plugin

気になるプラグインはこちら。
@wizeline/serverless-amplify-plugin

A Serverless Framework plugin that enables you to easily host static websites with AWS Amplify Console including Continuous Deployment in as few as 3 lines of YAML.

とありますね 。ワクワクです。3行足すだけですってよ。

準備をする

では必要なリソースを準備していきます。

今回はシンプルな API を用意した上で、その API を叩く Vue.js の簡単なフロントエンドを作成します。
この環境を serverless のコマンド一発でデプロイしてやろうという寸法。やるぜ。

ツールインストール / ディレクトリ作成

今回、フロントエンド作成に Vue CLI、バックエンド構築に Serverless Framework を使いますので、これらをインストールします。

$ npm install -g @vue/cli serverless
$ vue --version
@vue/cli 4.x.x
$ serverless --version
Framework Core: 1.xx.0
...

また作業を行うためのディレクトリも作成しておきましょう。

$ mkdir serverless-amplify
$ cd serverless-amplify
$ pwd
/path/to/serverless-amplify

Simple API Endpoint の作成

今回は Serverless のページに掲載されていた Simple HTTP Endpoint というテンプレートを使います。

以下のコマンドでテンプレートからプロジェクトを生成します。

$ pwd
/path/to/serverless-amplify
$ serverless install -u https://github.com/serverless/examples/tree/master/aws-python-simple-http-endpoint -n serverless-amplify-backend
$ cd serverless-amplify-backend

出来上がったプロジェクト内でちょこっと修正が必要なので対応していきましょう。

まずPythonバージョンを3.7に変更、リージョンを東京リージョンにしておきます。(デフォルトのリージョンは us-east-1になります)
SPA からアクセスするので、 CORS の設定も ON にする必要があります。

service: serverless-amplify

frameworkVersion: ">=1.2.0 <2.0.0"

provider:
  name: aws
  runtime: python3.7  # 2.7 -> 3.7 に変更
  region: ap-northeast-1  # 一行追加

functions:
  currentTime:
    handler: handler.endpoint
    events:
      - http:
          path: ping
          method: get
          cors: true  # 一行追加

次に Lambda のコードを編集します。
こちらも CORS の対応のためです。

import json
import datetime


def endpoint(event, context):
    current_time = datetime.datetime.now().time()
    body = {
        "message": "Hello, the current time is " + str(current_time)
    }

    response = {
        "statusCode": 200,
        "body": json.dumps(body),
        # ここから追加
        "headers": {
          "Access-Control-Allow-Origin": "*"
        }
        # ここまで追加
    }

    return response

ではデプロイしてみましょう。

$ serverless deploy
...
Service Information
service: serverless-amplify-backend
stage: dev
region: ap-northeast-1
stack: serverless-amplify-backend-dev
resources: 11
api keys:
  None
endpoints:
  GET - https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/ping
functions:
  currentTime: serverless-amplify-backend-dev-currentTime
layers:
  None
Serverless: Run the "serverless" command to setup monitoring, troubleshooting and testing.

endpoints に書かれている URL にアクセスしてみます。
以下のような JSON が取得できれば完成です。

{"message": "Hello, the current time is 10:48:49.568250"}

Vue プロジェクトを作成

ではこの API を叩くフロントエンドのコードを作成します。
今回は Vue のプロジェクトを作ってやってみましょう。

バックエンドのディレクトリから抜けて serverless-amplify ディレクトリに戻り、以下を実行します。

$ pwd
/path/to/serverless-amplify
$ vue create serverless-amplify-frontend
? Please pick a preset: default (babel, eslint)  # default で Enter を押す
$ cd serverless-amplify-frontend

正しくサンプルプロジェクトが作成されたことを確認します。

$ npm run serve

localhost:8080 を開いて以下が表示されれば OK です。

フロントエンドのコードを修正

フロントから先ほど作成した API を叩くようにします。
今回は src/App.js を以下のように修正していきましょう。

<template>
  <div id="app">
    <img alt="Vue logo" src="./assets/logo.png">
    <!-- 下の行を修正 -->
    <HelloWorld v-bind:msg="message"/>
  </div>
</template>

<script>
import HelloWorld from './components/HelloWorld.vue'

export default {
  name: 'App',
  components: {
    HelloWorld
  },
  // ここから追加
  data: function () {
    return {
      message: 'Loading...'
    }
  },
  mounted: function () {
    fetch('https://nfz4hxrfp1.execute-api.ap-northeast-1.amazonaws.com/dev/ping')
    .then(function (res) {
      return res.json()
    })
    .then(function (json) {
      this.message = json.message
    }.bind(this))
    .catch(function (err) {
      console.error(err)
    })
  }
  // ここまで追加
}
</script>

<style>
#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;
}
</style>

これで API のレスポンス内容を表示するよう修正できました。
(詳しい修正内容の説明は今回端折ります。各自 Vue.js のドキュメントとか見つつ読み解いてあげてください。)

さて、今回はここまでとします。
次回、作成したコードを使って実際にデプロイを行ってみましょう。

S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ

$
0
0






s3privatecontents

S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ

S3 に置いたコンテンツをインターネットに公開する際に https 化や キャッシュ保持、WEBサーバ ( API Gateway など )とのURL共有 を考えると 自然と候補に上がるサービスは CloudFront です

S3 に置いたコンテンツを CloudFront を利用して インターネットに公開する際には 2つの方法があります

( A ) CloudFront のオリジンに Amazon S3 バケットを使用する方法

( B ) CloudFront のオリジンに Amazon S3 バケットの静的ウェブサイトホスティングエンドポイントを使用する方法

両者を構成する際の相違点を分かり易く整理してみることにしました

以下は本ブログに記載する内容です

①比較: ( A ) と ( B ) の比較

②手順: ( A ) と ( B ) についての具体的な作成手順

 

①比較:( A ) と ( B ) の比較

通信

( A ) CloudFront のオリジンに Amazon S3 バケットを使用する方法

参考:

CloudFront と Amazon S3 オリジンとの間の通信で HTTPS を必須にする

オリジンアクセスアイデンティティを使用して Amazon S3 コンテンツへのアクセスを制限する

 

( B ) CloudFront のオリジンに Amazon S3 バケットの静的ウェブサイトホスティングエンドポイントを使用する方法

参考:

Amazon S3 でホストされている静的ウェブサイトを提供するために CloudFront をどのように使用したらよいですか ?

 

機能

A B 機能
S3 バケットへのアクセスを CloudFront ディストリビューションからのみに制限
ウェブページリダイレクト ※但しリダイレクトルールは動きません
(静的WEBサイトホスティングの機能)
カスタムエラードキュメントの設定
(静的WEBサイトホスティングの機能)
CloudFront ディストリビューションから オリジン(S3)への通信 ※ を https にする ※インターネットを経由する通信

 

( A ) と ( B ) の比較まとめ

1.S3 に置いたコンテンツに CloudFront から ( インターネット経由で ) HTTP 通信することを許容できない場合は ( A ) を選ぶしかありません

2.1の制約は無く「ウェブページリダイレクト」や「カスタムエラードキュメントの設定」といった静的WEBサイトホスティングの機能を利用しようと考える場合には ( B ) を選ぶと良さそうです

 

②手順: ( A ) と ( B ) についての具体的な作成手順 (別ブログに切り出しました)

お手数ですが以下をご参照ください

S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ ( A )CloudFront のオリジンに Amazon S3 バケットを使用する方法

S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ ( B ) CloudFront のオリジンに Amazon S3 バケットの静的ウェブサイトホスティングエンドポイントを使用する方法

 
以上

S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ ( A )CloudFront のオリジンに Amazon S3 バケットを使用する方法

$
0
0






( A ) CloudFront のオリジンに Amazon S3 バケットを使用する方法

 

本記事の概要につきましては大変お手数ですが 以下のブログをご参照ください

S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ

 

( A ) CloudFront のオリジンに Amazon S3 バケットを使用する方法

本記事で作成するのは以下の構成です

公式ドキュメントはお手数ですが以下をご参照ください

オリジンとしての Amazon S3 バケットの使用

 

手順

S3にバケットを作成しコンテンツを配置

[サービス]→[S3] の順にクリックします

 
[バケットを作成]をクリックします

 
[バケット名]に任意の文字列を入れて [バケットの作成]をクリックします
※ デフォルトで [パブリックアクセスをすべてブロック] のバケットになります

 
バケットが出来ました

 
トップページになる s3contents.html を作成しアップロードします
 

 
[次へ]を押します
 

 
[次へ]を押します

 
[次へ]を押します

 
[アップロード]を押します

 
 
アップロードできました

 
アップロードしたファイルの [オブジェクト URL] をブラウザで 確認してみます

 
アクセス不可となります

 
作成したバケットの[バケットポリシー]に何も入っていないことを確認します

 
 

CloudFront の作成

[サービス]→[CloudFront] の順にクリックします

 
[Create Distribution] をクリックします

 
[Web]セクションにある [Get Started] をクリックします

 
作成した S3 バケット をプルダウンから選択して入れます (bucket-name.s3.region.amazonaws.com)

 
 
[Restrict Bucket Access] を [Yes] に変更します ★重要
 

 
[Origin Access Identity] を [Create a New Identity] に変更します ★重要
また [Grant Read Permissions on Bucket] を [Yes, Update Bucket Policy] に変更します ★重要
 

 
他は変更せずに [Create Distribution] をクリックします

 
 
作成中になります

 
 
 
作成したディストリビューションを選択して [General] タブ にある [Edit] をクリックします

 
 
 
[Default Root Object] に アップロードしたファイルのファイル名を入れ [Yes, Edit] をクリックします
※ CloudFront のURL xxxx.cloudfront.net にアクセスした際にトップページになります

 

Origin Access Identity (確認のみ)

CloudFrontの左ペインにある [Origin Access Identity] を確認すると作成した [Origin Access Identity] があります
 

 
S3 バケット のバケットポリシーを確認してみると 上の [Origin Access Identity] のみからアクセスを許可する バケットポリシーに更新しています

 

確認

CloudFront のURL xxxx.cloudfront.net にアクセスしたところ無事開くことができました
( CloudFrontのステータスが "deployed" になってから 15分ほど待ちました ご注意ください )
 

HTTPS 化

通信の HTTPS 化 については以下に手順があります
お手数ですがご参照ください

CloudFront と Amazon S3 オリジンとの間の通信で HTTPS を必須にする

 
以上

Service Catalogにアクションを追加する

$
0
0

2020年5月8日のアップデートで、AWS Service Catalogのサービスアクションでパラメーターサポートが利用可能になりました。
Parameter support is now available with service actions in AWS Service Catalog

しかし、Service Catalogのサービスアクションってそもそも何でしょうか。
そんなところから試してみました。

AWS Service Catalogとは

AWS Service Catalog では、AWS での使用が承認された IT サービスのカタログを作成および管理できます。この IT サービスには、仮想マシンイメージ、サーバー、ソフトウェア、データベースから包括的な多層アプリケーションアーキテクチャまで、あらゆるものが含まれます。AWS Service Catalog では、一般的にデプロイされた IT サービスを集中管理でき、一貫性のあるガバナンスを実現し、コンプライアンス要件を満たすと同時に、ユーザーは必要な承認済みの IT サービスのみをすばやくデプロイできます。

引用元:AWS Service Catalog

以前にService Catalogの入門編の記事(AWS Service Catalogで制御された自由を)を書きましたので、全く知らない方はまずみていただければと思います。
今回の内容は前回からの続きになります。

サービスアクションとは

前回はService Catalogを通して、EC2インスタンスを起動しました。
起動後のインスタンスに対してできることは、SSHなどでログインし操作することを除けば、更新、所有者の変更、削除のみです。
薄々気づいていましたが、なかなかにストイックな感じです。

サービスアクションを定義すれば、作成した製品に対してできるアクションを追加できます。
どのようなアクションを追加できるかといえば、Systems Manager オートメーションで利用できるドキュメントとなります。

再起動のサービスアクションを定義してみる

公式ページ(AWS Service Catalog のサービスアクション)では、再起動の例が記載されているので、その通りにやってみます。

ステップ 1: エンドユーザーのアクセス許可を設定する

エンドユーザーの属しているIAMグループに、下記のポリシーを追加します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1536341175150",
            "Action": [
                "servicecatalog:ListServiceActionsForProvisioningArtifact",
                "servicecatalog:ExecuteprovisionedProductServiceAction",
                "ssm:DescribeDocument",
                "ssm:GetAutomationExecution",
                "ssm:StartAutomationExecution",
                "ssm:StopAutomationExecution",
                "cloudformation:ListStackResources",
                "ec2:DescribeInstanceStatus",
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

ステップ 2: サービスアクションを作成する

Service Catalog > サービスのアクション > アクションの作成

SSMドキュメントの選択

定義済みのSSMドキュメントがズラッと並ぶので、再起動用のAWS-RestartEC2Instanceを選択します。

アクション詳細の仕様

アクション名はデフォルトのままにしました。
ちなみに日本語入力不可でした。(^[a-zA-Z0-9_-.]*のパターンが許可)

パラメータとターゲットの設定

このパラメータが今回アップデートされたところと思われます。
SSMドキュメントの種類によって、パラメータが異なっていたり、数が多くあったりします。

ただ、今回はパラメータはデフォルトのままにします。
再起動のアクションに必要なパラメータは、対象のインスタンスIDだけで問題ないはずです。

アクセス許可

アクセス許可もそのままにします。

作成できました

ステップ 3: サービスアクションを製品バージョンに関連付ける

作成したサービスアクションを選択し、アクションの関連付けを行います。

前回の記事で作成した開発用Ubuntuという製品の全バージョンに関連付けをします。

私の環境ではなぜかエラー表示が出ましたが、画面を更新してみると、問題なく関連付けに成功していました。

ステップ 4: エンドユーザーのエクスペリエンスをテストする

前回記事の手順でEC2インスタンスは作成済みとします。
アクションで、定義したAWS-RestartEC2Instanceが選択できるようになっています。

アクションの実行を選択します。

アクションが実行され、状況がIn progressとなります。

しばらく待つと、成功となりました。

おまけ

Service Catalogで実行されたアクションはの実行ログは、Systems Manager Automationでも確認できます。

感想

Service CatalogでSystems Manager オートメーションを実行できるとわかりました。
Systems Manager オートメーションに詳しくなれば、便利そうな気がします。

私は少しまだわかってないのは、エンドユーザーのIAMグループに割り当てた権限です。
公式ドキュメントの通りにポリシー設定すると、どのインスタンスに対しても再起動できてしまう気がしました。
ただ、IAMユーザーにアクセスキーを割り当てなければ、問題ないかもしれません。
機会があれば、調べてみたいと思います。

S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ ( B ) CloudFront のオリジンに Amazon S3 バケットの静的ウェブサイトホスティングエンドポイントを使用する方法

$
0
0






( B ) CloudFront のオリジンに Amazon S3 バケットの静的ウェブサイトホスティングエンドポイントを使用する方法

 

本記事の概要につきましては大変お手数ですが 以下のブログをご参照ください

S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ

 

( B ) CloudFront のオリジンに Amazon S3 バケットの静的ウェブサイトホスティングエンドポイントを使用する方法

本記事で作成するのは以下の構成です
 

公式ドキュメントはお手数ですが以下をご参照ください

オリジンのウェブサイトエンドポイントとして構成された Amazon S3 バケットの使用

Amazon S3 でホストされている静的ウェブサイトを提供するために CloudFront をどのように使用したらよいですか ?

 

手順

静的ウェブサイトホスティングエンドポイントを作成

公式ドキュメント:
Amazon S3 での静的ウェブサイトのホスティング

 
[サービス]→[S3] の順にクリックします

 
[バケットを作成]をクリックします

 
[バケット名]に任意の文字列を入れて [バケットの作成]をクリックします ※ デフォルトで [パブリックアクセスをすべてブロック] のバケットになります

 
バケットができました

 
トップページとなる s3contents.html を作成しアップロードします

 
[次へ]を押します

 
[次へ]を押します

 
[次へ]を押します

 
[アップロード]を押します

 
アップロードできました

アップロードしたファイルの [オブジェクト URL] をブラウザで 確認してみます

 
アクセス不可となります

 
作成したバケットの[バケットポリシー]に何も入っていないことを確認します

 
[プロパティ] タブの [Static website hosting] をクリックします

 

 

① [このバケットを使用してウェブサイトをホストする] にチェックします
② インデックスドキュメントに 先にアップロードした s3contents.html を入力します
③ エンドポイントをコピーしておきます (後で使います)
④ [保存] をクリックします

 
 
 
 

上でコピーしておいた エンドポイント (http://bucket-name.s3-website.Region.amazonaws.com) にブラウザからアクセスし 「403 Forbidden」となることを確認します ※ バケットの「ブロックパブリックアクセス」が有効になっており パブリックアクセスの許可設定についてもしていないため接続不可となります

[アクセス権]タブ に移動し[ブロックパブリックアクセス]枠内の[編集]をクリックします

 
[パブリックアクセスをすべてブロック]のチェックを外します

 
[保存] をクリックします

フィールドに 「確認」と入力し [確認] ボタンを押します

 
 
「パブリックアクセス設定が正常に更新されました」と出ました

 

[バケットポリシー]を編集します
特定の HTTP Referer へのアクセスの制限
を参考にバケットポリシーを記載し [保存] をクリックします (リファラーの値は任意のバイト数の任意の文字列を入れています)

{
    "Version": "2012-10-17",
    "Id": "http referer policy example",
    "Statement": [
        {
            "Sid": "Allow get requests originating from www.example.com and example.com.",
            "Effect": "Allow",
            "Principal": "",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::バケット名/",
            "Condition": {
                "StringLike": {
                    "aws:Referer": "リファラーの値"
                }
            }
        }
    ]
}

 
 
「このバケットにはパブリックアクセス権限があります」と表示され [パブリック] 印が表示されるようになりました

 
 

静的ウェブサイトホスティングのエンドポイント(http://bucket-name.s3-website.Region.amazonaws.com) にアクセスし コンテンツを表示できないことを確認します ※リファラーが一致しないためバケットポリシーで拒否されます

 
 
また s3contents.html の[オブジェクト URL] をブラウザで 確認してみます

オブジェクトURLでもファイルを表示できないことを確認します ※リファラーが一致しないためバケットポリシーで拒否されます

 
 
 

CloudFrontを作成

公式ドキュメント:
オリジンのウェブサイトエンドポイントとして構成された Amazon S3 バケットの使用

 
[サービス]→[CloudFront] の順にクリックします

 
[Create Distribution] をクリックします

 
[Web]セクションにある [Get Started] をクリックします

 

[Origin Domain Name]に静的ウェブサイトホスティングのエンドポイント(http://bucket-name.s3-website.Region.amazonaws.com)を入れ 他の設定はそのままにして [ Create Distribution]をクリックします

 
 
数十分するとデプロイが完了します ブラウザで CloudFront の URL ( xxxx.cloudfront.net ) を開き ファイルを表示できないことを確認します ※リファラーが一致しないためバケットポリシーで拒否されます

 
 
作成したディストリビューションの [Origins and Origin Groups] タブを開き [Edit] をクリックします

 
[Origin Custom Headers] の [Header Name]に「Referer」を入れ [Value] に バケットポリシーに設定した リファラーの値を入れ [Yes, Edit]をクリックします

 
CloudFrontのステータスが 「In Progress」になり その後に 「Deployed」になったことを確認します

 
CloudFront の現在のキャッシュクリアをするため [Invalidations] タブで [Create Invalidation] をクリックします [Object Paths] に「*」を入れ [Invalidate] をクリックします
 

 
 
Invalidation の [Status] が 「Completed」になりましたら ブラウザで CloudFront の URL を開き ファイルを表示できることを確認します ※ CloudFront で付与したリファラーが バケットポリシーに設定したものと一致しました
 

 

HTTPS化

CloudFront の [Behavior] にある [Viewer Protocol Policy]を編集することで ユーザーからCloudFrontへのアクセスをHTTPS化可能です(各 behavior に設定) ただし CloudFront からバックエンド (オリジン) の静的ウェブサイトホスティングのエンドポイント(http://bucket-name.s3-website.Region.amazonaws.com)への通信は HTTP になります

 
 
 
 

静的ウェブサイトホスティングの機能を試してみる① カスタムエラードキュメントの設定

[エラードキュメント] に エラー時に表示する html を設定しておくことにより ウェブサイトでエラーが発生した際にリダイレクトしてくれます

参考:
(オプション) カスタムエラードキュメントの設定

 

 
試しに存在しないパス (/無いページ) にアクセスするとリダイレクトしてくれました ( error.html の中身が表示されました)

 
 

静的ウェブサイトホスティングの機能を試してみる② ウェブページリダイレクトの設定

ウェブページリダイレクトの設定をしてみます

参考:
ウェブページリダイレクトの設定

 
試しに CloudFront の URL (xxxx.cloudfront.net) にアクセスが来た際に aws.amazon.com にリダイレクトさせてみます ※ 本来は公開するコンテンツの場所が変わった場合に追跡できるように本機能があります

 
CloudFront の URL (xxxx.cloudfront.net) を入れてみます

→ リダイレクトできました!

 
 
続いて 高度な条件付きリダイレクトの設定 を設定してみます (結論:使えませんでした…)
images/ 配下へのリクエストをすべて folderdeleted.html というページにリダイレクトするように設定します


    
    
       images/
    
    
      folderdeleted.html
    
    

 
images/ 配下にある test.png をリクエストします

 
 

確かに folderdeleted.html にはリダイレクトしているものの ホストが CloudFront (xxxx.cloudfront.net) ではなく静的ウェブサイトホスティングのエンドポイント(http://bucket-name.s3-website.Region.amazonaws.com)になってしまいました ※ CloudFront 経由でないため リファラーが付与されずアクセス不可となりました

 
CloudFront を経由する通信経路のみ許可する場合は ウェブページリダイレクト機能は使えるものの 「高度な条件付きリダイレクトの設定」 はできないようです
 
〜おわり〜

CloudFront のオリジンへ直接アクセスさせない方法まとめ

$
0
0






CloudFront のオリジンへ直接アクセスさせない方法まとめ

CloudFront を利用する際に オリジンの Webサーバ に 「CloudFront を経由しないアクセスを許可したくない」という状況があるかと思います

「CloudFront を経由しないアクセスを許可したくない」を達成する方法として以下の2つを紹介します
① カスタムヘッダの追加による制御
② Origin Access Identityによる制御

① カスタムヘッダの追加による制御

CloudFront には カスタムヘッダーの追加 機能があり
CloudFront のオリジンへ直接アクセスさせないように制御できます

参考:オリジンリクエストへのカスタムヘッダーの追加

コンテンツへのアクセス制御
カスタムヘッダーを使用して、コンテンツへのアクセスを制御できます。CloudFront によって追加されたカスタムヘッダーが含まれている場合にのみリクエストに応答するようオリジンを設定することで、ユーザーが CloudFront をバイパスして、オリジンで直接コンテンツにアクセスすることを防ぐことができます。詳細については、「 カスタムオリジン上のファイルへのアクセス制限」を参照してください。

CloudFront のオリジンが API Gateway や ELB の場合

CloudFront のオリジンが API Gateway や ELB の場合には AWS WAF を利用可能なため
AWS WAF を利用して CloudFront が付与したカスタムヘッダの制御を行うことが出来ます

例えば CloudFront のオリジンが API Gateway の場合は以下のように構成します

例えば CloudFront のオリジンが ELB の場合は以下のように構成します

CloudFront のオリジンが EC2 や コンテナ の場合

Webサーバの機能を利用してヘッダの制御を行います
Webサーバを提供するソフトウェア内の設定となるため方法は割愛します

CloudFront のオリジンが S3の静的ウェブサイトホスティングである場合

CloudFront のオリジンが S3の静的ウェブサイトホスティングである場合は Referer ヘッダを利用します
Referer ヘッダを S3のバケットポリシーで制御可能です

詳細はお手数ですが以下のブログ記事をご参照ください
S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ

追加できないカスタムヘッダ

追加出来ないカスタムヘッダは以下のため避けてください

オリジンに送信されるリクエストに以下のヘッダーを追加するように CloudFront を設定することはできません。

  • Cache-Control
  • Connection
  • Content-Length
  • Cookie
  • Host
  • If-Match
  • If-Modified-Since
  • If-None-Match
  • If-Range
  • If-Unmodified-Since
  • Max-Forwards
  • Pragma
  • Proxy-Authorization
  • Proxy-Connection
  • Range
  • Request-Range
  • TE
  • Trailer
  • Transfer-Encoding
  • Upgrade
  • Via
  • X-Amz- で始まるヘッダー
  • X-Edge- で始まるヘッダー
  • X-Real-Ip

②Origin Access Identityによる制御

CloudFront のオリジンが S3バケット (静的ウェブサイトホスティングではない )

CloudFront のオリジンが S3バケット (静的ウェブサイトホスティングでは無い場合 ) は Origin Access Identity を利用します

詳細はお手数ですが以下のブログ記事をご参照ください
S3 に置いたコンテンツを CloudFront を利用 してインターネットに公開する方法まとめ

以上



CloudTrail のログを Lambda から Athena 使って解析してみる

$
0
0

こんにちは。ポインコと暮らしている高橋です。
こどもの日は兄がAmazonで購入した室内用こいのぼりを揚げてくれました。

AthenaにCloudTrailのログを取り込む、というのは以前当社blogで紹介済みでした。
紹介時の2016年12月時点では、クエリを実行してCloudTrailのログを取り込んでいましたが、2020年5月現在では、簡単にCloudTrailのログを取り込めるようになっています。

Amazon Athena に CloudTrailのログを取り込んでみた

ということで、今回はCloudTrailのログをAthenaに取り込んで、最終的にはLambda (Python) からクエリを実行してみます。

AWS CloudTrail とは

CloudTrailとは、AWSアカウント内のアクティビティログ (マネコンの操作、SDK、CLIの操作など) を記録、閲覧することができるサービスです。

CloudTrailの基本

AWSの操作履歴を記録するCloudTrailを試してみた

Amazon Athena とは

Athenaとは、S3のデータを使ってテーブル定義をおこない、Presto (SQLクエリエンジン) ベースのSQLでデータ分析ができるサービスです。
読み方はAthena (アテナ) です。アテナというとギリシャ神話の女神ですが、何故アテナなのかはちょっと良く分からないですね。。
サーバーレスなので、SQLクエリに対して課金されます。2020年5月現在、東京リージョンではスキャンデータ1TBあたり5.00USDです。100MBだと0.0005USD ≠ 0.05円くらいですね。かなりお安いと思います。
また、Glue、Lambda、QuickSightなどと連携することが可能です。

CloudTrail のログを Athena に取り込む

それでは、まずはCloudTrailのログをAthenaに取り込んでみましょう。
マネジメントコンソールでCloudTrailを開き、左ペインのイベント履歴から「Amazon Athena で高度なクエリを実行します」をクリックします。

すると以下のようにテーブル作成のポップアップが表示されます。

先ほど「以前はクエリを実行してAthenaに取り込む」と説明しましたが、これがまさにそのクエリなんですね。自動で生成して実行してくれるというわけです。

CREATE EXTERNAL TABLE cloudtrail_logs_syoseteki_test_desuyo (
    eventVersion STRING,
    userIdentity STRUCT<
        type: STRING,
        principalId: STRING,
        arn: STRING,
        accountId: STRING,
        invokedBy: STRING,
        accessKeyId: STRING,
        userName: STRING,
        sessionContext: STRUCT<
            attributes: STRUCT<
                mfaAuthenticated: STRING,
                creationDate: STRING>,
            sessionIssuer: STRUCT<
                type: STRING,
                principalId: STRING,
                arn: STRING,
                accountId: STRING,
                userName: STRING>>>,
    eventTime STRING,
    eventSource STRING,
    eventName STRING,
    awsRegion STRING,
    sourceIpAddress STRING,
    userAgent STRING,
    errorCode STRING,
    errorMessage STRING,
    requestParameters STRING,
    responseElements STRING,
    additionalEventData STRING,
    requestId STRING,
    eventId STRING,
    resources ARRAY<STRUCT<
        arn: STRING,
        accountId: STRING,
        type: STRING>>,
    eventType STRING,
    apiVersion STRING,
    readOnly STRING,
    recipientAccountId STRING,
    serviceEventDetails STRING,
    sharedEventID STRING,
    vpcEndpointId STRING
)
COMMENT 'CloudTrail table for syoseteki-test-desuyo bucket'
ROW FORMAT SERDE 'com.amazon.emr.hive.serde.CloudTrailSerde'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://syoseteki-test-desuyo/AWSLogs/xxxxxxxxxxxx/CloudTrail/'
TBLPROPERTIES ('classification'='cloudtrail');

AWSアカウントIDは加工していますが、それ以外は実際に生成されたクエリそのままです。

CREATE EXTERNAL TABLE
指定した名前とパラメータでテーブルを作成します。各パラメータの詳細はドキュメントを参照してください。
CREATE TABLE

CREATE EXTERNAL TABLE~( )内の各項目は、作成する各列の名前とデータ型で、CloudTrailのレコードです。実際のデータ項目ですね。
CloudTrail レコードの内容

無事作成が完了すると、以下のように表示されるはずです。データベースは指定していないので、defaultに作成されるようです。
既に同じテーブルがあるとエラーになります。上書きされない点に注意です。

Athena を使ってみる

テーブルが作成されたので、Athenaのマネジメントコンソール画面で確認します。
以下の通りテーブルが作成されています。ここで、テーブルをプレビューしてみます。

プレビューすると、「SELECT * FROM “default”.”cloudtrail_logs_syoseteki_test_desuyo” limit 10」というクエリが実行されます。テーブルのレコードを10件表示するクエリです。
(出力先のS3バケットが指定されていない場合、エラーになります。右上の設定から出力先を指定してください)

あとは、自分が解析したいことをクエリで実行するのみです。サポートされているSQLについては、ドキュメントを参照してください。
Amazon Athena の SQL リファレンス

今回は、3月~4月にAWSアカウントIDxxxxxxxxxxxx な人がいつスイッチロールしたかを調べてみます。こんなクエリにしました。

SELECT eventtime, responseelements, json_extract(additionalEventData, '$.SwitchFrom') AS SwitchRole
FROM "default"."cloudtrail_logs_syoseteki_test_desuyo"
WHERE eventname='SwitchRole' and
eventtime>='2020-03-01T00:00:00Z' and
eventtime<'2020-04-30T00:00:00Z' and
REGEXP_LIKE(additionalEventData, '.*arn:aws:iam::xxxxxxxxxxxx.*')

実行結果を見ると、4月17日にスイッチロールしていることが分かりました。
(スキャンしたデータは約900MBなので、これで約0.45円です)

また、クエリ実行結果はS3に保存されます。保存先を指定することも可能です。
クエリ結果、出力ファイル、クエリ履歴の使用

こんな感じでCSV形式で保存されています。

Lambda から Athena のクエリを実行してみる

最後に、Lambdaから先ほどのクエリを実行してみます。
事前準備として、AthenaとS3の権限をアタッチしたIAMロールを使用するようにしておきます。

今回はPython (boto3) を使用します。DB名、実行結果の出力先も指定することができます。
Athena (Boto 3 Documentation)

import boto3

def lambda_handler(event, context):

    query =  "SELECT from_iso8601_timestamp(eventtime) AS EventTime, json_extract(additionalEventData, '$.SwitchFrom') AS SwitchRoleFrom\n"
    query += "FROM \"default\".\"cloudtrail_logs_syoseteki_test_desuyo\n"
    query += "WHERE eventname='SwitchRole' and\n"
    query += "eventtime>='2020-03-01T00:00:00Z' and\n"
    query += "eventtime<'2020-04-30T00:00:00Z' and\n"
    query += "REGEXP_LIKE(additionalEventData, '.*arn:aws:iam::xxxxxxxxxxxx.*')\n"
    
    database = "default"
    output   = "s3://athena-test-out/test"

    query_athena(query, database, output)

def query_athena(dst_que, dst_db, dst_out):

    client  = boto3.client('athena')
    res     = client.start_query_execution(
        QueryString = dst_que,
        QueryExecutionContext = {
            'Database': dst_db
        },
        ResultConfiguration = {
            'OutputLocation': dst_out
        }
    )

    que_exe_id  = res['QueryExecutionId']
    que_exe_sts = ""

    # queryが成功か失敗するまで待つ
    while(que_exe_sts != "SUCCEEDED") and (que_exe_sts != "FAILED"):
        que_sts     = client.get_query_execution(QueryExecutionId = que_exe_id)
        que_exe_sts = que_sts['QueryExecution']['Status']['State']

    result = client.get_query_results(QueryExecutionId = que_exe_id)
    print(result)

単純にクエリをAPIに渡して、実行されるを待っているだけです。
・クエリの実行時間を考慮して、Lambda関数のタイムアウト時間の調整が必要です。
・今回は実装していませんが、クエリやDB名などは、Inputファイルを用意したり、環境変数を使った方がスマートです。。
・実行待ちのタイムアウト処理も必要です (que_ext_stsが期待値にならないと無限ループしてしまう) 。

成功したら、指定したS3バケットに実行結果が出力されているはずです。

あとがき

膨大なCloudTrailのログから、目的のデータを見つけるのにAthenaは有用そうです。なんとなく難しそうなイメージのあったAthenaも、クエリをきちんと理解すれば、簡単に操作可能ですね。「Athenaはアテーナとも読むんやで」と、兄がどうでもいいポイントを教えてくれました。

それではまた、ごきげんよう。

Macユーザーが本気でWorkspaces(Windows)で仕事をしてみた

$
0
0

ゴールデンウィークの課題として、タイトルのとおり 妥協なしでWorkspaces(Windows)で仕事をできるようにする って検証をしてみました。
きっかけは↓こちらの記事を書きながら『そもそもローカルディスクを使わなければ良いのに』と思い立った次第です。

macOSのスリープ時に一時ファイルを削除しよう

現状の業務環境は、以下のとおりです。

  • MacBook Air (Retina, 13-inch, 2019) macOS Catalina
  • USキーボード / Dvorak配列
  • 外付けのハードウェア
    • Jabra Elite 65t
    • その他、ディスプレイ / マウス等は使っていません

以下、ひさしぶりのWindowsで大変に苦労をしたので、今後Workspacesの導入を検討されるMacユーザーのお役にたてればとの思いでセットアップの内容を記載しておきます。

1. ブラウザの変更

デフォルトのブラウザが Firefox だったので、Google Chrome に変更しました。(普段は Safari

2. IMEの設定

日本語入力の切り替えは control + spaceに設定しました。
参考: WorkSpacesを利用する際のTips キー入力編

3. キーボード配列の変更

regeditでレジストリを書き換えて、QWERTY配列からDvorak配列に変更しました。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\00000411
Layout File の値を KBDJPN.DLLから KBDDV.DLLに変更してOSを再起動します。

4. caps lockキーをcontrolキーに変更

regeditでレジストリを書き換えて、caps lockキーcontrolキーに変更しました。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
にバイナリ値の Scancode Mapを追加して以下の値を設定します。
0000  00 00 00 00 00 00 00 00
0008  03 00 00 00 1D 00 3A 00
0010  3A 00 1D 00 00 00 00 00
0018

5. デスクトップのカスタマイズ

Workspaces 標準のテーマだと寂しいので、Windows 10 に変更しました。
併せて、普段 Mac を使っているので、デスクトップに ショートカット や ごみ箱 のアイコンがあるのは違和感があるのでショートカットは削除、ごみ箱は非表示にしました。

6. タスクバーのカスタマイズ

デフォルトだと利用することのないアイコン群でゴチャついているので、不要なアイコンは非表示にして、タスクバーを自動的に隠す ように設定しました。

7. フォントの変更

デフォルトのフォントが合わなかったので変更しました。

8. 各種アプリケーションのインストール

ここまでの手順で、なんとなく違和感がある部分は解消されました。
ここから、やっと普段業務で利用するアプリケーションのセットアップをはじめられます。

9. Git for Windows SDK のカスタマイズ

開発環境は EC2 に移行してあるので、Workspaces には ssh クライアントと EC2 を起動する為の awscli のみが必要です。
参考: エンジニアブログ – 開発環境をAmazonEC2に移した結果、僕のVimはもうしゃべらない
Git for Windows ではなく Git for Windows SDK をインストールすることで、パッケージ管理ツールの pacman を利用することが可能です。
pacman から pip をインストールして、pip から awscli をインストールしました。
(試していませんが、zshも配布されているみたいです)

$ pacman -S python-pip
$ pip install awscli

使用感 

ショートカットキーがMacと異なる部分は耐えるしかないとして、いまのところ業務を進めるうえで問題になりそうな部分は Google Meet でカメラが使えないところくらいですね。
とは言え、カメラが必要なミーティングであればスマホから参加すれば解決できちゃいますね。
desktop
これでローカルに秘匿情報を一切持つことなく全ての業務ができる。ってのは、本当にすばらしい。
iPad版のWorkspacesクライアントと組み合わせれば、生産性を下げることなく今まで以上にフレキシブルな働き方ができそうですね。

よく使うショートカットキー

コマンド 効果
command + esc Windowsスタートメニュー
control + space IMEの切り替え
option + space, x Windowの最大化
option + space, n Windowの最小化
option + tab Windowの切り替え(サムネイルあり)
option + esc Windowの切り替え(サムネイルなし)

 

WorkSpacesで移動プロファイル、フォルダーリダイレクトの利用

$
0
0

こんにちは、技術2課、大阪勤務の全(ちょん)です。

最近、便利なWindowsのコマンドを発見しました。
それは、、、fsutil です。
大容量データの転送テストの際によく使われるコマンドとなりますが、CUIに長けている方は「常識だろ」と思われる方は多いかもしれません。
5年早く知って入ればテキストファイルに文字列を繰り返しコピペするといった苦行を味合わずに済んだのにと、恥ずかしくなりました。
(今回のブログ内容とは関係ありません)

今回はWorkSpacesで移動プロファイルやフォルダーリダイレクト機能が利用できるということで実装方法をご紹介します。

移動プロファイルおよびフォルダーリダイレクトの概要

それぞれの概要は以下のリンクをご参照願います。
https://docs.microsoft.com/ja-jp/windows-server/storage/folder-redirection/folder-redirection-rup-overview

移動プロファイルおよびフォルダーリダイレクト機能で実現できること

WorkSpacesではデフォルトで12時間ごとにユーザーボリューム(Dドライブ)のスナップショットが取得されます。
言い換えると障害等でWorkSpacesを再構築する必要が発生した場合、最悪、12時間前のデータに戻る可能性があります。
移動プロファイルやフォルダーリダイレクトを利用することで、ユーザーボリュームを逐一バックアップすることができ、不測の事態に備えることができます。

また、ユーザープロファイルにはデスクトップやドキュメントはもちろん、メールデータやインストールされた電子署名証明書等も含まれます。
日々のバックアップだけではなく、オンプレミス環境からWorkSpacesへの移行する場合にも大いに役立つ機能だと思います。
クライアント用PCを移行するのは大変な作業ではありますが、この機会にご検討してみてはいかがでしょうか。

前提条件

今回は以下の構成で実装しました。
・Active Directory on EC2(Windows Server 2016 R2)
・ADConnecter(サイズ:スモール)
・WorkSpaces(Windows 10)
・FSx for Windows Server(Single AZ)
AWS環境構築手順およびActive Directoryインストール手順は省略します(特別な手順は特にありません)

構成図は以下のとおりとなります。

移動プロファイル設定

手順は以下のリンクを参考とさせていただきました。
https://docs.microsoft.com/ja-jp/windows-server/storage/folder-redirection/deploy-roaming-user-profiles

手順1.移動プロファイル用フォルダの作成

FSx for Windowsへアクセスし、移動プロファイル用フォルダ(今回はProfiles)を作成します。

手順2.ユーザープロファイルの設定

[Active Directory ユーザーとコンピューター]を起動し、移動プロファイルを設定したいWorkSpacesユーザーを右クリックし[プロパティ]を選択します。

[プロファイル]タブを選択し、[プロファイルパス(P):]へ、手順1.で作成した移動プロファイル用フォルダのフルパスを入力し、末尾にユーザー名を入力します。その後、[OK]を選択します。

複数ユーザーを一括で設定したい場合、複数選択でプロパティ画面を開き、プロファイルパスの末尾に%username%と入力します。

【テスト】 移動プロファイルの確認

設定が完了しましたら、WorkSpacesへログインしてみましょう。
確認方法は以下の通りとなります。

WorkSpaces側で[コントロールパネル]>[ユーザーアカウント]>[ユーザーアカウント]>[ユーザープロファイルの詳細プロパティ]を選択し、[種類]と[状態]がそれぞれ移動と表示されていること。

移動プロファイル用に作成した共有フォルダにユーザー名のフォルダ(※)が作成されていること。

※ 今回の構成の場合、フォルダ名は<ユーザー名.V6>となります。詳細については以下のリンクをご確認ください。
https://support.microsoft.com/ja-jp/help/3056198/roaming-user-profiles-versioning-in-windows-10-and-later

フォルダーリダイレクト設定

手順は以下のリンクを参考とさせていただきました。
https://docs.microsoft.com/ja-jp/windows-server/storage/folder-redirection/deploy-folder-redirection

手順1.フォルダーリダイレクト用フォルダの作成

FSx for Windowsへアクセスし、フォルダーリダイレクト用フォルダ(今回はRedirect)を作成します。

手順2.フォルダーリダイレクトのGPO作成

[グループポリシーの管理]を起動し、WorkSpacesを利用するユーザーが所属するOU(今回はWorkSpaces-OU)を右クリックし、[このドメインにGPOを作成し、このコンテナーにリンクする]を選択します。

GPO名(今回はRedirect)を入力し、[OK]を選択します。

作成したGPOを右クリックし、編集を選択します。

[ユーザーの構成]>[ポリシー]>[Windowsの設定]>[フォルダーリダイレクト]を選択し、フォルダーリダイレクト設定を実施したいフォルダを右クリックし、[プロパティ]を選択します。

[ターゲット]タブの[設定]を[基本 – 全員のフォルダーを同じ場所にリダイレクトする]を選択します。
[対象フォルダーの場所(T)]を[ルートパスの下に書くユーザーのフォルダーを作成する]を選択します。
[ルートパス(P):]を手順1.で作成したフォルダーリダイレクト用フォルダのフルパスを入力します。
設定が完了したら[OK]を選択します。

警告画面が表示されますが、[はい(Y)]を選択します。

【テスト】 フォルダーリダイレクトの確認

設定が完了しましたら、WorkSpacesへログインしてみましょう。
確認方法は以下の通りとなります。

ポリシーを適用させるため、コマンドプロンプト(またはPowerShell)を管理者権限で起動し、以下のコマンドを実行してください。

gpupdate /force

ポリシーの適用が完了後、ログオフの要求がきますので再接続してください。

WorkSpaces側でフォルダーリダイレクト設定を実施したフォルダのプロパティ画面を開き、[全般]タブの[場所:]に記載されているパスに、設定した共有フォルダのパスが表示されていること。

フォルダーリダイレクト用に作成した共有フォルダにユーザー名のフォルダが作成されていること。

まとめ

今回はWorkSpacesで移動プロファイルおよびフォルダーリダイレクト機能が利用できるという紹介となりました。
今回はFSx for Windows Serverを利用しましたが、もちろんEC2で構築したWindowsサーバーでも共有フォルダ設定を実施することで代用可能となっております。
移動プロファイルやフォルダーリダイレクト機能はすごく便利な機能のため、ぜひ、ご活用ください。

CloudWatch Logs Metric Filter と Alarm を CloudFormation で作成する

$
0
0
こんにちは。技術4課の保田(ほだ)です。
GW はずっと AWS Translate と Google 翻訳を使って適当な文章を200回ぐらい再翻訳してめちゃくちゃな日本語を作って遊んでました。オススメです。
 

要約

Lambda で特定の文字列がログ出力されたらメール通知してくれる仕組みを CloudFormation で作ります。

導入

Lambda で特定の文字列がログ出力されたらメール通知してくれる仕組みがサクッと作れればいいな、って思うことはありませんか?ありますよね? Lambda 自体は SAM (Serverless Application Model) や Serverless Framework で作成するので一緒に作ってしまった方が良いですよね。設定し忘れていて通知されなかったら大変です。

本題

今回は Lambda のログに SystemFault という文字列が出力されたら CloudWatch のアラーム状態になってそれが SNS でメール通知してくれるような仕組みを SAM で作ってみます。

ディレクトリ構成はとりあえずこんな感じとしておきます。

.
├ sns.yml
├ template.yml
└src
  └handler.py

Lambda のコード( src/handler.py )は以下のものとします。

def main(event, context):
    print('↓の文字列が出力されるとメールが飛ぶ仕組み')
    print('SystemFault')
    return 'Hello, World!'

ただ実行されるだけだとエラーは起きませんが、この SystemFault をメトリクスフィルターで引っ掛けて拾ってみよう、というわけです。(参考:https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/MonitoringLogData.html

テンプレートを書く

まず、メール通知に使う SNS トピックおよびサブスクリプションを作成します。複数の Lambda が存在しても通知するトピックは共通化されているのが自然なので、実際に使用するときもテンプレートを別にすることが多いであろうという意図でテンプレートを分けています。

AWSTemplateFormatVersion: "2010-09-09"
Description: SNS for Alarm Mail Notification

Parameters:
  SNSSubscriptionEmail:
    Type: String
    Default: xxxx@example.com
    Description: Email for Error Notice SNS Subscription.

Resources:
  # SNS Topic
  MyNoticeAlertTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: my-notice-error
      DisplayName: my-notice-error
      Subscription:
        - Endpoint: !Ref SNSSubscriptionEmail
          Protocol: email

Outputs:
  MyNoticeAlertTopicArn:
    Description: Topic Arn of MyNoticeAlert
    Value: !Ref MyNoticeAlertTopic
    Export:
      Name: !Sub ${AWS::StackName}-MyNoticeAlertTopic

そしてメインの Lambda とロググループ、メトリクスフィルター、アラームについてのテンプレートですが、一気に全部載せると長いので部分ごとに分けてご説明します。

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31
Description: Log Filter and Alarm Sample

Globals:
  Function:
    Runtime: python3.8
    Timeout: 30
    MemorySize: 256

Resources:
  LogFilterAlarmSampleFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: log-filter-alarm-sample-function
      Handler: handler.main
      CodeUri: ./src
      Role: !GetAtt LogFilterAlarmSampleFunctionRole.Arn

  LogFilterAlarmSampleFunctionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: "sts:AssumeRole"
      RoleName: LogFilterAlarmSampleFunctionRole
      Policies:
        - PolicyName: LogFilterAlarmSampleFunctionPolicy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              -
                Effect: Allow
                Action:
                  - logs:CreateLogGroup
                  - logs:CreateLogStream
                  - logs:PutLogEvents
                Resource:
                  - !Sub arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/log-filter-alarm-sample-function*:*
                  - !Sub arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/log-filter-alarm-sample-function*:*:*

まずこちら。 Lambda のソースと実行ロールです。SAM なので頭に Transform: AWS::Serverless-2016-10-31 がついています。サンプルなのでログを出力する権限しかつけていません。

通常 SAM ではロググループも自動で作成されますが、このあとメトリクスフィルターを定義する際にリソース名を指定するため、このように明示的に定義しています。(参考:https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-logs-loggroup.html

# Log Group
  LogFilterAlarmSampleFunctionLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub /aws/lambda/${LogFilterAlarmSampleFunction}
      RetentionInDays: 14

そしてメトリクスフィルターです。

# Log Filter
  LogFilterAlarmSampleFunctionMetricFilter:
    Type: AWS::Logs::MetricFilter
    Properties:
      FilterPattern: "SystemFault"
      LogGroupName:
        !Ref LogFilterAlarmSampleFunctionLogGroup
      MetricTransformations:
        -
          MetricValue: "1"
          MetricNamespace: LogMetrics
          MetricName: !Sub ${LogFilterAlarmSampleFunction}/SystemFault

FilterPattern として SystemFault という文字列の出現回数をカウントします。(参考:https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-logs-metricfilter.html

最後にアラームです。(参考:https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-cw-alarm.html

# Alarm
  LogFilterAlarmSampleFunctionAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmDescription: My Lambda SystemFault Alarm
      AlarmName: !Sub ${LogFilterAlarmSampleFunction}-system-fault
      AlarmActions:
        - !ImportValue SampleSNSStack-MyNoticeAlertTopic
      ComparisonOperator: GreaterThanOrEqualToThreshold
      Threshold: 1
      DatapointsToAlarm: 1
      EvaluationPeriods: 1
      MetricName: !Sub ${LogFilterAlarmSampleFunction}/SystemFault
      Namespace: LogMetrics
      Period: 60
      Statistic: Maximum

上に書いたメトリクスを MetricName で指定し、「1分以内にメトリクスフィルターで拾った出現回数の最大値が1を超えたら」つまり「1分以内にフィルターパターンに合致したログが1回でも出力されれば」アラームのメール通知が飛ぶようになっています。

冒頭のディレクトリ構成の図に書いた template.yml はこれらの4つをそのままつなげたものです。

デプロイする

デプロイします。

まず SNS です。エンドポイントのメールアドレスは必要に応じて上書きします。

$ aws cloudformation deploy \
  --template-file sns.yml \
  --stack-name SampleSNSStack \
  --parameter-overrides SNSSubscriptionEmail=yyyy@example.com

デプロイに成功するとサブスクリプションを Confirm して下さいというメールが来るので Confirm します。ちなみに 2020 年5月時点で CloudFormation のマネジメントコンソールの「リソース」タブから SNS トピックのリンクを飛ぼうとすると ARN の「:(コロン)」がエスケープされてしまって変な感じになりますが、問題ありません。

続けて Lambda 周りのテンプレートをデプロイしますが、まず Lambda のソースコードをパッケージングしてやる必要があります。バケット名には適切な既存のバケットを指定します。

$ aws cloudformation package --template-file template.yml \
  --output-template-file packaged.yml \
  --s3-bucket hoge-bucket

成功するとこんなログが出るかと思います。

Successfully packaged artifacts and wrote output template to file packaged.yml.
Execute the following command to deploy the packaged template
aws cloudformation deploy --template-file C:\Users\xxxx\hoge\packaged.yml --stack-name <YOUR STACK NAME>

デプロイします。ひっかけのような気がしますが、出力されたコマンドそのままでは不十分です。  IAM ロールを作成しますので --capabilities CAPABILITY_NAMED_IAM を付けてやる必要があるからです(十分な権限が付与されている前提ですが…)。

$ aws cloudformation deploy --template-file packaged.yml \
  --stack-name SampleLogFilterAlarmStack \
  --capabilities CAPABILITY_NAMED_IAM

完了したらマネジメントコンソールで確認してみましょう。

メトリクスフィルターですが、名前はマネジメントコンソールから手動で作ったときに比べてランダム文字列がサフィックスとして付きます。

アラームはこんな感じです。上で説明した通りの設定になっています。「1」という数字が各所に出ていて混乱しますがテンプレートとしてガッチリ管理してあれば安心ですね!

ちなみになぜかわからないのですが、アクションの項目を見る通知先の SNS トピックには保留中の確認という「エンドポイントは Confirm されていないよ!」というメッセージが出っぱなしになります。ちゃんと Confirm していても出るので動作としては問題ないですがちょっとアレです。

次は実際に動かしてちゃんとメール通知がくるか試してみます。

試す

デプロイが完了したら早速挙動を確かめてみます。

どういう方法でも良いので作成された Lambda を実行します。今回のサンプルでは適当でいいです。

テストイベントを作成したら実行します。

ちょっとするとメールが来ます。やったね。

まとめ

以上の方法を活用すれば、Lambda の処理中にランダムな文字列を生成してログ出力するようにしたうえで、それが事前に登録したランダムな文字列と一致したら開発者の自分にメール通知させて「おめでとうございます!一兆分の一の確率で当選しました!」という粋な遊びができますね。

 

 

DWH製品の注目株!! Snowflake をさわってみた

$
0
0

 

技術 4 課の宮本です。最近電動式のスタンディングデスク(の脚)を購入し、意味もなく上げ下げして満足感に浸っています。さて、今回は Data Warehouse-as-a-Service として最近注目を集めている Snowflake を触ってみました。

Snowflake とは

クラウド向けに構築されたデータウェアハウスで、以下の特徴があります。

  • Instant Elasticity (瞬間的な弾力性)
    • 必要なパフォーマンスと実行可能なインサイトを得るため、任意の数のユーザーに必要な量のコンピューティングパワーを提供します。
  • セキュリティ
    • 管理性、セキュリティを担保しながら、リアルタイムにデータ共有を実現することにより、部門間や外部パートナーとの協業を推進します。
  • 秒単位課金
    • ワークロードを支えるコンピューティングパワーの量を自動的に縮小することで、ウェアハウスのコストを削減します。
  • クラウド向けに設計
    • 既存データ・アプリをそのまま残しながらも、地域やクラウドプロバイダーの垣根を超えてデータレプリケーションを実現することにより、フェイルオーバー・継続性面でも自信を持って運用。

引用元: https://www.snowflake.com/?lang=ja

早速触ってみる

ものは試しですね。まずはアカウントを作って試してみます。

https://www.snowflake.com/?lang=ja にアクセスしてみましょう。

SNOWFLAKEを試す を選択します。

トライアルで 30 日間 \$400 分の利用が無料でできるようです。全て入力して CONTINUE を選択します。

エディションは Enterprize を選択しました。トライアルの時点ではクレジットカードなどの登録は行わないため、ご安心ください。クラウドプロバイダーは AWS 、リージョンは Asia Pacific (Tokyo) を選択しました。Phone Number も入力して GET STARTED を選択します。

尚、Asia Pacific (Tokyo) リージョンの他は、以下のリージョンが選択できるようです。

 YOU'RE NOW SIGNED UP! が表示されるまで待ちましょう。

登録したメールアドレス宛に確認用のメールが届いているはずです。

CLICK TO ACTIVATE を選択します。

アクティベーションが成功しました。作成したい任意のユーザー名とパスワードを入力して Get Started を選択します。

Web インターフェースにログイン出来ました。

クエリを実行する

初期で用意されているサンプルデータがあるので、早速SQLを実行してみましょう。画面上部のメニューで Worksheets を選択します。

画面左側のオブジェクト一覧を展開してみましょう。存在するテーブルが確認できます。

Database -> Schema -> Table という構成になっています。ここはデータベース製品ごとに用語が変わってくるので抑えておきたいところです。

スキーマ TPCH_SF1 、テーブル CUSTOMER を取得するクエリを実行してみます。画面右上部分を選択し、現在のセッション状態を変更出来ます。

スキーマまで選択しておきましょう。選択しない場合、SQLのFROM句に スキーマ名.テーブル名 の形式で指定しなければなりません。

エディタ部分にSQLを入力し、Run ボタンを選択します。

画面下部に結果が表示されます。Snowflake で使えるSQL構文についてはドキュメントを参照してみてください。

クエリの履歴を確認する

続いてクエリの履歴を確認してみましょう。画面上部の History を選択します。直近に実行したクエリが一覧表示されます。

任意の行の Query ID を選択してみましょう。実行したSQLとその結果が表示されます。

その他のメニューについて

Databases

既存のデータベース一覧が確認出来ます。

データベース名を選択すると、配下のオブジェクトも一覧で確認出来ます。

Shares

他の Snowflake アカウントとデータを共有できる機能のようです。長くなりそうなので次回以降、試してみることにします。

Warehouses

Warehouse の一覧が確認出来ます。

Warehouse とは

仮想ウェアハウスは、顧客によるクエリの実行、データのロード、他の DML 操作の実行を可能にする1つ以上のコンピュートクラスタです。

引用元: https://docs.snowflake.com/ja/user-guide/credits.html

クエリ性能、請求に関わってくる部分の様なので、実運用する際は押さえておきたい部分ですね。

Partner Connect

Snowflake のパートナーのサービスにデータを連携できる様です。データの可視化、分析、加工が必要な際に使えそうです。

 

まとめ

アカウントの登録からクエリの実行まで、30分程度で試すことが出来ました。実際に導入するまでには、抑えておかなければならないことが沢山ありますが、簡単に試せるのは良いことですね。

次回以降、Web インターフェース以外からのアクセスや、アーキテクチャーについてもご紹介出来ればと思います。

 

Viewing all 1210 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>