AWS CloudFrontとLambda勉強まとめ

CloudFront

CDN
– Contents Delivery Network
– エッジのキャパシティを利用して効率的かつ高速にコンテンツ配信
→ユーザに最も近いサーバに誘導して、配信を高速化
→エッジサーバではコンテンツのキャッシングを行い、オリジンに負荷をかけない

・最適なエッジへの誘導方法
①ドメイン名問い合わせ(クライアント→DNS)
②IPアドレス問い合わせ(DNS→CloudFrontDNS)
③最適なEdgeアドレス応答(CloudFrontDNS→DNS)
④最適なEdgeへアクセス(クライアントからEdge)
⑤キャッシュがある場合:コンテンツ配信
キャッシュがない場合:オリジンサーバから取得

・CloudFront特徴
– 84拠点のエッジサーバ
– 予測不可能なスパイクアクセスへの対応
– ビルトインのセキュリティ機能(WAF連携、DDoS対策)
– 充実したレポート

・動的コンテンツ:ELBでEC2に負荷分散。HTML
静的コンテンツ:S3などで保存

・84エッジロケーション→11リージョナルキャッシュ→オリジン
→オリジンに対するコンテンツ取得を削減

CloudFront Distribution
– ドメインごとに割り当てられるCloudFrontの設定
– 40Gbpsもしくは100,000RPSを超える場合上限申請必要
– HTTP/2対応
– IPv6対応
– CNAMEエイリアスを利用して独自ドメイン名の指定可能
→Route53と合わせたZone Apex(wwwがないもの)も利用可能

Gzip圧縮機能
エッジでコンテンツをGzip圧縮することでより高速にコンテンツ配信
※S3はGzip圧縮をサポートしていないので有効

キャッシュコントロール
– キャッシュヒット率の向上がCDNのポイント
→URLおよび有効化したパラメータ値の完全一致でキャッシュが再利用

キャッシュの無効化
コンテンツごとの無効化パス指定

ダイナミックコンテンツ機能
オリジンサーバに対して下記情報をフォワードすることで、動的なページの配信にも対応
– ヘッダー(必要最小限)
– Cookie(Cookie名と値をセットでCloudFrontがキャッシュ)
– クエリ文字列パラメータの値

ダイナミックキャッシング
リクエストパターンをもとにオリジンへのアクセスルールを個別指定可能

カスタムエラーページ
4xx系:クライアントエラー。オリジン側で対処
5xx系:サーバエラー。CloudFrontで対処
参考URL:https://goo.gl/NcUQiY

読み取りタイムアウト
CloudFrontがオリジンからの応答を待つ時間を指定
デフォルトは30秒

キープアライブタイムアウト
接続を閉じる前に、CloudFrontがオリジンとの接続を維持する最大時間
デフォルトは5秒

・セキュリティ
– HTTPS対応
– SSL証明書
→専用IPアドレスSSL証明書には申請必要
ビューワーSSLセキュリティポリシー
→クライアントとCloudFront間のSSL/TLSプロトコルとCipherの組み合わせを指定可能
– オリジン暗号化通信
– オリジンカスタムヘッダー
GEOリストリクション
→地域情報でアクセス判定。制御されたアクセスには403を応答
署名付きURL
→プライベートコンテンツ配信。
→署名付きURLを生成する認証サイトにクライアントから認証リクエスト
→認証サイトからEdgeにアクセス※署名付き出ない場合は、403を返す
-オリジンサーバーの保護
→Origin Access Identitiy(OAI)を利用
S3のバケットへのアクセスをCloudFrontからのみに制限
– AWS WAF連携
AWS ShieldによるDDoS攻撃対策
ブロック時は403応答
– AWS ShieldによるDDoS攻撃対策
デフォルトで有効

・CloudFrontレポート・アクセスログ機能
任意のS3バケットに出力可能

・CloudWatchアラームの活用
リアルタイム障害・異常検知

・S3オリジン自動キャッシュの無効化(Invalidation)
S3にアップロード→Lambdaファンクション呼び出し→CloudFront Invalidation APIの呼び出し→CloudFront上でキャッシュの無効化

Lambda

高度にパーソナライズされたウェブサイト
ビューワーリクエストに応じたレスポンス生成
URLの書き換え
エッジでのアクセスコントロール
リモートネットワークの呼び出し

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-blackbelt-online-seminar-2017-amazon-cloudfront-aws-lambdaedge

続きを読む

Amazon Transcribeを調べてみた

Amazon Transcribeとは

Amazon Transcribeは一言で言うと”Speech to Text”と呼ばれる、音声をテキスト情報に変換するサービスです。
話されている言語を機械学習の技術で識別し、テキスト情報に変換します。

この技術は以下のような新しいサービスやプロダクトの提供に役立ちます。

  • 映像ファイルから音声を認識し、クローズドキャプションを生成
  • コールセンター業務などでの問い合わせ内容の分析
  • 医療分野や法律分野での活用

また、”Amazon Translate”や”Amazon Polly”と連携して、生成したテキスト情報を翻訳し、再度翻訳した言語で音声に変換することなどもできます。

何ができるのか

Amazon Transcribeには以下の3つのオペレーションがあります。

  • StartTranscriptionJob : 非同期で音声をテキストに書き起こす
  • ListTranscriptionJobs : 開始された音声認識ジョブのリストを返す。 返して欲しいJobをステータスで絞り込むことができる
  • GetTranscriptionJob : 音声認識の結果を返す。結果にはJSON形式に変換された結果へのリンクが含まれている

Speech Input

インプットするファイルはS3 bucketに保管されている必要があります。
インプットファイルの仕様は以下のみ

  • FLAC、MP3、MP4、WAV
  • 尺は2時間未満

言語、フォーマット、サンプリングレートを指定する必要があります。

  • PCM 16ビットエンコーディングのFLACやWAVなどのロスレスフォーマットを使用。
  • サンプリングレートは8000 ~ 16000Hz

Amazon TranscribeのS3とその中のファイルへのアクセスを許可する必要があります。

Output JSON

Jobが完了するとJSONが含まれた結果が生成され、テキストファイルがS3に置かれます。
ファイルのIDはユーザー固有のURIとなっており、そのURIを利用することで結果を取得できます。

Ex)

 {
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.874,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }
 

始め方

始めるにはAWSアカウント、ID、IAMユーザーが必要です。CLIの利用も可能です。

Step.1 AWSアカウント設定

いつも通りなので割愛

Step.2 CLI設定

いつも通りなので割愛

Step.3 コンソールでの利用開始

Jobの作成

1.各種情報の入力
 - Transcription job name : AWSアカウント毎にユニークである必要がある
 - Amazon s3 input URL: 音声ファイルが格納されているS3 busket。Transcribeと同一リージョンである必要がある
 - Language:インプットファイルの言語を選択
 - Format:インプットファイルのフォーマットを選択
 - Media sampling rate(Hz):インプットファイルのサンプリングレートを8000 ~ 48000Hzの間で指定。8000~16000Hzが推奨
2.「Create」を押す

Jobの確認

Jobのリストを表示。「Availability」にサーバーに結果が保管される残り期間が表示される。結果の保管期間は90日
Jobをクリックすると、詳細(Job名、残りの保管期間、I/OのファイルのS3パス)と結果の文字列が表示される。
「Code Samples」で該当JobについてのJSONファイルを取得可能

Step.4 API

CLI

Transcribeのテストをする場合

1.InputファイルをS3 バケットに配置する(Transcribeと同じリージョンに)
2. ファイル情報を含んだJSONファイルを作成する

{
    "TranscriptionJobName": "request ID", 
    "LanguageCode": "en-US", 
    "MediaFormat": "wav", 
    "Media": {
        "MediaFileUri": "https://S3 endpoint/test-transcribe/answer2.wav"
    }
}

3.下記コマンドを実行
json
aws transcribe start-transcription-job
--endpoint-url endpoint
--region region
--cli-input-json file://test-start-command.json

・下記レスポンスが返れば成功
“`json

{
“TranscriptionJob”: {
“TranscriptionJobName”: “request ID”,
“LanguageCode”: “en-US”,
“TranscriptionJobStatus”: “IN_PROGRESS”,
“Media”: {
“MediaFileUri”: “https://S3 endpoint/test-transcribe/answer2.wav”
},
“CreationTime”: timestamp,
“MediaFormat”: “wav”
}
}
“`

Jobのリストを取得

1.Jobが完了していた場合、下記コマンドでステータスを取得する

aws transcribe get-transcription-job-results 
   --endpoint-url endpoint 
   --region endpoint 
   --request-id "DocTest-01"

・成功すればレスポンスは下記通り返ってくる

{
    "TranscriptionJob": {
        "TranscriptionJobName": "request ID",
        "LanguageCode": "en-US",
        "TranscriptionJobStatus": "COMPLETED",
        "Media": {
            "MediaFileUri": "input URI"
        },
        "CreationTime": timestamp,
        "CompletionTime": timestamp,
        "Transcript": {
            "TranscriptFileUri": "output URI"
        }
    }
}
```json

2.Output URIを使って翻訳されたテキストを取得

```json
{
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.87,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }

SDK for Python(Boto)

・InputファイルをS3 バケットに配置する(Transcribeと同じリージョンに)。ファイル情報を含んだJSONファイルを作成する

from __future__ import print_function
import time
import boto3
transcribe = boto3.client('transcribe')
job_name = "job name"
job_uri = "https://S3 endpoint/test-transcribe/answer2.wav"
transcribe.start_transcription_job(
    TranscriptionJobName=job_name,
    Media={'MediaFileUri': job_uri},
    MediaFormat='wav',
    LanguageCode='en-US'
)
while True:
    status = transcribe.get_transcription_job(TranscriptionJobName=job_name)
    if status['TranscriptionJob']['TranscriptionJobStatus'] in ['COMPLETED', 'FAILED']:
        break
    print("Not ready yet...")
    time.sleep(5)
print(status)

・成功すればレスポンスは下記通り返ってくる

 {
      "jobName":"job ID",
      "accountId":"account ID",
      "results": {
         "transcripts":[
            {
               "transcript":" that's no answer",
               "confidence":1.0
            }
         ],
         "items":[
            {
               "start_time":"0.180",
               "end_time":"0.470",
               "alternatives":[
                  {
                     "confidence":0.84,
                     "word":"that's"
                  }
               ]
            },
            {
               "start_time":"0.470",
               "end_time":"0.710",
               "alternatives":[
                  {
                     "confidence":0.99,
                     "word":"no"
                  }
               ]
            },
            {
               "start_time":"0.710",
               "end_time":"1.080",
               "alternatives":[
                  {
                     "confidence":0.87,
                     "word":"answer"
                  }
               ]
            }
         ]
      },
      "status":"COMPLETED"
   }

認証とアクセスコントロール

・AWS Transcribeの利用にはCredentialが必要です。Credencialには認証とアクセスコントロールの設定を行う必要があります。

認証

・認証には以下のいずれかを使用します。
– AWS Account ルートユーザー(非推奨)
– IAM role
  (1) ユーザーごとの許可
  (2) AWSサービスのからのアクセス
  (3) EC2からのアクセス許可

アクセスコントロール

TranscribeへアクアセスするためのPermissionの管理

アクセスとアクションの確認

・誰が何にアクセスするかはは下記方法で定義します。
 - IAMポリシー:IAMユーザーやIAM roleに権限を付加する
 - リソースベースのポリシー:各AWSのサービスにAPIでアクセスする際に要求されるポリシー主にResource,Action,Effect,Principalなど

TranscribeのためのIAM ポリシー

・StartTranscriptionJobを実行するためのIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "transcribe:StartTranscriptionJob"
             ],   
            "Resource": "*"
        }
    ]
}

・コンソールでTranscribeを使用するためのIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "transcribe:*"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

・音声を取得するためにIAM roleの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "transcribe.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::bucket name/*"
        }
    ]
}

・KMSを使ったS3の暗号化を行うための IAM roleの例

{
      "Sid": "Allow-Transcribe",
      "Effect": "Allow",
      "Principal": {
        "Service": "transcribe.amazonaws.com”
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }

APIに対する権限のリファレンス

・Amazon TranscribeのAPIは下記通り
 - GetTranscriptionJob:
   API: transcribe:GetTranscriptionJob
   Resource:*
 - ListTranscriptionJobs:
   API: transcribe:ListTranscriptionJobs
   Resource:*
 - StartTranscriptionJob:
   API: transcribe:StartTranscriptionJob
   Resource:*

ベータ版のガイドラインと制限

・現在は下記リージョンのみ
 -リージョン:US East (N. Virginia)
 - Endpoint::https://transcribe.us-east-1.amazonaws.com
 - プロトコル:HTTPS
・推奨素材は以下
 - ロスレスFLAC、ロスレスWAV、PCM(16ビット)
 - サンプリングレート 8000 ~ 16000Hz
・制限は以下の通り
 - 尺は最長2h

APIリファレンス

・別紙参照(https://docs.aws.amazon.com/ja_jp/transcribe/latest/dg/API_GetTranscriptionJob.html)

続きを読む

Amazon S3 に Git LFS サーバを超簡単に立てる

元ネタはこちら。
Serverless Git LFS for Game Development – Alan Edwardes
Amazon API Gateway + Amazon Lambda + Amazon S3 を使うんだそうです。

準備: AWS のアカウントをとる

AWSのアカウントがなければとります。
作成の流れは 公式のドキュメント でだいじょうぶです。

アカウントをとったら初期設定しておきます。以下のエントリが参考になりました。
AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ – Qiita

サーバ作成手順

Screen_Shot_2018-01-21_at_22_29_22-fullpage.png

  • 「次へ」をクリックします → オプションの設定ページはスルーで「次へ」をクリックします。
  • 「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」にチェックして「作成」をクリックします。

Screen_Shot_2018-01-21_at_23_05_08-fullpage.png

  • スタックのリストに新しいスタックができて(スタックがなければリロードして下さい)、「CREATE_COMPLETE」と表示されたら成功です。

Screen_Shot_2018-01-21_at_23_10_18-fullpage.png

  • スタックの詳細画面に入って、出力を確認すると、Git LFSのエンドポイントのURLが表示されているので、リンクをコピーします。

Screen_Shot_2018-01-21_at_22_34_53-fullpage.png

Git LFS に lfs.url を設定

Git LFS は導入してあることとします。

以下のコマンドで、 .lfsconfig を作成します。

git config -f .lfsconfig lfs.url <表示されたエンドポイントのURL>

git lfs env で確認して、Endpoint= の行が設定したURLになってたらOKです。

git push すると、S3の方にLFSオブジェクトがpushされるようになります。

問題点

URL を見ればわかると思いますが、この方法で作成するとリージョンが 欧州 (アイルランド) に作成されます。
東京リージョンにS3を立てたいと思って、 URL の region=eu-west-1 の部分を region=ap-northeast-1 に変えてみましたが、リージョンを変えると成功しないみたいです。

alanedwardes/Estranged.Lfs – Github

どなたか検証お願いします。 m(_ _)m

続きを読む

AWS IoT device managementのJob機能の動きをデバイス視点で見てみる

はじめに

公式ページはこちらになります。(2018/1/20時点では英語のマニュアルのみとなっております)
同じく、投稿時点では、javascript IoT Device SDKはjobの処理が入っているようですが、pythonなどはまだSDKに入っていないようですので、本説明にあわせてご自分でシーケンスをコードで表現する必要があるようです。
デバイス側でどういったことを考えてシーケンスを書くかや、request/responseのjsonについての理解が深まるようにまとめようと思います。

デバイスが意識すべきjob用のtopic

以下、topoic中の{}で区切ったものは変数となるものです。 device名やjobIdなど。

job情報取得で使えるtopic

新規job待受用のsubscribe topic

  • $aws/things/{thingName}/jobs/notify
  • $aws/things/{thingName}/jobs/notify-notify

新規jobが作成されると下記2つにpublishされます。つまり新規jobを受け取るために、動作中のデバイスがsubscribeしたままにすべきtopicということになります。2つのtopicの情報の差を含めて見ましょう。

$aws/things/{thingName}/jobs/notify
=> job一覧入ってきます。jobDocumentはありません。

{
  "timestamp": unixtime,
  "jobs": {
    "IN_PROGRESS": [
      {
        "jobId": "作成したjob名",
        "queuedAt": unixtime,
        "lastUpdatedAt": unixtime,
        "startedAt": unixtime,
        "executionNumber": 1,
        "versionNumber": 3
      }
    ],
    "QUEUED": [
      {
        "jobId": "作成したjob名",
        "queuedAt": unixtime,
        "lastUpdatedAt": unixtime,
        "startedAt": unixtime,
        "executionNumber": 1,
        "versionNumber": 1
      }
    ]
  }
}

$aws/things/{thingName}/jobs/notify-next
=> 次にやるべきjob情報のみが、通知されます。
jobDocumentにある、test:testは job生成時に指定したS3のjob fileの中身(json)が入っています。

{
  "timestamp": unixtime,
  "execution": {
    "jobId": "job名",
    "status": "QUEUED",
    "queuedAt": unixtime,
    "lastUpdatedAt": unixtime,
    "versionNumber": 1,
    "executionNumber": 1,
    "jobDocument": {
      "test": "test"
    }
  }
}

注意:通知対象のdeviceに”IN_PROGRESS”のstatusがある場合、notify-nextは発行されません。
複数の処理を通知して、デバイス側でupdate処理が重複しないための考慮だと思います。

この場合、デバイスが “testjob-20180120-00” のtaskの終了通知(後述のupdate通知をSUCCEEDEDでpublish)すると、AWS IoTがnotify-nextへ通知します。

能動的にjob statusを確認するためのtopic

起動時などにjobを確認する用途 publishすると、acceptedへ返却される

  • $aws/things/{thingName}/jobs/get (publish)
  • $aws/things/{thingName}/jobs/get/accepted (publish前にsubscribeしておく)

上記の通り、シーケンスとしては acdepted topicを先にsubscribeしてから、get topicへpublishすることとなります。acceptedへのsubscribeへの返却は以下のようなjsonとなります。先に説明したnotifyと少しjsonフォーマットが異なりますが、取得できる内容はほぼ同じです。
こちらはデバイスが起動したばかりなどで前回の終了状態が分からない場合や電源off時などにupdateが来ていないかなど、最初にチェックするような用途になるかと思います。

{
  "timestamp": unixtime,
  "inProgressJobs": [],
  "queuedJobs": [
    {
      "jobId": "Job名",
      "queuedAt": unixtime,
      "lastUpdatedAt": unixtime,
      "executionNumber": 1,
      "versionNumber": 1
    }
  ]
}

deviceがAWS IoTにreportするためのtopic

$aws/things/thingName/jobs/jobId/update
requestのjson format

{
  "status": ["IN_PROGRESS", "FAILED", "SUCCEEDED", "REJECTED"],
  "statusDetails": {
    "progress": "0%"
  },
  "expectedVersion":"",
  "clientToken":""
}

statusは上記の4つの状態のみを指定可能
statusDetailsのjsonについては自由に記載できます。ここでは例として”progress”としています。
管理者視点で見ると、統計などが見れる機能があるので、デバイス側のupdate処理内で定期的に呼び出して置くと良いかと思います。

AWS IoTのテスト画面を使っての動作確認

device想定のsubscribe設定

AWSのマネージメントコンソールから、AWS IoTを選択し左側メニューの “Test” を選択します。
Subscription topicへ”$aws/things/+/jobs/#”を入力し、subscribe to topicを押下して、受信状態のままにしておきます。

意味を説明すると$aws/things/(+ = すべてのthingName)/jobs/(# = ここ以下すべてのレイヤtopic)
を受信することになります。

スクリーンショット 2018-01-21 21.39.56.png

test Jobの作成

事前作業

AWS IoTの作成

今回は、AWS IoTのテスト画面しか使わないので名前だけあれば良いです。(証明書やpolicyなどは使いません)
本投稿では qiita-thing としています。

job通知のjsonドキュメント配置

S3へjsonドキュメントを置きます。このjsonドキュメントがjobのjobDocumentとして通知されます。
ここでは、 {“test”:”test”}としておいておきます。

AWS IoTからjob作成

先程の受信状態のコンソールをそのままにして別タブなどでもう一つ AWS IoT画面を開き、Manage => Jobsを選択します。画面右上にあるCreateを押下して、jobの作成をしてみます。

Select a job で、Create custom jobを選択。次の画面で以下を設定
– Job IDに qiita-test
– device updateに、先程作ったthingを一つ選択、
– job fileに 先程おいたS3のjson fileを選択
– job typeに snapshotを選択
createを実行。createを実行するとjob通知が自動で発行されます。

通知の確認とupdateで通知

AWS IoTのtest画面の方に戻ります。
先程のjob作成でsubscribeにnotifyとnotify-nextの通知がきています。
スクリーンショット 2018-01-21 22.09.31.png

本test画面の Publish の topicを以下とします。
$aws/things/qiita-thing/jobs/qiita-test/update

updateのpayloadに以下を設定

{
  "status": "IN_PROGRESS",
  "statusDetails": {
    "progress": "0%"
  },
  "expectedVersion":"",
  "clientToken":""
}

状態を確認

Publishのtopicを以下に変更して、publishを実行します。
$aws/things/qiita-thing/jobs/get
mqttのpayloadは設定しなくともよいです。

test画面のsubscribeの画面に以下が表示されました。想定通り、queueからinProgressへ変化しています。

{
  "timestamp": 1516540819,
  "inProgressJobs": [
    {
      "jobId": "qiita-test",
      "queuedAt": 1516540026,
      "lastUpdatedAt": 1516540699,
      "startedAt": 1516540699,
      "executionNumber": 1,
      "versionNumber": 2
    }
  ],
  "queuedJobs": []
}

AWS IoTコンソールのjob詳細画面もin progressとなっています。
スクリーンショット 2018-01-21 22.28.08.png

複数jobを通知してみる

notifyとnotify-nextの動きを確認するために、再度jobを作成して送信してみます。
jobIdは qiita-test-2としてみます。それ以外は先程同じにしています。

説明済みですが、notifyのみが通知されました。

{
  "timestamp": 1516541383,
  "jobs": {
    "IN_PROGRESS": [
      {
        "jobId": "qiita-test",
        "queuedAt": 1516540026,
        "lastUpdatedAt": 1516540699,
        "startedAt": 1516540699,
        "executionNumber": 1,
        "versionNumber": 2
      }
    ],
    "QUEUED": [
      {
        "jobId": "qiita-test-2",
        "queuedAt": 1516541383,
        "lastUpdatedAt": 1516541383,
        "executionNumber": 1,
        "versionNumber": 1
      }
    ]
  }
}

最初のjobを完了させてみる

updateの通知と同様の手順で以下のtopicに payloadを”SUCCEEDED”として送信してみます。

topic : $aws/things/qiita-thing/jobs/qiita-test/update

{
  "status": "SUCCEEDED",
  "statusDetails": {
    "progress": "100%"
  },
  "expectedVersion":"",
  "clientToken":""
}

完了通知に合わせて自動でnotifyとnotify-nextが送られてきました。
ということで、notify-nextをsubscribeしておけば良いことがわかります。
スクリーンショット 2018-01-21 22.37.56.png

まとめ

ということで、AWS IoTのdevice managementのjob機能についてdeviceの観点で簡単に整理してみました。実際にはjob documentのデザイン(プログラムDLのS3 urlをセット)やプログラム更新をする部分というところがdevice updateの本質なので、主にシーケンス/request方法についての説明となりますが、AWS IoT側でこのくらい作られていれば、device updateプログラムの開発に集中出来るのではないでしょうか?

免責

本投稿は、個人の意見で、所属する企業や団体は関係ありません。
ご自身でもドキュメントの確認や、動きを確認してからの利用をおすすめします。

続きを読む

AWS S3勉強まとめ

ブロックストレージ
EBS, インスタンスストア
→EC2にマウントして活用
→Block番号で管理

オブジェクトストレージ
S3, Glacier
→安価かつ高い耐久性を持つオンラインストレージ
→オブジェクト、それに付随するメタデータ、そのオブジェクトにアクセスするためのユニークなIDで構成

ファイルストレージ
EFS
→EC2から同時マウントできる共有ストレージサービス
→ファイルシステム

・S3特徴
→容量無制限、安価なストレージ(1GB3円)、データ容量に依存しない性能(RAIDやサーバー台数を考える必要なし)

・S3用途
①コンテンツ配信、保管サーバ
②ログ&データハブストレージ
③バックアップやDR

バケット
オブジェクトの保存場所。デフォルト100個/1アカウントまで作成可能。名前はグローバルでユニークな必要あり。
オブジェクト
データ本体。URLが付与される
キー
オブジェクトの格納URL
メタデータ
オブジェクトに付随する属性情報。システム定義メタデータ、ユーザ定義メタデータあり
リージョン
バケットを配置するAWSのロケーション
アクセスコントロールリスト(ACL)
バケットやオブジェクトのアクセス管理

・ストレージクラス
スタンダード
標準低頻度アクセスストレージ:スタンダードに比べて安価だが、データの読出し容量に対して課金
Glacier:最も低コスト。データの取り出しにコストと時間
低冗長化ストレージ:Glacierから取り出したデータの置き場所として利用

結果整合性(Eventual Consistency Readモデル)
「更新はそのうち全体に反映される」
読み取り一貫性
– あるトランザクションがデータを変更中のとき、ほかのトランザクションからは変更される前のデータを参照します。
– ほかのトランザクションからは変更前の確定されたデータを参照します。
– あるユーザーAが値をUPDATEしたとき、ユーザーBがそのデータを参照すると、戻ってくる値はUPDATE前の値となります。
– あるトランザクションで変更した確定前のデータをほかのトランザクションから参照することはできません。

・パソコンのファイルシステムやデータベースと同じようにロックやトランザクション処理は行われない
参考URL:https://dev.classmethod.jp/cloud/amazon-s3-eventually-consistent-and-consistent-read/

・アクセス管理
①ユーザポリシー
→IAMuserに対して権限設定
②バケットポリシー
→バケットごとに権限設定。クロスアカウントで使用する際など
③ACL
→バケット、オブジェクトごとに指定可能(オブジェクトACLが優先)

署名付きURL
AWS SDKで作成。S3のプライベートなオブジェクトに対して一定時間アクセスを許可

・Webサイトホスティング機能
静的なWebサイトをS3のみでホスティング可能
– バケット単位で指定
– 独自ドメインの設定→ドメイン名をバケット名として指定
– リダイレクト機能→任意のドメインにリダイレクト設定が可能
CloudFrontとの経由で配信することを推奨。バケットポリシーでHTTP/HTTPSリクエストのみを許可可能

VPCエンドポイント
プライベートサブネットからNATゲートウェイなどを経由せずに直接S3とセキュアに通信可能
同一リージョンのみ

S3 support for IPv6
追加費用なし
静的ウェブホスティングは使用不可

・暗号化
– サーバーサイド暗号化(サーバリソースを利用して格納データの暗号化)
– クライアントサイド暗号化(クライアント側で暗号化したデータをS3にアップロード)

クロスリージョンレプリケーション
異なるリージョン間のS3バケットオブジェクトのレプリケーションを実施
→オブジェクトに対する動作を非同期でレプリケーション
→対象元バケットはバージョニングの機能を有効にする必要あり
※リージョン間データ転送費用が発生

バージョン管理機能
誤操作による削除対策に有効
バケットに対して設定
任意のオブジェクトを参照可能
バージョニングのオブジェクト分も課金。保存期間も指定可能

ライプサイクル管理
バケット内のオブジェクトに対して、ストレージクラスの変更や、削除処理の自動化
データ登録→Standard保存(一定期間過ぎたら削除)→Standard-IA移動(一定期間過ぎたら削除)→Glacierにアーカイブ(一定期間過ぎたら削除)

・アーカイブ
S3上のデータを削除でGlacier側のデータも削除
S3には8KBのオブジェクト名とメタデータのみ保管

・復元
オブジェクトごと
一時的にS3の低冗長化ストレージに指定日数複製(Glacierと低冗長化ストレージ両方課金)
復元にかかる時間の選択肢は3つ
①Expedited:緊急のアクセス
②Standard:3-5時間。標準的
③Bulk:大量のデータ。5-12時間
それぞれによってコストが異なる

・オブジェクト移動
Standard⇔Standard-IA→Glacier
→Glacier

S3分析
Standard-IAとGlacierどちらにいつ移動すればいいだろうかという疑問に答える可視化ツール
→ライフサイクルポリシーの設定値の参考になる

S3インベントリ
S3のオブジェクトのリストを一気にcsvファイルで取得
スケジュールかも可能

・イベント通知
SNS:メール送信
SQS:キューメッセージの登録
Lambda:ファンクションの実行

・CloudWatchによる監視
ストレージメトリクス:バケット単位。1日単位でのレポート。追加費用なし
リクエストメトリクス:オブジェクト単位。通常のCloudWatch料金

CloudTrailによるAPI(操作ログ。Get, Delete, Putなど)管理
S3への操作ログを収集
監査対象とは別のS3バケットの用意推奨

Logging
バケットに対するアクセスログの出力設定可能

Tag管理
バケット/オブジェクトに対してタグの指定可能

・パフォーマンスの最適化
大きなサイズのファイルをアップロード、ダウンロード
RANGE GETを活用。マルチパートアップロード機能
大量のGETリクエストが発生する場合はCloudFrontを併用することを推奨

Transfer Acceleration(高速ファイル転送サービス)
AWSのエッジネットワークから最適化されたAWSのネットワークを経由する。
S3のデータ転送コストとは別に加算
※通常の転送より高速でない場合は、課金されない

コンテンツ配信サーバ
データをS3に配置、CloudFrontでキャッシュさせる
CloudFrontで静的コンテンツ配信。CloudFrontの料金はかからない
Webサーバーで動的コンテンツは処理

ログ&データハブストレージ
オンプレ:Direct Connectでログデータ収集
外部データソース;Kinesisで収集
AWS;S3に保管。Glacierにアーカイブ
分析:Redshift, EMR, Atenaなど

バックアップ、DR
クロスリージョンでデータの複製を保持
リージョン内でもDR設定

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-amazon-s3

続きを読む

AWS RDS勉強まとめ

・RDSの制限事項
バージョンが限定
キャパシティに上限
OSログインやファイルシステムへのアクセス不可
など

上記が許容できない場合はOn EC2かオンプレミスで構築

Multi-AZ
同期レプリケーションと自動フェイルオーバー
インスタンスやハードウェア障害時など

リードレプリカ
デフォルトで5台増設可能
マルチAZやクロスリージョン対応も可能
マスタと異なるタイプに設定可能
読み取り専用などに設定し、スループット向上

・スケールアップ、スケールダウン可能

・ストレージタイプ
汎用SSD
プロビジョンドIOPS
マグネティック

・バックアップ
自動スナップショット+トランザクションログをS3に保存
1日1回設定した時間に自動スナップショット取得、保存期間は0日~35日、手動スナップショットも可能

・リストア
スナップショットをもとにDBインスタンス作成
指定した時刻の状態にすることも可能(Point-in-Time)

・スナップショットはDBインスタンスのサイズと同サイズまでコスト無料
・自動スナップショットはDBインスタンス削除と同時に削除
※手動スナップショットは削除されないので、削除前に最終スナップショットをとること推奨
・スナップショット実行時にI/Oが停止するが、マルチAZの場合はスタンバイから取得するためアプリへの影響なし

リネーム
RDSに接続する際のエンドポイントを切り替える機能
旧本番インスタンスをリネーム→新本番インスタンス(スナップショットからリストア)をリネーム

・リネームの注意点
DNSはすぐに切り替わるわけでない
CloudWatchのMetricNameは引き継がない
マスターをリードレプリカの関係、タグ、スナップショットは引き継ぐ

・RDSにかかわる制限事項
RDSインスタンス数:40
1マスターあたりのリードレプリカ数:5
手動スナップショット数:100
DBインスタンスの合計ストレージ:100TB
必要に応じて上限緩和申請

・デフォルトではDBインスタンスに対するネットワークアクセスはオフ
→セキュリティグループで制御し、アクセス許可のポートなどを指定

・DBインスタンスとスナップショットの暗号化可能

オンデマンドDBインスタンスVSリザーブドインスタンス
リザーブドインスタンス:予約金を支払うことで価格割引

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/20170510awsblackbeltrds

続きを読む

AWS EBS勉強まとめ

2017年新しい機能追加
==
・起動ボリュームの暗号化をサポート

スループット最適化HDD
高スループットを必要とするワークロード(MapReduce、Kafka、ETL処理、ログ処理、データウェアハウスなど)向けのタイプ; 1GBあたり月額0.054ドル
コールドHDD
同様のワークロードでアクセス頻度が低いユースケース向け; 1GBあたり月額0.03ドル
プロビジョンドIOPS SSD
I/O性能に依存するNoSQLデータベースやリレーショナルデータベース
汎用SSD
起動ボリューム、低レイテンシを要求するアプリケーション、開発・テスト環境
マグネティック
アクセス頻度の低いデータ
参考URL:https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-cold-storage-and-throughput-options/

・汎用SSDボリュームのバーストクレジットの残高がCloudWatchで確認可能(残高はパーセンテージ)

・稼働中のEBSをオンラインのまま、ダウンタイムなく、変更することを可能にするエラスティックボリューム機能をリリース

・現行世代のインスタンスに関しては下記可能
①容量の拡張
②IOPS値の変更(PIOPSボリュームのみ)
③ボリュームタイプの変更(汎用SSD→コールドHDDなど)
→CloudWatchとCloudFormationやAWS Lambdaなどで自動化も可能

参考URL:https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-elastic-volumes-change-everything/

・EBSスナップショットにコスト配分タグをサポート
→コスト集計ができるようになった
==

・EBSスナップショットはS3に保存
・AZごとに独立。同一AZのインスタンスのみから利用可能
→しかし、Snapshotから任意のAZに復元可能
・EC2に複数のEBSを接続可能だが、反対は不可

・EBSはレプリケートされているので、冗長化は不要
・セキュリティグループによる制御の対象外。全ポートを閉じてもEBSは利用できる

・インスタンスストアVSEBS
インスタンスストア:揮発性。EC2のローカルディスク。仮想マシンが止まるとデータ消去。一時的なデータの置き場所などに利用。
EBS:永続化ストレージ。OSやDBのデータなど永続化のデータ用。

・スペックは下記の順
プロビジョンドIOPS→汎用SSD→スループット最適化HDD→コールドHDD→マグネティック

SSDの種類は下記2種類
汎用SSD
I/O機能を一時的に3000IOPSまで上げるバースト機能付き
→I/O Creditが必要。CloudWatchで監視可能。上限(540万I/Oクレジット)に対するパーセント
容量:1GB~16TB
IOPS:ベースは100IOPS。最大10000IOPS
スループット:128MB/秒~160MB/秒

プロビジョンドIOPS
容量:4GB~16TB
IOPS:50IOPS/1GB。最大20000IOPS
スループット:最大320MB/秒

HDDの種類は下記2種類
→小さいデータのランダムアクセスになりがちな処理、起動ボリューム、データベース、ファイルサーバー等への利用は非推奨
→ログ処理などのシーケンシャルアクセス用途。アクセス頻度が低いもの

スループット最適化HDD
容量:500GB~16TB
IOPS:最大500IOPS
スループット:40MB/秒がベース

コールドHDD
容量:500GB~16TB
IOPS:最大250IOPS
スループット:12MB/秒がベース

マグネティック
磁気ディスクタイプ
容量:1GB~1TB
IOPS:100IOPS
スループット:40MB/秒~90MB/秒
I/Oリクエスト回数による課金が唯一ある

EBS最適化インスタンス
EC2とEBSの独立した帯域を確保し、I/O性能の安定化

事前ウォーミング
Snapshotから復元したボリュームへの初回アクセス時に設定

・EBSのパフォーマンス改善
①EC2インスタンス側のスループット
EBS最適化を有効にする
EBSからのスループットの上限値に到達していないかをCloudWatchのVolume Read/Write Bytesの合計値で確認

②EBSが処理できるIOPS
CloudWatchのVolume Read/Write Opsを参照

③各EBSボリュームのスループット
CloudWatchのVolume Read/Write Bytesの合計値で確認

・Snapshot
EBSのバックアップ機能
S3に保管。2世代目以降は増分バックアップ。1世代目を削除しても復元可能
ブロックレベルで圧縮して保管するため、圧縮後の容量に対して課金
データ整合性を保つため、静止点を設けることを推奨
別AZに移動したい場合や、容量変更などもSnapshot経由で行う

・バックアップと静止点
EBSへのI/O停止→Snapshot作成指示→作成指示レスポンス→EBSへのI/O再開
※Snapshotの作成完了前にEBSへのI/O再開してよい

・Snapshotの削除
1世代目を削除しても、1世代目にしかないデータは削除されない

・リージョン間コピーをサポート
リージョン間でのコピーも可能

参考URL:https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-elastic-block-store-ebs

続きを読む

【AWS SDK for PHP】1000以上のファイルがあるS3バケットの内容を取得する

やりたいこと

PHPでS3バケットにあるファイルのリストを取得する際、AWS SDK for PHPのListObjectsメソッドListObjectsV2メソッドが使えます。v1とv2ではパラメーターの設定方法や返り値が若干異なるだけで中身は同じです。どっちでもいいのですが今回はv2でいきます。

しかし困ったことに一度に1,000件までしか取得できない…さすがにそれは不便すぎる

解決策

バケットにオブジェクトが1000より多く存在する時、ListObjectV2の返り値のIsTruncatedがtrueになることを利用します。
ちなみに’truncated’は切り捨てという意味で、取りこぼしたやついるよ〜っていう主張でしょうね。
さて、IsTruncatedがtrueの時、返り値のNextContinuationTokenに、今取得したリストの次から取得するためのトークンが入っています。これをリクエストパラメーターContinuationTokenに入れてあげてもう一回1000件取得…を繰り返していけばいいわけです。

結果的にコードは次のようになりました。

use AwsS3S3Client;

$config = [
    'credentials' => [
        'key' => '*** アクセスキー ***',
        'secret' => '*** シークレットキー ***',
    ],
    'region' => '*** リージョン ***',
    'version' => '2006-03-01'
];
$bucket = '*** バケット名 ***';
$prefix = '*** プレフィックス ***';


$client = S3Client::factory($config);

$object_list = GetObjectList($client, $bucket, $prefix);



function GetObjectList($client, $bucket, $prefix, $continuous_token=null)
{
    $result = $client->ListObjectsV2([
        'Bucket' => $bucket,
        'Prefix' => $prefix,
        'ContinuationToken' => $continuous_token
    ]);

    $object_list = [];
    if (isset($result['Contents'])) {
        foreach ($result['Contents'] as $object) {
            // 名前がxxxx/のオブジェクト(フォルダ)はリストに含めない
            if(substr($object['Key'], -1, 1) !== '/') {
                $object_list[] = 's3://'.$bucket.'/'.$object['Key'];
            }
        }

        if($result['IsTruncated'] === true) {
            $object_list = array_merge($object_list, GetObjectList($client, $bucket, $prefix, $result['NextContinuationToken']));
        }
    }

    return $object_list;
}

続きを読む

AWS S3を使ってUnity WebGLの開発で起こったこと。

まえふり

UnityでWebGL向けに開発し、ネットに公開するには何らかの方法でサーバーが必要になります。
本番をどのように対応するかはさておき、簡単かつ無料でWebGLを公開したいのであればAWSの1年無料枠でS3を使って動作確認しました。

そのときの内容とトラブったことのまとめになります。
個人的に、Unity使ってWebGL向けの開発をしている人で、WebGLのデータを置くサーバーを検討している人やどうするのか分からない人などにこの記事を参考にしていただけると幸いです。

環境

  • Unity 2017.2.0f3

    • WebGL
  • AWS(無料枠)
    • EC2, S3

Unity WebGLでの開発について

クロスドメインとCORS

Unity内でサードパーティなどの外部連携の際、APIをWWWなどで処理させると思います。

WWWの処理は、Unityがビルドするプラットフォームに合わせて対応しているため、iOS/Androidだったらネイティブの通信処理に合わせた対応が行われており、WebGLはJavascriptのXMLHttpRequestで対応している模様。
WebGLでサードパーティなどの外部連携を行うと必ず、クロスドメイン問題が発生します。

今回のクロスドメイン問題の対応は、開発しているゲーム専用のAPIも開発していたので、そこを経由して外部連携することにしました。

 
   

 

検証: S3でCORSの設定について

S3には、外部からのアクセスを考慮するためCORSの設定があります。これは外部向けに設定するケースっぽいから、今回はその逆なので関係ナッシング。

PHPで説明するところの

header('Content-type: application/json');
header("Access-Control-Allow-Origin: *");

を対応しないと解決しないので、実は記事書いている時に気づいたものの、、ふぅ笑

だいたいの人がサーバーを用意することが多いよねー。

関連記事:
* WebGL WWW security (Cross-Origin Resource Sharing) help please
* Unity 5 の WebGL で外部からテクスチャを与える方法について調べてみた

HTTPS(SSL)

今回、プライベートでの開発でなるべくお金をかけて開発したくなかったため、AWSの1年間無料枠を前提に開発を進めていました。EC2にはパブリックDNS、S3にはリンクが用意されるので、ドメインを用意することなく動作確認までできちゃいます。

スクリーンショット 2018-01-21 13.45.08.png

スクリーンショット 2018-01-21 13.49.37.png

ただし、S3はhttpsでEC2はhttpなので、S3はAWSが提供しているSDKを使って、データのダウンロードをすることがありますが、直リンクで扱うことも全然あるので、セキュリティ関連で問題になったりならなかったり。

今回、EC2のパブリックDNSによって、「Mixed Content: The page at …」というエラーに遭遇しました。

Mixed Content: The page at …

実際には↓こんなエラーです。

スクリーンショット 2018-01-21 14.22.05.png

Wordpressでよく遭遇する問題としてよく見かけますが、今回の場合だと、サードパーティで扱われるAPI群が全てHttpsで用意されていたため、Httpで統一する方法が取れず、EC2のパブリックDNSでは限界がきた感じ。

対応方法

Route53でドメインを購入し、ACMでSSL証明書を発行してRoute53とロードバランサーと連携する方法になるかと思います。

まとめ

ここまでで大きなトピック2つをご紹介しました。
全て把握すると開発中でなくても情報さえ把握しておけば、今回のようなことは設計段階で解決する内容だと思います。
知っておけば設計段階で問題解決することは、どんな分野でも一緒ってことですねー。

特に経験者には敵いませんねぇ、、ホント笑
 

続きを読む

Amazon VPC勉強メモ

・ネットマスクは/28(14IP)-/16の範囲で利用可能
サブネットで利用できないIP
1. ネットワークアドレス(.0)
2. VPCルータ(.1)
3. Amazonが提供するDNS(.2)
4. AWSで予約されている(.3)
5. ブロードキャストアドレス(.255)

・VPC作成後はVPCアドレスブロックは変更できない

・同一リージョン内のAZは高速専用線でつながっている。リージョン間はインターネット経由

ネットワークACL(アクセスリスト)でネットワークレベルでのセキュリティソフトを設定

ENI(Elasticネットワークインターフェース)
EC2で利用するネットワークの仮想インターフェース
EC2ごとにENIを複数持つことが可能
下記の情報をENIに紐づけて維持可能
1. プライベートIP(固定の設定可能)
2. Elastic IP
3. MACアドレス
4. セキュリティグループ

Floating IP
サーバに障害が起こった際に、ENIを維持して対応する
※VPCではサブネットを超えてアドレスを付け替えることができない点に注意
参考URL:https://goo.gl/JKphCj

サブネット内のDHCP
サブネット内のENIにIPを自動割り当て
※プライベートIPを固定にした場合はDHCP経由で該当のIPが割り当てられる

・VPCで使えるAmazonが提供するDNS
169.254.169.253
VPCのネットワーク範囲のアドレスに+2をプラスしたIP

プライベートホストゾーン
VPC内のインスタンスのみ参照可能。Route53のプライベートホストゾーンを利用

インターネットゲートウェイ(IGW)
VPC内のリソースにインターネットの接続を提供。VPCにアタッチする
単一障害店や帯域幅のボトルネックはない

メインルートテーブルカスタムルートテーブル
メインルートテーブル:VPCを作成したときに自動的に割り当て
カスタムルートテーブル:任意で作成したルートテーブル。メインに変更することも可能

パブリックサブネットの設定
自動で割り当て:サブネットに自動割り当てを設定
固定で割り当て:Elastic IPをアタッチ

Elastic IP
費用がかかるのは下記の場合
1. 追加でEIPを利用する場合
2. 起動中のEC2インスタンスに割り当てられていないとき
3. アタッチされていないENIに割り当てられている場合
4. 1ヶ月でリマップ(割り当て、取り外し)が100回を超えた場合

NATゲートウェイ
プライベートサブネットのリソースがインターネットに通信するために必要
AZごとに設置するのがベストプラクティス

VPCエンドポイント
プライベートサブネットからS3バケットにアクセス可能
S3アクセスのためにIGWNATインスタンスが不要

バーチャルプライベートゲートウェイ(VGW)
オンプレミスとのVPN接続のためのエンドポイントとなる仮想ルータ。VPC側
単一障害点や帯域幅のボトルネックはなし

カスタマゲートウェイ(CGW)
オンプレミス側。AWSとのVPN接続のため

VPN接続
VGWCGW間でIPsecトンネルが設定

・VPC Peering

2 つの VPC 間でトラフィックをルーティングすることを可能にするネットワーク接続
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-peering.html

ネットワーク接続の最大送信単位 (MTU)に注意。VPC Peeringは1500

異なるAWSアカウントでも可能
但し、異なるリージョン間では使用できない

セキュリティグループ
仮想ファイアウォール
1つのEC2で5つのセキュリティグループが設定可能
デフォルトですべての通信は禁止
VPCぴあリング先のセキュリティグループが設定可能

ネットワークACLVSセキュリティグループ
ネットワークACL:サブネットレベルで効果。ステートレスなので戻りのトラフィックも明示的に許可設定
セキュリティグループ:サーバーレベルで効果。ステートフルなので戻りのトラフィックは気にしなくてよい

・オンプレミスとのハイブリッド構成
Direct Connectを使用する
VPCからオンプレミスへの通信をするためには、各サブネットのルートテーブルの設定が必要
宛先:オンプレミスのIP
ターゲット:VGWのID
VPNとDirect Connectで冗長可能。Direct Connectが優先

・VPC設計
アプリケーション/監査/フェーズ(本番/検証/開発)/部署などによる分割

VPC Flow Logs
ネットワークトラフィックをキャプチャ氏、CloudWatchへPublishする機能
ネットワークインターフェースを送信元/送信先とするトラフィックが対象
CloudWatch Logsの標準料金のみ課金
VPC Flow Logsで取得できない通信
1. Amazon DNSサーバへのトラフィック

・VPCのリミット
リージョン当たりのVPCの数:5
VPC当たりのサブネット:200
AWSアカウント当たり1リージョンのEIP:5
ルートテーブルあたりのルートの数:100
VPCあたりのセキュリティグループの数:500

参考URL:
http://kakakakakku.hatenablog.com/entry/2016/08/07/232305
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2016-amazon-vpc

続きを読む