こんにちは、AWSセールスエンジニアの加藤カズキです。
ジーンズ、スニーカー、釣具、Tシャツ。。。集めだしたらキリがない、管理が大変なものってありますよね。
AWSの各リソースにも使える数量に上限が設けられています。これまでは個別に管理する必要がありましたが、現在の上限値が一元管理可能な
AWS Service Quotas がリリースされましたのでご紹介します。

AWS Service Quotas とは

対応するAWSリソースの上限値、現在利用値を横断で一元的に閲覧する事が出来ます。

ダッシュボードは、良く利用するリソースを表示出来るように編集可能です。

複数リソースの現在上限値（適用されたクォータ）が一元的に表示されています。

個別のリソースに管理画面でも、標準の上限値(AWSのデフォルトのクォータ)と現在上限値(適用されたクォータ)を確認する事が出来ます。

これは非常に嬉しいアップデートですね！従来ですと都度確認、管理が必要でしたが、AWS Service Quotasの登場によって、設計段階での管理や、上限緩和申請が事前に行えるようになりました。
既に東京リージョンでも利用出来ますので、増々管理がラクチンになりますね！

追記

AWS Service Quotas ダッシュボードへは、マネジメントコンソールから「サービスクォータ」と検索してください。
今現在(2019/6/25 12時頃)だと「AWS Service Quotas」では検索出来ないようです。

こんにちは。限定物に目がない佐藤です。
今日は私の誕生日なのでブログを書くことにしました。

きっかけ

• Elastic BeanstalkでデプロイしたCLBはデフォルトでセキュリティポリシーが「ELBSecurityPolicy-2016-08」が適用されて、TLS1.0 / TLS1.1 / TLS1.2が許可されています。
• PCI DSS準拠な環境ではTLS1.2のみにしないといけない場合、デフォルトから変更する必要がありました。
• お手軽にTLS1.2に限定したくなったのでお手軽な手順を調べました。
• 参考
  • クラシックロードバランサー での事前定義された SSL のセキュリティポリシー

前提

• 事前にAWS CLIのセットアップとテスト用にElastic BeanstalkにてTest-env-1というものを作っておきます。
• CLBでHTTPSリスナーが無いと始まらならないので、以下な設定があることを確認してください。
• ELBの設定で「ELBSecurityPolicy-2016-08」になってることを確認してください。

変更方法

• cliで以下実行してください。Test-env-1とsslpolicyについては環境毎に要変更。

aws elasticbeanstalk update-environment --environment-name Test-env-1 --option-settings Namespace=aws:elb:policies:sslpolicy,OptionName=LoadBalancerPorts,Value=443
aws elasticbeanstalk update-environment --environment-name Test-env-1 --option-settings Namespace=aws:elb:policies:sslpolicy,OptionName=SSLReferencePolicy,Value=ELBSecurityPolicy-TLS-1-2-2017-01

確認

• CloudFormationが実行されてセキュリティポリシーが変更されます。5分くらいで変更されます。
• 以下になっていれば変更成功です！

最後に

• 私自身、.ebextensionsで変更する必要があると思い込んでいましたが、上記手順で変更することができました。
• 普段GUIでデプロイしている環境から.ebextensionsに変更するのは大変なので踏み切れない方のお役に立てたら嬉しいです。

CS課佐竹です。

はじめに

今回は「RDSを本番環境で停止運用しないほうが良いですよ」という理由について記載します。つまり、「EC2の様に夜間は停止して、朝に起動して使いたい」というような要件は、RDSでは積極的に推奨されないのが実情です。その3つの理由について、以下で具体的にご説明いたします。

何故、RDSを夜間に停止したいのか？

ズバリ、コスト削減のためです。RDSは停止している時間はRunning費用がかからなくなります。そのコストを削減するため、「業務時間外は停止としたい」ケースがあるでしょう。例としてですが、毎営業日において、8:00-17:59のみ利用するシステムであれば1日10時間だけの起動でよく、加えて土日は利用自体が不要となります。1ヶ月の営業日を22営業日と仮定しますと、実利用時間は月あたり220時間のみ。1ヶ月 = 31日 = 744 時間 で計算しますと、営業時間だけうまく稼働させることができれば約30%の利用料で済むので、70%の起動コストが削減できます。「おお、これはお得だ。さっそくCloud Autoamtorで夜間にRDSを停止しよう」そう考えるのも頷けます。しかし、本番環境でこれをやる前に、ちょっと立ち止まって一度以下の内容に目を通してみてください。

1. 停止機能は検証用の環境向けである

最初に共有しますのは以下の公式ドキュメントです。

Amazon RDS DB インスタンス » Amazon RDS DB インスタンスのライフサイクル » 一時的に Amazon RDS DB インスタンスを停止する
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_StopInstance.html

こちらの公式ドキュメントの最初に、以下に引用する文章が記載されています。

一時的なテストや毎日の開発作業のために、断続的に DB インスタンスを使用する場合、コスト削減のため、Amazon RDS DB インスタンスを一時的に停止できます。DB インスタンスが停止している間は、プロビジョニングされたストレージ (プロビジョニングされた IOPS を含む) とバックアップストレージ (指定された保存期間内の手動スナップショットと自動バックアップを含む) は請求されますが、DB インスタンス時間は課金されません

一時的なテストや毎日の開発作業のために とまずあります。この文章から見てもRDSの停止が開発環境や、ステージング環境など、「検証環境」の用途を目的として実装されたことが伺えます。最初に重要な点は「この機能は検証完了や開発環境などをターゲットとして提供しています」という点です。ここが「AWSが想定しているメッセージ」となりますため、これ以外の利用用途、つまり本番環境での利用においては「保証されない」ということが示唆されます。

2. 停止、開始に時間がかかる場合がある

先ほどと同じドキュメントに以下の記載もあります。

場合によっては、DB インスタンスを停止するのに長い時間がかかります。

これは読んで字のごとくですが、「停止処理を実行すると直ぐにRDSが停止されることも、いつも同じ処理時間で停止することも保証していない」ことになります。そもそもですが、データベース(DB)は停止に時間がかかります。トランザクション処理が終わってなくて、コミット待ちのデータがあるとか、メモリにある情報をディスクに降ろさないといけないとか、そういうのをしっかりクローズし、問題なく起動するために様々な終了処理が実行されます。つまり、停止にかかる時間は停止タイミングのDBの状況に依存します。それだけでなく、AWSはパブリッククラウドのサービスです。ハードウェアは共有資産のため、たまたま利用している内部のインフラストラクチャの状態が「混雑状態」になっていて、そのために停止に予想以上の時間がかかってしまうという事もあり得ます。この「DBとインフラストラクチャ状態によって停止時間が左右されてしまうために、長い時間がかかる場合がある」というのが、この注記に集約されています。

また、この注記では停止についてのみ記載されており、かつドキュメント「以前に停止した Amazon RDS DB インスタンスを開始する」には明示的に注記はないのですが、開始についても同じ事が言えます。開始にかかる時間も同様に、「停止時のDBの状態から復帰にかかるDBの内部処理の多さ」と「開始時のインフラストラクチャの混雑状況」によって左右されるのが実情です。よって、「EC2のように短時間で停止(Stop)して、短時間で開始(Start)してくれるだろう」という思いこみは危険です。

これらの状況を鑑みると停止も開始も、前後1時間から2時間は余裕をみて運用を行わないといけないでしょう。また、安定性を担保するには実際にそのようにせざるを得ません状況になります。つまり、10:00 AMから使いたいシステムであれば、8:00 AMくらいからはRDSを開始する必要が出ることになり、想定よりも3-4時間ほどコスト削減の効率が悪化するということになります。

これらのように、RDSは停止・開始にEC2よりも慎重になる必要があります。

3. キャパシティ不足時に対応する手段が限られている

これが、RDSを本番環境では停止・開始することが推奨できない最も厳しい理由となります。理由のご説明の前に、キャパシティ不足について記載します。

キャパシティ不足とは？

キャパシティ不足 (insufficient capacity) とは、利用したいRDSのdb.instance classに在庫がない場合に発生します。例えば、t2.smallのdb.instanceを停止⇒開始したとします。この開始のタイミングで、利用しているAvailability Zoneにおいてt2.smallの利用可能なキャパシティ(在庫)が存在しない場合、「t2.smallでは開始できない」という状況になります。これはEC2でも同様で、開始したいInstance Typeのキャパシティが利用したいAvailability Zoneで不足している場合は、そのInstance Typeでは開始が(もちろんLaunchもですが)できません。

EC2におけるキャパシティ不足対応

EC2におけるキャパシティ不足の対応には以下の対応が考えられます。

1. 少しの時間待ってからStart(開始)のリトライを行うことを数度繰り返す
2. キャパシティ不足でEC2が開始できない場合は自動的にStopされるため、Stopped状態のEC2 instanceのInstance Typeを別のTypeへ変更し、Start(開始)を試みる
3. EC2のAMIを取得し、別のAvailability ZoneでLaunch(起動)を試みる
4. 予め、Reserved InstanceをAvailability Zone指定で購入しておく(ゾーン リザーブドインスタンス)
5. 予め、EC2 Capacity Reservation(オンデマンドキャパシティー予約)を利用する

SWXでは運用も行っておりますが、このような場合はまず[1]と[2]を実行しており、おおよその場合ではこの2つで解消します。しかし、どうしても回避できない場合は、[3]の手段を取ることもあります。[4]と[5]はどちらも予めキャパシティを予約しておく方法ですため「そもそもキャパシティ不足を発生させない」という対応策となります。さて、これと比較してRDSのキャパシティ不足を見てみましょう。

EC2と比較したRDSのキャパシティ不足対応

比較して記載します。

1. 〇。Start(開始)の後キャパシティ不足に陥った場合は、停止ステータスでも、起動ステータスでもない状態で固まり、キャパシティが確保されるまでその状態で静止するため、不足が解消するまで待つしかない状況となる
2. ×。キャパシティ不足のRDS db.instanceが停止中の状態では、ModifyコマンドによるInstance classの変更はできない。RDSは起動中のみInstance classの変更が可能なModifyが実行可能なため、Instance classの変更による対応は不可能である
3. △。RDS db.instanceのSnapshotを取得するか、既存の最新のSnapshotを利用し、別のAvailability ZoneでCreate(作成)を試みる。なお同じdb instance identifier(DBインスタンス識別子)は利用できないため、RDSを削除するか変更を行う必要があるが、識別子の変更はModifyで実施するためこれも同様に停止中は利用ができない。そのため、この手順においては合わせてdb.instance削除の実施が必要となる
   1. 補足すると停止中のRDSを削除できるのは通常のRDSのみで、Auroraは停止中に削除ができない点に注意が必要。つまりAuroraの場合は開始時にキャパシティが不足した時点で、同じ名前で別AZにdb.instanceを作成することができないという制約が発生する
4. ×。Reserved InstanceをAvailability Zone指定で購入するオプションが存在しないため、RDSではReserved Instanceを利用したキャパシティ予約が不可能である
5. ×。EC2のCapacity Reservation(オンデマンドキャパシティー予約)のような機能はRDSでは提供されていない

上記の通り、EC2と比較して取れる手は2つしかありません。1つは[1]の、待って祈るという選択です。ですが、いつまで待てばいいのかは不明ですため、長時間の待機でも開始できない場合は[3]で対応となりますが、EC2と異なりRDSではdb instance identifier(DBインスタンス識別子)が一意になっている必要がある、という制約があるために既存の環境を削除しないといけないというのがEC2と異なる点になります。上記の通り、RDSでキャパシティ不足が発生した場合は、かなり対応が難しい状況になるとご理解頂けると思います。

まとめ

いかがでしたでしょうか。本記事では、「RDSを本番環境で停止運用しないほうが良いですよ」という理由について記載してきました。その理由は、以下の3点でした。

1. 停止機能は検証用の環境向けである
2. 停止、開始に時間がかかる場合がある
3. キャパシティ不足時に対応する手段が限られている

特に厳しいとお伝えしましたのは「3. キャパシティ不足時に対応する手段が限られている」になります。そしてこれら3つの理由を鑑みました結果「RDSでは常時起動し続けるのが最も安定した運用になる」ということがご理解頂けるかと存じます。なお、常時起動時のコスト最適化におきましては、同時にReserved Instanceを購入されることも推奨させて頂きます。

それでも本番環境のRDSを停止したい方へ

上記3つの理由を踏まえてみても、「コストを優先されたい」場合に、やはり停止する運用を選択されるという方もいらっしゃるかと考えています。もちろん、そのような選択も可能です。ただし、夜間停止するRDSの保守運用担当が、上記の懸念点を認識されずに保守運用されている場合もあるかと存じますので、これらの懸念点はご理解頂いた上で、適切な選択を頂ければ嬉しく思います。

Modifyによるdb.instance classの変更について

停止運用に関連し、こちらも重要なため記載します。起動中のRDSでは、db.instance classの変更が可能です。その場合ですが、内部的には「停止⇒開始」を伴います。EC2で説明しますと「停止⇒Instance Type変更⇒開始」の流れと同じで、一度停止を経ることになります。そのため「常時起動」と言いましても「定期的にModifyによるdb.instance classの変更を行う」場合には注意が必要になります。つまり、Modifyを行う場合にも停止と同様の懸念が潜在しているということも合わせてご認識頂ければと存じます。

以上で終わりにしたいと思います。皆様もよきRDSライフを。

技術三課のWindowsおじさんこと、鎌田です。
Amazon FSx for Windowsをご検討のお客様も多いかと思うのですが、Directory ServiceのMSADが必須となっている点がネックというケースも多かったのではないかと思います。

その点が、最新のupdateにより既存のActive Directoryドメインでの利用に対応しました！

詳細な条件

AWSドキュメントに詳細が記載されていますが、以下の環境に対応していれば、利用可能です。

• ドメインの機能がWindows Server 2008 R2以降であること
• Active DirectoryのIPアドレスがFSxを構築するVPCと同じVPC内にあるか、以下のIPアドレスレンジにあること
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
• 以下の権限持つActive Directoryのユーザー情報 (ドメイン参加、コンピューターアカウントの追加/削除などを実施するため、それに必要となる権限です)
  • Ability to reset passwords
  • Ability to restrict accounts from reading and writing data
  • Validated ability to write to the DNS host name
  • Validated ability to write to the service principal name

構築してみた

構築を実施してみました。構築手順の詳細は過去のブログも参照いただければと思います。

これまでDirectory ServiceのMSADしか選択できなかったWindows authenticationに、「Self-managed Microsoft Directory」が追加されています。
こちらを選択すると、ドメイン名、ドメインコントローラーのIPアドレス、上記にも記載したドメイン参加の権限などを持つユーザー情報とパスワードの入力を求められるので入力します。

任意選択ですが、FSxのコンピューターを作成するOUも選択が可能です。なおOUに関しては、作成後の変更が出来ないため、ご注意ください。

構築後にアクセスすると、確かに既存のドメインに対してFSxが構築できていることが確認できました！

設定変更が可能な箇所

構築後にマネジメントコンソールを確認すると、ドメインコントローラーのIPアドレスと、ユーザー名/パスワードについては編集可能であることが分かります。その他の部分は編集できないため、構築後の設定変更が行えません。
構築の際に十分検討を実施の上、構築を実施されることを推奨いたします。

おわりに

既存のActive Directoryドメインに参加できるようになったことで、FSx for Windowsを利用する上でのハードルが下がりました。
マネージドなファイルサーバーをご検討のお客様は、是非選択肢に加えてみては如何でしょうか。

ひょっとするとタイトルのようなことをしないといけない時が来るかもしれません。

以下のドキュメントを参考にしました。

Amazon S3: IAM ユーザーが自分の S3 ホームディレクトリにプログラムおよびコンソールでアクセスすることを許可する

下記のIAMポリシーをIAMユーザーへ適用してやればOKです。
ドキュメントと違いはhomeディレクトリはなしを想定しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::バケット名",
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "",
                        "${aws:username}/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::バケット名/${aws:username}",
                "arn:aws:s3:::バケット名/${aws:username}/*"
            ]
        }
    ]
}

ConditionでS3プレフィックスを指定することでそのフォルダしか操作できません。

しかし上記のポリシーだと、マネコンからの操作で一番上に空のフォルダが作れてしまうようです。

なので下記のようにしてみました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::バケット名",
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "",
                        "${aws:username}/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "PutObject",
            "Resource": "arn:aws:s3:::バケット名/*",
            "Condition": {
                "StringLike": {
                    "s3:prefix": "${aws:username}/*"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::バケット名/${aws:username}",
                "arn:aws:s3:::バケット名/${aws:username}/*"
            ]
        }
    ]
}

PutObjectにもConditionでS3プレフィックスを指定してやれば作れなくなりました。

6月11日にβ版として公開しました タイマートリガーをいつでも実行できる機能 を本日正式版としてリリースしました！
正式版に伴い、お客様にて何かご対応いただく必要はございません。
機能のご利用方法や一覧できる情報はマニュアルページをご覧ください。

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

本日から、Cloud AutomatorにAWSアカウントを追加する際に「IAMロール」（IAMロールのARN）を利用することができるようになりました。

これまで、Cloud Automatorを利用するためには、AWS側に作成した「IAMユーザー」の認証情報（アクセスキーIDおよびシークレットアクセスキー）をCloud Automator側に入力する必要がありましたが、今回リリースとなる新方式ではCloud Automator側に認証情報を持たせる必要がなくなるため、より安全にご利用いただけるようになります。

新方式と旧方式の違い

「IAMロール」を利用する新方式は、「IAMユーザー」を利用する旧方式に比べて主に次の点が異なります。

• 新方式では、Cloud Automatorに登録したAWSアカウント毎に、ユーザー側のAWS環境に「CloudFormationスタック」と「IAMロール」が必要となる
• 新方式では、AWSアカウントを登録する過程で、AWSマネジメントコンソールを使ってCloudFormationスタックを作成する手順が必要となる（作業はほぼ自動化されています）
• 新方式では、Cloud Automator側が認証情報を保持しないため、Cloud Automatorからのアクセスを完全に禁止させたい場合は、AWSマネジメントコンソールにて当該IAMロールを削除するだけで済むようになる

旧方式への影響

従来の方法で追加されているAWSアカウントについては、現時点でとくに変化はありません。これまで通りお使いいただけます。

セキュリティの観点からは新方式のほうがより優れた設計となっていますので、今後追加されるAWSアカウントについては新方式のご利用をおすすめします。

なお、既存のAWSアカウントを新方式に切り替えることはできません。既存のジョブや後処理が参照するAWSアカウントを新方式に切り替えたい場合は、新方式で新たにAWSアカウントを追加したうえで、各ジョブや後処理の設定を変更してください。

新方式の使い方

IAMロールを利用してAWSアカウントを追加する場合は、グループの追加ページや編集ページで「AWSアカウントの追加」ボタンを押します。

すると以下のようなダイアログが表示されます。

①の「IAMロールを作成」ボタンをクリックしてください（このボタンをクリックしないとSTEP2の作業は行えません）。すると、AWSマネジメントコンソールがブラウザの別ウィンドウまたはタブで開かれるので、クイックスタートガイドの「IAMロールによるAWSアカウントの登録を行う」を参考にAWSマネジメントコンソール側でCloudFormationスタックの作成を行います。

CloudFormationスタックの作成が完了したら「IAMロールのARN」を控えて、Cloud Automator側のダイアログに戻り、②にIAMロールのARNを入力します。③にはCloud Automator内における識別用の任意の名前を入力します。

最後に「AWSアカウントの追加」ボタンを押すと一時的な仮登録が行われます。最終的な登録はまだ完了していませんので、最後にグループの追加や更新を行って、IAMロールを利用したAWSアカウントの追加は完了となります。

終わりに

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

こんにちは！

サーバーワークス入社1年目の松井です！

入社して3ヶ月で無事目標であった二冠を達成することができました！！

ので、

OJTが始まる前に合格までの道のりを書いていこうと思います！

まず入社して1ヶ月はネットワークとサーバーの本をみっちり読み込んで基礎を固めました！

インフラのことは全然知らなかったのでこれらの本を読んで面白いなと思いながら勉強してました！

　スライド図解 これ1冊でマスターできる! ネットワークのしくみと動きがわかる本

https://www.amazon.co.jp/dp/480261120X

　イラスト図解式 この一冊で全部わかるサーバーの基本

http://www.amazon.co.jp/dp/4797386665

インフラの基礎知識が固まったところでゴールデンウィーク明けからはLinuxコマンドを勉強しつつ、AWSのネットワーク&サーバー構築でマネコンを触りながらSAアソシエイトの対策本をやりました！

本読むのと同時並行で実際に手を動かしてみると理解度がめちゃめちゃ上がるなと実感

　最短突破 AWS認定ソリューションアーキテクト アソシエイト 合格教本 

http://www.amazon.co.jp/dp/4297103826

　Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

http://www.amazon.co.jp/dp/4822237443

問題集はこちらを使いました！英語ですが最新の問題があって値段も格安なのでとても役に立ちました！

https://www.udemy.com

　AWS SAアソシエイト受験

対策本と問題集をやり込んで満を辞して5月の3週目にAWSソリューションアーキテクトアソシエイトを受けに行ったところ見事に、、、、

落ちました！

結果は700点！

合格点の720点に20点及ばずに不合格となってしまいました。。。

自分の人生いつも一発合格なんていうかっこいい経験はできないんだろうなと改めて実感

原因は細かいところを詰め切れていなかったことと、検定本の知識だけでは本番の問題の全てに対応していないことでした。。。

でもこんなのはいつものことなので、

気持ちを入れ直し、制限が取れる2週間後に受かってやることを決意！！

　2週間の間にやったこと

・Black beltをひたすら読み込む

・試験の復習

・問題集の解き直し

・検定本完璧にする

これらをやったとこ見事に、、

6月の1週目に合格できました！！

755点！

うーーん、低い

という感じでした！

解いてた感覚的にギリギリかなと思ったんで受かっただけ良かったです！

　受けてみた感想

・EC2、EBS、S3、DainamoDB、RDS、Route53、ALB、セキュリティー関係は深いとこまで出してくるなというイメージで他はさらっと

・新しい技術の話が結構出る

・時間は結構余裕がある

・細かいところまで押さえておかないと痛い目見る

　AWS SOAアソシエイト受験

次に先輩社員にsysopsだったらSAと似てるよって言われ、

残りの研修期間特にやることもなかったので、

AWSsysops受験を決めました！

こちらはアソシエイトと同じ問題集を2週間やっただけで臨みました！

完全に自信がなくて、問題を解いてる途中も落ちたなと思いながら萎えて問題解いてたらなんと、

受かってました！

738点！

うーーん、

相変わらずギリギリ、、

受かってラッキーでした笑笑

　受けてみた感想

・タグの話とか証明書関係の話とか完全にノータッチだった問題が多くて全然わかんねーと思いながら解いていた

・メトリクスの話が結構出る

・とにかくCloudWatch

・セキュリティーの話とか高可用性の話とかは結構SAとダブってる

・わかんなかったところに関しては触ったことがないので対策しようがなかった

・突撃したらなんとかなった

　まとめ

以上サーバーワークスでの3ヶ月間の二冠を取るまでの奮闘記でした！

少しでも参考になればと思っています！

僕みたいに一回落ちたとしても諦めずに受けるといいことあります！

今後はSAProを見据えながら実務を頑張りたいです！

それではみなさんまた！

こんにちは、技術3課の城です。
先日、Amazon Elasticsearch Service（以降、AES）にVPC Flowlogsのデータを投入するという内容のブログ記事を書きました。
今回はこのAESを用いてアラート機能を用いて時間当たりのリジェクトの異常発生を検知、Slack投稿する、というのをやってみたいと思います。

1.前提条件

AESにVPC Flowlogsのデータが投入できていること

2.SlackのIncomming Webhookの用意

こちらの当社ブログの「PowerShellがSlackに投稿するための準備」の内容を実施します。

3.Destinationの追加

Destinationは通知先の設定となります。
用意されている送り先としてはSlack、Amazon SNS、Amazon Chime、Custom Webhookとなります。
今回はSlackを利用します。

Kibanaにブラウザでアクセスし、左側サイドバーの[Alerting]⇒上部タブの[Destinations]⇒[Add Destination]と順にクリックします。

[Name]、[Type]、[WebhookURL]を入力し、[Create]をクリックします。

4.Monitorの作成

Monitorはモニタリングの間隔、対象期間やどういう条件のログを検出するか、といった設定を行います。

左側サイドバーの[Alerting]⇒上部タブの[Monitors]⇒[Create Monitor]と順にクリックします。

下記内容を設定します。

【Configure Monitor】

【Define Monitor】

Define extraction queryについては、具体的には下記のように記載しました。
VPC外（!dstaddr:”10.200.0.0/16″）に対するアウトバウンド通信で、REJECT（action.keyword:”REJECT”）のログを検出したいという意図のクエリとなります。

{
    "size": 0,
    "query": {
        "bool": {
            "must": [
                {
                    "query_string": {
                        "query": "action.keyword:\"REJECT\" AND !dstaddr:\"10.200.0.0/16\"",
                        "analyze_wildcard": true,
                        "default_field": "*"
                    }
                },
                {
                    "range": {
                        "@timestamp": {
                            "from": "now-15m",
                            "to": "now",
                            "format": "epoch_millis"
                        }
                    }
                }
            ]
        }
    }
}

画面は↓の感じです。

こちらは参考とさせていただいた下記のQiita記事に記載のように、DiscoveryなどでGUIでクエリをかけて、[Inspect]からRequestの内容をみると作成しやすいかと思います。
https://qiita.com/hssh2_bin/items/06550d437ceb095a139c

設定したら、[Create]をクリックします。

5.Triggerの作成

Triggerの作成画面に遷移しますので、設定していきます。
下記の画像のように設定していきますが、デフォルトのメッセージにDashboardのURLを追加してみました。

設定内容を記載したら、[Create]をクリックします。
こちらで設定は終わりです。

6.確認

試しにセキュリティグループのアウトバウンドルールを削除して、アラート発報するかテストしてみるとうまくいきました。

こんな感じのアラートメッセージが送られてきます。

※時間はUTCで表示されます。

用意していたダッシュボードにアクセスし、時間を合わせてみると、いろいろリジェクトされていたことが分かります。

7.おわりに

クエリを良い具合に考えれば、色々とうまく使えそうな機能だなと思いました。
ただ最近思うのは、AESにVPC Flowlogsを集約しての運用は環境が大きくなればなるほどデータ量も大きくなり、クエリやデータ収集自体での負荷が高いものとなります。
コストをかけてスペックをガンガン上げられる場合はいいかもしれませんが、安定運用するためにはデータをフィルタするなど、用途を限定的にして使えるとよいのかなと感じました。

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

参考資料

https://qiita.com/hssh2_bin/items/06550d437ceb095a139c

こんにちは、技術３課の城です。
先日、下記のドキュメントが更新されていることに気づきました。
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/copy-custom-image.html

そう、WorkSpacesのカスタムイメージコピー（リージョン間も！！）が出来るようになっていたのです！！

これまではリージョンレベルの障害に対してのDiserster Recovery（以降、DR）を意識したWorkSpaces運用をする場合、DR先のリージョンで一からイメージを作成しておく必要がありました。
これからは数クリックでカスタムイメージ自体をコピーできるとなると、かなりハードルが下がった気がします。
早速、DR構成を試してみます。

1.前提

メインリージョンは東京リージョン（ap-northeast-1）とし、DR先をシンガポールリージョン（ap-southeast-1）とします。

2.構成

構成としては定石通り、東京リージョン側はアベイラビリティゾーン（以降、AZ）を2つ利用し可用性を担保します。
Active Directory（以降、AD）on EC2をそれぞれのサブネットに配置し、レプリケーションさせます。
東京リージョン側のAD Connectorについてはこちらの2台のADをDNSサーバーとして登録します。
DR先のシンガポールリージョンのVPCとはVPCピアリングを利用してVPC間を通信可能にします。
シンガポールリージョンのVPCにもADを配置し、東京リージョン側と同一ドメインのドメインコントローラーとして稼働させ、レプリケーションします。
シンガポールリージョンのAD ConnectorについてはシンガポールリージョンのADをDNSサーバーとして登録します。
利用者は別リージョンのWorkSpacesを利用したい場合はレジストレーションコードを変更してアクセスします。

全てをホットスタンバイさせるのはコストが高くつくので、RTOが1時間程度許容され、かつ、障害時に構築することが可能であれば、障害発生後にAD Connector及び、WorkSpacesを作成する方針でもよいかと思います。
また、AD Connector + AutoStopのWorkSpacesを1台だけ作成しておく、など状況に応じて選択するかなと思います。

3.WorkSpacesイメージの作成

下記公式ドキュメントに沿って、東京リージョン側でWorkSpacesイメージを作成します。
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/create-custom-bundle.html

豆知識ですが、Windows Updateされていないとイメージ作成に失敗するので、イメージ作成前はWindows Updateの確認 + 再起動をしておくと幸せになれます。

4.イメージのコピー

冒頭のドキュメントに沿って、イメージをシンガポールリージョンにコピーします。

マネジメントコンソールのWorKSpacesの画面にて左側サイドバーの[イメージ]をクリックします。
コピー元となるカスタムイメージにチェックし、[アクション]⇒[イメージをコピーする]とクリックします。

[対象を選択する]（コピー先のリージョン）、[コピーの名前]、[説明]を入力し、[イメージをコピーする]をクリックします。

なお、コピー先にDirectory ServiceやWorkSpacesなどのリソースを作成していなくても、イメージコピーは可能なようです。

5.イメージの確認

シンガポールリージョンにイメージがコピーできているか確認します。
コピーを開始してすぐはステータスが「PENDING」となっていましたが、10分はかからず「AVAILABLE」となりました。

6.バンドルの作成

シンガポールリージョンにて、コピーしたイメージからバンドルを作成します。
コピーしたイメージにチェックし、[アクション]⇒[バンドルの作成]とクリックします。

必要な項目を入力し、[バンドルの作成]をクリックします。

7.WorkSpacesの作成

下記ドキュメントを参考にシンガポールリージョンにて、WorkSpacesを作成します。
バンドルの選択の際に、作成したカスタムバンドルを選択して作成します。
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/launch-workspace-ad-connector.html#create-workspace-ad-connector

8.アクセス確認

ユーザーから東京、シンガポール、それぞれへのアクセスを制御するものとしては、「レジストレーションコード」となります。
東京、及び、シンガポールリージョンのWorkSpacesのレジストレーションコードを登録し、ログインしてみます。
詳細なログイン方法についてはこちらのブログでもご紹介しておりますので、不明点ある場合はご覧ください。

WorkSpacesクライアントを起動し、[歯車マーク]⇒[登録の管理]とクリックします。

東京リージョン側のWorkSpacesのレジストレーションコードを入力し、[登録]をクリックします。

[ユーザー名]、[パスワード]を入力し、[サインイン]をクリックします。

ログインできました。
Powershellで下記コマンドを実行して、メタデータを取得しAZを確認してみます。

Invoke-RestMethod -Uri "http://169.254.169.254/latest/meta-data/placement/availability-zone" -Method GET

このWorkSpaceはap-northeast-1cに配置されていることが分かります。

WorkSpacesクライアントのレジストレーションコードを変更し、シンガポールリージョン側のWorkSpacesも同一ユーザーでログインし確認してみます。

こちらのWorkSpaceはap-southeast-1aに配置されていますね。
WorkSpacesのDR構成ができました。

9.おわりに

WorkSpacesのDRというと、ハードルが高いものと感じていましたが、イメージコピーができるようになって、少し緩和された気がします。
ただし、今回作成してみた構成においてはユーザー領域のデータについては同期されていないので、WorkSpacesの外部にデータを持たせる設計にするなど、少し工夫が必要かと思います。
必要な要件に応じて、適切な設計ができるといいですね！

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

CS課佐竹です。

最近、Amazon WorkSpacesの運用で少々困ることがあったため共有目的で記載します。

はじめに

Amazon WorkSpaces （ワークスぺース） では、EBS Volumeの「Modify」のようにDiskサイズの変更が可能となっています。公式ドキュメントのリンクは以下の通りです。

Amazon WorkSpaces » 管理ガイド » WorkSpaces の管理 » WorkSpace の変更
https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/modify-workspaces.html

ボリュームのサイズを変更する際の制限

早速ですが制限を見ていきます。

1. 組み合わせの制限

WorkSpacesのボリュームサイズで利用可能な組み合わせは、2019年7月現在以下の一覧の通りとなっております。

まずWorkSpacesのボリュームサイズには、上記の組み合わせ以外は選択できないという制限があることをご理解頂ければと存じます。
補足しますと、上記種類の「バリュー」が80 GBと10 GBの組み合わせというのは「AWS側が決めた推奨初期値」となっております。構築時にユーザ側でこれ以外の値に変更することも可能ですが、その組み合わせは上記の一覧の中におさまっている必要があります。具体的には、RootのCドライブを100GBにすることはできません。また、UserのDドライブに80GBを選択することもできません。この「組み合わせが上記一覧におさまっている必要がある」という制限は、初期構築時だけではなくボリュームサイズの変更時にも当てはまります。

CドライブもしくはDドライブの片方しか1度に変更できない

先に記載した内容への追加になるのですが、ボリュームのサイズ変更はRootとUserボリューム、それぞれ別々に実行する必要があります。よって、CドライブとDドライブが80 GBと10 GBの組み合わせのWorkSpaceを、175 GBと100 GBの組み合わせに一度に同時変更はできないのが現状です。もし現在ご利用されているWorkSpaceのCドライブの80 GBが容量不足で、かつDドライブのサイズが10 GBしかない場合は、一度Dドライブを100 GBに変更してから6時間待機の後、Cドライブを175 GBへと拡張するという段階を踏んでいただく必要があります。一度に同時変更はできない点にご注意ください。

ボリュームのサイズは縮小できない

一度、拡張したボリュームのサイズは小さくすることはできません。例えば50G GBを100 GBに拡張した後、改めて50 GBに縮小するということはできません。

2. 変更が可能な時間の制限

公式ドキュメントに記載がありますが、ボリュームの拡張は 6 時間に 1 回リクエストできます。一度ボリュームサイズの変更を実行すると、その後6時間は変更ができません。また、この「6時間に1回」という制限は、「構築直後のWorkSpace」にも当てはまります。つまり、新規に構築されたWorkSpaceでは、その後6時間はボリュームサイズの変更ができないということになります。実際に構築直後のWorkSpaceに対してボリュームサイズの変更を行ってみましたところ、以下のエラーが発生しました。

「Error Modifying WorkSpace Properties」とエラー表示がされます。このようなエラーが発生した場合、「WorkSpaceが構築されてから6時間が経過したかどうか？」「前回のボリュームサイズの変更から6時間が経過していないのではないか？」という2つの観点から切り分けを行う必要があります。合わせて、以下の公式のナレッジセンターもご参考ください。以下のナレッジセンターにおいても「6 時間に 1 回、ボリュームの増加をリクエストできます。」と記載があります。

WorkSpaces のボリュームサイズまたは計算タイプを変更するにはどうすればよいですか?
https://aws.amazon.com/jp/premiumsupport/knowledge-center/workspaces-change-volume-size/

なお残念ながらこの「WorkSpaceの構築もしくは前回の変更から6時間が経過したかどうか」はマネジメントコンソールからも、CLIからも確認する術がありません。そのため確実な方法としてはエラーが発生した場合は6時間の待機を行い、再度実行するのが確実となります。

3. 変更が可能なボリュームタイプの制限

WorkSpacesのボリューム(EBS Volumeと同等です)は、現在 Magnetic ではなく SSD で構築されています。これは2017年1月31日のリリースで発表された仕様変更となります。詳細は以下の公式ブログをご確認ください。

Amazon WorkSpaces の更新 – SSD ボリュームとコストオプティマイザ
https://aws.amazon.com/jp/blogs/news/amazon-workspaces-update-ssd-volumes-and-cost-optimizer/

これに加えて、重要なのが以下の制限です。最初にご紹介しました公式ドキュメントの注記において記載がありますが「サイズ変更できるのは、SSD ボリュームのみです。」という箇所です。つまり、WorkSpaceのボリュームサイズを変更しようとしても、変更ができるのは2017年1月31日以降に新規構築(Create)もしくは再構築(Rebuild)したWorkSpaceのみとなります。そしてさらに残念ながらこの「WorkSpaceのボリュームがMagneticなのかSSDなのか」はマネジメントコンソールからも、CLIからも確認する術がありません。調査が必要な場合、AWSサポートに問い合わせを行うか、もしくは対象のWorkSpaceの過去の操作履歴を追う必要があります。ただし、ある条件の時だけ確実にマグネティックであると判断できる条件があります。そのご説明のために、先に以下のリリースをご連絡致します。

Amazon WorkSpaces now comes with larger root volumes
https://aws.amazon.com/jp/about-aws/whats-new/2016/06/amazon-workspaces-now-comes-with-larger-root-volumes/

2016年6月24日にリリースされたこの拡張により、それ以後のWorkSpaceのRootボリューム(Cドライブ)は80 GBになりました。つまり時系列に並べると以下の通りです。

この一覧から判断が可能なのは「Rootのボリュームサイズが 60 GBのWorkSpaceは確実にマグネティックであるためボリュームのサイズを変更することはできない」という点です。注意が必要なのは、80 GBであっても、マグネティックで構築が可能となっていた時期が半年間ほどありました。よって、 80 GBだからといってSSDであるという判断は誤っている場合があることも留意が必要です。なお、マグネティックのボリュームをModifyにて拡張しようとした場合も、同様に「Error Modifying WorkSpace Properties」とエラー表示がされます。

停止中にもボリュームのサイズの変更は可能か？

制限に関連して記載させて頂きます。停止中のWorkSpaces、つまりSTOPPEDステータスのWorkSpaceに対してのボリュームサイズの変更ですが、結論からお伝えすると「可能」です。よって、制限には当たりません。ただし、変更中のステータスが画面に表示されないため、進行状況が把握しにくいというデメリットがあります。それを確認するために「aws workspaces describe-workspaces」が利用可能です。aws workspaces describe-workspaces を実行すると、”ModificationStates” という値が確認できます。この値は、ボリュームサイズの拡張が進行中では、以下の結果が返ります。

"ModificationStates": [
                {
                    "Resource": "USER_VOLUME",
                    "State": "UPDATE_IN_PROGRESS"
                }
            ]

この値を確認することで、停止中のWorkSpaceでもボリュームサイズの変更が正常に動作しているか確認が可能となります。

ボリュームサイズ変更の運用ワークフロー

これまでに記載しました上記3つの制限を加味した簡易的な運用ワークフローを記載してみました。

以下、フローの補足説明となります。

1. サイズが不適切な場合、再度申請時に「やはり再構築(リビルド)が必要」と連絡されると利用者もやり取りが面倒と感じる可能性を加味して、サイズの確認時に同時にRootボリュームサイズが60 GBかどうか＝マグネティックかどうかも合わせて確認してから連絡を返すフローにしています
2. 6時間経過した後でもエラーになる場合に、AWSサポートに問い合わせを行う作業を挟んでいますが、これは「マグネティックが原因ではない可能性も加味して」行うもので、凡その場合はマグネティックと考えられますため、フロー上はそのままマグネティックだった場合の再構築調整に進む想定です
3. 「再構築の調整」と「再構築実施」のフローは本フローとは別で管理する想定のため、「再構築を調整」とだけ記載しています。再構築が完了した場合は、再度本フローが実行される想定です

まとめ

本記事では、WorkSpacesの運用における「ボリュームのサイズを変更する際の制限」についてまとめさせていただきました。制限は大きくわけて以下の3つの制限について記載しました。

1. 組み合わせの制限
   1. 決められた組み合わせが存在すること 
   2. CドライブとDドライブは同時に拡張ができないこと
   3. 縮小ができないこと
2. 変更が可能な時間の制限
3. 変更が可能なボリュームタイプの制限

これらに加え、記事の最後に運用ワークフローも提示させて頂きました。こちらのワークフローは「フロー策定時の叩き台」としてご利用いただければ幸いです。
この記事の通り、WorkSpacesのボリュームのサイズを変更するという作業1つ取っても注意すべき点が多々あります。というわけで、Amazon WorkSpacesの運用にお困りでしたら、是非サーバーワークスまでお問い合わせください。

ではまたお会いしましょう。

こんにちは。

サーバーワークス新人の松井です。今回はReadOnlyAccessポリシーがアタッチされたユーザーのパスワードを変更する方法を紹介します。

IAMグループに以下のポリシーをアタッチし、作成したIAMユーザーをIAMグループの配下におきました。

・ReadOnlyAccess

・IAMUserChangePassword

この状態でReadOnlyAccessのユーザに入って、　コンソール>IAM>ユーザー>認証情報>コンソールのパスワードにある[管理]　からパスワードを変更しようとすると以下のように表示されて変更できません。

しかし、　コンソール画面の右上のアカウントID>マイセキュリティー資格情報>コンソールアクセスのパスワード　からパスワードを変更すると変更できます。

こんにちは、AWSセールスエンジニアの加藤カズキです。週末は近所のホームセンターは赴いて草花を買い、自宅に植えるのが楽しみです。
3歳になる娘も10秒くらいは手伝ってくれます。後は1人です。家族との時間は何ものにも代え難いです。

さて、私はセールスエンジニアとして多くのお客様先へご訪問し、様々な課題をお聞かせ頂いています。
その中でよく伺うのが
「AWSを使ってみたいがサービスの数が多く何から検討したらいいか分からない」
「いつかAWSを使ってみたいが、今は特に検討する対象が無い」
といった類のお話です。
そのようなお悩みのお客様へはまず最初にこのようなご案内をします。

「まずはAmazon Route53のご利用をご検討されてみてはいかがですか？」

本章では、何故最初にAmazon Route53を検討することが有用なのかを共有します。

そもそもAmazon Route53って何？

AWSの提供するフルマネージド型のDNSサービスです。
ユーザの利用するドメインの名前解決（IPアドレスとのマッピング）機能を利用する事が出来ます。
ほとんどの企業に於いて、ドメインを保有しており、コーポレートサイトやメールサービスでDNSは利用していると思います。
Amazon Route53によって、現状のDNS環境をグレードアップ出来る可能性があります。

公式ドキュメント：
Amazon Route53 https://aws.amazon.com/jp/route53/

Amazon Route53を検討するべき理由その１：スイッチング・コストの負担が少ない

Amazon Route53は利用した分だけ課金される従量制です。

Amazon Route53 の料金
ホストゾーンごとに 0.50 USD/月 – 最初の 25 個のホストゾーン
標準的クエリ
100 万件のクエリごとに 0.400 USD – 最初の 10 億件のクエリ/月
https://aws.amazon.com/jp/route53/pricing/

まず、サービスを利用するにあたっての初期費用を意識する必要がありません。
また、月額費用も上記記載の通り非常に安価です。
登録するホストゾーン(ドメインの事です)の数やDNSクエリ(参照数)にもよりますが、1ゾーン¥1,000/月くらいで見通しを立てる事が出来ます。

また、DNSの切り替えを不安に思われる方もいるかもしれませんが、JPRSでも手順が公開されているように、一般的に行われている対応です。
簡単に手順を記載すると以下の通りです。

1,移管先DNSに各種レコード情報を登録する
2,移管元DNSのTTLを最小にする(重要)
3,対象ドメインの委任情報(DNSの参照先)を移管先DNSに切り替える

こうする事で、一時的に新旧両方のDNSを並行運用する事が可能で、名前解決の取りこぼし無く移管する事が出来ます。

Amazon Route53を検討するべき理由その２：高機能である

DNSの主たる役割は対象ドメインの名前解決ですが、Amazon Route53にはそれ以外にも様々な機能が用意されています。
すぐにでも利用出来る有用な機能を１つ紹介します。

ヘルスチェックとフェイルオーバー機能

指定したIPアドレス(サーバ)に対してヘルスチェックを行う事が出来ます。
更に、Aレコードに2つのIPアドレスを登録する事も可能です。
これらを組み合わせると、Webサーバに万が一障害が発生した場合、Amazon Route53のヘルスチェック機能を使ってSorryサーバへフェイルオーバーさせるという構成が手軽に実現できます。

Amazon Route53を検討するべき理由その３：BCP対策になる

Amazon Route53は恐ろしい程に冗長化されています。
NS（ドメインに指定するDNSの参照先)が4つ付与されます。この4つはリージョンが異なり、国を跨いだ冗長構成が取られます。
SLAは100%で定義されています。グローバルでの冗長構成に裏打ちされた設定値ですよね。
DNSはその重要性に比べると、比較的安価に運用出来るサービスです。サイト閲覧やメール利用を考慮すると、BCP対策は念頭に入れるに越した事はありません。

おわりに

いかがでしたでしょうか。
Amazon Route53は、単純なDNS機能に留まらず、高付加な機能がアドオンされているいかにもAWSらしいサービスだと個人的には感じています。
切り替えもさほど複雑な手順ではありませんので、ぜひご検討ください。
家族との過ごす時間は1秒でも長く、DNS切り替えの際のTTLは1秒でも短く。これが人生で最も重要な事です。

こんにちは。技術二課の伊藤Kです。

Sysprepについて、こんな記事を書きました。
【EC2】Sysprepの手順【Windows】

上記手順に沿ってSysprepを実施したところ、OSのドライブレターが、
Sysprep前は「システム：C、データ：G」だったのに・・・

Sysprep後に「システム：C、データ：D」になってしまいました・・・。

もともと「システム：C、データ：D」のときは変化なし、「システム：C、データ：E、データ：G」のとき「システム：C、データ：D、データ：E」になってしまうので、データドライブがDから順番に並べなおされるように見えます。

今日は、データドライブのSysprep前のドライブレターを維持する方法についてです。

はじめに

前提として、まずこの現象はバグではなく仕様です。

EC2Configの場合

EC2Config サービスを使用した Windows インスタンスの設定

システムは、インスタンスにアタッチされたボリュームにドライブ文字をマッピングします。Amazon EBS ボリュームの場合、デフォルトでは D: から Z: のドライブ文字が割り当てられます。

EC2Launchの場合

EC2Launch を使用した Windows インスタンスの設定
こちらは明示的な記述はありませんが、動きはEC2Configと同じです。

ドライブ文字のマッピング

冒頭に「Sysprep前のドライブレターを維持する方法」と書きましたが、イメージとしては「維持する」というよりも、「指定する」となります。Sysprep前と同一のレターの指定も可能です。

EC2Configの場合

まず、ドライブ文字を割り当てたいドライブには、あらかじめOSの設定より「ボリュームラベル」を設定しておきます。
ここでは、Hドライブに「FILES」のボリュームラベルを設定しました。

EC2Configを用いたSysprepの手順内で、プログラム一覧よりEC2Configを開いた後に「Storage」タブを選択し、
「Drive Letter Mappings」のペインより [Mappings] をクリックします。

「Volume Name」に設定した「ボリュームラベル」の値を入力し、「Drive Letter」に指定するドライブレターを入力します。
維持するなら「Hドライブ」でよいのですが、ここでは「Gドライブ」に変更してみます。
[OK] をクリックします。

その後は通常のSysprepと同様に [Shutdown with sysprep] をクリックしてSysprepします。

Sysprepが完了してシャットダウン状態となったインスタンスよりイメージ（AMI）を作成し、作成したイメージよりインスタンスを起動すると、指定したボリュームラベルのドライブに、指定したドライブレターが付与されています。

EC2Launchの場合

※ 記事作ってから気づきました。OSの「ディスクの管理」からドライブ文字を普通に振りなおせばよくないか、と。
以下は参考情報として載せておきます。

EC2Launchには、「Drive Letter Mappings」の項目がありません。
EC2Configの場合と同様に、ドライブ文字を割り当てたいドライブには、あらかじめOSの設定より「ボリュームラベル」を設定しておきます。

さらに、「C:\ProgramData\Amazon\EC2-Windows\Launch\Config\DriveLetterMappingConfig.json」をメモ帳等で開き、以下の通り記載します。

{
  "driveLetterMapping": [
    {
      "volumeName": "DATA",
      "driveLetter": "G"
    }
  ]
}

その後は通常のSysprepと同様に [Shutdown with sysprep] をクリックしてSysprepします。

Sysprepが完了してシャットダウン状態となったインスタンスよりイメージ（AMI）を作成し、作成したイメージよりインスタンスを起動すると、今度はDドライブになってしまいます。

ここで、以下パスのPowerShellスクリプトを実行します。
　C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeDisks.ps1

すると、ドライブレターが上記「DriveLetterMappingConfig.json」で指定した文字に変更されます。

参考情報

EC2Launchでドライブ文字をボリュームにマッピングする

技術3課の島村です。
最近気温の落差が激しいですが、元気に体調も崩さず過ごしています。
皆様も体調管理は気をつけましょうね。

さて、今回はAppStream2.0を構築していきます。

その前にAppStream2.0ってどんなサービスなのか知ってもらうために
サービスの特徴を箇条書きにしてみました。

AppStream2.0とは

・完全マネージド型のアプリケーションストリーミングサービス
・アプリケーションの集中管理
・ActiveDirectoryと連携可能
・アプリケーションとデータの保護

より詳細な機能を知りたい方はAWS公式ページをご確認ください。
https://aws.amazon.com/jp/appstream2/

やること

さて、簡単にサービスの特徴を書いたところで、今回の記事の中でやることを書きました。
以下の通りです。

1.Image Builderの作成
2.Imageの作成
3.Fleetの作成
4.Stackの作成
5.ユーザーの作成
6.ストリーミング配信を体験してみる

…項目多いですね。
今回は構築手順を中心に扱っています。
各コンポーネントの説明と設定値の説明については一部割愛しています。

構築する前にVPC、SecurityGroupを事前に作成しておいてください。
それでは早速始めていきます。

1.Image Builderの作成

まずはImage Builderを作成していきます。
AppStream2.0のメニューから[Images]→[Image builder]タブから
[Launch Image Builder]を選択します。

元となるイメージを選択します。
描画性を求められるアプリケーションなど、アプリケーションの要件によって
求められるインスタンスファミリーがあると思います。
イメージ選択についても考慮する必要があります。

今回はあくまで動作を確認するためだけなので
[AppStream-WinServer2012R2-05-28-2019]というイメージを選択します。

Image Builder名と任意のインスタンスタイプを選択して[Next]を選択します。

Image Builderを配置する[VPC]、[サブネット]、[SecurityGroup]を選択します。

設定のレビューです。よければ[Lunch]を選択してImageBuilderを作成します。

作成後、Image Builderに接続できるようになるまで10分~15分程度かかります。
コーヒーでも飲んで気長に待ちましょう。

2.Imageの作成

コーヒーブレイクは楽しめたでしょうか？
さて、ここからはImageを作成していきます。

Image Builderの[Status]が[Running]になったら接続できるようになります。
接続したImage Builderを選択して、[Connect]を押して接続しましょう。

接続するとどのアカウントでログインするか求められます。
各アカウントごとの役割は以下の通りです。

最初にアプリケーションのインストールを行う必要があるので
[Administrator]を選択します。

[Administrator]でログインできたら必要なアプリケーションを
インターネットやインストーラ等を使用してインストールしてください。

今回はインターネットからアプリケーションをインストールせずに、Windowsに
もともと入っているアプリケーション(メモ帳、エクスプローラー、IE)でカタログを作っていきます。

アプリケーションカタログを作成するにはDesktopにある[Image Assistant]を選択して
起動します。

[Image Assistant]を起動するとアプリケーションカタログに追加するアプリケーションを
追加する画面が表示されます。[+ Add App]を選択してアプリケーションを選択します。

今回はWindows OSでおなじみのアプリケーションをカタログに追加しました。
追加したら[Next]を押して次に進みます。

ユーザー共通のアプリケーションの設定やWindowsの設定がある場合は、
[Switch User]を選択して[Template User]に切り替える必要があります。
今回は特にそういった設定は行わないためスキップします。

ちなみに[Template User]で設定が完了後、再度[Administrator]に切り替え
[Save Setting]を押すことで始めて設定が保存されますのでご注意ください。
設定が終わったら、[Next]を選択します。

ここでは[TEST User]を使用してアプリケーションカタログで選択しているアプリケーションが
正常に起動するか確認します。[Switch User]を選択して[Test User]に切り替えることができます。

アプリケーションの動作確認とWindowsの設定が確認できたら
Userを[Administrator]に切り替えます。

右上の[AdminCommands]から[Switch User]を選択します。
Administratorに切り替えるとImageAssistantが[OPTIMIZE]に進みます。

ここではアプリケーションの起動について依存関係がないかを確認し、
最適化を行うステップです。[Launch]を選択してアプリケーションを起動します。
アプリケーションの起動に問題なければ、[Next]を選択します。

ここではイメージ名とイメージの説明を入力します。適当なイメージ名を入力しましょう。

最後にイメージ名と説明を確認して[Disconnect and Create Image]を押します。
押した後、イメージビルダーとの接続が切れますが問題ありませんので安心してください。

これでイメージの作成は完了です。
イメージの作成までに20〜25分程度かかります。
２回目のコーヒーブレイクを楽しみましょう。

3.Fleetの作成

2回目のコーヒーブレイクは楽しめたでしょうか？
楽しめた方はなかなかのカフェイン中毒ですね。

さて、次はFleetを作成していきます。この調子でどんどん行きましょう!
左ペインから[Fleet]を選択し、[Create Fleet]から作成していきます。

Fleet名、Fleetの説明を入力します。

Fleetで使用するイメージを選択します。今回は先ほど作成したイメージを選択しましょう。

次にFleetの設定を行なっていきます。
以下の項目について設定が可能です。
・インスタンスタイプ
・フリートタイプ
・セッションの設定
・フリートスケーリング

今回の構築では設定値を以下の通りで設定しています。

設定したら[Next]を押します。

ネットワーク周りの設定を行います。
配置するVPC、サブネット、セキュリティグループを選択したら[Next]を押して次へいきます。

確認して問題なければ[Create]を選択します。

Fleetが完成しました。
Fleetは起動までに10分程度かかります。この間にStackの作成を行いましょう。

4.Stackの作成

さぁ、ここまできたら残りはあと少しです。頑張っていきましょう！！

左ペインから[Stack]を選択して、[Create Stack]から作成を行います。

Stackの基本設定を行なっていきます。
ここではStack名の入力と、関連させるFleetを選択します。
選択し終えたら[Next]を押して次に進みます。

ストレージ設定を行います。
[Home Folder]、[GoogleDrive for G suite]、[OneDrive for Bisiness]が選択できます。
ここでは[HomeFolder]のみにチェックを入れます。

ユーザーのクリップボード有効化、アプリケーション設定の永続化、ローカルデバイスとの
ファイル転送について設定することができます。

[Enable Application Persistence]にチェックがついてなければつけてください。
その他の設定についてはデフォルトのままでOKです。

内容を確認して問題なければ作成します。

これでStackの作成は完了です。

5.ユーザーの作成

ユーザーの作成をしていきます。
左ペインから[User Pool]→[Create User]を作成します。

選択すると招待するユーザー名とメールアドレスを入力するポップアップが出てきます。
招待したいユーザー名とメールアドレスを入力しますが、今回は自分自身のメールアドレスを
入力します。

入力が完了するとメールアドレスが送信されます。
送付されたメールを確認する前にユーザーと作成したStackを紐付ける必要があります。
作成したユーザーを選択した状態で[Action]ペインを開き、[Assign Stack]押します。
選択後にポップアップが表示されるので、ユーザーに関連付けたいStackを選択します。

これでユーザーの準備が整いました！！！

6.アプリケーション配信環境を体験する

前の章で送られてきたメールを確認します。
ログイン画面へのリンクがあるのでアクセスします。

アクセスするとメールアドレスとパスワードを求められるので入力していきます。
※送付されたメールに初期パスワードが書いてあります。

入力すると初期パスワードを変更するよう求められるので、任意のパスワードに変えていきます。
パスワード変更が終わったら再びメールアドレスとパスワード情報を入力します。
ログインできるとアプリケーションカタログが表示されます。

どのアプリケーションでもいいので選択するとストリーミング接続が開始されます。

そしてついに….

接続できました！！！！！ここまで長かったですね！！！！

最後に

長い記事となってしまいましたがこれでAppStream2.0の環境が構築できたと思います。
比較的簡単にアプリケーションの配信と集中管理できるのは魅力的ですね。

次回はAppStream2.0とActiveDirectoryを連携させる手順を記事にしていきたいと思います。

こんにちは。
夏らしい強い日差しを求めている技術3課の島村です。

今年の梅雨は長いですね。
暑い中で冷えたアイスコーヒーを美味しく飲みたいものです。

さて、今回はFSxでABE(アクセスベースのディレクトリ列挙)の設定を行なっていきます。
本題に入る前にFSxの紹介とABE(アクセスベースのディレクトリ列挙)の説明を簡単します。

Amazon FSx for Windows

名前の通り、完全マネージドサービスで提供されているファイルシステムサービスです。
WindowsServerに構築されているため従来のWindowsServerで使用されている
WindowsACLとも互換性があります。

最近既存ADとも連携ができるようになり、使い勝手がさらに向上しました。
より機能の詳細を知りたい方は公式ページを参照してみてください。
https://aws.amazon.com/jp/fsx/windows/

ABE(アクセスベースのディレクトリ列挙)

基本的にWindowsOSではアクセス権のないフォルダでも表示されてしまいますが
ABEの設定を行うことにより、アクセス権のないフォルダは表示されなくなる機能です。

環境

今回、検証を行う環境を構成図にしてみました。
構成図の通り、ADサーバにFSxのファイルシステムをネットワークドライブとしてマウントしてABEの挙動を確認していきます。

前提

ADサーバとFSxは構築済みかつADサーバでFSxがマウントされている状態から進めていきます。
ADサーバとFSxの準備ができていない方は弊社鎌田がFSx構築のブログを書いておりますので
参考の上環境を作ってみてください。

Amazon FSx for Windowsが既存のActive Directoryのドメインを直接利用できるようになりました！

検証に使用するユーザーは以下の権限で作成しています。

1.ABEの有効化

早速設定をやっていきます。
ABEはデフォルトでオフとなっているのでABEの有効化をしていきます。

まずはADサーバーにログインし、Powershellを管理者権限で実行します。

ファイル共有モジュールのダウンロードを行います

Install-Module -Name FileShareUtils

設定前の確認

Get-NetShare -server fs-xxxxxxxxxx."DomainName" -name "ShareFolderName"

設定前の確認をするとABEの設定がDisabledになっていることが確認できると思います。

PS C:\Users\test> Get-NetShare -server fs-xxxxxxxxxx."DomainName" -name "ShareFolderName"


Server              : amznfsxj2mdb1kk.serverworks.local
Name                : share
Path                : D:\share
Description         :
ABE                 : Disabled
CachingMode         : Manual
ShareACLText        : Everyone|FullControl
CurrentUses         : 1
ConcurrentUserLimit : -1
BranchCache         : Disabled
Flags               : 0
Type                : Disk Drive
ShareSDDL           : D:(A;;FA;;;WD)
ShareACL            : System.Security.AccessControl.DirectorySecurity

ABEの有効化

以下のコマンドを実行してABEの有効化を行います。

Set-NetShare -server fs-xxxxxxxxxx."DomainName" -name "ShareFolderName" -abe enabled

設定後の確認

ABEが有効になっているかを確認します。

Get-NetShare -server fs-xxxxxxxxxx."DomainName" -name ShareFolderName

ABEの設定がEnabledになりました！

PS C:\Users\test> Get-NetShare -server fs-xxxxxxxxxx."DomainName" -name "ShareFolderName"


Server              : amznfsxj2mdb1kk.serverworks.local
Name                : share
Path                : D:\share
Description         :
ABE                 : Enabled
CachingMode         : Manual
ShareACLText        : Everyone|FullControl
CurrentUses         : 1
ConcurrentUserLimit : -1
BranchCache         : Disabled
Flags               : 2048
Type                : Disk Drive
ShareSDDL           : D:(A;;FA;;;WD)
ShareACL            : System.Security.AccessControl.DirectorySecurity

これで有効化が終わりました。
実際に動きを確認していきましょう。

2.ABE有効化の反映確認

フォルダを2つ作成します。
※名前は任意です。

権限は次の通りとなっています。

以下の通り権限を設定します。
親フォルダの”Share”から継承を受けている状態となるので継承を無効化にして設定を行なってください。
ただし、SYSTEMグループだけは削除しないでください。ファイルシステムやフォルダが利用できなくなる可能性があります。

さて、これで準備ができたので各ユーザーでログインして試してみます。

FSxUserでログインした結果

FSxAdminでログインした結果

うまくいきました！！
ABEの制御できていてアクセス権のあるフォルダのみ表示されていると思います！

最後に

フルマネージドサービスのFSxでもABEによる制御ができました。
オンプレミスのファイルサーバの移行を考えている方はFSxを選択肢に入れてみてはいかがでしょうか。

技術一課の杉村です。CloudWatch Logs を使っていますか？知っている人には「いまさらなかよー」な情報ですが、小技のご紹介です。

メトリクスフィルタリング機能をうまく使うことで、ログ監視、APIコールの監視、などなどを行うことができます。

メトリクスフィルタリング？？

CloudWatch Logs のロググループに出力された特定の文字列をフィルタでひっかけて、その出現数を CloudWatch の一種のカスタムメトリクスとしてカウントすることができます。
一定の出現数を超えたら、SNS 通知を飛ばすことができます。

例1. アプリケーションのログ監視

最もシンプルな使い方です。
Lambda 関数のログは通常、CloudWatch Logs のロググループに出力すると思います。

そのロググループに例えば “ERROR” という文字列でメトリクスフィルタを作成します。
そのような文字列が出現したら、SNS で通知を投げるように設定が可能です。

もちろん「〇分間の合計値が×を超えたら発動」のような設定方法も可能です。

EC2 にあるアプリケーションから CloudWatch エージェントを使って CloudWatch Logs にログを送信し、それに対してメトリクスフィルタを設定することも当然できますので、Zabbixなどを使わなくても独自のアプリケーションのログ監視が可能です。

例2. AWSのAPIコールを監視する

AWS 利用者の IAM 権限は厳重に管理すべきものですが、意図せぬ API コールが行われていないか監視したい、またオペミスなどを監視するために特定のオペレーションが行われたら通知が欲しい、などのニーズがあるかもしれません。
AWS の API コールは CloudTrail で記録することが可能ですが CloudWatch Logs と組み合わせることで特定の API コールを監視することが可能です。

CloudTrail のログは通常、S3バケットに出力されますが、同時に CloudWatch Logs にも出力することが可能です。
CloudWatch Logs にイベントを送信する

そして出力先に指定したロググループに対して、メトリクスフィルタを指定すればよいのです。

なおメトリクスフィルタでは、構文を使って記述することでけっこう複雑なフィルタリングが可能です。

例 特定のIAM Role以外から発生したとあるAPIコールをフィルタ

{ $.userIdentity.arn != “arn:aws:sts::＜YourAWSAccountID＞:assumed-role/＜IAMRoleName＞/*” && $.eventName = “＜APIEventName＞” }

CloudTrail のレコードの属性名でフィルタすることで「特定のIAM User以外から○○をやられたくない」「特定の時間以外で××が発生するのはおかしいから、監視したい」という要望を実現できますね。

下記のような画面でフィルタを定義するのですが、しっかりとお目当てのレコードが検出されるか、テストすることもできます。

ちなみに、検知すると以下のようなメールが発信されます。

You are receiving this email because your Amazon CloudWatch Alarm “＜CloudWatch Alarm名＞” in the Asia Pacific (Tokyo) region has entered the ALARM state, because “Threshold Crossed: 1 datapoint [1.0 (02/04/19 07:30:00)] was greater than or equal to the threshold (1.0).” at “Tuesday 02 April, 2019 07:35:22 UTC”.

View this alarm in the AWS Management Console:
https://console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1#s=Alarms&alarm=＜CloudWatch Alarm名＞

Alarm Details:
– Name: ＜CloudWatch Alarm名＞
– Description: ＜Description＞
– State Change: INSUFFICIENT_DATA -> ALARM
– Reason for State Change: Threshold Crossed: 1 datapoint [1.0 (02/04/19 07:30:00)] was greater than or equal to the threshold (1.0).
– Timestamp: Tuesday 02 April, 2019 07:35:22 UTC
– AWS Account: ＜AWSアカウントID＞

Threshold:
– The alarm is in the ALARM state when the metric is GreaterThanOrEqualToThreshold 1.0 for 300 seconds.

Monitored Metric:
– MetricNamespace: LogMetrics
– MetricName: ＜CloudWatchメトリクス名＞
– Dimensions:
– Period: 300 seconds
– Statistic: Sum
– Unit: not specified

State Change Actions:
– OK:
– ALARM: [arn:aws:sns:ap-northeast-1:＜AWSアカウントID＞:＜SNSトピック名＞]
– INSUFFICIENT_DATA:

以上です。

こんにちは。技術1課の木次です。

弊社では今年も テレワーク・デイズ に参加しており、今週1週間はリモートワーク勤務が推奨されています。
(2019年もテレワーク・デイズに参加いたします)

自宅でモクモクと作業するのもいいのですが、ずっとだと寂しいですよね。気分転換が必要です。
なので、社内勉強会としてリモートでモブプロにチャレンジしてみようかと思います。

モブプロって何？

モブプロとは「Mob programming」の略で、チーム全体が同じことを同時に同じPCで作業する開発アプローチで、PCを操作する人(ドライバー)を交代しながらワイワイと進めていきます。

通常は同じ場所、1つのモニタでやるものですが AWS Cloud9 を使って、リモートでチャレンジしてみます。なお、音声は Google Hangouts Meet を利用します。

AWS Cloud9 とは

AWS Cloud9 は、ブラウザのみでどのマシンからでもコードを記述、実行、デバッグできる、クラウドベースの統合開発環境 (IDE) です。
EC2 環境であれば、素早く新しいプロジェクトを開始でき、リアルタイムに共同コーディングやチャットが可能です。
ペアプロだけでなく、モブプロにも最適です。

共同コーディングをする場合、Cloud9 では2パターンの共有方法があります。

• 同じ AWS アカウント内の IAM ユーザーと共有する場合
• 異なる AWS アカウントの IAM ユーザーと共有する場合

同じAWS アカウント内の IAM ユーザー同士の場合は、比較的簡単に出来ますが、異なる AWS アカウントの IAM ユーザーの場合は少し手順が複雑です。今回はこのケースのお話になります。

異なる AWS アカウント同士の共有方法

異なる AWS アカウント同士で共有する場合、IAM ロールによるクロスアカウントアクセスにて主催者側の Cloud9 環境に接続します。
アカウントごとの Cloud9 環境同士が接続するわけではないので注意してください。 

おおまかな流れは以下になります。

• 事前準備
  • (1)【参加者】AWS アカウントとユーザー名を主催者に連絡
  • (2)【主催者】ロール作成
  • (3)【参加者】ロールを引き受けるポリシー設定
• Cloud9 共有
  • (4)【主催者】Cloud9 共有環境から参加者を招待
  • (5)【参加者】スイッチロール
  • (6)【参加者】Cloud9 共有環境を開く

細かく見ていきましょう。

事前準備

Cloud9 共有をする前に事前準備が必要です。以降、下記の値を例として説明していきます。

1.【参加者】AWSアカウントとユーザー名を主催者に連絡

参加者は、自分の AWS アカウントと管理コンソールで利用している IAM ユーザー名を主催者に連絡します。
AWS アカウントは IAM ロールの信頼ポリシーの関連付けに、IAM ユーザー名は Cloud9 共有環境からの招待時に利用します。

2.【主催者】ロール作成

参加者全員の AWS アカウントと IAM ユーザー名を確認できたら、AWS Cloud9 共有用のロールを作成します。
ロールにはAWSCloud9EnvironmentMemberと参加者の信頼ポリシーを関連付けします。

今回は IAM ロールを簡単に登録できるように CloudFormation テンプレートを用意してみました。

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  RoleName:
    Type: "String"
    Default: "AWSCloud9EnvironmentMemberCrossAccountRole"
  JoinAccounts:
    Type: "CommaDelimitedList"
    Description: "ex) arn:aws:iam::999999999999:root,arn:aws:iam::888888888888:root"
Resources:
  MyRole:
    Type: "AWS::IAM::Role"
    Description: "role for shared environments in AWS Cloud9"
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          -
            Effect: "Allow"
            Principal: 
              AWS: !Ref JoinAccounts
            Action: "sts:AssumeRole"
      Path: "/"
      ManagedPolicyArns:
        - "arn:aws:iam::aws:policy/AWSCloud9EnvironmentMember"
      RoleName: !Ref RoleName
Outputs:
  RoleArn:
    Description: "closs-account role's ARN"
    Value: !GetAtt MyRole.Arn

テンプレートファイルをアップロードします。スタックの詳細の指定画面で、2つのパラメータを設定します。

• JoinAccounts
  • 参加者のアカウントを入力
  • arn:aws:iam::{AWSアカウント}:root の形式で、複数ある場合はカンマ区切り
• RoleName
  • 作成するロール名を入力
  • デフォルトは AWSCloud9EnvironmentMemberCrossAccountRole

スタック作成が完了すると IAM ロールが作成されます。
出力タブに RoleArn の値が表示されるので、コピーして参加者に連絡します。

以下は作成された IAM ロールに紐づく信頼関係のポリシードキュメントです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::888888888888:root",
          "arn:aws:iam::999999999999:root"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

3.【参加者】ロールを引き受けるポリシー設定

主催者から AWS Cloud9 共有用のロール Arn を受け取ったら、ロールを引き受ける(AssumeRole)ポリシーを作成してアカウントに紐づけます。
具体的には、専用のグループを作成してポリシードキュメントを定義し、そのグループに自分のIAMユーザーを追加することで紐づけします。

IAM グループを簡単に登録できるように CloudFormation テンプレートを用意しました。

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  CrossAccountRoleArn:
    Type: "String"
    Description: "ex) arn:aws:iam::111111111111:role/AWSCloud9EnvironmentMemberCrossAccountRole"
  GroupName:
    Type: "String"
    Default: "AWSCloud9CrossAccountGroup"
  JoinUsers:
    Type: "CommaDelimitedList"
    Description: "ex) fukaya-negi,shimonita-negi"
Conditions:
  IsAddition: !Not [!Equals [!Join ["", !Ref JoinUsers], ""]]
Resources:
  MyGroup:
    Type: "AWS::IAM::Group"
    Description: "group for shared environments in AWS Cloud9"
    Properties:
      GroupName: !Ref GroupName
      Path: "/"
      Policies:
        -
          PolicyName: "AWSCloud9CrossAccountGroupPolicy"
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              Effect: "Allow"
              Action: "sts:AssumeRole"
              Resource: !Ref CrossAccountRoleArn
  MyUserToGroup:
    Type: "AWS::IAM::UserToGroupAddition"
    DependsOn: "MyGroup"
    Condition: IsAddition
    Properties:
      GroupName: !Ref GroupName
      Users: !Ref JoinUsers
Outputs:
  GroupArn:
    Description: "for closs-account group's ARN"
    Value: !GetAtt MyGroup.Arn

テンプレートファイルをアップロードします。スタックの詳細の指定画面で、3つのパラメータを設定します。

• CrossAccountRoleArn
  • 主催者が作成した IAM ロールの ARN を入力
• GroupName
  • 作成するグループ名を入力
  • デフォルトは AWSCloud9CrossAccountGroup
• JoinUsers
  • グループに追加する IAM ユーザー名 を入力
  • 複数ある場合はカンマ区切り

スタック作成が完了すると、IAM グループが作成されます。
以下は作成された IAM グループのインラインポリシーです。

{
  "Version": "2012-10-17",
  "Statement": {
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::111111111111:role/AWSCloud9EnvironmentMemberCrossAccountRole",
    "Effect": "Allow"
  }
}

AWS Cloud9 共有

事前準備が完了したら、AWS Cloud9 で共有できます。

4.【主催者】Cloud9 共有環境から参加者を招待

東京リージョンで AWS Cloud9 EC2 環境を作成します。
Cloud9 コンソールを開き、[Your environments] – [Create environment] ボタンを押下します。

AWS Cloud9 環境作成

• 環境名
  • Environment name and description
    • [Name] に環境名を入力します。
  • [Next step] ボタンを押下
• 構成設定
  • Environment settings
    • Environment type
      • Create a new instance for environment (EC2)
    • Instance type
      • t2.small (2 GiB RAM + 1 vCPU)
      • インスタンスタイプは人数に合わせて変更してください。
    • Platform
      • Amazon Linux
  • [Next step] ボタンを押下
• 確認
  • [Create environment] ボタンを押下

参加者を招待

AWS Cloud9 IDE が表示されたら参加者を招待します。
画面右上の [Share] ボタンを押下して [Share this environment] ダイアログを表示します。

[Invite Members] 欄のテキストフィールドに IAM ユーザーを入力して [Invite] ボタンを押下します。

• IAM ユーザー
  • arn:aws:sts::{主催者AWSアカウント}:assumed-role/{ロール名}/{参加者IAMユーザー名}
  • (例) arn:aws:sts::111111111111:assumed-role/AWSCloud9EnvironmentMemberCrossAccountRole/fukaya
• 操作権限
  • RW: 読み取り/書き込み権限

※信頼できる参加者のみを共有環境に招待してください。

参加者は信頼する人のみに書き込み権限を付与した場合、セキュリティ警告ダイアログが表示されます。その場合は [OK] ボタンを押下してください。

参加者全員を招待したら [Done] ボタンを押下します。これで主催者側の準備は完了です。

5.【参加者】Cloud9 共有環境を開く

コンソールからロールAWSCloud9EnvironmentMemberCrossAccountRoleへスイッチします。

• 右上のナビゲーションバーのユーザー名を選択
  • 通常はusername@accountId_or_aliasのように表示
• [スイッチロール] を選択
• ロールの切り替え
  • アカウント
    • 111111111111
  • ロール
    • AWSCloud9EnvironmentMemberCrossAccountRole
  • 表示名
    • Cloud9SharedEnv
  • 色
    • 好きな色を選択
• [ロールの切り替え] ボタンを押下

スイッチロールをした後は Cloud9 へ接続します。

サービスから Cloud9 コンソールを選択し、[ナビゲーションペイン] – [Shared with you] を選択します。
主催者の共有環境が表示されていたら成功です。

[Open IDE] ボタンを押下して Cloud9 環境を開きます。うまく共有できたでしょうか？

クロスアカウントアクセスの場合、チャットにロール名が表示されて何のネギだかサッパリわかりません。この辺は改善の余地ありですかねぇ。

モブ最高！！

参考

• AWS Cloud9 の共有環境を使用する
  • https://docs.aws.amazon.com/ja_jp/cloud9/latest/user-guide/share-environment.html

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

はじめに

今回のメインは東京リージョンにやっとこさt3aのインスタンスタイプが対応しましたのでそのための追記となります。

Amazon EC2 AMD Instances are Now Available in additional regions
https://aws.amazon.com/jp/about-aws/whats-new/2019/07/amazon-ec2-amd-instances-available-in-additional-regions/

これを受け、実際に東京リージョンのどのAZが対応済なのか確認しました。

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

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

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

前回からの変更点

全ての差分を確認してみましたが、t3aが東京リージョンに対応した以外の変更はありませんでした。ただし、1c (apne1-az1)で構築ができません。t3aをご利用される場合は1c以外のアベイラビリティーゾーンをご利用ください。

まとめ

今回と前回の更新を踏まえ、各AZの特徴を再度まとめてみましょう。

• 旧世代のインスタンスタイプは、東京リージョンの1dでは構築できない
• m5dとc5d、z1d、x1eについては東京リージョンの1dでは構築できない
• t3aとm5a、r5a、c5n、i3enについては東京リージョンの1cでは構築できない
• 1aは現状、東京リージョンで構築可能な全てのインスタンスタイプが構築可能である

ちょっとした更新でしたが、参考になりましたら幸いです。
それではまたお会いしましょう。

Amazon SageMakerでお魚を判別したいときってありますよね。

というわけで今回はSageMakerでお魚を判別してみました。

準備

撮影

魚の写真を撮りまくります。

水槽側面や水草にコケがついてますが、サイアミーズが食べないせいであって、僕のせいではないです。

全部で250枚撮りました。もっとある方がいいですが疲れたのでこの辺にしときました。

撮った写真はS3バケットへアップロードします。

ラベリング

Ground Truthをつかってラベリングします。

パブリックでラベリングジョブを作成してもいいのですが、お魚の種名が分からず適当にラベリングされても困るので、プライベートでジョブを作成し自分でラベリングすることにしました。

250枚ですが、丸1日くらいかかりました。しんどかったです。

ラベリングジョブが終了すると、指定のS3の場所に結果ファイルが出力されます。

このファイルをもとにトレーニングジョブを実行します。

困った点

ラベリングジョブはラベリングしたいファイルのあるS3パスを指定すればよいと思ってたのですが、それは間違いでマニフェストファイルにファイルのS3キーを記載し、ラベリングジョブ作成時にそのマニフェストファイルのS3キーを指定してやる必要があります。

要は、ラベリングしたいファイルのS3キーを記載したファイルをS3に置いておく必要があるということです。

マニフェストファイルの例

{"source-ref": "s3://bucket/key/sample01.JPG"}
{"source-ref": "s3://bucket/key/sample02.JPG"}
{"source-ref": "s3://bucket/key/sample03.JPG"}
...

トレーニング

コンソールからトレーニングジョブを作成し実行します。後に記載しますが、SageMakerのノートブックなどからコードで実行するのが断然楽チンです。

アルゴリズム選択

今回使用するアルゴリズムは、組み込みアルゴリズムのObject Detection Algorithmです。

入力モードは「Pipe」とします。

リソース設定

Object Detection AlgorithmはGPUしかサポートしてません。

一番小さいml.p2.xlargeで実行しましたが、メモリが足らずエラーとなるのでp2.8xlargeで実行しました。

ハイパーパラメータ

なんだかんだあってepochsをデフォルト(30)→24、mini_batch_sizeをデフォルト(32)→8に変更しました。

入力データ設定

Object Detection Algorithmで必要なチャンネルはtrainチャンネルとvalidationチャンネルです。チャンネル名が違うだけでもジョブがエラーとなるので気を付けてください。

今回は学習にラベリングジョブでラベリングしたデータを使用するため、どちらのチャンネルも以下の設定とします。

• 入力モード – Pipe
• レコードラッパー – RecordIO
• S3 データタイプ – AugmentedManifestGile
• S3 の場所 – ラベリングジョブ結果ファイルのS3キー

AugmentedManifestFile 属性名はラベリングジョブ結果ファイル(マニフェストファイル)内のキーを指定します。詳しくはドキュメントの『Train with Augmented Manifest Image Format』を確認してください。

出力データ設定

トレーニングしたモデルアーティファクトの保存場所をしていします。いい感じの場所にしましょう。

困ったこと

入力データ設定の誤りで何度かジョブを作成しなおしました。それだけでなくハイパーパラメータが合ってない？とかでジョブがエラーを起こしてしまい、合計で15回ほどジョブを作成しなおしました。

さすがにコンソールポチポチで15回も再作成するのはしんどかったのでこんどからはノートブックから実行しようと思います。

ちなみにトレーニングのログはCloudWatch Logsから確認できるので、ジョブがエラーを起こす場合はそちらを確認してください。

エンドポイント作成

トレーニングが成功してしまえば、あとは難しいことはありません。

以下の順で推論エンドポイントを作成します。

1. モデル作成
2. エンドポイント設定作成
3. エンドポイント作成

Object Detection Algorithmは学習ではP2/P3系インスタンスを指定する必要がありましたが、エンドポイントはその制限はないようです。

判別してみよう！

いい感じに確認したかったので、さすがにノートブックを使いました。

といってもObject Detection Algorithmのサンプル「object_detection_birds.ipynb」の推論部分の画像とエンドポイントを変更しただけです。

こんな感じ

ほう…

まあ学習データが少ないので精度は期待してませんでしたが、なんとなく判別で来てる感じです。

色が派手なベタの判別がより精度出ているようにも見えます。コリドラスやサイアミーズは地味だから精度出にくい？

学習データの魚の向きも精度にかかわるので、種類ごとに横向き前向き200枚くらいデータ揃えればさすがにそこそこの精度は出るでしょう。

まあ、それだけの量を一人でラベリングしたくないですが…

まとめ

SageMakerをつかえば、データ集めるのさえ頑張ればあとはどうにでもなりますね。