1 Minute Tips

投稿者: sumito.tsukada

  • オンプレミスのライセンスごとAWSに移行方法

    オンプレミスの DB2、SAP、Windows などを AWS に移行する方法について

    • 移行方法
    • ライセンスの管理方法

    上記２点を考える必要がある。

    移行方法について

    これらのライセンスをそのまま移行するためには、

    EC2インスタンスにソフトウェアをインストールすることになる。

    そのための移行方法としてAWS SMSを利用してECインスタンスへの移行が選択肢になる。

    ライセンスの管理について

    AWS License Manager を利用する

    AWS License Manager の特徴

    ライセンスルールを定義。

    ライセンス対象となるソフトウェアをインストールしたEC2インスタンスに適用することができる。

    コンソールを利用してライセンス利用状況を追跡することも可能。

    ソフトウェアベンダーのライセンスを簡単に管理できるようになる。

    管理者はライセンス契約の規約をエミュレートするカスタマイズされたライセンスルールを作成することで、EC2 のインスタンスの起動時にそれらのルールを適用できる。

    管理者はこれらのルールを使用して、契約が定める以上のライセンスを使用する。

    または短期的に異なるサーバーにライセンスを再度割り当てるといったライセンス違反を規制できる。

    AWS License Manager は AWS のサービスと統合し、1 つの AWS アカウントを通じて、複数のアカウント、IT カタログ、オンプレミスにわたってライセンスの管理を簡素化することができる。

    また、ライセンス管理者は AWS Service Catalog でルールを追加することができる。

    参考情報

    AWS Licence Manager

    https://aws.amazon.com/jp/license-manager/features/

    AWS Service Catalog

    https://aws.amazon.com/jp/servicecatalog/features/

  • Amazon Rekognition について

    Amazon Rekognition

    画像検品作業は可能だが、

    画像検品に特化したサービスではない

    もし画像検品などを行いたい場合は、

    G2インスタンスにソフトウェアを導入するなどの対応が必要。

    低レイテンシネットワーキングを備えた高度なグラフィック処理サーバーについて言及する場合は、EC2インスタンスの中のG2インスタンスが最適。

  • Amazon SWF について

    Amazon SWF の特徴

    • マネージド型の状態トラッカー
    • タスクコーディネーター

    ユースケース

    開発者が

    • 並行したステップ
    • 連続したステップがあるバックグラウンドジョブを構築、実行

    するケース。

    SWFはAWSサービスとの人間のやり取りを含むワークフローをサポートするが、

    現在ではワークフロー作成にはSWFではなくAWS Step Functions の利用が推奨されている

    AWS Step Functions よりも Amazon SWFの使用が求められるユースケース

    • 結果を親に返す子プロセスを起動する場合
    • プロセスにおいて介入する外部信号が必要な場合

    公式は以下の通り

    https://aws.amazon.com/jp/step-functions/faqs/

  • AWS Organizations の[組織の証跡]について整理する

    「組織の証跡」とは

    組織内のマスターアカウントとすべてのメンバーアカウントの CloudTrail イベントを同じ

    • Amazon S3 バケット
    • CloudWatch Logs
    • CloudWatch イベント

    に配信できるようにする設定である。

    組織の証跡を作成すると、組織のための統一されたイベントログ記録戦略を定義するのに役立つ。

    組織の証跡を作成すると、自分の組織に属するすべての AWS アカウントに、指定した名前の証跡が作成される。

    メンバーアカウントで CloudTrail アクセス許可を持つユーザーは、

    • AWS アカウントから AWSCloudTrail コンソールにログインしたとき
    • describe-trails などの AWS CLI コマンドを実行したとき

    この証跡 (証跡 ARN を含む) を表示することができる。

    各AWSアカウントでアクティビティが発生すると、そのアクティビティはCloudTrailイベントに記録される。

    イベント履歴に移動すると、CloudTrailコンソールで最近のイベントを簡単に表示できる。

    マルチリージョンおよびグローバルイベントの追跡を有効にすることもできる。

    デフォルトでは、CloudTrailによってバケットに配信されるログファイルは、

    Amazon S3管理の暗号化キー（SSE-S3）を使用したAmazonサーバー側の暗号化によって暗号化される。

    直接管理可能なセキュリティレイヤーを提供するために、

    CloudTrailログファイルにAWS KMS管理キー（SSE-KMS）を使用したサーバーサイド暗号化を使用できる。

    ログを保護するには、S3バケットを暗号化し、バケット作成時にデータ削除不可の設定を行うことで、永続的にログを保存することが可能。

    マスターアカウントに対して単一のCloudTrailを有効化して、ターゲットアカウント設定において他の子アカウントをターゲット設定・・・と言うことは必要ない。

    AWS Organizationsを利用して、CloudTrailの「組織の証跡」を利用することで子アカウントにも自動的にCloudTrailログを設定することが可能になるからだ。

  • IPSec VPN の特徴

    デフォルトで Amazon VPC 内に起動されるインスタンスと、ユーザー独自のネットワークとの通信はできない。

    VPC から独自のネットワークへのアクセスを可能にするには、以下のアプローチが必要になる。

    1. 仮想プライベートゲートウェイを VPC に関連付ける
    2. カスタムルートテーブルを作成
    3. セキュリティグループ規則を更新
    4. AWS Site-to-Site VPN接続を作成する

    Site-to-Site VPN は、インターネットプロトコルセキュリティ (IPsec) VPN 接続をサポートしている。 

    IPSecの特徴

    • Site-to-Site VPN 接続は、AWS Classic VPN または AWS VPN のいずれか。
    • IPSecトンネル経由で送信されるデータの整合性を保持する。
    • IPSecトンネルを経由して送信されるデータは暗号化される。
    • IPSecはインターネット経由で送信中のデータを保護する。
    • IPSecトンネルのセットアップ中にIDが認証される。
    • VPNゲートウェイ（VPG）とカスタマーゲートウェイ（CGW）の間にIPSecトンネルが確立される。

    データは暗号化されるが、SSLを利用してはいるわけではないと言うのは大きな特徴だ。

    参考情報

    IPsec-VPNとは？SSL-VPNとの違いもわかりやすく徹底解説！

    https://it-trend.jp/vpn/article/48-0063

  • AWS Elastic Beanstalk の deploy policy を整理する

    AWS Elastic Beanstalk は、デプロイポリシーも含めデプロイを処理するいくつかのオプションがある。

    All at once

    新しいバージョンをすべてのインスタンスに同時に展開する。

    環境内のすべてのインスタンスは、展開が行われている間、短時間サービスが停止することになる。

    そのため、展開に必要な合計時間を最短にする方法にはなる。

    Rolling

    Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイする。

    そのため、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になる。

    つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在する。

    Rolling with additional batch

    新しいバージョンをバッチで展開するが、最初にインスタンスの新しいバッチを起動して、展開プロセス中に完全な容量を確保する。

    Immutable

    変更不可能な更新を実行して、古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動する。

    部分的に完了したローリングデプロイにより発生する問題を防止することができる。

    新しいインスタンスがヘルスチェックをパスしなかった場合、Elastic Beanstalkはそれを終了し、元のインスタンスをそのまま残す。

    参考情報

    https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html

  • AWSアカウントを跨いで S3 などを共有する

    リソースベースポリシーのクロスアカウントアクセスを設定することで対応が可能。

    一部の AWS サービスでは、リソースに対するクロスアカウントアクセス許可を付与することができる。

    クロスアカウントの理論についてはこちら

    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html

    これを行うには、プロキシとしてロールを使用するのではなく、

    共有するリソースに直接ポリシーをアタッチすることになる。

    共有するリソースは、リソースベースのポリシーをサポートしている必要がある。

    なお、リソースベースポリシーが有効になっているサービスは

    • S3
    • SNS
    • SQS

    のみ。

    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_compare-resource-policies.html

    ユーザーベースのポリシーとの違い

    端的に言うと、ユーザーに割り当てるのではなく、サービスに割り当てるもの。

    リソースベースポリシーは Principal が必須となる。

    公式のスライドはこちら

    https://www.slideshare.net/AmazonWebServicesJapan/20150617-aws-blackbeltiam

    公式ドキュメントはちょっと難解なので、Classmethod さんの記事が非常にわかりやすく噛み砕かれていた。

    https://dev.classmethod.jp/articles/aws-iam-policy/

  • Lambda カスタム統合/Lambdaプロキシ統合 について

    API Gateway と Lambdaファンクションを統合して実行するための方法は

    • Lambda カスタム統合
    • Lambdaプロキシ統合

    の２つあるのでそれぞれ整理する

    Lambda カスタム統合

    プロキシ統合のセットアップ手順に加えて、

    受信リクエストデータがどのように統合リクエストにマッピングされるか、
    統合レスポンスデータの結果がメソッドレスポンスにどのようにマッピングされるかを指定す。

    https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/set-up-lambda-custom-integrations.html

    Lambda プロキシ統合

    おそらく、API GW + lambda の構成の場合最も使われている機能だと思う。

    API にコンテンツのエンコーディングやキャッシュが不要な場合は、

    統合の HTTP メソッドを POST に設定し、統合エンドポイント URI を特定の Lambda 関数のアクションを呼び出す Lambda 関数の ARN に設定することで、認証情報を API Gateway がユーザーに代わって Lambda 関数を呼び出すことを許可する。

    https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html

  • AWS OrganizationsのSCP の落とし穴

    概要

    AWS Organizationsのサービスコントロールポリシー (SCP) は、組織を管理するために使用できるポリシーのタイプ。

    特徴

    SCP は、組織内のすべてのアカウントの最大使用アクセス権限を一元的に管理できる機能を提供し、アカウントが組織のアクセスコントロールガイドラインに沿って活動することを確実にする。

    SCP は、すべての機能が有効になっている組織でのみ使用できる。

    SCPはサービスにリンクされたロールには影響しないようになっているという特徴がある。

    IAMロール をインスタンスにアタッチしているなどの場合は、SCPによって制限することはできない。

  • EC2 で動いている Windows Server をアップグレードについて

    インプレースアップグレードと移行 (並行アップグレード) の 2 通りの方法が選択肢になる。

    それぞれの特徴についてまとめる

    インプレースアップグレード

    セッションレスアプリケーション用に設計されている。

    ローリングデプロイメントスケジュールを実装することにより、ステートフルアプリケーションにインプレースアップグレード方式を引き続き使用することができる。

    Windows のサーバに十分なストレージがあることを確認する必要がある。

    並行アップグレード

    アップグレードのエラーや問題がより少ない反面、インプレースアップグレードより時間がかかる。

    公式ドキュメント

    https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/serverupgrade.html