AWS Direct Connectの勉強その２ プライベートVIFの接続パターン

　昨日に引き続きAWS Direct Connectのお勉強です。大切なことなので繰り返しますが、私はネットワークについては苦手なので、勘違いしていることがあれば容赦のないマサカリをお願いいたします。

AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その２ プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その３ パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その４ Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その５ 経路選択と冗長化 - プログラマでありたい

プライベート接続

単一VPCへの接続

　まずはプライベート接続からです。一番、基本的なオンプレミス側のデータセンターとAWSのVPCを一つ接続するパターンです。

データセンター側にルーターが必要となります。ルーターの機能要件としては、下記の4つです。

• BGP サポート
• MD5認証 サポート
• IEEE802.1q サポート
• VLAN サポート

　Private VIFをVGW（Virtual Private Gateway）にアタッチし、VPCとデータセンター間の通信を確立します。その際に、異なる2つのネットワークの経路を制御するのがBGP（Border Gateway Protocol）です。BGPを介して、双方のネットワークを広告します。図中に、eBGPと書いていますが、これはExternal BGPの略です。External（外部）という言葉から解るように、異なるネットワーク（AS）間の経路交換です。同一ネットワーク間の間の経路交換の場合はiBGP（Internal BGP）を利用します。この辺りは経路の冗長化のところで説明します。

複数VPCへの接続

　開発用VPC・検証用VPC・本番用VPC或いは、システムA用VPC・システムB用VPCと複数のVPCを利用するケースは多いと思います。Direct Connectを利用する企業の場合、むしろ複数VPCを活用しているケースの方が多いのではないでしょうか？ Direct Connectのみで、複数VPCに接続する方法が次の図です。

　その解決方法は、ずばりVPCごとにPrivate VIFを用意して異なるVLANを割り振ってそれぞれ接続するという方法です。Direct Connectは基本的には論理的接続であるPrivate VIF単位ではなく物理的な回線であるConnection単位です。そのため、一本のConnectionを複数のPrivate VIFに分割しても料金は基本的には変わりません。（パートナー経由でPrivate VIFを提供されている場合は、そうでないケースは多いと思います。）
　一方で、Connectionの全体の帯域をPrivate VIFで分け合うので、Private VIFが増えるとVIF単位の帯域は狭める必要があります。そもそも、VPCの数が数個くらいであれば大きな問題にはなりませんが、10や20或いは100といった単位で利用している場合はVPCごとにPrivate VIFを用意するのは困難です。そこで今まで色々なパターンの接続方法が編み出されてきました。その辺りも紹介していきます。

Transit VPC

　複数のVPCに接続するパターンとして昔からあるパターンの一つがTransit VPCです。いわゆるハブアンドスポークネットワークトポロジーの接続形態で、オンプレミスの拠点とハブとなるVPCを接続し、ハブVPCから複数のスポークVPCに接続するというパターンです。スポークとは、車や自転車のタイヤで中心から伸びてるあれです。

※Wikipediaさんから拝借

概念的には普遍的な接続形態だと思うのですが、AWSの場合はTransit VPCというとハブVPC内にCiscoのルーターを置いたものを指すようです。

　オンプレミス拠点とハブVPCは、VPNもしくはDirect Connectで接続します。まぁこの文脈だとDirect Connectを利用してくださいですが。ポイントはハブVPCとスポークVPCの接続です。これはハブVPC内に起動したルーター機能を果たすec2インスタンスとスポークVPC間でVPN接続をします。なぜ、AWSの機能であるSite to Site VPNを使わないかというと、AWSのVGWはIPSECのネゴシエーションはしないので、VPC同士でVPNを貼れないからです。そこでルーターの仮想アプライアンスを利用するという形になっています。

　実際のTransit VPCの構成は、可用性を確保するために2つのAZにそれぞれ仮想アプライアンスを配置し冗長化した構成になっています。詳細は、下記のページを参照してください。

aws.amazon.com

VPCピアリングのパターン

　先程のTransit VPCのパターンと同様にVPC Peeringを使ってHub VPCとSpoke VPCを形成することも可能です。VPCピアリングはVPWを利用したVPN通信ではなく、VPC同士をネットワーク的に通信可能にする機能です。通常のAZ間、或いはリージョン間の通信として扱われるため、Direct Connect GatewayやTransit Gatewayを介した通信より低コストで運用できることが多く、VPCピアリングは今でも採用されるケースが多いように思えます。

　ちなみにVPC Peeringは、隣接するVPC同士の通信のみサポートするので、オンプレからspoke VPCのインスタンスに対して直接通信するような透過的通信はできません。
※上のTransit VPCでも同様だと思います。（未確認）

プライベートVIFからのVPC外のAWSサービスへの接続方法

　ここまででプライベートVIFの接続パターンや構成パターンを幾つか見ました。さて、S3やLambdaのようなVPC外のAWSサービスにアクセスしたい場合はどうしたら良いのでしょうか？次の図のようにプライベートVIF経由では、VPC外のAWSサービスに直接アクセスすることが出来ません。Direct Connect経由でS3にアクセスしたいというユースケースはわりとありまして、そういった時の接続パターンの一つとしてはVPC内にプロキシ的な役割を果たすEC2インスタンスを用意するといった方法があります。ちょっと面倒くさいですね

　そういった用途に応えるためのAWSサービスとして、インターフェース型のVPCエンドポイント（Private Link）があります。これは、VPC内にAWSサービスのエンドポイントをのばしてきて、あたかもVPC内のリソースにアクセスするというサービスです。

なおS3とDynamoDBはVPCエンドポイントに対応しているのですが、ゲートウェイ型VPCエンドポイントという形式です。これを利用しても、オンプレからプライベートVIF経由でS3にアクセスすることはできません。2020年のre:Inventの発表でS3もインターフェース型VPCエンドポイント（Private Link）に対応するという宣言があったので、近い将来利用できるようになるです。

まとめ

　Direct ConnectのプライベートVIFについて接続パターンをまとめてみました。プライベートVIFはVPCと１対１で接続するため、複数のVPCを利用している場合は接続パターンに工夫が必要です。今回はプライベートVIFのみで解決する方法を幾つか紹介しています。が、どれも使いにくいというのが正直なところです。その改善として、AWSはDirect Connect GatewayやTransit Gatewayを出してきています。これもそのうち紹介したいです。
　今回のDirect Connectの勉強シリーズは、自身の苦手なところの補強。そして、BGPの理解のために書いています。が、なかなかそこまでたどり着かないので、来週に控えたAWS認定アドバンストネットワークに合格できるか不安になってきました

AWS Direct Connectの勉強

現在、AWS認定は9個持っていますが、どうせなら12個全部取ってドヤ顔したいと思っています。残りはアドバンストネットワーク（高度なネットワーキング）、データベース、Alexaです。データベースとAlexaは取れる自信があるので、最大の鬼門のアドバンストネットワークを片付けたいです。これを取るためには、Direct Connectまわりの理解が必要です。Direct Connectは利用者としての知識しかないので、ちゃんと勉強してみようと思います。

AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その２ プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その３ パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その４ Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その５ 経路選択と冗長化 - プログラマでありたい

高度なネットワークング周りのDirect Connectの出題範囲

まずは試験範囲の確認として、AWS公式のExam Readinessのデジタル講座を受講しました。
Exam Readiness: AWS Certified Advanced Networking - Specialty (Digital)
https://www.aws.training/Details/Curriculum?id=21330

Direct Connect周りは、下記の知識が必要なようです

• Direct Connectの概要
• BGP
• Public VIF
• Private VIF
• Connecting to VPC Multiple Accounts
• VPN and Direct Connect Communication Outside of VPC
• Transit VPC
• Direct Connect Gateway

まずはDirect Connectの基礎知識から、BGP・VIF辺りを確認してみます。

Direct Connectの構成要素

Direct Connect ロケーション

　Direct Connectは、ユーザーが利用しているデータセンターなどの物理拠点とAWSの間を専用線で接続するためのサービスです。しかし、物理拠点とAWSは直結されるのではなく、Direct Connect ロケーションと呼ばれる接続ポイントを介して接続します。AWSの所有するデータセンターがどこにあるか解らないし、かつ複数のAZ・データセンターに分散しているためですね。

　東京リージョンだと、Equinix TY2が有名ですが、アット東京 CC1や大阪・台湾など幾つかのDirect Connect ロケーションが利用可能です。Direct Connect ロケーション内には、AWSが管理する機器とユーザーもしくはDirect Connect提供パートナーが管理する機器があります。

Connection（接続）

　AWSが管理する機器とユーザーもしくはDirect Connect提供パートナーが管理する機器も同一構内にありますが、この間もネットワークによって接続されます。これをConnection（接続）と呼びます。Connectionは1Gbps or 10Gbpsで 接続できます。ちなみに、ユーザー自身でも直接Direct Connectを敷設できますが、直接利用するケースは少なくDirect Connect提供パートナー経由で利用することが殆どです。そのため、アドバンストネットワークで問われるDirect Connect絡みの問題は、やったことがないよって状態になることが多いです。

Link Aggregation Group（LAG）

　10Gbps or 1Gbpsの回線を利用可能ですが、それ以上の帯域が必要な場合はどうしたら良いのでしょうか？Link Aggregation Group（LAG）を使って複数の物理的な回線を1本の論理的な回線にまとめることができます。集約する場合は、等速度の回線を利用する必要があります。また最大4本までです。つまり、（オーバーヘッド分を無視すると）40Gbps分の帯域が利用可能になります

　ちなみにDirect ConnectのFAQを眺めていると、途中でLAGのリンクを追加できるようです。例えば、最初2本で集約していたところに更に2本追加して4本というようなことも出来るようです。ただし、追加しようとした時にLAGを形成しているポートに空きが無い場合は、新たにLAGを組み直さないといけないようです。問い合わせる時、超ドキドキですね

仮想インタフェース（Virtual Interface = VIF）

　先程、Connectionが1Gbps or 10Gbpsの物理的な接続と説明しました。このConnectionをそのまま使うのではなく仮想インタフェース（VIF）と呼ばれる論理的なインタフェースとして扱います。Connectionは10Gbpsか1Gbpsですが、VIFはもっと細かい単位で利用できます。パートナー経由の提供ですが、1Gbps未満の50,100,200,300,400,500Mbpsの帯域を利用できます。

※AWSのWebサイトから拝借

　先程、Direct Connectを直接利用する人は少なくパートナー経由の提供が多いといいましたが、パートナーのサービスの多くはConnectionではなくVIFを提供することになります。そのため、多くの人のイメージではDirect Connect = VIFになるのではないでしょうか。Connection自体を提供するのが専有型で、VIFを提供するのが共有型です。
※だからAWS認定アドバンストネットワークが難しく感じる。愚痴です

　さて、このVIFですが、実はPublic VIFとPrivate VIFとTransit VIFの3種類があります。Transit VIFはTransit Gatewayと密接な関係があります。ここでは、Public VIFとPrivate VIFの説明していきます

Private VIF

　まずPrivate VIFです。Private VIFはVPCに接続するために利用します。Direct Connectの目的の9割9部がこちらの方ではないでしょうか？オンプレミスのデータセンターのプライベートネットワークから、VPCのプライベートネットワークまでグローバルIPを介すことなく通信可能にします。

Public VIF

　Public VIFはオンプレミスのデータセンターのプライベートIPをパブリックIPにNATして利用するサービスです。そして、S3やDynamoDBなどVPCに入らないサービスを直接利用可能にします。と言っても、Direct Connect提供パートナーでこちらのサービスを提供しているところは殆どありません。Private VIFのニーズが高いのでしょうね。
　ちなみに、S3やDynamoDBはVPCの中には入らず、基本的にはパブリックIPで接続します。このAWSネットワークの中でVPCじゃない空間は一体何なのでしょう？インターネット空間なのかそうではないのか？これは面白いテーマなので、いつか解説しようと思います。

まとめ

　力尽きたので、今日はここまでです。今回はDirect Connectの物理的な設備（Direct Connect ロケーション）のところから、物理的な回線（Connection）、論理的な接続として提供されるVIFまでです。VIFには、馴染みがないですがPrivate VIFとPublic VIFの２種類があります。次回はPrivate VIFやPublic VIFの接続パターンや経路選択・経路切替について説明してみようと思います。経路選択にはBGPの知識が必要なので、これを上手く理解して説明できるか今後の自分に期待しています。ネットワークは苦手な分野なので、認識違いありましたら容赦ないマサカリをお願いします

2021年1月の目標

昨年の実績がダメダメだったので、初心に戻って月ごとの目標を立てていきます。いつまで続くか解りませんが、まずはやってみます。

2021年1月の目標

• AWS 認定 高度なネットワーキング – 専門知識の取得
• 序章を完成させる
• 新規書籍の目次完了。メンバーが執筆レディの状態にする
• 技術ブログを４本書く

AWS 認定 高度なネットワーキング – 専門知識の取得

12冠の最大の壁、AWS認定 アドバンストネットワーク – 専門知識の受験と合格目指します。試験範囲については、年末にまとめていて、1/15に受験するので勉強時間を15時間ほど確保する。平日1時間×８日と休日2時間×3日とどこかでプラスアルファ。ついでに勉強した内容をブログにまとめる

序章を２本完成させる

　昨年末に手をつけていた新刊の序章を完成させる。残り8,000字くらい

新規書籍の目次完了

　企画が完了している新規書籍の目次を完成させる。メンバーと担当箇所を割り振って、執筆可能な状態に持っていく

技術ブログを４本書く

　毎週１本を目安に技術ブログを書く。今月は、AWS認定アドバンストネットワークの勉強した内容を中心にまとめる。一本は、昨年まとめていなかったre:Inventの１行まとめ

その他

• 毎日１万歩歩く。１月は31万歩
• 仕事始める時に、１日分のToDoリストを作る
• 本を５冊読む

2020年の振り返りと2021年の目標

　あけましておめでとうございます。今年もよろしくお願いします。
毎年恒例の、昨年の振り返りと今年の目標です。2020年の主な活動は、執筆3冊と登壇4回です。あと、AWSにアンバサダーでTop Japan Ambassadorsとして貢献度日本一と表彰されました。これだけ書くと順調のようですが、個々の振り返りをしてみると非常に苦しんだ1年です。

11,12冊目の本の出版と13冊目の執筆

　昨年の執筆実績は3冊です。と言っても、執筆に当てられる時間が少なく、純粋に書いた文字数ではここ数年の中で一番少なかったかもです。1冊目は、AWS認定セキュリティの試験対策本である、要点整理から攻略する『AWS認定 セキュリティ-専門知識』。こちらは初のマイナビ出版さんから刊行です。また執筆自体も、私は最初の企画と一章のナビの部分のみで、あとは殆ど会社の同僚の上野さんと小林さんの執筆です。初版の誤植などの問題はありましたが、内容的なクオリティは非常に高いと思っています。絶賛発売中です

要点整理から攻略する『AWS認定 セキュリティ-専門知識』

　12冊目は、また技術同人誌です。前回はIAM本だったので、次はAWSアカウントセキュリティにフォーカスを当てています。物理開催される予定だった技術書典8に合わせて書いていたのですが、残念ながら物理開催は中止でオンラインで販売中です。まぁこれも、技術同人誌というカテゴリーの中ではかなり売れていると思います。合わせて技術書典9で、AWSのマルチアカウント本を書いて3部作完結とする予定でしたが、気力が尽きて書けていません。春までには書きたいですね

booth.pm

　13冊目は、AWS認定ソリューションアーキテクトの対策本の改訂です。2019年に書いたのに、2020年に試験が改訂されたのでそれに合わせての修正です。執筆が遅れて2021年1月の発売になってしまいました。そのため、10月過ぎくらいから在庫切れが続き、出版社にも購入希望者にも申し訳なかったです。すいません。

AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版

登壇

　昨年は登壇は4つと少なめです。新型コロナの影響というより、気力・体力の関係ですね。登壇すると自分自身の学びの効果も高く効率がいいのですが、なかなか手を挙げられませんでした。もともとは無理やり機会を作るために、地方の勉強会に参加しようと意気込んていたのですが、物理開催が難しくなり実現できずです。論理開催になったので、全国の勉強会に参加するチャンスはできたのですが、その辺りを活かせずですね。

『AWSの薄い本 IAMのマニアックな話』の輪読会

　登壇ではないのですが、唯一物理参加したのが輪読会です。自著の輪読会が開催されているのを知って、押しかけさせてもらいました。楽しかったです。都合があえば可能な限り参加するので、お気軽にお声がけください

blog.takuros.net

富山IT勉強会

　地方に旅行することをモチベーションに、勉強会に登壇の機会を増やそうと考えていました。ちょうど良いタイミングで富山であると知って参加予定でしたが、残念ながら新型コロナの影響で論理開催に。少人数でいろいろ話せたので、これはこれで良かったです。また参加したいです。

blog.takuros.net

Fin-JAWS

　AWS認定セキュリティの対策本の執筆記念にお声がけいただきました。Fin-JAWSは初参加だったのですが、金融クラスターの方々と話ができる良い機会でした。

speakerdeck.com

JAWS-UG朝会

　AWS OrganizationsとCloudFormation StackSetsの話をしたくて申し込みました。朝の時間を有効活用できるのは良いですね。またこの辺のテーマの話は、もっといろいろしたいです。

speakerdeck.com

Security-JAWS

　同じくAWS認定セキュリティの対策本の執筆記念にお声がけいただきました。テーマがFin-JAWSで話したのと同じだったのと、参加者の層もかぶっていたので、結果的に2回聞いたという人も多かったようです。この辺は工夫すべきでした。反省

speakerdeck.com

ブログ

　自分にとっての活動のバロメーターであるブログの投稿は、2020年は41本でした。2019年は26本だったので少し復調かなという気はしますが、月によってのばらつきがありコンスタントな活動ができていません。またブログのアクセス数は86,126と前年の202,257に較べて大幅減です。定期的な投稿していないと減るのよねぇと改めて実感です。今年は毎週1本くらいのペースに戻そうと思います

　10年くらいのスパンでみると、低迷っぷりは明白です

Japan APN Ambassadorで日本一

　唯一明るいニュースが、AWSのAPN Ambassadorで地域（日本）貢献度で一番ということで表彰されました。ありがとうございます。ちなみに一番順位が高い時は、世界で3位くらいでした。※

www.nri-net.com

　なお、今では同僚の上野さんに抜かれて、国内2位です。
※Ambassadorだけが入れるポータルがあり、そこでランク付けされています。

2020年の目標に対しての採点

本を3冊書く　⇒　○　一応3冊分書いたので良しとしましょう。今年は複数人で並行で進めているのを、一気に展開したい
Kindle本を書く　⇒　○　IAM本とAWSアカウントセキュリティ本をKindle本として出してみました。少しだけ様子が解りました　
ブログ　⇒　☓　9万ビュー弱。昨年から半減以下。最盛期の1/10くらい。コンスタントに書く習慣が無くなってから駄目だ　
英語ブログ　⇒　☓　全く取りかかれず　
資格試験　⇒　☓　なんと一度も試験を受けず
英語　⇒　☓　何もせず。。。

自己採点すると、もうダメダメです。このレベルになると、やろうとしている方向性と目標の立て方がずれていたということでしょう。

2021年の目標

• 本を書く　自分中心ではなく、周りの人を巻き込んでの活動にします。2020年からこの活動はしているので、順調にいけば2021年には結構な本数を出せると思います。ただ、AWSの薄い本の三部作目は自分の手で完結させたいです。あと1冊ずっと出せていない本もちゃんと書かないと。
• 動画コンテンツ　個人でやるか会社としてやるか、或いはその両方か検討中ですが、動画コンテンツに挑戦してみたいです。今までブログや書籍など活字コンテンツ中心だったので、違う市場というのを見てみたいというのが目的です
• 資格試験　AWS認定試験12冠。これだけはちゃんと達成します。3月まで
• ブログ　ページビュー数を目標じゃなくて、毎週書くということを目標に再設定します。考えてみたらビュー数は結果ですし、忙しくても書くという習慣化が必要なのだと思います
• IAM本を英語化＆Kindleで全世界販売　世界の市場規模を知りたいので、これをやってみたい。2年ほど前から検討してたのですが、今年こそはやります。誰か手伝ってくれる人募集
• 事業として考える　過去の執筆物が積み上がり技術同人誌の販売をしていて、経理とか含め片手間でやるのがしんどくなってきました。この辺り、一度ちゃんと税理士さんとかと相談できるような体制つくりたいと思っています。※ちゃんと毎年納税していますよ
• Twitterのフォロワー5,000人　最近マーケティング的な動き方というのも模索しています。まずは自分ごとで始めるのが大事なので、Twitterのフォロワーを増やしてみたいです。現時点で2,600人なので倍の5,000人。かなり厳しいですが、方法考えてみます

まとめ

　全般的に不調な2020年でした。子供が地域の野球チームに入ったので、土日にそれの手伝いが必要など時間的な制約面が大きかったのかもしれません。が、それ以上にやる気がでなかったのが大きいと思います。理由の一つとしては、活動がマンネリ化していることだと考えています。執筆活動はそれなりにもう充分成果は出してきたと思うので、企画等の段階から含めて若者に任せていきたいと思います。その代わりに新しい挑戦をしていきたいです。具体的な内容については、計画立てて順次発表していきたいと思います。
　2021年も宜しくおねがいします

社内re:capでAWSの進化の話と、少しエモい話をしてきました

　所属する会社のグループ全体で、3週連続でAWSのre:Inventのre:capするということで、アンバサダーとして登壇してきました。登壇者の中で一番の高齢者層だったので、新サービスの発表についてでなく、昔話からの振り返り的な話をしています。

S3の歴史からみる「強力な書き込み後の読み取り整合性」について

　テーマに選んだのが、2020/12/03に発表されたS3の「強力な書き込み後の読み取り整合性」についてです。個人的には今回の新サービスの発表の中で、一二を争うくらいの凄い改善だと思うものの、なかなかその凄さが伝わっていないのかなと思います。ということで、歴史的な経緯から。

結果整合性

　はじめは結果整合性から。US Standardリージョンという耳慣れない言葉と一緒に紹介しています。いずれは最後に書き込んだ値になるけど、読み込むタイミングによっては最新の情報ではないかもというのが結果整合性です。

　ちなみに最初期はS3にデータを転送するのにもお金がかかっていたんですよね。今は、Inの転送料は無料です。

「書き込み後の読み込み」整合性

　次に出てきたのが「書き込み後の読み込み」整合性です。新規のオブジェクト作成時は、即時に整合性が反映されているが、オブジェクトの上書きや削除については結果整合性というのが、「書き込み後の読み込み」整合性です。

　US Standardリージョン以外はわりと早い時期にこれが利用できたので、S3の標準的な動作として捉えられていることが多いと思います。

「強力な書き込み後の読み取り整合性」

　今回発表された「強力な書き込み後の読み取り整合性」です。オブジェクトの上書きや削除の直後にも読み込みの整合性が保証されるようになりました。

　ちなみに短いプレゼンの中で、「書き込み後の読み取り整合性」や「強力な書き込み後の読み取り整合性」を連発するのは辛いものがありました。舌噛みそうなのと、自分で何言っているのか解らなくなってきます。

結果整合性と「書き込み後の読み込み」整合性と「強力な書き込み後の読み取り整合性」のまとめ

　これらのS3の進化をまとめると、次の表のようになります。基幹となるサービスを着実に進化させてきているところに、AWSの底力を感じられますね。

S3のプレフィックスと性能の話

　次にS3のプレフィックスと性能の話です。S3は、秒間のGetやPostなどの性能設定がされていることは割と知られています。しかし、正確にはプレフィックスごとの秒間の設定という条件があります。

　この条件があるので、昔のAWSのベストプラクティスでは、プレフィックスの先頭にランダムな値をつけて分散させましょうというのがありました。S3のデータ配置のアルゴリズムと深い関係があるのでしょうね。

　しかし、2018年のサービスアップデートでS3の基礎的な性能が大幅に向上したので、今ではほぼ無用の長物と化しています。しかし、今でもこのような設計の命名規則が残っていることも多く、最近の若者からしたら謎設計になっていると思います。というような話をしていました。

　勘違いがないように補足しておくと、現在でもプレフィックスごとの性能設定というのは現状でも同じで、単に上限値が上がっているので不要なケースが増えているということです。

比較優位の話

　こんなことがあるので、AWSの知識は常にアップデートが必要なことと、それを一人でやるのは無理という話をしました。そのためには、みんなでアウトプットしましょうと。ただ、うちのグループ内って、スーパーマンみたいなに何をやっても凄い人が、まれによくいます。そんな人たちを見ていると、自分がアウトプットする必要ないじゃんというマインドになりがちになります。
　そんなことないですよ。みんなアウトプットしましょうということで、リカードさんの比較優位の話を軽く紹介しています。

　時間の関係もあり、超絶端折ったスライドで煙に巻いている感もありますが、詳しい話はこちらをご参照ください。

ja.wikipedia.org

まとめ

　オンライン開催なのでよく解らなかったのですが、数百人規模の参加者がいたようです。CommentScreenによるコメントも活発で盛り上がってよかったです。また、これらの会が若手主体で、発表者も１〜２年目の人も多かったです。勢いを感じられるイベントで良かったなと思います

AWSのマルチアカウント管理ことはじめ ログインの一元化の設計

　日本のAWSのAPN Ambassadorが集まって作り上げるJapan APN Ambassador Advent Calendar 2020の初日です。佐々木の方からは、最近の関心事項であるマルチアカウント管理の中から、認証（ログイン）の一元化の設計について考えてみましょう。

マルチアカウント管理における認証（ログイン）の一元化の必要性

　AWSを本格的に使い始めるとすぐに直面するのが、利用するAWSアカウントの増大です。AWSのお勧めのプラクティスの一つとして、用途ごとにAWSアカウントを使い分けてリスクを下げるというのがあります。本番環境と開発環境が同居しているより、分離した上で使えるユーザーを役割ごとに限定した方がリスクを下げることができますよね。一方で、プロジェクトごと・環境ごとにAWSアカウントを分離していくとすぐに10や20のアカウントになってしまいます。その時に第一の課題となるのが、IAMユーザーの問題です。

　AWSアカウントごとにIAMユーザーを作っていくと、ユーザーごとにIAMユーザーのIDとパスワードが10個も20個もできてきます。さらにAWSに携わる人が数十人いたら、数百のオーダーのID管理が必要となります。これを個々のユーザー任せで適切に管理することができるでしょうか？なかなか難しいのが現状で、放っておくと全部同じID・パスワードで運用されるといったことも発生しうるでしょう。そこで、必要になってくるのが認証（ログイン）の一元管理です。

認証の一元化のデザインパターン

認証の一元管理にも、AWSの機能のみで管理するパターンやサードパーティのツールを駆使するパターンなど幾つかあります。代表的なパターンを幾つかみていきましょう。

踏み台AWSアカウントパターン

　一番お手軽なのが踏み台AWSアカウントパターンです。踏み台となるAWSアカウントのみにIAMユーザーを発行し、後はクロスアカウントのスイッチロールでスイッチしていくパターンです。

　このパターンは、踏み台となる一つのAWSアカウントのみにIAMユーザーを発行し、他のAWSアカウントにはIAMロールのみ発行します。踏み台にログイン後にスイッチロールを利用してそれぞれのAWSアカウントを利用します。スイッチされる側のIAMロールで、スイッチできるIAMユーザーを制限できるので各アカウント側で権限の制御ができるのがポイントです。また、このパターンだとAWS Organizationsで管理外のものでも簡単に利用できるというメリットもあります。ただし、スイッチ先の各アカウントでCLIを利用したい場合は、一工夫が必要となります。
　なお、このパターン名は、私が勝手に名付けているだけです。

サードパーティのIdP（Identity Provider）を利用するパターン

　次に紹介するパターンは、ある意味王道であるサードパーティのIdP（Identity Provider）を利用するパターンです。IdPは認証部分を専用のシステムに委託し、認証した結果を受け取ってAWSアカウントの利用を許可するパターンです。IdPを利用するとAWS側でID/パスワードの管理が不要になります。代表的なIdPとしては、Microsoft Active Directory（AD）やGoogle Workspace（旧G Suite）,Okta,OneLoginなどがあります。

　IdPを利用するパターンも、AWS部分はIAMロールを使います。そのため、踏み台AWSアカウントパターンと構成的には大きく違わないように見えます。しかし、ポイントはAWSアカウント内に一切IDとパスワードを持つ必要がない点にあります。AWSを使うような組織は、AWS以外にも様々なシステムを利用し、ID/パスワードを管理する必要があります。そこにAWSのID管理を統合できるのは大きなメリットです。一方で、踏み台AWSアカウントパターン同様にCLIを利用したい場合は一工夫が必要です。

AWS SSOを利用するパターン

　3つ目のパターンとしては、AWS SSO（AWS Single Sign-On）です。AWS SSOは、その名の通りマルチアカウントでのAWS運用を想定したサービスです。AWS SSO用のログイン画面があり、ログイン後に自身が利用できるAWSアカウントを選択できるようになっています。

　構成的には、IdPパターンと大きく変わりませんが、メリットは幾つかあります。そのうちの１つが、SSOから利用しているユーザーもCLI（v2）が使えることです。もう一つは、アクセス権限セットという機能を使って、複数アカウントのアクセス権限を一元管理できることです。ただし、SSOの利用はAWS Organizationsが前提となります。それにしても、これいいじゃんってなりますよね。ただ、お勧めの使い方としては別パターンがあるので、SSOのアクセス権限セットを説明の後で紹介したいと思います。

AWS SSOのアクセス権限セット

　先程紹介したどのパターンでも、IAMロールが肝になっているのが解るでしょうか？認証の一元化はできても、どの機能が使えるかという認可の部分については各アカウントに設定されたIAMロールに依存することになります。そのため、個々のアカウントにIAMロールを設定していくという作業が必要になります。AWS OrganizationsとCloudFormation StackSetsを使えばこの辺りの作業もだいぶ楽にはなりますが、一元管理とは少し遠い世界です。
　そこで登場するのがAWS SSOのアクセス権限セットです。アクセス権限セットはユーザーごとのアクセス権限を一元管理する仕組みです。SSOを設定するOrganizationsの管理アカウント（旧マスターアカウント）で定義します。アクセス権限セットと呼ばれるポリシーを作成し、ユーザーがどの権限を利用できるかを紐付けます。管理者の操作としてはこれだけなのですが、アクセス権限セットの良いところは、裏で対象のAWSアカウントの方に、アクセス権限セットと対応するIAMロールを作っているということです。まさしく一元管理！！

お勧めのデザインパターン IdP + AWS SSO

　アクセス権限セットとCLI対応の2点でAWS SSOがお勧めです。一方で、いろいろな現場でSSOを紹介しても、やっぱり既存のIdPを使いたいというケースが多いです。やっぱりIDの二重管理は嫌ですもんね。そんな時にお勧めがIdP + AWS SSOというパターンです

　構成としては、ユーザーはIdPでまず認証します。認証後にAWS SSOのポータル画面に移動します。そして、任意のAWSアカウントに移動するというパターンです。画面遷移が一つ増えるという手間が増えますが、このパターンには大きなメリットがあります

• ID管理をAWS以外も含めて一元化できる
• 認証（IdP）と認可（アクセス権限）を明示的に分離できる
• AWS SSOの機能が100%利用できる
• 今後AWS SSOの機能が増えてもグヌヌとならない

まとめ

　AWSのマルチアカウント管理については、踏み台AWSアカウントあたりから始める人が多いのではと思います。コストも掛からないので、それで充分な場合も多いです。一方で大規模になると辛くなるということもあります。そんな際の参考になれればなと思います。
　じつはこの辺の話をAWSの薄い本Ⅲとしてまとめようと思いつつ、はや半年が過ぎました。１行もかけていません。年内に執筆在庫を一層して、年初あたりから取りかかれればと思っておりますので、生暖かい目で見守ってください。また、AWS SSOを使う上では、Organizationsが必須となります。請求代行使っててOrganizations使えないよという方は、Organizations対応の支払い代行とかしているところを検討するといいんじゃないかなと思います。（ステマ）
　今回は論理設計の話が中心だったので、もう少し具体的な話を今後紹介していきます。乞うご期待！！

www.nri-net.com

booth.pm

booth.pm

S3のマイナー機能の四天王候補の一つであるS3 オブジェクトロックの機能について

　Amazon S3の正式名称は、Amazon Simple Storage Serviceです。Simpleを辞書で紐解くと、次のような言葉が出てきます。

1. 易しい、難しくない
2. 簡素な、簡略した、シンプルな
3. 質素な、地味な、豪華でない
4. 単一の、一つだけで構成される
5. 単純な、複雑でない
6. 〔人が〕気取らない、控えめな、見えを張らない
7. 〈軽蔑的〉〔知的レベルが〕単純な、ばかな
8. 〈軽蔑的〉教養がない、無知な
9. 〔人が〕素朴な、洗練されていない
10. 〔人が〕真面目な、誠実な、うそをつかない
11. 普通の、いつもの、ありふれた
12. 基本の、初歩の
13. ささいな、重要でない、つまらない
14. 《植物》単一の◆【対】compound
15. 《化学》〔化合物が〕単純な
16. 《言語学》〔文構造が〕単純な

引用元　英辞郎 on the Web

　AWSの認定試験を受けていると、普段あまり使わないような機能がどんどん出てきて、Simpleってなんだろうと哲学的な気分になります。昔、大阪でインド人がやっているカレー屋で辛そうに食べていたら、インド人に「辛くない〜、辛くな〜い」と励まされた事も思い出されます。シンプルなのかシンプルじゃないのか、辛いのか辛くないかは、人それぞれということですね。

　前置きが長くなりましたが、今回のテーマは、数あるS3の機能の中で一般的な機能要件ではまず使うことがないオブジェクトロックの機能についてです。

S3のオブジェクトロックの概要とそのニーズ

　S3のオブジェクトロックは、雑な言い方をすると指定されていると何があっても変更したり消せなくする機能です。モードによりますが、管理者であっても消せなくなります。何故、そのような機能が求められるのかというと、コンプライアンス対応です。業種・業界によっては、一定期間データを保持し続けないといけないとルールで定められているものがあります。ルールの多くは、データの完全性を求めていて、期間中のデータ変更や削除を防がないといけません。そんな時に、どうしたらいいでしょうか？
　ぱっと思いつくのは、データにアクセスできる場所と人を限定することです。しかし、その場合は期間中のそのデータへのアクセス履歴とともに、データにアクセスできる人の行動履歴を残し続けないといけません。また、履歴データ自体も改ざんされていないことを証明することが必要です。結構、大変ですよね。そこで登場するのがS3のオブジェクトロックの機能です。これはAWSによって、期間中は一切変更・削除できないということを保証する機能です。利用者は、対象データが確かにその設定がされていることだけ確認するだけで良くなります。格段に楽になりますよね。

S3のオブジェクトロックの機能

　S3 オブジェクトロックは、リテンションモードとリーガルホールドの2つを利用できます。どちらか一方を利用することも、両方を利用することも可能です。まずここからして、オブジェクトロックが解らなくなります。順を追って説明します。

リテンションモードの2つのモード

　リテンションとは、保持とか維持するという意味です。オブジェクトを保護しますよという機能ですね。リテンションモードは2つのモードを提供しています。

• ガバナンスモード
• コンプライアンスモード

　ガバナンスモードは、特別なアクセス許可を持つユーザー以外は、オブジェクトのバージョンの上書きや削除、ロック設定を変更することはできません。つまり、限定したユーザーだけは変更・削除できるということです。続いて、コンプライアンスモードは、AWSアカウントのルートユーザーを含めて、指定期間中は対象のオブジェクトのバージョンを上書きまたは削除、ロック設定の変更をすることはできません。結構強烈な機能ですね。

保持期間

　リテンションモードには、保持期間が設定されます。これはバケット単位で○○日までというような設定ではなく、オブジェクト単位に何日保持するかというような指定です。例えば、ルールで1年間保持しないといけないのであれば、365日と指定します。

リーガルホールド

　オブジェクトロックは、リテンションモードとは別にリーガルホールドというオブジェクトを保護する仕組みがあります。リテンションモードとの違いは、保持期間がないという点です。削除するためには、リーガルホールドの適用を解除する必要があり、s3:PutObjectLegalHold を持つユーザーがその設定をできます。つまりS3のFullAccessをもっていると、リーガルホールド対象のオブジェクトは直接は消せないけど、ひと手間掛けると消せるということになります。リテンションモードよりは少し弱い保護となります。

リテンションモードとリーガルホールドの組み合わせ

　さて、ここからが地獄です。リテンションモードとリーガルホールドは何故か排他の設定ではなく組み合わせることができます。設定のパターンとしては、以下のパターンが可能です。

• オブジェクトロックなし（デフォルトの状態）
• リテンションモードのガバナンスモード
• リテンションモードのコンプライアンスモード
• リーガルホールド
• リーガルホールドかつリテンションモードのガバナンスモード
• リーガルホールドかつリテンションモードのコンプライアンスモード

　AWSの認定試験でここまで問われることは無いと信じています。ただ、オブジェクトロック機能がリテンションモードとリーガルホールドの2つの機能があることと、それの違いを理解していないと混乱するでしょう。事実、試験のたびにどうだったかなぁと頭を悩まします。

オブジェクトロックを利用する方法

　オブジェクトロックの概要はだいたい理解できたかと思います。それでは、実際にどう設定すればいいのでしょうか？たぶんこの記事を読んでいる人の9割8分3厘は実際に設定することがないと思いますので、詳細は省きます。下記の2点が必要という事を覚えておいてください。

• バケット設定でオブジェクトロックの有効化
• オブジェクト単位で保持期間やリーガルホールドの設定

　バケット設定でオブジェクトロックを有効化して、その後にオブジェクト単位で設定していくという流れです。注意点としては、バケット設定で有効化するには新規作成のバケットのみで指定できるという点です。既存のバケットに対しては、サポートにお願いすると有効化してくれそうな雰囲気ですが、試したことはないです。またオブジェクトロックを利用する場合は、バージョニング設定が必須となります。

デフォルトの保持設定

　先程、バケットでオブジェクトロックを有効化されても、オブジェクト単位で指定する必要があると説明しました。いやいや、それは面倒くさいという人のために、デフォルトの保持期間が設定可能です。なお、画面コンソールから指定できるのは、リテンションモードのみです。

オブジェクトロックされたファイルの消し方

　最後にオブジェクトロックされたファイルの消し方をまとめておきましょう

• リテンションモードのガバナンスモード

　　保持期間明けまで待ってから削除
　　特別なアクセス許可を持つユーザーでガバナンスモードを解除してからオブジェクトを削除

• リテンションモードのコンプライアンスモード

　　保持期間明けまで待ってから削除

• リーガルホールド

　　IAMで権限を持つユーザーでリーガルホールドを解除してからオブジェクトを削除

　リテンションモードとリーガルホールドは併用できるので、その場合はそれぞれの条件を満たす必要があります。こうやってみると、リテンションモードのコンプライアンスモードの制約の大きさが解りますね。退職前にコンプライアンスモードの設定で保持期間をこっそり10年とか指定するのは、テロに等しいのでやめましょうね。

まとめ

　S3のマイナー機能の四天王候補の一つであるオブジェクトロック機能です。機能を知ると、よく考えられているなぁと感心します。ただ、ここまで求められる要件がでてくるのは、ごく一部の業界のみで大半の人は使わずに終わるのではないかなぁと思います。そんな業界に飛び込んだあなたは、ラッキーと思ってドヤ顔で使いましょう。私は、残りの四天王の３つを探す旅にでることとします

AWS認定資格試験テキスト　AWS認定 ソリューションアーキテクト-アソシエイト