AWS

Overview

AWS関連やAWSユビキタスについて記載する。

AWS海外展開

AWSはいつでもグローバルにサービスを展開できる。
これはAWSが世界中にデータセンターを保持し、サービス提供に必要な国際的な要件やISO、JISといった各国が決めた規格にAWSのサービスが対応しているため。

オンプレミスだと、海外でサービスを提供する際に現地観察や現地データセンターとの契約などが必要。これは時間と労力のかかる作業。

AWS 開発速度の向上と属人性の排除

AWSでは、すべてのサービスをAPI経由で連携する踈結合なシステムを導入した。
これをマイクロサービスアーキテクチャと呼ぶ。
システムを疎結合状態に保つことで、巨大に成長しても管理しやすいモデルを実現している。
これにより、随時追加されるAWSの新たなサービスの活用を柔軟に行うことも可能となった。AWSでは年間2,000回を超えるバージョンアップや機能改修をデグレードによる障害を引き起こすことなく実施しています。

AWS マネージドサービス

「マネージドサービス」とは、AWSなどのクラウド事業者がインフラの保守や運用をしているクラウドサービスを指します。

オンプレミスでは、システム構築後は開発チームと運用チームに分かれて管理するケースがあり、各チームの責任範囲が曖昧になることがある。 そこでAWSは、開発チームが「提供するシステム全体の責任を持つ」ことが望ましいと考えた。
そして、AWSは開発チームの運用負荷を軽減するために、サーバーレス、フルマネージドなサービスを提供するようになった。

AWS Well-Architected フレームワーク

AWSを利用する上では、さまざまな課題に直面する。
とくにノウハウが蓄積されるまでの間は試行錯誤の繰り返しになる。
とはいえ、何も知らずに0からスタートするのは大きなリスクを伴う。
指針となる設計原則があれば、迷いや不安を大きく軽減し、自信を持って信頼性の高いシステムを構築できる。
AWSではそのような問題を解決するための設計原則とベストプラクティスをまとめたAWS Well-Architectedフレームワーク（以降、W-Aと表記。）が公開されている。
これはAWSと利用者が長年の運用で経験した失敗や反省をもとに、同じ失敗を繰り返さないためのノウハウを詰め込んだ集大成ともいうべきドキュメント。
W-Aにしたがって要件定義・設計・構築・運用などさまざまなフェーズでレビューをすることで、サービスや環境の改善に繋げることができます。

AWS Well-Architectedフレームワーク

W-Aは一般的な設計原則と次の6つの柱で構成されている。
一般的な設計原則については次のリンク 一般的な設計原則

AWS Well-Architected フレームワーク 6つの原則

1. 運用上の優秀性(Operational Excellence)

※オペレーショナル・エクセレンスと表記されることもある
システム運用を効率化し、開発のプロセスや手順を継続的に改善することで、利用者はサービスの価値を高めることに集中できる。

• 運用をコードとして実行する
  • AWSでは、Cloudformationというサービスによってインフラ構築をコード化することが可能。本来は煩雑な作業が必要となるインフラ構築を、作成したコードを実行するのみに自動化・省力化でき、人為的なミスを防止できます。
• 小規模かつ可逆的な変更を頻繁に行う
  • 大規模な更新作業は、失敗した時の切り戻しの負担も大きくなり、リスクが高くなります。システムの更新は、顧客影響や切り戻しなどのリスクを抑えるために可能な限り小規模に、定期的に実行するように計画することが求められる。
• 運用手順を定期的に改善する
  • システム運用は定常的になりがちですが、現在の運用手順が常に最適とは限りません。作業者へのヒアリングや、障害対応のシミュレーションを行うなどして定期的に手順を改善したり、手順に対するチームの理解を深めることが重要です。
• 障害を予想する
  • どんなプロジェクトでも、ひとつの障害もなく完了を迎えることはまずないでしょう。運よく何も起きなければいい、などと障害から目を背けて楽観的に運用していくのは、無謀とすら言えます。 プロジェクトをスタートする前に、どんなリスクが潜んでいるのか、どんな障害が発生し得るのか、プロジェクトの終わりから逆算して想像する「プレモータム演習」を実施しましょう。あらかじめリスクを予測して備えを怠らなければ、影響を最小限に留めることができます。
• 運用上のすべての障害から学ぶ
  • システムの運用を行う上で発生する障害は、改善のための大きなインプットとなります。障害が発生したら、今後その障害が発生しないようにシステム構成や手順を改善していくことで、サービスの価値を高めることができる。障害が発生したら担当者を責め立てるのではなくどのように改善していくかに注目してポジティブに対応指定いくことが重要。

2. セキュリティ(Security)

AWSはインターネット上に環境を構築する性質上、常に悪意ある攻撃のリスクに晒されている。
AWSではセキュリティの強化に必要なサービスが多数用意されており、適切に設定することでセキュリティ事故のリスクや影響を低減できる。

• 強力なアイデンティティ基盤の実装
  • アイデンティティとは、ユーザーIDやパスワードなどの識別情報のこと。AWSでは、AWS IAMというサービスによってアイデンティティおよび権限管理を実現する。
  • IAMではAWSリソースに対するアクセスについても権限管理ができますが、業務上必要な権限のみ許可することを推奨している。余分な権限が付与されているということは、不必要な操作を許可しているということであり、予期しない事故を招く恐れがあるためです。
• トレーサビリティの実現
  • トレーサビリティとは、英語の「Trace（追跡）」と「Ability（能力）」を組み合わせた言葉で、日本語に訳すと「追跡可能性」という意味になる。
  • ログやアラームなどを活用し、環境内で起きている事象を把握することは、セキュリティの強化に繋がる。
  • AWSでは、Amazon Cloudwatchというサービスを利用してトレーサビリティの高いリアルタイムな運用監視を実現する。
• 全レイヤーでセキュリティを適用する
  • ここでいうレイヤーとは、ネットワーク・コンピューティング・アプリケーションなどの各層のことを指す。セキュリティは一部のレイヤーだけ強化しても他の脆弱なレイヤーで攻撃を許してしまえば本末転倒になるため、関連するすべてのレイヤーに対して必要充分なセキュリティ対策を実装することが求められる
• セキュリティのベストプラクティスを自動化する
  • ベストプラクティスとは「最善策」という意味。セキュリティ事故の検知を自動化したり、セキュリティ設定を含めたインフラ構築をコード化することで自動化・標準化するなど、ベストプラクティスを適用することが求められます。
• 伝送中および保管中のデータの保護
  • システム運用において、データの保護は重要な課題です。暗号化されていないデータ通信は傍受される可能性がありますし、機密性の高いデータが誰でも容易にアクセスできる状態では漏えいのリスクがあります。暗号化・アクセスコントロール・トークン分割などの技術を用いて、移動中のデータ、保管中のデータを適切に保護しましょう。
• データに人の手を入れない
  • データを手動で処理するということは、それ自体がセキュリティリスクになり得ます。手動操作は、誤操作や認識の誤りによる意図しない変更といったヒューマンエラーの可能性を伴うためです。LambdaやAmazon SQSなどのサービスを活用してデータ処理を自動化することで、ヒューマンエラーによるデータ破損のリスクを低減できます。
• セキュリティイベントに備える
  • ここでいうセキュリティイベントとは、システムを危険にさらす事案のことです。システムが直面し得るセキュリティイベントを想定し、それに対応する検出・調査・復旧のポリシー、プロセスを明確に定義して備えましょう。 また、対応手順は机上で完璧に策定したつもりでも、実際に効果的に運用できるかは不安が残ります。事前にシミュレーションを行って精度とスピードを確認し、改善することが重要です。

3. 信頼性(Reliability)

システムにおける信頼性とは、障害に対する対応力や、需要の変化に適応する柔軟性を表わしています。
信頼性の高い設計とは、障害の発生を抑えこもうするのではなく、障害の発生を前提としてあらかじめ迅速な復旧手順を整備したり、復旧そのものを自動化するなどあらかじめ対策しておくこと。AWSではこのような設計方針を「Design for Failure」（故障のための設計）と表現して推奨している。

• 障害から自動的に復旧する
  • 障害が発生した際に手動で対応するとなると、それだけ復旧は遅くなってしまいます。復旧を自動化する手段はいくつかありますが、とくに重要なのがMulti-AZです。Multi-AZ とは、複数のAZ（アベイラビリティゾーン）にリソースを冗長化する設計のことで、ひとつのAZに障害が発生しても他のAZに配置したリソースでシステムの運用を維持できます。
  • Multi-AZの利点は他の信頼性向上策と比較して非常に費用対効果が高いと言われており、優先的に設定することが推奨されている。たとえば、データベースサービスであるRDSは、Multi-AZ配置を機能として備えています。
• 復旧手順をテストする
  • 復旧手順は事前にテストをしておく必要があります。擬似的に障害を発生させ、正しく復旧できることをテストします。テストをしておかないと実際に障害が発生したときに復旧ができなかったり、誤った手順により別の障害を誘発し二次被害が発生する可能性があります。
• 水平方向にスケールしてワークロード全体の可用性を高める
  • ここでいうスケールとは、性能や台数を増減することを指します。
  • 性能のスケールは1台の性能の高さが伸びるイメージなので「垂直方向」
  • 台数のスケールは同じものが横に並ぶイメージなので「水平方向」
  • AWSでは、システムの信頼性を高めるためには水平方向のスケーリングが重要だと考えています。たとえば、同じ処理を行うとして、処理能力の高いEC2インスタンス一台で処理する場合、その一台に障害が発生したらシステムは停止してしまいますが、複数台のEC2インスタンスに処理を分散することで、1台あたりの障害の影響を低減できます。
• キャパシティーを推測することをやめる
  • ここでいうキャパシティーは、許容量を表します。オンプレミスでは臨機応変なリソース変更が難しいため、必要となるキャパシティーを予測してシステムを設計しますが、予測通りに推移するとは限らないのが現実であり、主な障害発生の原因にキャパシティーオーバーが挙げられます。AWSのようなクラウドサービスでは、需要の変化に対応してリソースの増減が容易なため、設計段階でキャパシティーを予測することは不要になります。
• オートメーションで変更を管理する
  • ここでいうオートメーションとは、インフラ構築の自動化という意味です。インフラ構築を手動で行うことは、効率の観点だけでなく、信頼性の観点からもリスクが高いといえます。データの処理を手動で実施する場合と同様に、構築手順におけるヒューマンエラーの可能性を伴うためです。AWSでは、Cloudformationなどのサービスを活用してコード化することでインフラ構築を自動化でき、変更管理も容易になります

4. パフォーマンス効率(Performance Efficiency)

パフォーマンス効率は、リソースがシステム要件を満たすためにどれだけ効率的に稼働しているかを表します。需要の変化に応じて過不足なくリソースを稼働させ、効率的に運用することが求められます。

• 最新テクノロジーの標準化
  • 開発者としては、本来はサービスの開発に全力を注ぎたいのが本音です。しかし、オンプレミスでは煩雑なインフラ管理や機械学習などの専門性の高い技術についても必要となれば自分達で学習し、業務として取り組まなければなりません。こうした避けられない学習や作業のためにエネルギーを割かざるを得ないということは、チームのパフォーマンスの悪化に繋がります。 AWSでは、基盤となるインフラ管理はAWSの責任となるため、利用者はインフラ管理から解放されます。また、専門性の高い技術を専門知識がない人材でも取り扱いやすいサービスとして提供しているため、最低限の学習コストで導入できます。これらのメリットを活用すれば、思う存分サービス開発に注力できます。
• わずか数分でグローバル展開する
  • 世界各地にある複数のAWSリージョンを利用することで、利用者が最小のコストでサービスをグローバル展開できます。
• サーバーレスアーキテクチャを使用する
  • AWSでは、サーバーを用意せずにさまざまなサービスを利用できるサーバーレスアーキテクチャのサービスが複数存在します。サーバーレスアーキテクチャを利用することで、OSやミドルウェアなどを管理する負担を軽減し、利用者の本来の業務にリソースを集中できます。
• より頻繁に実験する
  • さまざまなシステム構成を容易に準備できるため、異なるタイプのシステム構成に対して簡単にテストや比較検討できます。事前に検証した上で適切なシステム構成を選択できます。
• 適切なアプローチを選択する
  • クラウドサービスの使用方法を理解し、常に最適なアプローチを使用できるよう考慮することが重要です。たとえば、データベースやストレージを使用する場合は、データにアクセスするパターンを精査し、適切なサービスや構成を選択する必要があります。

5. コスト最適化(Cost Optimization)

適正なコストでシステムを運用することで、サービスの価値を高めることができます。

• クラウド財務管理の実装
  • クラウドを利用する上での財務管理は今までにない領域となるため、AWSを利用する組織は時間とリソースを投入する必要があります。セキュリティや運用と同レベルの知識の積み上げを行うことが重要です。
• 消費モデルを導入
  • ビジネス要件に応じて必要なリソースのみ消費できるように構成することが重要です。たとえば、9:00〜18:00のみ利用するシステムであれば、それ以外の時間はサーバーを停止することでコストを削減できます。
• 全体的な効率を測定する
  • システムの利用状況を測定し、生産性の向上やコストの削減状況を把握することが必要です。AWSのサービスを利用してシステムの利用状況を測定できます。
• 差別化につながらないインフラ管理に費用や負担をかけるのをやめる
  • AWSのクラウドサービスやマネージドサービスなどを活用することで、インフラ管理に費用や負担をかけず、利用者の本来の業務に集中できます。
• 費用を分析および属性化する
  • システムの使用状況とコストを、AWSのサービスにて把握できます。利用者はこれらを分析し、リソースを最適化してコストを削減することが可能です。

6. 持続可能性(Sustainability)

2021年に追加された6本目の柱は、地球環境についての提言に関わるものです。 環境問題に配慮したビジネスかどうかに関心を持つ消費者も増えてきており、企業は利益を最大化するだけでなく、環境問題への取り組みをアピールすることでブランド価値を向上できます。システム会社も環境に配慮することは責務となり、コスト最適化とのバランスを考えるべき柱です。 システムのエネルギー消費量を削減し、効率の向上を目的として、ワークロードの設計やアーキテクチャ、実装を評価していくことが求められます。

• 影響を把握する
  • 利用者がシステムに対して行う改善や変更が、持続可能性のために与える影響を正しく測定し、把握することが重要です。
• 持続可能性目標の設定
  • 持続可能性の目標を設定し、目標を達成するためのシステム構成を設計します。
• 使用率の最大化
  • システムやアーキテクチャのサイズを適切に調整し、ハードウェアのエネルギー効率を最大化し、アイドル状態のリソースを最小限に抑えます。 たとえば、2台のハードウェアそれぞれで1台ずつ仮想マシンを運用するよりも、1台のハードウェアで2台を運用する方が、ハードウェアの消費電力や計算に関わるコンピューターリソースの使用率が高くなります。 このように、システム設計の観点をコストだけでなく、エネルギー消費量からアプローチします。
• より効率的な新しいハードウェアとソフトウェアの提供を予測して採用する
  • エアコンや冷蔵庫などの家電と同様に、新しいものほどエネルギー効率は高くなります。ITインフラの設計においても、長期的な視点でエネルギー効率が高いハードウェアやソフトウェアを選択できるように、一部の技術に依存せず、柔軟性を考慮した設計を行うことが重要です。
• マネージドサービスの使用
  • マネージドサービスを使用することで持続可能性を効率的に実現できます。たとえば、重要度の低いバックアップデータをAmazon S3(詳しくは「3-5 Amazon S3」で解説)のライフサイクルポリシーを利用して1ゾーン低頻度アクセスのストレージクラスに移動することで、過剰なリソース消費を避けることができます。
• クラウドワークロードのダウンストリームの影響を軽減
  • クラウドから発信するダウンストリーム(利用者に送信されるデータ)を削減することで、利用者は高性能なデバイスを用意しなくてもシステムを利用できます。たとえば、毎日大容量のファイルを送信するシステムであれば、そのファイルを保存・管理するためのストレージを利用者が用意する必要があります。ダウンストリームを最小限にして必要な情報を都度クラウドで参照するような構成にすれば、利用者は大容量のストレージを保持する必要がなく、結果として環境に配慮した持続可能なアーキテクチャとなる

AWS の基本要素

1. リージョンとアベイラビリティゾーン

AWSは多くのデータセンターで構成されますが、1つまたは複数のデータセンター群をまとめたものをアベイラビリティゾーン(以降、AZと表記)と呼ぶ。
また、リージョンとは地理的に近い位置にある複数のAZをグループ化した単位。

リージョンを選択する際に地理的に近い場所を選択することで通信遅延（レイテンシー）を抑えられる

2. エッジロケーション

AWSでは、リージョンやAZの他に「エッジロケーション」という拠点があります。エッジロケーションはコンテンツ配信を行うための拠点となる設備です。AWSではCloudFrontの拠点として、エッジロケーションが使われます。 コンテンツ配信を行う際は、Webサイト閲覧者から地理的に近い場所から配信したほうがレイテンシーが少なくなります。そのため、AWSでは世界各地にエッジロケーションを設けており、閲覧者に地理的に近い拠点からコンテンツを配信できる仕組みを構築しています。

3. サービスクォータ

AWSにおけるサービスクォータとは、AWSの各種サービスごとに設定できるデフォルトの制約事項です。基本的にはリージョンごとにサービスクォータが設定されていますが、例外となるサービスもあります。 各サービスに応じたサービスクォータの具体的な制限事項は、次のサイトから確認できます。

サービスエンドポイントとクォータ

4. ルートユーザー

AWSアカウントを新規作成に作成される初期ユーザーをルートユーザーと呼びます。 ルートユーザーはAWSアカウントにおいて最も強い権限を持ち、ルートユーザーの削除、権限の変更や制限はできません。 非常に強い権限を持ち、漏えいした場合のリスクが高いため、日々の業務では使用しないことが推奨されています。 通常は、ルートユーザーでログインした後に個別のユーザーを作成し、このユーザーにルートユーザーと同等の権限を付与して運用します。 ルートユーザーアカウントの保護に関するベストプラクティスは以下があります。

1. rootユーザーのアクセスキーをロックするか、可能であれば削除する。
2. 強固なパスワードの使用
3. 多要素認証(MFA)の有効化

AWSのリソース命名規則

命名規則

ケバブケースが推奨（S3のバケット名に大文字とアンダースコアを含めることができないため）

タグ名は？ タグはパスカルケースがオススメ

AWSのコストを削減する方法

AWSのコストを削減する９の方法

AWS セキュリティ

本番環境で実践したいAWSセキュリティのベストプラクティス26選

AWSは高いセキュリティを確保し、利用者の運用負荷を軽減する。

企業のコンプライアンス範囲を最小限にする
コンプライアンスとは「法令遵守」を意味する言葉で、「社会規範」、「社会道徳」、「ステークホルダーの利益」など、組織が遵守すべきことを表す。
企業はシステム導入時、このコンプライアンスを遵守しているかチェックする必要があり、オンプレミスでは、コンプライアンスはすべて利用者の責任で実施する必要があった。
一方、AWSでは、その責任の一部をAWSに委任できる。

AWSのセキュリティ基本コンセプト
AWSには責任共有モデルと呼ばれるセキュリティの基本コンセプトがある。
サービスにより内容は異なりますが、AWSが所有する物理的な環境を保守する責任はAWSが担い、クラウド内に構築したシステムやデータのセキュリティを管理する責任は利用者が担います。この責任共有モデルにより、利用者の運用負荷を軽減できます。

AWS 勉強サイト

AWS Cloud Quest

EIP(Elastic IP)

EIPについて

Elastic IPアドレスは、AWSに登録したアカウントに紐つけされるIPアドレスです。 IPアドレスは基本的にパブリックIPアドレスとプライベートIPアドレスの２つに分けることができ、パブリックIPアドレスはインターネットを通じて機器を利用する際に割り当てられるアドレスで、もっともポピュラーなIPアドレスと言えます。 一方のプライベートIPアドレスはインターネットではなくローカルのネットワークでのみ割り当てられるIPアドレスで、インターネットからは遮断されたIPです。

パブリックIPもプライベートIPもサーバーを再起動すると変更されてしまうという特性を持っているのですが、このElastic IPはサーバーを再起動しても同じIPアドレスを割り当てることができる性質を持っています。

AWSを操作方法種類

• GUI（マネジメントコンソール）
• CLI（AWS CLI）
• SDK（プログラム）

config credentialsを作成する

AWS CLIはaws configureで指定された機密性の高い認証情報をホームディレクトリの .aws という名前のフォルダーにあるcredentialsへ保存する

config aws configureで指定された機密性の低いオプションを保存する cliを使う上での設定を記載したファイル。

credentials aws configureで指定された機密性の高い認証情報を保存する AWSに接続するための認証情報

config credentials

リファレンス

頻繁に利用される構成設定および認証情報をAWS CLIが維持するファイルに保存できる。 CLIは default という名前のプロファイルにある設定を使用する。

名前付きプロファイル

リファレンス

アベイラビリティーゾーン

参考URL

東京リージョン ap-northeast-1 では4つの利用可能なAZ（アベイラビリティゾーン）が提供されている。

• ap-northeast-1a
• ap-northeast-1b
• ap-northeast-1c
• ap-northeast-1d

これらは実体として1つずつの独立したデータセンターを表しており、耐障害性、安定性の確保のために物理的に分けられている。
いわゆるマルチAZ構成にして、片方のDCに隕石が直撃したときでもサービスを継続できるようにするため。

AWS単語

参考URL

インターネットゲートウェイ

VPCからインターネット間の接続をする。
Public Subnet内のEC2インスタンスのプライベートIPとパブリックIPを1対1変換
インターネットゲートウェイとNATゲートウェイはともにNAT機能を提供する、インターネット接続時に利用されるオブジェクトです。

NATゲートウェイ

NAT-GWはプライベートIPとパブリックIPが多対1で変換されます。
複数のEC2インスタンスから発する通信が、各々のプライベートIPでNAT-GWを通過する際、NAT-GWで1つのパブリックIPに変換されます。
ただし、複数のプライベートIPを1つのパブリックIPに変換してしまうと、戻りの通信においてどの通信がどのプライベートIPに変換すればいいか一意に定まらなくなってしまうので、TCP/UDPポート番号も変換することでそれを回避しています。このようなNAT方式を「動的NAPT（ナプト）=Dynamic NAPT」と呼びます。

インターネットとの接続にはインターネットGWが必要なためこれひとつではどうにもできない。
Private Subnet内のEC2インスタンスプライベートIPとパブリックIPを多対1変換
NATゲートウェイに関連付けるためのElastic IPを作ります。
※NATゲートウェイの生成にはElastic IPとサブネットが必須なためです。

インターネットゲートウェイとNATゲートウェイの違い

参考URL

Elastic IP(AWS Elastic IP アドレス（EIP）)

固定のパブリックIPアドレス（IPv4）を「Amazon EC2」等のインスタンスに設定できるAWSのサービス。

---

AWS CDK

5分で理解するAWS CDK リファレンス AWSクラウド開発キット (AWS CDK) は、最新のプログラミング言語を使用してクラウドインフラストラクチャをコードとして定義し、それをAWS CloudFormationを通じてデプロイするためのオープンソースのソフトウェア開発フレームワーク。

TypeScriptおよびPythonなどのプログラミング言語を使用して、AWSリソースを定義し、Terraformの様にInfrastructure as Code（以降、IaC）を実現する手段として、クラウドインフラのリソースをプロビジョニングできる。

CDK（TypeScripts or Python ...etc → CloudFormation Template（JSON or YAML）

CDK メリット

$ cdk deploy コマンドが優秀 CloudFormationで同じことをしようとしたら

• 初回実行時は普通にデプロイ
• 二度目以降は変更セットを作成して差分デプロイ（みたいなヘルパースクリプトが必要）
• クロスリージョン参照ができる（cdk-remote-stackパッケージを使用）（us-east-1で作らないといけないリソースがあっても安心）
• S3バケットの同期やCloudFrontのキャッシュ削除までできる

AWS CDK と CloudFormationの関係

AWS CDK は、最新のプログラミング言語のすべての機能を活用して AWS Infrastructure as Code を定義する、デベロッパー中心のツールキットと考えることができる。 AWS CDKアプリケーションが実行されると、それらは完全に形成されたCloudFormation JSON/YAMLテンプレートにコンパイルされ、プロビジョニング用にCloudFormationサービスへ送信される。 AWS CDKはCloudFormationを利用しているため、CloudFormationの安全なデプロイ、自動ロールバック、ドリフト検出などのすべての利点がそのまま提供されます。

AWS CDK と AWS SAMの関係

AWS サーバーレスアプリケーションモデル（SAM）と AWS CDK はどちらも AWSインフラストラクチャをコード として抽象化しているため、クラウドインフラストラクチャを簡単に定義できる。 AWS SAM は特にサーバーレスのユースケースとアーキテクチャに焦点を当てており、コンパクトで宣言型の JSON/YAMLテンプレートでインフラストラクチャを定義できる。 AWS CDK は、AWS のすべてのサービスを幅広くカバーしており、TypeScript、Python、C#、Java などの最新のプログラミング言語でクラウドインフラストラクチャを定義できます。AWS SAM と AWS CDK は、どちらも CloudFormation をインフラストラクチャスタックのプロビジョニングエンジンとして利用します。

つまりAWS SAMはサーバーレスに特化している。

アベイラビリティゾーン(AZ):Availability Zone

参考URL

アベイラビリティゾーンとは、AWSである地域に立地するデータセンター群をひとつの論理的な管理単位にまとめたもの。 各リージョン内は2つ以上のAZで構成されている。

マルチAZ

参考URL

マルチAZ配置は同じリージョンのAZを同時に2つ以上使用し、サーバや機能、データを分散して配置する。 バックアップやフェイルオーバーをAZをまたいで行うことで可用性や耐障害性を高めることができる。 サービスの種類にもよるが、単一のAZのみで運用するシングルAZ（Single-AZ）に比べ利用料金が高額となる（他の構成が同じなら2倍程度

IAM(Identity and Access Management)

ユーザに対してAWSのアクセスを制御する仕組みのこと ※CloudFrontやRoute 53と同様、グローバルサービスのためリージョンを気にする必要がない

OAI(Origin Access Identity)

S3からCloudfrontを一意に特定する識別子

Sid(Statement Id)

お客様がポリシードキュメントに与える任意の識別子。 Sid値は、ステートメント配列内の各ステートメントに割り当てることができる。

Lambdaなどのerrorに関して

LambdaなどのerrorはcloudWatchに紐づいているため、デフォルトで通知される。とのこと

AWS アクセスキー

Amazon Web Services(AWS)にアクセスするには、まずアクセスキーが必要。 アクセスキーはAWSで個人を識別する認証情報であり、アクセスキーID (ユーザー名のようなもの）とシークレットアクセスキー（パスワードのようなもの）の2つの部分から構成されています。 アクセスキーを作成するには、S3への認証許可が必要です。

AWS CLIの認証設定をする際の注意

AWS CLIを使うためにはAWSにアクセスするためのアクセスキー(アクセスキーIDとシークレットアクセスキー)が必要になる。

オンプレミス(所有)

所有はすべてを自社で管理する方式。必要なコンピューターー資源はすべて購入して構築から運用まですべて自社で行う。

↓ 所有形態の場合、初期に多額のコストがかかる。また運用を自ら行わなければいけないため運用に携わる技術者が必要となってしまう。

レンタル

コンピューター資源を所有することは非常に大変 しかしレンタル期間は1か月単位、あるいはそれ以上になることが普通。コンピューターー資源の増減は電話やメール・書面などのやりとりとなるため今すく使いたいというニーズに答えることが難しい。インフラ障害が発生したときにもレンタル会社に依頼することしかできず、復旧が遅れる場合がある。

クラウド

コンピューターー資源を1時間単位、あるいは1分単位で借りることができる。

AWS CDK(Cloud Development Kit)

参考URL

AWS CDK(Cloud Development Kit)はAWS上のリソースをコンポーネント化して提供し、AWS上でのアプリケーション開発を支援するサービス AWS Cloud DEvelopment Kitが必要とされる理由は、AWSを操作するその他の方法の課題を解決するためのもの

AWSを操作する方法 一番有名なのはマネジメントコンソール マネジメントコンソールを始めるのは簡単だが以下の課題もある。

• 操作のために操作手順書が必要になる
• 画面を使った操作なので、繰り返し人間の操作が必要になる。
• 人間の操作はヒューマンエラーのリスクがある
• 作業に労力と時間がかかる

SDKやCLIといったスクリプトを使って操作手順を定義する方法は繰り返し使用することが可能だが、アップデートを行う際にはその都度手順を変えなければならない。

これらの、AWSを操作するその他の方法の持つ課題を解決するために活用されるのがAWS Cloud Development Kit (CDK)

AWS Cloud Development Kit (CDK)は、AWSの環境を一般のプログラム言語で記述できるツールで、オープンソースで開発されているので、ユーザーが拡張することも可能です。

AWS CDK(Cloud Development Kit) メリット

• 簡単にawsサービスを活用できる AWS Cloud Development Kit (CDK)では、専門的な知識が必要ではなく新たに学習することなく今まで活用してきた知識とスキルで使用が可能なため、AWSサービスを使ったアプリケーション開発を簡単に取り入れることができます。

• 現在使っているプログラミング言語やツールを使用できる アプリケーション開発のために新しいプログラミング言語やツールが必要になると、時間と労力がかかります。AWS Cloud Development Kit (CDK)は、下記のような多くのプログラミング言語が使用でき、既に使用しているIDEやテストツール、ワークフローパターンを使用できます。

TypeScript Phthon Java .NET

• AWS CloudFormationとの連携 AWS Cloud Development Kit (CDK)を使ってインフラストラクチャを定義すれば、AWS CloudFormationに連携することで、Amazon EC2インスタンスやAmazon RDSDBインスタンスといったAWSリソースを使ったプロビジョニングができます。

• コンポーネントをカスタマイズしてスピードを加速する AWS Cloud Development Kit (CDK)では、開発チームや組織でAWSサービスをいくつか組み合わせて使う必要がある場合の組み合わせや、定型文、ロジックなどのコンポーネントを組織のセキュリティやコンプライアンス、ガバナンスなどを考慮したかたちでカスタマイズできます。

カスタマイズされたコンポーネントは繰り返し使用でき、開発チームや組織で簡単に共有できます。そのことで、新規のプロジェクトなどが発生してもスピーディーに開発を進めることが可能となります。

開発言語にTypeScriptを使用する場合はデプロイする前にCDKテンプレートがビルド(コンパイル)されている必要がある。

CloudFormationは、AWS CDKから使うのが正解な気がしてきた

参考URL

AWS CDKとは？

一言で言うとCloud Formationテンプレートジェネレーター TypeScript等のプロブラム言語で、CloudFormationテンプレートを出力するプログラムが書けます。

また、出力したテンプレートを使ってCloudFormationへのデプロイもAWS CDK上で行うこともできます

テンプレートをプログラムで書くとは

プログラムは下記のような流れになる

1. AWSの各種リソースがクラスとして定義されていて、デプロイしたいAWSリソースのクラスをnewでオブジェクトとして生成していきます。
2. オブジェクトは親子関係を持っていて、CloudFormationのスタックを頂点とした、リソースのオブジェクトツリーを構築していきます。

ユーザーが書くプロブラムはここまでで、このプロブラムを実行すると、構築されたオブジェクトツリー全体が、CloudFormationテンプレートとして出力されます。

CloudFront

webでよく使われる 一番レイテンシーの低いサーバにアクセスがいく

• そもそもCDNとは？ CDNとはコンテンツデリバリーネットワークの略。 負荷分散をするためのコンテンツを配信するためだけのネットワークのことを指す 単にファイル(画像やZIPファイル)をダウンロードするための技術

• アクセス方法 CDNはwebサーバを並べるだけとは違い アクセス元から見て一番近くにあるサーバを自動で選択してダウンロードさせることで表示が高速化される。 CDNのキャッシュサーバはアクセスされたキャッシュサーバにキャッシュがなかったらオリジンサーバ（稼働している元のWebサーバ）にアクセスを行い、データを取ってくることでwebサーバのようにすべてのサーバに同じデータを置かなくても良い。

Cloudfront のメリット

• 高パフォーマンス 世界中の主要都市のほとんどに設置されているエッジロケーションを介してコンテンツ配信を行うことで高速な通信が可能になる。

• 可用性の向上 エッジロケーションを通してコンテンツ配信を行うことにより、オリジンサーバのワークロードを減らし、アプリケーションの可用性を高めることができる。

• 無料のHTTPS証明書を提供している

S3とAmazon CloudFrontの違い

参考URL

ファイルのダウンロードを目的として場合、AmazonS3だけでも事足りるように思えるが、CloudFrontを利用した際のメリットとは Amazon CloudFrontを利用しないで直接Amazon S3などのオリジンサーバーからオブジェクトを取得した場合を比較したとき、一番大きな特徴がエッジデリバリーによるメリットの有無となります。

nuxt.js S3と CloudFrontを使用してAWSへデプロイ S3とCloudFrontでホストしたNuxtjsをGithub Actionsでデプロイする

AWS CDKを使ってS3とCloudFrontを作成する 作成した後、SPAをdeployする まあ料金は高くなるだろう。

マルチAZ配置

マルチAZとは、米アマゾンドットコム（Amazon.com）社のAmazon Web Services（AWS）におけるシステム構成のひとつで、複数のアベイラビリティゾーン（AZ）にまたがってシステムの配置を行う方式。

AZ = アベイラビリティーゾーン

Serverless Framework

LambdaはAWSコンソールから作成できるが、コードのGit管理、ローカルでのデバッグ、デプロイの自動化などを行おうとする場合、何らかしらのツールを使用することが一般的。

その際に使用する代表的なツールとして、 Serverless Frameworkがある。 Serverless Frameworkは、AWS以外のプラットフォームでも使用できるマルチクラウド対応のサーバレスアプリケーション開発支援ツールです。

CloudFormation

CloudFormationはプログラミング言語やテキストファイルを使用してAWSリソースを自動で構築するサービスです。 所望のAWS環境をテンプレート化しておくことで、同じ環境を作成する時間を削減できます。

AWS アクセスキー

アクセスキーはAWSで個人で識別する認証情報(ユーザ名のようなもの)

AWSにアクセスするにはまずアクセスキーが必要。 アクセスキーはAWSで個人で識別する認証情報であり、アクセスキーID(ユーザ名のようなもの)とシークレットアクセスキー(パスワードのようなもの)

S3のアクセスキーとシークレットキーを作る方法

参考URL

1. S3のアクセスキーとシークレットキーを作成するにはIAMユーザを作る必要がある。
2. グループのを作る
3. グループの名前と使用用途を決める。例: node.jsからs3へ画像をアップしたrい、取得したり

バージニア北の理由

バージニア北のが色々制限はゆるい。

CloudFrontとAPI Gatewayの違い

API GatewayがListenするのはHTTPSのみで、HTTPリクエストを受け付ける事はできない 一方、CloudFrontはHTTPとHTTPSの両方のリクエストを受けられるのでCloudFrontを経由することでAPI GatewayへのリクエストをHTTPで受けることができる。

~/.aws/配下のファイルについて

config AWS CLIを使うときのプロファイル別情報

credentials AWS SDK, AWS CLIを使う時の認証情報

• ここでのプロファイルとは アクセスキー、シークレットキーのペアに名前をつけて管理する機能。

[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[test-user]
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

環境ごとに分けること。

$ aws s3 ls --profile cfc-dev 上記コマンドはawsクレデンシャルが反映されているか確認できる。

スイッチロールとは

スイッチロール自体のメリットは一度ログアウトしてから、もう一度別のアカウントでログインする必要がなくなる。

参考URL

CLIでのスイッチロール

マネジメントコンソールからスイッチロールは可能 AWS CLIからもスイッチロールは可能

aws configure

defaultのクレデンシャルをconfigに実装できる。

AWSアクセスキー

CLI、SDK、& APIアクセスに使用するAWSアクセスキー アクセスキーを使用して、AWS CLI、Tools for PowerShell、AWS SDK、または直接AWS API呼び出しからプログラムでAWSを呼び出すことができます。一度に持つことができるアクセスキーは最大2つ（アクティブまたは非アクティブ）

保護の観点から、シークレットキーは誰とも共有しないでください。また、業界のベストプラクティスとして頻繁にキーを更新することが推奨されている。 シークレットキーは、作成時に表示またはダウンロードできるのみです。既存のシークレットキーを正しく配置できなかった場合は、新しいアクセスキーペアを作成する必要がある。

AWS シークレットマネージャー

aws 基本を学んだ後

参考URL

Tips

aws-vaultでアクセスキーをセキュアに保存しつつ、MFAもシームレスにやる AWS Secrets Managerを使おう！

AWS KMS(Amazon Key Management Service)

参考URL

鍵を管理するところ。 元々の鍵をマスターキー 暗号化された鍵をデータキーとしてAWSで保存ができる。

HTTPSの終端

HTTPSの終端とは、HTTPS接続のセキュリティ層がどこで解除されるかを指す用語

たとえば、クライントがHTTPSリクエストを送信し、そのリクエストがロードバランサーに到達したとします。ロードバランサーが設定されていてHTTPSの終端を行う場合、ロードバランサーはHTTPS通信を「終端」させ、その後の通信はHTTP（非暗号化）または再度HTTPSで行われます。これはロードバランサーがクライアントからの暗号化された通信を受け取り、それを解読（デコード）し、バックエンドのサーバにその情報を送るために必要です。

AWS認定資格

AWS認定資格10種類を一覧で解説！ 難易度や費用、おすすめの学習方法も

試験の種類として10種類あるが、大きく分けて4つのカテゴリーがある。

FOUNDATIONAL

AWS認定資格の中では最も易しく、初心者に適したカテゴリです。AWSやクラウドの基礎知識を学ぶことができるため、AWSに触れたことがない方や、基礎からしっかりと学びたい方はここから始めると良い。

ASSOCIATE

基礎レベルよりも難易度が上がり、対象者は1年程度のAWS環境の使用経験があることが望ましいとされているカテゴリです。アソシエイトレベルの資格を取得すると、実務環境に対応できるスキルを証明できます。現在アソシエイトレベルとして用意されている資格は次の4種類です。

AWS Certified Solutions Architect - Associate

システム構築やデプロイの基礎知識から、データベース、ストレージ、ネットワークといった幅広い分野の知識が問われる資格です。AWS環境の設計や提案をするSEやコンサルタント向けですが、基礎を含め幅広く学べる内容なので、経験の浅いエンジニアにも適しています。

AWS Certified Sysops Administrator - Associate

AWSの運用担当者向けの資格です。運用に重点が置かれ、安全で適切なシステム開発や運用を行うためのAWSワークロードやネットワーク、セキュリティーサービスなどの知識が問われます。

AWS Certified Developer - Associate

AWSの開発担当者向けの資格です。AWS環境でのクラウドベースアプリケーションの開発とデプロイ、デバッグなどに関する知識が問われます。取得することでAWSでのアプリ開発や保守における知識やスキルの証明ができます。

AWS Certified Data Engineer - Associate

データエンジニアやデータアーキテクト向けの資格です。データ関連のAWSサービスやデータモデルの設計、データ品質の確保、データライフサイクルの管理などに関する知識が問われます。

PROFESSIONAL

AWSの高度な知識とスキルが求められる上級者向けのカテゴリです。取得にはAWS環境の実務経験が2年以上あることが望ましいとされています。現在プロフェッショナルレベルとしては次の2種類の資格があります。

AWS Certified Solutions Architect - Professional

ASSOCIATEカテゴリのAWS Certified Solutions Architect - Associateの上位資格です。より複雑で多様な環境でAWSアプリケーションの設計やデプロイ、評価を行う知識が求められます。すでに実務でAWS環境の設計や提案を経験しており、さらなるスキルアップを目指す人におすすめです。

AWS Certified DevOps Engineer - Professional

ASSOCIATEカテゴリのAWS Certified Sysops Administrator - AssociateとAWS Certified Developer - Associateの上位資格です。高度な開発知識と運用知識や、最新の運用・開発プロセスの理解が求められます。安全でコンプライアンスに準拠した、効率的なシステムを迅速に提供するプロフェッショナルとしての証明ができます。

SPECIALTY

専門性に特化したカテゴリです。プロフェッショナルレベルと同じく難易度が高いため、チャレンジする際はAWS環境の実務経験が2年以上、専門分野での経験が5年以上あることが望ましいとされています。現在専門知識カテゴリとしては次の3種類の資格があります。

AWS Certified Advanced Networking - Specialty

AWSにおける高度なネットワーク構築をするエンジニア向けの資格です。一般的な知識よりもAWSに特化したネットワークの知識が多く問われるため、取得することでAWSネットワークへの専門性や高い設計力、AWSサービスの統合に関する知識を証明できます。

AWS Certified Machine Learning - Specialty

機械学習エンジニアやデータサイエンティストなど、AI開発に携わるエンジニア向けの資格です。AWSでの機械学習モデルの構築やトレーニング、チューニング、デプロイに関する専門知識の証明となります。

AWS Certified Security - Specialty

セキュリティーエンジニア向けの資格です。AWSにおける専門的なデータ分類やデータ保護メカニズム、データ暗号化方法などのセキュリティーソリューションに関する知識が幅広く問われます。取得することでAWS環境全般におけるセキュリティスペシャリストとしてのスキルを証明できます。

AWS Skill Builder

AWS学習を加速！Skill Builderの活用法：日本語化・フィルター・学習プラン