プログラマでありたい

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

「Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド」を読みました

 著者の西谷さんAmazon Web Servicesを使ったサーバーレスアプリケーション開発ガイドを頂いたので読みました。予想以上に丁寧に書いていて、これから本格的にサーバレスアプリの開発をしようとしようという方には、非常にお勧めです。

サーバーレスアプリを取り巻く現状



 最近ではサーバレスという概念自体はだいぶ広まっているのですが、すぐに作れるという部分のみにフォーカスしていることが多いです。解説されている内容も、設計手法というよりサービスの紹介と使いかた、或いはコードの書き方というのが多いです。結果として、どうなっているかというと取り敢えず動くけど、何か問題が起きた時に原因が解らない、対処の方法が解らないということが多いです。また、作った人しか全容を把握していなくて、担当者の異動や転職でニッチもサッチもいかなくなる事態というのを何度か見てきました。

サーバーレスアプリをチームで開発するためには



 じゃぁ、どうすれば良いのか。個人的な見解としては、サーバーレスアプリも個人ではなくチームで開発するための体制を作るべきです。その為には何が必要かというと、標準的な考え方や開発手法です。実はこの部分について、AWSは色々なものを用意しています。例えば、アプリケーションを定義するモデルであるAWS Serverless Application Model (AWS SAM)であったり、フレームワークであるServerLesss Expressがあります。また継続的なビルド・デプロイを可能にするCodePiplineやCodeCommit,CodeBuild,CodeDeployなどもあります。ブラックボックスになりがちな実行状況については、CloudWatchやX-Rayで追跡可能です。
 これらをどうやって使っていけば良いのか、包括的に解説しているのが本書となります。

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイドの構成



 7章構成となっています。

1章 サーバーレスアプリケーションの概要
2章 Amazon Web Services(AWS)利用の準備
3章 インフラを自動化しよう
4章 Twitterのリアルタイム分析をしよう
5章 写真投稿サイトをシングルページアプリケーションで作ろう
6章 サーバーレスアプリケーションのライフサイクル管理
7章 サーバーレスアプリケーションのトラブルシューティング

 1,2章が概要説明と準備、3〜5章が実践編、6章が運用を見据えてどのように管理をしないといけないのか、7章が障害発生時にどう対処するのかといった内容です。個人的には6章の部分で、SAMや複数環境の利用、CI/CDについてしっかりと解説しているところがポイントが高いです。作ることを優先して、この辺りをおざなりにすることが多いので、少なくとも一度は読んでどうすべきなのかを把握しておくとよいと思います。

本書の特徴



章立ての他に、本書にはもう一つ特徴があります。画面の操作は最小限に、出来るだけコマンドラインで実行している点です。画面が少ない理由としては、AWSのUIは頻繁に変わるのでその対策だと思います。また、それを除いたとしても、実際の開発の現場ではコード固めて画面からアップしてという形ではなく、コマンドからデプロイするという方法に落ち着くと思います。そのあたりを考慮すると、かなり実践的な使いかたに即してよいのではと思います。

感想



 おっさん視点なので、どうしてもサーバレスアプリを継続的に開発できるチームはどう作るかという視点で読んでしまいました。ここで書かれている手法は、もちろんチームではなく個人でも有効です。むしろ、まず個人として身につける内容です。そういった意味で、非常によい本だなと思います。
 ハンズオン形式で実際に作りながら学ぶという形式なので、ここに書かれている内容を全てやりとげれば、現状のサーバレス開発の現場であれば、非常に重宝されると思います。ぜひぜひ挑戦してみてください。
※実は私も、まだ読みながら手を動かしていないので、時間見つけてやります

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド


以下、目次です

目次



Chapter1 サーバーレスアプリケーションの概要
1-1 サーバーレスアプリケーションとは
1-2 ユースケースとアーキテクチャパターン
1-3 サーバーレスアプリケーションのライフサイクル管理概要

Chapter2 Amazon Web Services(AWS)利用の準備
2-1 AWSアカウントの取得
2-2 AWSにおける認証と認可について
2-3 リージョンの選択
2-4 AWS Command Line Interface(AWS CLI)の準備

Chapter3 インフラを自動化しよう
3-1 Amazon CloudWatchのアラームをトリガーに自動処理をする
3-2 Webサイトの状態を定期的にチェックする

Chapter4 Twitterのリアルタイム分析をしよう
4-1 Amazon Kinesisを使ってTwitterのデータを受け取る
4-2 AWS Lambdaを使ってストリーミングデータをAmazon DynamoDBへ保存する

Chapter5 写真投稿サイトをシングルページアプリケーションで作ろう
5-1 Webサイトの概要を確認する
5-2 バックエンドのAPIを実装する
5-3 フロントエンドを実装する
5-4 Amazon Cognitoを利用した認証処理を追加する
5-5 Amazon Rekognitionを使って自動タグづけを行う

Chapter6 サーバーレスアプリケーションのライフサイクル管理
6-1 AWS Serverless Application Model(AWS SAM)詳細
6-2 複数環境の管理
6-3 デリバリプロセスの自動化(CI/CD)

Chapter7 サーバーレスアプリケーションのトラブルシューティング
7-1 メトリクスのモニタリング
7-2 AWS X-Rayを利用したトラブルシューティング

まとめ


クラウドエンジニア養成読本を書きました

 ご報告遅くなりましたが、技術評論社から出版中のクラウドエンジニア養成読本の執筆に参加させていただきました。この本は、AWS, Azure, GCPという3大クラウドを取り扱うという意欲的な企画で、それぞれの分野の第一人者の方々が執筆されています。その中の末席に加えて頂けたこと、大変光栄です。

マルチクラウド


 私は、特集1の「ゼロから学ぶクラウドの世界 〜クラウドの現在、そして未来はどうなる?」という部分を担当しました。導入的な部分で、クラウドを取り巻く現状、主要ベンダーとその位置付け、最近の潮流、さらにはエンジニアはクラウドとどう向かい合うのかということをつらつらと書いています。
 その中のひとつのキーワードとして、マルチクラウド化を挙げています。マルチクラウドというと、何を持ってと宗教論争が起きるので、ここでの言葉の定義は2つ以上のクラウドを使っていたらマルチクラウドとざっくりしたものとしています。

f:id:dkfj:20180322072148p:plain

 マルチクラウド化の必然については、後述するコンテナ・サーバレスという2つの潮流の中で、クラウド間の可搬性がより高まることが予想されます。そうなると、企業としては、サービスごとに一番良いものを使い分けていくという方向になります。そんな未来がテーマの一つにしています。

コンテナ化とサーバレスアーキテクチャ


 先程のマルチクラウド化の論拠は、コンテナ化とサーバレス・アーキテクチャだと言いました。この2つは、システム・アプリケーションの可搬性を高めます。どちらも上手く作れば、動くプラットフォームはなんでもよくなります。そうなると、特定のクラウドサービスに拘る理由が少なくなってきます。実際、AWSをメインで使っているものの、コンテナ部分についてはKubernetesが便利なのでGCPを使っているという話をよく聞きました。
 コンテナ・サーバレス以外にもAI・機械学習・ビッグデータに関わるようなサービスについては、既に併用しているというケースは多いのではないでしょうか?GCP使ったことないと言いつつ、Big Queryだけ使ったことある人多いですよね。

成長戦略


 じゃぁ、マルチクラウドが進む中で、エンジニアはどうすれば良いのでしょうか?全てのクラウドを学んでいく?私の意見として、それは現実的ではないと思っています。個人として、複数のクラウドを習熟するのは困難ですし、たとえ組織としてもかなり大規模な組織ではないと難しいのではないかと考えています。
 では、取るべき道はどうすれば良いのでしょうか?私は、T型のアーキテクトか、特定のレイヤーに特化のどちらかだと思います。

 まずT型のアーキテクトです。下の下手な字にあるとおり、特定のクラウドに習熟した上で、他のクラウドについても、ある程度抑えるという方向です。

f:id:dkfj:20180322072108p:plain

 これに対して、特定レイヤー特化型は、ネットワークやコンテナ、サーバレスなどレイヤーを絞って、複数のクラウドサービスに習熟するという方向です。

f:id:dkfj:20180322072137p:plain

 私自身としては、T型です。特定レイヤーについては、もう少し余裕があれば手を伸ばしたいところです。取り組むとしたら、主戦場であるコンテナ・サーバレスではなく、今までの経験が活きる認証認可の分野かなと思っています。

まとめ


 他の方の執筆内容については言及できませんでしたが、かなり面白いです。同僚の石川によるサーバレスで構築するシングルページアプリケーション&バックエンドや、ソラコム松井さんのIoT、ハンズラボさんのクラウド移行話など、読み応えたっぷりです。
 余談ですが、最近だしたAWS関係本がAmazonのクラウドランキングに3つ並んで、ちょっと嬉しいです。

f:id:dkfj:20180322064951j:plain

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

  • 作者: 佐々木拓郎,西谷圭介,福井厚,寳野雄太,金子亨,廣瀬一海,菊池修治,松井基勝,田部井一成,吉田裕貴,石川修,竹林信哉
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/03/14
  • メディア: 単行本
  • この商品を含むブログを見る

AWSのアクセスキー・シークレットアクセスキーをプログラムに安全に埋め込む(埋め込まない)方法

 AWSでやらかす系の事故で、もっとも恐ろしいものの一つに、アクセスキー・シークレットアクセスキーの流出があります。これは、多くの場合プログラム中にアクセスキー・シークレットアクセスキーを埋め込んだままGitHub等の公開リポジトリに登録することで起こります。GitHubを監視しているBotがカモを待ち受けているので、キーを発見するやいなや不正利用して可能な限りのインスタンスを立ち上げます。そして、BitCoin等の採掘などに利用します。気が付かないと、一晩で100万円近くの請求という話もあったようです。

 

AWSのアクセスキーの流出を防ぐ方法


 このアクセスキーの流出は、AWSの仕組みを知っていると、ほぼ被害は防げます。という事、基本的な部分をおさらいしましょう。アクセスキーではなく、IAMロールを使うというのが基本ですが、どうしても使わざるをえない場合は、下記のルールを守ってください。

 

 守るべきシンプルなルールは、たったの一つです。

 

AWSのアクセスキーは、プログラムに直接書き込まない。環境変数から読み込む

 

 この環境変数というところがミソで、実はAWSのSDK,CLIは特定の環境変数名を自動で読み込むようになっています。アクセスキーは、AWS_ACCESS_KEY_IDで、シークレットアクセスキーは、AWS_SECRET_ACCESS_KEYです。

Linuxの設定例
export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key

 

Windowsの設定例
set AWS_ACCESS_KEY_ID=your_access_key_id
set AWS_SECRET_ACCESS_KEY=your_secret_access_key

 

AWSの認証情報の検索順


  この辺りの情報は、AWSの認証情報の検索順等で検索すると出てきます。例えばRubyの例だと次のように定義されています。

 

AWS SDK for Ruby は、次の手順で認証情報を検索します。

 

1. クライアントオブジェクト内で認証情報を設定する

2. Aws.config を使用して認証情報を設定する

3. 環境変数を使用して認証情報を設定する

4. 共有認証情報の設定

5. IAM を使用して認証情報を設定する

 

 

 言語によっては多少違いますが、優先順位や設定可能項目は概ね同じです。つまりプログラムで設定したものが最優先で、次に環境変数系、最後にIAMロールという順です。

 

AWSのアクセスキー運用のベスト・プラクティス


 

 上記の最低限のルールの他に、下記のようなアクセスキーの運用を守ってください。いわゆるベストプラクティスの一部です。

 

- AWSサイドで利用する場合は、IAMロールを利用し、アクセスキーを利用しない

- アクセスキーを使う場合は、該当のIAMユーザには最小権限を付与する

- 可能な限りIPアドレスで絞る

- git-secretsを利用して、誤操作時に気付けるようにする

- Assume Roleを利用して、一時的なアクセスキーを利用すると、なお良い

 

 ただし、初めての人にこれ全部最初にやれというのも現実的ではないので、最低限守っておくべきというのが最初に説明したプログラムに埋め込まないという対応になります。

 

まとめ 


 実務的な部分では、もっと考慮しないといけない部分は沢山あります。ただ、手始めにローカルで試す場合、最低限この方法を守っていれば危険を回避します。本当は、サーバーサイドでロール使ってが良いですが、環境面の制約があり、キーを使わざるをえない場合の話です。

 こういった話も、3/23発売の改定第2版 Amazon Web Services パターン別構築・運用ガイドにまとめています。転ばぬ先の杖として、ぜひご活用ください。

 

Amazon Web Services パターン別構築・運用ガイド 改訂第2版

Amazon Web Services パターン別構築・運用ガイド 改訂第2版

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/03/23
  • メディア: 単行本
  • この商品を含むブログを見る
 

 

 

 

Amazon Web Services パターン別構築・運用ガイドの改訂第2版が出ました

 2015年3月に出した「Amazon Web Services パターン別構築・運用ガイド」の改訂を行い第2版として新しい本になりました。

Amazon Web Services パターン別構築・運用ガイド 改訂第2版

Amazon Web Services パターン別構築・運用ガイド


 パターン別構築・運用ガイドはAWSの分厚い本という愛称のもと、なかなかの人気を誇ってきました。AWSの基本的なサービスであるEC2, S3, VPCを中心にアカウントの作り方から、SDK,CLIの使い方、EBSとスナップショット、AMIの作り方などを丁寧に説明しています。また、作るだけでなく、運用監視やセキュリティについても、それぞれ章を取って取り扱っています。内容的には、AWSの認定試験であるソリューションエンジニア・アソシエイトの内容をかなりカバーしているのではないでしょうか。
 なお、本書と今年1月に出したAmazon Web Services 業務システム設計・移行ガイドは、扱ってる技術的には似ています。一方で、この本はあくまで個々のエンジニアがどうAWSを使うかがテーマであり、業務システム本は組織を主題に書かれています。その為、章立て・取り扱いサービスは似ているものの、中身は随分と違うものになっています。是非、読み比べてみて下さい

改訂の箇所


 改訂版を出してということなので、改めて読み直しました。出版後、丸3年を迎えようとしていたのですが、EC2,S3,VPCなど基本的な機能を取り扱っている為に、そこまで大きな変更を必要としない内容でした。そこで細かいサービスのアップデートを反映すると共に、前回では機能が無くてサードパーティのツールを使っていた部分についての修正を加えました。例えば、下記のような例です。

継続的な脆弱性診断 ⇒ Amazon Inspector
定期的なジョブ実行 ⇒ CloudWatch Events + Lambda
サーバレスな2Tierアーキテクチャ ⇒ API Gateway + Lambda
WAF機能 ⇒ AWS WAF

 これらを見ていると、足りない機能を足していってAWSのみでサービスが完結できるようになってきているのが解るのでは無いでしょうか。あとは、アクセスキー周りの事故が多いので、プログラムに安全に埋め込む(埋め込まない)方法を指南しています。ここは是非読んで欲しいです。

電子書籍版で買われた方へ


 たぶん前作を電子書籍版で買われた方は、アップデートすることが出来ます。書籍を一意に示すISBNは違うものになっているので、別書籍扱いになるために単純アップデートはできません。ただサポート経由等でアップデートできると思うので、発売後にやり方確認してまた案内しようと思います。

感想


 前作は、5刷で電子書籍を合わせて1万部を大きく超える売れ行きでした。今作も3年間くらい売れ続けてくれればなぁと思います。そして、また3年後に、また機能の差分を振り返れればなぁと思います。

Amazon Web Services パターン別構築・運用ガイド 改訂第2版

Amazon Web Services パターン別構築・運用ガイド 改訂第2版

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/03/23
  • メディア: 単行本
  • この商品を含むブログを見る

Amazon Web Services 業務システム設計・移行ガイドの増刷決定しました

2018年1月20日発売のAmazon Web Services 業務システム設計・移行ガイド ですが、発売3週間で増刷決定しました。ありがとうございます!!

本書のターゲット


 本書のターゲットは、企業内でAWSを構築・運用する立場の人、或いはその導入を支援するSIerで働く人を対象に書かれています。レベル的には、初心者ならびに初心者を脱して中級者を目指す人を想定しています。まぁ下のポップの金澤さんの意気込みどおりです。私は、とにかく楽したいしか頭にありません。

f:id:dkfj:20180129194052j:plain

売れ行きの推移


 ネット上でのレビューなどが、まだあまり出ていないので地味です。しかし、なかなか堅調な売れ行きで、Amazonでの売り行き推移も手堅いです。
f:id:dkfj:20180208072620p:plain

 書店巡りしていても、結構手に取ってパラパラめくってくれている人を目にするので、関心が多い分野なのかもしれません。手に取った人は、そのまま買ってくれても良くてですよ。

増刷にあたり


 今回の増刷にあたっては、大きな修正はしません。誤字脱字を修正するくらいです。後は巻末のプロフィールにそれぞれどこの執筆担当だったのかを書こうかなと考えています。Kindle版で購入している方は、最新化できるので是非してみてください。

感想


 著者にとって、増刷ほど嬉しい言葉はありません。何故なら、何もしなくても印税が入るからです。自分達が書いたものが、世の人に必要とされていたということの証左だからです。仕事しながら執筆するのは、なかなか大変なところもありますが、もう少し頑張ります。とりあえず今は、Amazon Web Services パターン別構築・運用ガイド 改訂第2版を書いています。

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

iPad Pro + Smart Keyboard + Apple Pencilを 買いました

 執筆用のMacBook Air (Early 2014)のバッテリーがへたってきました。また、元々Retina対応ではないので、原稿の校正の時にPDFを見ようとしても拡大しないと見えないという問題がありました。年末くらいから悩んでいたのですが、iPad Pro(10.5インチ) + Smart Keyboard + Apple Pencilを買いました。

 

f:id:dkfj:20180129235149j:image

 

iPad Proを選んだ理由


 Macbookの買い替えでなく、iPad Proを選んだ理由はApple Pencilの存在です。プライベートの趣味である執筆活動の関係で、PDFになった原稿に赤入れする機会が多いです。現状、Macのプレビューの編集機能を使っているのですが、正直面倒くさいです。これ手書きでやりたいなぁということでiPad Proにしました。

 それ以上に、iPad Proでどこまでパソコンの代替になるか試してみたいという気持ちが強かったのも事実です。 

iPad Proにして良かった点

  Smart Keyboardの使い易さは、予想以上でした。過去、iPhone, iPad用のキーボードを3〜4個くらい買いましたが、まぁソフトウェアキーボードよりましかな程度でした。しかし、iPad Pro用のSmart Keyboardは、パソコンのキーボードとほぼ遜色がないレベルです。タブやコピー&ペーストをキーボード操作で実現できるのは、やっぱり楽です。※価格は、遜色がないレベルではなく、REALFORCE/Happy Hacking Keyboardレベルですが。。。

 Apple Pencilについても、手書き用途としては全く問題ないレベルです。私の汚い字を、ちゃんと再現してくれます。また、細かいタッチを微妙に補正する機能もあるようで、ハードとソフト面でいろいろ工夫しているのだなと垣間見れます。

 

f:id:dkfj:20180129233422p:image

 

 あとは、持ち運びやすさもいいですね。今回の選定基準の一つに、常にカバンに入れていても負荷が小さいというのもいれていました。今のところ、全く気にならないレベルです。

 

iPad Proで困っているところ


 逆にiPad Proで困っている点、つまりはMacbookより使い難い点をあげると沢山あります。入力一つにしても、悩むところは多いです。例えば、全角の空白をどう入れるかとか、行の先頭の英単語を勝手にに大文字にされるとか。それ以上に大きいのが、各アプリ側の対応。例えば、この記事は、はてなブログアプリで書いています。最低限の機能はあるものの、PC版の機能のフルセットではありません。結局、ブラウザの方を利用に切り替えたのですが、それでもスクロールにあわせた右の補助メニューの追付いのように、PCで出来ていることが実現できないことが多々あります。

 これは、Appleの問題というより各社の対応状況の問題です。利用者数から考えると、当面は解決の見込みはないでしょう。

 

これから試したいこと


 いろいろ不便なところがあるというのは、まぁ予想の範疇です。でも折角なので、iPad Proでしか出来ない使い方をいろいろ試してみようかなと思います。もともとMacbookも併用するというのは既定路線なので。Apple Pencilの活用以外としては、例えば音声入力ですかねぇ。

 

感想


 とりあえず半年後の自分への備忘録として書いてみました。1ヶ月、2ヶ月と使っていって、どう変わっていくか乞うご期待!!

一方で、下記については依然として自分の中でも消化できていません。

 

 

 

 

AWSにおけるネットワーク設計の真髄。Amazon Web Services 業務システム設計・移行ガイドにおけるネットワーク章

 早速Amazonで品切れになったAmazon Web Services 業務システム設計・移行ガイド です。個人的に最大の見どころは、4章のネットワーク接続の設計・構築・維持管理ではないかと思っています。

AWSにおけるネットワーク設計


 AWSにおけるネットワークサービスは、VPCを中心にDirect ConnectやRoute53、Internet GatewayやVPN Gateway,Nat Gatewayなど幾つものサービスがあります。ウィザードに沿って設定すると一通りの設定ができるものの、果たしてどのように設定するのがベストな設計なのか、ネットワーク設計の経験がないと難しいものがあります。また、AWSならではというハマりポイントもあるのも事実です。Amazon Web Services 業務システム設計・移行ガイド では、ネットワーク設計に必要な考え方をネットワーク面、AWSの機能面を含めて丁寧に説明しています。

4章のネットワーク接続の設計・構築・維持管理の執筆者


 というのも4章のネットワークに関する部分の執筆者は、NRIにおけるネットワークのスペシャリストである宮川亮さんの手によるものだからです。

パブリッククラウドのネットワーク基盤担当。2012年の東京リージョンへのAWS Direct Connect導入以来、多くのお客様への提案、構築、維持管理に従事。西日本でのリージョン開設やAWS Direct Connect Gatewayの開始によりニーズがさらに高まるのが楽しみ。好きなAWSサービスはもちろんAWS Direct ConnectとAmazon VPC。これからAWS PrivateLinkを好きになる予定。

 Amazonの著者ページにある略歴にあるとおり、2012年のNRIにおけるDirect Connectのサービスの提供以来、ずっとAWSのネットワークに関するサービスの中心にいました。数多くの企業にDirect Connectを提供し、或いはオンプレミスとAWSのネットワーク設計をし続けてきています。AWSのネットワーク設計をした数と規模では、間違いなく日本でも稀有の存在です。
 私も仕事の際には色々助けて貰ったことがあります。今回の執筆でも出来上がった原稿を見て、ネットワークの専門家はこんなことを考えながら設計するものなのだと、随分と勉強になりました。

ネットワーク設計ネタ


この章で取り扱ってるネットワーク設計のネタを幾つかピックアップします

・ダイレクトコネクトか、インターネットVPNか
・セキュリティグループとネットワークACLの使い分けのポイント
・ルーティング設計。BGPによる経路広報も添えて
・名前解決の問題
・インターネットへの出口をどうするか

この中でBGPの話などは、ネット上で情報が少ないので助かります。私もダイレクトコネクトについては、サービスとして提供されてるものを使う方なので、動的な経路設計などにいつも悩みます。その辺りの情報がひとまとめになっているのがありがたいです。

未来を占うコラム


 4章には、3つのコラムがあります。これが特に秀逸で、AWSのサービスに対する考察がなされています。

・「ダイレクトコネクトサービスはどれも同じ」ではない
・Direct Connect Gateway
・VPCエンドポイントの「ゲートウェイ」と「インターフェイス」

 ここは是非、本文読んでみてください。どのコラムも1ページ程度の分量なので、店頭での立ち読みでも直ぐに読めると思います。

まとめ


 身内で褒めるのも何ですが、AWS本でここまでネットワークについて書けている本は少ないと思います。最初の原稿見たときに、少し難しいすぎるかなと思ったものの、まとめて読んでみると全て必要な内容でした。ぜひ手にとって読んで頂きたいものです。

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る


See also:
Amazon Web Services 業務システム設計・移行ガイドの目次
「Amazon Web Services 業務システム設計・移行ガイド」という本を書きました