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

Security HubのイベントをAWS ChatbotでSlackへ通知

$
0
0

表題の通りです。
Security Hubで検出されたアレやコレをSlackに流し込むようにします。

AWS Chatbot が一般公開されました!の記事では、CloudWatchアラームの内容をSlackに流していましたが、今回はCloudWatchイベントの内容をSlackに流します。

全体構成はこんなイメージ

Security Hubで集約したセキュリティ系イベントを自動的にSlackに通知したい場合、残念ながら直接はできません。
EventBridge、SNS、そしてAWS Chatbotを経由する必要があります。

1.SNS Topic作成

SNS Topicを作成します。
Topicの名前は指定する必要がありますが、その他のSubscription等の設定は不要です。

2.Event Bridge作成

イベントルール名
EventBridgeでイベントルールを作成します。
適当なルール名をつけます。

パターンを定義
Security Hubのイベントでフィルタするためにパターンを指定します。
今回はSecurity Hubの全イベントを対象にしてみました。

{
  "source": [
    "aws.securityhub"
  ]
}

ターゲットを選択
先ほど作成したSNS Topicへ転送されるようにターゲットを指定します。

3.AWS Chatbotの設定

AWS Chatbot > 設定済みクライアント > 新しいクライアントを設定

クライアントとしてSlackを指定

Slackワークスペースにログイン
ブラウザでSlackにログインしていない場合は、ログイン画面へのリダイレクトが発生します。

Slackワークスペースへアクセスする権限を与える
いろいろ書いてありますが、権限をカスタマイズはできず、AllowかCancelかの2択となります。

なお、このタイミングでSlackに登録しているメールアドレスに通知メールが送られてきます。
AWS Chatbotがワークスペースにインストールされたという内容になります。

AWS Chatbotの設定画面に自動的に戻ってきます。

AWS Chatbot > 設定済みクライアント > Slackワークスペース: > 新しいチャネルを設定

設定名

Slackチャネル
通知を流すチャネルを指定します。

アクセス許可
AWS ChatbotのサービスにアタッチするIAMロールを作成します。

デフォルトでは、ポリシーテンプレートが「通知のアクセス許可」となっています。今回はそのままで問題ありません。

なお、「通知のアクセス許可」の実際のポリシーは以下となります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "cloudwatch:Describe*",
                "cloudwatch:Get*",
                "cloudwatch:List*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

ちなみに説明を読むと、 AWS ChatbotがAmazon CloudWatchからメトリクスグラフを取得できるようになります。 とありますね。
今回はメトリクスグラフは関係ないので、このポリシーは削除してしまっても構いません。

通知
作成したSNS Topicを指定します。

4.Slackチャネルに@awsをinvite

このようなメッセージが表示されます。

メッセージに従い、AWS Chatbotで指定したチャネルの中で /invite @aws を実行しましょう。

これで設定完了です。

5.動作確認

Security Hubの検出結果がSlackに通知されるようにできました。


Box CLI でフォルダアップロード

$
0
0

こんにちは。
友人のハーレーダビッドソンに触発されて、とりあえず大型二輪免許を取得しようとしている設樂です。
バイクって、ベストシーズンが少ない気がするのは私だけでしょうか。それとも日本だけでしょうか。
春=強風&花粉症
夏=暑い
秋=快適
冬=寒い

今回は Box CLI を使って、Box へフォルダアップロード手順を紹介させていただきます。

事前準備

Box CLI のインストール Windows編を実施してください。

  • Box アプリケーションの作成
  • Box CLI のインストール

Box App User の確認

Box App User を確認します。

  1. Box CLI コマンドの入力
    box users:get me
  2. Box App User 情報の確認
    Type: user
    ID: ‘123456789’
    Name: box-app
    Login: AutomationUser_1234567_ABCDEFGHIJ@boxdevedition.com
    Created At: ‘2020-04-20T04:20:00-00:00’
    Modified At: ‘2020-04-20T04:20:00-00:00’
    Language: ja
    Timezone: Asia/Tokyo
    Space Amount: 0
    Space Used: 0
    Max Upload Size: 16106127360
    Status: active
    Job Title: ”
    Phone: ”
    Address: ”
    Avatar URL: ‘https://serverworks.app.box.com/api/avatar/large/123456789’
    Notification Email: []
  3. Box App User の確認
    AutomationUser_1234567_ABCDEFGHIJ@boxdevedition.com

Box フォルダの共有

Box 管理者が Box App User に対してフォルダを共有します。

  1. 共有したいフォルダに移動し、[このフォルダを共有]をクリック
  2. Box App User の招待

フォルダアップロード

Box CLI でローカルフォルダを Box フォルダにアップロードします。
フォルダ内のすべてのファイルのアップロード

  1. Box App User に共有されているフォルダの確認
    box folders:get 0
  2. アップロードしたい共有フォルダ情報の確認
    Type: folder
    ID: ‘111846215691’
    Sequence ID: ‘1’
    ETag: ‘1’
    Name: 月次ディレクトリ数
    Offset: 0
    Limit: 100
    Order:
  3. 共有フォルダIDの確認
    111846215691
  4. 共有フォルダにアップロード
    box folders:upload C:\Users\Administrator\Box --parent-folder=111846215691
  5. アップロード結果の確認

まとめ

上記の方法で Box CLI を使って Box フォルダにアップロードができます。
Box App User 情報の取得と招待が重要な部分だと思っています。
それでは、良き Box Life をお過ごしください。

Amazon Transcribe がリアルタイム文字起こしの語彙フィルタリングをサポートしました

$
0
0

はじめに

こんにちは、技術1課の山中です。
今日は中本の蒙古タンメンをデリバリーで頼んでみたのですが、とても辛くてかなりテンションが下がっています。
※味は美味しいのですが、辛いのが苦手なことを失念しておりました。

というのはさておき!
今回はこのアップデートについて見ていきます!

Amazon Transcribe がリアルタイムの文字起こしの語彙フィルタリングのサポートを開始

Amazon Transcribe

Amazon Transcribe (以下、 Transcribe) は、音声をテキストに変換する AWS の音声認識サービスです。
保存された音声ファイルだけでなく、リアルタイム変換にも対応しています。

語彙フィルタリング

Transcribe を利用して文字起こしする場合、事前に登録しておいた単語を特定し、フィルタリングしてくれます。
これまでは、保存された音声ファイルに対して実行するジョブ (バッチ処理) でのフィルタリングにのみ対応していましたが、今回のアップデートでリアルタイムの文字起こし (リアルタイム処理) でも利用できるようになりました。
また、バッチ処理とリアルタイム処理では以下の点でで違いがあります。

フィルタリングされた単語の処理 バッチ処理 リアルタイム処理
3 つのアスタリスク *** に置き換える (マスキング)
削除する
タグ付けする

リアルタイム処理では特定の単語に対してタグ付ができるため、ユーザの特性に合わせて見せる、見せないなど文字起こし結果のカスタマイズが柔軟に可能です。
※ 大人のユーザにはそのまま見せて、未成年のユーザにはマスキングする

対応言語

2020年5月現在、リアルタイム文字起こしに対応している言語は以下のとおりです。

  • Australian English (en-AU)
  • British English (en-GB)
  • US English (en-US)
  • French (fr-FR)
  • Canadian French (fr-CA)
  • US Spanish (es-US)

ただし、 API ではなくマネジメントコンソール上で実行する場合は、 US English (en-US) 及び US Spanish (es-US) のみ選択可能でした。

How Amazon Transcribe Works – Amazon Transcribe

対応リージョン

Amazon Transcribe ストリーミングサービスが利用できるすべてのリージョンで利用可能です。
対応リージョンの明確なドキュメントは探しても見当たらなかったのですが、マネジメントコンソールで確認したところ以下リージョンは対応していました。

  • バージニア北部
  • オハイオ
  • オレゴン
  • シドニー
  • カナダ
  • アイルランド

料金

リアルタイム文字起こしの語彙フィルタリングは追加料金なしでご利用いただきます。

試してみる

早速リアルタイム文字起こしの語彙フィルタリングを試してみましょう。
今回は バージニア北部 リージョンにて試してみます。

語彙フィルターファイルの作成

フィルタリング対象の単語を指定するためのファイルを作成します。
今回は以下の内容を samplewords.txt として作成しておきました。

hyper
super

語彙フィルターの作成

作成したテキストファイルを取り込み、語彙フィルターを作成します。
マネジメントコンソールで Transcribe にアクセスし、左ペインから Vocabulary filtering を選択します。

Create vocabulary filter ボタンをクリックします。

Nameにフィルタ名を入力し、 Language は English, US (en-US) を選択します。
また、 Choose File から先ほど用意したテキストファイル samplewords.txt を指定して、 Create vocabulary filter ボタンをクリックします。

これで語彙フィルターの作成は完了です。

リアルタイムストリームの設定

続いて左ペインから Real-time transcription を選択し、リアルタイムストリームの設定を行っていきます。

Additional settings を展開し、 Vocabulary filtering をオンにします。

Filter selection で作成した語彙フィルター sample-vf を選ぶとリアルタイムストリームに対応する 3 つのメソッドが表示されます。

Mask vocabulary を指定すると、フィルタリングされた単語はアスタリスクでマスクされます。
Remove vocabulary を指定すると、フィルタリングされた単語は削除されます。
Tag vocabulary を指定すると、指定した単語にタグ付けされます。
今回は、一番イメージが湧きづらいタグ付を試してみたいので、 Tag vocabulary を選択しておきます。

リアルタイムストリームの開始

準備が完了したので、音声を入力していきましょう。
今回はお試しということで、以下を読み上げます。

We are a Cloud integrator, who provides hyper integration businesses and services specialized for AWS (Amazon Web Services). In 2009, we started AWS integration businesses. In 2014, we became 1st Japanese company to acquire Managed Service Provider Competency in AWS Partner Network ("APN"). In addition, we were elected to become APN Premium Consulting Partner, which is a highest tier consulting partner for AWS, and we became well-known company that is continuously making super advanced efforts in this field.

Start streaming ボタンをクリックすると音声の入力待ちになります。

ボタンをクリック

音声を入力し、 Stop streaming ボタンをクリック

フィルターに登録した、 hypersuper が検出されて斜線になっていることがわかります。

Download full transcript ボタンをクリックし、文字起こし結果をダウンロードしてみましょう。

ダウンロードした json ファイルを開いてみると VocabularyFilterMatch の項目が hypersuperだけ true となっていることがわかります。
※ 69 行目および 112 行目

[
    {
        "Transcript": {
            "Results": []
        }
    },
… (中略) …
    {
        "Transcript": {
            "Results": [
                {
                    "Alternatives": [
                        {
                            "Items": [
                                {
                                    "Content": "We",
                                    "EndTime": 5.14,
                                    "StartTime": 5.11,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": "are",
                                    "EndTime": 5.32,
                                    "StartTime": 5.15,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": "cloud",
                                    "EndTime": 5.68,
                                    "StartTime": 5.33,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": "into",
                                    "EndTime": 5.88,
                                    "StartTime": 5.69,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": "greater",
                                    "EndTime": 6.24,
                                    "StartTime": 5.89,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": "who",
                                    "EndTime": 6.64,
                                    "StartTime": 6.47,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": "provides",
                                    "EndTime": 7.1,
                                    "StartTime": 6.65,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": "hyper",
                                    "EndTime": 7.46,
                                    "StartTime": 7.11,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": true
                                },
                                {
                                    "Content": "into",
                                    "EndTime": 7.68,
                                    "StartTime": 7.47,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                }
                            ],
                            "Transcript": "We are cloud into greater who provides hyper into"
                        }
                    ],
                    "EndTime": 7.72,
                    "IsPartial": true,
                    "ResultId": "aee77e53-ee01-41f1-86b0-047626d02d93",
                    "StartTime": 5.11
                }
            ]
        }
    },
… (中略) …
    {
        "Transcript": {
            "Results": [
                {
                    "Alternatives": [
                        {
                            "Items": [
                                {
… (中略) …
                                {
                                    "Content": "making",
                                    "EndTime": 38.33,
                                    "StartTime": 38.01,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": "super",
                                    "EndTime": 38.66,
                                    "StartTime": 38.34,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": true
                                },
                                {
                                    "Content": "advanced",
                                    "EndTime": 39.16,
                                    "StartTime": 38.67,
                                    "Type": "pronunciation",
                                    "VocabularyFilterMatch": false
                                },
                                {
                                    "Content": ".",
                                    "EndTime": 39.16,
                                    "StartTime": 39.16,
                                    "Type": "punctuation",
                                    "VocabularyFilterMatch": false
                                }
                            ],
                            "Transcript": "And we became well known companies that is continuously making super advanced."
                        }
                    ],
                    "EndTime": 39.2,
                    "IsPartial": true,
                    "ResultId": "4e664e13-ebb9-470b-8602-87557645efc9",
                    "StartTime": 35.39
                }
            ]
        }
    },
… (中略) …
]

きちんとフィルターが機能していることがわかりました!!

おわりに

Transcribe の語彙フィルタリングがリアルタイムストリームに対応したことで、これまでよりももっと柔軟に文字起こしが実現できそうです。

また、この内容は 2020/5/27(水) 12:00 よりYouTube Liveで配信する「30分でわかる AWS UPDATE!」で取り上げますますので、是非ご覧ください!

参考

S3 のライフサイクルポリシー以外で削除させないようにして経過を見守る

$
0
0

こんにちは。技術4課の保田(ほだ)です。

在宅勤務に伴いずっと家にいるので7年ぶりに自炊を再開しました。でもちゃんと作るのが面倒なので海外の調味料などを飛び道具として、日々よく分からない強い味の料理を食べています。

要約

S3 のオブジェクトをライフサイクルポリシー以外で削除させないようにして経過を見守った

導入

S3 にはライフサイクルポリシーという、一定期間が経過すると別のストレージクラスに移行したり、有効期限を設定して自動的にオブジェクトを削除したりして主に保管コストを削減できる機能があります。

また、S3 にはバージョニング機能というものもあり、複数のバージョンを保持することができます。これによって、意図しないオブジェクトの変更や削除から保護することができます。

バージョニングを有効にすると、オブジェクトを削除しても表向きは消えたように見えますが、実際には削除マーカーで上書きされているだけでオブジェクト自体にはアクセスできます。

このバージョニングとライフサイクルを併用すると、一定期間が経過すると過去のバージョンを永久的に削除したり、最新のバージョンを有効期限切れにする(削除マーカーの作成)、といったことが可能になります。

そしてバケットポリシーを使用するとバケットやバケット内のオブジェクトに対する API アクションに制限を設けられます。

今回はこれらを駆使して、ライフサイクルポリシー以外の方法ではオブジェクトを削除できないようにしてみます。

バージョニングの有効化

バージョニングを有効にします。マネコンポチポチお手軽です。

ライフサイクルの設定

prefix が archive であるようなオブジェクトを1日で最新のバージョンと以前のバージョンを期限切れにするよう設定します。

ここの期限切れ時間の算出方法については若干の注意が必要です。今回は1日と設定しましたが、これは明日になったら削除される、というわけではありません。

ライフサイクルルールに指定された日数(今回は1日)をオブジェクトの作成時刻に加算し、それを翌日の 00:00 UTC (日本時間では 9:00)に丸めることで算出します。

したがって、2020 年 5 月 18 日の 19:28:14 JST にオブジェクトを作成した場合、ルールに設定した1日が経過したうえでその翌日の 00:00 UTC になるので、有効期限は 2020 年 5 月 20 日の 9:00:00 JST です。ここで「削除されるのは」と書かなかったのは実際にオブジェクトが削除されるのはこの有効期限に対して遅延が発生する可能性があるためです。(参考:https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/how-to-set-lifecycle-configuration-intro.html

また、バージョニングと併用した場合は、オブジェクトが最後に更新された時点(最終更新日時)から先ほどのようなやり方で有効期限を算出します。つまり1日で以前のバージョンを削除する設定にしたとして、2020 年 5 月 18 日の 19:28:14 JST にオブジェクトを最終更新した場合、有効期限は 2020 年 5 月 20 日の 9:00:00 JST になります。

ドキュメントにも記載はありますがちょいとややこしいですね。

バケットポリシーの設定

root ユーザー以外には削除させないようにします。以下のようなバケットポリシーを適用します。xxxxx にはバケット名が、 012345678901 には AWS アカウントの ID が入ります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "statement1",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "s3:DeleteObject",
                "s3:DeleteObjectVersion",
                "s3:PutLifeCycleConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::xxxxxx",
                "arn:aws:s3:::xxxxxx/archive/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "aws:userId": [
                        "012345678901"
                    ]
                }
            }
        }
    ]
}

ここで明示的に拒否している API アクションについては以下のドキュメントを参考にしました。

ユーザーやアカウントがオブジェクトを削除することを明示的に禁止する場合は、s3:DeleteObjects3:DeleteObjectVersion、および s3:PutLifecycleConfiguration のアクセス許可を明示的に拒否する必要があります。

ここで、 s3:DeleteObject アクションを明示的に禁止していますが、ライフサイクルポリシーによるオブジェクトの削除は内部の S3 エンドポイントを使用して実行されるため、このバケットポリシーの影響を受けません。なのでちゃんと削除されます。

また、このライフサイクルによって実行される API アクションは CloudTrail ではキャプチャされません。(参考:https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/lifecycle-and-other-bucket-config.html#lifecycle-general-considerations-logging

オブジェクトをアップロードする

prefix が archive であるようなオブジェクト test.txt を作成します。つまりオブジェクトのキーは archive/test.txt です。

中身は適当でいいでしょう。

$ cat test.txt
init

アップロードします。

そしてバージョニングによる効果も確認したいので、複数バージョン作成します。

$ cat test.txt
version2

これもアップロードします。

こんな感じです。バージョニングされてる感が伝わってきますね。

二晩寝かせる

ここまでの手順で、archive という prefix 下にアップロードされたオブジェクトは、作成されてから1日の有効期限をもって以前のバージョンが完全に削除され、最新版が削除マーカーで上書きされ、しかもその期限までは root ユーザー以外は消したりライフサイクルポリシーを弄ったりバージョニングを無効にしたり、ができないようになりました。

削除されるのは2日後なのでそれまで待ちます。

2日経ちました。

古いバージョンが削除されて、最新のバージョンとして削除マーカーが上書きされてますね。日本時間の 9:00 に削除されているように見えますが、前述の通り実際にはラグがあるので、3~4時間程度かかっていました。

ちなみにこの段階でマネジメントコンソールのバージョンを非表示にするオプションを選ぶと prefix 含め何もないように見えます。

マネジメントコンソールからフォルダオブジェクトを作成した場合、 prefix 以下に配置したオブジェクトを削除してもフォルダオブジェクトは残るのですが、ライフサイクルだと prefix も消えてしまうみたいです。

さらに二晩寝かせる

まだ続きがあります。さらに二晩寝かせるとどうなるでしょうか。

2日経ちました。

まず削除マーカーで上書きされたことで、その直前のバージョンが最新版ではなくなります(削除マーカーが最新バージョン)。
なので、ライフサイクル設定によってこの削除マーカーで上書きされた時点から1日の有効期限が設定され、以前のバージョンが完全に削除されます。
その結果として削除マーカーのみが残る状態になります。
今回も削除されるまで3時間程度のラグがありました。

どうやら「最新版を失効する」というルールは削除マーカーには適用されないみたいですね。

翌日

最終段階がありました。

削除マーカーだけになった翌日。

削除マーカーも消えており、画像のようにバージョニングを有効にした表示でも何も確認できなくなりました。

実はライフサイクル設定の画面上にて、現行バージョンを失効させる設定にする(画像左上の 現行バージョン にチェックを入れる)と 期限切れのオブジェクト削除マーカーをクリーンアップする にはチェックが入れられなくなります。

「有効期限を有効にする場合、期限切れのオブジェクト削除マーカーのクリーンアップを有効にすることはできません」という表示もされます。

当初は削除マーカーだけ残るのかと思っていましたが、おそらく有効期限を設定することがすなわち削除マーカーだけ残っても最終的には削除されることと同義になるため、「クリーンアップする」チェックボックスが意味をなさないから有効にできないのだと思われます。

とはいえ削除マーカーが最終更新(作成)された時点から、最新版が1日で失効するライフサイクルに照らして言えば前日の段階で消えていてもおかしくないのでこの点についてはまだ検証の余地がありそうです。

結果

長くなってしまいましたが、冒頭のような設定をすることで

  • ルートユーザー以外によるオブジェクト削除を拒否
  • 一定期間は過去のバージョンを取得可能
  • ライフサイクルにより一定期間で自動的に完全に削除

という設定が可能であることがわかりました。

まとめ

S3 は Simple Strage Service という名前の割りにできることがめちゃくちゃ多くて、組み合わさると実際どういう挙動になるのかわからなくなったりしますよね。今回はほんの一部ですが、複数の機能を組み合わせてどんな挙動になるのかを見てみました。これが何かしら参考になる方がいらっしゃったら幸いです。

Amazon VPCでBYOIPv6のサポートが開始されました(東京リージョン含む)!

$
0
0

こんにちは、技術1課の小倉です。
2020/5/21にアップデートがあり、Amazon VPCでBYOIPv6のサポートが開始されました(東京リージョン含む)!

Amazon Virtual Private Cloud (VPC) で独自 IPv6 アドレスの持ち込み (BYOIPv6) のサポートを開始

2019/11/13にBYOIPで所有しているIPv4アドレスをAWSへ持ち込みができるようになったのですが、今回はIPv6アドレスが持ち込み可能になりました。また持ち込みによる追加料金はかかりません。

AWSへ移行後も同じIPアドレスを使うメリット

  • AWS移行時の変更が最小限で済む
    • オンプレミスから別拠点に通信するときにファイアウォールなどで通信を制御していても設定変更なし
    • アプリケーションなどでIPアドレスをハードコーディングしていて変更が難しいとき

注意点

  • オンプレミスで利用中のIPアドレスの場合は、AWSへIPアドレスの持ち込み時にサービス断が発生する
    • インターネット内のルーティングをオンプレミスからAWSへ変更するのに時間がかかる(最大24時間)

設定手順

AWSへIPv6アドレスを持ち込む

手順は以下に記載されています。

Bring your own IP addresses (BYOIP)
※言語を日本語にするとIPv4の持ち込み手順のみ表示されます。

手順の要件に以下のように記載されています。インターネットから通信できるものは/48、できないものは/56のCIDRが最大。おそらくどちらもグローバルユニキャストアドレスだけど、インターネットに経路広告をしないで内部向けに使うこともできるようです。

The most specific IPv6 address range that you can bring is /48 for CIDRs that are publicly advertised, and /56 for CIDRs that are not publicly advertised.

AWSに持ち込んだIPv6を使う

持ち込んだIPv6アドレスを使うには、VPCにIPv6のCIDRブロックを追加します。

マネジメントコンソールでVPCを開きます。
IPv6を利用するVPCを選択して、 [アクション] – [CIDRの編集]をクリックします。

 

CIDRの編集画面で、[IPv6 CIDRの追加]をクリックします。

Add IPv6 CIDR画面で、[IPv6 CIDR owned by me]を選択し、Poolのプルダウンから追加するIPv6アドレスを選択します。
(私はIPv6アドレスを所有していませんので、実行結果をお見せすることができません)

 

まとめ

Amazon VPCでBYOIPv6のサポートが開始されました。IPv6を利用している方は少ないかもしれませんが、現在、オンプレミスで利用している方は同じIPアドレスのままAWSへ移行することができます。IPアドレスの変更が支障となってクラウドの利用をあきらめていた方はAWSへの移行を検討してみてはいかがでしょうか。

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

[2020/5/26版] 東京リージョンで構築可能なインスタンスタイプのアベイラビリティーゾーン別一覧表

$
0
0

SRE部 佐竹です。
こちらの記事は以前2019年4月10日に投稿させて頂きました記事「[EC2]東京リージョンで構築可能なインスタンスタイプのアベイラビリティーゾーン別一覧表」の更新版となります。

はじめに

今回は以下のリリースを受けての更新となります。

AWS Graviton2 プロセッサを搭載した Amazon EC2 M6g インスタンスが一般利用可能に
https://aws.amazon.com/jp/about-aws/whats-new/2020/05/amazon-ec2-m6g-instances-powered-by-aws-graviton2-processors-generally-available/

>M6g インスタンスは、AWS の米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト、アイルランド)、アジアパシフィック (東京) の各リージョンでご利用いただけるようになりました

補足となりますが、「前回の2019/9/11版」と同様に「こちら」の公式ドキュメントの英語版に記載があるInstance Typeの一覧が、それぞれ東京リージョンの全アベイラビリティーゾーン(AZ)で構築が可能か「aws ec2 run-instances」の –dry-run オプションを利用して確認します。詳しくは「[EC2]東京リージョンで構築可能なインスタンスタイプのアベイラビリティーゾーン別一覧表」をご覧ください。

結果(アベイラビリティーゾーン別一覧表)

以下に結果を表示します。なお以下に存在していない「apne1-az3」は、現在Subnetの作成もできないクローズされたアベイラビリティーゾーンですので、結果からは省いております。また前回のブログとの差分は赤字で示しております。

Instance Type 1a (apne1-az4) 1c (apne1-az1) 1d (apne1-az2)
a1.medium 成功 他のAZで構築可能 成功
a1.large 成功 他のAZで構築可能 成功
a1.xlarge 成功 他のAZで構築可能 成功
a1.2xlarge 成功 他のAZで構築可能 成功
a1.4xlarge 成功 他のAZで構築可能 成功
a1.metal 成功 他のAZで構築可能 成功
m4.large 成功 成功 成功
m4.xlarge 成功 成功 成功
m4.2xlarge 成功 成功 成功
m4.4xlarge 成功 成功 成功
m4.10xlarge 成功 成功 成功
m4.16xlarge 成功 成功 成功
m5.large 成功 成功 成功
m5.xlarge 成功 成功 成功
m5.2xlarge 成功 成功 成功
m5.4xlarge 成功 成功 成功
m5.8xlarge 成功 成功 成功
m5.12xlarge 成功 成功 成功
m5.16xlarge 成功 成功 成功
m5.24xlarge 成功 成功 成功
m5.metal 成功 成功 成功
m5a.large 成功 成功 成功
m5a.xlarge 成功 成功 成功
m5a.2xlarge 成功 成功 成功
m5a.4xlarge 成功 成功 成功
m5a.8xlarge 成功 成功 成功
m5a.12xlarge 成功 成功 成功
m5a.16xlarge 成功 成功 成功
m5a.24xlarge 成功 成功 成功
m5ad.large 成功 成功 成功
m5ad.xlarge 成功 成功 成功
m5ad.2xlarge 成功 成功 成功
m5ad.4xlarge 成功 成功 成功
m5ad.8xlarge 成功 成功 成功
m5ad.12xlarge 成功 成功 成功
m5ad.16xlarge 成功 成功 成功
m5ad.24xlarge 成功 成功 成功
m5d.large 成功 成功 成功
m5d.xlarge 成功 成功 成功
m5d.2xlarge 成功 成功 成功
m5d.4xlarge 成功 成功 成功
m5d.8xlarge 成功 成功 成功
m5d.12xlarge 成功 成功 成功
m5d.16xlarge 成功 成功 成功
m5d.24xlarge 成功 成功 成功
m5d.metal 成功 成功 成功
m5dn.large 他のAZで構築可能 成功 成功
m5dn.xlarge 他のAZで構築可能 成功 成功
m5dn.2xlarge 他のAZで構築可能 成功 成功
m5dn.4xlarge 他のAZで構築可能 成功 成功
m5dn.8xlarge 他のAZで構築可能 成功 成功
m5dn.12xlarge 他のAZで構築可能 成功 成功
m5dn.16xlarge 他のAZで構築可能 成功 成功
m5dn.24xlarge 他のAZで構築可能 成功 成功
m5n.large 他のAZで構築可能 成功 成功
m5n.xlarge 他のAZで構築可能 成功 成功
m5n.2xlarge 他のAZで構築可能 成功 成功
m5n.4xlarge 他のAZで構築可能 成功 成功
m5n.8xlarge 他のAZで構築可能 成功 成功
m5n.12xlarge 他のAZで構築可能 成功 成功
m5n.16xlarge 他のAZで構築可能 成功 成功
m5n.24xlarge 他のAZで構築可能 成功 成功
m6g.medium 成功 成功 他のAZで構築可能
m6g.large 成功 成功 他のAZで構築可能
m6g.xlarge 成功 成功 他のAZで構築可能
m6g.2xlarge 成功 成功 他のAZで構築可能
m6g.4xlarge 成功 成功 他のAZで構築可能
m6g.8xlarge 成功 成功 他のAZで構築可能
m6g.12xlarge 成功 成功 他のAZで構築可能
m6g.16xlarge 成功 成功 他のAZで構築可能
m6g.metal 成功 成功 他のAZで構築可能
t2.nano 成功 成功 成功
t2.micro 成功 成功 成功
t2.small 成功 成功 成功
t2.medium 成功 成功 成功
t2.large 成功 成功 成功
t2.xlarge 成功 成功 成功
t2.2xlarge 成功 成功 成功
t3.nano 成功 成功 成功
t3.micro 成功 成功 成功
t3.small 成功 成功 成功
t3.medium 成功 成功 成功
t3.large 成功 成功 成功
t3.xlarge 成功 成功 成功
t3.2xlarge 成功 成功 成功
t3a.nano 成功 他のAZで構築可能 成功
t3a.micro 成功 他のAZで構築可能 成功
t3a.small 成功 他のAZで構築可能 成功
t3a.medium 成功 他のAZで構築可能 成功
t3a.large 成功 他のAZで構築可能 成功
t3a.xlarge 成功 他のAZで構築可能 成功
t3a.2xlarge 成功 他のAZで構築可能 成功
c4.large 成功 成功 成功
c4.xlarge 成功 成功 成功
c4.2xlarge 成功 成功 成功
c4.4xlarge 成功 成功 成功
c4.8xlarge 成功 成功 成功
c5.large 成功 成功 成功
c5.xlarge 成功 成功 成功
c5.2xlarge 成功 成功 成功
c5.4xlarge 成功 成功 成功
c5.9xlarge 成功 成功 成功
c5.12xlarge 成功 成功 成功
c5.18xlarge 成功 成功 成功
c5.24xlarge 成功 成功 成功
c5.metal 成功 成功 成功
c5d.large 成功 成功 成功
c5d.xlarge 成功 成功 成功
c5d.2xlarge 成功 成功 成功
c5d.4xlarge 成功 成功 成功
c5d.9xlarge 成功 成功 成功
c5d.12xlarge 成功 成功 成功
c5d.18xlarge 成功 成功 成功
c5d.24xlarge 成功 成功 成功
c5d.metal 成功 成功 成功
c5n.large 成功 成功 成功
c5n.xlarge 成功 成功 成功
c5n.2xlarge 成功 成功 成功
c5n.4xlarge 成功 成功 成功
c5n.9xlarge 成功 成功 成功
c5n.18xlarge 成功 成功 成功
c5n.metal 成功 成功 成功
r4.large 成功 成功 成功
r4.xlarge 成功 成功 成功
r4.2xlarge 成功 成功 成功
r4.4xlarge 成功 成功 成功
r4.8xlarge 成功 成功 成功
r4.16xlarge 成功 成功 成功
r5.large 成功 成功 成功
r5.xlarge 成功 成功 成功
r5.2xlarge 成功 成功 成功
r5.4xlarge 成功 成功 成功
r5.8xlarge 成功 成功 成功
r5.12xlarge 成功 成功 成功
r5.16xlarge 成功 成功 成功
r5.24xlarge 成功 成功 成功
r5.metal 成功 成功 成功
r5a.large 成功 成功 成功
r5a.xlarge 成功 成功 成功
r5a.2xlarge 成功 成功 成功
r5a.4xlarge 成功 成功 成功
r5a.8xlarge 成功 成功 成功
r5a.12xlarge 成功 成功 成功
r5a.16xlarge 成功 成功 成功
r5a.24xlarge 成功 成功 成功
r5ad.large 成功 他のAZで構築可能 成功
r5ad.xlarge 成功 他のAZで構築可能 成功
r5ad.2xlarge 成功 他のAZで構築可能 成功
r5ad.4xlarge 成功 他のAZで構築可能 成功
r5ad.8xlarge 成功 他のAZで構築可能 成功
r5ad.12xlarge 成功 他のAZで構築可能 成功
r5ad.16xlarge 成功 他のAZで構築可能 成功
r5ad.24xlarge 成功 他のAZで構築可能 成功
r5d.large 成功 成功 成功
r5d.xlarge 成功 成功 成功
r5d.2xlarge 成功 成功 成功
r5d.4xlarge 成功 成功 成功
r5d.8xlarge 成功 成功 成功
r5d.12xlarge 成功 成功 成功
r5d.16xlarge 成功 成功 成功
r5d.24xlarge 成功 成功 成功
r5d.metal 成功 成功 成功
r5dn.large 他のAZで構築可能 成功 成功
r5dn.xlarge 他のAZで構築可能 成功 成功
r5dn.2xlarge 他のAZで構築可能 成功 成功
r5dn.4xlarge 他のAZで構築可能 成功 成功
r5dn.8xlarge 他のAZで構築可能 成功 成功
r5dn.12xlarge 他のAZで構築可能 成功 成功
r5dn.16xlarge 他のAZで構築可能 成功 成功
r5dn.24xlarge 他のAZで構築可能 成功 成功
r5n.large 他のAZで構築可能 成功 成功
r5n.xlarge 他のAZで構築可能 成功 成功
r5n.2xlarge 他のAZで構築可能 成功 成功
r5n.4xlarge 他のAZで構築可能 成功 成功
r5n.8xlarge 他のAZで構築可能 成功 成功
r5n.12xlarge 他のAZで構築可能 成功 成功
r5n.16xlarge 他のAZで構築可能 成功 成功
r5n.24xlarge 他のAZで構築可能 成功 成功
u-6tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
u-9tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
u-12tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
u-18tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
u-24tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
x1.16xlarge 成功 成功 成功
x1.32xlarge 成功 成功 成功
x1e.xlarge 成功 成功 他のAZで構築可能
x1e.2xlarge 成功 成功 他のAZで構築可能
x1e.4xlarge 成功 成功 他のAZで構築可能
x1e.8xlarge 成功 成功 他のAZで構築可能
x1e.16xlarge 成功 成功 他のAZで構築可能
x1e.32xlarge 成功 成功 他のAZで構築可能
z1d.large 成功 成功 成功
z1d.xlarge 成功 成功 成功
z1d.2xlarge 成功 成功 成功
z1d.3xlarge 成功 成功 成功
z1d.6xlarge 成功 成功 成功
z1d.12xlarge 成功 成功 成功
z1d.metal 成功 成功 成功
d2.xlarge 成功 成功 成功
d2.2xlarge 成功 成功 成功
d2.4xlarge 成功 成功 成功
d2.8xlarge 成功 成功 成功
h1.2xlarge 東京Region未対応 東京Region未対応 東京Region未対応
h1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
h1.8xlarge 東京Region未対応 東京Region未対応 東京Region未対応
h1.16xlarge 東京Region未対応 東京Region未対応 東京Region未対応
hi1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
i3.large 成功 成功 成功
i3.xlarge 成功 成功 成功
i3.2xlarge 成功 成功 成功
i3.4xlarge 成功 成功 成功
i3.8xlarge 成功 成功 成功
i3.16xlarge 成功 成功 成功
i3.metal 成功 成功 成功
i3en.large 成功 成功 成功
i3en.xlarge 成功 成功 成功
i3en.2xlarge 成功 成功 成功
i3en.3xlarge 成功 成功 成功
i3en.6xlarge 成功 成功 成功
i3en.12xlarge 成功 成功 成功
i3en.24xlarge 成功 成功 成功
i3en.metal 成功 成功 成功
f1.2xlarge 東京Region未対応 東京Region未対応 東京Region未対応
f1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
f1.16xlarge 東京Region未対応 東京Region未対応 東京Region未対応
g3s.xlarge 成功 成功 他のAZで構築可能
g3.4xlarge 成功 成功 他のAZで構築可能
g3.8xlarge 成功 成功 他のAZで構築可能
g3.16xlarge 成功 成功 他のAZで構築可能
g4dn.xlarge 成功 他のAZで構築可能 成功
g4dn.2xlarge 成功 他のAZで構築可能 成功
g4dn.4xlarge 成功 他のAZで構築可能 成功
g4dn.8xlarge 成功 他のAZで構築可能 成功
g4dn.12xlarge 成功 他のAZで構築可能 成功
g4dn.16xlarge 成功 他のAZで構築可能 成功
p2.xlarge 成功 成功 他のAZで構築可能
p2.8xlarge 成功 成功 他のAZで構築可能
p2.16xlarge 成功 成功 他のAZで構築可能
p3.2xlarge 成功 成功 他のAZで構築可能
p3.8xlarge 成功 成功 他のAZで構築可能
p3.16xlarge 成功 成功 他のAZで構築可能
p3dn.24xlarge 成功 他のAZで構築可能 他のAZで構築可能
inf1.xlarge 東京Region未対応 東京Region未対応 東京Region未対応
inf1.2xlarge 東京Region未対応 東京Region未対応 東京Region未対応
inf1.6xlarge 東京Region未対応 東京Region未対応 東京Region未対応
inf1.24xlarge 東京Region未対応 東京Region未対応 東京Region未対応
m1.small 成功 成功 他のAZで構築可能
m1.medium 成功 成功 他のAZで構築可能
m1.large 成功 成功 他のAZで構築可能
m1.xlarge 成功 成功 他のAZで構築可能
m3.medium 成功 成功 他のAZで構築可能
m3.large 成功 成功 他のAZで構築可能
m3.xlarge 成功 成功 他のAZで構築可能
m3.2xlarge 成功 成功 他のAZで構築可能
t1.micro 成功 成功 他のAZで構築可能
c1.medium 成功 成功 他のAZで構築可能
c1.xlarge 成功 成功 他のAZで構築可能
cc1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
cc2.8xlarge 成功 成功 他のAZで構築可能
cg1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c3.large 成功 成功 他のAZで構築可能
c3.xlarge 成功 成功 他のAZで構築可能
c3.2xlarge 成功 成功 他のAZで構築可能
c3.4xlarge 成功 成功 他のAZで構築可能
c3.8xlarge 成功 成功 他のAZで構築可能
m2.xlarge 成功 成功 他のAZで構築可能
m2.2xlarge 成功 成功 他のAZで構築可能
m2.4xlarge 成功 成功 他のAZで構築可能
cr1.8xlarge 東京Region未対応 東京Region未対応 東京Region未対応
r3.large 成功 成功 他のAZで構築可能
r3.xlarge 成功 成功 他のAZで構築可能
r3.2xlarge 成功 成功 他のAZで構築可能
r3.4xlarge 成功 成功 他のAZで構築可能
r3.8xlarge 成功 成功 他のAZで構築可能
hs1.8xlarge 東京Region未対応 東京Region未対応 東京Region未対応
i2.xlarge 成功 成功 他のAZで構築可能
i2.2xlarge 成功 成功 他のAZで構築可能
i2.4xlarge 成功 成功 他のAZで構築可能
i2.8xlarge 成功 成功 他のAZで構築可能
g2.2xlarge 成功 成功 他のAZで構築可能
g2.8xlarge 成功 成功 他のAZで構築可能

前回からの変更点

  • m6g が東京リージョンに対応しました。ただし 1d では構築できません

まとめ

新しい Instance Family は 1d に先に追加されるイメージでしたが (現在も a1 は 1c で構築できません) 、今回は 1d では利用できず、 1a, 1c で利用可能となっていました。利用される場合は、念のためご注意ください。
簡単ですが、以上になります。

[Docker入門]Dockerを使ってコンテナを触ってみよう:Dockerの使い方の基本

$
0
0

はじめに

こんにちは。孔子の80代目子孫兼技術5課の孔です。最近、仕事でActive Directoryとの死闘を続けた結果、チョットワカル程度までレベルアップすることができました。こんなに認証、認可って奥が深いものなのか…と感動している最近です。ADも一段落ついたので、今日はこちらDockerのブログを更新したいと思います!

先日までの内容を復習してみましょう。1回目のブログではDockerとは、イメージとは、そしてレイヤーとは何かについて説明しました。そして2回目のブログではリポジトリとDockerfile、そしてビルドについてお話ししましたね!今日は実際Dockerを使って前回と前々回お話しした内容をDockerを使って確認しつつ、Dockerでコンテナを実際どうやって作成するのかをみていきたいと思います。今までは理論的な話でしたが、今回は実際Dockerを触ってみましょう。主要なコマンドもいくつか紹介していきますので、今回登場するコマンドは覚えるといいと思います。

それでは、Let’s move!!

Dockerコマンドの概要説明

Dockerのコマンドは”マネジメントコマンド”と”コマンド”に分かれています。以下はDockerのコマンドの一つの例となります。

docker container run -it -p 80:80 httpd

“docker”以降がコマンドの様式となります。Dockerのコマンド様式は、[docker “マネジメントコマンド” “コマンド” “オプション”]の形になります。具体的に説明すると、上記のコマンドはDockerの中で”containerに関するコマンド”となります。また、さらに”containerをrunするコマンド”となります。

第一コマンドの例は以下のようなものがあります。

  • container:コンテナに関するコマンド。コンテナ起動、削除、停止、ログ確認などができます。
  • image:イメージに関するコマンド。イメージ作成、ダウンロードなどができます。
  • network:Dockerのネットワークを設定するコマンド。ネットワークを構築、コンテナをアタッチなどができます。
  • volume:ボリュームに関するコマンド。コンテナ同士で参照できるマウントポイントに関する操作ができます。

このように、「マネジメントコマンド」を作ったことによってDockerはコマンドを効率的に管理しています。余談ですが、”docker container run”コマンドは”docker run”でも全く同じことができます。”docker run”はマネジメントコマンドを導入する前のコマンドとなります。両方使えますが、せっかくなので最近のやり方で覚えましょう。コマンドがマネジメントコマンド同士で整理されているので、こちらが将来的には使いやすいかと思います。

イメージがレイヤーの重なりであることを確認する

それでは、1回目のブログで紹介した「イメージがレイヤーの重なりである」ことをDockerを使って確認してみましょう。まずローカルにあるイメージを確認します。イメージ一覧を確認するコマンドは”docker image ls”となります。

kong@KongnoAir docker % docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
test2               latest              4221b6ada1b6        5 days ago          95.5MB
test                latest              98d48c9e8359        5 days ago          95.5MB
httpd               latest              d4e60c8eb27a        9 days ago          166MB
ubuntu              latest              1d622ef86b13        4 weeks ago         73.9MB

前回作ったtestイメージが残ってますね。今回はhttpdだけ使いたいと思いますので、他のイメージは削除しましょう。イメージを削除するコマンドは”docker image rm [イメージID]”です。

kong@KongnoAir docker % docker image rm 42 98 1d
Untagged: test2:latest
Deleted: sha256:4221b6ada1b62f303391bb5641fcc005483fab3c15942a7f5714cd26a5e6fb96
<略>

このように、イメージIDは全部入力する必要はありません。被ってなければ最初の一文字だけ入力しても削除することができます。次に、イメージがレイヤーの重なりであることを確認するために中身をみてみましょう。イメージの中身を確認するコマンドは”docker image inspect [イメージID]”となります。

kong@KongnoAir docker % docker image inspect d4
[
    {
        "Id": "sha256:d4e60c8eb27a1e2a9370e6d0120008433b3f543888d3fd8636a2426b3b8b37aa",
        "RepoTags": [
            "httpd:latest"
        ],
    <中略>
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:ffc9b21953f4cd7956cdf532a5db04ff0a2daa7475ad796f1bad58cfbaf77a07",
                "sha256:2a3864bf0abad092e46d1b9af07579e060f0dc6647733777506966bfac4e5220",
                "sha256:4d7f420ed1cfe829b6594bccb9ae962b31d3f0b09f7241ff5f65b616eb64e506",
                "sha256:91cd4594943819b101aceaef3f5f96e3280784daf2d21b1e36bff90c2ee3373a",
                "sha256:50ed22113887f7c70a42a030e092e3643629da71c0b92d9f7dfae61a7b3cd64f"
            ]
        },
        "Metadata": {
            "LastTagTime": "0001-01-01T00:00:00Z"
        }
    }
]

イメージの中身には、そのイメージをビルドする際に設定した様々な情報が入ってますので、ぜひ一度読んでみて大体どのような情報が乗っているのか読んでみてください。その中に、”Layers”というものがあり、sha256形式で発行された複数のIDがあるのを確認できます。こちらのものがhttpdイメージをビルドする際に使用されたレイヤーとなります。この5つのパーツを重ねるとhttpdイメージと全く同じイメージを作成することができる、とのことですね。

また、httpdが使用するこのレイヤーたちのなかで、もし一致するレイヤーが他のイメージをビルドする際に必要そうであれば、保存したレイヤーを共通のディスクから使用してイメージをビルドすることもできます。このようにレイヤーは管理され、使われています。

イメージからコンテナを作成してみよう

それでは、httpdコンテナを作成してみましょう。もしhttpdイメージがローカルにない方はリポジトリからダウンロードしてきてください。そろそろ慣れてきたのかと思いますが、イメージをダウンロードするのはimageのマネジメントコマンドを使います。コマンドはpullとなります。ですので、”docker image pull httpd”でイメージをダウンロードすることができます。

kong@KongnoAir docker % docker image pull httpd
Using default tag: latest
latest: Pulling from library/httpd
afb6ec6fdc1c: Pull complete 
5a6b409207a3: Pull complete 
41e5e22239e2: Pull complete 
9829f70a6a6b: Pull complete 
3cd774fea202: Pull complete 
Digest: sha256:db9c3bca36edb5d961d70f83b13e65e552641e00a7eb80bf435cbe9912afcb1f
Status: Downloaded newer image for httpd:latest
docker.io/library/httpd:latest

コンテナのマネジメントコマンドはcontainerとなります。コンテナを作成するコマンドはrunになります。ですので、コンテナを作成するコマンドは”docker container run [イメージ名]”となります。コンテナを作成したら”docker container ls”を入力してみましょう。予想できるかと思いますが、現在起動中のコンテナをリストアップするコマンドとなります。

kong@KongnoAir docker % docker container run -d -p 8080:80 --name httpd_container httpd
4ffebef83b85fc46c1e4dcb8cc6f3c120b30268f8f2957d699b3c351e5e58ec7
kong@KongnoAir docker % docker container ls
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
4ffebef83b85        httpd               "httpd-foreground"       38 seconds ago      Up 37 seconds       0.0.0.0:80->80/tcp   httpd_container

runコマンドに、よく使うオプションを追加してみました。”-d”はバックグラウンドでコンテナのプロセスを動かすオプションです。インタラクティブで操作したいときは”-it”オプションを入れます。”-p”はポートを指定しています。ローカルの8080番ポートと、コンテナの80番ポートをマッピングしています。1個目の番号がローカルポート、2個目の番号がコンテナのポートになります。”–name”はコンテナに名前をつけるオプションです。”docker container ls”コマンドを実行した結果の中に、”NAMES”という欄があるのを確認できるかと思います。こちらに登録される名前を指定します。次回また紹介しますが、Dockerのネットワークで名前解決するためにこの名前が使用されますので、名前を決めておくとコンテナを再度作成する際に、毎回コンテナ同士の通信の際にフォワード先を変えたりする必要がなくなるので運用が楽になります。

次に、コンテナが正常に動いているか確認してみましょう。ブラウザからlocalhost:8080を入力してみると、おなじみの”It works!”を確認できるかと思います。ちなみに、プロセスのログは”docker container logs [コンテナID or コンテナの名前]”で確認できます。ちゃんと訪問履歴が残ってますね。

kong@KongnoAir docker % docker container logs httpd_container
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.3. Set the 'ServerName' directive globally to suppress this message
[Tue May 26 02:08:43.274214 2020] [mpm_event:notice] [pid 1:tid 140226650358912] AH00489: Apache/2.4.43 (Unix) configured -- resuming normal operations
[Tue May 26 02:08:43.274676 2020] [core:notice] [pid 1:tid 140226650358912] AH00094: Command line: 'httpd -D FOREGROUND'
172.17.0.1 - - [26/May/2020:02:17:03 +0000] "GET / HTTP/1.1" 200 45
172.17.0.1 - - [26/May/2020:02:17:04 +0000] "GET /favicon.ico HTTP/1.1" 404 196

最後に、それぞれのコンテナがどれくらいリソースを使用しているのか、コンテナを運用するときは必ず確認しないといけないかと思います。それを確認するコマンドは”docker container stats”となります。現在起動中のプロセス一覧と、それぞれのプロセスがどれくらいリソースを使用しているのかを簡単に確認できますので、見てみてくださいね。

最後に

ざっくりDockerでコンテナを作成するまでの流れと、主要なコマンドについて見てみました。いかがでしょう、Dockerは結構コマンドが多いですが、マネジメントコマンドを導入したことによって直感性のあるコマンドになっていることを確認できたかと思います。従来のDockerコマンドだと、コンテナ一覧を確認するコマンドは”docker ps”、イメージの一覧を確認するコマンドは”docker images”だったんですね。それが”docker container ls”、”docker image ls”になり、よりどのようなコマンドなのかわかりやすくなってきたのではないかと思います。どちらでもできることは同じなので、「コマンドは短い方がいいよ!」と思う方は従来のコマンドを覚えるのもいいと思います。

次回は、Dockerのネットワークとボリュームについてみていきましょう!Dockerの少し踏み入った概念、特徴を取り扱いますので、今までの話を十分復習した上で読んでくださいね。それでは、お元気で!

AWS Client VPNでSAMLによるフェデレーション認証ができるようになりました!

$
0
0

こんにちは、技術1課の小倉です。
2020/5/19にアップデートがあり、AWS Client VPNでSAMLによるフェデレーション認証ができるようになりました!

AWS Client VPN で SAML 2.0 経由のフェデレーション認証のサポートを開始

今までは、クライアント証明書による相互認証、Active Directory によるユーザー認証でしたが、さらにSAML2.0での認証ができるようになりました。SAMLとはシングルサインオンを実現するときに使われる仕組みで、認証情報を受け渡しするための決まり事です。フェデレーションは異なるサービス間で認証情報を連携することです。

今回の設定例ですと、Client VPNを接続するために、Oktaというフェデレーション認証を提供するサービスで認証することでVPN接続ができる設定にしています。ですから、今までよりも簡単にClient VPNの認証設定ができるようになりました。

AWS Client VPNとは

普段利用している端末からAWSに対してVPN接続して、AWSリソースに安全にアクセスできるようにする、クライアントベースのマネージドVPNサービスです。
AWS公式サイト : AWS Client VPN とは

料金は、AWS Client VPNのエンドポイント数と接続時間でお金がかかります。最新の料金はAWS公式サイトでご確認ください。
AWS VPN の料金

設定手順

こちらのAWSブログを参考に実施しました。
Authenticate AWS Client VPN users with SAML

事前準備が必要なもの

Oktaの設定

事前にOktaのアカウント作成をしますが、作成するのは30日間無料のTrialで問題ありません。

アカウント作成後、Oktaにログインします。
上のメニューの[Applications]をクリックして、[Add Application]をクリックします。

Add Application画面で、ClientVPNを検索し、結果にでてきた[AWS ClientVPN]をクリックします。

AWS ClientVPN画面で[Add]をクリックします。

Add AWS ClientVPN画面で、[Done]をクリックします。

Oktaで、AWS ClientVPNの設定をしていきます。
[Sign On] – [Edit]をクリックします。

下にスクロールし、以下を入力してから、[Save]をクリックします。

  • memberOfのプルダウンからMatches regexを選択し、値に .* と入力
  • Portに35001と入力
  • Identity Provider metadataのリンクを右クリックし、名前をつけて保存をします(あとで使います)。

IAMのIDプロバイダーの設定

Oktaでダウンロードしたメタデータ情報を使って、IDプロバイダーの設定をします。

マネジメントコンソールでIAMを開きます。
ナビゲーションペインの[IDプロバイダー]をクリックし、[プロバイダの作成]をクリックします。

以下の項目を入力し、右下の[次のステップ]をクリックします。

  • プロバイダーのタイプ : SAMLを選択
  • プロバイダ名 : 任意の文字列(今回はtest)
  • メタデータドキュメント : Oktaからダウンロードしたファイルを選択

内容確認して、右下の[作成]をクリックします。

Client VPN エンドポイントの作成

クライアントからVPN接続をするためのエンドポイントを作成します。

マネジメントコンソールでVPCを開きます。
ナビゲーションペインの[クライアントVPNエンドポイント]をクリックし、[クライアントVPNエンドポイントの作成]をクリックします。

クライアントVPNエンドポイントの作成画面で、以下を入力し、右下の[クライアントVPNエンドポイントの作成]をクリックします。

  • 名前タグ : 任意の文字列 (今回はClientVPNtestにしています)
  • クライアントIPv4 CIDR : VPN接続時にクライアントにアサインするIPv4アドレス
  • サーバー証明書ARN : ACMにインポートした証明書を指定
  • 認証オプション : ユーザーベースの認証を使用を選択し、統合認証を選択
  • SAMLプロバイダーARN : 先ほど作成したIAM IDプロバイダーを選択
  • クライアント接続の詳細を記録しますか? : 今回はいいえを選択(はいにするとCloudWatchにログを保存できます)

VPN接続後にアクセスできるVPCを設定します。
作成したクライアントVPNエンドポイントを選択し、下の[関連付け]タブをクリックし、[関連付け]をクリックします。

接続するVPCとサブネットを選択し、[関連付け]をクリックします。

認証設定をすることで接続元を制限することができますが、今回はOktaに登録しているユーザすべてアクセスできる設定にします。
作成したクライアントVPNエンドポイントを選択し、下の[認証]タブをクリックし、[受信の承認]をクリックします。

認証ルールの画面で、アクセスを有効にする送信先ネットで、接続先のVPCのCIDRを入力、アクセスを付与する対象はすべてのユーザーにアクセスを許可するを選択し、[認証ルールの追加]をクリックします。

これで、一通り設定が終わりました。
クライアントVPNエンドポイントを選択し、画面上の[クライアント設定のダウンロード]をクリックし、クライアント設定のダウンロード画面で[ダウンロード]をクリックします。

クライアントからVPN接続

AWS VPN Clientを起動します。
[ファイル] – [プロファイルの管理]をクリックします。

プロファイルを管理画面で、[プロファイルを追加]をクリックします。
プロファイルを追加画面で、表示名とVPN設定ファイルを指定(先ほどクライアントVPNエンドポイントからダウンロードしたファイル)し、プロファイルを追加をクリックします。

プロファイルを管理画面に作成したプロファイルが表示されるので、[完了]をクリックします。

これで、準備ができました。
[接続]をクリックして、VPN接続をしてみましょう。

ちょっと待つとブラウザでOktaの認証画面が表示されるので、ログインするとVPN接続が完了します。
クライアントからAWSにあるEC2にpingを実行するとpingが通ります。

接続を切りたいときは、[切断]をクリックします。

まとめ

AWS Client VPNでSAMLによるフェデレーション認証ができるようになりました。今までよりも設定や管理が楽になりますので、ぜひお使いいただければと思います。

また、VPN接続時のトラブルシュートはAWS公式サイトにもいくつかよくあることがのっていますので、もしつながらないときなどは参考にしてみてください。ちなみに私は手順を確認していたときにVPN接続ができずに原因調査をしていたのですが、AWSのトラブルシュートのページに対応方法がのっていて、対応通りに実施したところ無事に接続できるようになりました。

クライアント VPN 接続のトラブルシューティング

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


VMware Cloud on AWSを解説してみる

$
0
0

技術三課の杉村です。VMware Cloud on AWS(以下、VMC on AWS)についての解説です。

当社では、下記のようなプレスリリースを出させていただきました。せっかくなので、VMCの解説を投稿してみます。
サーバーワークス、VMware Cloud(TM) on AWSの提供開始 提供に先立ち千趣会へ本サービスの実証実験を実施

なお本投稿に記載の内容は、公式情報から得た内容およびVMware社様から得た情報を総合して記載した弊社の理解を記事にしたものです。正式な内容はVMC on AWSを提供するVMware社の公式資料や、サポート等の回答内容の方を優先とお考えください。

1. What’s VMC on AWS?

VMware Cloud on AWS は簡単に言うと「VMwareをAWS上で動かせます」というサービスです。
ただし、以下の点で通常のAWSサービスとは異なります。

  • VMware社から提供されるサービスです。サポートも原則、VMwareから提供されます。(パートナーの場合もあり)
  • 基盤としてAWSを利用しています。ESXiが動作するホストとしてEC2ベアメタルインスタンスが利用されます
    • ESXiホストが存在するのは SDDCアカウント と呼称される、VMwareが管理するAWSアカウントであり、当該AWSアカウントにユーザはログイン等はできません
  • SDDCアカウントと顧客の持つAWSアカウントをリンクできます。これによりSDDCアカウントに存在するESXiホスト、そしてその上に存在する仮想マシン(VM)と顧客の既存AWS環境との間で通信ができるようになります

AWS公式の VMware Cloud on AWS のよくある質問 も参照してみてください。

上記まで読んで、AWSのご利用経験がある方であれば「あれ、なんか普通のAWSサービスと違うぞ…」とご理解いただけると思います。

2. ネットワークアーキテクチャ

AWSは既にある程度お使いの方を対象読者とする前提で、いきなりですがネットワーク構成図をどんと載せちゃいます。

ご覧のように、左側に顧客の持つ通常のAWSアカウント(以下、カスタマーアカウント)があります。
右側にESXiホストが動くアカウント(以下、SDDCアカウント)があります。右側のアカウントは通常のAWSアカウントではなく、AWSマネジメントコンソール等ではログインできません。

SDDC(Software-defined Data Center)をセットアップする際に、紐づける先のカスタマーAWSアカウントを指定します。

その際にサブネットを1つを指定します。(複数は指定できません)
そのサブネットに、ENIが複数(デフォルトで16個)作成されます。そのENIのうち1個がアクティブであり、ESXiホストの1個と繋がっています。

カスタマーアカウント側のルートテーブルでは、このVMwareのVMのIPレンジのルートがENIに向いています。
このENI経由で、カスタマーアカウントとSDDCアカウント内のVMの間で通信できるのです。

ちなみにENI1個は1個のESXiホストと紐づいており、アクティブなENIのホストがダウンした場合は自動的に別のホストのENIがアクティブになり、ルートテーブルも自動で書き換えられます。(自動で書き換えられる対象ルートテーブルは1個しか指定できない)

SDDCアカウントのほうでは、ESXiが動作しており、各VM、vCenterやNSX Managerなどの管理アプライアンスが動作しています。
VMWareのSDNソリューションであるNSX-Tにより仮想ネットワークが構成され、VMがその上で動いています。
つまり各VMは通常のAWSのようにVPC上に存在するのではなく、NSXにより構成される仮想ネットワーク上に存在しています。
これらは管理コンソールで管理することができます。

また仮想的なルータであるt0 Routerとオンプレの間でVPNを結ぶことができ、またL2 VPN(on L3 Network)を結ぶこともできます。
これによりオンプレからの “L2延伸” を実現し、vMotionなどの機能を利用してオンプレからVMを移行することも可能です。

かなりざっくりしていますが、上記がVMC on AWSのネットワークアーキテクチャの概要です。

3. ストレージ

VMC on AWSのストレージは vSAN という機能により提供されます。
vSANはVMwareのストレージ仮想化ソリューションで、IAサーバに付帯のストレージを仮想化してプロビジョニングできるものです。

AWSのベアメタルインスタンスに付属のローカルストレージまたはEBSをvSANとして構成します(ローカルストレージなのかEBSなのかはベアメタルのインスタンスタイプによって異なる)。
また追加のEBSをvSANに組み込む機能もあります。

利用可能な総容量は、ベアメタルのインスタンスタイプ、RAIDの種類、管理オーバヘッド、vSANによって自動的に行われる重複排除・圧縮の効き方によって異なりますが、大まかに見積もることは可能です。

またストレージはmustで暗号化されます。(裏ではAWS KMSが使われています)

これらを図に簡単に表すと、下記のようになります。

4. まとめ

ごく簡単なまとめでしたが、重要なのは VMWare Cloud on AWS は通常のAWSサービスとは大きく異なり、むしろVMWareの世界の知識がメインで求められるものです。

「VMWareで動作する既存ワークロードをスムーズにAWSと連携させたい」
「AWSの提供するスケールメリットの上でVMWareを利用したい」

などの場合に大きな力を発揮します。

Amazon FSx for Windows と AWS Managed Microsoft AD で Windows用のファイルサーバを作って EC2 から接続しよう①概要説明

$
0
0




Amazon FSx for Windows と AWS Managed Microsoft AD で Windows用のファイルサーバを作って EC2 から接続しよう①概要説明



作成する構成

以下になります

「※ EIP を利用し パブリックIPアドレスを固定する (自動割当パブリックIPを使わない) 」という箇所に関しまして補足します
EC2 の作成時にパブリックIPアドレスを付与しない場合には 「ドメイン結合ディレクトリ」を指定しても EC2がドメインに参加しません
(EC2作成後にEIPを付与しOSにログインしてドメイン参加を実施することにより大丈夫なことを確認済みです)
本記事の手順中に解説します

作成の大まかな流れ

  1. AWS Managed Microsoft AD を作る
  2. EC2 (固定のEIP付き) を作成し 1. のADに参加
  3. FSx (Windows用ファイルサーバ) を作成し 1. のADに参加
  4. EC2 から FSx に接続しファイルやフォルダを作成可能なことを確認

作成を始める前に

  • 一通り以下を確認していきます
    • Amazon FSx for Windows ファイルサーバーとは
      • EC2 で ファイルサーバを作成する場合と異なる点
    • AWS Managed Microsoft AD とは
      • EC2 で ADを作成する場合と異なる点

Amazon FSx for Windows ファイルサーバー とは

Amazon FSx for Windows File Server provides fully managed Microsoft Windows file servers, backed by a fully native Windows file system.

参考: Amazon FSx for Windows File Server

Windowsのファイルシステムで構成する Windows ファイルサーバー のマネージドサービスです

Amazon FSx for Windows ファイルサーバー の前提条件

  • Amazon FSx for Windows ファイルサーバー(以下 FSx) を配置するための VPC
    • Single AZ または Multi AZ が選べる
      • Single AZ はコンポーネントの障害を自動的に検出して対処することにより単一のアベイラビリティーゾーン(AZ)内で高可用性を保証
      • Multi AZ は AWSリージョン内の別のアベイラビリティーゾーンでスタンバイファイルサーバーをプロビジョニングおよび維持することにより複数のアベイラビリティーゾーンにわたって高可用性とフェイルオーバーのサポートを提供
  • FSx を配置した VPC への経路を持つ以下のインスタンス(Windows Server 2008 以降の Windows と Linux )から接続可
    • EC2インスタンス
    • Amazon WorkSpaces instance
    • AppStream 2.0 instance
    • VM running in VMware Cloud on AWS environments の 上のVM
    • AWS Direct Connectを使用したオンプレミスのインスタンス
  • FSxはMicrosoft Active Directory (AD) と連携して ユーザー認証とアクセス制御を実行する
    • ADは以下から選択可能
      • AWS Managed Microsoft AD
      • オンプレミスのサーバやEC2インスタンスにインストールしたAD
  • FSxはマネージドサービスとして以下を提供
    • 内部的にWindowsソフトウェアを最新の状態に保つ
    • ハードウェア障害を検出して対処
    • バックアップを実行
  • HIPAAに適合(ISO、PCI-DSS、SOCの認定に準拠していると評価)したセキュリティとコンプライアンスを提供
    • AWS Key Management Service(AWS KMS)で管理するキーを使用して(ファイルシステムとバックアップの両方の)保存データを自動的に暗号化
    • 転送中のデータは SMB Kerberosセッションキーを使用して自動的に暗号化
  • ストレージの種類は SSD または HDD が選べる
    • 容量は 32 〜 65536 GiB
      • これ以上増やす場合は DFS サーバを作成して複数のFSxを同じ名前空間に配置する (但しパスは各 FSx 毎に分かれる)
    • スループットの指定も可能(8 〜 2048 MB/s)
  • FSx には内部的に発行するDNS名でアクセスする
  • Powershell によるファイルシステムの管理が可能

Amazon FSx for Windows の料金

  • 料金計算ツール
    • Amazon FSx for Windows File Server の料金
      • 例えば 50GiBのファイルサーバを東京リージョンにマルチAZで作成し1世代分バックアップする場合(スループットはデフォルトの (MB/s) は 月額 8.15 USD (ファイルサーバのコスト 6.90 USD + バックアップのコスト 1.25 USD) になる

EC2 で ファイルサーバを作成する場合と異なる点

  • 料金 ( バックアップを取得しない50 GiB のファイルサーバで比較)
    • EC2の場合は EC2 インスタンスの利用料金 + EBS の利用料金になる
      • m5.large の場合は以下
        0.216 USD x 24時間 = 5.184 USD /日
        仮に 1ドル 100 円換算とした場合 月間(730時と仮置)で 15,768 円
      • 50GiBの EBS を月 730時間実行すると 6.00 USD
        仮に 1ドル 100 円換算とした場合 月間(730時と仮置)で 600 円
        参考:Amazon EBS の価格
      • 月額合計は 16,368 円
    • FSx は 月額 6.90 USD になる
      仮に 1ドル 100 円換算とした場合 月間(730時と仮置)で 690 円
      • 月額合計は 690 円
      • FSxのほうが安い
  • 非機能
大項目 中項目 EC2 Amazon FSx for Windows ファイルサーバー
可用性 冗長性・BCP ユーザー側が導入・冗長化を行う AWS側で導入・冗長化を行う(最小構成では1つのAZを利用してレプリカを作成しておきコンポーネントの障害を自動的に検出して対処する 任意のタイミングでバックアップ取得も可能)
運用保守性 ハードウェア障害時 EC2 にはインスタンスのリタイアがありハードウェアで回復不可能な障害があるとユーザー側で手動リカバリ(停止・起動)が必要 AWS側で復旧
運用保守性 パッチ適用 EC2 のOSパッチ適用はユーザー側で責任を持って行う AWS側で実施
セキュリティ 脆弱性・ウイルス対策 EC2への導入ソフトウェアはユーザー側で管理 ソフトウェアの導入不可
セキュリティ 不正アクセス対策 EC2へのログイン時に利用するセキュリティグループと秘密鍵はユーザー側で管理 OSへのログイン不可

AWS Managed Microsoft AD とは

AWS Directory Service によって、Microsoft Active Directory(AD) をマネージドサービスとして実行することができます

参考:AWS Managed Microsoft AD

AWS Managed Microsoft AD の前提条件

  • 異なるアベイラビリティーゾーンにある2つのサブネットを利用してドメインコントローラーを動作させる(可用性の担保)
    • デフォルトで 2台のドメインコントローラーを動作させる
      • ドメインコントローラー 1台につき ENI(elastic network interface) を 1つ使う
      • ドメインコントローラーは追加可能
    • 198.18.0.0/15 アドレス空間は管理用に使うセグメントとなるためサブネットには利用不可
    • Active Directory を使用したネットワークアドレス変換 (NAT) の使用はサポートしていない
  • ドメインコントローラーへの接続は、VPC の他のコンピュータまたは他の VPC ( VPC ピアリング接続 )のコンピュータ または AWS Direct Connect や VPN を介したオンプレミスのコンピュータ から可能
  • Administrator ではなく 「Admin」ユーザーを利用しディレクトリを管理する
  • 可能なことは以下
項目 可能/不可能
ユーザーとグループの管理(Builtin除く) 可能
DNSの管理 可能
GPOの管理 可能
OUの管理(ドメイン名以下のOU) 可能
信頼関係の構築 可能
ドメインコントローラーの追加 可能
ADFS連携 可能
マネジメントコンソールからのスナップショット作成とリストア 可能
Administrator ユーザーの利用 不可能
サイトの作成 不可能
DefaultDomain Policyの変更 不可能
ドメインコントローラーへのリモートデスクトップ接続 不可能
ドメインコントローラーへのソフトウェアインストール 不可能

AWS Managed Microsoft AD の料金

本記事の構成は東京リージョンを利用し Standard Edition (従業員数が最大 5,000 人の小規模または中規模のビジネス向け) を選択します
ドメインコントローラーはデフォルトの2台構成にします
仮に 1 日 24 時間起動した際には以下の計算式となります
0.146 USD × 24時間 = 3.504 USD/日
仮に 1ドル 100 円換算とした場合 月額(730時間と仮置)で 10,658 円 になります

EC2 で ADを作成する場合と異なる点

  • 料金
    • m5.large の場合は以下
      0.216 USD x 24時間 = 5.184 USD /日
      仮に 1ドル 100 円換算とした場合 月間(730時と仮置)で 15,768 円
      **2 台構成では 月額 31,536 円 **
      → EC2 の方がコストは高い
    • t3.large の場合は以下
      0.1364 USD x 24時間 = 3.2736 USD /日
      仮に 1ドル 100 円換算とした場合 月間(730時間と仮置)で 9,957 円
      2 台構成では 月額 19,914 円
      →EC2 の方がコストは高い
  • 非機能
大項目 中項目 EC2 AWS Managed Microsoft AD
可用性 冗長性・BCP ユーザー側が導入・冗長化を行う AWS側で導入・冗長化を行う(最小構成では2つのAZを利用した2台構成のドメインコントローラーとなる AZの追加やサイト作成は不可)
運用保守性 ハードウェア障害時 EC2 にはインスタンスのリタイアがありハードウェアで回復不可能な障害があるとユーザー側で手動リカバリ(停止・起動)が必要 AWS側で復旧
運用保守性 パッチ適用 EC2 のOSパッチ適用はユーザー側で責任を持って行う AWS側で実施
セキュリティ 脆弱性・ウイルス対策 EC2への導入ソフトウェアはユーザー側で管理 ソフトウェアの導入不可
セキュリティ 不正アクセス対策 EC2へのログイン時に利用するセキュリティグループと秘密鍵はユーザー側で管理 OSへのログイン不可
セキュリティ 不正アクセス Administrator ユーザーはユーザー側で管理 Administrator利用不可

作成手順

前置きが長くなってしまったので別記事にしました


Amazon FSx for Windows と AWS Managed Microsoft AD で Windows用のファイルサーバを作って EC2 から接続しよう②作成手順

$
0
0

作成する構成

以下になります

本記事の概要につきましてはお手数ですが以下の記事をご参照ください
Amazon FSx for Windows と AWS Managed Microsoft AD で Windows用のファイルサーバを作って EC2 から接続しよう①概要説明

作成の大まかな流れ

  1. AWS Managed Microsoft AD を作る
  2. FSx (Windows用ファイルサーバ) を作成し 1. のADに参加
  3. EC2 (固定のEIP付き) を作成し 1. のADに参加
  4. EC2 から FSx に接続しファイルやフォルダを作成可能なことを確認

作成手順

1. AWS Managed Microsoft AD を作る

[サービス]→[Directory Service]

[ディレクトリのセットアップ]

[次へ]

矢印の箇所を修正

サブネットを選択 (AZは2つ)

[ディレクトリの作成]

[作成中]→[アクティブ]になるのを待つ

2. FSx (Windows用ファイルサーバ) を作成し 1. のADに参加

事前にセキュリティグループを作成します ([サービス]→[VPC]→[セキュリティグループ]から作成)
EC2に付与するセキュリティグループから以下のポート宛通信を許可します

Rules Ports
UDP 53, 88, 123, 389, 464
TCP 53, 88, 135, 389, 445, 464, 636, 3268, 3269, 9389, 49152-65535

参考:File System Access Control with Amazon VPC

[サービス]→[Fsx]

[Create file system]

[Amazon FSx for Windows File Sever]→[Next]

矢印の箇所を修正→[Next]

[Create file system]

[Createing]→[Active]

3. EC2 (固定のEIP付き) を作成し 1. のADに参加

DHCPオプションセット作成 (EC2のDNSを作成したADに設定する用)

作成した AWS Managed Microsoft AD を参照して [DNSアドレス] をコピーしておきます

[サービス]→[VPC]

[DHCPオプションセット]→[DHCPオプションセットを作成]

矢印の箇所を修正→[DHCPオプションセットを作成]
※[ドメインネームサーバ]に上でコピーした[DNSアドレス]を設定 また [ドメイン名]は 作成した AWS Managed Microsoft AD のドメイン名を設定

作成完了した状態

VPCに 作成したDHCPオプションセットを紐付けます
[VPC]→対象のVPCを選択→[DHCPオプションセットの編集]

[保存]

[閉じる]

EC2作成

[サービス]→[EC2]

[インスタンスの作成]

Windowsの公式AMIを選択

VPCとサブネットを選択

EC2用のセキュリティグループを付与→[起動]

EC2 が作成完了した状態

EC2に EIP を付与

[EC2]→[Elastic IPアドレス]→[Elastic IPアドレスの割り当て]

[割り当て]

[Elastic IPアドレスの関連付け]

作成したEC2を選択→[関連付ける]

EC2 をAWS Managed Microsoft AD のドメインに参加させる

作成したEC2にログインし確認

[コントロールパネル]→[システム]→[設定の変更]→[変更] (英語版OSで申し訳ないです

[ドメイン]にドメイン名を入力

再起動

4. EC2 から FSx に接続しファイルやフォルダを作成可能なことを確認

作成した FSx を確認

EC2 にログインしエクスプローラーから ¥¥ドメイン名¥share に接続

S3に配置したForm画面より情報を入力しSlackへ投稿してみる

$
0
0

こんにちは。技術5課の芳賀です。最近、CloudFront+S3の組み合わせ、API Gateway+Lambdaの組み合わせでサービスを触っていました。ふと、これを全部組み合わせて何か作れないか・・・と思い今回のネタを思いつきました。

思いついた内容としては以下になります。

  1. CloudFront経由でS3のコンテンツ(フォーム)を参照
  2. S3に配置したフォームより情報を入力
  3. S3のフォームよりAPI Gatewayを実行
  4. APIGatewayをトリガーにLambdaを実行
  5. LambdaよりSlackへ投稿

簡単な図にしてみると以下のようなイメージです。

そして今回S3に配置するフォームは以下のようなイメージになります(とてもシンプル!)

図の後ろの方から準備していきたいと思います。
既出のネタもありますので、要所要所で割愛させて頂きますがご了承ください。

1.Slackの設定

Slackアプリではなく、カスタムインテグレーションの方の「Incoming Webhook」を設定します。
設定方法についてはいろいろな方が書かれているので割愛させて頂きます。

※カスタムインテグレーションの「Incoming Webhook」は現在非推奨となっています。そのためSlackへ投稿する部分についてはSlackのAPIを使用することをお勧めします(恥ずかしながらこのブログを書く際に非推奨と分かりました。)

以下のようにSlackの画面を確認すると最新のAPIを使用することをお勧めされます。

2.Lambda関数の作成

LambdaからSlackへ通知するためのLambda関数を作成します。以下の内容を入力し、「関数の作成」を選択します。

  • 関数名:任意。今回は「SendTOSlack」としました(TOの「O」を小文字にしたつもりでしたが大文字になってました)。
  • ランタイム:「Pyathon3.8」を選択。
  • 実行ロール:「基本的なLambdaアクセス権限で新しいロールを作成」を選択。

画面が遷移し、関数コードの項目を確認するとデフォルトで「lambda_function.py」が作成されています。以下のコードをコピペして上書きします。

ざっくりとプログラムの中身を説明すると、「lambda_handler」関数の「event」引数にS3に配置したフォームで入力した情報が入っています。
フォームで入力した情報というのはSlackへの投稿者、アイコン、投稿先チャンネル、投稿内容です。この内容を取得し、Slackの「Incoming Webhook」に対して情報を渡すことでSlackへ投稿するようなコードになっています。

import boto3
import json
import urllib
import os

def lambda_handler(event, context):

    SLACK_POST_URL = os.environ['SLACK_POST_URL'] # SlackのIncoming WebhooksのURL
    username =  urllib.parse.unquote(event['name'])
    icom =  urllib.parse.unquote(event['icon'])
    message = urllib.parse.unquote(event['message'])
    channnel = urllib.parse.unquote(event['channel'])

    # メッセージの内容
    send_data = {
        "username": username,
        "icon_emoji": icom,
        "text": message,
        "channel": channnel,
        "link_names": 1,
    }

    send_text = ("payload=" + json.dumps(send_data)).encode('utf-8')

    result = urllib.request.Request(
        SLACK_POST_URL,
        data=send_text,
        method="POST"
    )

    with urllib.request.urlopen(result) as response:
        response_body = response.read().decode('utf-8')

    return response_body

ちなみにos.environ['SLACK_POST_URL']の部分は、Lambdaの環境変数を参照する記述になっています(プログラムにベタ書きは格好が悪かったので)。
以下のようにSlackのIncoming WebhookのURLを設定しておきます。

3.API Gatewayの作成

関数を作成したらAPI Gatewayのトリガーを設定していきます。先ほど作成したLambda関数のDesignerより、「トリガーを追加」を選択します。

以下の内容を入力し「追加」を選択します。

  • トリガー:API Gateway
  • API:Create an API
  • API type:REST API
  • セキュリティ:オープン(今回は検証のためオープンを選択しています)

「SendTOSlack-API」というAPIが作成されました。

「SendTOSlack-API」の設定をします。リソースの「SendTOSlack」を選択した状態で「アクション」→「メソッドの作成」を選択します。

「POST」を選択し、右にあるチェックマークを選択します。

「POST」メソッドが作成されます。SendTOSlackの「POST」を選択、以下の内容を入力し「保存」を選択します。

  • 統合タイプ:Lambda関数
  • Lambdaリージョン:ap-northeast-1
  • Lambda関数:SendTOSlack
  • デフォルトタイムアウトの使用:任意(ここではチェックを入れました)

確認ダイアログが表示されるので「OK」を選択します。

以下のような画面になるので(ならなかったらもう一度「POST」を選択)、「統合リクエスト」のリンクを選択します。

遷移した先の画面下に「マッピングテンプレート」という項目があるので表示させます。

「マッピングテンプレートの追加」を選択、以下を入力して右のチェックマークを選択します。

  • Content-Type:application/x-www-form-urlencoded

Content-Typeはどのような形式でリクエストパラメータを受け取るかの設定で、他に「application/json」や「application/xml」などがあります。

確認ダイアログが表示されるので「はい、この統合を保護します」を選択します。

マッピングテンプレートの入力項目が表示されるので、以下の内容を入力して「保存」を選択します。

{
 #set( $param = $input.body )
 #foreach( $keyValue in $param.split( '&' ) )
 #set( $keyValueArray = $keyValue.split( '=' ) )
        "$keyValueArray[0]" : "$keyValueArray[1]"#if( $foreach.hasNext ),#end
 #end
}

このマッピングテンプレートというものがなかなかの曲者で、理解するのにかなりの時間を要しました(未だに完全には理解していませんが・・・)。
上記の設定で何をしているかというと、今回作成しようとしているS3のフォームから入力された内容をJSON形式に変換するような処理になっています。

例えばS3のフォームで以下のような内容でSendTOSlack-APIにPOSTしたとします。

  • 投稿者:haga
  • アイコン::eyes:
  • 投稿先チャンネル:#general
  • 投稿内容:テストテスト

すると以下のような内容でAPIは情報を受けとります。

name=haga&icon=:eyes:&channel=#general&message=テストテスト

上記の内容を「&」、「=」といった記号から分解し、以下のようなJSON形式に変換した形でLambdaへ渡します。

{
 name:haga
 icon::eyes:
 channel:#general
 message:テストテスト
}

フォームからPOSTする際にJSON形式に変換してPOST、Lambda関数側でJSON形式に変換するなどの方法も可能ですが、今回はこのマッピングテンプレートを使用してみました。

マッピングテンプレートについては以下のドキュメントが参考になるかと思います。
API Gateway マッピングテンプレートとアクセスのログ記録の変数リファレンス

「SendTOSlack-API」の設定が完了したので、APIが使用できるようデプロイします。
リソースより「POST」を選択、「APIのデプロイ」を選択します。

デプロイされるステージ、デプロイメントの説明を入力し「デプロイ」を選択します。
今回ステージは「default」を選択しました。

以下のような画面に遷移します。
「URLの呼び出し」にあるURLを入力することでAPIが実行されます。後ほどS3に配置するフォームに埋め込むのでURLをメモしておきます。

4.S3バケットの作成とCloudFrontの設定

この設定は以下のブログを参考にCloudFrontを設定、S3のコンテンツを配置します(ほぼやりたいこと通りなのでここでの詳細は省きます)。

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

S3バケットを作成します。
ここでは「sendtoslack-testbucket」という名前でデフォルト設定のS3バケットを作成しました。

配置するコンテンツは以下です。
index.htmlはバケットの直下に配置します。「slack.css」は「css」フォルダを作成してその配下に配置します。
(HTML、CSSは得意ではないので温かい目でコードを見て頂ければと思います・・・)

【index.html】

<!DOCTYPE html>
<html>
  <head>
      <meta charset="utf-8">
      <link rel="stylesheet" type="text/css" href="css/slack.css">
      <script type="text/javascript">
        var $form = $('#sendMessageForm')
        var $trigger = $('#sendMessageTrigger')

        $trigger.click(function() {

            $form.submit();
            $form[0].reset();

            return false;
        });
      </script>
  </head>
 
  <body>
  <p class="lead-form">Slackへ投稿!!</p>

    <form name="myform" id="sendMessageForm" action="<API Gatewayで作成したURLを指定する>" method="post" accept-charset="utf-8" target="sendMessage">
      
      <div class="item">
        <label class="label">投稿者</label>
        <input class="inputs" type="text" name="name">
      </div>
      
      <div class="item">
        <label class="label">アイコン</label>
        <input class="inputs" type="text" name="icon">
        <label class="notice">:〇〇:の形式でアイコンを指定</label>
      </div>

      <div class="item">
        <label class="label">投稿先チャンネル</label>
        <input class="inputs" type="text" name="channel">
        <label class="notice">#〇〇で指定したチャンネルへ投稿</label>
      </div>

      <div class="item">
        <label class="label">投稿内容</label>
        <textarea class="inputs" type="text" name="message" placeholder="投稿内容を入力"></textarea>
      </div>

      <div class="btn-area">
        <input id="sendMessageTrigger" type="submit" value="投稿">
      </div>

    </form>
    <iframe name="sendMessage" style="width:0px;height:0px;border:0px;"></iframe>
  </body>
</html>

上記コードの<form>タグ内のactionには、「3.API Gatewayの作成」で取得したURLを“<API Gatewayで作成したURLを指定する>”の箇所に記述してください。

【slack.css】

.lead-form{
  text-align: center;
  font-size:28px;
}
form{
  width:460px;
  margin:0 auto;
}
.item{
  overflow: hidden;
  margin-bottom: 20px;
}
.label{
  float: left;
  margin-right: 20px;
  width:430px;
  padding-left: 10px;
}
.inputs{
  float: left;
  width:430px;
}
.notice{
  float: left;
  margin-right: 20px;
  width:430px;
  padding-left: 10px;
  font-size:12px;
  text-align: right;
}
input[type="text"] {
  border: solid 1px;
  border-radius:5px;
  padding:10px;
  font-size: 15px;
}
textarea{
  border: solid 1px;
  border-radius:5px;
  padding: 10px;
  height: 160px;
  font-size: 15px;
}

input[type="submit"]{
  border: none;
  font-size:17px;
  font-weight:bold;
  padding: 10px 20px;
  margin: 0 5px;
}
.btn-area{
  text-align: right;
}

CloudFrontを設定していきます。
設定は先ほど紹介したブログと同様の設定でOKです。1点、ディストリビューション作成時に設定する「Default Root Object」が「index.html」になる点だけが異なります。

ステータスが「Deployed」になるまで暫く待ち、デプロイが完了したら作成したディストリビューションのドメイン名を指定してブラウザでアクセスしてみます(デプロイ直後はアクセスできず、1時間ほど待ちました。コンテンツの反映に時間がかかる場合がありそうです)。

アクセスすると、冒頭で紹介したシンプルなWeb画面が表示されます。
以下の内容でSlackへ投稿してみました。

無事、Slackへ投稿できました!!

最後に

どうしても一度、入力フォームを持ったサーバレスなアプリケーションを作成したく今回のような内容となりました。API GatewayとLambdaの部分はServerless Frameworkを使うともっと効率よくデプロイできそうな気がしますが、情報が盛り沢山になりそうだったのであえてマネージメントコンソール上からの構築としました。

入力フォームを持ったサーバレスアプリケーションを構築したい方の参考になれば幸いです。

【はじめてのAWS】 AWS Budgetsで予算を管理しよう

$
0
0

 

今回は、弊社のYoutubeチャンネル「サーバーワークス チャンネル」にて先日公開した以下動画についてblogでも内容を紹介いたします。

動画内では、実際にAWSマネージドコンソールを操作しながら設定を行っていくデモがありますのでもし興味があれば是非、動画も参照頂ければと思います。

内容が良かった、為になったと感じたら是非Goodボタンやチャンネル登録頂けると嬉しいです。

対象者

・AWSをこれからはじめたい方
・AWSをもっと活用したい方
・AWS Budgets による予算管理に関する設定イメージを把握したい方

AWS Budgetsとは

AWSコスト管理サービスの一種となり、“AWS利用料を予算別に管理する”ことが出来ます。
AWSアカウント全体の管理だけでなく、例えば Amazon EC2の利用料金を毎月いくらまでに抑えたいといった際にも設定し管理が可能です。

管理するだけでなく、例えば設定予算に近づいた際などに管理者へアラートを通知する事も可能です。

参照:AWS Budgets
https://aws.amazon.com/jp/aws-cost-management/aws-budgets/

AWS Budgetsの料金

基本料金は以下となっており 20200601現在の単価は $0.02- となっています。
基本料金 = 日数 * 予算(数) * 単価

無料利用枠があり、登録された予算2つまでは毎月無料となっているので試用が可能です。
詳細はAWS公式の情報を参照ください。

参照:AWS コスト管理の料金
https://aws.amazon.com/jp/aws-cost-management/pricing/

AWS Budgets の注意事項

注意点として以下3点を紹介します。

  • IAMユーザの制限事項
    AWS初期設定では、IAMユーザで請求情報を参照できず、ルートユーザで権限の変更が必要となります。
  • コスト予測の利用開始条件
     予測コストの算出には、最低5週間の利用データが必要となります。
     利用データが不足している状態、アラームは実行されませんので注意が必要です。
  • 予算の更新周期
     AWS請求データの更新周期(1日1回以上)と連動しており、ユーザ側で指定は出来ません。

 AWS Budgetsによる予算の設定デモ(動画内 02:22〜)

AWSアカウント全体の利用料の予算を $100- に設定し、その予算の80%の閾値を超えた場合に管理者へEmailで通知する設定を行い、後に予算/現状/予測 のステータスを確認するといった簡単なデモを動画内で紹介しております。

管理者視点で、ざっくりとAWS Budgetsの設定や利用イメージを掴んで頂ける内容となっておりますので、もし興味があれば動画を参照ください。

まとめ

AWS Budgets を有効活用する事で、AWS利用料を適切に管理する事が可能です。
管理者としてAWSアカウントを作成した際には、無料利用枠もありますので、初期設定項目として実施を検討してみてください。

どんなときにAmazon Connectインスタンスをわける?わけない?

$
0
0

Amazon Connect専任チームの丸山です。

Amazon Connectを導入したらとてもよかった。
今回のような在宅勤務やソーシャルディスタンスを実現する際にさらによさを実感。
ありがたいことにこのようなお声を複数社から頂いております。

せっかくなので他の部門や業務でAmazon Connectを利用したくなってきた。
Amazon Connectインスタンスをわけるべき?わけないべき?
というご質問をいただいたのでまとめます。
 
 

検討するポイント

 

料金について

Amazon Connectは「AWSアカウント」単位で利用明細がでてきます。
「AWSのアカウント」単位というのがポイントです。
インスタンス単位では利用料がわかりません。
電話番号ごとの明細もでてきません。
タグ別明細のような機能にも対応していません。
 
部門ごとに利用料金を明確に分けたい場合はAWSアカウントを分離する他ありません。
 

オペレータについて

通常オペレーターがログインできるAmazon Connectインスタンスは1つです。
複数のブラウザを利用したり、ブラウザのプロファイルを複数利用すれば複数のAmazon Connectインスタンスにログインが可能ですが、着信時にどのソフトフォンがなっているのかわからなくなりおそらく混乱して使いにくいでしょう。
事実上1つのAmazon Connectインスタンスにログインして利用していただくことになると思います。
 
したがって同じオペレータ(人)が複数のAmazon Connectに所属しないような設計をすることをおすすめします。
 

複数の業務でAmazon Connectを利用する選択肢

 

1. 1つのConnect環境にまとめる

  • AWSアカウント/Connectインスタンス
    • 1つ/1つ
  • 用途例
    • オペレータが複数業務を担当する場合
      • 1つのインスタンスで電話番号やフローの分岐で複数業務を分けてオペレータにつなげる
  • メリット
    • 1回のログインで複数の電話番号、キューの対応ができる
  • デメリット
    • 利用料金が業務ごとに分離できない

2. 同じAWSアカウントで別のConnect環境を用意する

  • AWSアカウント/Connectインスタンス
    • 1つ/2つ
  • 用途例
    • 種類の異なる業務を導入する場合(有人対応と完全自動応答システムなど)
    • 異なるセキュリティー要件がある場合
    • 本番環境と検証環境を利用する場合
  • メリット
    • インスタンス単位でデータを管理をしやすい
      • 詳細ログが分離されるので調査しやすい
      • 録音データの保存先が分離されるのでセキュリティーコントロールができる
    • 本番/ステージング/テスト 等によって外部システムの接続先やセキュリティーレベルをコントロールできる
  • デメリット
    • 利用料料金もわけられないし、オペレータのログインも分断するので用途によってはムダでしかない

3. 別のAWSアカウントに別のConnect環境を構築する

  • AWSアカウント/Connectインスタンス
    • 2つ/2つ
  • 用途例
    • 業務も人も経費もわけた利用の場合
  • メリット
    • 利用料金が業務ごとに分離できる
  • デメリット
    • 同一人物が複数の業務を担当する場合にログインの使い分けが必要

迷ったとき用マトリックス

簡単マトリックスを作成しました。

赤字のパターン以外は迷わないと思います。

赤字のパターンのときはシステムの組み合わせやある程度の妥協で実現可能なこともあるので、ぜひわたしまでご相談ください。

 

Amazon Data Lifecycle Manager(DLM)でcron式にてスケジューリングできるようになりました!

$
0
0

こんにちは、技術1課の小倉です。
2020/5/26にアップデートがあり、Amazon Data Lifecycle Manager(DLM)でcron式にてスケジューリングできるようになりました!

Data Lifecycle Manager が cron 式に基づくスケジューリングと、週単位、月単位、年単位のスケジュールを含む追加のバックアップ間隔を新たにサポート

今までは、1, 2, 3, 4, 6, 8, 12, 24時間おきにEBSのスナップショットをとるという指定しかできなかったのですが、今回のアップデートでcron式をサポートしたため、週単位や年単位、日付指定などでスナップショットを取得できるようになりました。

cron式は cron(0 * * * ? *) のように書き、左から (分、時、日、月、曜日、年) を指定することができます。この例ですと、毎時0分に実行するという書き方です。

cron式の書式はこちら : Cron Expressions

Amazon Data Lifecycle Manager(DLM)とは

ポリシーを作成することにより、EBSのスナップショットの作成、保持、削除を自動でできます。ポリシーの設定でスナップショットの取得間隔、世代管理や保持日数を指定してスナップショットを管理することができます。また、DLMの利用料金はかかりませんが、保管するEBSのスナップショットの料金は別途かかります。

AWS公式サイト : Amazon EBS スナップショットライフサイクルの自動化

設定手順

新規作成

マネジメントコンソールにログインして、EC2のコンソールを開きます。
ナビゲーションペインの[ライフサイクルマネージャー]をクリックし、[スナップショットのライフサイクルポリシーを作成する]をクリックします。

スナップショットのライフサイクルポリシーを作成する画面で、*がついている必須項目を入力します。

  • 説明 : ライフサイクルポリシーの説明を入力
  • リソースタイプを選択 : 今回はインスタンスを選択
  • これらをタグを持つターゲット : 対象のEC2インスタンスのタグを設定(今回はタグのキーがName、値がserverlessframework)
  • スケジュール名 : 適宜変更(今回は変更なし)
  • ポリシーを次の時間ごとに実行する : 今回のアップデートで指定可能になった Custom cron expression を選択
  • Cron expression : cron式を入力
  • 保持タイプ : カウントか保持期限を選択(今回は保持期限を選択)
  • 保持する : 保持する世代数を入力(今回は5世代保管)

下にスクロールして、[ポリシーの作成]をクリックします。

成功のメッセージが出力されたら[閉じる]をクリックします。
これで設定は完了です。あとはスナップショットが取得されるのを待ちます。

ナビゲーションペインの[スナップショット]をクリックすると取得されたスナップショットが確認できます。
DLMで作成されると説明に「Created for policy: …」と書かれます。今回は保持するスナップショットを5に設定しています(4:21 – 8:22の計5つ)。

スナップショットが5つとっている状態で次のスナップショットを取得すると一番古いスナップショットが削除されます(一番古いスナップショットが5:20になっています)。

既存設定の変更

既存設定の変更の場合は、EC2コンソールで、ナビゲーションペインの[ライフサイクルマネージャー]をクリックして、変更対象のポリシーを選択し、[アクション] – [スナップショットのライフサイクルポリシーを変更する]をクリックします。

[ポリシーを次の時間ごとに実行する]を Custom cron expression に変更し、Cron expressionにcron式を入力します。

下にスクロールして、[ポリシーの更新]をクリックします。

まとめ

Amazon Data Lifecycle Manager(DLM)でcron式にてスケジューリングできるようになりました。今までは指定した時間おきにEBSのスナップショットを取得という設定しかできませんでしたが、より柔軟に取得できるようになりましたので、利用してみてはいかがでしょうか。

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


AWS CodePipeline が AWS Step Functions の呼び出しをサポートしました

$
0
0

はじめに

こんにちは、技術1課の山中です。
昨日久しぶりに外に買い物に出かけたのですが、紫陽花がきれいに咲いてて6月だな〜と思いました。時が経つのは早いものです。

というのはさておき!
今回はこのアップデートについて見ていきます!

CodePipeline が新しいアクションタイプでの Step Functions の呼び出しをサポート

AWS CodePipeline (以下、 CodePipeline) から AWS Step Functions (以下、 StepFunctions) のステートマシンの実行が可能となったようです。

AWS Step Functions とは

Step Functions は、視覚的なワークフローを使用して、分散アプリケーションとマイクロサービスのコンポーネントを調整できるマネージドなサービスです。ASL (Amazon States Language) と呼ばれる JSON 形式の言語でワークフローを定義できます。

AWS Step Functions(分散アプリケーションの調整)| AWS
Step Functions タグが付けられた記事一覧を表示しています。 -サーバーワークスエンジニアブログ

今回 CodePipeline と統合したことによって、アプリケーションのリリースプロセスの一部でテストの実施や、テスト結果による分岐、エラー処理等複雑な処理が Step Functions で実施できるようになりました。

試してみる

今回は Tutorial: Use an AWS Step Functions Invoke Action in a Pipeline – CodePipeline に従い CodePipeline からステートマシンの実行していきます。

準備

パイプラインに StepFunctions を追加する前に、追加対象のパイプラインを 1 つ作成しておく必要があります。
事前に チュートリアル: シンプルなパイプラインを作成する (S3 バケットの場合) – CodePipeline に従いパイプラインを 1 つ作成してください。

サンプルステートマシンの作成

Getting Started with Step Functions – AWS Step Functions に従い、 CodePipeline から実行させるステートマシンを作成します。
テンプレートを利用して作っただけなので、とてもシンプルな ASL となっています。

{
  "Comment": "A Hello World example of the Amazon States Language using Pass states",
  "StartAt": "Hello",
  "States": {
    "Hello": {
      "Type": "Pass",
      "Result": "Hello",
      "Next": "World"
    },
    "World": {
      "Type": "Pass",
      "Result": "World",
      "End": true
    }
  }
}

ステートマシンの実行アクションをパイプラインに追加

作成したステートマシンの実行をパイプラインに追加していきます。

不要なステージの削除

まずは チュートリアル: シンプルなパイプラインを作成する (S3 バケットの場合) – CodePipeline で作成したパイプライン内の不要なステージを削除します。
マネジメントコンソールで CodePipeline を開き MyFirstPipeline を選択します。

編集する ボタンをクリックし、 Production ステージを削除しましょう。

Step Functions 実行ステージの追加

不要なステージを削除できたので、ステートマシンの実行を追加していきます。
Source と Deploy の間にある + ステージを追加する をクリックします。

ステージ名を Invoke とし追加しましょう。

続いて アクショングループを追加する ボタンをクリックし、アクショングループを追加します。

アクション名は Invoke とし、アクションプロバイダーに AWS Step Functions が追加されているので選択しましょう。

入力アーティファクトは SourceArtifact とし、 State Machine Arn に先ほど作成した Step Functions の ステートマシン ARN を入力します。

Input type は Literal を選択し、 Input にステートマシンに渡す JSON を入力します。

{"IsHelloWorldExample": true}

ここまで入力できたら、 完了 ボタンをクリックします。
これで Step Functions の実行ステージが追加されたので、 保存する ボタンをクリックします。

変更をリリースする ボタンをクリックし、パイプラインを実行してみましょう。

Oh……ステートマシンの実行部分で失敗しました…
詳細を見てみると、どうやら CodePipeline から Step Functions を実行するための権限がないようです。

ドキュメントを確認すると、確かに記載されていますね。
Identity and Access Management for AWS CodePipeline – CodePipeline
具体的には以下ポリシーを追加してあげる必要があります。
※ CodePipeline で既存の IAM ポリシーを利用している場合

{
    "Action": [
        "states:DescribeStateMachine",
        "states:DescribeExecution",
        "states:StartExecution"
    ],
    "Resource": "*",
    "Effect": "Allow"
},

IAM ポリシーを更新したので再度実行!

おお、成功しました!!

Step Functions のコンソールからも対象のステートマシンが実行されていることがわかります。
また、入力には CodePipeline の INPUT で指定した値がきちんと渡されていますね。

おわりに

CodePipeline から Step Functions のステートマシンが実行できるようになったことでより柔軟にリリースプロセスを実装できそうですね。

また、この内容は 2020/6/3(水) 12:00 よりYouTube Liveで配信する「30分でわかる AWS UPDATE!」で取り上げますますので、是非ご覧ください!

参考

AWS Client VPN接続後にVPCを経由せずにインターネットにアクセスする方法

$
0
0

こんにちは、技術1課の小倉です。
先日、AWS Client VPNのブログを書いたのですが、このときにVPN接続をしたあとにクライアントからインターネットに接続できなくなって不便だなと感じていたのですが、クライアントからVPCを経由せずにインターネット接続する方法がありました。

AWS Client VPNでSAMLによるフェデレーション認証ができるようになりました!

デフォルトでは、VPN接続をすると宛先がクライアントVPNエンドポイントのデフォルトルートがクライアントで設定されます。そのため、すべての通信がクライアントVPNエンドポイントあてに通信するようになります。このデフォルトルートを入れないようにするためには、クライアントVPNエンドポイントを作成するときに スプリットトンネルを有効にする にチェックを入れる、たったこれだけです。

既存設定であれば、対象のクライアントVPNの設定を選択し、[アクション] – [クライアントVPNエンドポイントの変更] をクリックし、変更することができます。

クライアントのルートテーブルの比較

スプリットトンネルの設定ありなしでクライアントのルートテーブルを比較します。先頭に★がついているルートが注目すべきルートです。

VPN接続前

VPN接続前のルートテーブルです。余計なものがたくさんありますが、前後の比較ということで、すべてを記載します。デフォルトルートがインターネットに向いています。

>netstat -nr
 ~省略~
IPv4 ルート テーブル
===========================================================================
アクティブ ルート:
ネットワーク宛先        ネットマスク          ゲートウェイ       インターフェイス  メトリック
★         0.0.0.0          0.0.0.0     192.168.86.1    192.168.86.22     40
     18.177.91.48  255.255.255.255      192.168.0.1    192.168.86.22     20
     18.177.91.48  255.255.255.255     192.168.86.1    192.168.86.22     20
        127.0.0.0        255.0.0.0            リンク上         127.0.0.1    331
        127.0.0.1  255.255.255.255            リンク上         127.0.0.1    331
  127.255.255.255  255.255.255.255            リンク上         127.0.0.1    331
   175.41.206.125  255.255.255.255      192.168.0.1    192.168.86.22     20
     192.168.56.0    255.255.255.0            リンク上      192.168.56.1    281
     192.168.56.1  255.255.255.255            リンク上      192.168.56.1    281
   192.168.56.255  255.255.255.255            リンク上      192.168.56.1    281
     192.168.86.0    255.255.255.0            リンク上     192.168.86.22    276
    192.168.86.22  255.255.255.255            リンク上     192.168.86.22    276
   192.168.86.255  255.255.255.255            リンク上     192.168.86.22    276
        224.0.0.0        240.0.0.0            リンク上         127.0.0.1    331
        224.0.0.0        240.0.0.0            リンク上      192.168.56.1    281
        224.0.0.0        240.0.0.0            リンク上     192.168.86.22    276
  255.255.255.255  255.255.255.255            リンク上         127.0.0.1    331
  255.255.255.255  255.255.255.255            リンク上      192.168.56.1    281
  255.255.255.255  255.255.255.255            リンク上     192.168.86.22    276
===========================================================================
固定ルート:
  なし
 ~省略~

VPN接続後(スプリットトンネル無効)

スプリットトンネルを無効(デフォルト)の場合、クライアントVPNエンドポイント向けのデフォルルート(10.200.0.130あて)が追加されます。追加されたルートのネットマスクは128.0.0.0で、ロンゲストマッチに従い、追加された方のルートが優先されます。これはメトリックを下げてもロンゲストマッチが優先されるので変わりません。

>netstat -nr
 ~省略~
IPv4 ルート テーブル
===========================================================================
アクティブ ルート:
ネットワーク宛先        ネットマスク          ゲートウェイ       インターフェイス  メトリック
          0.0.0.0          0.0.0.0     192.168.86.1    192.168.86.22     40
★         0.0.0.0        128.0.0.0     10.200.0.129     10.200.0.130     25
     10.200.0.128  255.255.255.224            リンク上      10.200.0.130    281
     10.200.0.130  255.255.255.255            リンク上      10.200.0.130    281
     10.200.0.159  255.255.255.255            リンク上      10.200.0.130    281
     18.177.91.48  255.255.255.255      192.168.0.1    192.168.86.22     20
     18.177.91.48  255.255.255.255     192.168.86.1    192.168.86.22     20
   18.178.252.187  255.255.255.255     192.168.86.1    192.168.86.22     20
        127.0.0.0        255.0.0.0            リンク上         127.0.0.1    331
        127.0.0.1  255.255.255.255            リンク上         127.0.0.1    331
  127.255.255.255  255.255.255.255            リンク上         127.0.0.1    331
        128.0.0.0        128.0.0.0     10.200.0.129     10.200.0.130     25
   175.41.206.125  255.255.255.255      192.168.0.1    192.168.86.22     20
     192.168.56.0    255.255.255.0            リンク上      192.168.56.1    281
     192.168.56.1  255.255.255.255            リンク上      192.168.56.1    281
   192.168.56.255  255.255.255.255            リンク上      192.168.56.1    281
     192.168.86.0    255.255.255.0            リンク上     192.168.86.22    276
    192.168.86.22  255.255.255.255            リンク上     192.168.86.22    276
   192.168.86.255  255.255.255.255            リンク上     192.168.86.22    276
        224.0.0.0        240.0.0.0            リンク上         127.0.0.1    331
        224.0.0.0        240.0.0.0            リンク上      192.168.56.1    281
        224.0.0.0        240.0.0.0            リンク上     192.168.86.22    276
        224.0.0.0        240.0.0.0            リンク上      10.200.0.130    281
  255.255.255.255  255.255.255.255            リンク上         127.0.0.1    331
  255.255.255.255  255.255.255.255            リンク上      192.168.56.1    281
  255.255.255.255  255.255.255.255            リンク上     192.168.86.22    276
  255.255.255.255  255.255.255.255            リンク上      10.200.0.130    281
===========================================================================
固定ルート:
  なし
 ~省略~

VPN接続後(スプリットトンネル有効)

スプリットトンネルが有効な場合は、デフォルトルートが入らず必要なVPN接続に必要なルートが個別で登録されます(VPNを経由して接続するアドレスは172.31.0.0/16)。そのため、AWSへの通信はVPN経由、その他の通信はインターネットへ直接通信できます。

>netstat -nr
 ~省略~
IPv4 ルート テーブル
===========================================================================
アクティブ ルート:
ネットワーク宛先        ネットマスク          ゲートウェイ       インターフェイス  メトリック
★         0.0.0.0          0.0.0.0     192.168.86.1    192.168.86.22     40
     10.200.0.128  255.255.255.224            リンク上      10.200.0.130    281
     10.200.0.130  255.255.255.255            リンク上      10.200.0.130    281
     10.200.0.159  255.255.255.255            リンク上      10.200.0.130    281
   18.178.252.187  255.255.255.255     192.168.86.1    192.168.86.22     20
        127.0.0.0        255.0.0.0            リンク上         127.0.0.1    331
        127.0.0.1  255.255.255.255            リンク上         127.0.0.1    331
  127.255.255.255  255.255.255.255            リンク上         127.0.0.1    331
★      172.31.0.0      255.255.0.0     10.200.0.129     10.200.0.130     25
     192.168.56.0    255.255.255.0            リンク上      192.168.56.1    281
     192.168.56.1  255.255.255.255            リンク上      192.168.56.1    281
   192.168.56.255  255.255.255.255            リンク上      192.168.56.1    281
     192.168.86.0    255.255.255.0            リンク上     192.168.86.22    276
    192.168.86.22  255.255.255.255            リンク上     192.168.86.22    276
   192.168.86.255  255.255.255.255            リンク上     192.168.86.22    276
        224.0.0.0        240.0.0.0            リンク上         127.0.0.1    331
        224.0.0.0        240.0.0.0            リンク上      192.168.56.1    281
        224.0.0.0        240.0.0.0            リンク上     192.168.86.22    276
        224.0.0.0        240.0.0.0            リンク上      10.200.0.130    281
  255.255.255.255  255.255.255.255            リンク上         127.0.0.1    331
  255.255.255.255  255.255.255.255            リンク上      192.168.56.1    281
  255.255.255.255  255.255.255.255            リンク上     192.168.86.22    276
  255.255.255.255  255.255.255.255            リンク上      10.200.0.130    281
===========================================================================
固定ルート:
  なし
 ~省略~

まとめ

AWS Client VPNを利用してもスプリットトンネルの設定を有効にすることで、クライアントからVPCを経由せずにインターネットに接続できます。もしインターネットに接続するためにVPCを経由して通信しているのであれば、スプリットトンネルを使ったほうが不要な通信がAWS内に流れなくなりますので、設定することをおすすめします。

Amazon FSx for Windows File Serverのストレージサイズの拡張、及び、スループットキャパシティの変更ができるようになりました

$
0
0

こんにちは、CSM課の城です。
私は毎朝、AWSのアップデートを見るのをとても楽しみにしています。
今朝は眠気も吹き飛ぶアップデートが来ていました。

Amazon FSx for Windows File Server – Storage Size and Throughput Capacity Scaling

これまで、ファイルサイズの拡張やスループット性能の変更は出来なかったため、実施する際には新しく作り直す必要がありましたが、このアップデートでそんな作業ともお別れすることができますね!

仕組

下記のドキュメントに仕組みが記載されていました。
https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-storage-capacity.html

When you increase the storage capacity of your Amazon FSx file system, behind the scenes, Amazon FSx adds a new, larger set of disks to your file system. The new capacity is available for use within minutes. When the new storage capacity becomes available, you are billed only for the new storage capacity.
Amazon FSx runs a storage optimization process in the background to transparently migrate data from the old disks to the new, larger disks. For most file systems, storage optimization takes a few hours up to a few days, with minimal noticeable impact on your workload performance.

機械翻訳)Amazon FSxファイルシステムのストレージ容量を増加させると、舞台裏で、Amazon FSxは新しい大きなディスクセットをファイルシステムに追加します。 新しい容量は数分で使用できます。 新しいストレージ容量が利用可能になると、新しいストレージ容量に対してのみ請求されます。
Amazon FSxは、バックグラウンドでストレージ最適化プロセスを実行し、データを古いディスクから新しい大きなディスクに透過的に移行します。 ほとんどのファイルシステムでは、ストレージの最適化には数時間から数日かかり、ワークロードのパフォーマンスへの顕著な影響は最小限です。

新しいディスクを追加し、データをコピーして最適化後、古いディスクを削除するようですね。

作成時の確認画面

作成時の確認画面においてもStorage capacity、Throughput capacityの項目の【Editable after Creation】の欄にチェックが入ってます。

注意事項

ドキュメントに記載がありますが、下記の条件があるので、注意が必要です。

  • ストレージサイズの変更は拡張させるのみ、少なくすることは出来ない
  • 拡張は現行の10%を越えるサイズから、最大65,536 GiBまで
  • ストレージサイズの変更をするにはThroughput capacityが16MB/s以上である必要がある
  • ストレージサイズの変更リクエスト後6時間、または、ストレージ最適化プロセスが完了するまでのいずれか長い方の時間まで、ストレージサイズの変更は出来ない

マネジメントコンソールでの変更操作

マネジメントコンソールからストレージサイズ変更、及び、Throughput capacity変更をするには各filesystemの画面にて次の方法で変更できます。

  • [Actions]から[update storage capacity]、[update throughput capacity]を選択

  • Storage capacity、Throughput capacityの表記の右側にある[Update]を選択

各変更の以降の操作は次項以降にて説明します。

ストレージサイズ変更

ストレージサイズの変更についてはPercentage(パーセントでの割合指定)、もしくは、Absolute(拡張後のサイズ(GiB)指定)で指定し、[Update]をクリックすることで変更可能です。

Updating to xx GiB から Optimizing xx% に表示が変わっていきます。

通常表記になると最適化も完了です。

Throughput capacity変更

Throughput capacityの変更についてはDesired throughput capacityの項目をプルダウンから選択し、[Update]をクリックします。

ここで気になる表記があります。

Your multi-AZ file system will fail over and fail back as Amazon FSx switches out the file servers when you initiate a thoroughput capacity update action.

機械翻訳)Amazon FSxがファイルサーバーを切り替えて、容量の更新処理を開始すると、マルチAZファイルシステムがフェイルオーバーしてフェイルバックします。

Multi AZだとThroughput capacity変更にはフェイルオーバー、フェイルバックが発生するようです。

ちなみにSingle-AZ 2のファイルシステムだと下記の表示になっていた為、ダウンタイムが発生するようです。

Your single-AZ file system will experience a temporary loss of availability as Amazon FSx switches out the file server when you initiate a throughput capacity update action.

機械翻訳)スループット容量の更新アクションを開始すると、Amazon FSxがファイルサーバーを切り替えるため、シングルAZファイルシステムの一時的な可用性が失われます。

変更中は下記のように表示されていました。

通常表記になると変更完了です。

最後に

FSx for Windows File Serverの泣き所だった部分が改善される、とても嬉しいアップデートですね。
ファイルサーバー運用は、正直かなり面倒に思われるシステムご担当者が多いと思います。
これを機にAWSマネージドのサービスであるFSx for Windows File Serverのファイルサーバー用途での利用をご検討されてもよいのではないでしょうか。

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

Network Load BalancerがTLS ALPNに対応しました

$
0
0

2020年に5月27日のアップデートでNetwork Load Balancer(以下、NLB)でTLS ALPNが利用できるようになりました。
Network Load Balancer が TLS ALPN ポリシーのサポートを開始

TLS ALPN についての説明は後述しますが、要するにNLBがHTTP/2に対応したということです。
本記事では、「HTTP/2ってなんだっけ?」 というあたりから軽く学びつつ、今回のアップデートの内容を理解していきたいと思います。

HTTP/2とは

HTTPのバージョン2であり、2015年にRFC7540と策定されています。
HTTP/2は前バージョンであるHTTP1.1よりも、いくつかの点で通信効率が上がっています。
例えば、HTTP1.1ではTCPセッション1つあたりの同時リクエスト数は1だったので、Webページにアクセスするたびに複数のTCPセッションを接続する必要がありました。
HTTP/2では1つのTCPセッションの中で並列にリクエストが可能です。

いかにいい仕様であってもソフトウェアが対応していないと使えないわけですが、2015年末の時点で既に主要なブラウザはHTTP/2に対応していたようです。

The standardization effort was supported by Chrome, Opera, Firefox,[11] Internet Explorer 11, Safari, Amazon Silk, and Edge browsers.[12] Most major browsers had added HTTP/2 support by the end of 2015.[13] According to W3Techs, as of May 2020, 46.0% of the top 10 million websites supported HTTP/2.
Wikipedia

したがって、HTTP/2は積極的に使っていくのがいいと思います。
あまり意識している方は少ないと思いますが、気がついたらHTTP/2を使っていたという方が多いと思います。

なお、HTTP/3というのもあるのですが、こちらはまだChromeブラウザ+Googleサイトの組み合わせでしか使われていないようです。

実際に自分でアクセスする時にどのプロトコルが使われているかの確認は各ブラウザの開発ツールで確認できます。
下記はChromeで弊社サイトにアクセスした時のものですが、現実はやや複雑ですね。
多くの外部リンクを含んでいるため、プロトコルが入り混じっていますが、h2がHTTP/2の通信となります。

ALBのよくある構成

AWSでHTTPS通信を使う場合、一般的にはNLBよりもALBがよく使われると思います。
NLBとの比較のためにALBを復習してみます。

ALBの構成図

ALBはHTTP/2に対応しているため、ブラウザも対応していれば自動的にHTTP/2で通信します。
ALBとEC2インスタンスの間の通信はHTTP1.1です。

Application Load Balancer は、HTTPS リスナーに HTTP/2 のネイティブサポートを提供します。1 つの HTTP/2 コネクションで最大 128 のリクエストを並行して送信できます。ロードバランサーは、これらのリクエストを個々の HTTP/1.1 のリクエストに変換し、ターゲットグループの正常なターゲットにこれを分配します。HTTP/2 ではフロントエンド接続を効率的に使用するため、クライアントとロードバランサー間の接続数が減少します。HTTP/2 のサーバープッシュ機能は使用できません。
Application Load Balancer のリスナー

ALBへの通信ログ

クライアントとALBの間でどんなやりとりがされているでしょうか?
curlでALBにアクセスした時のログをみてみると、「GET / HTTP/2」と最終的にHTTP/2でリクエストを出しているのがわかります。
また、今回のお題であるALPNという文字も見えます。

~$ curl -v https://alb.supergood.site
*   Trying 18.180.196.49...
* TCP_NODELAY set
* Connected to alb.supergood.site (18.180.196.49) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.supergood.site
*  start date: May 31 00:00:00 2020 GMT
*  expire date: Jun 30 12:00:00 2021 GMT
*  subjectAltName: host "alb.supergood.site" matched cert's "*.supergood.site"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fbc6f808200)
> GET / HTTP/2
> Host: alb.supergood.site
> User-Agent: curl/7.64.1
> Accept: */*

ターゲットサーバのアクセスログ

今回の検証ではEC2インスタンスでNGINXを動かしていますが、そちらでは「GET / HTTP/1.1」となっているのが確認できます。
確かにALBとターゲットの間はHTTP1.1となっていますね。

10.200.10.52 - - [01/Jun/2020:16:33:48 +0900] "GET / HTTP/1.1" 200 3520 "-" "curl/7.64.1" "106.171.71.150"

TLS ALPNとは

ALPNとは、Application-Layer Protocol Negotiationの略でありTLSの拡張機能です。
アプリケーションレイヤーのプロトコルでHTTPの1.1を使うのか、それともHTTP/2を使うのか、それともさらに別の何かを使うのかをネゴシエーションします。

先ほどのALBの例ではブラウザとALBの接続は結果的にHTTP/2が使われましたが、実はそれはTLSでALPNが使われたからです。
ALBへの通信ログをみると、先頭部分にALPNのネゴシエーション要求が確認できます。

* ALPN, offering h2
* ALPN, offering http/1.1

また、中盤部分にもALPNのネゴシエーション応答が確認できます。

* ALPN, server accepted to use h2

HTTPSで通信をする場合は、TCP接続し、TLS接続し、それでやっとHTTP通信ができるようになります。
このプロトコルスタックの全体的な流れは以下のようになります。

HTTP/2には、ALPNは、ほぼ必須

HTTP/2にALPNは必須かというと、そうではないようです。
ただし、HTTP/2 over TLSの場合ALPNはMUSTであるとRFC7540に記載があります。

implementations that support HTTP/2 over TLS MUST use protocol negotiation in TLS [TLS-ALPN].

では、TLSを使わないHTTP/2なら不要かと思うのですが、各ブラウザは、HTTP/2単独ではサポートせずに、HTTP/2 over TLSのみサポートしているようです。

Although the standard itself does not require usage of encryption,[36] all major client implementations (Firefox,[37] Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.

したがって、一般的にはHTTP/2はにTLSが必須、そうするとALPNも必須と考えていいかと思います。

NLBでHTTP/2を使う

長々と書いてきましたが、これでようやく 「Network Load Balancer が TLS ALPN ポリシーのサポートを開始」 というアップデートが、 「Network Load Balancer が HTTP/2のサポートを開始」 という意味と理解できました。

NLBの構成図

NLBでALPNを使うためには、リスナーをTLS、ターゲットグループもTLSにする必要があります。

Requirements
・ TLS listener
・ TLS target group
TLS Listeners for Your Network Load Balancer

したがって、以下のような構成になります。

ターゲット側にもサーバ証明書を入れたりする必要があります。
なお、ここでは詳細の解説はしませんが、今回の検証で使用したサーバ証明書は、NLB用はACM、EC2インスタンス用はLet’s Encryptで発行しました。

NLBでALPNの設定をする

NLBの設定としては、チェックボックスでALPNポリシーを選択するだけです。
curlの応答でみた 「ALPN, server accepted to use xx」の部分でNLBに何を応答させたいかを考えて選択しましょう。

下記表の日本語はマネコンの説明で、英語はTLS Listeners for Your Network Load Balancerの説明です。

ALPNポリシー 説明
None ALPN を受け入れません。
Do not negotiate ALPN. This is the default.
HTTP1Only HTTP/1 接続だけを許可します。
Negotiate only HTTP/1.*. The ALPN preference list is http/1.1, http/1.0.
HTTP2Only HTTP/2 接続だけを許可します。
Negotiate only HTTP/2. The ALPN preference list is h2.
HTTP2Optional HTTP/1 接続を優先します。HTTP/2 接続を受け入れます。
Prefer HTTP/1.* over HTTP/2 (which can be useful for HTTP/2 testing). The ALPN preference list is http/1.1, http/1.0, h2.
HTTP2Preferred HTTP/2 接続を優先します。HTTP/1 へのフェイルバックを許可します。
Prefer HTTP/2 over HTTP/1.*. The ALPN preference list is h2, http/1.1, http/1.0.

NLBでHTTPS通信をしてみる

各ALPNポリシーでどのような違いがでるか試してみました。
なお、ポリシー変更後、即座には変更が反映されず、数秒〜10数秒程度かかりました。
下記にログを記載しますが、結果としてはドキュメントに記載されている通りの期待通りの動作と確認できました。

None

~$ curl -v https://nlb.supergood.site
*   Trying 18.181.66.175...
* TCP_NODELAY set
* Connected to nlb.supergood.site (18.181.66.175) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=*.supergood.site
*  start date: May 31 00:00:00 2020 GMT
*  expire date: Jun 30 12:00:00 2021 GMT
*  subjectAltName: host "nlb.supergood.site" matched cert's "*.supergood.site"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: nlb.supergood.site
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.12.2
< Date: Mon, 01 Jun 2020 08:46:17 GMT
< Content-Type: text/html
< Content-Length: 3520
< Last-Modified: Wed, 28 Aug 2019 19:52:13 GMT
< Connection: keep-alive
< ETag: "5d66db6d-dc0"
< Accept-Ranges: bytes

クライアントは、「ALPN, offering」していますが、NLBは、「ALPN, server accepted to use h2」といった応答がありません。
その結果、HTTP/1.1が使われています。
NLBとターゲットの間もHTTP/1.1でした。

HTTP1Only

~$ curl -v https://nlb.supergood.site
*   Trying 18.181.66.175...
* TCP_NODELAY set
* Connected to nlb.supergood.site (18.181.66.175) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=*.supergood.site
*  start date: May 31 00:00:00 2020 GMT
*  expire date: Jun 30 12:00:00 2021 GMT
*  subjectAltName: host "nlb.supergood.site" matched cert's "*.supergood.site"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: nlb.supergood.site
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.12.2
< Date: Mon, 01 Jun 2020 08:53:52 GMT
< Content-Type: text/html
< Content-Length: 3520
< Last-Modified: Wed, 28 Aug 2019 19:52:13 GMT
< Connection: keep-alive
< ETag: "5d66db6d-dc0"
< Accept-Ranges: bytes
<

クライアントは、「ALPN, offering h2」していますが、NLBは、「ALPN, server accepted to use http/1.1」と応答しています。
その結果、HTTP/1.1が使われています。
NLBとターゲットの間もHTTP/1.1でした。

HTTP2Only

~$ curl -v https://nlb.supergood.site
*   Trying 18.181.66.175...
* TCP_NODELAY set
* Connected to nlb.supergood.site (18.181.66.175) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.supergood.site
*  start date: May 31 00:00:00 2020 GMT
*  expire date: Jun 30 12:00:00 2021 GMT
*  subjectAltName: host "nlb.supergood.site" matched cert's "*.supergood.site"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f8484009c00)
> GET / HTTP/2
> Host: nlb.supergood.site
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: nginx/1.12.2
< date: Mon, 01 Jun 2020 08:58:18 GMT
< content-type: text/html
< content-length: 3520
< last-modified: Wed, 28 Aug 2019 19:52:13 GMT
< etag: "5d66db6d-dc0"
< accept-ranges: bytes

クライアントは、「ALPN, offering h2」し、NLBも、「ALPN, server accepted to use h2」と応答しています。
その結果、HTTP/2が使われています。
NLBとターゲットの間もHTTP/2でした。

HTTP2Optional

~$ curl -v https://nlb.supergood.site
*   Trying 18.181.66.175...
* TCP_NODELAY set
* Connected to nlb.supergood.site (18.181.66.175) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=*.supergood.site
*  start date: May 31 00:00:00 2020 GMT
*  expire date: Jun 30 12:00:00 2021 GMT
*  subjectAltName: host "nlb.supergood.site" matched cert's "*.supergood.site"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: nlb.supergood.site
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.12.2
< Date: Mon, 01 Jun 2020 09:03:51 GMT
< Content-Type: text/html
< Content-Length: 3520
< Last-Modified: Wed, 28 Aug 2019 19:52:13 GMT
< Connection: keep-alive
< ETag: "5d66db6d-dc0"
< Accept-Ranges: bytes
<

クライアントは、「ALPN, offering h2」していますが、NLBはHTTP/1接続を優先ということで、「ALPN, server accepted to use http/1.1」と応答しています。
その結果、HTTP1.1が使われています。
NLBとターゲットの間もHTTP1.1でした。

HTTP2Preferred

~$ curl -v https://nlb.supergood.site
*   Trying 18.181.66.175...
* TCP_NODELAY set
* Connected to nlb.supergood.site (18.181.66.175) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.supergood.site
*  start date: May 31 00:00:00 2020 GMT
*  expire date: Jun 30 12:00:00 2021 GMT
*  subjectAltName: host "nlb.supergood.site" matched cert's "*.supergood.site"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7ff69500dc00)
> GET / HTTP/2
> Host: nlb.supergood.site
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: nginx/1.12.2
< date: Mon, 01 Jun 2020 09:10:26 GMT
< content-type: text/html
< content-length: 3520
< last-modified: Wed, 28 Aug 2019 19:52:13 GMT
< etag: "5d66db6d-dc0"
< accept-ranges: bytes
<

クライアントは、「ALPN, offering h2」し、NLBも、「ALPN, server accepted to use h2」と応答しています。
その結果、HTTP/2が使われています。
NLBとターゲットの間もHTTP/2でした。

まとめ

今回のアップデートでNLBでHTTP/2を使えるようになりました。
ただし、「クライアントーNLBーターゲット」でエンドツーエンドでTLSであるという条件があります。
おそらく、ALBと異なり、HTTPの処理をNLB側で行わないので、このような仕様になっているのだと思います。

エンドツーエンドで暗号化ができていいと思う反面、ターゲット側での証明書管理の負担がでてきます。
また、NLBでもTLS処理しますが、ターゲット側でもTLS処理するため、TLS負荷をNLB側に完全にオフロードできなくなっています。
ただし、HTTP/2は1.1よりも通信効率が改善されるため、全体としてはターゲットの負荷が増えるとは言えないと思います。

AWSのロードバランサーには、CLB、ALB、NLBとありますが、当初は選択基準が簡単でした。
HTTPやHTTPSはALB、その他のプロトコルはNLBを選べば良かったと思います。
しかし、今回のアップデートのようにNLBでできることも増えてくると、だんだんわからなくなってきました。
確かにALBはWAFが使えたり、リダイレクトしたり、パスベースのルーティングをしたり、選択するメリットがあります。
ただ、単純に高速なHTTPSサーバが欲しい場合、NLBを検討するのもいいのかもしれません。

YouTubeやってます

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

AWS DeepComposerの画面が変わっていたので共有したい

$
0
0

こんにちは、技術2課の濱岡です。
最近、どうぶつの森でカブ価が気になる毎日です。

さて、今回、AWS Deep Composerの画面に変化があったので共有しようと思いブログを書きました。

こちらのブログもよろしければどうぞ。
AWS DeepComposerで遊んでみた
AWS DeepComposerで遊んでみた その2
AWS DeepComposer:別のキーボードでも動くか試してみた

画面見比べ

旧画面

新画面

かなり変わってますよね!
私的におっ!と思ったのがこちら

旧画面

新画面


古い方だと鍵盤のところに音名がかかれているのですが、新しい画面だとA、W、S、E….など書かれていますね。
これは、ピンときている方もいらっしゃると思うのですが…..
キーボードの配列をみてもらえばわかると思います。

そうですね、キーボードからの入力がわかりやすい形になっています。
というかキーボードからの入力が増えた!?!?
古い方で確認していないのでなんともいえないのですが、これはわかりやすくなりましたね。

あとはこちら

モデルのパラメータが見れるようになっていますね。
これも古い方だといちいち別の画面から確認しないといけなかったのですが、これは便利です。

まとめ

今回は、AWS DeepComposerの画面が変わっていたので旧の画面と比べてみました。
他にも細かい部分があるのですが、それはみなさん実際に触ってみてみてください。

以上、濱岡でした!

Viewing all 1210 articles
Browse latest View live


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