セキュリティとアイデンティティ

セキュリティとアイデンティティ

AWSのアカウントの種類

AWSにはAWSアカウントとIAMユーザーと呼ばれる2種類のアカウントがある。

• AWSアカウント
  • AWSのすべてのサービスをネットワーク上のどこからでも利用可能
  • ルートユーザーとも言われる
• IAMアカウント
  • AWSを利用する各利用者向けに作成されるアカウント
  • 必要に応じてAWSアカウントユーザーにより作成される
  • AWSの各利用者がWebコンソールログインして操作するとき、APIを利用してAWSを操作するときなどに利用
  • IAMユーザーには最小限の権限を付与することでセキュリティの安全性を高めることができる

IAMの機能

1. AWSサービスやAWSリソースに対する操作権限をIAMポリシーとして定義
2. IAMポリシーをIAMユーザーやIAMグループにアタッチする
3. IAMユーザー、IAMグループに属するIAMユーザーがマネジメントコンソールにログインすると、付与された権限の操作を行うことができる

IAMポリシー

Acion(サービス), Resource(機能や範囲), Effect(許可/拒否)という3つの大きなルールに基づいて、AWSの各サービスを利用する上での様々な権限を設定

• インラインポリシー
  • 対象ごとに個別に適用する
• 管理ポリシー
  • 複数のユーザー・グループにまとめて適用する
• AWS管理ポリシー
  • AWSによって用意されたもの
• カスタマー管理ポリシー
  • ユーザー自身が管理するもの

IAMユーザーとIAMグループ

ユーザーとは、AWSを利用するために各利用者に1つずつ与えられている認証情報のこと。

• ユーザーIDとパスワード
  • Webコンソールにログインする際に利用
  • Multi-Factor Authenticationを推奨
• アクセスキーとシークレットアクセスキー
  • CLIやAPIからAWSのリソースにアクセスする場合に使用

IAMロール

IAMロールは、一時的にAWSリソースへのアクセス権限を付与するときに利用

• AWSリソースへの権限付与
  • EC2インスタンス上で稼働するアプリケーションに一時的にAWSのリソースへアクセスする権限を与えたい
• クロスアカウントアクセス
  • 複数のAWSアカウント間のリソースを1つのIAMユーザーで操作したい
• IDフェデレーション
  • 社内のAD(Active Directory)サーバーに登録されているアカウントを使用して、AWSリソースにアクセスしたい
• Web IDフェデレーション
  • FacebookやGoogleのアカウントを使用してAWSリソースにアクセスしたい

KMSとCloudHSM

KMS(=AWS Key Management Service)は、AWSが管理するマネージドサービスで、多くの場合、CloudHSMではなくこちらを用いる

CloudHSM(=AWS CloudHSM)は、VPC内で専有のハードウェアを利用して鍵を管理するサービスで、相当に大規模なシステムに用いる

KMSとCloudHSM

	CloudHSM	KMS
専有性	VPC内の専有ハードウェアデバイス	AWSが管理するマルチテナント
可用性	ユーザー側が管理	AWS側が高可用性・耐久性を設計
信頼の基点	ユーザー側が管理	AWS側が管理
暗号化機能	共通鍵及び公開鍵	共通鍵
コスト	ほぼ固定	従量課金

KMSの機能

KMSでは、データキーでデータを暗号化し、データキーをマスターキーで暗号化する。（エンベロープ暗号化）

• Encrypt: 暗号化API
• Decrypt: 復号化のAPI
• GenerateDatakey: ユーザーがデータの暗号化に利用するためのカスタマーデータキーを作成する

マスターキーとデータキー

• Customer Master Key
  • データキーを暗号化するための鍵
• Customer Data Key
  • データを暗号化するための鍵

AWS Certificate Manager

証明書の役割と種類

1. 経路間通信の安全性の確保
2. 通信している相手が誰かの証明

• 自己証明書: 自分で認証局をたてて証明書を発行(第三者による保証無し)
• ドメイン証明(DV): ドメインの所有のみを証明。組織情報の確認はされない
• 組織認証(OV): 組織情報の審査を経てから認証する

- 拡張認証(EV): OVより厳格な審査で認証する。アドレスバーに組織名が表示される

ACM

AWS Certificate Manager(ACM)は、AWS自身が認証局になってDV証明書を発行するサービス。
ACMは、AWS自身が認証局となって、RSA鍵とサーバー証明書の作成・管理を行うサービス。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第16弾

以下の違いについて覚えておいて損はありません。

・AWS WAF

AWS WAFとは

そもそも、WAFはWeb Application Firewallの略称です。

アプリケーションを保護してくれます。
AWS WAFは、一般的なウェブの脆弱性からアプリケーションを保護します。

(以下、公式サイトより)

AWS WAF は、可用性、セキュリティ侵害、リソースの過剰消費といった一般的なウェブの脆弱性からウェブアプリケーションまたは API を保護するウェブアプリケーションファイアウォールです。AWS WAF では、SQL インジェクションやクロスサイトスクリプティングなどの一般的な攻撃パターンをブロックするセキュリティルールと、定義した特定のトラフィックパターンを除外するルールを作成できるため、トラフィックがアプリケーションに到達する方法を制御できます。AWS または AWS Marketplace 販売者が管理する事前設定済みのルールセットである AWS WAF のマネージドルールを使用して、すぐに開始できます。WAF のマネージドルールは、OWASP トップ 10 のセキュリティリスクなどの問題に対処します。これらのルールは、新しい問題が発生すると定期的に更新します。AWS WAF には、セキュリティルールの作成、デプロイメント、およびメンテナンスを自動化するために使用できる、完全な機能を備えた API も含まれています。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第14弾

以下サービスについて覚えておいて損はありません。

・AWS shield

AWS shieldとは

DDoS対策のためのサービス。
AWS Shield StandardとAWS Shield Advancedが存在します。

＊AWS Shield Standard
追加費用なし。
YN/ACK フラッド、リフレクション攻撃、HTTPスローリードなど、今日最も一般的な攻撃の96％から守ってくれます。

＊AWS Shield Advanced

ボリューム攻撃に対する追加のDDoS軽減機能、インテリジェントな攻撃検出、アプリケーションおよびネットワーク層での攻撃に対する軽減を提供。

DDoS攻撃の影響で請求金額が急増することを防ぐために、AWSのDDoSレスポンスチーム(DRT)が24時間365日サポートしてくれます。

利用料金は高め。

(以下、公式サイトより)

AWS Shield はマネージド型の分散サービス妨害 (DDoS) に対する保護サービスで、AWS で実行しているアプリケーションを保護します。AWS Shield ではアプリケーションのダウンタイムとレイテンシーを最小限に抑える常時稼働の検出と自動インライン緩和策を提供しているため、DDoS 保護のメリットを受けるために AWS サポートに依頼する必要はありません。AWS Shield にはスタンダードとアドバンストの 2 つの階層があります。

参考)

AWS Shield – DDoS攻撃からアプリケーションを保護
https://aws.amazon.com/jp/blogs/news/aws-shield-protect-your-applications-from-ddos-attacks/

Amazon Rekognition とは

Amazon Rekognition では、イメージ分析とビデオ分析をアプリケーションに簡単に追加することができます。Amazon Rekognition API にイメージやビデオを指定するだけで、このサービスによってモノ、人物、テキスト、シーン、アクティビティを識別できます。不適切なコンテンツも検出できます。Amazon Rekognition は、高精度な顔分析、顔比較、および顔検索機能も備えています。顔の検出、分析、比較は、ユーザー検証、カタログ作成、人数計数、公共安全など、多岐にわたって活用できます。

Amazon Rekognition の仕組み

Amazon Rekognition には 2 つの API セットがあります。Amazon Rekognition Image はイメージ分析に、Amazon Rekognition Video はビデオ分析に使用します。

センサー、入力イメージ、ビデオのベストプラクティス

Amazon Rekognition Image オペレーションのレイテンシー

イメージが含まれている Amazon S3 バケットのリージョンと Amazon Rekognition Image API オペレーションで使用するリージョンが一致している必要があります。
イメージのバイトを使用した Amazon Rekognition Image オペレーションの呼び出しは、イメージを Amazon S3 バケットにアップロードしてから、アップロードされたイメージを Amazon Rekognition Image オペレーションで参照するよりも高速です。
イメージがすでに Amazon S3 バケットにある場合、Amazon Rekognition Image オペレーションで参照すると、イメージのバイトをオペレーションに渡すよりも高速になる可能性があります。

イメージのバイトを使用した Amazon Rekognition Image オペレーションの呼び出し > イメージを Amazon S3 バケットにアップロードしてから、アップロードされたイメージを Amazon Rekognition Image オペレーションで参照する

AWS SAP取得に向けて予備知識としてあった方が良いもの

・ブルーグリーンデプロイメント

ブルーグリーンデプロイメントとは

ブルーとグリーンという2つの環境を用意する。
ルーティングは片寄しておく。
例えば、ブルー側でサービスが本番稼働している場合、もう1つの環境（グリーン）で新しいアプリケーションをデプロイし、ルーティングの向け先をグリーンに振り向けることでバージョンアップを行うという手法のこと。

問題が発生した場合は、ルーティングの向け先を戻し切り戻しを行います。

以下サイトの内容が非常に分かりやすかったです。
https://www.google.co.jp/amp/s/cloudpack.media/25426/amp

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第13弾

以下サービスについて覚えておいて損はありません。

・Amazon Workdocs

Amazon Workdocsとは

コンテンツの作成、編集、共有が可能。
Workdocsアカウントを持たないユーザに対しては、ReadOnlyで共有できます。

イメージとしては、dropboxやboxのようなサービスです。

(以下、公式サイトより)

Amazon WorkDocs はコンテンツの作成、ストレージ、コラボレーション用の安全なフルマネージド型サービスです。Amazon WorkDocs を使用すると、コンテンツの作成、編集、共有が簡単になります。また、AWS 内に一元管理で格納されるため、どこからでも、どんなデバイスからでもアクセスできます。Amazon WorkDocs では他のユーザーとのコラボレーションが容易になり、コンテンツ共有、豊富なフィードバックのやりとり、文書の共同編集を簡単に行えます。また、Amazon WorkDocs を使用してファイル共有をクラウドに移行することにより、古いファイル共有インフラストラクチャを不使用にすることができます。Amazon WorkDocs はお客様の既存システムと統合可能なうえ、豊富な API が利用できるため、独自のリッチなコンテンツを持つアプリケーションの開発が実現できます。Amazon WorkDocs は AWS 上にビルドされるため、お客様のコンテンツは世界最大のクラウドインフラストラクチャで保護されます。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第12弾

以下サービスについて覚えておいて損はありません。

・AWS Discovery Service

AWS Discovery Serviceとは

オンプレミスで稼働しているサーバの各情報を取得し、アセスメント・分析を行うための支援をしてくれる。

移行時、情報収集に苦労する場合があるがADSを利用すると楽に情報収集が可能です。

・収集したデータはAWSのDBに安全に保持
・データを収集するにあたりエージェントのタイプが2つある

＊エージェントレス
osパッケージなどは取得不可。

＊エージェントベース
サーバにエージェントをインストールし、情報を収集。サーバ上の詳細な情報(パッケージ、プロセス、ネットワーク通信など)を収集できます。

はじめに

大量のEC2インスタンスのEBSのスナップショットを作成しようとすると、AWSコンソール上からポチポチやるのでは辛いところがあります。そこで、aws cliを使いコマンドライン上で、EC2インスタンス名からEBSのスナップショットを作成する手順を備忘録として残します。

aws cli

まず、今回使用するaws cliについて軽く解説をします。本家の解説ページより引用。

AWS Command Line Interface (AWS CLI) は、コマンドラインシェルでコマンドを使用して AWS サービスとやり取りするためのオープンソースツールです。

aws cliには大量のサブコマンドがあり、それらを用いてaws上の各種リソースにアクセスします。今回使用するコマンドは以下の二つです。

• aws ec2 describe-instances
• aws ec2 create-snapshot

describe-instancesはインスタンスの情報を取得するためのコマンド、create-snapshotはEBSのスナップショットを作成するコマンドです。
aws ec2 create-snapshotのオプションには以下の物があります。この中で必須のオプションが--volume-idです。ここにはスナップショットを作成するEBSのボリュームIDを指定します。
また、タグを設定する場合、ResourceTypeにはResourceType="snapshot"を指定します。

$ aws ec2 create-snapshot help
...
OPTIONS
       --description (string)
          A description for the snapshot.

       --volume-id (string)
          The ID of the EBS volume.

       --tag-specifications (list)
          The tags to apply to the snapshot during creation.

       Shorthand Syntax:

          ResourceType=string,Tags=[{Key=string,Value=string},{Key=string,Value=string}] ...
...

aws ec2 describe-instancesのオプションには以下の物があります。オプション無しで実行すると、アカウントに紐ずく全てのEC2インスタンスの情報を取得しますが、--filtersオプションを使用することで情報を取得するEC2を絞り込むことができます。

$ aws ec2 describe-instances help
...
OPTIONS
       --filters (list)
          The filters.
...
       Shorthand Syntax:

          Name=string,Values=string,string ...
...

ボリュームIDの取得

まず、EBSのボリュームIDを取得します。aws ec2 describe-instancesの--filtersオプションでは様々な条件でインスタンスの絞り込みを行えます。今回はタグを用いて絞り込みを行います。タグでの絞り込みの書式は以下通りです。

 aws ec2 describe-instances --filters "Name=tag:{TAG_NAME},Values={TAG_VALUE1}[,TAG_VALUE2]..."

適切なタグ名と値の組み合わせでコマンドを叩くと次の様なデータが返ってきます。

$ aws ec2 describe-instances --filters "Name=tag:Name,Values=aws-cli-snapshot"

{
    "Reservations": [
        {
            "Groups": [],
            "Instances": [
                {
                    "AmiLaunchIndex": 0,
                    "ImageId": "ami-xxxxxxxxxxxxxxxxx",
                    "InstanceId": "i-xxxxxxxxxxxxxxxxx",
                    "InstanceType": "t2.micro",
                    "KeyName": "xxxxx",
                    "LaunchTime": "2020-06-03T03:15:48+00:00",
                    "Monitoring": {
                        "State": "disabled"
                    },
                    "Placement": {
                        "AvailabilityZone": "ap-northeast-1a",
                        "GroupName": "",
                        "Tenancy": "default"
                    },
                    "PrivateDnsName": "ip-xxx-xx-xx-xxx.ap-northeast-1.compute.internal",
                    "PrivateIpAddress": "xxx.xx.xx.xx",
                    "ProductCodes": [],
                    "PublicDnsName": "ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com",
                    "PublicIpAddress": "xx.xxx.xxx.xxx",
                    "State": {
                        "Code": 16,
                        "Name": "running"
                    },
                    "StateTransitionReason": "",
                    "SubnetId": "subnet-xxxxxxxx",
                    "VpcId": "vpc-xxxxxxxx",
                    "Architecture": "x86_64",
                    "BlockDeviceMappings": [
                        {
                            "DeviceName": "/dev/xvda",
                            "Ebs": {
                                "AttachTime": "2020-05-13T02:20:17+00:00",
                                "DeleteOnTermination": true,
                                "Status": "attached",
                                "VolumeId": "vol-123456789xxxxxxxx"
                            }
                        }
                    ],
                    "ClientToken": "",
                    "EbsOptimized": false,
                    "EnaSupport": true,
                    "Hypervisor": "xen",
                    "IamInstanceProfile": {
                        "Arn": "arn:aws:iam::1234567890:instance-profile/xxxxxxxx",
                        "Id": "123456789XXXXXXXXXX"
                    },
                    "NetworkInterfaces": [
                        {
                            "Association": {
                                "IpOwnerId": "amazon",
                                "PublicDnsName": "ec2-xxx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com",
                                "PublicIp": "xxx.xx.xx.xx"
                            },
                            "Attachment": {
                                "AttachTime": "2020-05-13T02:20:16+00:00",
                                "AttachmentId": "eni-attach-xxxxxxxxxxxxxxxxx",
                                "DeleteOnTermination": true,
                                "DeviceIndex": 0,
                                "Status": "attached"
                            },
                            "Description": "",
                            "Groups": [
                                {
                                    "GroupName": "xxxxx",
                                    "GroupId": "sg-xxxxxxxxxxxxxxxxx"
                                }
                            ],
                            "Ipv6Addresses": [],
                            "MacAddress": "xx:xx:xx:xx:xx:xx",
                            "NetworkInterfaceId": "eni-xxxxxxxxxxxxxxxxx",
                            "OwnerId": "414867676510",
                            "PrivateDnsName": "ip-xxx-xx-xx-xx.ap-northeast-1.compute.internal",
                            "PrivateIpAddress": "xxx.xx.xx.xx",
                            "PrivateIpAddresses": [
                                {
                                    "Association": {
                                        "IpOwnerId": "amazon",
                                        "PublicDnsName": "ec2-xxx-xx-xx-xx.ap-northeast-1.compute.amazonaws.com",
                                        "PublicIp": "xxx.xx.xx.xx"
                                    },
                                    "Primary": true,
                                    "PrivateDnsName": "ip-xxx-xx-xx-xxx.ap-northeast-1.compute.internal",
                                    "PrivateIpAddress": "xxx.xx.xx.xx"
                                }
                            ],
                            "SourceDestCheck": true,
                            "Status": "in-use",
                            "SubnetId": "subnet-xxxxxxxx",
                            "VpcId": "vpc-xxxxxxxx",
                            "InterfaceType": "interface"
                        }
                    ],
                    "RootDeviceName": "/dev/xvda",
                    "RootDeviceType": "ebs",
                    "SecurityGroups": [
                        {
                            "GroupName": "xxxxxxxxxx",
                            "GroupId": "sg-xxxxxxxxxxxxxxxxx"
                        }
                    ],
                    "SourceDestCheck": true,
                    "Tags": [
                        {
                            "Key": "Name",
                            "Value": "aws-cli-snapshot"
                        }
                    ],
                    "VirtualizationType": "hvm",
                    "CpuOptions": {
                        "CoreCount": 1,
                        "ThreadsPerCore": 1
                    },
                    "CapacityReservationSpecification": {
                        "CapacityReservationPreference": "open"
                    },
                    "HibernationOptions": {
                        "Configured": false
                    },
                    "MetadataOptions": {
                        "State": "applied",
                        "HttpTokens": "optional",
                        "HttpPutResponseHopLimit": 1,
                        "HttpEndpoint": "enabled"
                    }
                }
            ],
            "OwnerId": "xxxxxxxxxxxxxxxxx",
            "ReservationId": "r-xxxxxxxxxxxxxxxxx"
        }
    ]
}

EBSのボリュームIDは、Reservations -> Instances -> BlockDeviceMappings -> Ebs -> VolumeIdにあります。この値をjqで取り出します。ボリュームIDは後ほど使用するので変数へ格納しておきます。

$ export VOLUME_ID=$(aws ec2 describe-instances --filters "Name=tag:Name,Values=aws-cli-snapshot" \
| jq '.Reservations[].Instances[].BlockDeviceMappings[].Ebs.VolumeId' -r)

$ echo $VOLUME_ID
vol-123456789xxxxxxxx

スナップショットの作成

続いて、取得したボリュームIDを用いてスナップショットを作成します。スナップショットの作成方法は、aws ec2 create-snapshotの--volume-idオプションに先ほどのボリュームIDを渡すだけです。今回はタグとdescriptionも同時につけておきます。

$ aws ec2 create-snapshot --volume-id $VOLUME_ID \
--tag-specification 'ResourceType="snapshot",Tags=[{Key="Name",Value="aws-cli-snapshot"}]' \
--description "Created by aws cli"

以上でEBSのスナップショットが作成されます！

まとめ

今回はaws-cliを使ってコマンドラインからEC2のEBSのスナップショットを作成する方法をまとめました。EC2のfilter方法だけあらかじめ決めておけば、シェルスクリプトなどを用いることで、数が多くなってもスナップショットの作成が容易に行えると思います。
aws-cli含め、awsはまだまだ初心者ですが、小さなハックから知識を深めていきたいです。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第11弾

以下のサービスについて覚えておいて損はありません。

・AWS SQS FIFO

AWS SQS FIFOとは

重複削除、単一実行、順序取得に対応。

FIFOでないSQSでは以下のデメリットがある。
・順番が保証されない
・メッセージが重複する可能性がある
・呼び出し側が2回呼んだら、2回実行しちゃう

一方で、FIFOキューでは、
・順番が保証される
・複数回実行しません
・同じ呼び出しをしたら削除します。

(以下、公式サイトより)

FIFO (先入れ先出し) キューは、オペレーションやイベントの順序が重要である場合、または重複不可の場合などにアプリケーション間のメッセージングを強化します。たとえば、次のような場合です。
ユーザーが入力したコマンドが正しい順序で実行されていることを確認します。
価格の変更を正しい順序で送信して、正しい製品価格を表示します。
アカウントを登録する前に受講者がコースに登録できないようにします。
FIFO キューはまた、1 回だけの処理を提供しますが、1 秒あたりのトランザクション (TPS) は制限されます。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第10弾

以下の違いについて覚えておいて損はありません。

・プロビジョンド IOPS SSD
・スループット最適化 HDD
・最適化インスタンス

プロビジョンド IOPS SSDとは

I/Oの性能を保証する。

(以下、公式サイトより)

プロビジョンド IOPS SSD (io1) ボリュームは、ランダムアクセス I/O スループットにおけるストレージパフォーマンスと整合性が重要な、I/O 集約型ワークロード (特にデータベースワークロード) のニーズを満たすように設計されています。バケットとクレジットのモデルを使用してパフォーマンスを計算する gp2 とは異なり、io1 ボリュームでは、ボリュームの作成時に一定の IOPS レートを指定できます。Amazon EBS は、プロビジョンドパフォーマンスを 99.9% 提供します。

スループット最適化 HDDとは

SSDほどの性能を必要とせず、コスト削減したい場合に利用。

(以下、公式サイトより)

スループット最適化 HDD (st1) ボリュームは、IOPS ではなくスループットでパフォーマンスを示す、低コストの磁気ストレージに使用できます。このボリュームタイプは、Amazon EMR、ETL、データウェアハウス、ログ処理など、サイズの大きなシーケンシャルワークロードに適しています。ブート可能な st1 ボリュームはサポートされていません。

最適化インスタンスとは

EC2-EBS間通信において、独立した帯域を確保。他のトラフィックの影響を受けない。

(以下、公式サイトより)

Amazon EBS– 最適化インスタンスは、最適化された設定スタックを使用し、Amazon EBS I/O に対して追加の専用の容量を提供します。この最適化は、Amazon EBS I/O とその他のインスタンスからのトラフィック間の競合を最小化することで、EBS ボリュームの高パフォーマンスを提供します。
EBS 最適化インスタンスは、Amazon EBS に専用の帯域幅を提供します。EBS 最適化インスタンスにアタッチした場合、汎用 SSD (gp2) ボリュームは、対応するベースラインパフォーマンスとバーストパフォーマンスを 99 % の時間で実現するように設計されています。また、プロビジョンド IOPS SSD (io1) ボリュームは、対応するプロビジョンドパフォーマンスを 99.9 % の時間で実現するように設計されています。スループット最適化 HDD (st1) と Cold HDD (sc1) の両方で、99% の時間はバーストスループットの 90% のパフォーマンス安定性が保証されます。毎時間、予測合計スループットの 99% 達成を目標に、準拠しない期間はほぼ均一に分散されています。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第9弾

以下の違いについて覚えておいて損はありません。

・加重ラウンドロビン
・レイテンシーベースルーティング
・位置情報ルーティング
・フェイルオーバールーティング

加重ラウンドロビンとは

各レコードに重み付けをし、任意の名前に対するクエリに指定された比率で異なる値を応答。

レイテンシーベースルーティングとは

クライアントが任意の名前にアクセスした際、レイテンシーが小さくなるような近場のリージョンから応答。

位置情報ルーティングとは

クライアントのIPアドレスを元に、チリデータベースでクライアントの接続地域を特定。
地理的に近い場所から応答。

フェイルオーバールーティングとは

ヘルスチェックでNGだった場合に、冗長構成であれば片寄するといったことが可能。

参考)
ルーティングポリシーの選択
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/routing-policy.html

概要

アプリケーションログやDBログなどS3にgz形式で保存した場合のログの確認方法についてまとめます。

前提

AWS CLIが使用できる

今回使用するもの

AWS S3
ターミナルなどの

方法

1. ダウンロードする

ダウンロードする前にダウンロードしたいフォルダに移動しておきましょう。

まずはS3内のフォルダを確認

aws s3 ls

下記のようにフォルダが表示されます

2020-01-17 20:36:54 フォルダA
2020-01-17 21:42:54 フォルダB

ダウンロード

aws s3 sync s3://フォルダA

フォルダAの中身全てローカルにダウンロードされます

2. ログを確認する

find {フォルダA} -type f | xargs gzcat | jq | grep [検索したい文字列]

gz圧縮、json形式
などのファイルであれば使用できると思います

コマンド解説

• find {フォルダA} -type f
  • フォルダA以下のファイルを取得
• xargs
  • コマンドA | xargs コマンドB → コマンドAの結果をコマンドBに渡す
• gzcat
  • gz形式を解凍
  • ここではfindで取得したgz形式のファイルを解凍している
• jq
  • json形式であればきれいに整形してくれる
  • こちらを参考
• grep
  • 最後は検索したワードで絞りこみ

概要

アプリケーションログやDBログなどS3にgz形式で保存した場合のログの確認方法についてまとめます。

前提

• AWS CLIが使用できる

本記事ではバケット内のファイルをダウンロードしておりますが、jsonなどのテキストファイルであればS3 SelectやAthenaも選択肢に入れておくと良いです。

今回使用するもの

AWS S3
ターミナルなどの

方法

1. ダウンロードする

ダウンロードする前にダウンロードしたいフォルダに移動しておきましょう。

まずはS3内のバケットを確認

aws s3 ls

下記のようにバケットが表示されます

2020-01-17 20:36:54 バケットA
2020-01-17 21:42:54 バケットB

ダウンロード

aws s3 sync s3://バケットA

バケットAの中身全てローカルにダウンロードされます

2. ログを確認する

find {フォルダA} -type f | xargs gzcat | jq | grep [検索したい文字列]

gz圧縮、json形式
などのファイルであれば使用できると思います

コマンド解説

• find {フォルダA} -type f
  • フォルダA以下のファイルを取得
• xargs
  • コマンドA | xargs コマンドB → コマンドAの結果をコマンドBに渡す
• gzcat
  • gz形式を解凍
  • ここではfindで取得したgz形式のファイルを解凍している
• jq
  • json形式であればきれいに整形してくれる
  • こちらを参考
• grep
  • 最後は検索したワードで絞りこみ

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第8弾

・Route53のヘルスチェックにおける正常性確認について

Route53とは

DNSサービス。

(以下、公式サイトより)

Amazon Route 53 は、可用性と拡張性に優れたクラウドのドメインネームシステム (DNS) ウェブサービスです。Amazon Route 53 は、www.example.com のような名前を、コンピュータが互いに接続するための数字の IP アドレス (192.0.2.1 など) に変換するサービスで、開発者や企業がエンドユーザーをインターネットアプリケーションにルーティングする、きわめて信頼性が高く、コスト効率の良い方法となるよう設計されています。Amazon Route 53 は IPv6 にも完全準拠しています。

Route53のヘルスチェック

エンドポイントをモニタリングするヘルスチェックを作成すると、エンドポイントが正常であるかどうか確認します。

エンドポイントの正常性確認

・HTTP/HTTPS ヘルスチェック
HTTP ステータスコード 2xx または 3xx でエンドポイントが応答する必要がある。

・HTTP/HTTPS 文字列チェック
文字列は5,120 バイト内に出現している必要があります。

(以下公式サイトより)

HTTP/HTTPS ヘルスチェック – Route 53 が、エンドポイントとの TCP 接続を 4 秒以内に確立できることが必要です。加えて、接続後 2 秒以内に、HTTP ステータスコード 2xx または 3xx でエンドポイントが応答する必要があります。
注記
HTTPS ヘルスチェックでは SSL/TLS 証明書が検証されないため、証明書が無効または期限切れの場合でもチェックが不合格になることはありません。
TCP ヘルスチェック - – Route 53 が、エンドポイントとの TCP 接続を 10 秒以内に確立できることが必要です。
HTTP/HTTPS ヘルスチェックと文字列一致 – HTTP/HTTPS ヘルスチェックと同様に、Route 53 はエンドポイントとの TCP 接続を 4 秒以内に確立し、そのエンドポイントが接続後 2 秒以内に 2xx または 3xx の HTTP ステータスコードで応答する必要があります。
Route 53 ヘルスチェッカーは、HTTP ステータスコードを受信した後 2 秒以内にそのエンドポイントからレスポンスボディを受信する必要があります。Route 53 は、指定された文字列をレスポンスボディで検索します。その際、検索文字列全体が、レスポンス本文の最初の 5,120 バイト内に出現している必要があります。それ以外の場合、エンドポイントはヘルスチェックで不合格となります。Route 53 コンソールを使用している場合は、[Search String] フィールドに文字列を指定します。Route 53 API を使用している場合は、ヘルスチェックの作成時に、SearchString 要素で文字列を指定します。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第7弾

以下の違いについて覚えておいて損はありません。

・ElastiCache Memcached
・ElastiCache Redis

Memcachedとは

マルチスレッドで動作する。
CPUのコア数を上げると、パフォーマンスも上がる。

(以下、公式サイトより)

以下がお客様の状況に当てはまる場合は、Memcached を選択します。
できるだけシンプルなモデルが必要である。
複数のコアまたはスレッドを持つ大きなノードを実行する必要がある。
システムでの需要の増減に応じてノードを追加または削除するスケールアウトおよびスケールイン機能が必要である。
データベースなどのオブジェクトをキャッシュする必要がある。

redisとは

シングルスレッドで動作する。

(以下、公式サイトより)

以下の状況が当てはまる場合は、Redis を Redis 用 ElastiCache のバージョンと共に選択します。
Redis 用 ElastiCache バージョン 5.0.0 (拡張)
プロデューサーが新しいアイテムをリアルタイムで追加できるようにし、コンシューマーがブロッキングまたはノンブロッキングの方法でメッセージを使用できるようにもするログデータ構造である Redis ストリームを使用します。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第6弾

・AWS Trusted Advisor

AWS Trusted Advisorとは

「コスト最適化」、「パフォーマンス」、「セキュリティ」、「フォールトトレーランス」の４つの項目で、AWSが自動で利用状況を精査し、アドバイスを送ってくれるものです。

ポイント

ビジネスサポートもしくはエンタープライズサポートを契約する必要がある。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第5弾

以下サービスについて覚えておいて損はありません。

・AWS Config
・AWS cloudtrail

AWS Configとは

AWSリソースの利用において、いつ、誰が何を使って何をしたのか、全て記録。

(以下、公式サイトより)

AWS Config は、AWS リソースの設定を評価、監査、審査できるサービスです。Config では、AWS リソースの設定が継続的にモニタリングおよび記録され、望まれる設定に対する記録された設定の評価を自動的に実行できます。Config を使用すると、AWS リソース間の設定や関連性の変更を確認し、詳細なリソース設定履歴を調べ、社内ガイドラインで指定された設定に対する全体的なコンプライアンスを確認できます。これにより、コンプライアンス監査、セキュリティ分析、変更管理、運用上のトラブルシューティングを簡素化できます。

AWS cloudtrailとは

AWSマネジメントコンソールやAWS の SDK やコマンドラインツールなどのユーザーアクティビティとAPI使用状況の追跡が可能。

(以下、公式サイトより)

AWS CloudTrail は、AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービスです。CloudTrail を使用すると、AWS インフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持できます。CloudTrail では、AWS マネジメントコンソール、AWS の SDK やコマンドラインツール、その他の AWS のサービスを使用して実行されるアクションなど、AWS アカウントアクティビティのイベント履歴を把握できます。このイベント履歴により、セキュリティ分析、リソース変更の追跡、トラブルシューティングをより簡単に実行できるようになります。 さらに、CloudTrail を使用して、AWS アカウントの異常なアクティビティを検出することができます。こうした機能は、運用分析とトラブルシューティングを簡素化するのに役立ちます。

Lambdaとは

ユーザーはコードだけ書いてくれれば、サーバー管理はAWS側でしますよってサービス。データの変更に応じてコードを実行したり、HTTPリクエストに応答してコードを実行したりしてくれる。

Lambdaの利点

サーバー管理が不要

Lambdaとはでも書いた通り、サーバー管理をAWS側でしてくれる。

継続的スケーリング

自動的にアプリケーションをスケーリングしてくれる。
重たい処理には多くのリソースを割り当てて、軽い処理には少しだけリソースを与える。

ミリ秒単位の課金

コードが実行される100 ms(= 0.1秒)ごとに課金される。
コードが実行されてない時は課金されないから料金は安く済む。

安定したパフォーマンス

それぞれの処理に適切なメモリサイズを割り当てるからコード実行時間を最適化できる。
2桁のミリ秒以内に応答するようにハイパー対応することも可能。

Lambdaの欠点

サーバー管理ができない

メリットでもあったけど、自分で管理したい時はそのままデメリットになる。

最後に

AWSについて学習中のメモ代わりに残しています。
新しくわかったことがあれば追記します。

参考
https://aws.amazon.com/jp/lambda/
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html

はじめに

運用レスのインフラ基盤でアプリ動かしたいと考え、
Flask（pythonのフレームワーク）を使った簡単なアプリをLambdaで動かしてみた。
※ すでにpython3.6がインストールされている前提（Cloud9は初期から入っている）
※ すでにNode.jsがインストールされており、npmコマンドが打てる前提（Cloud9は初期から入っている）

所要時間

本手順は30分ほどで完了する想定です。（60分あれば十分なハズ）

モジュールのインストール

ここではCloud9でserverless frameworkを用いてLambdaにFlaskをデプロイする方法を載せます。

• npmがインストールされていることを確認

$ npm --version

• npmのバージョンアップ

$ npm update -g

• serverless frameworkのインストール

$ npm install -g serverless

• labmdaでflaskを使用するためのモジュールをインストール

$ npm install --save-dev serverless-wsgi serverless-python-requirements

• Flaskのインストール

$ sudo python -m pip install flask

Serverless Frameworkの初期設定

• Serverless Framework用のIAM作成 Serverless Frameworkに管理者権限を渡すと権限がでかすぎるので、 下記のポリシーを付与したIAMユーザを作成した。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "cloudformation0",
            "Effect": "Allow",
            "Action": [
                "cloudformation:DescribeStackEvents",
                "cloudformation:CreateStack",
                "cloudformation:DeleteStack",
                "cloudformation:UpdateStack",
                "cloudformation:DescribeStackResources",
                "cloudformation:DescribeStackResource",
                "cloudformation:DescribeStacks",
                "cloudformation:ListStackResources"
            ],
            "Resource": "arn:aws:cloudformation:ap-northeast-1:<アカウントID>:stack/<サービス名>*"
        },
        {
            "Sid": "cloudformation1",
            "Effect": "Allow",
            "Action": [
                "cloudformation:ValidateTemplate"
            ],
            "Resource": "*"
        },
        {
            "Sid": "iam",
            "Effect": "Allow",
            "Action": [
                "iam:*"
            ],
            "Resource": [
                "arn:aws:iam::<アカウントID>:policy/<サービス名>*",
                "arn:aws:iam::<アカウントID>:role/<サービス名>*"
                ]
        },
        {
            "Sid": "s3",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*",
                "s3:Put*",
                "s3:CreateBucket",
                "s3:DeleteBucket",
                "s3:DeleteBucketPolicy",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::<サービス名>*"
        },
        {
            "Sid": "cloudwatch",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups",
                "logs:CreateLogGroup",
                "logs:DeleteLogGroup",
                "logs:PutRetentionPolicy"
            ],
            "Resource": "arn:aws:logs:ap-northeast-1:<アカウントID>:*"
        },
        {
            "Sid": "cloudwatchevents",
            "Effect": "Allow",
            "Action": [
                "events:PutRule",
                "events:DescribeRule",
                "events:DeleteRule",
                "events:PutTargets",
                "events:RemoveTargets"
            ],
            "Resource": "arn:aws:events:ap-northeast-1:<アカウントID>:rule/<サービス名>*"
        },
        {
            "Sid": "apigateway",
            "Effect": "Allow",
            "Action": [
                "apigateway:*"
            ],
            "Resource": "arn:aws:apigateway:ap-northeast-1::*"
        },
        {
            "Sid": "lambda",
            "Effect": "Allow",
            "Action": [
                "lambda:GetFunction",
                "lambda:DeleteFunction",
                "lambda:CreateFunction",
                "lambda:GetFunctionConfiguration",
                "lambda:ListVersionsByFunction",
                "lambda:AddPermission",
                "lambda:RemovePermission",
                "lambda:PublishVersion",
                "lambda:UpdateFunctionCode",
                "lambda:ListAliases",
                "lambda:UpdateFunctionConfiguration"
            ],
            "Resource": "arn:aws:lambda:ap-northeast-1:<アカウントID>:function:<サービス名>*"
        }
    ]
}

＜サービス名＞：この後serverless.ymlで設定するサービス名
<アカウントID>：各自のAWSのアカウントID

権限を絞るのがすごく苦労しました。（IAMとAPI Gatewayは結局絞り切れなかった。）
まだ絞れる場合は教えてもらえると助かります。

参考：https://docs.aws.amazon.com/index.html
参考：https://blog.kozakana.net/2019/12/serverless-framework-deploy-policy-for-aws/

• Serverless Framework用のAWSアカウント設定

$ serverless config credentials --profile sls --provider aws --key <アクセスキーID> --secret <シークレットアクセスキー>

※ profileを指定しないと[Defalt]のアカウントが使用されます。

Flaskアプリの構築

• プロジェクト作成

$ sls create -t aws-python3 -p <プロジェクト名>
$ cd <プロジェクト名>

• requirements.txtの作成

pythonで使用するライブラリはrequirements.txtで指定しないと
Lambdaにデプロイする際にデプロイモジュールの中に含まれない。

$ pip freeze > requirements.txt

requirements.txtの中身はデプロイしたいライブラリだけ残して後は消します。
下記は今回残しておいたものです。

boto3==1.12.14
Flask==1.0.4
requests==2.22.0
serverless-wsgi==1.7.5
serverlessrepo==0.1.9
Werkzeug==1.0.0

• Flaskアプリの配置

今回は動作することまで確認するので、プロジェクトディレクトリ配下に以下の内容のmain.pyを配置します。

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello, Flask!"

if __name__ == "__main__":
    app.run()

• serverless.ymlの編集

プロジェクトディレクトリ配下にあるserverless.ymlを編集します。

service: 
  name: ＜サービス名＞

plugins:
  - serverless-python-requirements
  - serverless-wsgi

provider:
  name: aws
  runtime: python3.6
  stage: ${opt:stage, 'dev'}
  region: ap-northeast-1
  timeout: 300
  memorySize: 2048 # Overwrite the default memory size. Default is 1024
  deploymentBucket: ${self:service}-deployment

custom:
  name: ${self:service.name}
  wsgi:
    app: main.app
    packRequirements: false
  stage: ${opt:stage, self:provider.stage}
  logRetentionInDays:
    dev: "30"
    stg: "60"
    prod: "90"
  pythonRequirements:
    dockerizePip: non-linux

functions:
  app:
    handler: wsgi.handler
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

※ logRetentionInDaysはログを何日分保存するかの設定です。デプロイしたLambdaのログはCloudWatch Logsに吐き出されますが、この保持期間を設定しています。

• プロジェクトディレクトリ内のファイル ここまでで、プロジェクトディレクトリ内には以下が配置されているかと思います。
  • requirements.txt
  • main.py
  • serverless.yml

Lambdaモジュールデプロイ先のS3構築

上記のyamlの中身に「deploymentBucket: ${self:service}-deployment」という部分があったが、
ここでLambdaのデプロイ先S3を指定している。
特に指定しなければServerless FrameworkがS3を作ってくれるが、
名前がいまいちだと感じたため自分で作ったS3を指定することにした。

S3バケット名は${self:service}-deploymentとなりますが、
これは「<サービス名>-deployment」を指しているので、
「<サービス名>-deployment」という名前のS3バケットをあらかじめ作っておく。

デプロイ

Serverless Frameworkを用いてLambdaにデプロイしていきます。

• デプロイ

sls deploy -v --aws-profile <プロファイル名>

デプロイが完了すると、以下の出力があると思います。
ブラウザからURLにアクセスしてうまく動作していることを確認できます。
※ 何か問題がある場合はCloudWatch Logsへ行き、ログを確認します。

endpoints:
  ANY - https://xxxxxxxxxxxx.ap-northeast-1.amazonaws.com/dev

削除

検証が終わって不要な場合は以下のコマンドで削除します。

• 削除

serverless remove -v --aws-profile <プロファイル名>

おわりに

簡単なアプリながら、Lambdaを用いてFlaskアプリを動かすことができました。
サーバレスによる運用フリーなアプリが作成できることが確認できました。

最後に、調査のきっかけになったLambdaについての記事リンクを張っておきます。
すごくまとまっていて、サーバレスアプリをこれから勉強していきたいと思う内容でした。

• サーバレス用のRDSについて https://qiita.com/G-awa/items/b9138cc1c9e4867a905e
• サーバレスのメリデメについて https://qiita.com/takanorig/items/3a3a0b43b5be5b4a124f

環境

Docker 19.03.8
macOS 10.15.4

IAMユーザーの作成

IAMユーザーを作成し、その後にアクセスキーを設定します。

terminal

$ aws configure
AWS Access Key ID [****************]: (credencialsのAccess key ID)
AWS Secret Access Key [****************]: (credencialsのSecret access key)
Default region name [ap-northeast-1]: ap-northeast-1
Default output format [json]: json

そして$ aws configure listを実行します。

terminal

$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     (credencialsのAccess key ID)      env    
secret_key     (credencialsのSecret access key)  env    
    region           ap-northeast-1      config-file    ~/.aws/config

※しかしこのときにセキュリティ的に伏せていますが$ aws configureと$ aws configure listのアクセスキー及び、シークレットアクセスキーが一致していない前提です

認証トークンを取得し、レジストリに対して Docker クライアントを認証しようとするものの...

terminal

$ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin (アカウントID).dkr.ecr.ap-northeast-1.amazonaws.com

An error occurred (UnrecognizedClientException) when calling the GetAuthorizationToken operation: The security token included in the request is invalid.

このエラーの内容は認証情報周りの設定に問題があることが原因だと言うことがわかりました。アクセスキーとシークレットアクセスキーがenvになっているのでおそらくどこかで環境変数にアクセスキーとシークレットアクセスキーを設定していると考えました。

.bash_profileを確認する

.bash_profileの中を確認してみます。

terminal

$ open -a TextEdit ~/.bash_profile

$ aws configure listで確認されたアクセスキーとシークレットアクセスキーの末尾と一致するアクセスキーとシークレットアクセスキーが表示されましたので削除します。

ターミナルを閉じて再度開いてから$ aws configure listを実行すると.bash_profileのアクセスキーとシークレットアクセスキーが優先され、IAMユーザー認証情報が実行できなかった場合にこれでエラーが解消されます。

それ以外のアクセスキーとシークレットアクセスキーが優先されていた場合は...

下記のコマンドを実行し一度リセットします。

terminal

$ mv ~/.aws/credentials /tmp/credentials.bak
$ mv ~/.aws/config /tmp/config.bak
# credentialとconfigを削除するコマンド

そして一度ターミナルを閉じてから再度開いて$ aws configureを実行して再設定する方法もあります。

以上が【ECSリポジトリにローカルのDockerをプッシュできないときの対処方法】になります^_^

概要

• 画像、動画処理のAIサービスであるAmazon Rekognitionの概要
• Auto Check-In Appソリューションの概要
• Auto Check-In Appソリューションを利用した顔認証システムの構築方法

内容

画像、動画処理のAIサービスであるAmazon Rekognitionの概要

AWS AIサービス

• 機械学習の深い知識なしに利用可能
• 学習済みのモデルをAPIで簡単に利用可能
• コンピュータビジョン
  • Amazon Rekognitions
• 音声（読み上げ、書き起こし)
  • Amazon Polly
  • Amazon Transcribe
  • Amazon Kendra
• 自然言語処理
  • Amazon Comprehend
  • Amazon Translate
  • Amazon Textract

Amazon Rekognition

• 機械学習による画像、動画分析の自動化
• 利用範囲
  • 対象物体、シーン、アクティビティ検出
  • 安全でないコンテンツの検出
  • 顔認識
• 機能
  • ラベル付け
  • カスタムラベル
  • 不適切コンテンツ検出
  • 文字検出
  • 顔検出分析
  • 顔検索、身元確認
  • 有名人認識
  • 動線分析
• アプリケーションに組み込む場合はAPIやSDKを利用して操作できる

Auto Check-In Appソリューションの概要

イベント受付の課題

• 人が集まるイベントでは受付業務が発生
  • 参加者リストとの照合に時間とコスト(人)がかかる
  • 本人確認が大変
  • 通過時間や時間帯ごとの通過人数の確認 ### 顔認証イベント受付サービスのアーキテクチャ
• 登録
  • 顔写真をS3へ保存する
  • Lambda functionで顔写真を処理、FaceIDをAmazon DynamoDBへ保存
• 検索
  • クライアントで顔写真などをアップロードと結果確認
  • Amazon API GatewayとAmazon Cognitoで情報転送
  • Lambdaで顔写真をamazon Rekognitionに処理する
  • FaceIdなどをAmazon DynamoDBに保存

仕組み

• 以下の部分
  • コレクション：登録した顔データの集合
  • 登録
  • 検索

Auto Check-In Appソリューションを利用した顔認証システムの構築方法

実装ガイド

• https://aws.amazon.com/jp/solutions/implementations/auto-check-in-app/
  • one-clickでバックグランドサービスを構築できる
• 注意点
  • イメージのバイトをAmazon Rekognition Imageに送る方が、S3にアップロードしたものを参照させるより高速
  • 送る前に画像サイズを小さくしたり顔の部分を切り出したりするとパファーマンスが向上
  • 結果にSimilarity(0から100)範囲をとるために、適切な閾値設定が重要
  • 顔認識だけではなく、身分証などの多要素認証を検討

感想

• AWS Summitのような大きいイベントに顔認証が広い範囲に使われると、チェックイン、セッション会場に入ることなどが時間がかからない
• 顔認証への影響要素が多く、成功率が100%ではないので、別の認証方法と併用すれば、一番安全になるはず
• Auto Check-In Appを利用して構築時間が少なくて、早めにプロトタイプを作ってお客様にソリューションのイメージを説明できる
• ハンズオンで顔認証を使ってみて、思ったよりもずっと早く認証できて、スピードにびっくりした

ただの作業メモ

ecs-cliインストール

$ sudo curl -o /usr/local/bin/ecs-cli https://amazon-ecs-cli.s3.amazonaws.com/ecs-cli-darwin-amd64-latest

$ sudo chmod +x /usr/local/bin/ecs-cli
$ ecs-cli --version
ecs-cli version 1.19.1 (a20cf74)

ecs-cli設定

既存クラスタの設定

$ ecs-cli configure --cluster tmp --default-launch-type FARGATE --config-name tmp --region  ap-northeast-1
INFO[0000] Saved ECS CLI cluster configuration tmp. 

$ ecs-cli ps
tmp/a84d9e85f592485093c3079c2f545731/log_router  RUNNING         example-firelens:5  UNKNOWN
tmp/a84d9e85f592485093c3079c2f545731/echoClient  RUNNING         example-firelens:5  UNKNOWN

こんにちは、MYLOPSのエンジニアの後河内です。
皆さま、AWSのEC2のバックアップはどのようにして取得してますでしょうか？

MYLOPSではAWS Lambdaを使用し、定期的にEC2のインスタンスのバックアップ（AMI）の取得を行ってました。

しかしAWSではすでにAWS Backup | クラウドバックアップの集中管理というものが準備されていますので、今回こちらでバックアップの取得と、復旧をやってみました。

一度だけのバックアップ

• バックアップについて一度だけであれば、”オンデマンドバックアップを作成”を選択することでバックアップをすることができます。
  

• ”リソースタイプ”に”EC2”を選ぶと、”インスタンスID”の欄で、EC2のインスタンスの一覧が出るのバックアップをしたいEC2のインスタンスを選択します。
  

• そのまま”オンデマンドバックアップを作成”を選ぶことで、バックアップが実行されます。
  

• バックアップ実行時には、バックアップジョブというものができます。
  

• こちらのジョブが完了するとステータスが完了となり、バックアップ完了です。
  

• ”保護されたリソース”にバックアップされたものが作られます。
  

定期的なバックアップ

• 定期的にバックアップをとるときは、”バックアッププランを管理”を選択します。
  

• 既存のプランというものもありますが、今回は”新しいプランを立てる”を選び、プランを作成します。今回考えているプランは、毎日バックアップを取得し、7世代保存するプランになります。
  まずは、”バックアッププラン名”を入れます。
  

• その後、バックアップのルールを設定し、”ルール名”を入れ、”頻度”に”毎日”を選びます。7世代作りたいので、”有効期限切れ”には”作成後の日数”に7を選びます。これで毎日バックアップが作られて、7日をすぎたバックアップは有効期限切れになります。
  

• またバックアップの開始時間を決めるには、”バックアップウィンドウをカスタマイズ”を選択し、時間を決めてあげないといけないようです。なお設定した時間そのものにはじめるのではなく、”次の時間内に開始”を選んだ時間内の中で開始されるようです。最短で選択ができるものは”次の時間以内に開始”が”1時間”で”次の時間以内に完了”が2時間です。
  UTC時間でいれますので、日本時間でAM5:00にしたい場合はPM8:00で設定してあげる必要があります。下記の設定ですと日本時間のAM5:00からAM6:00以内にバックアップが開始されAM:7:00以内に終了となるようです。
  

• そして”送信先リージョン”には、今回のバックアップ対象のEC2のインスタンスが動いている”アジアパシフィック（東京）”を選びます。
  

• その他の設定はデフォルトのままにして”プランを作成”を選びます
  

• プランができると、バックアップ対象を”リソースを割り当てる”で選択できます。
  

• リソース割り当て名を入力し、”割り当て単位”を”リソースID”にし、”リソースタイプ”を”EC2”にすることで、”インスタンスID”からバックアップ対象のEC2インスタンスを選び、”リソースを割り当てる”を選択することで定期的にバックアップの取得ができるようになります。
  

復旧

• 復旧については保護されたリソースから対象のインスタンスを選びます。
  

• そこから、復旧ポイント（複数のバックアップをとってる場合は複数あります）を選び”復元”を選択します。
  

-その後はインスタンスタイプやVPCなどを選び新しいEC2のインスタンスとしてバックアップから作成することができました。

-また”インスタンス起動ウィザード”というものを選ぶと、普段のAMIからインスタンスを作成するものと同じ方法で作成することができ、ローカルIPなどを設定したい場合は、"インスタンス起動ウィザードか"ら作成する必要があります。

感想

以上がAWS BackUPを使用したものになります。
使用した感じは、簡単にバックアップをとることもでき、復旧も簡単にできました。
大変便利なものと感じました。
ただし復旧する際に、インスタンス名からではなくインスタンスIDから選ばなければいけないので、バックアップ対象数が増えてきたときの復旧には少々手間はありそうだと感じました。

第二回で、Amplify CLIを使ってバックエンドリソースを作成し、CICDを回してVueアプリを外部公開するところまで辿り着いた。
今回は、さらにAPIとLambda関数を用意し、Vue.jsからaxiosで呼び出すところまでをトライ。これができれば、「Vue.jsでフロントエンドを作ってAWSサービスを叩いてみる」という当初の目的を達成できたことになる。

前回の内容はこちら。
Vue.js、AWS Amplifyおよびboto3でサンプルアプリを作ってみる（第二回：Amplifyとバックエンドリソース編）

（今回）やりたいこと

• axiosをセットアップする
• APIとLambda関数を作る
• Vue.jsからaxios経由でAPIを呼び出す

あえてやらないこと

AmplifyはライブラリやUIコンポーネントを備えていて、その気になればVue.js内から直接AWSサービスを操作できる様子（例：学習/デプロイ済みの機械学習モデルエンドポイントに推論リクエストを投げる、S3にオブジェクトをアップロードするなど）。
ただ、それをやるとなるとVue.jsのディレクティブやJavascript SDKにもう少し深入りする必要がありそう。あっちもこっちも手を出したくないので、今回は初志貫徹でコードはPython、SDKはboto3に留めておく。

ということで、上図の通りフロントエンドからはAPIを叩くだけにして、ロジックやSDKの使用はバックエンドで行う役割分担にする。

axiosについて

簡単に言うとHTTPクライアントで、Vue.jsのコード内からPostman的にREST APIを呼び出す方法がないかと探すうちに発見。

axios

これなら簡単にAPIの呼び出しと結果の受領ができそうだ。

以下を参考にさせていただきました。感謝。
axios を利用した API の使用
axiosを乗りこなす機能についての知見集
Vue.js+axiosでDynamo DBにAjax通信する
[axios] axios の導入と簡単な使い方

Step by Step

1. Amplifyライブラリのインストール

やらないとは言いつつも、後学のために、セットアップして使えるようにするところまでは試しておく。

% npm install aws-amplify
% npm install aws-amplify-vue 

このあたりを参照しながらインストール。
公式も参照のこと。

2. src/main.jsへの取り込み

src/main.jsを編集して、Amplifyライブラリの取り込みを指定する。

src/main.js

// Amplify
import Amplify, * as AmplifyModules from 'aws-amplify'
import { AmplifyPlugin } from 'aws-amplify-vue'
import awsconfig from './aws-exports'
Amplify.configure(awsconfig)

Vue.use(AmplifyPlugin, AmplifyModules)

aws-exportsが見つからない、というエラーが出る場合は、.gitignoreでGitのトラッキング対象外になってしまっていないかを確認する。
自分の環境では、これをコメントアウトすると動いた。
.gitignoreへの追加はAmplify自身が行っているようなので若干謎だが、とりあえず動いたので、気にせず先に進む。

.gitignore

.DS_Store
node_modules
/dist

# local env files
.env.local
.env.*.local

# Log files
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Editor directories and files
.idea
.vscode
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?

#amplify
amplify/\#current-cloud-backend
amplify/.config/local-*
amplify/mock-data
amplify/backend/amplify-meta.json
amplify/backend/awscloudformation
build/
dist/
node_modules/
# aws-exports.js <-- ここ
awsconfiguration.json
amplifyconfiguration.json
amplify-build-config.json
amplify-gradle-config.json
amplifyxc.config

3. axiosのインストール

Amplifyライブラリと同じ手順。

% npm install axios

4. src/main.jsへの取り込み

ここもAmplifyライブラリと同様だが、axoisの仕様に若干のクセがありハマった。
axiosは厳密にはプラグインでないので、main.jsでVue.use()に書いてあっても、this.axiosがUndefinedとなってしまう。
代わりに以下のようにprototype.$axiosとして定義し、読み込み元では$axios.get()として呼ぶ必要がある。

// ダメな例

// Axios
import axios from 'axios'
import VueAxios from 'vue-axios'

Vue.use(AmplifyPlugin, AmplifyModules, VueAxios, axios)

// 動く例

// Axios
import axios from 'axios'
import VueAxios from 'vue-axios'

Vue.use(AmplifyPlugin, AmplifyModules, VueAxios)
Vue.prototype.$axios = axios

main.jsは最終的にこのようになる。

src/main.js

import Vue from 'vue'
import App from './App.vue'
import router from './router'

// Element UI
import './plugins/element.js'

// Axios
import axios from 'axios'
import VueAxios from 'vue-axios'

// Amplify
import Amplify, * as AmplifyModules from 'aws-amplify'
import { AmplifyPlugin } from 'aws-amplify-vue'
import awsconfig from './aws-exports'
Amplify.configure(awsconfig)

Vue.config.productionTip = false
Vue.use(AmplifyPlugin, AmplifyModules, VueAxios)
Vue.prototype.$axios = axios

new Vue({
  router,
  render: h => h(App)
}).$mount('#app')

これでようやくaxiosの事前準備が完了。

5. Lambda関数の準備

バックエンド側を作る。
そろそろAmplifyに全部やらせるのも飽きてきたので、練習も兼ねて、amplify add functionではなくスクラッチで用意する。
こんな感じのLambda関数を書く。

lambda_function.py

import boto3
import json
import os
import datetime

print('Loading function')
glue = boto3.client('glue')
gluedb = os.environ['GLUEDBNAME']

# dict内のdatetime型データをJSON対応のISOフォーマット（文字列）に変換する
def convert_datetime2iso(object):
    if isinstance(object, type(datetime)):
        return object.isoformat()

# 本体
def lambda_handler(event, context):
    operation = 'GET'
    if operation == 'GET': 
        tables = glue.get_tables(
            DatabaseName=gluedb
        )["TableList"]
        response = json.dumps(tables, default=convert_datetime2iso)
        return {
            'isBase64Encoded': False,
            'statusCode': 200,
            'headers': {
                # CORSの許可
                'Content-Type': 'application/json', 
                'Access-Control-Allow-Origin': '*' 
            },
            'body': response
        }
    else:
        response = ('Unsupported method:' + format(operation))
        return response

ファイル名がlambda_function.py、関数名がlambda_handler()なので、Lambdaからはlambda_function.lambda_handlerとして呼び出すことになる。

AWS Glueを呼び出し、DB名を渡してテーブル一覧を取得する簡単な関数で、GLUEDBNAMEをLambdaの環境変数として渡す形を取っている。今回はsh10_externalをDB名とした。よーく見る（見なくても）とメソッドがGETしか定義されてないが、お試しなのでご容赦。。

実際にGlueに渡す命令はglue.get_tables()のみで、特に複雑な処理はない。

6. APIの準備

次に、axiosから呼び出すREST APIを作成する。このAPIのバックエンドとして、先程のLambda関数を実行する形。
これもamplify add apiではなくスクラッチでAPIを作成してみる。
マネジメントコンソールでAPI Gatewayの画面に移動し、以下の仕様でAPIを作成。

• Lambdaプロキシー統合
• /tablesリソース
• ANYメソッド

API作成まではすんなりいったものの、Lambda関数と統合して動かすまでに色々ハマった。

まず、not JSON seriarizableエラー（クライアントから見ると500エラー）が出まくる。Lambda単体では動くようになっても、APIから呼ぶとまた出る。ここで大分時間を使った。
詳細はまた項を改めるが、結論としてはGlueからのdict型のレスポンスをjson.dump()した上で、API GatewayがLambdaプロキシ統合で要求する形式に成形して返すことで、無事API様に受け取って貰えた。

ようやく関門突破かと思いきや、今度はCORS header 'Access-Control-Allow-Origin' missing'といったエラーが出る。何か見覚えある単語が。
これは、axiosというか今回のSPAが当該APIを別のオリジンから呼ぶ形になるので、CORSを許可する必要があるということだ。
CORSは一般にサーバー側で設定し、API GatewayもOPTIONS`メソッドでこれを設定するメニューがあったので設定してみたが、どうやら効いてなさそうだ。

色々調べたところ、今回使用したLambdaプロキシー統合の場合はどうもバックエンドのLambdaの方で明示的にCORSを許可するヘッダを記述してやる必要がある模様。
上記の返値の中ほど、'headers':{}の中にCORS設定を書いてやると、ようやく動いた。やれやれ。

        return {
            'isBase64Encoded': False,
            'statusCode': 200,
            'headers': {
                # CORSの許可
                'Content-Type': 'application/json', 
                'Access-Control-Allow-Origin': '*' 
            },
            'body': response
        }

7. API呼び出しとテーブルへの取り込み設定

最後は再びフロントエンド側に戻り、axiosでAPIを呼び出してデータを取得する箇所と、取得したデータをElement UIのtablesの中に成形して取り込む受け皿部分を作る。
今回のSPAではsrc/components/配下に全てのコンポーネントを配置してVue Routerからルーティングしているが、この一つとしてCatalogueTable.vueというページを用意する。

ここでのポイントは以下の三つ。
- getDummyData()内のthis.$axios.getでaxiosを呼び出し、REST APIを叩く
- tablesという配列でデータを受け取る
- Element UIのel-tableコンポーネントでtablesのデータ（:data="tables"）を成形する

axiosの引数となるREST APIのURIには、先程API Gatewayで作成したAPIのエンドポイントを指定する。
成形は<el-table></el-table>や<el-table-column></el-table-column>の中で、Element UIの書式を使ってわりと自由に行うことができる。
ここでは最低限の属性だけを設定してみた。

• テーブル

属性	内容
:data	データソース
stripe	ストライプ表示にする
style="width: 100%"	横幅の長さ
align="center"	中央揃え

• 列

属性	内容
prop	列名
label	列の表示名
width	列の長さ
sortable	ソート可能な列として指定

src/components/CatalogueTable.vue

<template>
  <div class="cataloguetable">
    <p></p>
    <h2>テーブル一覧</h2>
    <el-button type="primary" @click="getDummyData" :loading="false">実行</el-button>
    <el-table
      :data="tables"
      stripe
      style="width: 100%"
      align="center">
      <el-table-column
        prop="Name"
        label="Table"
        width="250"
        sortable>
      </el-table-column>
      <el-table-column
        prop="DatabaseName"
        label="Database"
        width="200"
        sortable>
      </el-table-column>
      <el-table-column
        prop= "TableType"
        label="Type"
        width="200"
        sortable>
      </el-table-column>
      <el-table-column
        prop="PartitionKeys[0][Name]"
        label="Partition Key 1"
        width="150"
        sortable>
      </el-table-column>
      <el-table-column
        prop="PartitionKeys[1][Name]"
        label="Partition Key 2"
        width="150"
        sortable>
      </el-table-column>
    </el-table>
  </div>
</template>

<script>
export default {
  data() {
    return {
      input: '',
      tables: []
    }
  },
  methods: {
    getDummyData() {
      let uri = 'https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/prod/tables';
      this.$axios.get(uri)
        .then((response) => {
          this.tables = response.data
        })
        .catch((e) => {
          alert(e);
        });
    }
  }
}
</script>

これを呼び出す側のApp.vueはこんな感じで記述する。
（最終的には色々やりたいので、Element UIを使ったコンポーネントのガラだけはたくさん作ってあるが、CatalogueTable.vue以外の中身はまだ空に近い）。

src/App.vue

<template>
  <div id="app">
    <div>
    <img alt="Vue Logo" src="@/assets/gluelogo.png/" width="60" height="60">
      <h1>Data Catalogue Explorer</h1>
      <el-menu :default-active="activeIndex" mode="horizontal" background-color="#545c64" text-color="#fff" active-text-color="#ffd04b" router>
        <el-menu-item index="home" :route="{ name:'Home' }">ホーム</el-menu-item>
        <el-menu-item index="dataset" :route="{ name:'Dataset' }">データセットの一覧を見る</el-menu-item>
        <el-menu-item index="finder" :route="{ name:'Finder' }">データセットを探す</el-menu-item>
        <el-menu-item index="adhoc" :route="{ name:'Adhoc' }">アドホック検索</el-menu-item>
        <el-submenu index="catalogue">
            <template slot="title">システムカタログ</template>
            <el-menu-item index="catalogue-database" :route="{ name:'CatalogueDatabase' }">データベース</el-menu-item>
            <el-menu-item index="catalogue-table" :route="{ name:'CatalogueTable' }">テーブル</el-menu-item>
            <el-menu-item index="catalogue-crawler">クローラー</el-menu-item>
            <el-menu-item index="catalogue-job">ジョブ</el-menu-item>
            <el-menu-item index="catalogue-jdbc">JDBC接続</el-menu-item>
        </el-submenu>
        <el-menu-item index="api" :route="{ name:'API' }">API実行</el-menu-item>
        <el-menu-item index="element" :route="{ name:'Element' }">Element UI</el-menu-item>
        <el-menu-item index="about" :route="{ name:'About' }">Vue.js</el-menu-item>
        <el-menu-item index="resources" :route="{ name:'Resources' }">リソース</el-menu-item>
      </el-menu>
      <router-view />
    </div>
  </div>
</template>

<script>
export default {
  name: 'app',
  data () {
    return {
      activeIndex: this.$route.name
    }
  }
}
</script>

<style>
#app {
  font-family: 'Avenir', Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;
}
</style>

Vue Routerにもこのコンポーネントへのルートを忘れずに追加してやる必要がある。

router/index.js

import Vue from 'vue'
import VueRouter from 'vue-router'
...（略）...
# ここと
import CatalogueTable from '@/components/CatalogueTable.vue'
...（略）...

Vue.use(VueRouter)

const routes = [
  {
    path: '/',
    name: 'Home',
    component: Home
  },
...（略）...
  # ここ
  {
    path: '/cataloguetable',
    name: 'CatalogueTable',
    component: CatalogueTable
  },
...（略）...

最後にここまでの内容をコミットし、レポジトリにプッシュ（このままAmplifyの方で自動ビルドが回り、ホスティングされている内容が更新される。詳しくは前回の記事を参照）。

% git add .
% git commit -m "axios defined"
% git push -u origin master

9. 動作確認

Amplifyがデプロイを回してサイトの更新を完了するまで、待つこと数分。
ブラウザ、スマホでアクセスしてみると、どうやら無事動作している模様。

10. 落ち穂拾い

• Amplifyマネージドのビルドで、なぜかconsole.logが失敗する。
  • 構文チェックツールのESlint設定が何かおかしいのかも、と疑って、このあたりを参考にあれこれ検証してみるも解決に至らず。 console.logを出さなければいいだけの話なので、ここではいったん忘れることにした。いずれ解決したい。

ポスト三個分の長丁場になってしまったが、ようやくタイトル通りの自習が完了。
追々、APIを追加したりUIをいじってみたりと、色々遊んでみたい。

はじめに

Cloud9で開発する際に、Cloud9のApacheで公開した開発用モジュールをブラウザから
確認したいケースがある。
その際、認証をかけるとすればBasic認証やDigest認証を検討することになるが、

• どちらを採用すべきか
• 実装するときの手順はなにか

本記事にまとめてみた。
ちなみに、Cloud9での開発を想定しているものの、開発環境に何かしらの認証を設けるときには汎用的に参照できるように考えた。

認証の実装方式（設定管理の方法）

下記認証方式が考えられる。

認証用のファイルを用いたBasic認証／Digest認証

• .htaccessを使用したBasic認証
• .htaccessを使用したDigest認証

認証用のファイルを用いるケースとしては、
複数のアプリベンダが利用する共通環境でApache設定ファイルを各アプリベンダが触れない場合が考えられる。

メリット

アプリベンダが自由に設定をオーバーライドできるためインフラ管理者が設定作業を行う必要がない

デメリット

インフラ管理者が各ディレクトリにどのような設定がされているか全体を把握できない

設定ファイルを用いたBasic認証／Digest認証

• 設定ファイルで管理／設定するBasic認証
• 設定ファイルで管理／設定するDigest認証

設定ファイルを用いるケースとしては、
インフラ管理者が設定ファイルで設定内容を一元管理したいときが考えられる。

メリット

設定ファイルの内容がすべてであるため、設定の全体を把握しやすい

デメリット

仮に、複数のアプリベンダが利用する共通環境でApache設定ファイルを各アプリベンダが触れない場合、
設定変更依頼をアプリベンダから受領したのち、インフラ管理者が設定するため手間がかかる。

どちらを選択すべきか

ケースによって状況が変わってくるので案件等で採用する方式は変わってくるが、
個人的には設定ファイルを用いたBasic認証／Digest認証を使用するようにしたいと考えている。
なぜなら、様々な関係者がApacheの設定に関与すると、全体像の把握して管理することが難しくなるため。

実装方式（Basic認証かDigest認証か）

では、Basic認証とDigest認証どちらを採用すべきか。
方式としては以下が考えられる。

• SSLを使用しない状況下でのBasic認証
• SSLを使用した状況下でのBasic認証
• SSLを使用しない状況下でのDigest認証
• SSLを使用した状況下でのDigest認証

それぞれ認証としてどれだけの強度があるかが焦点になる。

SSLを使用するかどうかについて

SSLを使用する場合、通信自体の暗号化が担保されているので
Basic認証でもDigest認証でもどちらを使ってもかまわないと考える。

SSLを使用しない場合については、以下で検討した。

SSLを使用しない状況下でのBasic認証

• 通信時の暗号化

ユーザーIDとパスワードをBase64で変換し、リクエストヘッダーに付加して送信する。
Base64の復号は容易であり、傍受された場合は情報が筒抜けとなる。
参考：https://madalinazaharia.com/column/basic-authentication-and-digest-authentication/

• 設定ファイルの暗号化

パスワード自体はハッシュ化した状態で置いておくことができる。
bcrypt、MD5、SHA1、cript()を使用できるようだが、強度的にbcrypt一択と考えられる。
形式はuser:password(ハッシュ)
参考：https://httpd.apache.org/docs/2.4/misc/password_encryptions.html

SSLを使用しない状況下でのDigest認証

• 通信時の暗号化

ユーザーIDとパスワードをMD5で変換したハッシュ値を送信するとのこと。
MD５は脆弱であるという認識が広まっているように思うが、
ユーザーIDとパスワードのハッシュ値を攻撃者が取得しても、
ハッシュ値から原文を復号することはまだ難しいとのこと。
参考：https://ja.wikipedia.org/wiki/MD5#%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E3%81%AE%E8%A1%9D%E7%AA%81%E8%80%90%E6%80%A7%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
参考：https://sylph01.hatenablog.jp/entry/20171207/1512615600#:~:text=%E5%BC%B1%E8%A1%9D%E7%AA%81%E8%80%90%E6%80%A7%20vs%20%E5%BC%B7,%E8%80%90%E6%80%A7%E3%81%A8%E5%91%BC%E3%81%B0%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82

ただし、wikiにもある通り、将来的には攻撃手法や計算能力の進化により突破される可能性があるとのこと。

• 設定ファイルの暗号化

パスワード自体はハッシュ化した状態で置いておくことができる。
ただし、Basic認証と違い、MD5ハッシュでなければならない。
形式はuser:realm:password(MD5ハッシュ)
参考：https://httpd.apache.org/docs/2.4/misc/password_encryptions.html

SSLを使用しない状況下についてまとめ

通信でのMD5はまだ突破が難しいため、Digest認証であれば使用できる。
※　ただしAuthorizationヘッダの情報以外は暗号化されていない点に注意。
Basic認証についてはSSLを使用しない場合は、採用しても傍受されればIDとパスワードが漏れてしまう。

それぞれの実装方法

• .htaccessを使用したBasic認証

・.htpasswdの作成（パスワードはBcryptでハッシュ化して書き込み）
htpasswd -nbB ユーザ名 パスワード > /etc/httpd/conf/.htpasswd

・.htaccessの作成（アクセス制御をかけたいディレクトリに作成する）
$ vi .htaccess

↓.htaccessの中身
AuthType    Basic
AuthName    "TEST"
AuthUserFile    /etc/httpd/conf/.htpasswd
require valid-user

※ そもそも.htaccessの書き込みが対象のディレクトリに対して許可されている必要がある。
　　対象ディレクトリに対して「AllowOverride All」もしくは「AllowOverride AuthConfig」が設定されていること。

• .htaccessを使用したDigest認証

・.htdigestの作成（パスワードはMD5でハッシュ化して書き込み）
sudo htdigest -c /etc/httpd/conf/.htdigest 'realm名' ユーザ名

・.htaccessの作成（アクセス制御をかけたいディレクトリに作成する）
$ vi .htaccess

↓.htaccessの中身
AuthType    Digest
AuthName    "realm名"
AuthUserFile    /etc/httpd/conf/.htdigest
require valid-user

※ そもそも.htaccessの書き込みが対象のディレクトリに対して許可されている必要がある。
　　対象ディレクトリに対して「AllowOverride All」もしくは「AllowOverride AuthConfig」が設定されていること。

• 設定ファイルで管理／設定するBasic認証

・.htpasswdの作成（パスワードはBcryptでハッシュ化して書き込み）
htpasswd -nbB ユーザ名 パスワード > /etc/httpd/conf/.htpasswd

・下記を対象の設定ファイルに追記
（例）
  <Directory "/var/www/cgi-bin/flask/">
    AuthType    Basic
    AuthName    "TEST"
    AuthUserFile    /etc/httpd/conf/.htpasswd
    require valid-user
    AllowOverride None
  </Directory>

AllowOverride Noneは.htaccessによる設定を禁止している。

• 設定ファイルで管理／設定するDigest認証

・.htdigestの作成（パスワードはMD5でハッシュ化して書き込み）
sudo htdigest -c /etc/httpd/conf/.htdigest 'realm名' ユーザ名
・下記を対象の設定ファイルに追記
（例）
  <Directory "/var/www/cgi-bin/flask/">
    AuthType    Digest
    AuthName    "realm名"
    AuthUserFile    /etc/httpd/conf/.htdigest
    require valid-user
    AllowOverride None
  </Directory>

AllowOverride Noneは.htaccessによる設定を禁止している。

おわりに

SSL通信下であればBasic認証、Digest認証いずれを使用してもかまわないが、
SSL通信下でないなら、Digest認証一択になると考えた。

設定は.htaccessと設定ファイルいずれに書くかだが、それぞれメリット／デメリットがあるので
都度考えていきたい。

AWS SAP取得に向けて勉強する中で覚えてよかったもの 第4弾

以下の違いについて覚えておいて損はありません。

・AWS Snowball
・AWS Snowmobile

AWS Snowball

オンプレミス環境からAWSにデータを転送する際、ネットワーク経由で転送するのではなく、AWSからsnowballという専用のデータストレージを物理的に借りてそこにデータを入れる。

データを入れたsnowballをAWSへ返送すると、AWSがS3へデータインポートしてくれる。

(以下公式サイトより)

オンボードのストレージとコンピューティング機能を備えたペタバイト規模のデータ転送

AWS Snowmobileとは

snowballより、更に大容量のデータを移行することができる。

45フィートコンテナに100PBストレージを搭載。
トラックで直接データ転送元のデータセンターへ移動、データをトラックに搭載したストレージに直接取り込んでAWSに転送します。

もはや、想像の域を超えたデータ移行方法だが、エクサバイト級のデータも楽チンにAWSへ移行できるらしい。

(以下、公式サイトより)

AWS Snowmobile は、超大容量データを AWS に移動するために使用できるエクサバイト規模のデータ転送サービスです。セミトレーラートラックが牽引する長さ 14 m の丈夫な輸送コンテナで、Snowmobile 1 台あたり 100 PB まで転送できます。Snowmobile を使うと、ビデオライブラリや画像リポジトリ、またはデータセンター全体まで、膨大な量のデータを簡単にクラウドに移動できます。Snowmobile でのデータ転送は、より安全かつ高速で、コスト効率の良い方法です。

AWS SnowballとAWS Snowmobileの違い

10 PB を超える大規模なデータを一つの場所に移行する場合は、AWS Snowmobile。

10 PB 未満のデータセットの場合、または複数の場所に分散する場合には、Snowball を使用。

バックボーンの帯域によっては、容量が大きくてもSnowballを複数利用した方が効率が良い場合もあります。

参照)
Q: Snowmobile と Snowball のどちらを選択したらよいですか?
https://aws.amazon.com/jp/snowmobile/faqs/

はじめに

前回紹介した記事では自宅からWorkSpacesの仮想デスクトップ上でVPNの設定を行い、会社のネットワークにつなげる方法を紹介しました。
今回は自宅のPCにある資料をWorkDocsに置き、WorkSpacesからダウンロードして会社のネットワークからしかアクセスできない共有ドライブに送ってみたいと思います。

Amazon WorkDocsとは

AWS(Amazon Web Services)が提供しているクラウドストレージサービスです。イメージとしてはGoogle DriveやDropBoxのようなものでしょうか。
WorkDocs上に置いたコンテンツはユーザー間で共有でき、ダウンロードやバージョン管理をすることができるため非常に便利です。
また、WorkSpacesを利用しているユーザーは、50GBまで無料で利用することができます。

WorkDocsの設定

早速設定をしていきましょう。
AWS マネジメントコンソール画面>エンドユーザーコンピューティング>WorkDocs　をクリック。

WorkDocsサイトの管理画面が表示されます。
※画像はすでにサイト作成済みのものを使っているため、一覧にWorkDocsのURLが表示されています。
新しいWorkDocsサイトの作成　をクリック。

標準セットアップの起動をクリック。

Simple ADの作成　をクリック。

ディレクトリの詳細情報を入力していきます。

• アクセスポイント
  WorkDocsのアクセスURLになります。

• ディレクトリの詳細
  任意のDNS名を入力します。

• WorkDocs管理者の名前
  利用するユーザーのメールアドレス、姓、名を入力します。

• VPC設定
  WorkDocs で使用する既存の VPC を選択　を選択して、作成済みのVPCとサブネットを設定します。

最後に問題がないか確認して、問題がなければ作成してください。

WorcSpaceでWorkDocsと同期

WorcSpaceにアクセスし、Install Amazon WorkDocsをクリックします。

クライアントが立ち上がるので、詳しくはこちらをクリック。

WorkDocsサイトのURLを入力し、次へをクリックします。
※WorkSpacesの登録コードを入力すれば、WorKDocs作成の手順を経由する必要がないらしいのですが、未検証のため今回は作成済みのWorkDocsに同期するという方法を紹介しています。

WorcSpaceのユーザー名とパスワードを入力してサインインをクリックします。

WorkDocsと同期するフォルダの場所を決めます。
問題なければ次へをクリックします。

今回はすべてのファイルを同期します。

これでWorcSpace側の設定は完了です。

実際にファイルを同期してみる

ここからはWorkDocsの設定で作成したWorkDocsに実際にファイルを設置してみます。
WorkDocsサイトの管理画面からWorkDocsのURLをクリックします。

MyDocs画面が表示されます。
適当に作成したテキストファイルをドラッグ&ドロップでMyDocs画面に設置します。

WorkSpacesでWorkDocsと同期したフォルダに移動します。

設置した直後はファイルがありませんが...

しばらくすると同期が完了してテキストファイルが見えるようになりました。

会社の共有ドライブにファイルを設置

WorkSpacesからVPNで会社のネットワークにアクセスして、先ほどWorkDocsに置いたテキストファイルを共有ドライブに設置します。

後日、事務所から共有ドライブを確認すると無事に中身を見ることが出来ました。

背景

最も本試験の難易度に近いと言われている【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）の中で、
自分が解いていてつまづいた箇所をピックアップしました。

◆ つまづいた用語一覧

用語	意味
NATインスタンス	プライベートサブネットのインターネットアクセスを許可。 送信元/送信先チェックの無効化
NATゲートウェイ	目的はNATインスタンスと同じ。Elastic IPアドレスの割り当てが必須
ブロードキャストアドレス	同じネットワークにいる全ノードに対して同じデータを散布する
マルチキャスト	複数のノードに対して同じパケット(データ)を送付する
ハイパーバイザー	VMWare, Hyper-Vなどの仮想マシンソフト
インスタンスストアボリューム	インスタンスが終了・停止した際に削除される
instance-Store-Backed	起動ディスクがインスタンスストア
プロキシ	内部NWからインターネット接続を行う際の中継サーバ
ユーザデータ	EC2インスタンスの初回起動時に実行したい処理を設定する ※ElasticIPアドレスの紐付けなど
メタデータ	インスタンスIDやIPアドレスなどEC2インスタンス自身に関するデータ
DHCP(Dynamic Host Configuration Protocol)	クライアントサーバ方式で、DHCPサーバがNWアドレスを動的に割り当て、 設定情報と共に、ホストに送信する
クライアントサーバシステム	サーバ/クライアントに分け、役割分担する
トランザクション	複数の処理を１つにまとめたもの
OLTP(Online Transaction Processing)	トランザクション処理を行うデータベース
OLAP(Online Analytical Processing)	分析処理を行うデータベース
リスナー	接続リクエストをチェックするプロセスのこと
ALB パスベースルーティング	・明らかな不正アクセスを上位レイヤーで弾く役割 ・任意のアクセスパスをターゲットグループに登録する ・対象リスナー(https)などの設定
クラスタープレイスメントグループ	単一AZ内のインスタンスを論理的にグループ化 低レイテンシーのネットワークに参加する Linuxの拡張ネットワーキング合わせて使用される
カスタマーゲートウェイ	VPN接続の際の作業者側のアンカー
仮想プライベートゲートウェイ	VPN接続の際のAWS側のアンカー
MD5チェックサム	S3にアップロードされたオブジェクトの整合性を確認する AWS CLIで整合性を確認する MD5チェックサム値をHTTPヘッダーに格納する
CIDRブロック	IPアドレスのネットワーク部 / ホスト部で決められたブロック単位で区切るのが普通 CIDRは任意のブロック単位で区切ることが出来る
シャーディング	データを複数ノードに分割 リクエスト分散 / スループット向上
スループット	単位時間あたりに処理できる量のこと
マスター/スレーブ	1つが管理 / 残りが制御という役割方式
sequential	シーケンシャル順次的な / 連続的な
スポットブロック	スポットインスタンスを1〜６時間継続して利用できるようになった機能
スポットフリート	自動で最安値のインスタンスを選択して起動する
AWS STS	アクセスキー/シークレットキー/セッショントークンの３つが発行される
RDS/DBスナップショット	DBスナップショットを取得するためには新しいインスタンスの起動が必要 RDSのスケールアップには停止が必要
ECU(EC2 Compute Unit)	EC2インスタンスのスペック単位
Source IP	IAMロールを使用して、特定のIPアドレスからAPI呼び出しを制限する
WAF(web application Firewall)	IDS/IPSで防ぐことのできない不正な攻撃からwebアプリケーションを防御するファイアーウォールのこと
eth0	仮想サーバのNICがインターネット通信全開であること
インターフェース	機器に関する外部との接続部分の総称
VPC/サブネットのCIDR範囲	デフォルトVPCのCIDRは172.31.0.0/16、 デフォルトサブネットはCIDRのうち/20 CIDRを使用
S3 export/import	大量の物理ストレージデバイスからAWSに転送するのに使用するサービス
フェデレーション STS	認証の際にSTSを使用することでセキュリティが保持される
パッチ	母体のプログラムに追加することでプログラムの変更/機能追加を促せること
バッチ	複数の処理を　一括で行えるようにする方法
ラウンドロビン方式	ロードバランサーによるサーバ/リクエスト振り分け方式の一つ
IOPS(Input OutPut Per Second)	１秒あたりに処理出来るアクセス数 ※HDDは低い / SSDは高い
IOPSとスループット	1秒あたりの最大データ送信料　※スコープ(範囲)は広い ※bps /kbpsなど

WorkSpace料金体系

Workspacesの料金体系は、月額料金または時間料金の課金オプションの選択となっています。
※詳しくはこちら↓
https://aws.amazon.com/jp/workspaces/pricing/

しかし、月額料金/時間料金の切り替えに関する資料がどこにあるか分かりづらい。

切り替え方法

マネジメントコンソールWorkSpacesページで設定変更したいWorkSpaceを選択し、
アクションボタンから実行モードプロパティの変更をクリックする。

すると以下のようなモーダルが表示され、AlwaysOn/AutoStopの選択ができる。
どうやら実行モードプロパティの切り替えによって、月額料金/時間料金の切り替えが可能なようである。

タイトルにもある通り、CodeCommitのコンソール上でプルリクエストを作成し、マージができない状態に陥ったのでメモ。

今回は開発ブランチ（develop）をmasterブランチにマージしようとしたときに、コンソール上に下記のエラーが発生してマージすることができませんでした。

Tips Divergence Exceeded Exception The merge cannot be completed because the divergence between the branches is too great. If you want to merge these branches, use a Git client.

上記のエラーをそのまま簡単に訳すと「差分が多すぎるからマージできないよ。マージするならGitクライアント使ってね」といった感じでしょうか。

え、差分多いと（コミット数なのかな・・？）コンソール上でマージできないとかあるんですか・・・。

原因

この記事を見に来ていただいた方、すみません。
いろいろ調べては見てみたものの、具体的にこのエラーになる原因というものがつかめなかったです。

もし原因や解消方法がわかる方がいらしたらコメントいただけますと幸いです

回避策

根本的な解決策にはなっていないと思いますが、いったんエラー内容に書いてある通り、ローカル上でマージして、プッシュする形でやりたかったことはできました。