20200710のAWSに関する記事は19件です。

AWSをゼロから勉強する。vol.1

7/10
まずは使う単語を覚えようと思います。

[Region(リージョン)]
 AWSを運用している基盤のある地域の事
 地理的に近ければ遅延が少なくて済む。
 選ぶリージョンによって料金が変わる(現地の電気代、土地代などの影響)
 頻繁にアクセスしないようなものはコスト安いところに置くなど、工夫できる。
 
[Availability Zone(AZ)]
 簡単に言うとデータセンターの事。
 複数のAZに分けてサーバーを配置することで負荷分散、冗長化が図れる。

[Virtual Private Cloud(VPC)]
 AWS内に構築できる仮想のネットワーク環境。
 同じVPC内であれば、複数のAZに分けてサーバーを配置しても
 同じネットワーク内にいる認識なので、片系が落ちても継続してサービス提供が可能。
 VPCにはサブネットが一つ以上必要。
  パブリックサブネット (トラストゾーンみたいなイメージ)
  プライベートサブネット (イントラゾーンみたいなイメージ)
 など。自由に何個でも作れる

[Route53]
 DNSのこと。
 ルーティングの機能とヘルスチェックの機能が備わっている。
 アラーム通知などもできて、正常なエンドポイントに自動で切り替えもできる。
 

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Well-Architected Framework 2020/07 の更新点まとめ

2020/7/10 のアップデートで「AWS Well-Architected Framework」が更新されました。
ホワイトペーパーの更新履歴いわく 「ほとんどの質問と回答を見直して書き換えました」 というくらいの、大々的な更新のようです。
一体何が変わったのかをまとめ、執筆時点において、AWS を利用する場合に重視すべきことは何かを紐解いてみます。

定義

「AWS Well-Architected フレームワークの柱」 は5本ありますが、これらの定義が微妙に変わっています。

  • 運⽤上の優秀性
    • (旧) ビジネス価値を提供し、サポートのプロセスと⼿順を継続的に向上させるためにシステムを稼働およびモニタリングする能⼒
    • (新) 開発をサポートし、ワークロードを効率的に実⾏し、運⽤に関する洞察を得て、ビジネス価値をもたらすためのサポートプロセスと⼿順を継続的に改善する能⼒
  • セキュリティ
    • (旧) リスク評価とリスク軽減の戦略を通してビジネスに価値をもたらす、情報、システム、アセットのセキュリティ保護機能
    • (新) データ、システム、資産を保護して、クラウドテクノロジーを活⽤し、セキュリティを向上させる機能
  • 信頼性
    • (旧) インフラストラクチャやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、誤設定や⼀時的なネットワークの問題といった中断の影響を緩和する能⼒
    • (新) 期待されるタイミングで、意図した機能を正確かつ⼀貫して実⾏するワークロードの能⼒で、ライフサイクル全体を通じてワークロードを運⽤およびテストする機能を含む
  • パフォーマンス効率 (変更なし)
    • システムの要件を満たすためにコンピューティングリソースを効率的に使⽤し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能⼒
  • コスト最適化 (変更なし)
    • 最も低い価格でシステムを運⽤してビジネス価値を実現する能力

また、製品ライフサイクルにおける、マイルストーンの定義が変更されています。

  • マイルストーン
    • (旧) 設計、テスト、サービス開始、運⽤
    • (新) 設計、テスト、ゴーライブ、本番

フレームワークの5本の柱

次に5本の柱にフォーカスしますと、それぞれの柱の定義が変わったことから、柱を構成する各項目の定義にも変化が見られます。

運用上の優秀性

設計原則

「設計原則」 が6つ→5つに変わり、ドキュメント作成を自動化して注釈をつける原則がなくなりました。

  • (旧) 運⽤をコードとして実⾏する、ドキュメントに注釈を付ける、定期的に・⼩規模な・元に戻すことができる変更を適⽤する、障害を予想する、運⽤上のすべての障害から学ぶ
  • (新) 運⽤をコードとして実⾏する、⼩規模かつ可逆的な変更を頻繁に⾏う、運⽤⼿順を定期的に改善する、障害を予想する、運⽤上のすべての障害から学ぶ

定義

ベストプラクティスの分野に 「組織」 が追加され、4つとなりました。

  • (旧) 準備、運⽤、進化
  • (新) 組織、準備、運⽤、進化

ベストプラクティス

前述の通り 「組織」 が追加されています。

  • (新) 組織
    • チームは、ビジネスの成功を実現する優先順位を設定するために、ワークロード全体、その役割、共有されるビジネス⽬標に関する理解を共有する必要がある
    • 優先順位を明確に定義する
    • 社内外の顧客のニーズを評価し、重点領域を決定する
    • 顧客ニーズを評価する
    • 組織のガバナンスに基づくガイドライン、義務、規制コンプライアンス要件、業界標準などの外部要因を認識する
    • 内部ガバナンスおよび外部コンプライアンス要件への変更を識別するメカニズムを検証する
    • 優先順位を定期的に確認する
    • ビジネスに対する脅威を評価して管理する
    • 競合する利益のトレードオフや代替アプローチを評価する
    • メリットとリスクを管理し、⼗分な情報に基づいて重点領域に関する意思決定を下す
    • チームはビジネスの成果を達成するうえでの役割を理解する
    • 他のチームの役割を理解し、⽬標を共有する
    • アプリケーション、ワークロード、プラットフォーム、インフラストラクチャの各コンポーネントの所有者を特定する
    • 各プロセスと⼿順の定義を担当する所有者、パフォーマンスに責任を持つ所有者を特定する
    • イノベーションを制約しないように、追加、変更、例外をリクエストするメカニズムを備える
    • チームの相互サポート方法、ビジネスの成果に関するチーム間の合意を定義する
    • チームの上級リーダーは、ベストプラクティスの採⽤と組織の進化の協賛者、⽀持者、および推進者であるべき
    • インシデントやリスクがあるとチームメンバーが考える場合に、意思決定者や利害関係者にエスカレーションすることを推奨
    • チームメンバーが関⼼と当事者意識を持ち続けるために、学習を加速するための実験を奨励
    • AWS クラウドコンプライアンスが提供するリソースを使⽤して、優先順位に与える影響を判別できるようにチームを教育する
    • チームを教育するため、AWS サポート (AWS ナレッジセンター、AWS ディスカッションフォーラム、AWS サポートセンター) および AWS ドキュメントが提供するリソースを使⽤する
    • AWS Organizations など、アカウント間で環境を集中管理できるツールまたはサービスを使⽤して、運⽤モデルの管理に役⽴てる

また、他のベストプラクティスの定義も加筆されています。
主に加筆されているポイントは以下のとおりです。

  • 準備
    • 品質に関する迅速なフィードバックを提供し、望ましい結果をもたらさない変更から迅速に復旧できるようにする
    • 失敗を予測し、必要に応じて⼿順を作成する
    • 組織、原価計算、アクセスコントロールのリソースにタグを付け、⾃動化された運⽤アクティビティの実⾏を意図する
  • 進化
    • 顧客に影響を与えるすべてのイベントについて、インシデント後の分析を実⾏すること
    • 反復を制限または防⽌する要因と予防措置を特定すること
    • AWS のサービスを活用してログを保管すること
      • ログデータを Amazon S3 にエクスポート
      • ログを直接 Amazon S3 に送信して、⻑期保存
      • AWS Glue を使⽤して、S3 上ログに関連するメタデータを AWS Glue データカタログに保存
      • Amazon Athena と Glue で、ログデータを分析
      • Amazon QuickSight のようなビジネスインテリジェンスツールを使⽤して、データの可視化、調査、分析

セキュリティ

設計原則

若干ですが、セキュリティの設計原則の定義が変更されています。

  • 強⼒なアイデンティティ基盤の実装
    • (旧) 権限の管理を⼀元化し、⻑期的な認証情報への依存を軽減あるいは解消する
    • (新) アイデンティティ管理を⼀元化し、⻑期にわたる静的な認証情報に依存しないようにすることを⽬的とする
  • セキュリティイベントへの備え
    • (旧) ご所属の組織の要件に合わせたインシデント管理プロセスにより、インシデントに備える
    • (新) 組織の要件に合わせたインシデント管理および調査のポリシーとプロセスを導⼊し、インシデントに備える

定義

セキュリティのベストプラクティス定義が5つ→6つに増えています。
アイデンティティ管理とアクセス管理は、Identity and Access Management (そのまま)、発⾒的統制は検出にリネームされました。

  • (旧) アイデンティティ管理とアクセス管理、発⾒的統制、インフラストラクチャ保護、データ保護、インシデント対応
  • (新) セキュリティ、Identity and Access Management、検出、インフラストラクチャ保護、データ保護、インシデント対応

広い意味での 「セキュリティ」 が加えられました。

  • (新) セキュリティ
    • セキュリティのすべての領域に包括的なベストプラクティスを適⽤する
    • 運⽤上の優秀性で定義した要件とプロセスを抽出し、ベストプラクティスをすべての領域に適⽤する
    • AWS や業界のレコメンデーションおよび脅威インテリジェンスを最新に保つ
    • セキュリティプロセス、テスト、検証を⾃動化する

また、他のベストプラクティスの定義も加筆されています。
主に加筆されているポイントは以下のとおりです。

  • Identity and Access Management
    • (新) お客様が意図した⽅法で承認、認証されたユーザーおよびコンポーネントのみがリソースにアクセスできるようにする

信頼性

設計原則

設計原則の項目は変わりませんが、過去項目の定義が微妙に変更されています。
分かりづらかった KPI の定義が、文書上で明確になったようです。
また、後ほども登場しますがサービスクォータの管理が重視されています。

  • 障害から⾃動的に復旧する
    • (新) KPI は、サービスの運⽤の技術的側⾯ではなく、ビジネス価値に関する指標である必要がある
  • キャパシティーを推測しない
    • (旧) クラウドでは、需要とシステムの使⽤率をモニタリングしてリソースの追加や削除を⾃動化し、需要を満たすために最適なレベルを維持できる
    • (旧) プロビジョニングが超過または不⾜することはありません。
    • (新) クラウドでは、需要とワークロード使⽤率をモニタリングし、リソースの追加と削除を⾃動化することで、プロビジョ⼆ングが過剰にも過⼩にもならない、需要を満たせる最適なレベルを維持できる
    • (新) 制限はまだあるが、制御および管理できるクォータもある

定義

ベストプラクティスの項目が3つ→4つに増えました。
ワークロードアーキテクチャについては、障害を防⽌および軽減するように設計する必要があると定められています。

  • (旧) 基盤、変更管理、障害の管理
  • (新) 基盤、ワークロードアーキテクチャ、変更管理、障害の管理

ベストプラクティス

ワークロードアーキテクチャに関する定義が追加されています。

  • (新) ワークロードアーキテクチャ
    • ソフトウェアとインフラストラクチャの両⽅について事前に設計を決定する
    • 開発者は使⽤する⾔語とテクノロジーを選択する
    • AWS SDK は、AWS のサービス⽤に⾔語固有の API を提供することで、コーディングの複雑さを排除する
    • SDK と⾔語の選択により、信頼性のベストプラクティスを実装できる

一部変更があり、主にサービスクォータに関する記述が追加されています。
主に加筆されているポイントは以下のとおりです。

  • 基盤
    • サービスクォータ (サービスの制限) を管理する
    • サービスクォータは誤って必要以上のリソースをプロビジョニングするのを防ぎ、サービスを不正使⽤から保護することを目的として、API 操作のリクエスト頻度を制限する
    • サービスクォータは、すべてのワークロード環境でモニタリングおよび管理する
    • 計画する際は、システム内およびシステム間の接続、パブリック IP アドレスの管理、プライベート IP アドレスの管理、ドメイン名解決といったネットワークに関する諸点も考慮する

パフォーマンス効率

設計原則

大きな変更はなく、引き続き以下のポイントです。

  • 最新テクノロジーの標準化、わずか数分でグローバル展開する、サーバーレスアーキテクチャを使⽤する、より頻繁に実験する、システムに対する精通の程度を考慮する

定義

ベストプラクティスの定義にも変更はなく、以下の4点です。

  • 選択、レビュー、モニタリング、トレードオフ

ベストプラクティス

ワークロードに関する考慮が追加されたこと、コストが考慮されたこと、情報の吟味による意思決定が重視されたことなどの変更点がありました。
また、反復的な見直しが全体的に重視されていることを踏まえ、各ベストプラクティスの説明はより詳細となっています。

  • 選択

    • コンピューティング
      • (旧) アーキテクチャに対して適切でないコンピューティングソリューションを選択すると、パフォーマンス効率が低下する場合がある
      • (新) コンピューティングオプションを評価するときは、ワークロードのパフォーマンスの要件とコスト要件に留意し、これを使⽤して⼗分な情報に基づいて意思決定を⾏う
      • (新) コンテナに関する詳細説明が追加
        • ECS の起動タイプ: コンピューティング環境のインストール、設定、および管理を制御する必要がある場合に EC2 を選択
    • ストレージ
      • (新) オブジェクト、ブロック、ファイルストレージの選択基準が追記
        • オブジェクトストレージは、ユーザーが⽣成したコンテンツ、アクティブなアーカイブ、サーバーレスコンピューティング、ビッグデータストレージ、またはバックアップと復旧のために、任意のインターネットの場所からデータへのアクセスを可能にする
          • Amazon S3
        • ブロックストレージは、仮想ホストごとに、⾼可⽤性かつ⼀貫性のある低レイテンシーのブロックストレージで、永続的なストレージを必要とするワークロード向け
          • Amazon EBS
        • ファイルストレージは、複数のシステムにまたがる共有ファイルシステムへのアクセスを提供
          • Amazon EFS
          • Amazon FSx
    • データベース
      • (新) 近年新たに登場したデータベースに関する追記
        • リレーショナル、key-value、ドキュメント、インメモリ、グラフ、時系列、および台帳データベースを含めた複数の専⽤データベースエンジンから選択
    • ネットワーク
      • (新) 近年新たに登場したネットワークサービスに関する追記
        • 拡張ネットワーク、Amazon EBS 最適化インスタンス、Amazon S3 Transfer Acceleration、動的 Amazon CloudFront など、ネットワークトラフィックを最適化するための製品機能
        • Amazon Route 53 のレイテンシールーティング、Amazon VPC エンドポイント、AWS Direct Connect、および AWS Global Accelerator などの、ネットワーク距離を縮め、ジッターを削減するネットワーキング機能
  • レビュー

    • (新) ワークロードコンポーネントに対する変更を継続的に評価して検討し、パフォーマンスとコストの⽬標を確実に満たすようにする
    • (新) アーキテクチャのパフォーマンスレベルが低い場合は、パフォーマンスレビュープロセスを導⼊することで、デミングの PDCA (計画 ‒ 実施 ‒ 評価 ‒ 改善) サイクルを適⽤して反復的な改善を促す
  • モニタリング

    • (新) AWS X-Ray を使⽤すると、アプリケーションの動作に関する洞察を得て、根本原因を検出し、パフォーマンスのボトルネックを特定可能
  • トレードオフ

    • (新) ワークロードに変更を加えた後、メトリクスを収集して評価し、それらの変更の影響を判断する
    • (新) システムおよびエンドユーザーに対する影響を測定して、トレードオフがワークロードにどのような影響を与えるかを理解する
    • (新) 負荷テストなどの体系的なアプローチを使⽤して、トレードオフによってパフォーマンスが向上するかどうかを調べる

コスト最適化

全体的に大きく見直され、コスト最適化に向けた組織や体制があるかどうかが、大変重視されるようになっています。
以下を読んでいくと勘付きますが、具体的な言葉はないものの、CCoE の重要性が AWS Well-Architected Framework の中で言及されたとも言えます。

設計原則

定義が見直されています。

  • (旧) 消費モデルを導⼊する、全体的な効率を測定する、データセンター運⽤のための費⽤を排除する、費⽤を分析し帰結させる、アプリケーションレベルのマネージドサービスを使⽤して所有コストを削減する
  • (新) クラウド財務管理の実装、消費モデルを導⼊、全体的な効率を測定する、差別化につながらない⾼負荷の作業に費⽤をかけるのをやめる、費⽤を分析および属性化する

新しい原則として加わった 「クラウド財務管理の実装」 は以下のとおりです。

  • (新) クラウド財務管理の実装
    • 組織は、テクノロジーと使⽤状態の管理という新しい領域における能⼒を獲得するために、時間とリソースを投⼊する必要がある
    • コスト効率の⾼い組織になるには、セキュリティまたはオペレーションの能⼒と同様、知識の積み上げ、プログラム、リソース、プロセスを通じて能⼒を構築する必要がある

定義

ベストプラクティスの定義がガラッと変わっています。

  • (旧) 費⽤認識、費⽤対効果の⾼いリソース、需要と供給を⼀致させる、⻑期的な最適化
  • (新) クラウド財務管理を実践する経費⽀出と使⽤量の認識、費⽤対効果の⾼いリソース、需要を管理しリソースを供給する経時的な最適化

ベストプラクティス

定義が変わったため、内容も大きく変わっています。

  • (新) クラウド財務管理を実践する
    • 合意された⼀連の財務⽬標に整合するように組織を調整し、それらを満たすメカニズムを組織に提供することで、より効率的な組織を構築する
    • AWS Cost Explorer およびオプションで Amazon Athena と Amazon QuickSight をコストと使⽤状況レポート (CUR) とともに使⽤して、組織全体のコストと使⽤状況を把握する
    • AWS ブログで、新しいサービスリリースの最新の状況を常に知る
    • コスト最適化機能を構築するときは、メンバーを引き⼊れるとともに、CFM および CO エキスパートでチームを補完することも検討する
    • 組織にコスト意識を浸透させようとする際には、既存のプログラムおよびプロセスを改善または構築することを検討する
      • 新しいプロセスおよびプログラムを構築するよりも、既存のものに追加する⽅がはるかに迅速で、結果を得るまでの時間が⼤幅に短縮される
  • (新) 経費⽀出と使⽤量の認識

    • AWS Organizations または AWS Control Tower を使⽤してアカウント構造を作成すると、組織単位を分離でき、コストおよび使⽤量の配分に役⽴つ
    • AWS Cost Explorer を使⽤してコストと使⽤状況を可視化するか、Amazon Athena と Amazon QuickSight でカスタマイズされたダッシュボードと分析を作成する
    • 詳細な分析と検査を⾏うには、AWS Cost Explorer で時間単位の粒度を使⽤するか、コストと使⽤状況レポート (CUR) を使⽤して時間単位の粒度で Amazon Athena と Amazon QuickSight を使⽤する
  • 費⽤対効果の⾼いリソース

    • (新) Savings Plans とリザーブドインスタンスは、オンデマンド料⾦に対して最⼤ 75% の割引を提供する
  • (新) 需要を管理し、リソースを供給する

    • スロットル、バッファ、またはキューを使⽤して、需要を滑らかにし、少ないリソースで供給することで、コストを削減したり、後でバッチサービスで処理したりできる
    • Amazon API Gateway を使⽤してスロットリングを実装するか、Amazon SQS を使⽤してワークロードにキューを実装する
  • (新) 経時的な最適化

    • 新しい機能またはリソースタイプを実装し、変更の実装に必要な労⼒を最⼩限に抑え、ワークロードを段階的に最適化する
    • 新しいサービスを使⽤して、ワークロードに新しいコンポーネントを置き換えたり、追加したりする

まとめ

今回のアップデートで具体的に変わり、新たに意識すべき点は、以下のポイントに集約されます。
これらのポイントは、密接に関連していました。

  • 組織作り
  • ワークロードに応じた情報収集と選択、反復的な見直し
  • コスト最適化

なぜなら、AWS を推進する上での体制(組織)が準備されていれば、アーキテクチャなどを継続的かつ反復的に見直すことができ、コスト最適化に繋がるからです。

また、反復的な見直しは、セキュリティを改善する上でも有効であり、これも Well-Architected の柱に関連してきます。
日本国内では殆ど言及がありませんでしたが、6月に改訂された「AWS Security Incident Response Guide」の中でも、セキュリティに対応できる組織を生成しスタッフを継続的に教育すること、小規模から始めて反復的な見直しを続けることなどの言及があります。

確かに、AWS を利用する上で、今この瞬間、技術的に優れたアーキテクチャであることは大事ですが、継続的に見直すための仕組みがなければ、未来において、そのアーキテクチャは過去のものになると言えます。

新たに追記された AWS Well-Architected Framework の考え方・心得を胸に留め、常に新鮮なアーキテクチャを追い求め、ベストを尽くしていると言えるようにしていきたいものです。

参考文献

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS] CloudFront +Lambda@Edge + S3 / DynamoDB 連携

はじめに

こちらの記事 で IP アドレスによるフィルタリングが実現できたので、本記事ではフィルタリングに用いる IP アドレスのリストを

  • S3
  • DynamoDB

に持たせる方法について見ていく。

注意

本記事は 2020年7月10日 時点の情報です。
ご覧になられた時点で UI が変更されている可能性がありますので、その点ご注意ください。

前提

環境

サービス 概要
macOS 10.15.x
Elemental MediaLive あらゆるデバイスへのブロードキャストおよびストリーミング向けにライブ動画をエンコードする
Elemental MediaStore ライブストリーミングによるメディアワークフロー向けにビデオアセットを保存、配信する
CloudFront 高速で安全性が高くプログラム可能なコンテンツ配信ネットワーク (CDN、content delivery network)
Lambda サーバーについて検討することなくコードを実行できる
Lambda@Edge ユーザーに近いロケーションでコードを実行
S3 どこからでもお好みの量のデータの保存と取得が簡単に行えるオブジェクトストレージ
DynamoDB どんな規模にも対応する高速で柔軟な NoSQL データベースサービス

やりたいこと

  • CloudFront へのアクセスを Lambda@Edge で IP フィルタリングする
  • フィルタリングほホワイトリスト形式で許可するIPアドレスを管理する
  • ホワイトリストは S3 / DynamoDB で管理する

S3 での実現方法

想定する構成 

MediaLive + MediaStore のプロダクトを作る場合、CloudFront でキャッシュすると想定すると、以下の図になる。

S3-01.png

S3 にホワイトリストを登録

バケットの設定

暗号化

  • AES-256 を設定

アクセス権限

  • ブロックパブリックアクセスをすべてブロックに設定

S3-02.png

ホワイトリストの内容

次の JSON ファイルを S3 のバケットにアップロード。

{
  "white_list": [
      "xxx.xxx.xxx.xxx" // 許可するIPアドレス
  ]
}

Lamdba@Edge の編集

アクセス権限

  • S3 へのアクセス権限をもつロールを付与
    • フルアクション
    • フルアクセス

S3-03.png

Lamdba 関数

以下の実装で実現できた。(あくまでサンプル。実運用の際は精査する)

'use strict'

// S3 からファイルを読み込む
const aws = require('aws-sdk');
aws.config.region = 'ap-northeast-1';
const s3 = new aws.S3();

const paramsToGet = {
    Bucket: 'ip-white-list',
    Key: 'white_list.json'
};

const errorResponse = (httpVersion) => {
  const body =
    '<!DOCTYPE html>\n' +
    '<html>\n' +
    '<head><title>Lambda@Edge からのエラー</title></head>\n' +
    '<body>\n' +
    '許可されていない IP アドレスです\n' +
    '</body>\n' +
    '</html>'

  return  {
    status: '403',
    statusDescription: 'Forbidden',
    httpVersion: httpVersion,
    body: body,
    headers: {
      'cache-control': [{
        key: 'Cache-Control',
        value: 'max-age=100'
      }],
      'content-type': [{
        key: 'Content-Type',
        value: 'text/html; charset=utf-8'
      }],
    },
  };
};

exports.handler = (event, context, callback) => {
  const request = event.Records[0].cf.request;
  const httpVersion = request.httpVersion;
  const clientIp = request.clientIp;


  // S3 からファイルを読み込む
  s3.getObject(paramsToGet, (err, response) => {
    if (err) {
      console.log(err);
      callback(err);
    }

    console.log('response: ' + JSON.stringify(response));
    if (!response) {
      callback('response is null or undefined');
    }

    console.log('response.body: ' + response.Body.toString("utf-8"));
    if (!response.Body) {
      callback('response.body is null or undefined');
    }

    // ここで指定する `white_list` は S3 のバケットにアップロードされた JSON 中の key
    const permitIp = JSON.parse(response.Body.toString("utf-8"))["white_list"];
    console.log('permitIp: ' + permitIp);

    const isPermittedIp = permitIp.includes(clientIp);
    if (isPermittedIp) {
      // 許可されているIPアドレスなので何もしない( 通常処理へ流れる )
      callback(null, request);
    } else {
      // 許可されていない IP アドレスなのでエラーを返す
      callback(null, errorResponse(httpVersion));
    }
  });
}

要検討事項

  • バケットの設定(暗号化等)とアクセス権限
  • Lamdba@Edge のロールに持たせるアクセス権限

DynamoDB での実現方法

想定する構成

MediaLive + MediaStore のプロダクトを作る場合、CloudFront でキャッシュすると想定すると、以下の図になる。

dynamodb-01.png

DynamoDB にホワイトリストを登録

テーブルの作成とデータ登録

NoSQL テーブルを作成してクエリを実行する に従いテーブルを作成する。
今回作成したテーブルと登録したデータの内容は次の通り。

dynamodb-02.png

Lamdba@Edge の編集

アクセス権限

  • DynamoDB へのアクセス権限をもつロールを付与
    • フルアクション
    • フルアクセス

dynamodb-03.png

Lamdba 関数

以下の実装で実現できた。(あくまでサンプル。実運用の際は精査する)
ポイントは以下の2つ。

  • aws.DynamoDB.DocumentClient を使用する
  • scan メソッドを使用する
'use strict'

const aws = require('aws-sdk');
aws.config.region = 'ap-northeast-1';

// DynamoDB のオブジェクトを作る
const ddb = new aws.DynamoDB.DocumentClient({apiVersion: '2012-08-10'});

const params = {
  TableName: 'ip-white-list'
};

const errorResponse = (httpVersion) => {
  const body =
    '<!DOCTYPE html>\n' +
    '<html>\n' +
    '<head><title>Lambda@Edge からのエラー</title></head>\n' +
    '<body>\n' +
    '許可されていない IP アドレスです\n' +
    '</body>\n' +
    '</html>'
  return  {
    status: '403',
    statusDescription: 'Forbidden',
    httpVersion: httpVersion,
    body: body,
    headers: {
      'cache-control': [{
        key: 'Cache-Control',
        value: 'max-age=100'
      }],
      'content-type': [{
        key: 'Content-Type',
        value: 'text/html; charset=utf-8'
      }],
    },
  };
};

exports.handler = (event, context, callback) => {
  const request = event.Records[0].cf.request;
  const httpVersion = request.httpVersion;
  const clientIp = request.clientIp;

  // DynamoDB からデータ取得
  ddb.scan(params, function(err, response) {
    if (err) {
      console.log(err);
      callback(err);
    }

    console.log('response: ' + JSON.stringify(response));
    if (!response) {
      callback('response is null or undefined');
    }

    console.log('response.Items: ' + response.Items);
    if (!response.Items) {
      callback('response.Item is null or undefined');
    }

    const permitIp = response.Items.map((item) => {
      // ここで指定する `ip_address` は DynamoDB のテーブルに作成したカラム
      return item.ip_address;
    });
    console.log('permitIp: ' + permitIp);

    const isPermittedIp = permitIp.includes(clientIp);
    if (isPermittedIp) {
      // 許可されているIPアドレスなので何もしない( 通常処理へ流れる )
      callback(null, request);
    } else {
      // 許可されていない IP アドレスなのでエラーを返す
      callback(null, errorResponse(httpVersion));
    }
  });
}

要検討事項

  • DynamoDB の設定
  • Lamdba@Edge のロールに持たせるアクセス権限

まとめにかえて

以上、S3 と Dynamo DB に IP アドレスのホワイトリストを持たせて、Lambda@Edge から利用する方法を見てきた。
これで

  • 別サービスと連携してホワイトリストを実現出来る
  • Lambda 関数内にデータを持つ必要はなくなった
  • 実装データ で密な関係を持たずに済む

というのが分かった。
要検討事項として

  • S3 や DynamoDB の設定
  • アクセス権限

といったものはあるが、これらについては実際の運用に合わせて適宜見直す。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

家庭ネットワークからVPNでAWSと動的ルーティング接続する(NATトラバーサル) - VyOS編

はじめに

皆さんこんにちは。仕事でAWSを使っているのですが、これまで自分でVPNを用いたことが無かったため、検証として自宅のネットワークからAWSへのSite-Site VPN接続を試してみました。

前提条件

AWSとの接続はSite-Site VPN構成による接続を行ってみます。
我が家はプロパイダー経由によるNTT光回線を利用しており、宅内にはNTTから送られてきた標準タイプひかり電話ルータなるものが設置されています。ルータからはPPPoE (PPP over Ethernet)による認証を用いて、インターネットプロパイダに接続され、インターネットへの接続が行われています。
グローバルの固定IPアドレスは契約していないため、今回はルータで取得したグローバルIPアドレスを用いて、NATトラバーサルによるVPN接続を行うことにしました。
ルータはテスト用途で、仮想環境で構築できるVyatta (VyOS)を用いました。

NAT-T (NATトラバーサル)とは?

NATトラバーサルとは、アプリケーションがNATによるIPアドレス変換に対応するために定義された規格です。IPSecにおいてはRFC3947でIPSec NAT-TとしてInternet側からNATの内側にあるVPN機器にポートマッピングさせることで通信が確立できるようになります。

  • IKE (UDP/500)
  • NAT-T (UDP 4500)

ハマる。。NTT光のルータに設定ができない!?

NATトラバーサルのために、家庭にあるルータに久々に接続し、ポートマッピング設定を見てみます。
・・・あれ、グレーになっており設定出来ない。
・・・というか、NAT設定が見当たらん!ポートマッピングが無い?
・・・それ以前に、PPPoEの認証設定も触れない!これって何?

調べてみたところ、今はIPv6によるIPoE方式がデフォルト契約になっており、IPv4網によるインターネット接続ではなく、IPv6網による通信が前提になっているようです。昔のNTTフレッツ網時代はPPPoE認証前提だったのに、世の中進化しているんですね。
IPv4網よりもIPv6網の方が通信の混雑が無く、高速なインターネット接続が実現出来るとのことですが、このままでは検証が出来ないため変更することにしました。
プロパイダのコールセンターに電話して、IPv6サービスを止めてもらいました。1週間ぐらいかかるとのことでしたが、1日後にメールが送られてIPv4に切り替えられたとの連絡が。改めてルータの設定を見たところ、懐かしいIPv4設定が出来るようになりました。

家庭用ルータ側の設定 ポートマッピングを行いましょう

自宅のルータはNTT光のPR-S300NEです。設定画面の「静的IPマスカレード設定」から行います。
本設定では、192.168.1.12がVPN機器になります。

  • UDP:4500 - IKE
  • UDP:500 - NATトラバーサル 2_fletsR_2.PNG

AWS側設定

手順は以下の通りです。

  • Customer Gateway
  • VPN Gateway
  • VPN設定

Customer Gateway設定

IPアドレスは自宅で取得しているグローバルIPアドレスを設定します。
固定IPを持てないPPPoE形式の場合は、アドレスが変更毎に修正しましょう。
image.png

仮想プライベートGateway設定

AWS側の仮想プライベートGatewayを設定します。
image.png

サイト間のVPN接続を設定

Customer Gatewayと仮想プライベートGatewayを用いて、Site-to-Site VPNを設定します。
image.png
設定後、「設定のダウンロード」から対象となるVPN設定ファイルをダウンロードできます。
今回はVyOSのVPN設定をダウンロードして適用します。

VyOSインストール

公式サイトからovaイメージをダウンロードして環境を構築します。

VyOS Configuration

AWS側でダウンロードしたVPN設定情報を流し込みます。

  • VyOSのNATトラバーサル設定のため、AWSの設定ファイルを流す前に以下を設定します。
set vpn ipsec nat-traversal enable
set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec nat-networks allowed-network 0.0.0.0/0
  • AWS設定ファイルを流し込んだ後、AWS側対向VPN宛のlocal-addressをNAT前のIPに書き換えます。
set vpn ipsec site-to-site peer 18.181.XXX.XXX local-address 192.168.1.12
set vpn ipsec site-to-site peer 54.250.XXX.XXX local-address 192.168.1.12

VyOS設定例

vyos@awsvpnr:~$ show configuration
interfaces {
    ethernet eth0 {
        address 192.168.1.12/24
        description OutSide
        duplex auto
        hw-id 08:00:27:0c:fe:cd
        smp_affinity auto
        speed auto
    }
    ethernet eth1 {
        address 172.16.1.1/24
        description InSide
        duplex auto
        hw-id 08:00:27:dc:b0:7d
        smp_affinity auto
        speed auto
    }
    loopback lo {
    }
    vti vti0 {
        address 169.254.XX.XX/30
        description "VPC tunnel 1"
        mtu 1436
    }
    vti vti1 {
        address 169.254.XX.XX/30
        description "VPC tunnel 2"
        mtu 1436
    }
}
protocols {
    bgp 65000 {
        neighbor 169.254.XX.XX {
            remote-as 64512
            soft-reconfiguration {
                inbound
            }
            timers {
                holdtime 30
                keepalive 10
            }
        }
        neighbor XXX.XXX.XXX.XXX {
            remote-as 64512
            soft-reconfiguration {
                inbound
            }
            timers {
                holdtime 30
                keepalive 10
            }
        }
        network 0.0.0.0/0 {
        }
    }
}
service {
    ssh {
        port 22
    }
}
system {
    config-management {
        commit-revisions 100
    }
    console {
    }
    gateway-address 192.168.1.1
    host-name awsvpnr
    login {
        user vyos {
            authentication {
                encrypted-password ****************
                plaintext-password ****************
            }
            level admin
        }
    }
    ntp {
        server 0.pool.ntp.org {
        }
        server 1.pool.ntp.org {
        }
        server 2.pool.ntp.org {
        }
    }
    package {
        auto-sync 1
        repository community {
            components main
            distribution helium
            password ****************
            url http://packages.vyos.net/vyos
            username ""
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
    time-zone Asia/Tokyo
}
vpn {
    ipsec {
        esp-group AWS {
            compression disable
            lifetime 3600
            mode tunnel
            pfs enable
            proposal 1 {
                encryption aes128
                hash sha1
            }
        }
        ike-group AWS {
            dead-peer-detection {
                action restart
                interval 15
                timeout 30
            }
            ikev2-reauth no
            key-exchange ikev1
            lifetime 28800
            proposal 1 {
                dh-group 2
                encryption aes128
                hash sha1
            }
        }
        ipsec-interfaces {
            interface eth0
        }
        nat-networks {
            allowed-network 0.0.0.0/0 {
            }
        }
        nat-traversal enable
        site-to-site {
            peer 18.181.XXX.XXX {
                authentication {
                    mode pre-shared-secret
                    pre-shared-secret ****************
                }
                connection-type initiate
                description "VPC tunnel 1"
                ike-group AWS
                ikev2-reauth inherit
                local-address 192.168.1.12
                vti {
                    bind vti0
                    esp-group AWS
                }
            }
            peer 54.250.XXX.XXX {
                authentication {
                    mode pre-shared-secret
                    pre-shared-secret ****************
                }
                connection-type initiate
                description "VPC tunnel 2"
                ike-group AWS
                ikev2-reauth inherit
                local-address 192.168.1.12
                vti {
                    bind vti1
                    esp-group AWS
                }
            }
        }
    }
}

VPN情報確認

AWSマネジメントコンソールから、VPN接続のステータスがUpすることを確認出来ます。
image.png

VyOS側VPNステータス

vyos@awsvpnr:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP
------------                            -------------
18.181.XXX.XXX                           192.168.1.12

    Description: VPC tunnel 1

    Tunnel  State  Bytes Out/In   Encrypt  Hash    NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----    -----  ------  ------  -----
    vti     up     25.1K/23.9K    aes128   sha1    yes    2670    3600    all


Peer ID / IP                            Local ID / IP
------------                            -------------
54.250.XXX.XXX                            192.168.1.12

    Description: VPC tunnel 2

    Tunnel  State  Bytes Out/In   Encrypt  Hash    NAT-T  A-Time  L-Time  Proto
    ------  -----  -------------  -------  ----    -----  ------  ------  -----
    vti     up     24.9K/25.0K    aes128   sha1    yes    2996    3600    all


vyos@awsvpnr:~$

ルーティング確認

vyos@awsvpnr:~$ show ip bgp neighbors
BGP neighbor is 169.254.XXX.XXX, remote AS 64512, local AS 65000, external link
  BGP version 4, remote router ID 169.254.XXX.XXX
  BGP state = Established, up for 00:35:09
  Last read 14:52:14, hold time is 30, keepalive interval is 10 seconds
  Configured hold time is 30, keepalive interval is 10 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    Inq depth is 0
    Outq depth is 0
                         Sent       Rcvd
    Opens:                  1          0
    Notifications:          0          0
    Updates:                2          2
    Keepalives:           212        212
    Route Refresh:          0          0
    Capability:             0          0
    Total:                215        214
  Minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  Inbound soft reconfiguration allowed
  Community attribute sent to this neighbor(both)
  1 accepted prefixes

  Connections established 1; dropped 0
  Last reset never
Local host: 169.254.XXX.XXX, Local port: 179
Foreign host: 169.254.XXX.XXX, Foreign port: 38641
Nexthop: 169.254.XXX.XXX
Nexthop global: ::
Nexthop local: ::
BGP connection: non shared network
Read thread: on  Write thread: off

BGP neighbor is 169.254.XXX.XXX, remote AS 64512, local AS 65000, external link
  BGP version 4, remote router ID 169.254.XXX.XXX
  BGP state = Established, up for 00:34:58
  Last read 14:52:12, hold time is 30, keepalive interval is 10 seconds
  Configured hold time is 30, keepalive interval is 10 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    Inq depth is 0
    Outq depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                4          2
    Keepalives:           211        211
    Route Refresh:          0          0
    Capability:             0          0
    Total:                216        214
  Minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  Inbound soft reconfiguration allowed
  Community attribute sent to this neighbor(both)
  1 accepted prefixes

  Connections established 1; dropped 0
  Last reset never
Local host: 169.254.XXX.XXX, Local port: 44927
Foreign host: 169.254.XXX.XXX, Foreign port: 179
Nexthop: 169.254.XXX.XXX
Nexthop global: ::
Nexthop local: ::
BGP connection: non shared network
Read thread: on  Write thread: off

vyos@awsvpnr:~$

まとめ

AWS側はNAT-Tを意識することなく、通常のSite-to-Site VPNを設定するだけでした。
公式サイトにも掲載されている通り、条件はユーザー側でNAT-TをポートマッピングすることでUDP 500(IKE)、4500(NAT-T)の疎通が行えるようにしてあげれば、問題がなく通信が行えるようになりました。
どなたかのお役に立てれば光栄です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ZshでAWS Profileの可視化と切り替えの容易化

本投稿では

Zshを用いてAWS Profileの可視化と切り替えを容易にする方法を説明します。
設定すると以下のようにAWS Profileを可視化・切り替えできるようになります。

複数のAWSルートアカウント/リージョン上にリソースを作成する必要がある方の参考になれば幸いです。
また、もっと良い方法をご存知の方、ぜひ教えてください。よろしくお願いします。

awsp-example.gif

前提

Zshが設定済であることを前提に説明します。

設定方法

1. AWS Profileの可視化

spaceship-promptを利用することで容易にAWS Profileを可視化できます。

以下のコマンドでインストール、
※npm以外にもインストール方法があります。詳細は公式ページをご確認ください。

$ npm install -g spaceship-prompt

~/.zshrcに以下の設定を追記した後、

autoload -U promptinit; promptinit
prompt spaceship

~/.zshrcを読み込めば、設定完了です。

$ source ~/.zshrc

後は以下の通り、環境変数を設定すると

$ export AWS_PROFILE=hoge

以下のようにAWS Profileがpromptに表示されます。
スクリーンショット 2020-07-10 16.20.18.png

2. AWS Profileの切り替え容易化

pecoをインストールします。
※homebrew以外にもインストール方法があります。詳細は公式ページをご確認ください。

$ brew install peco

~/.zshrcに以下の設定を追記した後、

alias awsp=aws_profile_update

function aws_profile_update() {

   PROFILES=$(aws configure list-profiles)
   PROFILES_ARRAY=($(echo $PROFILES))
   SELECTED_PROFILE=$(echo $PROFILES | peco)

   [[ -n ${PROFILES_ARRAY[(re)${SELECTED_PROFILE}]} ]] && export AWS_PROFILE=${SELECTED_PROFILE}; echo 'Updated profile' || echo ''

}

~/.zshrcを読み込めば、設定完了です。

$ source ~/.zshrc

以下の通り、コマンドを実行すると

$ awsp

動画のように~/.aws/configの中からAWS Profileを選択、切り替えできます。

3. 余談

動画とpromptの表示が違うと思った方がいらっしゃるかもしれません。
私はspaceshipを以下の通り、カスタマイズしています。

SPACESHIP_TIME_SHOW=true
SPACESHIP_KUBECONTEXT_SHOW=false
SPACESHIP_DIR_PREFIX=' '
SPACESHIP_AWS_PREFIX=' '
SPACESHIP_EXEC_TIME_PREFIX=''

spaceshipは~/.zshrcに環境変数を追加するだけで容易に項目の追加/削除やprefixの変更等ができます。
詳細はspaceshipのOptionsをご確認ください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SAA-C02 結局何を勉強すればええんや

先日AWS SAA(Solutions Architect Associate)に合格しました。
社内向けに記事を書いたのですが、社外の友人も知りたいと言ってきていたのでQiita記事化しようかと思います。(ほぼ丸コピ)

AWS認定資格って何や

AWS Certificate(AWS認定)という枠組みで、AWSについての高い知識を持つことを証明する資格。
領域や担当分野に応じて複数の資格がある。
参考:https://aws.amazon.com/jp/certification/?nc2=sb_ce_co

Solutions Architect Associateって何や

アーキテクト系のアソシエイト資格で、AWSでのアプリケーション設計やシステム設計系のスキルを証明するもの。
同じアソシエイト系のSysOps Administrator AssociateやDeveloper Associateの内容を包括し、AWS学習の中ではより一般的な領域の知識が問われる。

試験内容はAWSのサービス変化によって変動し、2020年3月23日以降から新バージョン(SAA-C02)の受験が可能となった。
旧バージョン(SAA-C01)は2020年7月1日まで受験可能である。

実施形式 テストセンターまたはオンラインプロクター試験
時間 130分
受験料金 15000円(税別)
合格ライン およそ72%

求められる知識と経験

  • AWS のコンピューティング、ネットワーキング、ストレージ、データベースサービスの実践的な使用経験
  • AWS のデプロイおよび管理サービスに関する実践経験
  • AWS ベースのアプリケーションに関する技術的要件を特定、定義する能力
  • 提示された技術的要件を満たす AWS のサービスを特定する能力
  • AWS プラットフォームで安全性と信頼性の高いアプリケーションを構築するために推奨されるベストプラクティスに関する知識
  • AWS クラウドでのソリューション構築における基本的なアーキテクチャの原則に関する理解
  • AWS のグローバルインフラストラクチャに関する理解
  • AWS に関連するネットワーク技術の理解
  • AWS で利用できるセキュリティ関連の機能およびツールと従来型サービスとの連携に関する理解

出典:https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/

要は何が分かっていればええんや

1. 一般的なIT知識

一般的なIT知識を前提として出題されるため、知っている必要がある。
例としては下記など。

  • サブネットマスク
  • DNSの各種レコード
  • HTTP / HTTPS / SSH 等のプロトコルとその対応するポート
  • RDBとNoSQLの違い

2. サービスの概要

一般的に使われるAWSサービスの概要の知識が問われる。
私は資格受験の学習の中で、下記サービスについて学んだ。
その中でも、太字になっているものが問題としては多く出されるものだった。

カテゴリ サービス
分析系 Amazon Athena / Amazon EMR / Amazon Redshift / Amazon Kinesis Data Streams / Amazon Kinesis Data Firehose / Amazon Kinesis Data Analytics / Amazon QuickSight / AWS Lake Formation
アプリケーション統合 Amazon Simple Notification Service(SNS) / Amazon Simple Queue Service(SQS) / AWS Step Functions / Amazon MQ
コスト管理 AWS Cost Explorer
コンピューティング AWS EC2 / AWS Lambda / AWS Auto Scaling / AWS Elastic Beanstalk
コンテナ Amazon Elastic Container Registry(ECR) / Amazon Elastic Container Service(ECS) / Amazon Kubernetes Service(EKS)
カスタマーエンゲージメント Amazon Simple Email Service(SES)
データベース Amazon Aurora / Amazon ElastiCache / Amazon Redshift / Amazon DynamoDB / Amazon RDS / AWS Database Migration Service(DMS)
開発者用ツール AWS X-Ray
エンドユーザーコンピューティング Amazon WorkSpaces
Machine Learning Amazon Lex / Amazon Rekognition
マネジメントとガバナンス Amazon CloudWatch / AWS CloudFormation / AWS Auto Scaling / AWS CloudTrail / AWS OpsWorks / AWS Organizations
移行と転送 AWS Application Discovery Service(ADS) / AWS Server Migration Service(SMS) / AWS Database Migration Service(DMS)
ネットワーキングとコンテンツ配信 Amazon VPC / Amazon Route 53 / Amazon API Gateway / Elastic Load Balancing(ELB) / Amazon CloudFront / AWS Transit Gateway / AWS Direct Connect / AWS Global Accelerator
セキュリティ、アイデンティティ、コンプライアンス AWS Identity & Access Management(IAM) / AWS Shield / Amazon Cognite / AWS Certificate Manager(ACM) / AWS CloudHSM / AWS Key Management Service(KMS) / AWS WAF
ストレージ Amazon Simple Storage Service(S3) / Amazon S3 Glacier / AWS Backup / Amazon Elastic Block Store(EBS) / Amazon FSx for Windows File Server / Amazon Elastic File System(EFS) / AWS Storage Gateway / AWS Snowball / AWS Snowball Edge / AWS Snowmobile

また、各カテゴリ内の要素に対して、それぞれ何が違うのか、どのような特徴があるのかを知っておく必要がある。
S3一つでもタイプによって、コストや対応するアクセス頻度、データ取得にかかる時間が異なる。

3. 実現方法

上記サービス単体の知識を得た上で、単体や組み合わせによってそれぞれ何が実現できるのかを理解する必要がある。
例えば、Lambda + API Gateway でサーバレスなAPIを構築できたり、S3 + CloudFrontで静的ホスティングができる等である。

4. 問われている内容の理解

ソリューションアーキテクトとして何が問題で何を解決したいのかを問題文から読み解く力が必要となる。
純粋に「○○を実現する」方法を求められるパターンや、「可用性を担保する」方法、「コストを抑える」方法、「復旧時の」方法など、パターンは無限にある。

サービスごとの特徴と出題の構成を加味して、最適な回答を選択すると良い。

学習方法

私の場合はまずUdemyの動画コースで学習し、その後問題集コースを2周した。
問題集では、誤答した問題に関連するAWSサービスの説明サイトにアクセスし、復習をした。

個人的には動画コースはそこまで勧められない。
インプットのみであれば書籍等の方が良いと考える。

動画コース
これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版)

過去問
【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問)

おわりに

と、まぁ、こんな感じです。

AWS触る機会が多い人もいるでしょうし、キャリアとしてのアピールポイントになったり、他AWSサービスの一部割引があったり、会社によっては報奨金があったりもするので、興味のある人は受験してみても良いんじゃないかなと思います。

実務で使いそうな知識も使わなそうな知識も、幅広く学習する機会を持つことができたので、受けてよかったと思ってます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Laravel6.0.4】の フォームリクエストで「This action is unauthorized. 」のエラーメッセージが出たら。

【開発環境】

Amazon EC2 Linux
Windows 10 HOME
Apache/2.4.43
Laravel Framework 6.0.4
vsftpd: Ver 3.0.2

Tera Term 4.1.105
FFFTP Ver 4.7

【エラーメッセージ】

自作のサイトでフォームボタンを押したら画面にこんなエラーメッセージが・・

This action is unauthorized. 

【対応】

Laravel6.0日本語 のドキュメントによると

フォームリクエストの認可

authorizeメソッドがfalseを返すと、403ステータスコードのHTTPレスポンスが自動的に返され、コントローラメソッドは実行されません。

アプリケーションの他の場所で認証のロジックを行おうと設計しているのでしたら、authorizeメソッドからtrueを返してください。

との事だったので「true」に修正したら正常に動作。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS認定ソリューションアーキテクト – アソシエイト(SAA-C02)に合格したので、学習方法をまとめてみた

先日、AWS認定ソリューションアーキテクト – アソシエイト(SAA-C02)に合格しました。

学習期間は約1ヶ月、点数は8割ちょっととまずまずの結果でしたが、同じくAWS認定試験の合格を目指されている方の参考になればと思い、学習方法をまとめさせていただきました。

前提

  • 普段の業務ではRailsをメインとしたバックエンドの開発を行っています。AWSの業務経験はなし。
  • AWS認定クラウドプラクティショナーに合格していたので、AWSの基礎知識は多少あり。

学習時間

約1ヶ月、1日2~3時間学習。
学習できない日もあったので、全体で50時間程度の学習時間だったと思います。

教材

使用した教材は、以下のとおりです。

  1. AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト
    こちらのテキストで、AWSの各サービスの基礎知識を学習しました。巻末に模擬試験も付いていますが、本試験と比べると難易度がかなり易しいかなと思います。

  2. これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版)
    こちらはUdemyの教材で、AWSの各サービスをハンズオン形式で学ぶことができます。1.のテキストで学習した基礎知識を、ハンズオンで学ぶことにより知識を定着させることができました。最後に模擬試験もついており、本試験よりは少し簡単かなと思いますが、とても参考になりました。

  3. 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問)
    こちらもUdemyの教材で、模擬試験が6回分付いているので、実戦形式の学習ができます。高難易度の模擬試験もいくつかありますが、個人的には本試験と同じくらいのレベルかなと思いました。

学習方法

上記の教材を使用して、以下のとおり学習しました。

  • テキストを1周、Udemyのハンズオンの学習を1周
  • テキスト巻末の模擬試験、Udemyの模擬試験を2~3周

Udemyのハンズオンは長いので、1周程度触ってみて雰囲気が掴めれば十分かなと思います。

模擬試験については、特にUdemyの模擬試験は本番に近い難易度なので、時間の許す限り繰り返して、間違えた箇所をテキストやAWS公式サイトのホワイトペーパーなどで復習するとよいかと思います。

試験のコツ

本試験の難易度はUdemyの模擬試験と同じくらいと述べましたが、出題方法や文章の組み立て方が全然違うので、答えを丸覚えしてしまっては本試験に対処できなくなると思います。

そのため、基礎学習を徹底したり、より多くの問題を解いて様々な出題形式に慣れることが大事かなと思います。

また、AWSのサービスは基本的にそれを利用することでより便利になることが多いので、今解いている問題はコストを最適化したいのか、それとも回復性を高めたいのか、などを意識して問題を解く練習をすることで、本番で文章の構成や出題形式が違う形で出題されても、より柔軟に対応できるようになると思います。

まとめ

AWS認定ソリューションアーキテクト – アソシエイト(SAA-C02)の学習方法について、まとめてみました。
個人的には、AWSの実務経験がまだ無いので、資格を取っただけで満足することなく、機会があれば実務の方にもチャレンジしていけたらなと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

copilot betaを触ってみる

ecs-cliの第二世代、copilotのベータが出ていることは知っていたが、大々的にブログで紹介されていたのと、担当プロジェクトで近い将来採用される可能性があるので、試してみる。

やりたいこと

  • copilotベータを触って、理解する

Step by Step

  1. インストールする。ecs-cli同様、ワンライナーで完了。
% curl -Lo /usr/local/bin/copilot https://github.com/aws/copilot-cli/releases/download/v0.1.0/copilot-darwin-v0.1.0 && \
  chmod +x /usr/local/bin/copilot && \
  copilot --help
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   634  100   634    0     0   1690      0 --:--:-- --:--:-- --:--:--  1686
100 37.9M  100 37.9M    0     0  5482k      0  0:00:07  0:00:07 --:--:-- 7683k
?‍✈️ Launch and manage applications on Amazon ECS and AWS Fargate.

Commands
  Getting Started ?
    init        Create a new ECS application.
    docs        Open the copilot docs.

  Develop ✨
    app         Commands for applications.
                Applications are a collection of services and environments.

    env         Commands for environments.
                Environments are deployment stages shared between services.

    svc         Commands for services.
                Services are long-running Amazon ECS services.

  Release ?
    pipeline    Commands for pipelines.
                Continuous delivery pipelines to release services.

    deploy      Deploy your service.

  Settings ⚙️
    version     Print the version number.
    completion  Output shell completion code.

Flags
  -h, --help      help for copilot
  -v, --version   version for copilot

Examples
  Displays the help menu for the "init" command.
  `$ copilot init --help`

ecs-cliとはサブコマンドが随分様変わりしている。
envとか、どちらかというとamplify CLIに近いかも?

  1. Dockerファイルを用意

以前ecs-cliのテストの際に使ったものをそのまま使う。

FROM centos

RUN yum update -y \
    && yum install httpd php -y \
    && echo "Hello from httpd" > /var/www/html/index.html \
    && echo "<?php phpinfo(); " > /var/www/html/index.php \
    && yum clean all

EXPOSE 80

ENTRYPOINT ["/usr/sbin/httpd", "-DFOREGROUND"]

~/ECS/copilotというディレクトリを作り、ここにDockerfileを配置。

  1. 初期化する

上記ディレクトリでinitコマンドを実行する。

% copilot init
Note: It's best to run this command in the root of your Git repository.
Welcome to the Copilot CLI! We're going to walk you through some questions
to help you get set up with an application on ECS. An application is a collection of
containerized services that operate together.

Application name: copilot-test
Service type: Load Balanced Web Service
Service name: copilot-webservice
✘ ask svc init: no Dockerfiles found within . or a sub-directory level below

失敗。何かと思ったら、Dockerfileの先頭が小文字(dockerfile)だった。
気を取り直して再実行。

copilot init
Note: It's best to run this command in the root of your Git repository.
Welcome to the Copilot CLI! We're going to walk you through some questions
to help you get set up with an application on ECS. An application is a collection of
containerized services that operate together.

Application name: copilot-test
Service type: Load Balanced Web Service
Service name: copilot-webservice
Dockerfile: ./Dockerfile
Ok great, we'll set up a Load Balanced Web Service named copilot-webservice in application copilot-test listening on port 80.

✔ Created the infrastructure to manage services under application copilot-test.

✔ Wrote the manifest for service copilot-webservice at copilot-webservice/manifest.yml
Your manifest contains configurations like your container size and port (:80).

✔ Created ECR repositories for service copilot-webservice.

All right, you're all set for local development.

copilot-testという名前の、ALB-backedなappができた。ECRレポジトリも作ってくれたらしい。

スクリーンショット 2020-07-10 12.52.55.png

確かにいる。AWS CLIのプロファイルを読んでくれるようなので、既にaws configureでセットアップ済みの環境だと随分楽。

  1. テスト環境にデプロイ

そのままcopilotから「テスト環境にデプロイする?」と聞かれたので、yを選択して進んでみる。

Deploy: Yes

✔ Created the infrastructure for the test environment.
- Virtual private cloud on 2 availability zones to hold your services     [Complete]
- Virtual private cloud on 2 availability zones to hold your services     [Complete]
  - Internet gateway to connect the network to the internet               [Complete]
  - Public subnets for internet facing services                           [Complete]
  - Private subnets for services that can't be reached from the internet  [Complete]
  - Routing tables for services to talk with each other                   [Complete]
- ECS Cluster to hold your services                                       [Complete]
- Application load balancer to distribute traffic                         [Complete]
✔ Linked account 0XXXXXXXXXX1 and region ap-northeast-1 to application copilot-test.

✔ Created environment test in region ap-northeast-1 under application copilot-test.
Sending build context to Docker daemon  65.02kB
Step 1/4 : FROM centos
 ---> 831691599b88
Step 2/4 : RUN yum update -y     && yum install httpd php -y     && echo "Hello from httpd" > /var/www/html/index.html     && echo "<?php phpinfo(); " > /var/www/html/index.php     && yum clean all
 ---> Using cache
 ---> 562fe7bfcb7e
Step 3/4 : EXPOSE 80
 ---> Using cache
 ---> 4fe58b868bcb
Step 4/4 : ENTRYPOINT ["/usr/sbin/httpd", "-DFOREGROUND"]
 ---> Using cache
 ---> 54ba23bdc480
Successfully built 54ba23bdc480
Successfully tagged 016831194521.dkr.ecr.ap-northeast-1.amazonaws.com/copilot-test/copilot-webservice:5e3bc3e
Login Succeeded
The push refers to repository [016831194521.dkr.ecr.ap-northeast-1.amazonaws.com/copilot-test/copilot-webservice]
a81bf2899a05: Pushed
eb29745b8228: Pushed
5e3bc3e: digest: sha256:ee1d990b9fce495fe9338c5b6c047d5fe7d6f6c2ec5ecb9ac70f398bb71d4de4 size: 741


✔ Deployed copilot-webservice, you can access it at http://copil-Publi-18XGAVCRBAQVU-300840140.ap-northeast-1.elb.amazonaws.com.

全部できてしまった模様。
インストール開始から2コマンド(+Dockerfileコピー)でここまで辿り着いてしまった。

Fargateクラスター。
スクリーンショット 2020-07-10 13.01.05.png

サービス定義。
スクリーンショット 2020-07-10 13.03.08.png

なんと、Route 53プライベートホステッドゾーンとAレコードまで。。。
Descriptionを見ると、CloudMapが裏で動いたようだ。

スクリーンショット 2020-07-10 13.07.04.png

  1. CLIをいくつか叩いてみる。
% copilot svc ls
Name                Type
------------------  -------------------------
copilot-webservice  Load Balanced Web Service

% copilot svc status
Showing status of service copilot-webservice deployed in environment test
Service Status

  ACTIVE 1 / 1 running tasks (0 pending)

Last Deployment

  Updated At        31 minutes ago
  Task Definition   arn:aws:ecs:ap-northeast-1:01XXXXXXXXX1:task-definition/copilot-test-test-copilot-webservice:1

Task Status

  ID                Image Digest        Last Status         Health Status       Started At          Stopped At
  b3407406          ee1d990b            RUNNING             UNKNOWN             32 minutes ago      -

Alarms

  Name              Health              Last Updated        Reason

「テスト」環境でタスクがデプロイされて稼働していることが分かる。

% copilot svc show
About

  Application       copilot-test
  Name              copilot-webservice
  Type              Load Balanced Web Service

Configurations

  Environment       Tasks               CPU (vCPU)          Memory (MiB)        Port
  test              1                   0.25                512                 80

Routes

  Environment       URL
  test              http://copil-Publi-18XXXXXXXXXXU-300840140.ap-northeast-1.elb.amazonaws.com

Service Discovery

  Environment       Namespace
  test              copilot-webservice.copilot-test.local:80

Variables

  Name                                Environment         Value
  COPILOT_APPLICATION_NAME            test                copilot-test
  COPILOT_ENVIRONMENT_NAME            test                test
  COPILOT_LB_DNS                      test                copil-Publi-18XXXXXXXXXXU-300840140.ap-northeast-1.elb.amazonaws.com
  COPILOT_SERVICE_DISCOVERY_ENDPOINT  test                copilot-test.local
  COPILOT_SERVICE_NAME                test                copilot-webservice

より細かいサービスの情報はshowで取れる模様。
Fargate、ALB、Route 53、CloudMap等々が、こびとさんのごとく働いてくれているのが見て取れる。

所感

copilot initだけで、関連リソースの作成からコンテナの立ち上げまで全部終わってしまった。なかなかの衝撃。
今回は雑に動かしたのでVPCなども雑に作成されたが、丁寧に作ればその辺もきっと綺麗にやってくれるんだろう。

コンテナでアプリを動かしたい、という目的がはっきりしている場合は、CloudFormationやAWS CLI、ましてやマネジメントコンソールでどうこうするより、こっちの方が全然楽。ecs-cliも楽だったが、さらにモダナイズされていて、先にも書いたがAmplifyに近い印象を受けた。

インフラエンジニアとしては、他のもっと難しい領域に時間と労力を使えるのが嬉しいところ。
CloudFormation書くのも、なかなか面倒なので。。。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLI で InvocationType が RequestResponse なのにLambda関数が複数回呼び出される

TL;DR

--cli-read-timeout オプションで0を設定するか、呼び出すLambda関数のタイムアウト時間の秒数を指定する。

事象

Lambda関数で60秒を超える処理を行った際に AWS CLI で InvocationType が RequestResponse なのにLambda関数が複数回呼び出される。

原因

AWS CLI の lambda invoke はデフォルトでは60秒間でタイムアウトし5回まで再実行されるため。

確認

以下のようなLambda関数を用意します。指定した秒数、スリープで停止するLambda関数です。Lambda関数名は sleep とします。
タイムアウト時間は900秒(15分)にでも設定しておいてください。

import json
import time

print('Loading function')

def lambda_handler(event, context):
    print("Received event: " + json.dumps(event, indent=2))
    sleep_seconds = int(event.get("sleep", 3))
    time.sleep(sleep_seconds)
    return "sleep: {}s".format(sleep_seconds)

AWS CLI でLambda関数を実行します。65秒停止するよう指定します。
--debug オプションでデバッグログを出力しています。

aws lambda invoke \
   --function-name sleep \
   --invocation-type 'RequestResponse' \
   --payload '{"sleep":"65"}' \
   --debug \
   output.text

デバッグログを参照すると、接続タイムアウト設定を行なっていることが確認できます。

2020-07-10 10:26:47,915 - MainThread - botocore.endpoint - DEBUG - Setting lambda timeout as (60, 60)

さらにLambdaエンドポイントへ接続し、60秒後にタイムアウトが発生していることが分かります。

2020-07-10 10:26:47,938 - MainThread - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): lambda.ap-northeast-1.amazonaws.com:443
urllib3.exceptions.ReadTimeoutError: AWSHTTPSConnectionPool(host='lambda.ap-northeast-1.amazonaws.com', port=443): Read timed out. (read timeout=60)

タイムアウトでエラーとなると AWS CLI は再度Lambda関数を呼び出しています。

2020-07-10 10:27:49,004 - MainThread - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (2): lambda.ap-northeast-1.amazonaws.com:443

最大5回の実行が確認されました。

2020-07-10 10:30:52,431 - MainThread - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (5): lambda.ap-northeast-1.amazonaws.com:443

AWS CLI のレスポンスには以下が返ってきます。 output.text は出力されません。
尚、ここで2回目以降の実行が60秒以内に戻ってきた場合、正常終了のレスポンスが戻り output.text も正常に出力されるため、複数回呼び出されていることに気付きにくいことになります。

Read timeout on endpoint URL: "https://lambda.ap-northeast-1.amazonaws.com/2015-03-31/functions/sleep/invocations"

解決

--cli-read-timeout オプションを指定します。ここでは900秒を指定しましたが、0(無期限)でも構いません。

aws lambda invoke \
   --function-name sleep \
   --invocation-type 'RequestResponse' \
   --payload '{"sleep":"65"}' \
   --cli-read-timeout 900 \
   --debug \
   output.text

デバッグログを参照すると、接続タイムアウト設定に900秒が設定されていることが確認できます。

2020-07-10 10:42:16,834 - MainThread - botocore.endpoint - DEBUG - Setting lambda timeout as (60, 900)

AWS CLI のレスポンスも戻ってきて、output.text にも出力されています。

{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}
output.text
"sleep: 65s"

参考

コマンドラインオプション
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-options.html

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS/Udacity】AWS クラウドアーキテクト ~Last Submit~

IAM ベストプラクティス

15分で教えるAWSのユーザー管理と権限管理 - Qiita
外部で認証されたユーザー(ID フェデレーション)へのアクセスの許可 - AWS Identity and Access Management

IaC

Terraform

ドキュメントが一番
Documentation - Terraform by HashiCorp

Cloud Formation

下記記事が概要を掴むのにおすすめ。
CloudFormation超入門 | Developers.IO

ファイルの指定方法は下記の通り¥
--template-body file://c3-vpc.yml

aws cloudformation create-stack --region us-east-1 --stack-name c3-s3 --template-body file://c3-vpc.yml

amazon web services - Template format error: unsupported structure seen in AWS CloudFormation - Stack Overflow

pemファイル作成

Amazon EC2 キーペアの作成、表示、削除 - AWS Command Line Interface

S3へのアップロード
aws s3 cp free_recipe.txt s3://cand-c3-free-recipes-803938340682 --region us-east-1

AWS CLI での高レベル (s3) コマンドの使用 - AWS Command Line Interface
AWS CLIでS3を操作するコマンド一覧 - Qiita

IaC のテスト

Terraform

GitHub - fugue/regula: Regula checks Terraform for AWS, Azure and GCP security and CIS compliance using Open Policy Agent/Rego
GitHub - accurics/terrascan: Collection of security and best practice test for static code analysis of terraform

CloudFormation

GitHub - Skyscanner/cfripper: Library and CLI tool for analysing CloudFormation templates and check them for security compliance.
CloudSploit | Open Source
GitHub - aws-cloudformation/cfn-python-lint: CloudFormation Linter

DevSecOps

AWS

DevSecOps | AWS Security Blog
AWSで使っておきたいセキュリティサービス - Qiita

サンプルパイプライン
DevSecOps時代のCloud Security! AWSとトレンドマイクロでどう実現するのか?

自分が考えたパイプライン

image.png

GCP

Google Cloud Blog - News, Features and Announcements
ぼくの考えたさいきょうのDevSecOps
開発チームのための DevOps パイプラインを統合する9つの優れた DevSecOps ツール - Qiita
How DevOps professionals can become security champions | Opensource.com
たった40分でわかるDevSecOpsの必要性

WAF

AWS WAF、AWS Shield、AWS Firewall Manager とは - AWS WAF、AWS Firewall Manager、および AWS Shield アドバンスド
【レポート】Inspectorを利用したDevSecOpsのSecの自動化 #reinvent #SID404 | Developers.IO

Container Scan

【超待望アップデート】ECRに対する脆弱性スキャン機能が提供されました | Developers.IO

ゴールデンAMI

構築済みのサーバーイメージをAMIとして作成しておき、これをベースとしてインスタンスを立ち上げるのはよくあるパターンだと思います
10分で理解するPacker - Qiita

これからAWSを始める人は一読すべき「AWS運用チェックリスト」を読んでみた | Developers.IO
Pairs Infra 2017 | by eureka, Inc. | Eureka Engineering | Medium

Security Hub

Security Hubの概要とユースケース | Developers.IO

ブルートフォース攻撃

ブルートフォースアタック(総当たり攻撃)とは?そのやり方・実際にかかる時間・対策方法は?
ブルートフォースアタックとは?実験から分かる危険性と有効な4つの対策

簡単な攻撃の流れ

  • 攻撃する側にssh する
  • textファイル準備
  • 攻撃対象のインスタンスにアタック

hydraコマンド

ログインクラックするときに使用します。
hydra -l ubuntu -P rockyou.txt ssh://ec2-23-21-251-196.compute-1.amazonaws.com

GuardDuty

主に全体の監視をしてくれます。
VPC フローログなどから検知を行うことが可能になっています。
ブルートフォース攻撃を識別するために GuardDuty を使用する
【初心者向け】AWSの脅威検知サービスAmazon GuardDutyのよく分かる解説と情報まとめ | Developers.IO

対策

ブルートフォースアタックとは?実験から分かる危険性と有効な4つの対策
アカウントリスト攻撃 | トレンドマイクロ

CloudTrail

CloudTrailの基本 – サーバーワークスエンジニアブログ

AWS Config

AWS Configはとりあえず有効にしよう | Developers.IO

その他

【セキュリティ】脆弱性診断・検査 ツール on Kali Linux - Qiita

OWASP Top Ten

OWASP Top Ten Web Application Security Risks | OWASP

ペネストレーションテスト

Network Administration Sub Notes Extra
【セキュリティ】脆弱性診断・検査 ツール on Kali Linux - Qiita

S3 デフォルト暗号化

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/bucket-encryption.html

AWS GCP全サービス比較

AWS/Azure/GCPサービス比較 2020.07 - Qiita
AWS/Azure/GCPサービス比較 2020.06 - Qiita

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Batchでスポットインスタンスを使ってハマった話

概要

AWS Batchで使用するコンピューティング環境でスポットインスタンスを使用する事ができます。これによってコスト削減が狙えるのですが、配分戦略でBEST_FITを選ぶ際に指定するスポットフリートロールでめちゃくちゃハマりました。
具体的にはスポットフリートロールをドキュメントの通りに作成しても、エラーとなってスポットインスタンスリクエストが失敗しました。

Linux/UNIX: The provided credentials do not have permission to create the service-linked role for EC2 Spot Instances.

こんな感じです。ドキュメントの通りにロールを作ったのですが、それだと権限が足りないようです。検索して出てくる解決策もバラバラで、ようやく解決したので記録として残しておきます。

結論

  • ロール作成で選ぶユースケースは [EC2 Spot Fleet Role]です。arn:aws:iam::aws:policy/service-role/AmazonEC2SpotFleetTaggingRoleが付与されているはずです。
  • この状態でロールを作成します。名前は [AmazonEC2SpotFleetRole]とします。
  • 作成したロールに、iam:CreateServiceLinkedRoleアクションをアタッチして下さい。

これで作成した[AmazonEC2SpotFleetRole]を、AWS Batchのコンピューティング環境で、スポットフリートロールで指定します。

経緯

AWS Batch環境のアップデートに伴い、別環境で色々検証していた際、少しでもコストを下げるためにスポットインスタンスを利用してみようと思ったのがそもそもの始まりでした。
別環境ではすでに成功しているので、それをそのまま持っていけば良いと思ったのですが、AWS Batchコンピューティングリソースのスポットインスタンスにタグ付けがサポートされた際、推奨されていた管理ポリシーが変更され、別環境で使っていたポリシーが使えなくなっていました。
そこで新しい方法として紹介されていたロールを作成し、コンピューティング環境にアタッチしても、スポットインスタンスリクエスト自体はできるがエラーになってしまい、色々試しまくった結果、今回の結論にたどり着きました。
冒頭で「解決策がバラバラ」と書きましたが、このアップデートに関連しています。管理ポリシーの変更前と後の両方の解決策が出てくる状態なので、探すのにえらい苦労しました。

AWS Batchとスポットインスタンスは非常に相性が良く、ジョブキューにオンデマンドコンピューティング環境も入れておけばより安全にスポットインスタンスを利用する事ができるので、効率よくコストを削減できます。
もし今回と同じ事例で引っかかっている人の助けになれば幸いです。

参考

AWS Batch で INVALID コンピューティング環境を修正する方法は?

  • こちらの無効なスポットフリートロールを修正するを参考にロールを作成

Bamboo fails to lodge spot instance request since the provided credentials do not have permission to create the service-linked role

  • ここに足りない権限に関する情報が記載されていました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

prefix listを作成し2つのAWSアカウントで共有する

概要

VPCでprefix listが利用できるようになったと聞いて...!

IPアドレスをまとめられるだけでなく、アカウント間での共有も可能という点に惹かれ
設定を試しました。

Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables

今回試すこと

  • 自宅のIPアドレスを設定したprefix listを作成
  • 作成したprefix listを2つのAWSアカウント間で共有する
  • EC2のセキュリティグループのIngressで作成したprefix listのみ許可する
    • AWSアカウント Hoge: EC2-hoge
    • AWSアカウント Fuga: EC2-fuga

最終的に確認したいポイントは
共有したprefix listを使って両環境のEC2へ接続できるか、という点です。

その1: prefix listを作成する

現在利用可能な作成方法はマネジメントコンソールまたはCLI。
今回はマネジメントコンソールから作成しました。

スクリーンショット 2020-07-10 午前5.22.33(2).png

その2: 別のAWSアカウントに共有する

作成したprefix listの共有にはRAM(AWS Resource Access Manager)を利用します。

共有元だけでなく、共有先のAWSアカウントでも作業が必要になるため
分けて記述していきます。

▼共有元のAWSアカウント(AWSアカウントHoge)
自分が共有 > リソースの共有 からリソースの共有を作成します。
スクリーンショット 2020-07-10 午前4.10.40(2).png

上記のように必要事項を入力し、作成すると
共有先AWSアカウントのステータスがAssociating(共有先アカウントのアクション待ち)になります。
スクリーンショット 2020-07-10 午前4.19.05(2).png

RAMはCloudFormationでも作成可能です。

Resources:
  RAMResourceShare:
    Type: AWS::RAM::ResourceShare
    Properties: 
      AllowExternalPrincipals: true
      Name: 'share-test-prefix-myip'
      Principals: 
        - !Ref AccountIDFuga 
      ResourceArns: 
        - !Ref PrefixListArn

※PrincipalにはAWSアカウントID以外に、OrganizationsのOUまたは組織のArnも可能とのこと。
AWS::RAM::ResourceShare

▼共有先のAWSアカウント(AWSアカウントFuga)
リソースの共有先に指定されると、自分と共有 > リソースの共有に招待が来るため
スクリーンショット 2020-07-10 午前4.28.55(2).png
以下のように承認する必要があります。
スクリーンショット 2020-07-10 午前4.37.43(2).png

その3: SecurityGroupでprefix listを許可する

▼マネージドコンソールから設定する場合
作成したPrefix ListsのIDを指定します。
スクリーンショット 2020-07-10 午前3.36.32(2).png

インバウンドルールに指定したprefix listのIDが反映されます。
スクリーンショット 2020-07-10 午前3.43.01(2).png

▼CloudFormationで設定する場合
PropertyにSourcePrefixListIdを指定することで設定可能でした。

  EC2SecurityGroup:
    Type: 'AWS::EC2::SecurityGroup'
    Properties:
      SecurityGroupIngress:
         - SourcePrefixListId: 'pl-xxxxxxxxxxxxxxxxx' #SourcePrefixListIdで指定する
           FromPort: 22
           ToPort: 22
           IpProtocol: 'tcp'
      Tags:
        - Key: 'Name'
          Value: !Sub '${AWS::StackName}-ec2'
      VpcId: !Ref EC2VPC

その4: 端末からEC2にsshする

どちらのEC2へも作成・設定したprefix listを利用して無事接続できました。

▼AWSAccount HogeのEC2

$ ssh -i "hoge_keypair.pem" ec2-hoge-user@ec2-xx-xxx-xxx-xx.ap-northeast-1.compute.amazonaws.com
Last login: Thu Jul  9 19:56:09 2020 from xxxxx

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/

▼AWSAccount FugaのEC2

$ ssh -i "fuga_keypair.pem" ec2-fuga-user@ec2-xx-xxx-xxx-xx.ap-northeast-1.compute.amazonaws.com
Last login: Thu Jul  9 19:56:09 2020 from xxxxx

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/

まとめ

  • prefix listを共有した場合は共有先AWSアカウントでの承認作業が必要

その他試した過程でわかったこととして、

  • 共有された側ではprefix listの削除はもちろん、変更(編集)はできなかった

    • アクションとして選択できなかった
  • 最大エントリ数100で作成したprefix listをセキュリティグループに設定しようとした際に、CloudFormationで以下のエラーが発生した

    • 実際にprefix listに設定していたエントリはセキュリティグループの上限(デフォルト60)以下だった
      • 最大エントリ数100がセキュリティグループのルール数として認識された...?

   The maximum number of rules per security group has been reached.

参考

Creating a prefix list
AWS::EC2::SecurityGroup Ingress

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ECRを使ってみる

Amazon ECRを使ってみる。
環境はEC2(AmazonLinux2:t2.micro)。

リポジトリ作成

マネジメントコンソール → サービス → ECS → レポジトリ で「レポジトリを作成」

レポジトリ名を入力
 名前空間を含めることができるとのことなので
 今回は sandbox/test-pj/web とする。

タグのイミュータビリティ
 有効にすると同じタグを上書きができなくなる。
 業務等でイメージのバージョンを確実に管理したい場合は
 有効にしたほうがよさそう。 

 # タグが上書きできてしまうとイメージの特定するには
 # ハッシュ値が必要になってしまう。

 一方、上書きできないとlatestのようなタグは
 使い勝手が著しく悪くなるのでどっちにするかは用途次第。

イメージスキャンの設定
 有効にするとプッシュ後も自動でイメージスキャンをしてくれる。
 

AWS CLI のバージョンアップ

バージョンアップしておかないとdockerコマンドの認証まわりでエラーが出る可能性がある。
バージョンアップの仕方は公式ドキュメントの「Linux での AWS CLI バージョン 2 の更新」。

AWS_CLIのバージョンアップ
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

unzip awscliv2.zip

which aws

ls -l /usr/bin/aws  ←whichコマンドの結果次第で内容が変わる

sudo ./aws/install --bin-dir /usr/bin --install-dir /usr/bin --update ←whichコマンド、lsコマンドと結果次第で内容が変わる

aws --version

参考までに、バージョンアップしないでdockerコマンドでget-login-passwordをやったら以下のとおりエラーになった。

バージョンアップしないとエラーになる
$ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin 056789090539.dkr.ecr.ap-northeast-1.amazonaws.com

usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help
aws: error: argument operation: Invalid choice, valid choices are:

batch-check-layer-availability           | batch-delete-image
batch-get-image                          | complete-layer-upload
create-repository                        | delete-lifecycle-policy
delete-repository                        | delete-repository-policy
describe-image-scan-findings             | describe-images
describe-repositories                    | get-authorization-token
get-download-url-for-layer               | get-lifecycle-policy
get-lifecycle-policy-preview             | get-repository-policy
initiate-layer-upload                    | list-images
list-tags-for-resource                   | put-image
put-image-scanning-configuration         | put-image-tag-mutability
put-lifecycle-policy                     | set-repository-policy
start-image-scan                         | start-lifecycle-policy-preview
tag-resource                             | untag-resource
upload-layer-part                        | get-login
help
Error: Cannot perform an interactive login from a non TTY device

dockerインストール

公式ドキュメントの「Docker のインストール」

IAMロールを作成しEC2にアタッチ

公式ドキュメント
「 Amazon ECR リポジトリへのアクセス」を参考に
Resourceは*でポリシーを作成しEC2にアタッチ。

ECR用ポリシー
{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"ListImagesInRepository",
         "Effect":"Allow",
         "Action":[
            "ecr:ListImages"
         ],
         "Resource":"*"
      },
      {
         "Sid":"GetAuthorizationToken",
         "Effect":"Allow",
         "Action":[
            "ecr:GetAuthorizationToken"
         ],
         "Resource":"*"
      },
      {
         "Sid":"ManageRepositoryContents",
         "Effect":"Allow",
         "Action":[
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:GetRepositoryPolicy",
                "ecr:DescribeRepositories",
                "ecr:ListImages",
                "ecr:DescribeImages",
                "ecr:BatchGetImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload",
                "ecr:PutImage"
         ],
         "Resource":"*"
      }
   ]
}

あとはマネジメントコンソール → ECR → リポジトリから
対象リポジトリを選んで「プッシュコマンドの表示」をクリックし
表示される内容をやっていくだけ。

image.png

デフォルトレジストリに対して認証する

認証
$ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ************.dkr.ecr.ap-northeast-1.amazonaws.com

WARNING! Your password will be stored unencrypted in /home/ec2-user/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

イメージ作成

イメージ作成
$ docker build -t sandbox/test-pj/web .

$ docker image ls
REPOSITORY                  TAG           IMAGE ID            CREATED             SIZE
sandbox/test-pj/web         latest        c2df0d42b9ce        10 seconds ago      221MB
$

ECR登録用のタグ付け

ECR登録用のタグ付け
$ docker tag sandbox/test-pj/web:latest ************.dkr.ecr.ap-northeast-1.amazonaws.com/sandbox/test-pj/web:latest

$ docker image ls
REPOSITORY                                                              TAG                 IMAGE ID            CREATED              SIZE
************.dkr.ecr.ap-northeast-1.amazonaws.com/sandbox/test-pj/web   latest              c2df0d42b9ce        About a minute ago   221MB
sandbox/test-pj/web                                                     latest              c2df0d42b9ce        About a minute ago   221MB

PUSH

PUSH
$ docker push ************.dkr.ecr.ap-northeast-1.amazonaws.com/sandbox/test-pj/web:latest

:latest
631e3af3d0e9: Pushed
fc8234f25c50: Pushed
933e707b3698: Pushed
895d16eabfa1: Pushed
latest: digest: sha256:d5d908a0a3e69a0c37af7b64dc21146333a358cc733b33837e279647d619c101 size: 1155
$
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2 Linux上でinodeが枯渇した際の対処法

There appears to be insufficient space on your system to finish とエラーがでた!

とある日,会社のサービスが止まっていまい,原因の究明を行ったところ上記のエラーが発生して新規ファイルの作成ができなくなっていた.
そこでディスクのスペースを確認したところ空き容量は問題ないが,inodeが枯渇していることが判明.
ここに,この問題を対処した際の備忘録を残す.

inode空き容量の確認

df -iコマンドでinodeの空き容量を調べる

/dev/xvda1     217227 217227 217227   100% /

確認すると使用率は100%になっている.
これでは新規ファイルの作成ができず,logを書き出したところでサービスが止まってしまう.

ファイルシステムの確認

df -Tコマンドでファイルシステムを確認する

/dev/xvda1     ext4   略

今回はext4であった.
ext4ではinodeテーブルのサイズを動的に変更は(多分)できないので,ファイルシステムを再構築するか,ディスクサイズを拡張し,同時にinodeテーブルサイズを方法をとる.
EC2では手軽にディスクサイズを拡張できるため,今後の事も考えディスクサイズの拡張を行う.

ボリュームサイズの拡張

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  8G  0 disk 
└─xvda1 202:1    0  8G  0 part /

ボリュームサイズを確認しておく.
次にEC2ダッシュボードで,問題のインスタンスからEBS IDをクリックし,EBSボリュームのページに移動に移動する.
スクリーンショット 2020-07-10 2.26.59.png

対象のボリュームのスナップショットを念のためとっておき,ボリュームの変更を行う.
スクリーンショット 2020-07-10 2.31.20.png

ここで先ほど確認しておいたボリュームサイズ以上の値を指定し,変更リクエストを行う.
この変更は5分ほどかかる事もある.

変更できたら以下のようになるだろう.

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  20G  0 disk 
└─xvda1 202:1    0  8G  0 part /

ある程度待っても変更されない場合はインスタンスの再起動をすると変更される.
しかし,ルートのパーティションは8Gのままで変更されていないため,以下コマンドで拡張を行う.

$ sudo growpart /dev/xvda 1

mkdir: cannot create directory '/tmp/growpart.1959': No space left on device
FAILED: failed to make temp dir
と出る場合は空きがなくtmpファイルが作成できないので,お掃除をしてから実行する)

再度確認

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  20G  0 disk 
└─xvda1 202:1    0  20G  0 part /

これでサイズが最大まで拡張されています.

ファイルシステムの拡張

最後にファイルシステムの拡張を行う

$ sudo resize2fs /dev/xvda1
$ df -i
/dev/xvda1     1310720 217227 1093493   17% /

inode使用率が17%まで減りました.
これで完了です.

おまけ

$ dpkg --get-selections | grep linux-
linux-base                  install
linux-headers-4.4.0-121             install
linux-headers-4.4.0-121-generic         install
linux-headers-4.4.0-124             install
linux-headers-4.4.0-124-generic         install
linux-headers-4.4.0-127             install
linux-headers-4.4.0-127-generic         install
linux-headers-4.4.0-128             install
linux-headers-4.4.0-128-generic         install
linux-headers-4.4.0-130             install
linux-headers-4.4.0-130-generic         install
linux-headers-4.4.0-133             install
linux-headers-4.4.0-133-generic         install
linux-headers-4.4.0-134             install
linux-headers-4.4.0-134-generic         install
linux-headers-4.4.0-137             install
linux-headers-4.4.0-137-generic         install
linux-headers-4.4.0-138             install
linux-headers-4.4.0-138-generic         install
linux-headers-4.4.0-139             install
linux-headers-4.4.0-139-generic         install
linux-headers-4.4.0-151             install
linux-headers-4.4.0-151-generic         install
linux-headers-4.4.0-154             install
linux-headers-4.4.0-154-generic         install
linux-headers-4.4.0-157             install
linux-headers-4.4.0-157-generic         install
linux-headers-4.4.0-159-generic         install
linux-headers-generic               install
linux-headers-virtual               install
linux-image-4.4.0-101-generic           deinstall
linux-image-4.4.0-104-generic           deinstall
linux-image-4.4.0-108-generic           deinstall
linux-image-4.4.0-109-generic           deinstall
linux-image-4.4.0-112-generic           deinstall
linux-image-4.4.0-116-generic           deinstall
linux-image-4.4.0-141-generic           deinstall
linux-image-4.4.0-142-generic           deinstall
linux-image-4.4.0-143-generic           deinstall
linux-image-4.4.0-151-generic           install
linux-image-4.4.0-154-generic           install
linux-image-4.4.0-157-generic           install
linux-image-4.4.0-159-generic           install
linux-image-4.4.0-92-generic            deinstall
linux-image-4.4.0-93-generic            deinstall
linux-image-4.4.0-96-generic            deinstall
linux-image-4.4.0-97-generic            deinstall
linux-image-4.4.0-98-generic            deinstall
linux-image-virtual             install
linux-libc-dev:amd64                install
linux-modules-4.4.0-143-generic         deinstall
linux-modules-4.4.0-151-generic         install
linux-modules-4.4.0-154-generic         install
linux-modules-4.4.0-157-generic         install
linux-modules-4.4.0-159-generic         install
linux-virtual                   install

確認してみると古いカーネルがいっぱい残っていた.
これをお掃除すれば空きが増えそうなので,空きがない場合は確認してみると良いかと思う.
一応確実に使わないであろうカーネルを削除

下記オプション--dry-runで削除テストを行い,問題がなければ削除を行う

$ apt-get autoremove --purge linux-*-4.4.0-{121,124,127,128,130,133,134,137,138,139}* --dry-run

以上で処置完了です.おつかれさまでした!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Cloud9においてPython用開発環境を整える (pip install & 時刻変更編)

目次

  1. 概要
  2. pip installについて
  3. Cloud9上の環境においての時刻変更

1. 概要

Amazon EC2 インスタンスにAWS Cloud9開発環境を作成する」において、
Cloud9の環境構築方法について説明したが、より細かいpython環境を整えるための方法を説明する.
今回は、python用moduleを入れる方法 (pip install)と、Cloud9側の時刻環境を変更する方法について説明を行う.

2. pip install

pythonを使うとなると、pip installなどで使いたいModuleを入れたくなる.
その方法についてまとめる.

2-1. Cloud9環境を作成する

Cloud9環境を作成していない人は、Amazon EC2 インスタンスにAWS Cloud9開発環境を作成するを参考に作成してみてください

2-2. Terminalを立ち上げる

タブの「+」をクリック、「New Terminal」をクリック
ezgif-4-6ea813b63d5b.gif

2-3. pipの確認

terminal
pip -V

すでにpipはinstallされていることを確認

Screen Shot 2020-07-10 at 01.21.33.png

2-4. pip install

Cloud9環境においてpip installは、管理者権限で実行しないといけない
Cloud9環境においてsudoのパスワードは設定されていないので、そのまま実行できる

terminal
sudo pip install <installしたいmodule>

ezgif-4-f4037b95e4f.gif

pip自身のversionも古いのでpipをupgradeする

terminal
sudo pip install --upgrade pip

ezgif-4-250a68aa6d92.gif

3. Cloud9上の環境においての時刻変更

3-1. 時刻の確認

terminal
date

Cloud9のDefaultの設定は、UTCらしい.

Screen Shot 2020-07-10 at 01.36.03.png

3-2. JST (日本時刻)に変更する

terminal
sudo sed -i -e 's/ZONE="UTC"/ZONE="Japan"/g' /etc/sysconfig/clock
sudo ln -sf /usr/share/zoneinfo/Japan /etc/localtime

Screen Shot 2020-07-10 at 01.38.11.png

時刻が、JST (日本時刻)に変わっていることを確認

terminal
date

Screen Shot 2020-07-10 at 01.39.02.png

まとめ

Cloud9 (IDE)環境とはいえ、開発者に容易に環境設定できるように、pipがdefaultでinstallされていたりするため、細かいことは気にせずにいつも通り環境を整えることができる.

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSサービス1行まとめ(を取得する)

tl;dr

  • AWSのサービスが色々ありすぎて、正直フォローしきれない
  • 年に1度くらいQiitaに上がるAWSサービス3行まとめ記事を読むけど、3歩歩いたら忘れてしまう
  • Qiitaの記事待ちじゃなくて、その時々で最新のサービス達をサクッと把握したい

やり方

  • 下記のシェルスクリプトを実行する。
curl -s "https://aws.amazon.com/jp/products/" | awk 'f==1{f=0;gsub(/ {2,}/,"",$0);split($0,s,"<span>");gsub(/<[^>]*>/,"",s[1]);gsub(/<[^>]*>/,"",s[2]);if(length(s[2])){print "  *"s[1]": "s[2]}}/lb-content-item/{f=1}/lb-trigger /{gsub(/ {2,}/,"",$0);gsub(/<[^>]*>/,"",$0);sub(/^ /,"* ",$0);print $0}' | sed -E "s:amp;::g" | sed -E "s: *$::g"
  • WindowsだしWSLも導入して無いよ、という人はWSLを導入する。下記のPowerShellで代用する。ogvはフィルタで絞れて便利だし。
Invoke-WebRequest "https://aws.amazon.com/jp/products/" | %{$_.Content -split "`n" | ?{$_ -match '<a href="/'} | ?{$_ -match "span" } | %{($_ -replace "<[^>]+>","`t").Trim() | %{$s = $_ -split "`t"; [PSCustomObject]@{"name"=$s[0];"desc"=$s[1]} }}} | sort -Unique name | ogv

2020/7/10現時点でのレスポンス

* 分析
  * Amazon Athena: SQL を使用した S3 でのデータクエリ
  * Amazon CloudSearch: マネージド型検索サービス
  * Amazon Elasticsearch Service: Elasticsearch クラスターを実行し、スケールする
  * Amazon EMR: ホスト型 Hadoop フレームワーク
  * Amazon Kinesis: リアルタイムストリーミングデータとの連携
  * Amazon Managed Streaming for Apache Kafka: フルマネージド型 Apache Kafka サービス
  * Amazon Redshift: 高速かつシンプルで、費用対効果の高いデータウェアハウス
  * Amazon QuickSight: 高速ビジネス分析サービス
  * AWS Data Exchange: クラウド内サードパーティのデータを検索、購読、および使用
  * AWS Data Pipeline: 定期的なデータ駆動型ワークフローに対するオーケストレーションサービス
  * AWS Glue: データの準備とロード
  * AWS Lake Formation: 安全なデータレイクを数日で構築
* アプリケーション統合
  * AWS Step Functions: 分散アプリケーションの調整
  * Amazon AppFlow: SaaS アプリと AWS のサービス向けにコード統合が不要
  * Amazon EventBridge: SaaS アプリと AWS のサービス向けサーバーレスイベントバス
  * Amazon MQ: ActiveMQ 向けマネージド型メッセージブローカーサービス
  * Amazon Simple Notification Service (SNS): Pub/Sub、モバイルプッシュ、SMS
  * Amazon Simple Queue Service (SQS) : マネージド型メッセージキュー
  * Amazon AppSync: 多くのソースから適切なデータを使用して、大規模にアプリを強化
* AR およびバーチャルリアリティ
  * Amazon Sumerian: VR および AR アプリケーションの構築と実行
* AWS コスト管理
  * AWS Cost Explorer: AWS のコストと使用状況を分析する
  * AWS 予算: カスタムコストと使用予算を設定する
  * AWS のコストと使用状況レポート: 包括的なコストと使用状況情報へのアクセス
  * リザーブドインスタンスレポート: リザーブドインスタンス (RI) の詳細を把握する
  * Savings Plans: 柔軟な料金設定でコンピューティング使用コストを最大 72% 節約
* ブロックチェーン
  * Amazon Managed Blockchain: スケーラブルなブロックチェーンネットワークを作成および管理
  * Amazon Quantum Ledger Database (QLDB): フルマネージド型台帳データベース
* ビジネスアプリケーション
  * Alexa for Business: Alexa を使って組織を強化
  * Amazon Chime: フラストレーションフリーの会議、ビデオ電話、チャット
  * Amazon Honeycode (ベータ): プログラミングなしでモバイルおよびウェブアプリケーションを構築
  * Amazon WorkDocs: エンタープライズドキュメントの安全なストレージと共有
  * Amazon WorkMail: セキュリティで保護されたマネージド型の企業向け E メールおよびカレンダー
* コンピューティング
  * Amazon EC2: クラウド内の仮想サーバー
  * Amazon EC2 Auto Scaling: 需要に合わせてコンピューティング性能をスケール
  * Amazon Lightsail: 仮想プライベートサーバーを起動および管理
  * AWS Batch: あらゆる規模でバッチジョブを実行
  * AWS Elastic Beanstalk: ウェブアプリの実行と管理
  * AWS Lambda: イベント発生時にコードを実行
  * AWS Outposts: AWS サービスをオンプレミスで実行
  * AWS Serverless Application Repository: サーバーレスアプリケーションを検索、デプロイ、公開する
  * AWS Snow ファミリー: エッジロケーションでデータを集約および処理してから AWS に転送する物理デバイス
  * AWS Wavelength: 5G デバイスのための超低レイテンシーアプリケーションを提供
  * AWS における VMware クラウド: カスタムハードウェアを使用せずにハイブリッドクラウドを構築する
* コンテナ
  * AWS App2Container: 既存のアプリケーションをコンテナ化して移行
  * Amazon Elastic Container Registry: コンテナイメージを簡単に保存、管理、デプロイ
  * Amazon Elastic Container Service (ECS): コンテナを実行するためのきわめて安全で、信頼性と拡張性が高い方法
  * Amazon Elastic Kubernetes Service (EKS): Kubernetes のもっとも信頼性の高い実行方法
  * AWS Fargate: コンテナ向けサーバーレスコンピューティング
* カスタマーエンゲージメント
  * Amazon Connect: クラウドベースのコンタクトセンター
  * Amazon Pinpoint: チャンネル間でのパーソナライズされたユーザーエンゲージメント
  * Amazon Simple Email Service (SES): E メールの送受信
  * Contact Lens for Amazon Connect: ML 駆動のコンタクトセンター分析
* データベース
  * Amazon Aurora: 高性能マネージドリレーショナルデータベース
  * Amazon DynamoDB: マネージド型 NoSQL データベース
  * Amazon DocumentDB (MongoDB 互換): フルマネージド型ドキュメントデータベース
  * Amazon ElastiCache: インメモリキャッシングシステム
  * Amazon Keyspaces (Apache Cassandra 用): マネージド型の Cassandra 対応データベース
  * Amazon Neptune : フルマネージド型グラフデータベースサービス
  * Amazon Quantum Ledger Database (QLDB): フルマネージド型台帳データベース
  * Amazon RDS: MySQL、PostgresSQL、Oracle、SQL Server、MariaDB 向けのマネージドリレーショナルデータベースサービス
  * Amazon RDS on VMware: オンプレミスデータベースの管理を自動化
  * Amazon Redshift: 高速、シンプル、費用対効果の高いデータウェアハウジング
  * Amazon Timestream: フルマネージド型の時系列データベース
  * AWS Database Migration Service: 最小限のダウンタイムでデータベースを移行
* 開発者用ツール
  * Amazon Corretto: 本番環境に向けて OpenJDK を配信
  * AWS Cloud Development Kit (CDK): コードを使用してクラウドインフラストラクチャをモデル化する
  * AWS Cloud9: Cloud IDE でコードを記述、実行、デバッグ
  * AWS CodeArtifact: ソフトウェア開発のための安全かつスケーラブルで費用対効果の高いアーティファクト管理
  * AWS CodeBuild: コードのビルドとテスト
  * AWS CodeCommit: プライベート Git リポジトリでのコードの保存
  * AWS CodeDeploy: コードデプロイの自動化
  * AWS CodePipeline: 継続的デリバリーを使用したソフトウェアのリリース
  * AWS CodeStar: AWS アプリケーションの開発とデプロイ
  * AWS コマンドラインインターフェイス: AWS サービスを管理するための統合ツール
  * AWS Device Farm: AWS クラウド内の実際のデバイスを使った Android、iOS、ウェブアプリケーションのテスト
  * AWS ツールと SDK: AWS のツールと SDK
  * AWS X-Ray: アプリケーションの分析とデバッグ
* エンドユーザーコンピューティング
  * Amazon AppStream 2.0: デスクトップアプリケーションを安全にブラウザへストリーミングするサービスです
  * Amazon WorkDocs: エンタープライズドキュメントの安全なストレージと共有
  * Amazon WorkLink: 社内のウェブサイトへのモバイルアクセスを可能にする
  * Amazon WorkSpaces: デスクトップコンピューティングサービス
* Game Tech
  * Amazon GameLift: シンプルで高速な費用対効果の高い専用ゲームサーバーホスティング
  * Amazon Lumberyard: AWS や Twitch と統合された完全なソースを利用できる、無料のクロスプラットフォーム 3D ゲームエンジンです。
* IoT(モノのインターネット)
  * AWS IoT Core: デバイスをクラウドに接続
  * AWS Greengrass: デバイスのローカルでのコンピューティング、メッセージング、および同期
  * AWS IoT 1-Click: AWS Lambda トリガーのワンクリック作成
  * AWS IoT Analytics: IoT デバイスの分析
  * AWS IoT ボタン: クラウドのプログラミング可能なダッシュボタン
  * AWS IoT Device Defender: IoT デバイスのセキュリティ管理
  * AWS IoT Device Management: IoT デバイスのオンボード、編成、リモート管理
  * AWS IoT Events: IoT イベントを検出し、対応
  * AWS IoT SiteWise: IoT データコレクターおよびインタプリタ
  * AWS IoT Things Graph: デバイスおよびウェブサービスを簡単に接続
  * AWS Partner Device Catalog: AWS 互換の IoT ハードウェアの精選カタログ
  * FreeRTOS: マイクロコントローラ向けリアルタイムオペレーティングシステム
* Machine Learning
  * Amazon SageMaker: 機械学習モデルを大規模に構築、トレーニング、デプロイ
  * Amazon Augmented AI: ML 予測のヒューマンレビューを簡単に導入
  * Amazon CodeGuru: 最もコストがかかるコード行を見つける
  * Amazon Comprehend: テキストのインサイトや関係性を検出
  * Amazon Elastic Inference: 深層学習の推論を高速化
  * Amazon Forecast: 機械学習を使用して予測の精度を向上させる
  * Amazon Fraud Detector (プレビュー): オンライン詐欺をより素早く検知
  * Amazon Kendra: ML を利用してエンタープライズ検索をさらに進化
  * Amazon Lex: 音声やテキストに対応するチャットボットの構築
  * Amazon Personalize: アプリケーションにリアルタイムの推奨を構築する
  * Amazon Polly: テキストを生きた話し声に変換
  * Amazon Rekognition: イメージとビデオを分析
  * Amazon SageMaker Ground Truth: 精度の高い機械学習トレーニングデータセットの構築
  * Amazon Textract: ドキュメントからテキストやデータを抽出する
  * Amazon Translate: 自然で流ちょうな言語翻訳
  * Amazon Transcribe: 自動音声認識
  * AWS 深層学習 AMI: EC2 で今すぐ深層学習を始める
  * AWS Deep Learning Containers: 深層学習向け Docker イメージ
  * AWS DeepComposer: ML が有効化されたミュージカルキーボード
  * AWS DeepLens: 深層学習に対応したビデオカメラ
  * AWS DeepRacer: 機械学習による 18 分の 1 のスケールでの自律走行型レースカー
  * Amazon Inferentia: 機械学習推論チップ
  * AWS での PyTorch: 柔軟なオープンソースの機械学習フレームワーク
  * AWS での Apache MXNet: スケーラブルでパフォーマンスに優れた深層学習
  * AWS での TensorFlow: オープンソースの Machine Intelligence Library
* マネジメントとガバナンス
  * Amazon CloudWatch: リソースとアプリケーションのモニタリング
  * AWS Auto Scaling: 需要に合わせて複数のリソースをスケール
  * AWS Chatbot: ChatOps for AWS
  * AWS CloudFormation: テンプレートを使ったリソースの作成と管理
  * AWS CloudTrail: ユーザーアクティビティと API 使用状況の追跡
  * AWS コマンドラインインターフェイス: AWS サービスを管理するための統合ツール
  * AWS Compute Optimizer: 最適な AWS コンピューティングリソースを特定
  * AWS Config: リソースのインベントリと変更の追跡
  * AWS Control Tower: 安全かつ基準に準拠した複数のアカウント環境をセットアップおよび管理
  * AWS コンソールモバイルアプリケーション: リソースの状態を外出先で確認
  * AWS License Manager: ライセンスの追跡、管理、制御
  * AWS マネジメントコンソール: ウェブベースのユーザーインターフェイス
  * AWS Managed Services: AWS のインフラストラクチャ運用管理
  * AWS OpsWorks: Chef や Puppet を使って運用を自動化する
  * AWS Organizations: AWS アカウント全体の一元管理
  * AWS Personal Health Dashboard: AWS のサービス状態のパーソナライズされた表示
  * AWS Service Catalog: 標準化された製品の作成および使用
  * AWS Systems Manager: 運用時の洞察を改善し、実行
  * AWS Trusted Advisor: パフォーマンスとセキュリティの最適化
  * AWS Well-Architected Tool: ワークロードの見直しと改善
* メディアサービス
  * Amazon Elastic Transcoder: スケーラブルで使いやすいメディア変換サービス
  * Amazon Kinesis Video Streams: ビデオストリームの処理と分析
  * AWS Elemental MediaConnect: 高信頼性、高安全性のライブ動画転送
  * AWS Elemental MediaConvert: ファイルベースのビデオコンテンツを変換
  * AWS Elemental MediaLive: ライブビデオコンテンツを変換
  * AWS Elemental MediaPackage: 動画の発信とパッケージ化
  * AWS Elemental MediaStore: メディアストレージとシンプルな HTTP オリジン
  * AWS Elemental MediaTailor: 動画のパーソナライズと収益化
  * AWS Elemental アプライアンスとソフトウェア: オンプレミスメディアソリューション
* 移行と転送
  * AWS Migration Hub: 複数の移行を 1 か所で追跡
  * AWS Application Discovery Service: オンプレミスのアプリケーションを検出して合理的に移行
  * AWS Database Migration Service: 最小限のダウンタイムでデータベースを移行
  * AWS DataSync: シンプルかつ高速なオンラインデータ転送
  * AWS Server Migration Service : AWS へのオンプレミスサーバーの移行
  * AWS Snow ファミリー: AWS との間でデータを移行するための物理的デバイス
  * AWS Transfer Family: フルマネージド SFTP、FTPS、および FTP サービス
  * CloudEndure Migration: AWS への大規模な移行を自動化
  * Migration Evaluator (旧 TSO Logic): クラウド移行のビジネスケースを作成
* モバイル
  * AWS Amplify: モバイルアプリケーションとウェブアプリケーションの構築とデプロイ
  * Amazon API Gateway: API を構築し、デプロイし、管理する
  * Amazon Pinpoint: チャンネル間でのパーソナライズされたユーザーエンゲージメント
  * AWS AppSync: 多くのソースから適切なデータを使用して、大規模にアプリを強化
  * AWS Device Farm: AWS クラウド内の実際のデバイスを使った Android、iOS、ウェブアプリケーションのテスト
* ネットワーキングとコンテンツ配信
  * Amazon VPC: 独立したクラウドリソース
  * Amazon API Gateway: API を構築、デプロイ、管理
  * Amazon CloudFront: グローバルコンテンツ配信ネットワーク
  * Amazon Route 53: スケーラブルなドメインネームシステム (DNS)
  * AWS PrivateLink: AWS でホストされているサービスに安全にアクセス
  * AWS App Mesh: マイクロサービスをモニタリングおよびコントロール
  * AWS Cloud Map: マイクロサービス向けのアプリケーションリソースレジストリ
  * AWS Direct Connect: AWS への専用ネットワーク接続
  * AWS Global Accelerator: アプリケーションの可用性とパフォーマンスを向上
  * AWS Transit Gateway: VPC およびアカウント接続を簡単にスケール
  * Elastic Load Balancing: 複数のターゲットにわたる着信トラフィックの分配
* 量子テクノロジー
  * Amazon Braket: 量子コンピューティングを探索して実験
* ロボット工学
  * AWS RoboMaker: ロボット工学アプリケーションの開発、テスト、デプロイ
* 人工衛星
  * AWS Ground Station: サービスとしてのフルマネージド型地上局
* セキュリティ、アイデンティティ、コンプライアンス
  * AWS Identity & Access Management: サービスとリソースへのアクセスを安全に管理
  * Amazon Cognito: アプリの ID 管理
  * Amazon Detective: 潜在的なセキュリティ問題を調査
  * Amazon GuardDuty: マネージド型脅威検出サービス
  * Amazon Inspector: アプリケーションのセキュリティの分析
  * Amazon Macie: 大規模な機密データを検出して保護する
  * AWS Artifact: AWS のコンプライアンスレポートへのオンデマンドアクセス
  * AWS Certificate Manager: SSL/TLS 証明書のプロビジョン、管理およびデプロイ
  * AWS CloudHSM: 法令遵守のためのハードウェアベースキーストレージ
  * AWS Directory Service: Active Directory のホスティングと管理
  * AWS Firewall Manager: ファイアウォールルールの一元管理
  * AWS Key Management Service: マネージド型の暗号化キー作成と管理
  * AWS Resource Access Manager: AWS のリソースを共有するためのシンプルで安全なサービス
  * AWS Secrets Manager: シークレットのローテーション、管理、取得
  * AWS Security Hub: 統合された AWS セキュリティ & コンプライアンスセンター
  * AWS Shield: DDoS 保護
  * AWS Single Sign-On: クラウドシングルサインオン (SSO) サービス
  * AWS WAF: 悪意のあるウェブトラフィックのフィルター
* ストレージ
  * Amazon Simple Storage Service (S3): スケーラブルなクラウドストレージ
  * Amazon Elastic Block Store (EBS): EC2 ブロックストレージボリューム
  * Amazon Elastic File System (EFS): EC2 用フルマネージド型ファイルシステム
  * Amazon FSx for Lustre: S3 と統合されたハイパフォーマンスファイルシステム
  * Amazon FSx for Windows File Server: フルマネージド型 Windows ネイティブのファイルシステム
  * Amazon S3 Glacier: クラウド上の低コストなアーカイブストレージ
  * AWS Backup: AWS のサービス全体にわたる一元管理型バックアップ
  * AWS Snow ファミリー: 厳しい環境や切断された環境向けの物理エッジコンピューティングおよびストレージデバイス
  * AWS Storage Gateway: ハイブリッドストレージの統合
  * CloudEndure の災害対策: 高度に自動化した災害対策

おまけ

  • AWSのリージョン一覧を取得する(curlとjqを使用)
curl -s https://raw.githubusercontent.com/boto/botocore/develop/botocore/data/endpoints.json | jq -r '.partitions[] as $p | $p.regions as $r | $r|keys[] | [$p.partitionName, ., $r[.].description] | @tsv'
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSプロダクト1行まとめ(を取得する)

tl;dr

  • AWSのプロダクトが色々ありすぎて、正直フォローしきれない
  • 年に1度くらいQiitaに上がるAWSサービス3行まとめ記事を読むけど、3歩歩いたら忘れてしまう
  • Qiitaの記事待ちじゃなくて、その時々で最新の情報をサクッと把握したい

やり方

  • 下記のシェルスクリプトを実行する。
curl -s "https://aws.amazon.com/jp/products/" | awk 'f==1{f=0;gsub(/ {2,}/,"",$0);split($0,s,"<span>");gsub(/<[^>]*>/,"",s[1]);gsub(/<[^>]*>/,"",s[2]);if(length(s[2])){print "  *"s[1]": "s[2]}}/lb-content-item/{f=1}/lb-trigger /{gsub(/ {2,}/,"",$0);gsub(/<[^>]*>/,"",$0);sub(/^ /,"* ",$0);print $0}' | sed -E "s:amp;::g" | sed -E "s: *$::g"
  • WindowsだしWSLも導入して無いよ、という人はWSLを導入する。下記のPowerShellで代用する。ogvはフィルタで絞れて便利だし。
Invoke-WebRequest "https://aws.amazon.com/jp/products/" | %{$_.Content -split "`n" | ?{$_ -match '<a href="/'} | ?{$_ -match "span" } | %{($_ -replace "<[^>]+>","`t").Trim() | %{$s = $_ -split "`t"; [PSCustomObject]@{"name"=$s[0];"desc"=$s[1]} }}} | sort -Unique name | ogv

2020/7/10時点でのレスポンス

* 分析
  * Amazon Athena: SQL を使用した S3 でのデータクエリ
  * Amazon CloudSearch: マネージド型検索サービス
  * Amazon Elasticsearch Service: Elasticsearch クラスターを実行し、スケールする
  * Amazon EMR: ホスト型 Hadoop フレームワーク
  * Amazon Kinesis: リアルタイムストリーミングデータとの連携
  * Amazon Managed Streaming for Apache Kafka: フルマネージド型 Apache Kafka サービス
  * Amazon Redshift: 高速かつシンプルで、費用対効果の高いデータウェアハウス
  * Amazon QuickSight: 高速ビジネス分析サービス
  * AWS Data Exchange: クラウド内サードパーティのデータを検索、購読、および使用
  * AWS Data Pipeline: 定期的なデータ駆動型ワークフローに対するオーケストレーションサービス
  * AWS Glue: データの準備とロード
  * AWS Lake Formation: 安全なデータレイクを数日で構築
* アプリケーション統合
  * AWS Step Functions: 分散アプリケーションの調整
  * Amazon AppFlow: SaaS アプリと AWS のサービス向けにコード統合が不要
  * Amazon EventBridge: SaaS アプリと AWS のサービス向けサーバーレスイベントバス
  * Amazon MQ: ActiveMQ 向けマネージド型メッセージブローカーサービス
  * Amazon Simple Notification Service (SNS): Pub/Sub、モバイルプッシュ、SMS
  * Amazon Simple Queue Service (SQS) : マネージド型メッセージキュー
  * Amazon AppSync: 多くのソースから適切なデータを使用して、大規模にアプリを強化
* AR およびバーチャルリアリティ
  * Amazon Sumerian: VR および AR アプリケーションの構築と実行
* AWS コスト管理
  * AWS Cost Explorer: AWS のコストと使用状況を分析する
  * AWS 予算: カスタムコストと使用予算を設定する
  * AWS のコストと使用状況レポート: 包括的なコストと使用状況情報へのアクセス
  * リザーブドインスタンスレポート: リザーブドインスタンス (RI) の詳細を把握する
  * Savings Plans: 柔軟な料金設定でコンピューティング使用コストを最大 72% 節約
* ブロックチェーン
  * Amazon Managed Blockchain: スケーラブルなブロックチェーンネットワークを作成および管理
  * Amazon Quantum Ledger Database (QLDB): フルマネージド型台帳データベース
* ビジネスアプリケーション
  * Alexa for Business: Alexa を使って組織を強化
  * Amazon Chime: フラストレーションフリーの会議、ビデオ電話、チャット
  * Amazon Honeycode (ベータ): プログラミングなしでモバイルおよびウェブアプリケーションを構築
  * Amazon WorkDocs: エンタープライズドキュメントの安全なストレージと共有
  * Amazon WorkMail: セキュリティで保護されたマネージド型の企業向け E メールおよびカレンダー
* コンピューティング
  * Amazon EC2: クラウド内の仮想サーバー
  * Amazon EC2 Auto Scaling: 需要に合わせてコンピューティング性能をスケール
  * Amazon Lightsail: 仮想プライベートサーバーを起動および管理
  * AWS Batch: あらゆる規模でバッチジョブを実行
  * AWS Elastic Beanstalk: ウェブアプリの実行と管理
  * AWS Lambda: イベント発生時にコードを実行
  * AWS Outposts: AWS サービスをオンプレミスで実行
  * AWS Serverless Application Repository: サーバーレスアプリケーションを検索、デプロイ、公開する
  * AWS Snow ファミリー: エッジロケーションでデータを集約および処理してから AWS に転送する物理デバイス
  * AWS Wavelength: 5G デバイスのための超低レイテンシーアプリケーションを提供
  * AWS における VMware クラウド: カスタムハードウェアを使用せずにハイブリッドクラウドを構築する
* コンテナ
  * AWS App2Container: 既存のアプリケーションをコンテナ化して移行
  * Amazon Elastic Container Registry: コンテナイメージを簡単に保存、管理、デプロイ
  * Amazon Elastic Container Service (ECS): コンテナを実行するためのきわめて安全で、信頼性と拡張性が高い方法
  * Amazon Elastic Kubernetes Service (EKS): Kubernetes のもっとも信頼性の高い実行方法
  * AWS Fargate: コンテナ向けサーバーレスコンピューティング
* カスタマーエンゲージメント
  * Amazon Connect: クラウドベースのコンタクトセンター
  * Amazon Pinpoint: チャンネル間でのパーソナライズされたユーザーエンゲージメント
  * Amazon Simple Email Service (SES): E メールの送受信
  * Contact Lens for Amazon Connect: ML 駆動のコンタクトセンター分析
* データベース
  * Amazon Aurora: 高性能マネージドリレーショナルデータベース
  * Amazon DynamoDB: マネージド型 NoSQL データベース
  * Amazon DocumentDB (MongoDB 互換): フルマネージド型ドキュメントデータベース
  * Amazon ElastiCache: インメモリキャッシングシステム
  * Amazon Keyspaces (Apache Cassandra 用): マネージド型の Cassandra 対応データベース
  * Amazon Neptune : フルマネージド型グラフデータベースサービス
  * Amazon Quantum Ledger Database (QLDB): フルマネージド型台帳データベース
  * Amazon RDS: MySQL、PostgresSQL、Oracle、SQL Server、MariaDB 向けのマネージドリレーショナルデータベースサービス
  * Amazon RDS on VMware: オンプレミスデータベースの管理を自動化
  * Amazon Redshift: 高速、シンプル、費用対効果の高いデータウェアハウジング
  * Amazon Timestream: フルマネージド型の時系列データベース
  * AWS Database Migration Service: 最小限のダウンタイムでデータベースを移行
* 開発者用ツール
  * Amazon Corretto: 本番環境に向けて OpenJDK を配信
  * AWS Cloud Development Kit (CDK): コードを使用してクラウドインフラストラクチャをモデル化する
  * AWS Cloud9: Cloud IDE でコードを記述、実行、デバッグ
  * AWS CodeArtifact: ソフトウェア開発のための安全かつスケーラブルで費用対効果の高いアーティファクト管理
  * AWS CodeBuild: コードのビルドとテスト
  * AWS CodeCommit: プライベート Git リポジトリでのコードの保存
  * AWS CodeDeploy: コードデプロイの自動化
  * AWS CodePipeline: 継続的デリバリーを使用したソフトウェアのリリース
  * AWS CodeStar: AWS アプリケーションの開発とデプロイ
  * AWS コマンドラインインターフェイス: AWS サービスを管理するための統合ツール
  * AWS Device Farm: AWS クラウド内の実際のデバイスを使った Android、iOS、ウェブアプリケーションのテスト
  * AWS ツールと SDK: AWS のツールと SDK
  * AWS X-Ray: アプリケーションの分析とデバッグ
* エンドユーザーコンピューティング
  * Amazon AppStream 2.0: デスクトップアプリケーションを安全にブラウザへストリーミングするサービスです
  * Amazon WorkDocs: エンタープライズドキュメントの安全なストレージと共有
  * Amazon WorkLink: 社内のウェブサイトへのモバイルアクセスを可能にする
  * Amazon WorkSpaces: デスクトップコンピューティングサービス
* Game Tech
  * Amazon GameLift: シンプルで高速な費用対効果の高い専用ゲームサーバーホスティング
  * Amazon Lumberyard: AWS や Twitch と統合された完全なソースを利用できる、無料のクロスプラットフォーム 3D ゲームエンジンです。
* IoT(モノのインターネット)
  * AWS IoT Core: デバイスをクラウドに接続
  * AWS Greengrass: デバイスのローカルでのコンピューティング、メッセージング、および同期
  * AWS IoT 1-Click: AWS Lambda トリガーのワンクリック作成
  * AWS IoT Analytics: IoT デバイスの分析
  * AWS IoT ボタン: クラウドのプログラミング可能なダッシュボタン
  * AWS IoT Device Defender: IoT デバイスのセキュリティ管理
  * AWS IoT Device Management: IoT デバイスのオンボード、編成、リモート管理
  * AWS IoT Events: IoT イベントを検出し、対応
  * AWS IoT SiteWise: IoT データコレクターおよびインタプリタ
  * AWS IoT Things Graph: デバイスおよびウェブサービスを簡単に接続
  * AWS Partner Device Catalog: AWS 互換の IoT ハードウェアの精選カタログ
  * FreeRTOS: マイクロコントローラ向けリアルタイムオペレーティングシステム
* Machine Learning
  * Amazon SageMaker: 機械学習モデルを大規模に構築、トレーニング、デプロイ
  * Amazon Augmented AI: ML 予測のヒューマンレビューを簡単に導入
  * Amazon CodeGuru: 最もコストがかかるコード行を見つける
  * Amazon Comprehend: テキストのインサイトや関係性を検出
  * Amazon Elastic Inference: 深層学習の推論を高速化
  * Amazon Forecast: 機械学習を使用して予測の精度を向上させる
  * Amazon Fraud Detector (プレビュー): オンライン詐欺をより素早く検知
  * Amazon Kendra: ML を利用してエンタープライズ検索をさらに進化
  * Amazon Lex: 音声やテキストに対応するチャットボットの構築
  * Amazon Personalize: アプリケーションにリアルタイムの推奨を構築する
  * Amazon Polly: テキストを生きた話し声に変換
  * Amazon Rekognition: イメージとビデオを分析
  * Amazon SageMaker Ground Truth: 精度の高い機械学習トレーニングデータセットの構築
  * Amazon Textract: ドキュメントからテキストやデータを抽出する
  * Amazon Translate: 自然で流ちょうな言語翻訳
  * Amazon Transcribe: 自動音声認識
  * AWS 深層学習 AMI: EC2 で今すぐ深層学習を始める
  * AWS Deep Learning Containers: 深層学習向け Docker イメージ
  * AWS DeepComposer: ML が有効化されたミュージカルキーボード
  * AWS DeepLens: 深層学習に対応したビデオカメラ
  * AWS DeepRacer: 機械学習による 18 分の 1 のスケールでの自律走行型レースカー
  * Amazon Inferentia: 機械学習推論チップ
  * AWS での PyTorch: 柔軟なオープンソースの機械学習フレームワーク
  * AWS での Apache MXNet: スケーラブルでパフォーマンスに優れた深層学習
  * AWS での TensorFlow: オープンソースの Machine Intelligence Library
* マネジメントとガバナンス
  * Amazon CloudWatch: リソースとアプリケーションのモニタリング
  * AWS Auto Scaling: 需要に合わせて複数のリソースをスケール
  * AWS Chatbot: ChatOps for AWS
  * AWS CloudFormation: テンプレートを使ったリソースの作成と管理
  * AWS CloudTrail: ユーザーアクティビティと API 使用状況の追跡
  * AWS コマンドラインインターフェイス: AWS サービスを管理するための統合ツール
  * AWS Compute Optimizer: 最適な AWS コンピューティングリソースを特定
  * AWS Config: リソースのインベントリと変更の追跡
  * AWS Control Tower: 安全かつ基準に準拠した複数のアカウント環境をセットアップおよび管理
  * AWS コンソールモバイルアプリケーション: リソースの状態を外出先で確認
  * AWS License Manager: ライセンスの追跡、管理、制御
  * AWS マネジメントコンソール: ウェブベースのユーザーインターフェイス
  * AWS Managed Services: AWS のインフラストラクチャ運用管理
  * AWS OpsWorks: Chef や Puppet を使って運用を自動化する
  * AWS Organizations: AWS アカウント全体の一元管理
  * AWS Personal Health Dashboard: AWS のサービス状態のパーソナライズされた表示
  * AWS Service Catalog: 標準化された製品の作成および使用
  * AWS Systems Manager: 運用時の洞察を改善し、実行
  * AWS Trusted Advisor: パフォーマンスとセキュリティの最適化
  * AWS Well-Architected Tool: ワークロードの見直しと改善
* メディアサービス
  * Amazon Elastic Transcoder: スケーラブルで使いやすいメディア変換サービス
  * Amazon Kinesis Video Streams: ビデオストリームの処理と分析
  * AWS Elemental MediaConnect: 高信頼性、高安全性のライブ動画転送
  * AWS Elemental MediaConvert: ファイルベースのビデオコンテンツを変換
  * AWS Elemental MediaLive: ライブビデオコンテンツを変換
  * AWS Elemental MediaPackage: 動画の発信とパッケージ化
  * AWS Elemental MediaStore: メディアストレージとシンプルな HTTP オリジン
  * AWS Elemental MediaTailor: 動画のパーソナライズと収益化
  * AWS Elemental アプライアンスとソフトウェア: オンプレミスメディアソリューション
* 移行と転送
  * AWS Migration Hub: 複数の移行を 1 か所で追跡
  * AWS Application Discovery Service: オンプレミスのアプリケーションを検出して合理的に移行
  * AWS Database Migration Service: 最小限のダウンタイムでデータベースを移行
  * AWS DataSync: シンプルかつ高速なオンラインデータ転送
  * AWS Server Migration Service : AWS へのオンプレミスサーバーの移行
  * AWS Snow ファミリー: AWS との間でデータを移行するための物理的デバイス
  * AWS Transfer Family: フルマネージド SFTP、FTPS、および FTP サービス
  * CloudEndure Migration: AWS への大規模な移行を自動化
  * Migration Evaluator (旧 TSO Logic): クラウド移行のビジネスケースを作成
* モバイル
  * AWS Amplify: モバイルアプリケーションとウェブアプリケーションの構築とデプロイ
  * Amazon API Gateway: API を構築し、デプロイし、管理する
  * Amazon Pinpoint: チャンネル間でのパーソナライズされたユーザーエンゲージメント
  * AWS AppSync: 多くのソースから適切なデータを使用して、大規模にアプリを強化
  * AWS Device Farm: AWS クラウド内の実際のデバイスを使った Android、iOS、ウェブアプリケーションのテスト
* ネットワーキングとコンテンツ配信
  * Amazon VPC: 独立したクラウドリソース
  * Amazon API Gateway: API を構築、デプロイ、管理
  * Amazon CloudFront: グローバルコンテンツ配信ネットワーク
  * Amazon Route 53: スケーラブルなドメインネームシステム (DNS)
  * AWS PrivateLink: AWS でホストされているサービスに安全にアクセス
  * AWS App Mesh: マイクロサービスをモニタリングおよびコントロール
  * AWS Cloud Map: マイクロサービス向けのアプリケーションリソースレジストリ
  * AWS Direct Connect: AWS への専用ネットワーク接続
  * AWS Global Accelerator: アプリケーションの可用性とパフォーマンスを向上
  * AWS Transit Gateway: VPC およびアカウント接続を簡単にスケール
  * Elastic Load Balancing: 複数のターゲットにわたる着信トラフィックの分配
* 量子テクノロジー
  * Amazon Braket: 量子コンピューティングを探索して実験
* ロボット工学
  * AWS RoboMaker: ロボット工学アプリケーションの開発、テスト、デプロイ
* 人工衛星
  * AWS Ground Station: サービスとしてのフルマネージド型地上局
* セキュリティ、アイデンティティ、コンプライアンス
  * AWS Identity & Access Management: サービスとリソースへのアクセスを安全に管理
  * Amazon Cognito: アプリの ID 管理
  * Amazon Detective: 潜在的なセキュリティ問題を調査
  * Amazon GuardDuty: マネージド型脅威検出サービス
  * Amazon Inspector: アプリケーションのセキュリティの分析
  * Amazon Macie: 大規模な機密データを検出して保護する
  * AWS Artifact: AWS のコンプライアンスレポートへのオンデマンドアクセス
  * AWS Certificate Manager: SSL/TLS 証明書のプロビジョン、管理およびデプロイ
  * AWS CloudHSM: 法令遵守のためのハードウェアベースキーストレージ
  * AWS Directory Service: Active Directory のホスティングと管理
  * AWS Firewall Manager: ファイアウォールルールの一元管理
  * AWS Key Management Service: マネージド型の暗号化キー作成と管理
  * AWS Resource Access Manager: AWS のリソースを共有するためのシンプルで安全なサービス
  * AWS Secrets Manager: シークレットのローテーション、管理、取得
  * AWS Security Hub: 統合された AWS セキュリティ & コンプライアンスセンター
  * AWS Shield: DDoS 保護
  * AWS Single Sign-On: クラウドシングルサインオン (SSO) サービス
  * AWS WAF: 悪意のあるウェブトラフィックのフィルター
* ストレージ
  * Amazon Simple Storage Service (S3): スケーラブルなクラウドストレージ
  * Amazon Elastic Block Store (EBS): EC2 ブロックストレージボリューム
  * Amazon Elastic File System (EFS): EC2 用フルマネージド型ファイルシステム
  * Amazon FSx for Lustre: S3 と統合されたハイパフォーマンスファイルシステム
  * Amazon FSx for Windows File Server: フルマネージド型 Windows ネイティブのファイルシステム
  * Amazon S3 Glacier: クラウド上の低コストなアーカイブストレージ
  * AWS Backup: AWS のサービス全体にわたる一元管理型バックアップ
  * AWS Snow ファミリー: 厳しい環境や切断された環境向けの物理エッジコンピューティングおよびストレージデバイス
  * AWS Storage Gateway: ハイブリッドストレージの統合
  * CloudEndure の災害対策: 高度に自動化した災害対策

おまけ

  • AWSのリージョン一覧を取得する(curlとjqを使用)
curl -s https://raw.githubusercontent.com/boto/botocore/develop/botocore/data/endpoints.json | jq -r '.partitions[] as $p | $p.regions as $r | $r|keys[] | [$p.partitionName, ., $r[.].description] | @tsv'
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon EC2 インスタンスにAWS Cloud9開発環境を作成する

目次

  1. 概要
  2. AWS Cloud9を立ち上げる
  3. AWS Cloud9でPythonを使ってみる

1. 概要

開発環境が欲しいけど、いちいちServerの設定をするのが面倒ですよね。。
そんなあなたに便利なのが、AWS Cloud9です。

Serverの設定なしで、いきなりコードを書き始められます!

参照 : AWS Cloud9

AWS Cloud9 は、ブラウザのみでコードを記述、実行、デバッグできるクラウドベースの統合開発環境 (IDE) です。
これには、コードエディタ、デバッガー、ターミナルが含まれています。Cloud9 には、JavaScript、Python、PHP などの一般的なプログラム言語に不可欠なツールがあらかじめパッケージ化されているため、新しいプロジェクトを開始するためにファイルをインストールしたり、開発マシンを設定したりする必要はありません。

Screen Shot 2020-07-09 at 23.18.54.png

2. AWS Cloud9を立ち上げる

AWSアカウントを持っていない人は、是非このQiitaの記事を参考にして作成してみてください
AWS 無料アカウントの作成方法

2-1. AWS マネジメントコンソールにLoginする

下記のURLへアクセスする
https://console.aws.amazon.com/

Screen Shot 2020-07-09 at 23.23.33.png

2-2. Regionを変更する (必要であれば)

個人的には、「東京」Regionが好きなので、Defaultの「オハイオ」から変更します
Screen Shot 2020-07-09 at 23.23.43.png

無事、「東京」に変わりました
Screen Shot 2020-07-09 at 23.28.27.png

2-3. Cloud9をクリック

左上にある「サービス」をクリック
Screen Shot 2020-07-09 at 23.30.32.png

こんな感じにサービス一覧が出てくる
Screen Shot 2020-07-09 at 23.32.09.png

一番下までスクロールすると、「開発者ツール」の箇所に「Cloud9」があるのでクリックする
Screen Shot 2020-07-09 at 23.33.29.png

こんな画面が出てきます(日本語対応してなく、英語のページです)
Screen Shot 2020-07-09 at 23.34.45.png

2-4. Cloud9環境を作成

「Create environment」をクリック
Screen Shot 2020-07-09 at 23.36.08.png

こんなページに遷移する
Screen Shot 2020-07-09 at 23.37.43.png

なに用途のCloud9環境か分かるように、「Name」と「Description(説明)」を入れて「Next step」をクリックする
Screen Shot 2020-07-09 at 23.44.07.png

環境設定の画面に遷移する
Screen Shot 2020-07-09 at 23.47.09.png

各自の環境に合わせて設定する

今回は、無料枠でのDemoをしたいので、「t2.micro」インスタンスを選択
また、OSはLinux系であれば特にこだわりはないので、「Amazon Linux」を選択

Cost-saving settingは、裏で処理を回したい時もあるので、接続していない時に勝手にDownされると困るので「Never」を設定
Screen Shot 2020-07-09 at 23.51.56.png

「Next step」をクリック
Screen Shot 2020-07-09 at 23.53.08.png

設定内容に最終確認して、「Create environent」をクリック
Screen Shot 2020-07-09 at 23.54.17.png

こんな感じで、Cloud9環境を作成してくれる(2-3分この状態で待つ)
Screen Shot 2020-07-09 at 23.55.41.png

Cloud9環境出来上がり!
Screen Shot 2020-07-09 at 23.57.13.png

3. AWS Cloud9でPythonを使ってみる

3-1. bashでpythonのVersionを確認してみる

一番下のConsole画面で下記のコマンドを入力
2020-07-10時点では、Python 3.6.10がDefaultで入っているらしい

Terminal
python -V

Screen Shot 2020-07-10 at 00.02.36.png

タブからもterminal画面は開けます
ezgif-4-52a91dfef452.gif

3-2. pythonのファイルを作成

タブの「+」を押して、New Fileを作成
Screen Shot 2020-07-10 at 00.17.34.png

「File」-> 「Save as」をクリック
Screen Shot 2020-07-10 at 00.19.37.png

適当な名前を設定して「save」をクリック
Screen Shot 2020-07-10 at 00.20.55.png

Screen Shot 2020-07-10 at 00.21.56.png

思い思いのCodeを書く
今回はテスト用なので、下記のCodeで実行する

qiita_python.py
print('hello world')
a = 1 + 2 - 3 * 4 
print(a)

Screen Shot 2020-07-10 at 00.24.16.png

3-3. 作成したDemo用のpythonを実行

「Run」をクリック
ezgif-4-e7ebfc3eed8f.gif

まとめ

こんな感じに、AWS Cloud9は開発環境を簡単に作成できるため非常におすすめです
是非、皆さんもTryしてみてくださいね

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む