プログラマでありたい

おっさんになっても、プログラマでありつづけたい

Security-JAWSで、AWS認定セキュリティ専門知識の試験について話してきました

 こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木(@dkfj)です。

 8月の登壇チャレンジの第三弾のSecurity-JAWSのレポートです。AWS認定セキュリティ専門知識の対策本の発売記念として、試験についての話をさせて頂きました。

s-jaws.doorkeeper.jp

発表内容

 20分枠で、前半(佐々木)と後半(上野さん)とで、別々に発表させて頂きました。

speakerdeck.com

speakerdeck.com

AWS認定セキュリティ専門知識の試験対策について

 試験の個別の問題についてはNDAで話すことができません。なので、どういった観点で学べば良いのかという話をさせて頂きました。受験した事が多いソリューションアーキテクトとの違いは、次の絵のとおりです。

f:id:dkfj:20200903190106p:plain
ソリューションアーキテクトとセキュリティ専門知識の違い

 ソリューションアーキテクトは、どのように作るのかを問われます。セキュリティ専門知識では、構築する/したシステムの安全をより確保するにはどうしたら良いのかという事を問われます。もちろん、ソリューションアーキテクトもWell-Architectedの柱の一つであるセキュリティについて問われることが多々あります。しかし、セキュリティ専門知識の方は、ずっとそのことについて問われるという形になります。

 具体的には、何を勉强したら良いのかという点については、公開されている試験の領域と配点を参考にするとよいです。

f:id:dkfj:20200903190421p:plain
セキュリティ専門知識の対象分野と配点割合

 20%以上の領域は4つありますが、私としては赤枠で囲っている3つの分野を重点的に勉强するのが良いと思います。なぜなら20%の配点がある『IDおよびアクセス管理』はIAMが重点的に問われて、かつIAMは他の分野にも密接に関わっています。IAMの技術同人誌を出しているからというバイアスはあるものの、AWSのセキュリティの根幹の一つはIAMです。ここをまず徹底的にやりましょう。
 あとの重点分野としては、KMSとS3やEBSなどのデータ保護です。KMSについては、普段から知らずに使っているという事が多いと思います。セキュリティ専門知識では、明示的にどういった場合にどのように使うのかということを理解しておく必要があります。なかなか奥深い分野なのですが、試験勉強を通して鍵管理についての知識を深めていくと、世の中のセキュリティ製品についての特徴がより解りやすくなります。セキュリティには、鍵の扱いは必須です。
 最後は、データの保護に関してS3やEBSの暗号化や経路の安全の確保の仕方です。S3はサービスとして(たぶん唯一)サーバーサイド暗号化とクライアントサイド暗号化に対応しているサービスです。何故、その両方に対応しているのか、問題となるユースケースを突き詰めていくと理解できるようになります。このあたりと、経路の暗号化のパターンを把握していると強いです。

感想

 我々の発表は試験という観点でしたが、他の登壇者の方々はThe専門家という感じで専門性が高い発表が続きとても勉强になりました。オンラインで参加できるようになっているので、気軽に参加してみてはいかがでしょうか?最後に、参加者から共感の高かった上野さんの名言「試験に不合格になっても、落ち込まない」に対して私からの補足をもってお終いとさせて頂きます。

いや、半端ないって

booth.pm


booth.pm

滋賀県(大津市)のデパートは何故潰れるのか?

 こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木(@dkfj)です。

 先日、滋賀県大津市唯一のデパートである西武百貨店が閉店となりました。元滋賀県民としては、寂しさがあるのでちょっと語ってみます。ちなみに大津市に住んでいましたが、大津市と宇治市の境の山奥に住んでいたので、子供時代は西武がある辺りは大都会だと思っていました。

www.kyoto-np.co.jp

 西武百貨店は44年の歴史がありましたが、近隣の大型商業施設はことごとく短命で終わっています。

浜大津OPA(オーパ) 1998年オープン、2004年閉店
大津PARCO 1996年オープン、2016年閉店

時代の流れもありますが、滋賀県の特殊要因も多分にあるので、ちょっと解説してみます。

大津市の大型商業施設が厳しい理由

琵琶湖がある

 滋賀県の宿命ですが、琵琶湖があるというだけで商業地としては致命的なハンデを持っています。どういうことかというと、普通店舗は徒歩や車などの移動手段の違いはあれど、半径○○キロ圏内の人を前提として商圏を持ちます。琵琶湖があると何故問題なのか?商圏の半分が湖の底になってしまうからです。言葉で説明してもイメージわきにくいので、Google Mapsさんのスクショで説明させてもらいます。西武百貨店を中心に円を適当に書きましたが、半分は琵琶湖になりますよね。

f:id:dkfj:20200902021912p:plain

 琵琶湖には当然人は住んでいなくてブラックバスしかいないので、お客さんにはなりえません。もう少し下流にいった魚と遊べるパラダイスの南郷水産センターの鯉であればもう少しで地上に出てこれそうですが、それにしたってお金を持っていません。

www.youtube.com

 ということで、琵琶湖のせいで商圏が半分というハンデがあります。

琵琶湖じゃないところは山がある

 じゃぁ、もう少し琵琶湖から離れたところに立地すればいいじゃないかと思うかもしれません。でも、それも難しいのです。滋賀県と聞くと琵琶湖だけあるようなイメージですが、それは正確ではありません。琵琶湖じゃないところは山しかないのです。(ちょっと言い過ぎ)
先程の地図を航空写真で見てみましょう

f:id:dkfj:20200902022718p:plain

はい。琵琶湖と山に挟まれていますね。もう少し琵琶湖より離れられそうにも見えなくはないですが、JRより西側(写真左)の方は斜面を切り開いたところです。


 ちなみに西の山は、織田信長の比叡山延暦寺の焼き討ちで有名な比叡山を含む山脈です。お猿さんが多くて、たまに麓の方まで遊びに来てくれますが、やっぱりお金は持っていないですね。

京都駅に近い

 あともう一つ致命的な問題があります。それは、実は電車だと京都駅にめちゃくちゃ近いということです。他県の人から見たら、或いは京都市の人から見ても大津と京都は離れているように印象を持っていると思います。でも、JRに乗ると大津駅〜京都駅は10分でいけます。早いやつだと9分。ということで、がっつり買い物しようと思うと、みんな京都に行ってしまうのですよね。

 以上、3点が大津市の商業施設が持つハンデでした。まぁもともとそれ前提の店舗計画なので、モノが店舗で売れなくなったとかの時代の流れも大きいとは思います。ちなみにこの構造は明るい廃墟として名を馳せたピエリ守山と同じ構造ですね。あちらは、琵琶湖大橋のそばということで、渋滞の問題もあったりします

そして草津の時代になったが

 ついでに蛇足。滋賀県は最近では大津より少し北東の草津の方が近鉄百貨店を中心に発展しています。草津と聞くと温泉を思い浮かべると思いますが、まったく関係ない草津です。草津駅周辺は、もともと琵琶湖から離れた田園地帯でした。それがベットタウンとして発展し人口が増え、かつ琵琶湖の呪縛からも京都の重力からも離れているお陰で上手く離陸できた模様です。

f:id:dkfj:20200902024830p:plain

 一方で起爆剤の一つであった立命館大学のびわこ・くさつキャンパスが離れていくこともあり、どうなるのかなぁと心配なところではあります。

まとめ

琵琶湖あっての滋賀県ですが、琵琶湖のほとりの商売は大変です

JAWS-UG朝会で、CloudFormation StackSets × AWS Organizationsの話をしました

 こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木(@dkfj)です。
 8月25日に開催されたJAWS-UG朝会#12で、CloudFormation StackSets × AWS Organizationsの話をしてきました。JAWS-UG朝会は、朝の7:30から勉強会をしようという会で、夜の勉強会に参加できない人や、テレワーク開始前の時間を有効活用したい人に好評を博しています。そして、ラジオ体操から始まる健康的な支部です。

発表内容

 発表した内容は、タイトルの通りにCloudFormation StackSets × AWS Organizationsです。CloudFormation StackSetsは、他のAWSアカウントやリージョンに対してCloudFormationのスタックを設定できる素晴らしい機能です。そして、Organizationsと連携することによりAWSアカウントをOrganizationsで作ったタイミングや、特定の組織単位(OU)に参加したタイミングで、自動的にCloudFormationを発動させることができる神機能です。つまりこれを使うと、AWSアカウント作成時の初期設定をCloudFormationで自動的に実行できるようになります。凄いですよ

speakerdeck.com

CloudFormation StackSets × AWS Organizations

 今、AWSのアカウントを作ったらどういうことをしているかというのをまとめているのが、次の図です。

f:id:dkfj:20200831081227p:plain

 CloudTrailやConfigの設定は元より、GuardDutyやSecurityHubとの連携、CloudWatchやSNSでアラート通知などを行います。また、それを監査用アカウントに集約するように、SecurityHubの設定や監査ログとしての保管などもすることがあります。これらは、原則として利用しているアカウントの一つ一つに設定していく必要があります。新規の設定や設定変更などもあるので、これを手でやっていくのは正直大変です。

 AWS Organizationsを使って、組織単位(OU)にCloudFormation StackSetsを設定しておくと、一度作っておくとこの辺りを自動でやってくれます。使わない手は、ないですよね。

f:id:dkfj:20200831074013p:plain

請求/支払い代行とAWS Organizations

 発表のところで少し触れましたが、AWSの請求/支払い代行を利用しているとAWS Organizationsの機能が使えない事が多々あります。支払い代行業者が使う一括請求の機能が、Organizationsと統合されてしまっているために、機能として分割して出しにくいのに起因しているのかと思います。今ではAWS SSOなどOrganizationsを前提とするサービスが多々あるので、この辺りAWS側にも仕組みの改善をして欲しいところですね。
 AWS Organizationsに対応している請求/支払い代行サービスを提供している会社もありますので、まずは問い合わせしてみるのもいいかもしれませんね。(ステマ)

www.nri-net.com

まとめ

 初参加のJAWS-UG朝会ですが、非常に有意義でした。朝の時間を有効活用できるのはいいですね。当日は朝早くから活動していたので、早めに仕事を切り上げようと思ってたのですが、すっかり忘れていて夜になればヘロヘロになっていました。朝型の生活リズムを作るのに、JAWS-UG朝会をかるようするのもいいと思います。次回は、9月28日です。

booth.pm

booth.pm

リザーブドインスタンスに変わる割引プランである「Savings Plans」を簡単に説明する

 こんにちは。仕事でAWSの構築し、プライベートでAWSの研究と技術書の執筆をし、Amazonで本を売っているAmazon依存症の佐々木(@dkfj)です。
 AWSはお手軽便利で、個々のサービスの利用料はリーズナブルです。一方で、いろいろなシステムを作っていくと、気がつけば月々のコストがそれなりの金額になっている場合もあります。そういった際に検討するのが、コスト削減の施策です。一般的な利用方法だと、一番コストが高くなるのがEC2インスタンスです。EC2の利用料削減の方法として、真っ先に思い浮かぶのがリザーブドインスタンスだと思います。しかし、今ではリザーブドインスタンスをより発展させて柔軟な形で利用できるSavings Plansというものがあります。今回は、これを紹介しようと思います。

2つのタイプのSavings Plans

 Savings Plansには、2つのタイプがあります。Compute Savings PlansとEC2 Instance Savings Plansです。

f:id:dkfj:20200830024610p:plain

 EC2 Instance Savings Plansは、従来のリザーブドインスタンスと非常に近い割引プランです。リージョンやインスタンスファミリーを指定する必用がある代わりに、後述のCompute Savings Plansより高い割引率を享受できます。この割引率はリザーブドインスタンスのスタンダードRIと同等です。リザーブドインスタンスより柔軟な点としては、購入後のOS変更やテナンシーなどを変更可能です。また、インスタンス自体の価格が変動した場合、それに追随します。EC2インスタンスが値引きされたら、その値引きされた金額を基準に計算されるということです。一方で、リザーブドインスタンスとの違いとしては、キャパシティ予約などはできません。
 Compute Savings Plansは、今後のコスト削減方法の本流となるべきサービスです。基本的な考え方は、EC2 Instance Savings Plansと同じですが、全リージョンが対象となります。そして、EC2のみならずFargateやLambdaも対象となります。これは、嬉しいですね。ということで、Savings Plansがどこの部分が割引の対象で、どのように購入するのかを見てみましょう。

Savings Plansの仕組み

 リザーブドインスタンスは割引させたいインスタンスタイプを指定していましたが、Savings Plansは金額を指定します。単位時間あたりの対象サービス(EC2, Fargate, Lambda)の利用料を合計し、最低限どれくらいを使うかをコミットします。下の図でいうところの、変動の下限の部分です。その金額が単位時間あたり$10としたら、コミットメントとして割引後の金額を指定します。
※EC2 Instance Savings Plansだと、リージョンやインスタンスファミリーの指定も必用です。

f:id:dkfj:20200830024624p:plain

 文章で説明すると少し難しく感じるかもしれませんが、実際は金額を指定するだけなので簡単です。コンソールに推奨事項というのがあって、現状の利用料を元に推奨の購入額も教えてくれます。

f:id:dkfj:20200830031229p:plain

 コンソールで数字を入れてみると解るのですが、1時間あたり$1でも1ヶ月で$720、1年だと$8,760と大きな数字になってビックリするかもしれません。指定している金額と実際に払う金額の乖離が、直感とずれていることが解りにくさなのかもしれませんね。

どう使うのか

 柔軟性が高くリザーブドインスタンスより有利な条件にも関わらず、まだまだ認知度が低いように思えます。その理由の一つがインスタンスに対してではなく、利用料をコミットメントするという事にあるのかと思います。設計・構築段階では、どのインスタンスファミリーをどれくらい使うというのは、はっきりさせていると思います。一方で、それがどれくらいの料金なのかは、実際に構築している人は気にしていない事が多いのではないでしょうか?
 リザーブドインスタンスと同じなのかもしれないですが、そのAWSアカウントを管理する立場の人が定期的に利用状況をチェックし、定量的に利用している部分についてはSavings Plansを適用していくという運用が必用です。また買い方は時間あたりのコミットメントを指定するだけですが、割引率はリージョン・プラットフォーム・OSごとに異なってきます。これを厳密に計算しようとすると大変なので、EC2インスタンスなら20%引きとかざっくりと計算した方が良いです。少しづつ適用し、実際の利用額を見ながら対象を増やすといったような感じですね。

まとめ

 リザーブドインスタンスに代わる割引プランとして、Savings Plansの紹介でした。インスタンスファミリーに関わらず利用できるというのは、かなり使いやすいです。リザーブドインスタンスの課題を克服してのサービスなので、今後も拡充が期待できると思います。またリザーブドインスタンスとの併用もできるので、キャパシティ予約が必用なものはリザーブドインスタンスを利用してというような使い方もできます。これを機に、AWSの利用料を一度見直してみてはいかがでしょうか?
 なお現状はRDSは対象ではないですが、そのうち対応してくれないかと切に願っています。

AWSのインスタンスの種別を改めて整理する

インスタンスタイプの読み方

 インスタンスの種別を説明する前に、まずインスタンスタイプの表記の命名規則の説明をします。AWSを使っていると、M5.LargeとかC5.Smallとか見かけると思いますが、何となく解るようで解らないという人もいるのではないでしょうか?命名規則は、次のようにインスタンスファミリー・世代・インスタンスサイズで構成されています。

f:id:dkfj:20200829204105p:plain

 インスタンスファミリーは、後ほど詳しく説明しますが、汎用タイプ・コンピューティング最適化タイプなど幾つかのカテゴリがあり、そのカテゴリー内でも更に細分化されています。世代は、そのインスタンスファミリーの何世代目なのかです。例にあるM5だと、汎用化タイプであるMの5世代目です。A1とかだとArmベースの1世代目ということですね。基本的には、いちばん新しいのをつかっておきましょう。最後のインスタンスサイズが、性能を示します。インスタンスファミリーごとにベースとなる性能は違いますが、そのベースの性能内でsmall, medium, large, xlarge, 2xlargeとサイズが大きくなるごとにCPU・メモリーのサイズが原則的に2倍になっていきます。一部のインスタンスは等比例になっていない場合もあり、また、インスタンスファミリーによってはサイズの選択肢が少ないものもあります。

 原則としては、上記の命名規則となりますが、最近は世代のあとに小文字のアルファベットがついているケースがあります。

f:id:dkfj:20200829204121p:plain

 これは追加機能を表します。例えば、M5aだと汎用タイプの第5世代目という点は同じですが、CPUがIntelベースではなくAMDベースとなります。同様に、AWSが設計したAWS ArmベースのGraviton2プロセッサを使用するM6gなどもあります。追加機能はCPUの種類が違うだけでなく、ネットワークが強化されたM5nのようなタイプがあります。小文字を見ただけでは判断つかないケースも多いので、それぞれの説明を見てみるとよいでしょう。

aws.amazon.com

インスタンスの分類

 前説が長くなりましたが、ここからが本題です。最近のAWSの試験だと、どのインスタンスファミリーを使うのかが適切かと問われるケースがあります。画像処理をするので、高速コンピューティングであるP3インスタンスかなと導き出せる必用があります。ということで、まずインスタンスの分類をみてみましょう。現在、5種類に分類されています。

  • 汎用
  • コンピューティング最適化
  • メモリ最適化
  • 高速コンピューティング
  • ストレージ最適化

 次に、それぞれのインスタンスの特徴と具体的なインスタンスファミリーをみてみましょう。

汎用

 汎用タイプは、言葉通り一番用途の幅が広いものです。CPU・メモリのバランスが取られています。どのタイプが良いか解らない場合は、まず汎用タイプを使ってみて、CPUやメモリの利用状況を計測してみると良いでしょう。

インスタンスファミリー 概要
A1 ArmベースのAWS Graviton プロセッサを搭載
T3 バースト可能なCPU。もともとTiny(小さな)という意味でパワーとコストを抑えたファミリー
T3a AMDベースのT3ファミリー
M6g AWS Graviton2 プロセッサベース。Mシリーズの6世代目は、現在はこのM6gだけ。Intelベースは今後出てくるのか?
M5 一番オーソドックスな構成のファミリー。最初のEC2インスタンスは、M1.smallだった
M5a AMDベースのM5ファミリー
M5n ネットワークを強化したM5ファミリー

Mシリーズがベーシックで、それ以外にTシリーズのバースト特性を把握しておく事が大切です。

コンピューティング最適化

 コンピューティング最適化はメモリに比べてCPUの性能比率が高いものです。CPUを多様するアプリケーション処理で利用するとパフォーマンスが向上します。なにげにWebサーバーで利用されるケースも多いです。インスタンスファミリーとしては、事実上1系統のCしかありません。CPUが良いのはCと覚えておきましょう。

インスタンスファミリー 概要
C6g ArmベースのAWS Graviton2 プロセッサを搭載。M6gと同様、最新世代はgだけ出ている
C5 C5ファミリーのオーソドックスな構成。Intelベース
C5a AMDベースのC5ファミリー
C5n ネットワークを強化したC5ファミリー

メモリ最適化

 名前の通り、メモリが大量に載っています。実はちょっとややこしくなってくるのが、このメモリ最適化以降。汎用化やコンピューティング最適化に比べ、利用の機会が限定的なので何だっけかなとなりがちです。代表的なのはRシリーズなので、RAM(Random Access Memory)がいっぱい使いたければRと覚えておきましょう。

インスタンスファミリー 概要
R6g ArmベースのAWS Graviton2 プロセッサを搭載。M6gと同様、最新世代はgだけ出ている
R5 C5ファミリーのオーソドックスな構成。Intelベース
R5a AMDベースのC5ファミリー
R5n ネットワークを強化したC5ファミリー
X1e SAP HANAとかにも使われるエンタープライズ向けインスタンスファミリー
X1 x1.16xlargeから始まってvCPUが64個に976GBのメモリから
ハイメモリ SAP HANAとかに使われるものごっついインスタンスファミリー。u-6tb1.metalという名前から解るようにベアメタル用
z1d CPUとメモリのどちらも高性能なインスタンスファミリー

X1などは、オンデマンドで利用すると1時間で1千円くらいします。とすると、1年間で876万円。富豪的ですね。

高速コンピューティング

この辺りから理解が難しくなってきます。高速コンピューティングとあるので、コンピューティング最適化とどう違うのとまず疑問になると思います。コンピューティング最適化はCPUの性能が高く、高速コンピューティングはGPU等のCPU以外を使っての処理が得意とざっくり抑えておいてください。

インスタンスファミリー 概要
P3 汎用 GPU インスタンス。画像処理となるとこのインスタンスファミリー
Inf1 機械学習推論アプリケーションに適したAWS Inferentia チップを搭載
G4 機械学習推論やグラフィックを大量に使用するワークロードに最適化
F1 FPGAが利用可能な特殊なインスタンス

 高速コンピューティングについては、概要を読んでもサッパリ解らないのではと思います。まず標準的なタイプがP3となります。NVIDIA Tesla V100 GPUを搭載し、画像処理(Picture)が得意なPシリーズとでも覚えておいてください。次にG4です。G4も機械学習推論やグラフィックとなっており、こちらも画像処理できるのかいと思うでしょう。こちらはNVIDIA T4 Tensor Core GPUsを搭載し、機械学習用途と理解しておきましょう。
 Inf1とF1は、更に特殊性が高いです。Inf1は用途的にはG4と同じで機械学習推論で利用されます。AWSが開発したAWS Inferentia チップを搭載し、コストパフォマンスが高い機械学習用途のインスタンスファミリーと理解しておきましょう。最後のF1は一番特殊です。FPGAということで、カスタムハードウェアアクセラレーションを実現できます。チップに処理を埋め込むような形で利用します。そうすることで、ハードウェアレベルで低コストでパフォーマンスの高い処理ができるとのことです。かなり特殊な用途ですね。

ストレージ最適化

 ストレージ最適化は、ストレージ処理に特化したインスタンスです。特徴としては、EBSじゃなくローカルストレージ(インスタンスストア)の性能が高く容量も大きいということです。

インスタンスファミリー 概要
I3 SSDベースで、Non-Volatile Memory Express (NVMe) SSD-backed インスタンスストレージを提供
I3en I3の拡張でネットワーク帯域が大きい
D2 HDDベースのインスタンスファミリー6〜48TBのローカルストレージ
H1 HDDベースで、CPUとメモリも大きい

 ストレージ最適化のややこしいところは、概要を読んでも違いが解りにくいところです。まずHDDベースのD2, H1とSSDベースのI3で分けましょう。HDDベースはシーケンシャルなアクセスに強く、SSDベースはランダムアクセスに強いです。HDDベースのD2とH1の違いは、CPU・メモリも高性能かという点です。が、D2は2015年、H1は2017年11月に発表されたインスタンスで、どちらもその後の後継が出ていないところをみると、性能特性としてはあまり進化していっていないです。同様にI3も2017年2月以降、後継のものは出ていません。

どのインスタンスを使うのか?

 いろいろなインスタンスファミリーを紹介して混乱したかも知れません。使い方に迷ったら、まずはMシリーズを使いましょう。そして、そのCPUやメモリの利用状況をみて、Cシリーズも検討しましょう。開発用途とかでコストを抑えたい場合は、Tシリーズになります。この3種類を使いこなせると、一般的なアプリケーション用途であれば9割ほどがカバーできます。認定試験対策としても、インスタンスファミリーの理解は必用ですので、これを機会に覚えてみてはいかがでしょうか?

Fin-JAWS 第14回で、AWS認定セキュリティ専門知識を基軸にAWSのセキュリティについて話しました

 8月13日に開催されたFin-JAWS 第14回 Fin人類育成計画で、論理登壇しました。全体のテーマは人材育成ということで、AWS認定試験の対策本の著者たちが集まってそれぞれ話しています。私は、セキュリティ専門知識の対策本を出した縁で、AWSのセキュリティの考え方を軸に話しました。

fin-jaws.connpass.com

登壇資料とTogetterまとめ

 当日の登壇資料は、これです。

speakerdeck.com

 当日のTwitterのまとめです。かなり活発に意見が飛び交いまして、最後には#finjawsのハッシュタグがトレンド入りしていました。

togetter.com

AWSのセキュリティの考え方

 資料中に書いていますが、当日話したことをダイジェストでお伝えします。

巨人の肩に乗る

 今やセキュリティ対策として検討する必用がある領域は、非常に多岐に渡っています。何の対策が必用か、自分で考えるのは現実的ではなくなっています。そこで、先人たちが考えたフレームワークに乗っかかるというのは非常に有効です。いわゆる巨人の肩に乗るということですね。

f:id:dkfj:20200820084747p:plain

 AWSのセキュリティ分野であれば、NISTのサイバーセキュリティフレームワークとAWS Well−Architectedフレームワークをまず読むことをおすすめします。

NIST サイバーセキュリティフレームワーク コア(IPA公開版)
AWS Well-Architected フレームワーク

 この2つを読み比べると解るのですが、どちらも結構似たことを言っています。それもそのはずで、AWS Well-Architectedのセキュリティの柱はNIST サイバーセキュリティフレームワークを下敷きにしている部分も多々あります。また既にWell-Architectedフレームワーク読んだよという方も、もう一度読んで見ることをお勧めします。2020年3月と7月に改訂されています。フレームワークもどんどん進化しているということですね。

 NIST サイバーセキュリティフレームワークの解説については、次の記事がお勧めです。

www.secure-sketch.com

フレームワークを当てはめる

 フレームワークでセキュリティ対策の概要を知ったら、次は実際のシステムにどのように当てはめればよいのかを考えてみましょう。その際のお勧めは、要素・構成を抽出して、同じシステムでも目的別・レイヤー別・アーキテクチャ別などいろいろな観点から構成を考えてみるのがよいです。

f:id:dkfj:20200820085748p:plain

f:id:dkfj:20200820085803p:plain

f:id:dkfj:20200820085815p:plain

 実は上記の図は全て、私が書いた技術同人誌である『AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー』からの引用です。当日話した内容をテキストベースで詳しく説明しているので、もし興味がありましたらBOOTHで見てください。2章までの無料版を公開しています。

booth.pm

伴走者を見つける

 これも持論ですが、この手の対策は机上でドキュメント読むだけで身につけるのは中々難しいです。実際に自分で設定して運用してみると、セキュリティーフレームワークが言わんとしていた事が理解できるようになってきます。で、実際に対策しようと、最初の取り掛かりが非常に大変です。なぜならばフレームワーク読んだとしても、実際に手を動かそうとした瞬間に何からすれば良いのか全く解らなくて途方にくれるからです。
 そんな際にお勧めは、最初は伴走者をつけることです。スタート時点で自分の少し前で走ってくれる伴走者がいると、走り出しが非常にスムーズになります。最初にすべきこと、次にすべきことといった優先順位の付け方の相談ができるだけで、心理的な負荷も小さいです。そして、気がついたら自走しているという形が理想的ですね。
 少し宣伝が入りますが、最近AWSのセキュリティ相談に関する案件が増えていることもあり、セキュリティ支援のサービスも開始しています。どういったアプローチで対策するかや、定番の対策方法についてはテンプレート化して提供もしています。も興味があれば、お気軽にお問い合わせください。

www.nri-net.com

まとめ

 ということで、AWSのセキュリティをどのような観点で考えて対策していくのかということの紹介でした。何から始めればよいか途方にくれている人の一助となれればと思っています。あと今月は、8/25にJAWS-UG朝会、8/28にSecurity-JAWS と立て続けに登壇します。朝会の方はCloudFormation StackSets × Organizations、Security-JAWSは試験対策寄りの話しをする予定です。お時間の都合が付けば、ぜひご参加ください。

jawsug-asa.connpass.com

s-jaws.doorkeeper.jp


AWSのAutoScalingの整理 猶予期間・ウォームアップ・終了ポリシー編

 基本に立ち返ろうということで、AWSのAutoScalingの仕様の確認です。前回は、スケーリングポリシーを中心に確認でした。今回は、起動や終了に関わる仕様ということで、猶予期間・ウォームアップ・クールダウン・終了ポリシーなどの解説になります。

前回
AWSのAutoScalingの整理 スケーリングポリシー編 - プログラマでありたい

ヘルスチェックと猶予期間



 まず最初にヘルスチェックと猶予期間です。ヘルスチェックは、AutoScalingの管理対象下のインスタンスの動作をチェックして、異常が認められた場合は新しいインスタンスと置き換えられます。

Auto Scaling インスタンスのヘルスステータスは、正常または異常のどちらかです。Auto Scaling グループ内のすべてのインスタンスは正常な状態で起動されます。インスタンスに異常があるという通知を Amazon EC2 Auto Scaling が受け取らない限り、インスタンスは正常であると見なされます。この通知は、Amazon EC2、Elastic Load Balancing (ELB)、カスタムヘルスチェックのうち 1 つ以上のソースから送られる可能性があります。

Amazon EC2 Auto Scaling がインスタンスを異常ありとマークすると、置き換えがスケジュールされます。インスタンスを置き換えない場合は、個々の Auto Scaling グループに対するヘルスチェックプロセスを停止できます。

Auto Scaling インスタンスのヘルスチェック - Amazon EC2 Auto Scaling (日本語)

 このヘルスチェックの挙動を理解するために重要になるのが、ヘルスチェック猶予期間です。英語では、Health Check Grace Periodです。AutoScalingが発動してインスタンスが起動されても、インスタンスの起動時間やインスタンス内のプロセスの起動時間があるために、すぐにそのインスタンスが利用可能な状態になる訳ではありません。その間にヘルスチェックでエラーが出続けると困るので、一定期間ヘルスチェックをしないという猶予期間があります。画面コンソールから作った場合の、猶予期間はデフォルトで300秒(5分)です。が、CLIやSDKから作った場合は、なんと0秒です。この辺の差異がある経緯、ちょっと気になりますね。

f:id:dkfj:20200810154503p:plain


 ヘルスチェックの猶予期間の設定画面をみると、EC2ELBの2つのヘルスチェックがあることに気が付きます。この違いは何なのか、それぞれ見てみましょう。

Amazon EC2 ステータスチェック

 まずEC2の方です。こちらは、正式名称がAmazon EC2 ステータスチェックです。その名の通り、EC2インスタンス単体としてのヘルスチェックを行います。AutoScalingのデフォルトのチェックは、こちらです。

Elastic Load Balancing (ELB) ヘルスチェック

 Elastic Load Balancing (ELB) ヘルスチェックは、ELBが提供するテストに基づいて判断されます。対象となるものは、ALBとNLBのターゲットグループならびにCLBです。ヘルスチェックの方法は、ELBの種類によって異なります。ALBの場合はアプリケーションレイヤー (HTTP および HTTPS) のヘルスチェックをサポートし、NLBとCLBの場合は、アプリケーションレイヤー (HTTP/HTTPS) とTCPの両方のヘルスチェックをサポートします。インスタンスは正常だけど、ELBから利用するプロセスが異常という場合に、素早く対処したい場合はELBヘルスチェックを利用します。
 ELBのヘルスチェックでややこしいのは、ヘルスチェック猶予期間はあくまでAuto Scalingの中だけで完結していることです。つまり、ELBからのヘルスチェックは猶予期間内であってもUnHealthyを返します。アラートがならないようにヘルスチェックをするには、この辺を考える必用があります。

 クラスメソッドさんのブログでも同じテーマで課題提起があり、ELB側ではなくAuto Scaling Group側のGroupTerminatingInstancesがお勧めとのことです。

ELB配下でAuto Scalingを構成する場合には、ELB側のUnHealthyHostCountを利用するのではなく、Auto Scaling Groupが持っているGroupTerminatingInstancesメトリクスを利用した監視がオススメとのことです。

EC2 Auto Scaling グループの「ヘルスチェックの猶予期間」を正しく理解する | Developers.IO

スケーリングクールダウンとウォームアップ


 ヘルスチェックの猶予期間を理解したのでAutoScalingについては完璧かと思いきや、AutoScalingにはクールダウンとウォームアップという概念があります。こちらも理解しておきましょう。

クールダウン

まずはクールダウンです。正式名称は、スケーリングクールダウンというようです。これはAutoScalingが発動した直後に追加でインスタンスの増減がなされるのを防ぐための設定です。猶予期間と混同されがちですが、猶予期間はヘルスチェックの猶予であり、クールダウンはインスタンスの増減のアクションの発動に対してのパラメータとなります。

f:id:dkfj:20200810184407p:plain


 ちなみにAWSの説明では、古い設定であり現在ではデフォルトの設定のまま調整しないで済むとバッサリと切り捨てられています。

スケーリングアクティビティが完了してから別のアクティビティが開始されるまでの時間を変更します。時間の長さは、インスタンスのウォームアップ期間、またはその他のアプリケーションニーズに基づいて設定できます。これは古い設定であり、ほとんどの場合において、デフォルトの 300 秒のままとすることができます。クールダウンオプションは、ターゲット追跡スケーリングポリシー、ステップスケーリングポリシー、またはスケジュールされたスケーリングではサポートされていません。

 切り捨てられている理由としては、クールダウンは主として簡易スケーリングに対するパラメータとして動いているためです。ステップスケーリングの場合、メトリクスに対して複数の閾値が指定できます。そのためスケーリング動作中に、別の閾値に達した場合にはクールダウンと関係なく反応するようになっています。一方で50%で1台追加で60%で2台追加と設定している場合、50%に反応して1台追加中に60%に達し更に2台追加となると過剰に追加しすぎとなる場合があります。それを抑止するために、ウォームアップという概念があります。

ウォームアップ

 ウォームアップは前述のとおり、ほぼステップスケーリングで差分でインスタンスを追加するために追加された機能です。事実、ステップスケーリングの機能が追加された時に、パラメーターとして登場しています。動作のポイントは2つです。CPUの利用率が50%の時に1台追加、70%の時に2台追加というポリシーが設定された場合を例に解説します。

  • (インスタンス追加され)ウォームアップ期間中には、そのアラームでのインスタンス追加はされない
  • ウォームアップ期間中に次のアラート(70%)が発動した場合、差分の台数が追加される

f:id:dkfj:20200810231420p:plain

ウォームアップは、ステップスケーリングとターゲット追跡スケーリングポリシーに対応しています。

その他のAutoScalingのオプション


 猶予期間とクールダウン、ウォームアップを理解できれば、AutoScalingのオプションについて、ほぼ理解していると言えるのではないでしょうか。ただ、上記以外にも、まだ幾つかオプションがあります。代表的なのがライフサイクルフックと終了ポリシーです。せっかくなので、この2つについても見ていきましょう。

ライフサイクルフック

 ライフサイクルフックは、Auto Scalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行する機能です。例えば、起動時にデータを取得してきたり、削除時にログやデータの退避の処理を追加するといった用途で使えます。待機時間はデフォルトで1時間、最大で48時間まで設定できます。ただ48時間必用なケースは、どうしても思い浮かびません。

https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/lifecycle_hooks.png

終了ポリシー

 負荷に応じてインスタンスを増やすのをスケールアウトと言います。これに対して、負荷が下がってインスタンスを減らす場合はスケールインといいます。さてAutoScalingでは、スケールインの際に、どのインスタンスを削除するのでしょうか?これを決めるのが、終了ポリシーです。デフォルトの終了ポリシーでは、インスタンスがアベイラビリティーゾーンに均等に配分されるように削除します。2つのAZで2台・3台とインスタンスがある場合、3台あるAZのインスタンスを一つ削除させてAZ間で均等にさせるというような動作になります。それ以外にも、

終了ポリシー 概要
OldestInstance 最も古いインスタンスを削除
NewestInstance 最も新しいインスタンスを削除
OldestLaunchConfiguration 最も古い起動設定のインスタンスを削除
ClosestToNextInstanceHour 次の課金時間に最も近いインスタンスを削除
Default
OldestLaunchTemplate 最も古い起動テンプレートを使用するインスタンスを削除
AllocationStrategy スポットまたはオンデマンドなどのインスタンスタイプの配分戦略に沿って削除

ClosestToNextInstanceHourなんかは、出た当初は素敵と思ったのですが、今はEC2のインスタンスの課金単位時間が1時間から1秒に変わりほぼ意味がなくなっていそうです。今だと、どういった挙動になるのは、どこかで実験してみます。1時間という前提を残して動くのではと予想しています。

まとめ



 前後2回に渡って整理してきたEc2 AutoScalingの仕様の確認はいかがでしたでしょうか?普段使わない設定も多く、知らない事も多かったのではないでしょうか?AWSの認定試験は、ケースごとにどのような設定をすれば良いのかということを問われます。そのためには、網羅的に仕様を把握しておく必用があり、AutoScalingは特に重要なポイントです。ELBとAutoScalingは一緒に設定することが多く、どれがどちらの仕様か混同して覚えてしまうことが多いです。一度、AutoScalingとELBを別々に学ぶというのは有効だと思います。
 次回は、ELBを整理してみようと思います。