こんにちは、技術3課の城です。
サーバーワークスに入社して１年半となりましたが、いろいろなお客様の設計や構築業務に携わらせていただきました。
その中で、アカウントやネットワークの設計は土台となるものなので、重要性や難しさについて経験してきました。

最近ではAWSのサービスの拡張により、設計思想を若干変化させる必要がありそうです。
特にネットワークにおいてTransit GatewayやVPC共有等が昨年末発表されたことにより、アカウント設計、ネットワーク設計をより分離して考えることができるようになったと感じています。
そこで、現時点ではどういう観点で設計の検討をしていくかについて、まとめてみたいと思います。

1. 基本的な方針

要件は抑えつつ、できるだけシンプルな構成を心掛けています。
AWSは自由度が高く、要件に合わせやすい反面、複雑にしようとすれば際限なく複雑になってしまう一面があります。
構成が複雑化しすぎることにより、運用場面において、辛いことも多いので気を付けたいところです。

2. マルチアカウント vs シングルアカウント

こちらについては、マルチアカウントにする理由があるかどうかです。
一般的には下記のような要件でマルチアカウントにされるのではないでしょうか。

• 各アカウントでの請求を分離したい
• 権限を委譲したい
  • IAMの管理をシンプルにしたい
• 各アカウントで役割を分けたい
  • 踏台アカウント
  • 監査用アカウント（CloudTrail、Configの集約）
  • 本番/ステージング/開発等

このような要件からアカウントを分ける必要があるかどうか、検討したらよいかと思います。
権限委譲については、IAMポリシーを頑張って作れば可能な部分もありますが、アカウントを分ければより明確に権限を分離することができます。
また、ネットワーク的観点でいえばVPC共有がリリースされた現在では、別アカウントであっても同一VPCにリソース（一部除く）を作成できるため、以前ほど同一アカウント内にこだわる理由が薄くなってきていると思われます。

アカウント設計については、2017年の資料ではありますが、下記資料がとても分かりやすいです。
AWS におけるマルチアカウント管理の手法とベストプラクティス

3. マルチVPC vs シングルVPC

VPC共有がリリースされる以前は、アカウントを分けると必然的にVPCをそれぞれで作成する必要がありました。
現在では、VPC共有を利用してマルチアカウントでも同一VPC、細かく言えばサブネットですが、共有して利用することも可能です。
用途や運用ポリシーによるところが多いと思いますが、下記パターンについて考えてみました。

• マルチVPC(完全分離型)
• マルチVPC + PrivateLink
• マルチVPC + VPC Peering or Transit Gateway
• シングルVPC（サブネット共有）

3.1 マルチVPC(完全分離型)

VPC間でネットワークを接続させたくない、接続する必要がない場合、マルチVPCで完全に分離した環境とするかと思います。
リソース間のネットワーク的な疎通が不要であれば、VPCを分け、完全に分離されたネットワークとするべきでしょう。
【イメージ図例】

3.2 マルチVPC + PrivateLink

こちらは要件として少し特殊にかもしれませんが、一部のリソースのサービスを提供したい(その他のリソースは共有したくない)場合、マルチVPCでのPrivateLinkがフィットするでしょう。
PrivateLinkを利用することでアクセス範囲をリソースのサービスレベルで限定できます。
例えばSaaSサービスを顧客に対してPrivateLinkで提供するということもあるようです。
PrivateLinkについてはリージョンが同一である必要があるので、それぞれのVPCで、どのリージョンを利用しているかということも加味する必要があります。
【イメージ図例】

3.3 マルチVPC + VPC Peering or Transit Gateway

VPCを分けて作成したいが、ネットワークとして接続したい場合、マルチVPCでのVPC PeeringまたはTransit Gatewayを検討するかと思います。
既存ですでに複数のVPC上にリソースがあり動かせない場合もこのパターンになるでしょう。
【イメージ図例】

VPCを分けて作成したい理由としては、例えば下記のようなことが考えられます。

• 全てではないが一部だけネットワーク疎通させたいケース
• ネットワーク疎通させたいがVPC共有ができないケース
• ネットワークリソースについての管理権限が必要なケース

3.3.1 全てではないが一部だけネットワーク疎通させたいケース

一部だけネットワーク疎通といっても、もちろん同一VPCにてセキュリティグループやNetwork ACLによる制限も可能ですが、ネットワーク的な疎通自体を制限することでよりシンプルに、かつ、明確に管理できます。
管理方法としては、接続したいリソースについてサブネットを用意、そのサブネットに紐づけるルートテーブルにのみ、対向のネットワークセグメントを記載するといった方法があります。

3.3.2 ネットワーク疎通させたいがVPC共有ができないケース

VPC共有には前提条件としてAWS Organizationsで同じ組織に属している必要があるため、別組織に属する場合はVPC共有ができません。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html

また、VPC共有で共有先のアカウントでは下記利用できないサービスがあり、こちらが必要な場合も該当しそうです。

• Amazon Aurora サーバーレス
• AWS CloudHSM
• AWS Glue
• Amazon EMR
• Network Load Balancer

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html#vpc-share-unsupported-services

3.3.3 ネットワークリソースについての管理権限が必要なケース

厳密には、必要な管理者にクロスアカウントのIAMロールやIAMユーザーを払い出すことで対応可能ですが、どのように運用するか次第でしょう。

3.4 シングルVPC（VPC共有）

特にVPCを分けて作成する理由がない場合はシングルVPCとなるでしょう。
なにかしら理由があったとしても、VPCは少ない方が管理リソース数が少なく、シンプルになることによる利点もあります。
VPCを分けるべき理由が許容できる範囲であったり、別の方法で回避することが可能であれば、シングルVPCでの設計とするのもアリでしょう。
【イメージ図例】

ただし、前の項でも述べていますが、VPC共有を利用する場合、共有先のアカウントではいろいろと制限があります。
作成できないリソースがあったり、ネットワークリソースは共有元の管理となるため、変更、追加等の操作は出来ません。
運用の仕方に依る部分かと思いますので、柔軟に検討しましょう。

※注) VPC共有を利用するには共有元アカウント、共有先アカウントがAWS Organizationsの同一組織に属している必要がありますので、ご注意ください。

4. VPC Peering vs Transit Gateway

VPC間の接続方法について比較します。

4.1 コスト

VPC Peering自体に対する課金はないのに対し、Transit Gatewayは処理データ量についての課金、また、各VPCとのアタッチメント毎にも課金されます。
Transit Gateway 料金

4.2 接続方法

VPC Peeringは接続するVPCをそれぞれ1対1で接続します。
Transit GatewayはひとつのTransit Gatewayから接続するVPCに対してアタッチメントを作成することで接続します。
下図は5つのVPCをすべて疎通させたいケースの例となりますが、VPC Peering（図左）はフルメッシュで作成するのに対し、Transit Gateway（図右）はハブ&スポークで接続できるイメージです。

4.3 サブネットのルートテーブル

VPC Peeringは送信先ネットワークレンジのターゲットとして、そのVPCとのVPC Peeringをそれぞれ指定する必要があります。
Transit GatewayはTransit Gatewayを指定できます。
Transit Gatewayはターゲットが同じなので、場合によっては経路集約するなどでシンプルなルートテーブルにできそうです。
対して、VPC Peeringは各送信先ネットワークレンジに対し別々のターゲットを指定する必要があり、接続するVPCが5,10と多くなればなるほど、複雑化します。
実際に経験としてありますが、中々に大変です。

4.4 VPN接続

VPC Peeringで接続しているVPCについては、同一拠点に対するVPN接続であっても、それぞれのVPCでVPN接続を行う必要があります。
Transit GatewayについてはVPN接続をアタッチできるため、一つのVPN接続を一つのアタッチメントとして取り扱うことができます。
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-vpn-attachments.html

4.5 Direct Connect

東京リージョンにおいては現状、どちらもDirect Connect(Direct Connect Gateway)からVirtual Interface作成し、各VPCのVirtual Private Gatewayに紐づけする必要があります。
ただし、Transit GatewayはDirect Connectに対応する予定とされており、一部リージョンではDirect Connect GatewayをTransit Gatewayと関連づける機能がリリースされています。
※2019/5/27時点の情報となります。

https://aws.amazon.com/jp/blogs/aws/use-aws-transit-gateway-direct-connect-to-centralize-and-streamline-your-network-connectivity/
https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/direct-connect-transit-gateways.html

4.6 その他

Transit Gatewayには各アタッチメント毎にルートテーブルを設定する必要があります。
デフォルトのルートテーブル（Any to Any）を利用することもできますが、内容を詳細に設定することもできます。
また、ブラックホール(ドロップ)を設定することもできます。
例えば、VPC間はすべて疎通させるが、VPN接続先の拠点ネットワークとの疎通はVPCにより制限するなど、詳細に設定することが可能です。
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-route-tables.html

4.7 比較まとめ

5. さいごに

改めて考えてみると、現状どのようなことを考えて設計を検討するか見えてきた気がします。
やはり、ほぼほぼアカウント設計とネットワーク設計を分離して考えることができ、それぞれの要件に引きずられることなく、実現しやすいようになっていそうです。

ざっとまとめてみましたが、どなたかの助けになれば幸いです。

はじめに

こんにちは、技術一課の山中です。

最近になって、 pipenv を使って開発をし始めたのですが、 Pipfile で管理しているライブラリレイヤーに含めてデプロイするにはどのようにすればよいでしょうか。

Lambda Layers のデプロイに必要な構成

Lambda Layers では、 こちら のブログにあるように以下の構成で、メインの Python コードとライブラリの依存関係をレイヤーに含める必要があります。

layer.zip
└── python
    ├── log.py
    ├── sns.py
    └── lib
        └── python3.7
            └── site-packages
                └── [libraries]

以下構成で開発しているコードを Lambda Layers にデプロイするにはどうすればよいでしょうか。

.
├── Pipfile
├── Pipfile.lock
└── python
    ├── log.py
    └── sns.py

依存ライブラリのインストール

Pipfile が存在するディレクトリで以下コマンドを実行します。

※ pipenv lock -r で requirements.txt の形式で依存ライブラリを標準出力し、 -r でその内容を受け取り -t で指定したディレクトリに依存ライブラリをインストールします。

$ pipenv lock -r | pip install -r /dev/stdin -t python/lib/python3.7/site-packages/

実行すると以下のように必要なライブラリが指定したディレクトリ構成でインストールされます。

.
├── Pipfile
├── Pipfile.lock
└── python
    ├── lib
    │   └── python3.7
    │       └── site-packages
    │           ├── [librariy_A]
    │           │   ├── INSTALLER
------------- [省略] ---------------------
    ├── log.py
    └── sns.py

あとは、これを Zip にしてアップロードすればデプロイ完了です。

おわりに

他によい方法があれば教えてください！

はじめに

こんにちは、技術一課の山中です。

Lambda Layers を AWS Lambda で利用する場合に、デプロイ時の最新の Layer を常に利用したいことがあったので、どのようにすればよいのか考えたことを以下に記します。

Lambda Layers のデプロイ

現在、Lambda Layers にデプロイするディレクトリの構成は以下の通りです。

.
├── package-lock.json
├── package.json
├── sample
│   └── python
│       └── sample.py
└── serverless.yml

デプロイする Python コードの中身は以下のようになっています。
say メソッドに引数を渡すことで say [引数] from layer を print してくれるという優れものです。

$ cat sample/python/sample.py
def say(message):
    print('say {} from layer'.format(message))

今回は Serverless Framework を利用してデプロイしますので、 serverless.yml を以下のように定義します。

$ cat serverless.yml
service: sample

provider:
  name: aws
  stage: dev
  region: ap-northeast-1

layers:
  sampleLayers:
    path: sample
    description: sample layer
    compatibleRuntimes:
      - python3.7

ここまで準備できたら serverless deploy コマンドでデプロイしてください。

Lambda Layers を利用するファンクションのデプロイ

通常であれば、以下のように serverless.yml で Lambda Layers の ARN をバージョンまで指定して定義しなければなりません。

service: sample-layers

provider:
  name: aws
  runtime: python3.7
  region: ap-northeast-1

functions:
  sample_function:
    handler: lambda_function.lambda_handler
    layers:
      - arn:aws:lambda:ap-northeast-1:000000000000:layer:sample:1

バージョン番号を指定せず常にデプロイ時に最新の Layers を指定したい場合はどのようにすればよいのでしょうか。
Serverless Framework では CloudFormation を利用して生成されたリソースを以下の形で参照し、利用することができます。

cf:[スタック名].[出力キー]

先ほどデプロイした Lambda Layers の出力キーは以下となっているので、これを利用してこれからデプロイする Lambda から参照するように serverless.yml を修正してみましょう。

service: sample-lambda

provider:
  name: aws
  runtime: python3.7
  region: ap-northeast-1

functions:
  sample_function:
    handler: lambda_function.lambda_handler
    layers:
      - ${cf:sample-layers-dev.SampleLayersLambdaLayerQualifiedArn}

${cf:sample-layers-dev.SampleLayersLambdaLayerQualifiedArn} の sample-layers-dev が Lambda Layers デプロイ時のスタック名、 SampleLayersLambdaLayerQualifiedArn が出力キーとなっています。
また、今回デプロイする lambda_function.py は以下です。

from sample import say

def lambda_handler(event=None, context=None):
    say('this is sample')

ここまで準備できたら Lambda ファンクションもデプロイしてみてください。

$ serverless deploy
Service Information
service: sample-lambda
stage: dev
region: ap-northeast-1
stack: sample-lambda-dev
resources: 4
api keys:
  None
endpoints:
  None
functions:
  sample_function: sample-lambda-dev-sample_function
layers:
  None

Stack Outputs
SampleUnderscorefunctionLambdaFunctionQualifiedArn: arn:aws:lambda:ap-northeast-1:000000000000:function:sample-lambda-dev-sample_function:1
ServerlessDeploymentBucketName: sample_bucket

実行してみる

デプロイした Lambda ファンクションを実行してみましょう。

$ serverless invoke -f sample_function -l
--(省略)--
say this is sample from layer
--(省略)--

きちんと Lambda Layers のメソッドを利用できています。

おわりに

先日デプロイパッケージの制限に引っかかりデプロイできない事案があったので、 Lambda のデプロイ時は以下をよく参照してデプロイしてください。

AWS Lambda の制限 – AWS Lambda

はじめに

こんにちは、技術一課の山中です。

Python のタイムゾーンについて、学んだことを忘れないようにブログにまとめました。

Python の組み込みモジュールである datetime を利用して現在時刻を取得する場合、通常以下のように記載すると思います。

from datetime import datetime

def lambda_handler(event=None, context=None):
    now = datetime.now()
    print(now)


if __name__ == '__main__':
    lambda_handler()

これを私のローカル PC で実行した結果は以下のとおりです。

2019-06-02 10:32:47.529957

同じものを AWS Lambda で実行してみると出力結果は以下のようになります。

2019-06-02 01:36:05.075726

同じコードを実行していてもかなり出力結果が異なります。

これは AWS Lambda の実行環境と私のローカル PC の実行環境とでタイムゾーンが異なることで起こります。

タイムゾーンの変換

AWS Lambda の実行環境におけるタイムゾーンは UTC ですが、出力時には JST タイムゾーンで出力したいケースがあります。

Python でのタイムゾーン変換は pytz モジュールで行います。

pytz は必要となるすべてのタイムゾーンの完全なデータベースを含んでいるので、任意のタイムゾーンに変換することが可能です。

import pytz

from datetime import datetime, timezone

def lambda_handler(event=None, context=None):
    now = datetime.now(tz=timezone.utc)

    tokyo = pytz.timezone('Asia/Tokyo')
    # 東京のローカル時間に変換
    jst_now = tokyo.normalize(now.astimezone(tokyo))
    print(jst_now)


if __name__ == '__main__':
    lambda_handler()

これを私のローカル PC で実行した結果は以下のとおりです。

2019-06-02 11:09:42.855108+09:00

同じものを AWS Lambda で実行した結果以下のとおりです。

2019-06-02 11:09:42.752163+09:00

pytz は標準モジュールではないため、 AWS Lambda で利用する場合は、 zip でアップロードしてください。

おわりに

タイムゾーンを意識していないと結果が想定どおりに出ずあれ？となることが多くありますが、いつも「コード内での時間は常に UTC で扱い、表示する段階でローカル時間に変換する」を意識していればいいかなと思います。

今年サーバーワークスに入社した新卒たちへのLinux研修を担当しました。

もちろん、利用するサーバーはEC2で用意。

研修なり検証なりでサーバーが壊れてもすぐに再構築できるのはクラウドのメリットでもあります。

新卒たちにも「壊しちゃってもいいのでどんどん触ろう」とは伝えていますが、実際どんなことをすると壊れてしまうのでしょうか？

ここでの「EC2インスタンスが壊れる」というのはインスタンスステータスチェックに失敗し、ログインできない状態とします。

使用したOSはAmazon Linux2です。

死の呪文

以下のコマンドをなんの疑問もなく実行し、念のためマネコンから停止/起動します。

sudo rm -rf –-no-preserve-root /

壊れました。

NICをダウン

上記のコマンドがすべての方法を包括してる気もしないでもないですが…

何の疑問もなく以下のコマンド実行します。
ENIを複数アタッチしている場合はそれぞれに対して実行してください。

ifdown eth0

壊れました。

まとめ

他にも方法はありますが。。。

まあわざと壊すことはないので気にしないことにします。

そう、インスタンス停止中じゃないと実行できません。エラーが出ます。

An error occurred (IncorrectInstanceState) when calling the ModifyInstanceAttribute operation: The instance 'i-xxxxxxxxxxxxxxxxx' is not in the 'stopped' state.

停止してから実行しましょう！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

こんにちは、技術３課、Elasticsearch初心者の城です。
Amazon Elasticsearch ServiceはオープンソースであるElasticsearchの完全マネージド型のサービスです。
ログ分析や全文検索に適しており、複数のログを集約して可視化するのに有用なサービスです。
https://aws.amazon.com/jp/elasticsearch-service/

先日、1つのドメインに対し、CloudTrail、及び、複数のVPC Flowlogsのデータを投入するというのをやってみました。
ほぼほぼ初めてに近いのですが、非常に便利なサービスで、個人的には触るのがすごく楽しいサービスですね。

今回は実際にやってみて、初めからこうしていた方がよかったなというポイントも多かったので、流れをご紹介したいと思います。
※CloudTrail、及び、VPC FlowlogsはCloudwatch Logsに出力されているのを前提とします。
※コマンド実行はWSLのubuntu 18.04のbash環境で実行しました。

1. Amazon Elasticsearch Serviceドメインの作成

構成についてはお試し構成ということで、小さめに作成してみます。
まず、Amazon Elasticsearch Serviceダッシュボードにて、[新しいドメインの作成]をクリックします。

1.1 Elasticsearch ドメインの作成 Step.1 デプロイタイプの選択

今回は最小構成で構築したいので、デプロイタイプは[カスタム]を選択します。
バージョンは最新の6.7を選択します。

1.2 Elasticsearch ドメインの作成 Step.2 クラスターの設定

下記画像のように、設定内容を入力し、[次へ]をクリックします。

1.3 Elasticsearch ドメインの作成 Step.３ アクセスの設定

今回はパブリックアクセスで送信元IPアドレスを基にアクセス制限したいと思います。
ネットワーク構成は[パブリックアクセス]にチェックし、ドメインアクセスポリシー設定の右側にある[テンプレートを選択]⇒[特定のIPからのドメインへのアクセスを許可]をクリックします。

入力欄にIPアドレス、または、CIDRブロックを入力し、[OK]をクリックします。
複数入力する場合はカンマ区切りで入力します。

アクセスポリシーが記載されていることを確認し、[次へ]をクリックします。

1.4 Elasticsearch ドメインの作成 Step.4 確認

設定内容を確認し、[確認]をクリックします。
「Elasticsearch ドメインが正常に作成されました。」と表示されていて、ドメインのステータスが「読み込み中…」となっているかと思います。
Activeになるまで、少し時間がかかります。

1.5 kibanaダッシュボードへのアクセス

ドメインのステータスがActiveになったらkibanaダッシュボードにアクセスします。
下記画面のKibanaのURLにブラウザでアクセスすると、Kibanaダッシュボードを開くことができます。

初期画面が表示されるので[Explore on my own]をクリックします。

Kibanaダッシュボードにアクセスできました。

2. Elasticsearchのインデックステンプレートの設定

私がElasticsearch Serviceを設定していく中でいくつか問題点、改善点に気づき、設定変更したり、あれしたりこれしたりしたのですが、予めやっておいた方が明らかに楽なポイントが多かったので、まとめておきます。
後述のCloudwatch LogsからElasticsearchへのストリーミングにおいては、いろいろとよしなにやってくれるのですが、前もって必要な設定をインデックステンプレートとして設定しておきます。
ちなみにインデックステンプレートについては、下記のElastic社のドキュメントをご覧ください。
https://www.elastic.co/guide/en/elasticsearch/reference/6.7/indices-templates.html

設定しておいた方がいいかなと思った点は下記となります。

• Cloudtrailのインデックスにて、index.mapping.total_fields.limitのデフォルト値:1,000を超過してしまうので、3,000くらいにしておく
• Cloudtrailのインデックスにて、apiVersionのフィールドのタイプがtext、dateと混在してしまい、コンフリクトするのでtextで設定
• VPC Flowlogsのインデックスのsrcaddr、dstaddrのフィールドのタイプがtextとなるので、ipで設定する
  • タイプをipで設定することでCIDRブロックでの検索が可能となる

インデックステンプレートの設定はcurlなどでElasticsearch Serviceのエンドポイントに対し、httpsリクエストを実行します。
今回はテンプレートをファイルとして用意し、コマンドを実行しました。

2.1 cloudtrail_indextemplate.jsonの作成

下記コマンドを実行します。

cat << ETX >> cloudtrail_indextemplate.json
{
  "index_patterns": ["cloudtrail-*"],
  "settings": {
    "index.mapping.total_fields.limit": 3000    
  },
  "mappings": {
    "logs": {
      "properties": {
        "apiVersion": {
          "type": "text"
        }
      }
    }
  }
}
ETX

2.2 Cloudtrail用インデックステンプレートの設定コマンド

下記コマンドを実行します。

curl -X PUT '【Elasticsearch Serviceのエンドポイント】/_template/template_1' -H 'Content-Type: application/json' -d @cloudtrail_indextemplate.json

【戻り値】

{"acknowledged":true}

2.3 vpc-flowlogs_indextemplate.jsonの作成

下記コマンドを実行します。

cat << ETX >> vpc-flowlogs_indextemplate.json
{
  "index_patterns": ["vpc-flowlogs-*"],
  "mappings": {
    "logs": {
      "properties": {
        "dstaddr": {
          "type": "ip"
        },
        "srcaddr": {
          "type": "ip"
        }
      }
    }
  }
}
ETX

2.4 VPC Flowlogs用インデックステンプレートの設定コマンド

下記コマンドを実行します。

curl -X PUT '【Elasticsearch Serviceのエンドポイント】/_template/template_2' -H 'Content-Type: application/json' -d @vpc-flowlogs_indextemplate.json

【戻り値】

{"acknowledged":true}

2.5 設定の確認

下記コマンドを実行します。
※パイプで渡しているjqコマンドはなくても問題ないですが、ないと内容を見るのが辛めです。

【Cloudtrail用インデックステンプレートの確認コマンド】

curl -X GET '【Elasticsearch Serviceのエンドポイント】/_template/template_1' | jq .

【戻り値】

{
  "template_1": {
    "order": 0,
    "index_patterns": [
      "cloudtrail-*"
    ],
    "settings": {
      "index": {
        "mapping": {
          "total_fields": {
            "limit": "3000"
          }
        }
      }
    },
    "mappings": {
      "logs": {
        "properties": {
          "apiVersion": {
            "type": "text"
          }
        }
      }
    },
    "aliases": {}
  }
}

【Cloudtrail用インデックステンプレートの確認コマンド】

curl -X GET '【Elasticsearch Serviceのエンドポイント】/_template/template_2' | jq .

【戻り値】

{
  "template_2": {
    "order": 0,
    "index_patterns": [
      "vpc-flowlogs-*"
    ],
    "settings": {},
    "mappings": {
      "logs": {
        "properties": {
          "srcaddr": {
            "type": "ip"
          },
          "dstaddr": {
            "type": "ip"
          }
        }
      }
    },
    "aliases": {}
  }
}

3. Cloudwatch Logsのサブスクリプション設定

Cloudwatch LogsからElasticsearch Serviceに対しては、便利なことにストリーミングが用意されています。
実態としてはLambda関数が自動的に作成され、Elasticsearchにログが転送されます。
ちょっと手間ではあるのですが、今回のCloudwatch LogGroup複数 対 Elasticsearch Service 1ドメインの構成ではLambda関数を少し修正する必要があります。
そのあたりの部分含めて記載していきます。

3.1 Cloudwatch LogGroupのストリーミング設定

Cloudwatchコンソールのログ画面にて、Cloudtrail、または、VPC FlowlogsのLogGroupを選択し、[アクション]⇒[Amazon Elasticsearch Serviceへのストリーミング開始]をクリックします。

3.2 ステップ 1: 宛先の選択

先ほど作成したElasticsearch Serviceのクラスターを選択します。
Lambda IAM 実行ロールはドロップダウンメニューを開き、[新しいIAMロールの作成]を選択します。

必要なポリシーについて自動的に設定されるので、そのまま[許可]をクリックします。

Lambda IAM 実行ロールに作成された[lambda_elasticsearch_execution]が設定されているので、[次へ]をクリックします。

3.3 ステップ 2: ログ形式とフィルタの設定

ログの形式はLogGroupがCloudtrailのものであれば[AWS Cloudtrail]、VPC Flowlogsのものであれば[Amazon VPC フローログ]を選択します。
そのまま[次へ]をクリックします。

3.4 ステップ 3: レビュー

そのまま[次へ]をクリックします。

3.5 ステップ 4: 確認

[ストリーミングの開始]をクリックします
「サブスクリプションフィルタが作成されました。」と表示されていればOKです。

3.6 Lambda関数のコード修正

LambdaコンソールにてLambd関数のコードを修正します。
修正点としては、Elasticsearch Serviceに投入されるインデックス名をCloudTrail、VPC Flowlogsでわけることと、action.index._typeを固定値にすることとなります。
action.index._typeがデフォルト通り、LogGroup名が入った状態だとログ転送時にリジェクトされて、うまくElasticsearch Serviceに取り込むことができませんでした。

Lambda関数「LogsToElasticsearch_【Elasticsearch Serviceのドメイン名】」を選択し、コードの61行目から79行目部分を修正します。
【修正前】

// index name format: cwl-YYYY.MM.DD
        var indexName = [
            'cwl-' + timestamp.getUTCFullYear(),              // year
            ('0' + (timestamp.getUTCMonth() + 1)).slice(-2),  // month
            ('0' + timestamp.getUTCDate()).slice(-2)          // day
        ].join('.');

        var source = buildSource(logEvent.message, logEvent.extractedFields);
        source['@id'] = logEvent.id;
        source['@timestamp'] = new Date(1 * logEvent.timestamp).toISOString();
        source['@message'] = logEvent.message;
        source['@owner'] = payload.owner;
        source['@log_group'] = payload.logGroup;
        source['@log_stream'] = payload.logStream;

        var action = { "index": {} };
        action.index._index = indexName;
        action.index._type = payload.logGroup;
        action.index._id = logEvent.id;

【修正後】

var source = buildSource(logEvent.message, logEvent.extractedFields);
        source['@id'] = logEvent.id;
        source['@timestamp'] = new Date(1 * logEvent.timestamp).toISOString();
        source['@message'] = logEvent.message;
        source['@owner'] = payload.owner;
        source['@log_group'] = payload.logGroup;
        source['@log_stream'] = payload.logStream;


        if (payload.logGroup == '/cloudtrail/trails') {
            var indexPrefix = 'cloudtrail-';
        } else {
            var indexPrefix = 'vpc-flowlogs-';
        }
        var indexName = [
            indexPrefix + timestamp.getUTCFullYear(),         // year
            ('0' + (timestamp.getUTCMonth() + 1)).slice(-2),  // month
            ('0' + timestamp.getUTCDate()).slice(-2)          // day
        ].join('.');

        var action = { "index": {} };
        action.index._index = indexName;
        action.index._type = 'logs';
        action.index._id = logEvent.id;

3.7 Lambda関数修正前のインデックスの削除

Lambda関数修正前のインデックスを削除しておきます。

curl -X DELETE '【Elasticsearch Serviceのエンドポイント】/cwl-YYYY.MM.DD'

【戻り値】

{"acknowledged":true}

3.8 その他LogGroupに対してストリーミング設定

項3.1から3.5と同様に未設定のLogGroupに対してストリーミング設定を実施します。

4. Kibanaダッシュボードでのインデックスパターンの作成

Kibanaダッシュボードにてデータを表示させるにはインデックスパターンを作成する必要があります。

4.1 CloudTrail用インデックスパターンの作成

サイドバーの[Management]⇒[Index Pattern]とクリックします。

4.2 Step 1 of 2: Define index pattern

初期状態では Create index patternの画面に遷移しますので、Index patternに[cloudtrail-*]と入力し、[Next step]をクリックします。

4.3 Step 2 of 2: Configure settings

Time Filter field nameに[@timestamp]を選択し、[Create index pattern]をクリックします。

インデックスパターンを作成できました。

4.4 VPC Flowlogs用インデックスパターンの作成

上記、4.1-4.3と同じ要領でVPC Flowlogs用インデックスパターンを作成します。
4.2のIndex patternは[vpc-flowlogs-*]を入力します。

ログデータが表示出来ることの確認

サイドバーの[Discover]をクリックします。
ログデータを取得、表示できていることが確認できるかと思います。

あとはVisualizeするなり、Dashboardを作るなり、やっていきましょう。

最後に

Amazon Elasticsearch Serviceは簡単に作れて、ログ集約、分析、可視化にとても有効なツールだなと感じています。
ただ、仕様として手戻りが発生するようなお作法があるので、もう少し触っていくとまた何かありそうですが、今日はこの辺にしておきたいと思います。

どなたかの助けになれば幸いです。

技術一課の杉村です。AWS Client VPN が東京リージョンにやってきました。

AWS Client VPN がアジアパシフィック (ムンバイ) と アジアパシフィック (東京) の 各AWS リージョンで利用可能に

特にエンタープライズのお客様にとっては、社内のシステムとリモートにいるクライアントPCを繋ぐいわゆるクライアントVPNはなじみ深いものです。

「ふむ、AWS Client VPNが東京リージョンに来たのか。検証しとくか！」と思いたちいざ触ってみると、初見では結構わかりづらい部分がありました。一度理解してしまえば簡単にクライアントVPNを実現できますので、AWS Client VPNの概念、そして実際の設定手順を解説してみたいと思います。

1. ざっくりポイント

AWS Client VPN のポイントを記載します。

• VPC上に Client VPN Endpoint を作成することで、クライアント（普通のPCなど）とVPCの間でVPNを張ることができる
• OpenVPN （オープンソースのVPNソフトウェア）を利用
• 認証には “Active Directoryによるアカウント管理“, “サーバ証明書・クライアント証明書による相互認証“, “その両方” を利用できる
  • Active Directory認証では AWS Directory Serviceを利用。オンプレのADと連携したい場合は AD Connectorを噛ませることで可能
• 利用料金は「(A) Client VPN Endpoint に関連付けられているサブネットの数 × 利用時間(hrs)」と「(B) アクティブなクライアント接続の数 × 利用時間(hrs)」に対して発生
  • 基本料金(A)と接続時間に応じた従量料金(B)のようなイメージ
  • AWS VPN の料金

2. AWS Client VPN のアーキテクチャ（構成図）

証明書を利用した「相互認証」の場合を記載しています。

Client VPN Endpoint (①)を作成し、VPCのサブネット（1つまたは複数）に紐づけます。

認証に利用するサーバ証明書・クライアント証明書を AWS Certificate Manager (②)、通称 ACM に登録しておきます。
クライアント(③)にはOpenVPNクライアントをインストールし、クライアント証明書を配置します。

Client VPN Endpointの設定時にクライアントに割り当てるIPアドレスレンジを予めCIDR形式で指定するのですが「/22」以上の割り当てが必須です。（1022ホスト分ですね）

VPN接続が確立されると、クライアントPCはVPCのネットワークの一員として組み込まれ、プライベートIPが割り当てられます。VPC上のNAT Gatewayやプロキシサーバ、セキュリティ系の仮想アプラインスを通じてインターネットにアクセスさせることも可能です。

なおClient VPN経由でVPC内のリソースにアクセスするとき、接続元IPはClient VPN EndpointのENIのものになります。つまりクライアントからの通信は Client VPN Endpoint でいったんNATされているということ。SG設計にてポイントになります。

AWS Client VPN の構成要素の詳細な解説は、下記をご参照ください。
Client VPN のコンポーネント

3. セットアップしてみる

今回は証明書を利用した相互認証のパターンでセットアップしてみます。（Active Directory認証のパターンは、また後日検証してみます）

3-1. サーバ証明書・クライアント証明書の作成

下記の手順で、簡単にオリジナルのサーバ証明書・クライアント証明書が作成できました。
クライアント認証と認可
私は、Windows PCを利用していますので検証用AWSアカウントのEC2(Amazon Linux 2)で上記手順を実施しました。

上記の証明書作成作業をVPN接続を実施するクライアントPCとは別のマシン上で行う場合（今回の私がそうですね）、証明書および秘密鍵ファイル（上記ドキュメントではclient1.domain.tld.crtおよびclient1.domain.tld.key）はクライアントPCにセキュアな方法で転送しておいてください。

また、作成したサーバ証明書・クライアント証明書を AWS Certification Manager (ACM)に登録する必要があります。
前述の公式ドキュメントではAWS CLIを利用していますが、AWSマネジメントコンソールを利用してGUIでも簡単にインポートができます。（作成した証明書本体と、秘密鍵をテキスト情報で入力します。）
AWSマネジメントコンソールを利用した証明書のACMへのインポートの方法は、下記の弊社ブログをご参照ください。

ACMに証明書をインポートしてお手軽に証明書利用

3-2. Client VPN Endpoint の作成

AWSマネジメントコンソールにログインし下記の手順で Client VPN Endpoint を作成します。おなじみの「VPC」の画面から作成できます。
ステップ 2: Client VPN エンドポイントを作成する

エンドポイントの管理用の名前を決めたり、クライアントに割り当てるIPアドレスのCIDRを入力します。
利用するサーバ証明書・クライアント証明書を選択します。（ACMに登録された証明書を選択することができます）

クライアント接続のログを CloudWatch Logs に残すかどうかも選択できます。予め CloudWatch Logs にてロググループ、ログストリームを作成しておく必要があります。（詳細は割愛）

またオプションパラメータとしてクライアントが使用するDNSサーバやTLSセッションにTCP/UDPのどちらを利用するかを選択することができます。（今回はデフォルトのまま）

なお Client VPN Endpoint を作成した時点ではまだ利用料金は発生しません。
次の 3-3 でサブネットに紐づけた時点で、前述の料金(A)が発生し始めます。

3-3. Client VPN Endpoint をVPCのサブネットに紐づける

紐づけたサブネットに Client VPN Endpoint のENIが作成されます。ENIが作成された時点で料金が発生します。
ステップ 3: クライアントの VPN 接続を有効にする

ここで関連付けるサブネットは、1つでも複数でも構いませんが、複数のサブネットを紐づけると、紐づけた数だけの料金（前述の(A)です）が発生します。

複数紐づける理由は可用性のためです。アベイラビリティゾーン(AZ)障害などで一つのサブネットが利用不可になってもクライアントからの接続が利用できるようにするためです。そのため複数紐づける場合には、それらのサブネットは別々のAZに属している必要があります。

サブネットを紐づけると Client VPN Endpoint には自動的にそのVPCのデフォルトセキュリティグループがアタッチされます。通信元/先IPアドレスやポートを制限したい場合は、別のセキュリティグループをアタッチすることができます。

重要なことに、クライアントPCからVPN経由でVPC内のリソース等にアクセスすると接続元IPアドレスは Client VPN Endpoint になっています（NATされている）。接続先リソースのセキュリティグループ設計は、それを考慮する必要があります。

3-4. クライアントのアクセスの「承認」

これだけではまだ、クライアントPCからVPCへは通信できません。
クライアントPCからVPC内のどのIPレンジへの通信を許可するか、CIDR形式で許可します。
ステップ 4: クライアントのネットワークへのアクセスを承認する

マネジメントコンソールで当該 Client VPN Endpoint を選択し”認証”タブを選択すると、クライアントPCから接続可能な接続先一覧が表示され、許可を追加することができます。
デフォルトではどのCIDRも許可されていないので、接続先を追加します。
VPC内の特定のCIDRのみを許可すれば、クライアントPCからはその範囲までにしかアクセスできません。

もしNAT Gatewayや仮想アプライアンス経由でインターネットに出ることを許可したければ、0.0.0.0/0への通信を許可する必要があります。（インターネットへ抜ける方法については、それ以外にも設定が必要ですがそれは次の項）

3-5. 追加のネットワークへのアクセスを有効にする（追加設定）

Client VPN Endpoint には「ルートテーブル」の設定があります。
ステップ 5: (オプション) 追加のネットワークへのアクセスを有効にする

クライアントPCからVPC内にだけ通信するだけであればデフォルト設定でOKなので、追加設定は不要です。
クライアントPCから「NAT Gateway経由でインターネットに接続させる」あるいは「VPC Peering経由で別のVPCに接続させる」などのルートを設定したいときだけ、追加設定が必要です。

Client VPN Endpoint のルートテーブルの概念はちょっと理解が難しいので例で説明します。

Client VPN Endpoint のルートテーブルのレコード追加時には「宛先のCIDR」「ターゲットサブネット」の2つを指定します。
“宛先のCIDR=0.0.0.0/0, ターゲットサブネット=subnet-01234567890abcdef” を追加したとしましょう。

この場合、クライアントPCがVPN経由で インターネット上のWebサーバに接続しようしてVPN経由でパケットが Client VPN Endpoint にまで到達すると、その後パケットは subnet-01234567890abcdef を経由して、そのサブネットのルートテーブルに従います。
subnet-01234567890abcdef のルートテーブルに「0.0.0.0/0 -> NAT Gateway」というルートがあれば、NAT Gateway経由でインターネットに接続しにいきます。あるいは「0.0.0.0/0 -> 仮想アプライアンスのENI」というルートも可能です。

また「0.0.0.0/0 -> Internet Gateway」というルートも可能のようですが、VPCの設定で「パブリック IPv4 アドレスの自動割り当て : true」である必要があります。これは Client VPN Endpoint のENIがパブリックIPを持つ必要があるからでしょう。

（デフォルトでは Client VPN Endpoint にサブネットを紐づけた時点で “宛先のCIDR=<対象VPCのCIDR>, ターゲットサブネット=<紐づけたサブネット>” が作成され、VPC内にのみ接続させる場合はこれで十分）

つまり Client VPN Endpoint のルートテーブルは、宛先CIDRごとにパケットが経由するサブネットを定義するものと理解できます。
ただし、ターゲットサブネットは手順3-3で関連付けた「関連付けられたサブネット」の中からしか設定することができません。

もう一例、クライアントVPN→ Client VPN Endpoint → VPC-A → VPC Peering → VPC-B という経路を設定することを考えます。

Client VPN Endpoint のルートテーブルに “宛先のCIDR=＜VPC-BのCIDR＞, ターゲットサブネット=＜VPC-BへのVPC Peeringへのルートを持つサブネット＞” と設定すればよいわけです。

3-6. クライアント用のVPN Endpoint設定をDLする

クライアント用のVPN Endpoint設定をDLして、クライアントソフトに設定します。
ステップ 6: Client VPN エンドポイントの設定ファイルをダウンロードする

マネジメントコンソールで当該 Client VPN Endpoint を選択し、上部に表示される青い「クライアント設定のダウンロード」ボタンを押せばDLできます。
「.ovpn」という拡張子の設定ファイルをクライアントPCにダウンロードします。

.ovpn設定ファイル、クライアント証明書、証明書の秘密鍵をクライアントソフトの設定ファイル用フォルダに配置します。

この.ovpnファイルはテキストなので、普通のテキストエディタで開くことができます。ファイルの末尾に以下を追記します。

cert ＜クライアント証明書へのファイルパス＞
key ＜証明書の秘密鍵へのファイルパス＞

以下は例ですが、Windows PCがクライアントの場合、以下のようになります。\（バックスラッシュ）はエスケープする必要があるので2つ繋げています。

cert C:\\Users\\username\\OpenVPN\\config\\client1.domain.tld.crt
key C:\\Users\\username\\OpenVPN\\config\\client1.domain.tld.key

これで晴れて設定完了です。
クライアントソフトで接続を確立してみましょう。VPC内のリソースに接続できるはずです。

「接続」タブでクライアント接続の履歴を確認できます。

4. いろいろな経路設定

4-1. Client VPNの要素の整理

ここまでの設定手順では、いろいろな要素… ルートテーブルや承認設定、関連付けサブネットなどが出てきて、少し混乱しているかもしれません。
改めて整理をしてみます。

「サブネットの関連付け」
→VPCのどのサブネットに Client VPN Endpoint 用のENIを作成するかを指定するものです。可用性のために複数のAZのサブネットに指定することができます。（ただし1つのAZにつき1サブネットまで）

「承認」
→クライアントがどのIPレンジに接続できるか許可するものです。

「セキュリティグループ」
→ Client VPN Endpoint 用のENIにアタッチするSGです。クライアントからの通信は Client VPN Endpoint のENIでNATされるのでこのSGを接続元として、接続先のSGで制御することができます。

「 Client VPN Endpoint のルートテーブル」
→通信先の経路(CIDR)ごとに、経由するサブネットを指定するものです。ただし経由するサブネットは「サブネットの関連付け」で関連付けられたサブネットの中から選ぶことになります。例えば、0.0.0.0/0のターゲットサブネットとして0.0.0.0/0->NAT Gatewayというルートを持つサブネットを指定すれば、クライアントはNAT Gatewayからインターネットへ出られます。

4-2. 例:クライアントからVPN経由・NAT Gateway経由でインターネットに出られる設定

「サブネットの関連付け」で Client VPN Endpoint とVPCのどれかのサブネットを関連付けます。ただしそのサブネットは0.0.0.0/0->NAT Gatewayというルートを持っています。

「承認」で0.0.0.0/0を承認します。

「セキュリティグループ」にて、0.0.0.0/0に対するアウトバウンド通信が許可されたSGをアタッチします。

「 Client VPN Endpoint のルートテーブル」で、0.0.0.0/0のターゲットサブネットとして先ほど関連付けたサブネットを指定します。

4-3. 例: クライアントからVPC Peering経由で他VPCに接続する設定

「サブネットの関連付け」で Client VPN Endpoint とVPCのどれかのサブネットを関連付けます。ただしそのサブネットはVPC Peeringへのルートを持っています。

「承認」で他VPCのCIDRを承認します。

「セキュリティグループ」にて、他VPCのCIDRに対するアウトバウンド通信が許可されたSGをアタッチします。

「 Client VPN Endpoint のルートテーブル」で、＜他VPCのCIDR＞のターゲットサブネットとして先ほど関連付けたサブネットを指定します。

5. 制限事項

Client VPN機能の制約事項は以下に記載されています。
Client VPN の制約事項

重要なものを抜粋します。

クライアント CIDR 範囲は、関連付けられたサブネットが配置されている VPC のローカル CIDR、または Client VPN エンドポイントのルートテーブルに手動で追加されたルートと重複することはできません。

→ Client VPN Endpoint の作成時に指定するクライアントのCIDR範囲は、VPCとかぶってはいけません。VPC Peering経由で他VPCなどに接続させる場合は、そことかぶってもいけません。
→ なおクライアントのCIDRが 192.168.x.x/16で、VPCが10.x.x.x/16など、被っていなければクラスがまたがっていてもOKです。

上記ドキュメントに記載されていない制限事項として、以下も確認できました。

• 1つの Client VPN Endpoint に複数のクライアント証明書を登録することはできない
  • ただし作成時に登録したクライアント証明書と同一の認証機関 (発行者)から発行された証明書であれば、ACM にアップロードすることなく利用可能…これをもって証明書を追加できる
• Client VPN Endpoint に登録したクライアント証明書を入れ替える（置き換える）ことはできない
  • ただしクライアント証明書失効リスト（いわゆるCRL）は設定可能
  • 前述の証明書追加方法とあわせて、置き換えのように利用可能

6. 最後に

私が初めて AWS Clinet VPN を検証したときになかなか仕様が理解できなかったため、他の方に参考になるよう解説・参考したものになります。とくにターゲットネットワーク・ルート・承認ルール・セキュリティグループ・NATの仕様…という部分が分かりづらかったため、整理してみた次第です。

今回は証明書を利用した相互認証の方法を紹介しましたが、そのうちActive Directory認証も検証してみたいと思います。

こんにちは、マネージドサービス課の小倉です。
2019年3月からこちらの課に所属が変わりました。

今回は、EC2にマウントしているEBSのバックアップ(スナップショット)を取得していることが前提ですが、EBSをファイル単位でリストアする方法をご紹介します。
ファイルをOS内でバックアップを取得せずに致命的な編集をしてしまった場合などに使うことができます。

リストア手順

リストアする内容

Amazon Linuxの/etc/hostsファイルを例にファイル単位でリストアする方法を説明します。
まず、現在の/etc/hostsの中身を確認します。

$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
iranaisettei
::1         localhost6 localhost6.localdomain6

/etc/hostsに “iranaisettei” という変な文字列が入ってますので、これを編集前の状態に戻します。

EBSボリュームの作成

マネジメントコンソールからEC2一覧を表示し、対象のEC2のインスタンスIDをコピーします。

左メニューの「スナップショット」をクリックし、検索画面に先ほど確認した対象EC2のインスタンスIDを入力して検索します。
検索結果に表示された中から、/etc/hostsが編集される前の時間のスナップショットを選択します。

スナップショット選択して、「アクション」 – 「ボリュームの作成」をクリックします。

ボリューム作成画面が表示されます。
後ほど、ここで作成したボリュームは削除しますので、タグに文字列を入れておくと削除対象がわかりやすくなります。
タグを入力して、「ボリュームの作成」をクリックします。

ボリュームが作成されました。
「閉じる」をクリックして、ボリューム一覧に戻ります。

EBSボリュームのアタッチ

対象のEBSボリュームを選択します。

「アクション」 – 「ボリュームのアタッチ」をクリックします。

アタッチする対象のインスタンスIDを選択して、「アタッチ」をクリックします。

左メニューのインスタンスをクリックし、対象のEC2インスタンスを確認するとブロックデバイスにアタッチしたEBSボリュームが表示されます。

EBSボリュームのマウント

EBSボリュームをマネジメントコンソール上でアタッチするだけでは、OS上で使用することはできませんので、EBSボリュームのマウントが必要です。
以下の例は、マウント先の /data ディレクトリを作成して、/dev/xvdf1をマウントしています。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        231M   68K  231M   1% /dev
tmpfs           241M     0  241M   0% /dev/shm
/dev/xvda1      7.9G  1.1G  6.7G  14% /

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
┗xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
┗xvdf1 202:81   0   8G  0 part

$ sudo mkdir /data

$ sudo mount /dev/xvdf1 /data

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
┗xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
┗xvdf1 202:81   0   8G  0 part /data

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        231M   68K  231M   1% /dev
tmpfs           241M     0  241M   0% /dev/shm
/dev/xvda1      7.9G  1.1G  6.7G  14% /
/dev/xvdf1      7.9G  1.1G  6.7G  14% /data

対象ファイルのコピー

マウントしたEBSボリュームから対象ファイルを上書きコピーして、編集前の状態に戻します。

$ diff /data/etc/hosts /etc/hosts
1a2
> iranaisettei

$ sudo cp -p /data/etc/hosts /etc/hosts

$ diff /data/etc/hosts /etc/hosts

$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost6 localhost6.localdomain6

編集前の状態に戻りました。

EBSボリュームのアンマウント

OS上でEBSボリュームをアンマウントします。

$ sudo umount /data

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        231M   68K  231M   1% /dev
tmpfs           241M     0  241M   0% /dev/shm
/dev/xvda1      7.9G  1.1G  6.7G  14% /

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
┗xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
┗xvdf1 202:81   0   8G  0 part

/dataにマウントされていた /dev/xvdf1がアンマウントされました。

EBSボリュームのデタッチ

マネジメントコンソールでEC2を表示します。
左メニューのボリュームをクリックし、対象のEBSボリュームを選択します。
「アクション」 – 「Detach Volume」をクリックします。

「デタッチする」をクリックします。

EBSボリュームの削除

左メニューのボリュームをクリックし、対象のEBSボリュームを選択します。
「アクション」 – 「Delete Volume」をクリックします。

「はい、削除する」をクリックします。

EBSボリューム一覧から表示が消え、EBSボリュームが削除されました。

まとめ

ファイルを編集するときはOS内でコピーを取得してから実施したほうがよいですが、想定外の事象などでどうしてもバックアップ(スナップショット)からファイル単位でリストアしなければならないときは、こちらの復旧方法を検討してみてはいかがでしょうか。

また、Windowsの場合は、EBSボリュームをマウントする手順が異なりますが、その他は同様の手順で実施可能です。以下、WindowsでEBSボリュームをマウントする手順になります。
Windows で Amazon EBS ボリュームを使用できるようにする

最近フラットデザインぽくなったRStudioのAmazon Linux 2へのインストール方法です。

まあ、これといって特筆すべき手順はありませんが、メモ程度に書いておきます。

Rインストール

Rをインストールしなければ始まりません。

amazon-linux-extrasかyumでインストールできます。

amazon-linux-extrasで

amazon-linux-extrasでインストールすることもできますがバージョンちょっと古いかもしれません
2019/06/10現在は3.4が使えました。

インストールできるバーっジョンの確認

$ amazon-linux-extras list | grep R
 9  R3.4                     available    [ =3.4.3 ]

インストール

$ sudo amazon-linux-extras install R3.4 -y

yumで

Amazon Linux 2でslコマンドをつかいたい のslと同様に標準のリポジトリにはRがありませんEPELリポジトリを有効化するとインストールすることができます。こちらは3.5が使えました。

有効化&バージョン確認&インストール

$ sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
$ yum list R
R.x86_64    3.5.2-2.el7    epel
$ sudo yum install R -y

RStudioインストール

公式のWebサイトのRedHat/CetOSの手順に従えばOKです。

まとめ

いかがでしたでしょうか？

まあ特に困ることはないと思います。

初めに

Amazon Connectを組み合わせたシステム開発をする際に以下のような場面に遭遇することがあります。

1. 録音されたオーディオファイルを聞きたい
2. 録音されたステレオファイルをデュアルモノファイルに変換したい（※）

※Amazon Connectで録音されたオーディオファイルはステレオファイルです。オペレータとお客様の声がLRチャネルになっています。

本記事ではそれらの解決方法のひとつとして波形編集ソフトによる操作をご紹介します。

波形編集ソフトのご紹介とオーディオファイルを聞く方法

世の中には多くの波形編集ソフトがありますが、ここではオープンソースソフトウェアであるAudacityをご紹介します。
インストール方法については配布元の情報をご参照ください。

以下の画面例ではAudacityにステレオファイルを読み込んでいます。
再生ボタンをクリックすることでオーディオファイルを聞くことができます。

Audacityでステレオファイルをデュアルモノファイルに変換する方法

以下の手順でデュアルモノファイルに変換することができます。

1. ファイル横の▼の箇所をクリックします（メニューが表示されます）
   
2. メニューの「ステレオからモノラルへ(n)」をクリックします（ファイルがモノラルファイル×2に分離されます）
   
3. 上部バーの「ファイル(F)」→「複数ファイルの書き出し(M)」をクリックします（LRチャネルがそれぞれモノファイルとして出力されます）
   

普段ご利用いただいているタイマートリガージョブを、設定している日付/曜日/時間に関係なく、いつでも実行できる機能をを、β版として Cloud Automator に追加しましたのでお知らせ致します。

（ 正式版のリリースは2019年6月下旬を予定しております )

タイマートリガーの「今すぐ実行」機能について

従来ですと、タイマートリガージョブの動作確認 ( 操作対象のリソースが正しいかどうか等 ) をしたい場合、ジョブ編集画面でトリガーの「実行日付/曜日」や「実行時間」を、例えば現在時刻より1分先の時刻をセットするなど、実行のタイミングを調整してジョブの実行結果を確認する必要がございました。

今回 Cloud Automator に追加されたタイマートリガーの「今すぐ実行」機能をご利用いただくことで、ジョブに設定されている日付や曜日や時間に関係なく、任意のタイミングでジョブを実行することができるので、上記のような動作確認にかかる手間を軽減することができます。

ご利用方法

運用ジョブ一覧画面で、タイマートリガージョブの右端にあるボタンをクリックした後に表示される「今すぐ実行」ボタンをクリックすると、任意のタイミングでタイマートリガージョブを実行することができます。

「今すぐ実行機能」について、詳細なご利用方法はマニュアルを用意しておりますのでご参照ください。

終わりに

今後のリリース計画については、ロードマップページにて公開しております。
これからも Cloud Automator をよろしくお願いいたします。

Cloud Automator(クラウドオートメーター)とは、ノンプログラミングでAWS運用を自動化し、AWSの利用を最大限に引き出すサービスです。バックアップや災害対策、AWS費用の削減を実現する「ジョブ」と、AWSがガイドライン通りに運用されていることを継続的に確認する「構成レビュー」という2つの機能をご提供しております。

技術三課の鎌田です。
WorkSpacesの構築が完了し、いざ接続という状況になった際、接続手順が分からないという声をいただくケースが増えてきましたので本ブログにて手順をまとめたいと思います。
こちらのブログでは、AD Connectorを想定した手順を記載しています。
Simple ADもしくはMSAD for Directory Service(既存のActive Directoryのユーザーとは別のユーザーを使った接続)とは一部手順が異なるため、そちらの手順を記載した記事をご参照ください。

WorkSpacesにログインするための事前準備

事前準備として、以下のものをご用意ください。

• デバイス認証を利用する場合は、デバイス認証用の証明書ファイル (デバイス認証を設定していない場合は不要です。)
• WorkSpacesにログインするためのユーザー名とパスワード
• WorkSpacesの登録コード ※通常、管理者の方より共有されます

1. サーバー証明書をインストールする

サーバー証明書を利用しない場合は必要ない手順のため、「2. WorkSpacesクライアントのダウンロード」から手順を進めてください

1-1. 証明書のファイルをダブルクリックします

1-2. 保存場所を確認されるので、「現在のユーザー を選択」を選択し、「次へ」をクリック

1-3. インポートする証明書ファイルが表示されますが、デフォルト表示のままで「次へ」をクリック

1-4．共有された 証明書のパスワードを入力し、「次へ」をクリック

1-5． 証明書ストアを選択する画面になりますが、デフォルト表示のままで「次へ」をクリック

1-6. 「完了」をクリックし、インストールを完了させます

1-7.「証明書は信頼されていません」と表示された場合は、「はい」をクリックしてインストールを続行してください

2. WorkSpacesクライアントのダウンロード

2-1. クライアントダウンロードページにアクセスし、ダウンロード

https://clients.amazonworkspaces.com/にアクセスします。WorkSpacesのクライアントをダウンロードするページになるので、インストーラーをダウンロードします

2-2. WorkSpacesクライアントのインストール

ダウンロードしたWorkSpacesクライアントをダブルクリックし、インストールを実施します。
デフォルトのまま進めればOKです。
インストール時には、管理者権限が必要ですのでご注意ください。

3. クライアントに初期設定を実施し、WorkSpacesにアクセス

3-1. WorkSpacesのクライアントを起動し、右上の歯車マークをクリックし、メニューより「Advanced Setting」をクリックします

3-2. 「Select a language:」で「日本語」を選択し、左下の「Save」をクリックします。

3-3. 管理者から共有された登録コードを入力し、「登録」をクリックします

c

3-4. ユーザー名とパスワードを入力し、サインインをクリックします

3-5.「このアカウントを記憶しますか？」と表示されますので、「はい」をクリックします。

3-6. WorkSpacesへのログインが完了すると、Windowsの画面が表示されます

まとめ

WorkSpacesの接続手順は少し分かりづらい部分もありますが、こちらの手順を参考に実施いただければ幸いです。

技術三課の鎌田です。
WorkSpacesの構築が完了し、いざ接続という状況になった際、接続手順が分からないという声をいただくケースが増えてきましたので本ブログにて手順をまとめたいと思います。
こちらのブログでは、Simple ADもしくはMSAD for Directory Serviceを想定した手順を記載しています。
AD Connector(既存のActive Directoryのユーザーを使った接続)の場合は一部手順が異なるため、そちらの手順を記載した記事をご参照ください。

WorkSpacesにログインするための事前準備

事前準備として、以下のものをご用意ください。

• デバイス認証を利用する場合は、デバイス認証用の証明書ファイル (デバイス認証を設定していない場合は不要です。)
• amazonworkspaces.comから届いたメール

メールについては、管理者がWorkSpacesを割り当てたタイミングで、お手元に届きます。接続に必要な情報が記載されていますので、必ずご用意の上、以下の手順に進んでください。

1. サーバー証明書をインストールする

サーバー証明書を利用しない場合は必要ない手順のため、「2. パスワードの初期設定とWorkSpacesクライアントのダウンロード」から手順を進めてください

1-1. 証明書のファイルをダブルクリックします

1-2. 保存場所を確認されるので、「現在のユーザー を選択」を選択し、「次へ」をクリック

1-3. インポートする証明書ファイルが表示されますが、デフォルト表示のままで「次へ」をクリック

1-4．共有された 証明書のパスワードを入力し、「次へ」をクリック

1-5． 証明書ストアを選択する画面になりますが、デフォルト表示のままで「次へ」をクリック

1-6. 「完了」をクリックし、インストールを完了させます

1-7.「証明書は信頼されていません」と表示された場合は、「はい」をクリックしてインストールを続行してください

2. パスワードの初期設定とWorkSpacesクライアントのダウンロード/インストール

amazonworkspaces.comから届いたメールを利用しますので、準備しましょう

2-1. メール本文にある「1.ユーザーのプロファイルを入力し、・・・」のリンクをクリックします

2-2. パスワードを入力し、「ユーザーの更新」をクリック

※パスワードは、英小文字大文字、数字、記号をいずれも1文字以上含む、全体で8文字以上にする必要があります

2-3. WorkSpacesのクライアントをダウンロードするページになるので、インストーラーをダウンロードします

2-4. WorkSpacesクライアントのインストール

ダウンロードしたWorkSpacesクライアントをダブルクリックし、インストールを実施します。
デフォルトのまま進めればOKです。
インストール時には、管理者権限が必要ですのでご注意ください。

3. クライアントに初期設定を実施し、WorkSpacesにアクセス

3-1. WorkSpacesのクライアントを起動し、右上の歯車マークをクリックし、メニューより「Advanced Setting」をクリックします

3-2. 「Select a language:」で「日本語」を選択し、左下の「Save」をクリックします。

3-3. 先程のメール本文にある登録コードを入力し、「登録」をクリックします

3-4. ユーザー名とパスワードを入力し、サインインをクリックします

3-5.「このアカウントを記憶しますか？」と表示されますので、「はい」をクリックします。

3-6. WorkSpacesへのログインが完了すると、Windowsの画面が表示されます

まとめ

WorkSpacesの接続手順は少し分かりづらい部分もありますが、こちらの手順を参考に実施いただければ幸いです。

CS課佐竹です。

はじめに

本日は、AWSの認定試験について記載します。
認定試験と言いましても、何かの認定試験対策のブログではなく、合格すると貰えてしまう特典の具体的な使い方をお伝えします。

AWS の認定試験に受かって得られる金銭的な利点

以下、公式サイトに紹介があります通り、AWSの認定を得ることで様々なメリット(ベネフィット)を得られます。

AWS 認定個人に対する利点
https://aws.amazon.com/jp/certification/benefits/

この中に記載があります、金銭的に素晴らしい利点と言えるのは以下の2つでしょう！以下の2つは、AWSの認定試験に1つでも合格すれば、その資格を得た時に同時に得られるものです。

1. 無料の模擬試験
2. 模擬試験のバウチャーを使用して次回試験の割引 (実際は資格試験を50%オフで受験可能とするもの)

今回はこの2つの金銭的なメリットにフォーカスし、かつ実際に無料で模擬試験を受ける方法までご紹介します。

自分が持っている特典の確認方法

先に「APNポータルのサインイン画面」から、「現在自分自身が保持している特典を確認する方法」をご説明します。これ自体が結構ややこしい上に、たどり着く方法が定期的に変化するので、2019年6月現在の手法とご理解くださいませ。

APNポータルにサインインしてAWS認定画面まで移動する

まずは、以下の画面からAPNポータルにサインインします。URLリンクは「こちら」です。

サインインができましたら、画面上のメニューの左から3つ目にある「Training」タブを選択してください。

そうしたら表示される3つのうちの、画面真ん中にある「AWS Training」において最下部の「Learn more」を押下してください。そうすると、新しい画面が立ち上がり以下の「トレーニングライブラリ」という画面に自動的にジャンプします。

この画面が開きましたら、次に「認定」を押下して先に進みます。すると次は以下の画面が表示されます。

この画面が現れたら、「アカウントに移動」を押下してください。すると、また新しい画面が開いて、やっと「AWSの認定」の画面に到着します。以下がその画面となります。

無事に移動できましたでしょうか。ここまで結構遠い道のりでした。

AWS認定画面から特典を確認する

ここまで来たら後は特典を確認するだけです。以下の画像の赤枠で囲っている「特典」のタブを押下しましょう。

そうすると、以下の通り特典が表示されます。

赤枠は、「AWS Free Practice Exam Voucher」で、これが「無料の模擬試験」に当たります。今回はこれを実際に使ってみたいと思います。なお(上の画像では省略していますが)、「50% Discount on your next Exam」は最下部にあり、これが「模擬試験のバウチャーを使用して次回試験の割引」になります。公式ドキュメントには「模擬試験のバウチャーを使用して」とありますが、実際は単純に「次のAWS認定試験を半額(50%オフ)で受けれる」という特典になっています。使い方は今から説明する「AWS Free Practice Exam Voucher」と同じになりますので、今回はこちらの使い方は省略とさせて頂きます。

特典コードを利用して模擬試験を無料で購入する

さっそく、AWS Free Practice Exam Voucherを利用してみましょう。今回のブログでは実際に「支払い」までやってみます。
さて、まずは今回特典を申請したいBenefitの右端の「特定を申請する」を押下しましょう。ちなみに、赤枠は「既に利用済の特典」になります。

「特典を申請する」を押下すると、次の瞬間には即時コードが表示されます。実際に表示してみましょう。

このコード、他人に知られてしまうのは良くないと思いますので、未使用のものは取り扱いには気をつけてください。上画像にあるコードは既に利用済なので、今回は画像を処理せずそのまま表示しています。
特典コードが得られましたら、次は実際にこれを支払いで利用します。受験の申し込みは、以下の一覧から選択を行います。ここは特に手順に変更はありません。コードは支払い時に利用します。

受けたい試験を選んでください。利用したい特典は「AWS Free Practice Exam Voucher」になっていますので、「AWS Practice Exams」の中から、プラクティス試験を選択します。今回は「AWS Certified Cloud Practitioner Exam – Practice」を選択することにしました。

Practice試験は、オンラインの試験となり自宅からでも受験可能です。支払いは「受験料の支払い」から行います。

言語を選択しましょう。言語を選択したら「続行」します。

支払いの画面に遷移します。すると上画像の通り「バウチャー/割引クーポン」を入力する画面が現れますので、ここに先ほど得たコードを入力してください。コードを入力したら忘れず「適用する」を押下します。

すると、Benefitsが適用され、2,000円の支払いが相殺され、0円になります。画面から値引きされていることを確認してください。

最後に「すぐに支払う」ボタンを押下しますと、上画像の通り支払いが完了します。そのタイミングで、0円が請求されていることを念のため再度確認してください。

以上で、「特典コードを利用して模擬試験を無料で購入する」説明を終わります。あとは実際に試験をオンラインで受けましょう！

まとめ

ご説明した通り、AWS認定試験に合格すると、以下の2つの金銭的なメリットを受け取れます。

1. 模擬試験が1つ無料で受けられるバウチャーコード
2. 資格試験が1つ50%オフで受けられるバウチャーコード

また、この2つは「同時に」受け取れます。そのため、「次に受けたいAWS認定試験の模擬試験を無料で受験」し、さらに追加で「実際のAWS認定試験も1回は半額で受験可能」なのです。この利点は特に高額な試験ほどメリットとなります。Pro試験やスペシャリティ試験は模擬試験が4,000円+税、実際の試験も30,000円+税ですため、個人には特に大きな負担になります。このバウチャーを有効活用すると、模擬試験が無料となり4,000円が浮き、さらに本番試験を一発合格すれば、負担は全部で15,000円+税だけで済みます。お金に困っているそこのアナタ！まずは1つでも認定試験を突破し、この特典を有効活用して効率的に試験を受けて行っては如何でしょうか！

ちなみに私は、現在以下の通り特典を保持しています。

なんと、模擬試験が1つ無料で受けられる特典は残り8個、資格試験が半額で受けられる特典は9個も残っています。そうです、私は最近までこの特典の存在を知らなったので、溜まりに溜まってしまいました。参考までに、そんな私が過去受けてきたAWS認定試験の履歴は以下の通りです。

私のように、特典を溜めに溜めてしまった人は、会社の他の人に「使ってもらう」のも手だと思いましたが他人に譲渡できるかは不明です。ただ、AWSは認定試験を次から次に増やしてきてもいますので、この特典を今後は有効活用して、効率的に取得していきたいと思います。

以上です！特典、みんなも使っていきましょう！

CS課佐竹です。

既に皆さまご存知かもしれませんが、AWSの公式ブログ（日本語版はこちら）にて表題の件のアナウンスがありましたのでご連絡いたします。また本ブログでは、「S3がSigV2を利用しているかどうか」を調べるための方法も合わせて記載いたします。

要約

1. S3のSigV2のサポートは、2019年6月24日に終了することはなくなりました
2. 2020年6月24日以降に作成された新しいS3バケットではSigV2署名付きリクエストをサポートしていません
3. 2020年6月23日以前に作成された既存のS3バケットは引き続きSigV2をサポートします

これを受けて利用者はどのようにすべきか

もともとのアナウンスにあったのは、2019年6月24日に署名バージョン2を利用した認証がS3で利用できなくなる、というものでした。これを受け、S3を利用しているユーザは、署名バージョンを2から4に変更する必要がありました。
※以後、ここでは基本的に署名バージョン2をSigV2、署名バージョン4をSigV4と記載します

署名バージョン2について詳しく知りたい方は、以下の公式ドキュメントをご覧ください。

付録 B: リクエストの認証 (AWS 署名バージョン 2)
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/auth-request-sig-v2.html

署名バージョン4についての変更点は以下の公式ドキュメントをご覧ください。

AWSAPI リクエストの署名 » 署名バージョン 4 署名プロセス » 署名バージョン 4 の変更
https://docs.aws.amazon.com/ja_jp/general/latest/gr/sigv4_changes.html

今回のアナウンスで、6月24日のSigV2の廃止は見送られることになりました。そのため、既存のS3バケットでは特に問題が出ないということになったため、急ぎの対応(SigV4への切り替え対応)をする必要がなくなりました。しかし「2020年6月24日以降に作成された新しいS3バケットではSigV2署名付きリクエストをサポートしません」という点で注意が必要です。それは、「既存の仕組みを利用し、新しく作成されたバケットに同じ仕組みを適用する」タイミングで、既存の仕組みがSigV2による実装を行っていた場合は、新しいバケットでだけ処理が失敗するということが起きてしまいます。
このような場合「今までうまくいっていたのに、急に動かなくなってしまった」となりますので、問題の切り分けが難しい場合もあるかと思われます。そのため、SigV4への強制的な切り替えはなくなったものの、基本的には仕組みはSigV4へ切り替えをされたほうが良いと考えます。実際、AWSのブログでもSigV4への切り替えを引き続き推奨しています。

SigV4をS3で利用しているのか調査する方法

何社か、お客様より対応方法についてお問い合わせを受けましたため、私が実際に調査した方法をお伝えします。参考にしていただければ幸いです。
以下の簡単なステップで確認が可能です。お客様によっては既に完了されているステップもあるかと存じますため、その場合は「4」から確認されるなどステップを飛ばして頂いて問題ございません。

1. CloudTrailを有効にします
2. CloudTrailでAmazon S3 オブジェクトレベルの API アクティビティの記録を有効にします
3. S3のアクティビティがCloudTrailのS3バケットに保存されるのを待ちます
4. AthenaでAmazon S3  オブジェクトレベルAPIのアクティビティから署名バージョンを分析します

以下で、それぞれのステップを説明いたします。

1. CloudTrailを有効にします

皆様 CloudTrail はOnにされているでしょうか？弊社のお客様には、証跡管理のためにほぼ必ずとOnにして頂いております機能となります。恐らくですが、多くのご利用者様ではOnになっていると考えられますため、ここでは詳細な設定方法についてはご案内致しません。未設定の場合ですが、以下の公式ドキュメントを参照し、ご設定ください。

AWS CloudTrail » ユーザーガイド » CloudTrail の使用開始 » お使いの AWS アカウントにおける証跡の作成 » コンソールで証跡を作成および更新する » 証跡の作成
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html

2. CloudTrailでAmazon S3 オブジェクトレベルの API アクティビティの記録を有効にします

この機能は2016年11月にアナウンスされた機能で、意外にも多くのユーザ様が設定されていないように見えます。この機能はリリースと同時に「CloudTrailの利用者には自動的に有効化」されたわけではなく、各利用者様側で追加で有効化していただく必要があります。そのため、今回の調査を行われる場合は以下念のためご確認ください。
補足として、この設定を有効する場合における懸念点ですが、S3のAPIアクティビティの量は膨大です。そのためCloudTrailのS3利用料が少々今まで以上に増加すると想定されます。S3の利用料は非常に安いものですが、利用料が気になる場合は、本調査が完了した後にオフにされても問題ございません。

CloudTrail の更新 – Amazon S3 オブジェクトレベルの API アクティビティのキャプチャと処理
https://aws.amazon.com/jp/blogs/news/cloudtrail-update-capture-and-process-amazon-s3-object-level-api-activity/

この機能がリリースされるまで、CloudTrailはS3の操作は「バケット単位」でのみ履歴を保持していました。つまり、Create Bucketなど、バケットを作成するようなイベントは記録されていたのですが、S3のオブジェクト操作である「GetObject、DeleteObject、PutObject」などの API オペレーション は履歴に保持されていませんでした。これを有効化することができる機能がこちらになります。このようなイベントをAWSでは「データイベント」と呼んでおり、これらのデータイベントを保存するにはS3とLambdaそれぞれで有効化が必要となります。なお本調査ではS3のオブジェクト操作をAthenaにて検索しますため、この設定が必ず必要になってきます。

証跡のデータイベントと管理イベントのログ記録：データイベント
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/logging-management-and-data-events-with-cloudtrail.html#logging-data-events

上記URLリンクに実際の設定方法が記載されていますが、以下参考までに画面キャプチャも添えておきます。

マネジメントコンソール上での設定方法

マネジメントコンソールから、CloudTrailの画面を表示します。Trailsを表示したら、設定済のCloudTrailを選択します。

赤枠で囲ってあるCloudTrailのNameを選択すると設定詳細画面に遷移します。

詳細設定の画面に遷移すると、「データイベント」の画面が現れます。何も設定されていない場合、上画像の通りの画面表示になるりますので、ここで「Configure」ボタンを押下して設定を進めます。

Configureを押下すると、上画像が表示されます。ここで「特定のバケットだけにデータイベントのロギングを設定する」ということもできますが、今回は全てのS3バケットに設定を行います。

「Select all S3 buckets in your account」にチェックを入れ、「Save」を押下します。

上の通り保存されましたら、S3のデータイベントのロギング設定は完了です。設定完了直後から、CloudTrailがS3のデータイベントを保存し始めます（過去に遡って実行ログの履歴を保存し直してくれることはありません）。

3. S3のアクティビティがCloudTrailのS3バケットに保存されるのを待ちます

先ほど「2」の設定を実施頂いたアカウントでは、実際のオペレーションが行われることで、「S3のオブジェクトレベルの API アクティビティ」がCloudTrailのS3バケット内に溜まるのを待つ必要があります。通常のオペレーションでは、1か月ほどのサイクルを待てば十分と考えますため、30日程度待って頂くのが良いと考えております。
既に前から「1」の手順も「2」の手順も完了しており、分析に十分なログが既にCloudTrailのS3バケットに保存されているユーザは次のステップに進んでください。

4. AthenaでAmazon S3  オブジェクトレベルAPIのアクティビティから署名バージョンを分析します

やっと調査の本題です。ただ、ここからはSQLを利用しますので、SQLになれていない方は少々戸惑われるかもしれません。ですがやってみると意外に簡単なので、一度お試しください。

分析用のテーブルを作成する

まずは、公式のドキュメントに則り、AthenaでCloudTrailのS3バケットを分析するテーブルを作成します。

Amazon Athena » ユーザーガイド » AWS のサービスのログのクエリ » AWS CloudTrail ログのクエリ
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/cloudtrail-logs.html

公式ドキュメントにある「次の DDL ステートメントをコピーして Athena コンソール内に貼り付けます。」以下にあります「CREATE EXTERNAL TABLE cloudtrail_logs ～」から始まるのがそれになります。なお、このCreate Table DDLをお客様の環境に応じて変更すべき点は以下の2つです。

1. 必須変更項目
LOCATION ‘s3://CloudTrail_bucket_name/AWSLogs/Account_ID/‘;

s3:// 以下は、S3のバケットのフォルダを指し示す必要があります。この設定通りに実行しても、S3のバケット名と、アカウントIDが不一致となりSQLは失敗します。修正のコツは以下の通りです。

1. まずは「CloudTrail_bucket_name」を実際のSQLのバケット名に変更する
2. 「Account_ID」を分析対象のアカウントIDに変更する
3. 1と2の変更だけでは検索対象が多すぎるため、リージョンと年月日を絞り込む。具体的には「’s3://cloudtrail-satake/AWSLogs/111122223333/CloudTrail/ap-northeast-1/2019/06`」とする

特に重要なのは「3」です。CloudTrailのS3バケットには、「過去全ての操作履歴」が残っているようになっていますので、アカウントID配下の全てのデータにSQLを実行してしまうと、すさまじいレコード数になり、SQLのレスポンスが返ってこなくなるほど遅くなります。そのため、特定のリージョンと年月日を絞り込まれるべきです。今回は1か月分の調査を目的としているため、2019年の6月を対象フォルダとしました。

2.推奨変更項目
CREATE EXTERNAL TABLE cloudtrail_logs

2つ目はテーブルの名称です。同じ名前のテーブルは2つ作成できないため、今回であれば「cloudtrail201906_tokyo_logs」などと、後からみてもわかりやすいテーブル名に変更しましょう。変更した点はリージョンと年月ですので、その2つを明示的にテーブル名に含めていきます。なおテーブル名には -(ハイフン) が利用できません。ですのでテーブル名にap-northeast-1を入れようとするとエラーになります（Athenaあるあるネタの1つです）。そのため、tokyoと記載したり、ap_northeast_1としたりして、これを回避しましょう。

上記変更を行ったDDLでテーブルを作成します。ここまできましたら、あとは作成したテーブルに対してSQLを実行するだけです。

調査用SQLを実行する

作成したテーブルにおける、「additionaleventdata」というカラムに、SignatureVersionがSigV2なのかSigV4なのか結果が保存されます。試しに以下のSQLを実行し、結果を比較してみてください。
まずは、SigV2を検索するSQLです。お試しSQLなので、数は30行に制限しています。

SELECT *
FROM "cloudtrail201906_tokyo_logs"
WHERE additionaleventdata LIKE '{"SignatureVersion":"SigV2",%'
        AND eventsource = 's3.amazonaws.com'
        AND useridentity.arn <> '' limit 30;

こうするとadditionaleventdataカラムには以下のような結果が出力されているはずです。

{“SignatureVersion”:”SigV2“,”CipherSuite”:”AES128-SHA”,”bytesTransferredIn”:0.0…

次に、SigV4を検索するSQLを試してみます。SQLの差は、数字を2から4に変更したのみです。

SELECT *
FROM "cloudtrail201906_tokyo_logs"
WHERE additionaleventdata LIKE '{"SignatureVersion":"SigV4",%'
        AND eventsource = 's3.amazonaws.com'
        AND useridentity.arn <> '' limit 30;

このSQLだと、additionaleventdataカラムには以下のような結果が出力されているはずです。

{“SignatureVersion”:”SigV4“,”CipherSuite”:”ECDHE-RSA-AES128-SHA”,”bytesTransferredIn”:0.0…

このように、additionaleventdataカラムを利用することで、実際にS3に対してSigV2が利用されているかどうかが判断可能です。ただ、多くの場合SigV2のAPIコールは多すぎます。よってSQLを改善し、どのIAM UesrやIAM Roleが実行を行っているのか？を特定するSQLを書いていく必要があります。例を以下にあげさせて頂きます。

SELECT count(useridentity.arn) AS count_arn,
         useridentity.arn
FROM "cloudtrail201906_tokyo_logs"
WHERE additionaleventdata LIKE '{"SignatureVersion":"SigV2",%'
        AND eventsource = 's3.amazonaws.com'
        AND useridentity.arn <> ''
GROUP BY  useridentity.arn
ORDER BY  count_arn DESC limit 30;

このSQLを実行すると、どの arn がSigV2を実行しているのか？というのが操作回数と共に確認可能です。実際の結果を画面キャプチャとして例として掲載いたします。
※注意：Limitを30にしているために、30行以上結果が表示されません。それ以上に結果が返る可能性がある場合はLimitを100などに増加させてください

このように、どのIAM Userがその月に何回SigV2の著名バージョンでS3に対してデータイベントを発行したのかが確認可能です。10行目と11行目にあります結果は、stsのassumed-roleの結果で、特定のInstanceがIAM Roleを経由してキックしていることがわかります。ここにはRole名とInstance idも記載されますので、EC2 InstanceがIAM Roleでキックしている場合でも拾うことが可能です。

arn (IAM User / Instance id)が判明しましたので、最初のSQLへ戻りWhere区を修正して対象 (例：IAM User) ごとに詳細な調査が可能です。以下では、 useridentity.arn に先ほど得た IAM User の1つを指定( useridentity.arn = ‘arn:aws:iam::111122223333:user/satake’ )して実行しています。この結果として「このIAM Userは具体的にどのような操作をS3に対して実行しているのか？」を確認できます。

SELECT *
FROM "cloudtrail201906_tokyo_logs"
WHERE additionaleventdata LIKE '{"SignatureVersion":"SigV2",%'
        AND eventsource = 's3.amazonaws.com'
        AND useridentity.arn = 'arn:aws:iam::111122223333:user/satake'
limit 30;

他にも様々なSQLの書き方があると思いますが、今回はここまでで調査方法については説明を終えます。

まとめ

まずは、S3のSigV2のサポートは、2019年6月24日に終了することはなくなりましたので、急な対応に追われることはなくなりました。しかし、SigV2を利用し続けるよりも、SigV4に切り替えることはAWSが未だに推奨している状況です。もしかすると、2020年以降にやはりSigV2のサポートを終了されるとも限りませんので、計画的にSigV4への切り替えを検討されることを推奨いたします。

なお、具体的な移行方法は以下の公式ドキュメントにまとまっていますので、合わせてご確認頂けますと幸いです。

署名バージョン 2 から署名バージョン 4 への移行
https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingAWSSDK.html#UsingAWSSDK-move-to-Sig4

以上になります。

技術一課の杉村です。AWS Client VPN が東京リージョンにやってきましたので、前回のブログでは解説をしてみました。

AWS Client VPN がアジアパシフィック (ムンバイ) と アジアパシフィック (東京) の 各AWS リージョンで利用可能に

先日のブログでは、そもそもの AWS Clinet VPN の概念を解説し、サーバ証明書とクライアント証明書を利用した「相互認証」のパターンの利用方法をご紹介しました。

AWS Clinet VPNを分かりやすく解説してみる

今回は「相互認証 + Active Directory認証」の組み合わせのパターンで、実際に検証してみた結果をスクリーンショット付きでご紹介します。

1. 前提

1-1. 構成図

下記のようなアーキテクチャで構成しました。

Active Directoryとして、私の検証では Simple AD を利用しました。ただし実際にはここが Managed Microsoft AD でも AD Connector でも、手順は変わらないはずです。

またクライアントPCには Windows 10 のパソコンを利用し、クライアントソフトとして下記より OpenVPN GUI v11 を利用しました。
https://www.openvpn.jp/download/

1-2. 前提作業

A. サーバ証明書・クライアント証明書を作成済みかつACMへインポート済み

前回ブログの「3-1.」までは終わっている状態、つまり「証明書の用意」「ACMへのインポート」は終わっている前提で進めます。

B. Simple AD作成済み

Active Directoryとして今回の検証では Simple AD (あるいはその他のDirectory Service)を作成済とします。
その中に、VPN接続に利用するユーザアカウントも作成済とします。

2. 設定手順

2-1. Client VPN Endpointの作成

マネジメントコンソールにて VPC ＞ クライアント VPN エンドポイント ＞ クライアント VPN エンドポイントの作成 ボタンを押下します。

下記のように「認証オプション」にて「Active Directory 認証の使用」「相互認証の使用」の両方をチェックします。
Directory ServiceのIDを選択します。
また、ACMにインポートしたサーバ証明書・クライアント証明書のARNを入力します。

以下はオプションです。
必要に応じて CloudWatch Logs のロググループ・ログストリームを選択します。（事前に作成が必要）
クライアントからの名前解決に使うDNSサーバも必要に応じて設定します。

2-2. サブネットとの関連付け

この操作を行った時点で、課金が開始されます。
これの意味については、冒頭に記載した前回のブログを参照してください。

2-3. セキュリティグループ設定

AWS Client VPN の関連付けサブネットごとにアタッチするセキュリティグループを選択します。
これの意味については、冒頭に記載した前回のブログを参照してください。

2-4. 認証(承認)設定

クライアントから許可する接続先を追加します。
これの意味については、前回の（略

なお承認設定については、AD認証ではADのグループごとに許可設定をできます。
このとき、グループはSID（ADのオブジェクトごとに割り当てられる一意のID）で指定する必要があります。

2-5. 設定ファイルダウンロード・クライアントに設定

上部の青い クライアント設定のダウンロード ボタンを押下して設定ファイルダウンロードします。

ダウンロードされる.ovpnファイルはテキストファイルです。
今回は証明書による相互認証とAD認証の併用ですので、設定ファイルに証明書へのパスを追記してあげます。

cert ＜クライアント証明書へのパス＞
key ＜秘密鍵へのパス＞

上記のように記載しますが、クライアントが Windows マシンの場合、パスの区切りはバックスラッシュ()となりますが、バックスラッシュはエスケープする必要があるため、2つ繋げることが注意点です。

証明書・秘密鍵・ovpnファイルを OpenVPN 用の設定フォルダに配置します。
OpenVPN GUI v11 をインストールしている場合、クライアントPCのデスクトップ下部の “隠れているインジケーター” から OpenVPN GUI のアイコンを右クリックし「設定」を押すことで下記のような画面が出ます。
Advanced タブから設定ファイル置き場のフォルダパスが分かります。3ファイルをこちらに配置します。

2-6. VPN接続を開始

OpenVPN GUI のアイコンを右クリックし「接続」を押下します。
ダイアログが現れ、IDとパスワードを要求されますので、接続に使用するADアカウントのIDとパスワードを入力します。
これで、接続が完了です。

3. 最後に

ひととおりスクリーンショット付きでご紹介しました。
作成・設定した各コンポーネントの意味については、冒頭に記載した前回のブログをご参照ください。

2019/06/12にAmazon Personalizeの一般提供が開始されました。

Amazon Personalize の一般提供開始と東京リージョンラウンチのおしらせ

モデル(Personalizeではレシピと呼ばれる)をトレーニングし、レコメンデーション機能が簡単に作成できるAWSサービスです。

今回はこのAmazon Personalizeをつかって、社内で利用しているピアボーナ制度(Unipos)のデータをもとに、「この人へポイントを送った人はこの人へも送っています」のようなレコメンデーションをしたいと思います。

S3に学習データ保存

今回はUniposの6か月分の投稿一覧(拍手ランキング)をPersonalizeへインポートするために加工しました。

こんな感じの5800行くらいのCSVを…

sender,receiver,sendersGroup,receiversGroup,contents,dateAndTimeOfThePost,numberOfMembersWhoClapped,numberOfClaps,pointsOfThePost,sendersEMailAddress,receiversEMailAddress,cardUrl
Foo Foo,Bar Bar,CI部,サービス開発部,"感謝感激！",XX/XX/XX XX:XX,20,30,2,foofoo@example.com,barbar@example.com,https://unipos.me/cards/xxxxx
Bar Bar,Hoge Hoge,サービス開発部,CI部,"ありがとう！",XX/XX/XX XX:XX,20,20,2,barbar@example.com,hogehoge@example.com,https://unipos.me/cards/xxxxx
...

こんな感じに加工。

"USER_ID","ITEM_ID","TIMESTAMP"
"foofoo@example.com","barbar@example.com",xxxxxxxxxx
"barbar@example.com","hogehoge@example.com",xxxxxxxxxx
...

形式についてはドキュメントを確認ください。
USER_ID・ITEM_IDとあるようにホントはIDでやるのが好ましいのかもしれませんが、今回はメールアドレスで利用しました。

こちらのCSVをS3へ保存すれば準備はOKです。

Dataset Groups作成

Personalizeでは、学習データのインポートやトレーニング(Solutionの作成)等はDataset Groupという単位で行います。

まずはDataset Groupを作成します。

Dataset Group名をいれます

Datasetのインポート

上記手順で「Next」をクリックするとそのままDatasetの設定へ移ります。

Dataset名をいれます。

Schemaを作成します。
Schema definitionはデフォルトのままとしました。

import job名をいれます。

初回利用の場合、IAMロールがないので「Create an IAM role」を選択し、IAMロールを作成します。
最低限のIAMポリシーで作成したい場合は、IAMのコンソールから作成することをお勧めします。

学習データを保存したS3パスを入力し、「Start Import」でimport jobが開始します。

Import job statusが「Active」となれば、import完了です。

Solution作成

続いてSolutionを作成します。Solutionとは、Recipeを使ったトレーニング済みのモデルのことだと思ってください。Solutionの作成はつまりトレーニングです。

Solution名を入れ、今回RecipeはManualで選択しました。
似たアイテムをレコメンドしたいのでRecipeはSIMSを選択しました。

あとはトレーニングが終わるまで待ちます。

作成したSolutionからSolution versionを確認し、Solution version statusが「Active」となればトレーニング終了です。

Campaign作成

最後にCampaignを作成します。Campaignは予測を行うエンドポイントのようなものです。

Campaign名をいれて、Solutionは先ほど作成したものを選択します。
Minimum provisioned transactions per secondはデフォルトの1としました。

しばらく待って、CampaignのStatusが「Active」となれば作成完了です。

レコメンドしてみる

実際に使用するとなると、LambdaやEC2からSDkを使用して使うことになると思いますが、マネコンからもお試し程度にレコメンドの結果をみることができます。
作成したCampaignの「Test campaign results」からそれが可能です。

実際にITEM_ID(今回はユーザーのメールアドレス)を入れてみました。

ふむ…見た感じレコメンドできているような気がしないでもないでした。
たしかに、ITEM_IDで入れたユーザーと同じ部署・プロジェクトのユーザーがレコメンドされるのである程度の精度は出ているようでした。

ちなみに今回のRecipeは、当てはまるITEM_IDがなければ人気なITEM_IDが返されるというものになっています。

まとめ

今回はUniposのデータを使いAmazon Personalizeを使用してみました。RecipeとかCampaignとか他の機械学習系のサービスでは見慣れない用語・コンポーネントが登場して戸惑いましたが、理解してしまえば簡単にレコメンデーションができるようになりました。

本記事ではEC2でRed Hat Enterprise Linux(RHEL)を用いたい場合のAMIの調べ方について、2019/6/18時点で「こうやったら良さそうという方法・留意点」についてご案内します。

8系が最近リリースされて、EC2の作成ウィザードのクイックスタートで表示されるRHELについても8系が表示されるようになりましたが、まだもうちょっと7系を利用したい・あれ過去verのAMIってどう調べたらいいんだろうと思っている方も多いはず。この記事はそんなあなたのための記事です。

なお、Cent OSのAMIの調べ方につきましては弊社の城が過去に記事を書いておりますので併せてご参照ください。

RHELの公式AMI一覧

AWSの公式ページにRHELの利用案内はあるのですが、こちらのページの[今すぐ購入する]から遷移するマーケットプレイスでは2019年6月18日時点では8系や7.6系等の最近のAMIは管理されていない・利用できないことに注意が必要です。

一方で、Redhat側でもAWSでのAMIの調べ方について記している記事があります。AMIを網羅的に調べるにあたっては同記事の方法を参照するのがよさそうです。

例えば、東京リージョンで7系のAMIを調べたい場合のコマンドの例は以下になります。

aws ec2 describe-images —owners 309956199498 —query 'Images[*].[CreationDate,Name,ImageId]' —filters "Name=name,Values=RHEL-7.?*GA*" —region ap-northeast-1 —output table | sort -r
|  2019-02-06T00:23:09.000Z |  RHEL-7.6_HVM_GA-20190128-x86_64-0-Hourly2-GP2  |  ami-00b95502a4d51a07e |
|  2018-10-17T14:14:10.000Z |  RHEL-7.6_HVM_GA-20181017-x86_64-0-Hourly2-GP2  |  ami-08419d23bf91152e4 |
|  2018-03-23T21:14:36.000Z |  RHEL-7.5_HVM_GA-20180322-x86_64-1-Hourly2-GP2  |  ami-6b0d5f0d          |
|  2017-08-08T15:45:51.000Z |  RHEL-7.4_HVM_GA-20170808-x86_64-2-Hourly2-GP2  |  ami-30ef0556          |
|  2017-07-24T15:55:34.000Z |  RHEL-7.4_HVM_GA-20170724-x86_64-1-Hourly2-GP2  |  ami-3901e15f          |
|  2016-10-26T22:33:03.000Z |  RHEL-7.3_HVM_GA-20161026-x86_64-1-Hourly2-GP2  |  ami-5de0433c          |
|  2015-11-12T21:11:15.000Z |  RHEL-7.2_HVM_GA-20151112-x86_64-1-Hourly2-GP2  |  ami-0dd8f963          |
|  2015-02-26T16:34:39.000Z |  RHEL-7.1_HVM_GA-20150225-x86_64-1-Hourly2-GP2  |  ami-b1b458b1          |
|  2015-02-16T16:17:50.000Z |  RHEL-7.0_HVM_GA-20150209-x86_64-1-Hourly2-GP2  |  ami-e532d3e5          |
|  2014-10-20T14:13:11.000Z |  RHEL-7.0_HVM_GA-20141017-x86_64-1-Hourly2-GP2  |  ami-35556534          |
|  2014-05-28T20:36:35.000Z |  RHEL-7.0_GA_HVM-x86_64-3-Hourly2               |  ami-87206d86          |
|                                            DescribeImages                                            |
————————————————————————————————————————————————————
+—————————————+————————————————————————+————————————+
+—————————————+————————————————————————+————————————+

冒頭で紹介したブログ中にあるCentOSのAMIを調べる際のコマンド結果とは違い、こちらは7.6なのか7.5なのかOS内で_etc_redhat-releaseを確認するまでもなくマイナーリリースのVerがわかるのがよいですね。

なお、マーケットプレイスで提供されているAMIは、上記のコマンドで検索できるAMIに含まれており両者に違いはありません（ex.東京リージョンで7.1のAMIをSubscribeしてEC2を展開しようとした場合、利用されるAMIは上記でリストアップされている7.1のAMI=ami-b1b458b1です）。

ちなみに—filtersオプションの正規表現をいじれば6系も8系も表示可能です（2019年6月18日現在は8系ではGAという名称がついたAMIはないようなので、フィルタ条件からGAという文言を除いてコマンドを打つとよいです）。

製品コード・請求コードについて

マーケットプレイスで提供のAMIの多くについては ProductCodesがあります。ただ、Amazon Linux等ごく一部のAMIについてはProductCodesがないものがあります。RHEL AMIもその一種となります。

Redhatの場合は、別種の請求コードを有しておりその内容は以下で確認することができます（ami-b1b458b1から作成したインスタンスでの確認結果）。billingProductsの配列中に格納する値が請求コードに該当します。

$ curl -s 'http://instance-data/latest/dynamic/instance-identity/document/' |grep -i product
 "devpayProductCodes" : null,
 "marketplaceProductCodes" : null, 
 "billingProducts" : [ "bp-6fa54006" ],

公式ドキュメント にも記載があります通り、RHELに関してはEBSスナップショットからAMIを作成してしまいますと、上記の請求コード情報が保持されなくなります。結果、RHUIに正常に接続できない等の弊害が生じることに注意です。

AMIをEBSスナップショットからではなくEC2インスタンス自体から取得するようにしていれば上記のような自体は生じ得ませんが、万一AMIから復旧したRHELにてyumが使えない等の事象が発生した場合のトラブルシューティング・確認事項として上記は覚えておくといいでしょう。

最後に

自身の備忘録も兼ねたごくごく簡易な記事ですが、城のCent OSのAMI確認ブログ共々、どなたかの役に立てば嬉しく思います。

ええ。起動しませんでした。

ちなみにOSはAmazon Linux 2です。

$ sudo systemctl status squid
● squid.service
   Loaded: not-found (Reason: No such file or directory)
   Active: failed (Result: exit-code) since Wed 2019-06-19 02:38:40 UTC; 21min ago
 Main PID: 32671 (code=exited, status=1/FAILURE)

Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal squid[32671]: Squid Parent: (squid-1) process 32707 started
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal (squid-1)[32707]: The basicauthenticator helpers are crashing too rapidly, need help!
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal squid[32671]: Squid Parent: (squid-1) process 32707 exited with status 1
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal squid[32671]: Squid Parent: (squid-1) process 32707 will not be restarted due to repeated, frequent failures
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal squid[32671]: Exiting due to repeated, frequent failures
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal systemd[1]: squid.service: main process exited, code=exited, status=1/FAILURE
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal squid[32715]: squid: ERROR: Could not send signal 15 to process 32707: (3) No such process
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal systemd[1]: squid.service: control process exited, code=exited status=1
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal systemd[1]: Unit squid.service entered failed state.
Jun 19 02:38:40 ip-192-168-10-185.ap-northeast-1.compute.internal systemd[1]: squid.service failed.

The basicauthenticator helpers are crashing too rapidly, need help!とのことですが、ググっても解決せず。

結局、安直にインスタンスタイプを上げてみたら起動しました。

メモリが足らなかったのか？