Amazon GuardDuty(1)GuardDutyの概要

GuardDutyとは

Amazon GuardDuty は、VPC フローログAWS CloudTrail イベントログDNS ログ を分析して、悪意のある操作や不正な動作を継続的にモニタリングする脅威検出サービス。AWS 環境内の予期しない潜在的に未許可なアクティビティや悪意のあるアクティビティを識別して、AWS アカウントとワークロードを保護を行う。

検出結果

潜在的に悪意のある予期しないアクティビティを検出すると、GuardDuty によって結果が生成される。またこれらの結果は、GuardDuty のマネージメントコンソールから閲覧できるだけでなく、 CloudWatch Events を利用して表示することもできる。

検出した脅威は以下のタイプに分類される。

タイプ 重要度 内容
Backdoor:EC2/Spambot EC2 インスタンスが ポート 25 でリモートホストと通信 して通常と異なる動作を示す。
Backdoor:EC2/C&CActivity.B!DNS EC2 インスタンスは、既知のコマンド&コントロールサーバーに関連付けられるドメイン名をクエリ している。
Backdoor:EC2/DenialOfService.Tcp EC2 インスタンスが、TCP プロトコルを使用したサービス拒否 (DoS) 攻撃の実行に利用されている可能性がある。
Backdoor:EC2/DenialOfService.Udp EC2 インスタンスが、UDP プロトコルを使用したサービス拒否 (DoS) 攻撃の実行に利用されている可能性がある。
Backdoor:EC2/DenialOfService.Dns EC2 インスタンスが、DNS プロトコルを使用したサービス拒否 (DoS) 攻撃の実行に利用されている可能性がある。
Backdoor:EC2/DenialOfService.UdpOnTcpPorts EC2 インスタンスが、TCP ポートで UDP プロトコルを使用したサービス拒否 (DoS) 攻撃の実行に利用されている可能性がある。
Backdoor:EC2/DenialOfService.UnusualProtocol EC2 インスタンスが、異常なプロトコルを使用したサービス拒否 (DoS) 攻撃の実行に利用されている可能性がある。
Behavior:EC2/NetworkPortUnusual EC2 インスタンスが 通常と異なるポート でリモートホストと通信している。
Behavior:EC2/TrafficVolumeUnusual EC2 インスタンスがリモートホストに対して通常と異なる 大量のネットワークトラフィック を生成している。
CryptoCurrency:EC2/BitcoinTool.B!DNS EC2 インスタンスは、 暗号通貨 関連のアクティビティに関連付けられているドメイン名をクエリしている。
CryptoCurrency:EC2/BitcoinTool.B EC2 インスタンスは、 暗号通貨 関連のアクティビティに関連付けられている IP アドレスをクエリしている。
PenTest:IAMUser/KaliLinux API が Kali Linux EC2 インスタンスから呼び出されました。
PenTest:IAMUser/ParrotLinux API が Parrot Security Linux EC2 インスタンスから呼び出されました。
PenTest:IAMUser/PentooLinux API が Pentoo Linux EC2 インスタンスから呼び出されました。
Persistence:IAMUser/NetworkPermissions プリンシパルが、通常 AWS アカウントの セキュリティグループ、ルート、ACL のネットワークアクセス許可を変更 するために使用される API を呼び出した。
Persistence:IAMUser/ResourcePermissions プリンシパルが、通常 AWS アカウントのさまざまなリソースの セキュリティアクセスポリシーを変更 するために使用される API を呼び出した。
Persistence:IAMUser/UserPermissions プリンシパルが、通常 AWS アカウントの IAM ユーザー、グループ、ポリシーを追加、変更、削除 するために使用される API を呼び出した。
Policy:IAMUser/S3BlockPublicAccessDisabled バケットの Amazon S3 ブロック パブリックアクセスが無効 になった。
Policy:IAMUser/RootCredentialUsage API が ルート認証情報を使用 して呼び出された。
PrivilegeEscalation:IAMUser/AdministrativePermissions プリンシパルが 許容度の高いポリシーを割り当て ようとしている。
Recon:EC2/PortProbeUnprotectedPort EC2 インスタンスの 保護されていないポートを既知の悪意のあるホストが探している
Recon:EC2/PortProbeEMRUnprotectedPort EMR クラスタの 保護されていないポートを既知の悪意のあるホストが探している
Recon:IAMUser/TorIPCaller API が Tor 出口ノード の IP アドレスから呼び出された。
Recon:IAMUser/MaliciousIPCaller.Custom API が カスタム脅威リストにある IP アドレス から呼び出された。
Recon:IAMUser/MaliciousIPCaller API が既知の 悪意のある IP アドレス から呼び出された。
Recon:EC2/Portscan EC2 インスタンスがリモートホストに アウトバウンドポートスキャン を実行している。
Recon:IAMUser/NetworkPermissions プリンシパルが、通常 AWS アカウントの既存のセキュリティグループ、ACL、ルートの ネットワークアクセス許可を検出 するために使用される API を呼び出した。
Recon:IAMUser/ResourcePermissions プリンシパルが、通常 AWS アカウントのさまざまなリソースに関連付けられた アクセス権限を検出 するために使用される API を呼び出した。
ResourceConsumption:IAMUser/ComputeResources プリンシパルが、通常 EC2 インスタンスなどの コンピューティングリソースを起動 するために使用される API を呼び出した。
Stealth:IAMUser/S3ServerAccessLoggingDisabled バケットの Amazon S3 サーバーアクセスログ記録が無効 になった.
Stealth:IAMUser/PasswordPolicyChange アカウントの パスワードポリシーが弱化 された.
Stealth:IAMUser/CloudTrailLoggingDisabled AWS CloudTrail の証跡が無効化 されている。
Stealth:IAMUser/LoggingConfigurationModified プリンシパルが、通常 AWS アカウントの CloudTrail ログ記録の停止、既存ログの削除 、その他アクティビティの痕跡を消去するために使用される API を呼び出した。
Trojan:EC2/BlackholeTraffic EC2 インスタンスは、ブラックホール と呼ばれるリモートホストの IP アドレスに通信しようとしている。
Trojan:EC2/DropPoint EC2 インスタンスは、マルウェア によって収集された認証情報やその他の盗難されたデータによって認識されているリモートホストの IP アドレスに通信しようとしている。
Trojan:EC2/BlackholeTraffic!DNS EC2 インスタンスは、ブラックホール IP アドレスにリダイレクトされるドメイン名へのクエリを実行している。
Trojan:EC2/DriveBySourceTraffic!DNS EC2 インスタンスは、Drive By Download 攻撃 の既知のソースであるリモートホストのドメイン名をクエリしている。
Trojan:EC2/DropPoint!DNS EC2 インスタンスは、マルウェア によって収集された認証情報やその他の盗難されたデータによって認識されているリモートホストのドメイン名をクエリしている。
Trojan:EC2/DGADomainRequest.B EC2 インスタンスで、アルゴリズムを使用して生成されたドメイン がクエリされている。
Trojan:EC2/DGADomainRequest.C!DNS EC2 インスタンスで、アルゴリズムを使用して生成されたドメイン がクエリされています。このようなドメインは、一般的にマルウェアによって悪用されることが多く、EC2 インスタンスが侵害されている場合がある。
Trojan:EC2/DNSDataExfiltration EC2 インスタンスが DNS クエリを通じて データを密かに抽出 しようとしている。
Trojan:EC2/PhishingDomainRequest!DNS EC2 インスタンスは フィッシング攻撃 に関与するクエリ実行のドメインである。
UnauthorizedAccess:EC2/MetadataDNSRebind Amazon EC2 インスタンスが、インスタンスメタデータサービスに解決される DNS ルックアップ を実行している。
UnauthorizedAccess:IAMUser/TorIPCaller API が Tor 出口ノードの IP アドレスから呼び出された。
UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom API が カスタム脅威リスト にある IP アドレスから呼び出された。
UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B 世界中でコンソールに対する複数の正常なログインが確認 された。
UnauthorizedAccess:IAMUser/MaliciousIPCaller API が既知の悪意のある IP アドレス から呼び出された。
UnauthorizedAccess:EC2/TorIPCaller EC2 インスタンスが Tor 出口ノードからのインバウンド接続を受信している。
UnauthorizedAccess:EC2/MaliciousIPCaller.Custom EC2 インスタンスが カスタム脅威リスト内の IP アドレス とアウトバウンド通信している。
UnauthorizedAccess:EC2/SSHBruteForce EC2 インスタンスが SSH ブルートフォース攻撃 に関与している。
UnauthorizedAccess:EC2/RDPBruteForce EC2 インスタンスが RDP ブルートフォース攻撃 に関与している。
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration インスタンス起動ロールを通じて EC2 インスタンス専用に作成された 認証情報が外部 IP アドレスから使用されている
UnauthorizedAccess:IAMUser/ConsoleLogin AWS アカウントのプリンシパルによる 通常とは違うコンソールへのログイン が確認された。
UnauthorizedAccess:EC2/TorClient EC2 インスタンスは Tor Guard または Authority ノードに接続している。
UnauthorizedAccess:EC2/TorRelay EC2 インスタンスは、Tor リレーとして Tor ネットワークに接続中である。

Amazon GuardDuty のセットアップ

Amazon GuardDutyはCloudFormationに対応しているため、CloudFormation経由でGuardDutyをセットアップすることができる。

サービスロールの有効化

以下のサービスロールを有効化することで、EC2リストの読み込み権限GuardDuty に付与する。これは、悪意のあるアクティビティに関係する AWS 環境の EC2 インスタンスのメタデータを取得するためである。

Resources:
  ServiceLinkedRoleForGuardDuty:
    Type: AWS::IAM::ServiceLinkedRole
    DeletionPolicy: Retain
    Properties: 
      AWSServiceName: guardduty.amazonaws.com
      Description: A service-linked role required for Amazon GuardDuty to access your resources.

GuardDutyの有効化

GuardDuty を有効化する。有効化すると直ちにデータの取得と分析を開始する。 これらの処理は、通常のAWS CloudTrail、VPC フローログ、および DNS ログの保存とは独立している。

Resources:
  GuardDutyDetector:
    DependsOn:
      - ServiceLinkedRoleForGuardDuty
    Type: AWS::GuardDuty::Detector
    Properties:
      Enable: true

CloudFormation Launch Stack URL

以下のボタンから上のCloudFormationテンプレートを実行することが可能である。ソースコードは、aws-cloudformation-templates/security – GitHub にて公開。

作成されるAWSサービス CloudFormationテンプレート
セキュリティサービス全般 cloudformation-launch-stack
GuardDutyのみ cloudformation-launch-stack

AWS Config(1)Configの概要

AWS Configとは

AWS Configは、リソースごとの設定項目を生成し、履歴としてこれを保持するため、全ての変更を追跡することが可能で、AWSリソース間の関係と設定の履歴などを確認することができる。

  • リソースの設定が最適であるか
  • 現在のスナップショットの取得
  • リソース設定の取得
  • 設定履歴の取得
  • リソース間の関係の表示
  • 通知

これらの機能を用いて、リソースの管理監査とコンプライアンス設定変更の確認とトラブルシューティングセキュリティ分析などを行うことができる。

設定項目は、S3バケットに蓄積することが可能で、データはJSON形式で、S3に6時間ごとに送信される。また、リソースが変更されたタイミング等で、Amazon SNSを用いてEメール等で通知することも可能である。

AWS Configは、マルチアカウントマルチリージョンの データ集約 に対応しており、複数のアカウントやリージョンの設定、コンプライアンスデータを1つのアカウントに集約することができる。

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2016-aws-cloudtrail-aws-config?ref=https://tech.blog.surbiton.jp/

AWS Configの概念

設定履歴と設定項目、スナップショット、レコーダ

設定履歴は、特定期間の特定リソースに関する設定項目のコレクションである。また、設定項目は、アカウント内のサポートされているAWSリソースの属性(メタデータ、関係、設定、関連イベントなど)を記録したものである。設定スナップショット は、設定項目のコレクションで、記録対象のリソースの全体像を示す。スナップショットは、S3 Bucketに配信が可能。

設定レコーダは、(標準設定では)Configがサポートしている全てのリソースの設定項目の評価と保存を行う。設定レコーダをオフにすると設定変更トリガによる評価は実行されない。一方で、定期実行トリガは引き続き指定した間隔で実行される

設定ストリーム

設定ストリームは、設定項目の自動更新リストで、リソースの作成や変更、削除が行われる度に、Amazon SNSを使用して通知を行うことができる。

ルール

AWS Configでは、望ましい設定をルールとして定めることができ、これに違反しているリソースに対しては、非準拠 のフラグを立てる。ルールは、事前に用意されたマネージドルールのほかに、ユーザが自ら作成したカスタムルールを適用することもできる。これらのルールは、リソースの設定変更時に評価されるのか、それとも定期的に評価されるのかを定義することができる。

AWS Configの仕組み

AWS Configは、サポートされているAWSリソースを検出し、リソースごとに設定項目を生成し、その記録を履歴として保持する。Configはリソースごとに、DescribeもしくはListのAPIコールによって、リソースの全ての変更を追跡する。Configルールを利用することで、定期的にこのルールに照らして、リソースの設定の評価を行うことができる。

また、この設定項目は、S3バケット もしくは Amazon SNS に配信することができる。SNSへ配信時のメッセージタイプは以下の通り。

メッセージタイプ 内容
ComplianceChangeNotification コンプライアンスタイプの変更時
ConfigRulesEvaluationStarted リソースの評価開始時
ConfigurationSnapshotDeliveryStarted スナップショット配信開始時
ConfigurationSnapshotDeliveryCompleted スナップショット配信完了時
ConfigurationSnapshotDeliveryFailed スナップショット配信失敗時
ConfigurationHistoryDeliveryCompleted 設定履歴配信完了時
ConfigurationItemChangeNotification リソース変更時
OversizedConfigurationItemChangeNotification SNSの最大サイズ超過時

AWS Configのセットアップ

AWS ConfigはCloudFormationに対応しているため、CloudFormation経由でConfigをセットアップすることができる。

サービスロールの有効化

以下のサービスロールを有効化することで、AWSリソースの読み込み権限 および S3への書き込み権限Config に、IAMとSystemManagerへの書き込み権限Config Remediation にそれぞれ付与する。

Resources:
  ServiceLinkedRoleForConfig:
    Type: AWS::IAM::ServiceLinkedRole
    DeletionPolicy: Retain
    Properties: 
      AWSServiceName: config.amazonaws.com
      Description: A service-linked role required for AWS Config to access your resources.
  ServiceLinkedRoleForConfigRemediation:
    Type: AWS::IAM::ServiceLinkedRole
    DeletionPolicy: Retain
    Properties: 
      AWSServiceName: remediation.config.amazonaws.com 
      Description: A service-linked role required for AWS Config Remediation to access your resources.

Configの有効化

DeliveryChannelConfigurationRecorder を作成する。

Resources:
  ConfigDeliveryChannel:
    Type: AWS::Config::DeliveryChannel
    Properties:
      Name: default
      S3BucketName: !Ref S3ForConfig
      SnsTopicARN: !Ref SnsTopicARN
  ConfigConfigurationRecorder:
    Type: AWS::Config::ConfigurationRecorder
    Properties:
      Name: default
      RecordingGroup:
        AllSupported: true
        IncludeGlobalResourceTypes: true
      RoleARN: !Sub arn:aws:iam::${AWS::AccountId}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig

すでにAWS Configをセットアップ済みの状態で上記テンプレートを実行すると、 the maximum number of delivery channels エラーが発生する。その場合は既存の DeliveryChannel を削除した上で、上記テンプレートを再度実行する。

aws configservice delete-delivery-channel --delivery-channel-name default
aws configservice delete-configuration-recorder --configuration-recorder-name default

S3バケットの作成

設定情報 (履歴ファイルやスナップショット)を保存するために使用する、Amazon S3 バケットと、それに紐づくバケットポリシーを作成する。

Resources:
  S3ForConfig:
    Type: 'AWS::S3::Bucket'
    DeletionPolicy: Retain
    Properties:
      BucketName: !Sub defaultsecuritysettings-config-${AWS::Region}-${AWS::AccountId}
      LifecycleConfiguration:
        Rules:
          - Id: ExpirationInDays
            ExpirationInDays: 60
            Status: Enabled
      PublicAccessBlockConfiguration: 
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
  S3BucketPolicyForConfig:
    Type: AWS::S3::BucketPolicy
    Properties: 
      Bucket: !Ref S3ForConfig
      PolicyDocument:
        Version: 2012-10-17
        Id: !Ref S3ForConfig
        Statement:
          - Effect: Allow
            Principal:
              Service: config.amazonaws.com
            Action:
              - 's3:GetBucketAcl'
              - 's3:ListBucket'
            Resource:
              - !GetAtt S3ForConfig.Arn
          - Effect: Allow
            Principal:
              Service: config.amazonaws.com
            Action:
              - 's3:PutObject'
            Resource:
              - !Join
                - ''
                - - !GetAtt S3ForConfig.Arn
                  - /AWSLogs/
                  - !Sub ${AWS::AccountId}
                  - /Config/*
            Condition:
              StringEquals:
                s3:x-amz-acl: bucket-owner-full-control

CloudFormation Launch Stack URL

以下のボタンから上のCloudFormationテンプレートを実行することが可能である。ソースコードは、aws-cloudformation-templates/security – GitHub にて公開。

作成されるAWSサービス CloudFormationテンプレート
セキュリティサービス全般 cloudformation-launch-stack
Configのみ cloudformation-launch-stack

モニタリング

他のAWSサービスを利用して、AWS Configのリソースをモニタリングすることができる。例えば、Amazon SQSAmazon CloudWatch Eventsを利用することで、AWSリソースが作成、変更、削除された際に通知を受け取ることが可能となる。

AWS Security Hub(1)Security Hubの概要

Security Hubとは

Security Hubは、Amazon GuardDutyAmazon InspectorAmazon Macie などのAWSが提供するセキュリティ関連サービスや、AWSパートナーが提供するセキュリティ製品からの セキュリティ検出結果等を統合的に閲覧可能なサービス で、本サービスを利用することで、情報の収集や優先度の決定などのコストを低減できる。発見事項は、Security Hub内に90日保管 される。Security Hubは、リージョンサービスであり、使用するリージョン毎にサービスを有効化する必要 がある。一方で、 複数アカウントをサポート しており、全てのアカウントを統合して発見事項を表示することもできる。

また、Center for Internet Security (CIS) AWS Foundations Benchmark のスコア表示にも対応しており、業界標準のベストプラクティスをどの程度満たしているかについても確認することが可能となっている。なお、この機能を正常に実行するためには、AWS Configを有効化することが必要。ベストプラクティスを満たしていない場合は、Security Hubから修復方法を確認することができる。

Amazon CloudWatch Eventsとの統合がサポートされているため、検出結果を受信した際に実行するカスタムアクションを規定することもできる。

また、インサイトと呼ばれるグループ化された検出結果のコレクションが存在し、コレクションを用いることで、修復が必要な問題の特定ができる。カスタムインサイトを作成することも可能。

AWS Security Hub のセットアップ

一部機能のみではあるがCloudFormationに対応しているため、CloudFormation経由でSecurity Hubをセットアップすることができる。

サービスロールの有効化

以下のサービスロールを有効化することで、AWS CloudTrail, AWS Config, Amazon CloudWatch Logs および Amazon SNS から 情報を取得する権限 を Security Hub 付与する。また、AWS Config に対して 新たなConfigルールを設定する権限 も付与される。このルールは、CIS AWS Foundationsコンプライアンスチェックに使用される。これらを正常に動作させるためには、 AWS Configを有効化 しておく必要がある。

Resources:
  ServiceLinkedRoleForSecurityHub:
    Type: AWS::IAM::ServiceLinkedRole
    DeletionPolicy: Retain
    Properties: 
      AWSServiceName: securityhub.amazonaws.com
      Description: A service-linked role required for AWS Security Hub to access your resources.

Security Hubの有効化

Security Hubを有効化することで、CIS AWS Foundationsコンプライアンスチェックが自動で有効化される。

Resources:
  SecurityHub:
    DependsOn:
      - ServiceLinkedRoleForSecurityHub
    Type: AWS::SecurityHub::Hub

AWS Security Hubのセットアップテンプレート

AWS Security Hubを含むAWSのセキュリティサービスをまとめて有効化できるCloudFormationテンプレートを公開している。

作成されるAWSサービス CloudFormationテンプレート
セキュリティサービス全般 cloudformation-launch-stack
Security Hub のみ cloudformation-launch-stack

CIS AWS Foundationsコンプライアンスチェック

Security Hubは、AWS Configに新たなConfigルールを自動的に作成した上で、Center for Internet Security (CIS) AWS Foundations Benchmarkに適合しているかのチェックを行う。Security Hubは、AWS Security Finding と呼ばれるテンプレートに沿って検出結果を表示するために、結果毎にデータ変換等を行う必要がない。AWS Security Finding の構成については、下記を参照のこと。

なお、CIS AWS Foundationsは、同一リージョン内のリソースに対しての結果のみ有効であり、他のリージョンのリソースに対しての結果は FAILED が返却される。したがって、例えば複数のリージョンでCloudTrailが有効化されており、各リージョンで証跡用およびアクセスログ用のバケットが作成されている場合は、チェック 2.3 および 2.6は非準拠として表示される

チェックは、前回から12時間以内に再度実行 される。また、変更によってトリガーされるチェックに関しては、リソースに変更が変更された際に実行される。

AWSサービスとの統合

Security Hubは、Amazon GuardDutyAmazon InspectorAmazon Macie など、AWSが提供するセキュリティ関連サービスで生成されたセキュリティ検索結果を統合することができる。統合を行うためには、各AWSサービスを有効化する必要がある。

CloudWatchイベントによる自動化

CloudWatchイベントを使用して、Security Hubで検知した問題やリソースの変更に自動的に対応することが可能である。以下の通知を行うことが可能である。

  1. 全ての結果を自動的にCloudWatchイベントに送信
  2. カスタムアクションに関連づけられた結果をCloudWatchイベントに送信
  3. カスタムアクションを使用してインサイトの結果をCloudWatchイベントに送信

1.の場合は、CIS AWS Foundationsコンプライアンスチェックに準拠している状態でも非準拠の場合でも、全ての結果が CloudWatch Events に送信されてしまうので、そのうち 準拠から非準拠となった状態のイベントのみを受信して、Amazon SNS に送信する場合は、以下のような Amazon CloudWatch Events を作成する。

  CloudWatchEventsForSecurityHub:
    Type: AWS::Events::Rule
    Properties: 
      Description: CloudWatch Events about SecurityHub.
      EventPattern:
        source:
          - aws.securityhub
        detail-type: 
          - Security Hub Findings - Imported
        # Events fired when status has been changed from PASSED to ARCHIVED.
        detail:
          findings:
            Compliance:
              Status:
                - PASSED
            RecordState:
              - ARCHIVED
      Name: AWS_Security_Hub
      State: ENABLED
      Targets:
        - Arn: !Ref SnsTopicARN
          Id: CloudWatchEventsForSecurityHub

これは、結果のステータスが PASSED から FAILED に変化した場合、

  1. 既存の結果のステータスを PASSED から ARCHIVED に設定
  2. 結果のステータスが FAILE である新たな結果を生成

という挙動となるため、1.の挙動のみを検知することで実現している。

CloudFormation Launch Stack URL

以下のボタンから上のCloudFormationテンプレートを実行することが可能である。ソースコードは、aws-cloudformation-templates/security – GitHub にて公開。

作成されるAWSサービス CloudFormationテンプレート
セキュリティサービス全般 cloudformation-launch-stack
Security Hub のみ cloudformation-launch-stack

AWS Connect(1)AWS Connectの概要

AWS Connectとは

AWS Connectとはクラウド型コンタクトセンターで、Amazonのコンタクトセンターと同じ技術が使われている。グラフィカルインタフェースを用いることでコーディングすることなく、対応フローの設計、スタッフの管理などが簡単に実現できる。

インフラの管理が不要で手軽に規模を拡大縮小できる。また、Amazon Lexとの連携によって自動応答を実現したり、CRMソリューションと連携して顧客情報の管理を行うこともできる。また、アウトバンドコンタクトAPIを用いて、スケジュールした時刻にプログラムから電話を発信することも可能である。

サポートされているブラウザは、最新3バージョンChrome最新Firefox。東京リージョンに対応し日本語にも対応している。

AWS Amplify Framework(1)Amplifyの概要

AWS Amplify Frameworkとは

AWS Amplifyは、モバイルアプリやウェブアプリの実装を容易にするフレームワークで、AWS上のバックエンドをプロビジョニングし、iOSAndroidWeb、React Native上などのフロントエンドと簡単に統合することが可能なライブラリUIコンポーネントCLIなどを提供する。バックエンドのサービスを設定可能なAmplify CLIや、Web上に展開するAmplify JSなどのリソースがGitHub上で提供されており、認証解析プッシュ通知ボットなどの機能を実装することが可能である。

Amplify Frameworkは、カテゴリベースのプログラミングモデルを採用しており、対話式の設定画面から各カテゴリを追加/編集/削除することができる。

機能名 Frontend API Backend Category AWSサービス 内容
Analytics AnalyticsClass analytics Pinpoint ユーザのセッションや属性などを計測
Interactions Interactions intaraction Lex Botの構築
Cache CacheObject LRUキャッシュ
API APIClass api Lambda + API Gateway REST/GraphQL APIの利用
PubSub PubSub IoT リアルタイムデータのやりとり
Hub HubClass ユーザセッション、属性等を追跡
Authentication AuthClass auth Cognito 認証APIとpre-build UI component
Notification PushNotification notifications Pinpoint プッシュ通知
I18n I18n 多言語化
Storage StorageClass storage S3, DynamoDB 静的コンテンツの管理
XR XR xr Sumerian AR/VR
Logger Logger コンソールログの記録
Service Worker ServiceWorkerClass
function Lambda 関数の作成
hosting S3, CloudFront Webサイトホスティング
Predictions prediction Recognition など 予測

Amplify CLI

Amplify CLIを用いることでバックエンドを簡単に設定することができる。バックエンドのカテゴリごとにカテゴリプラグインや、プロバイダープラグインフロンドエンドプラグインなど様々なプラグインが用意されている。これらのリソースの状況は、amplify statusコマンドで確認することができる。

初期設定

amplify initコマンドを実行することで、フロントエンドの設定確認と初期化、AWS上のバックエンドをセットアップすることができる。このとき、CloudFormation経由で IAMロールやS3バケットの作成 も行われる。

コマンド 実行内容 備考
amplify init Amplify プロジェクトを作成/初期化, IAMロールの作成 ルートディレクトリで実行すること
amplify delete Amplify プロジェクトをすべて削除 再度構築する場合は amplify init が必要

コマンドの実行手順は以下の通り。

実行順序 コマンド 内容
1 amplify configure AWSユーザや認証情報の設定
2 amplify init プロジェクトの作成
3 amplify add カテゴリの追加
4 amplify push バックエンドのデプロイ

バックエンドの環境設定

1つのプロジェクトは設定の異なる複数のバックエンド(=Env)を持つことが可能で、amplify envコマンドを用いてこれらのバックエンドを切り替えることが可能。Gitのブランチと組み合わせることも可能で、masterブランチ上のプロジェクトはprod環境のバックエンド上にデプロイ、developブランチ上のプロジェクトはdevelop環境のバックエンド上にデプロイするなどの設定を行うことができる。万が一、AWS上のCloudFormationを削除してしまった状態のままデプロイした場合はエラーとなるので、この場合はamplify initコマンドでバックエンドの再生成が必要となる。

コマンド 実行内容
amplify env add <ENV> バックエンドを追加
amplify env remove <ENV> バックエンドを削除
amplify env pull <ENV> –restore AWS上のバックエンド設定を参照して上書き
amplify env ckeckout <ENV> –restore 指定した環境設定を適用
amplify env list バックエンドの一覧を表示

AWS Amplify Console等の外部サービスでAmplifyをデプロイしたあとに、amplify pushコマンドを用いて開発環境上でデプロイを実行すると、バックエンドのデプロイ状態に差異が生じているためにデプロイに失敗する。上記のamplify env pullコマンドによって、AWS上の最新のバックエンド情報を取得することで、この問題は解決する。

カテゴリの追加と削除

上述のようにAmplify Frameworkは、認証解析などの様々な機能を有している。これらの機能(=カテゴリ)を自身のプロジェクトに追加したり削除したりするのが以下のコマンドである。

コマンド 実行内容
amplify add <CATEGORY> カテゴリを追加
amplify update <CATEGORY> カテゴリを更新
amplify remove <CATEGORY> カテゴリを削除

その他のコマンド

その他よく使うコマンドは以下の通り。

コマンド 実行内容
amplify status Amplify プロジェクトのステータスを表示
amplify push Amplify プロジェクトをAWS上でデプロイ
amplify pull AWSから設定情報を取得し、ローカル環境を変更
amplify console AWSのマネージメントコンソールに遷移
amplify delete Amplify プロジェクトを削除

Amplifyプロジェクト

Amplifyプロジェクトは、以下のようなディレクトリ構成となっている。

.
├── amplify/
│   ├── .config/                        (自動生成)   クラウドの構成とユーザー設定を格納 (amplify init)
│   │   ├── local-aws-info.json         (自動生成)  AWSクレデンシャルのプロファイル名を格納
│   │   ├── local-env-info.json         (自動生成)  ローカルのディレクトリやIDEの設定を格納
│   │   └── project-config.json         (自動生成)  プロジェクトの設定を格納       
│   ├── backend/
│   │   ├─── api
│   │   │   └── PROJECT_NAME
│   │   │       └── schema.graphql      (編集可)    GraphQLのスキーマ
│   │   ├─── auth
│   │   │   └── PROJECT_NAME
│   │   │       └── parameters.json     (編集可)    プロンプトで設定した内容を格納(amplify add auth)
│   │   ├── amplify-meta.json          (自動生成)   AWSリソースの設定情報(Permission, Category)を格納, Gitリポジトリの管理対象外
│   │   └── awscloudformation          (自動生成)   CloudFormationのルートスタック, Gitリポジトリの管理対象外   
│   ├──  #current-cloud-backend/       (自動生成)  直近に取得したクラウド構成, Gitリポジトリの管理対象外
│   └──  team-provider-info.json       (自動生成)  Environment設定(Permission, Category, CloudFormation Stack)を格納
└──  src/
    ├── App.vue                         (編集可)     Vueの単一コンポーネントファイル   
    ├── aws-exports.js                  (自動生成)   AWSリソースのエンドポイント等の情報を格納, Gitリポジトリの管理対象外 (amplify init)
    ├── components/                     (手動生成)   作成したVueコンポーネント
    │    ├── Authenticator.vue         (自動生成)   認証画面コンポーネント
    │    └── Main.vue                  (手動生成)   メインコンポーネント
    ├── graph/                          (自動生成)   GraphQL statement
    │    ├── mutation.js               (自動生成)   
    │    ├── queries.js                (自動生成)   
    │    ├── schema.json               (自動生成)   
    │    └── subcriptions.js           (自動生成)   
    ├── main.js                         (編集可)     Vueのエントリーポイント 
    ├── package.json                    (自動生成)   依存関係のあるライブラリの一覧
    └── router/                         (手動生成)   ルータコンポーネント
         └── index.js                  (手動生成) 

AWS EC2(7)Auto Scaling

EC2 Auto Scalingとは

EC2 Auto Scalingを用いることで、アプリケーションの負荷を処理するための適切な数のEC2インスタンスを利用することができる、。Auto Scalingを利用するためには、Auto Scalingグループと呼ばれるEC2インスタンスの集合を定義し、このグループに含まれる最小と最大のインスタンスの数を定義する。また、希望するインスタンス数(Desired capacity)を定義することも可能。また、Auto Scalingグループ内のEC2インスタンスを複数のAZに分散配置することで、地理的な冗長性や安全性を実現できる。

Auto Scaling グループ

Auto Scalingを用いることで、耐障害性や可用性が向上する。また、必要な数のインスタンスのみ起動されるため安定的なパフォーマンスを低コストで実現することができる。

Auto Scalingグループ内の各EC2インスタンスの負荷に偏りが発生した場合は、古いインスタンスを終了して新しいインスタンスを起動させる。この場合にスムーズに処理が継続されるように、一時的に最大容量に対して10%のマージンが確保される

ライフサイクル

Auto Scalingのライフサイクルは以下の通り。

ライフサイクル

Auto Scalingグループはグループ内のインスタンスに対して定期的にヘルスチェックを行なっている。スケールイン/アウトは、手動もしくはスケーリングポリシースケジュールに基づき実行される。スケールイン、ヘルスチェックの失敗、Auto Scalingグループからの離脱等が発生した場合には、Auto Scalingグループ内のEC2インスタンスは終了処理が実施される。

Auto Scalingグループ

起動設定

Auto Scalingグループ内のEC2インスタンスは、起動テンプレートもしくは起動設定の設定内容に基づいて起動される。これらには、AMIのIDやインスタンスタイプ、ネットワーク設定、ストレージの設定、オンデマンドインスタンスとスポットインスタンスの配分等が含まれる。また、起動設定は、既に起動済みのインスタンスの属性を使用して作成することも可能である。Auto Scalingグループに関連付けられる起動設定は1つだけであり、グループ作成後に変更することはできない。Auto Scalingグループに関連づける起動設定を変更する場合は、現在の起動設定をコピーした上で新たな起動設定を作成し、これを当該のAuto Scalingグループに紐づける。

ロードバランサとの連携

Auto Scalingで増減したインスタンスに対して適切にトラフィックが分散されるようにするためには、Elastic Load Balancingの受信トラフィックの通信先にAuto Scalingグループを指定する。Auto Scalingのヘルスチェックは、通常EC2のステータスチェックのみであるが、オプションでELBのヘルスチェックを用いてAuto Scalingグループのヘルスチェックを行う設定にすることも可能である。この場合、ELBから送られる定期的なPINGに応答しないなど、ELBのヘルスチェック合格しなかった場合、このインスタンスは異常ありと判定されて他のインスタンスに置き換えられる。

スケーリング

Auto Scalingでは、以下のスケーリング方法を実施可能である。

  • 現在のインスタンスレベルの維持
  • 手動スケーリング
  • スケジュールに基づくスケーリング
  • 要求に基づくスケーリング(動的スケーリング

CloudWatchのメトリクスを利用して複数のスケーリングポリシーを適用することも可能である。例えば、EC2のCPU使用率を指標としたポリシーと、SQSのメッセージ処理に関するメトリクスを指標としたポリシーを同時に適用する、といったような場合である。複数のポリシーが適用となった場合は、より影響を与えるポリシーの実行命令が優先される

スケジュールされたスケーリング

あらかじめ指定したスケジュールに沿って、スケーリングアクションが実行されるように指定することが可能である。スケーリングアクションが有効になる時間と、最小/最大サイズ希望するサイズを指定する。このスケジュールは、1回のみ実行することも定期的に実行することもできる。

スケジュールされたスケーリングを作成する場合、ほとんどの場合指定した時刻から数秒以内に実行されるが、最大2分ほど遅れる可能性もあるので留意が必要である。また、複数のスケジュールを同時刻に設定することはできない。

動的スケーリング

動的スケーリングは、以下の方法をサポートしている。

ポリシー名 トリガおよび動作
Target tracking scaling 特定のメトリクスのターゲット値を維持するようにスケーリング
Step scaling 複数のスケーリング調整値をトリガにスケーリング
Simple scaling 1つのスケーリング調整値をトリガにスケーリング

Simple scaling および Step scaling

トリガに基づいてスケーリングが実行される際には、以下の調整タイプに基づいてスケーリングが実行される。

調整タイプ 動作
ChangeInCapacity 指定した数だけ増減する
ExactCapacity 指定した数になるように増減する
PercentChangeInCapacity 割合指定する

また、Step scalingの場合は、新しく起動されたインスタンスがAuto Scalingグループに追加されるまでの待ち時間(ウォームアップ)を指定できる。

SQSに基づくスケーリング

SQSにキューが積み上がり、処理が遅延することがないようにするには、 SQSのデータを読み取り処理を行うEC2をAuto Scalingさせる必要がある。このAuto Scalingを適切にスケーリングさせるためには、 Amazon SQS メトリックスApproximateNumberOfMessagesを用いてキューの長さを測定した上で、1インスタンスあたりの処理能力を計算しどの程度スケーリングさせる必要があるか指定する。

SQSに基づくスケーリング

クールダウン

メトリクス値が短期間で増減し、その度にスケーリングが実行されることを防ぐために、クールダウン期間が設けられている。デフォルトのクールダウン値は300秒。クールダウン期間は新たなスケーリングは実行できない。なお、このクールダウンが有効なのは、Simple scalingのみ。

インスタンスの停止

スケールイン時に停止されるインスタンスは以下の条件で決定される。

  1. インスタンスが最も多いAZ
  2. 最も古い起動設定またはテンプレートを使用している
  3. 次の課金開始時間に近いインスタンス

終了時ポリシーはカスタマイズが可能である。また、終了から保護するインスタンスを指定することもできる。

ポリシー名 実行内容
OldestInstance 最も古いインスタンス
NewestInstance 最も新しいインスタンス
OldestLaunchConfiguration 最も古い起動設定のインスタンス
ClosestToNextInstanceHour 次の課金開始時間に近いインスタンス
Default デフォルト(上記)
OldestLaunchTemplate 最も古い起動テンプレート
AllocationStrategy オンデマンド/スポットの割り当て戦略に合わせて決定

ライフサイクルフック

インスタンスの起動時もしくは削除時に一時停止して、カスタムアクションを実行できる機能。ソフトウェア等をインストールできる。

ライフサイクルフック

スケーリングプロセスの中断と再開

スケーリングプロセスの1つ以上を停止し、あとで再開できる。

スケーリングプロセス 内容
Launch インスタンスを追加
Terminate インスタンスを削除
HealthCheck ヘルスチェック
ReplaceUnhealthy 異常なインスタンスを削除し代替インスタンスを作成
AZRebalance AZ間のバランスを調整
AlarmNotification CloudWatchからアラーム通知を受け取る
ScheduledActions スケジュールされたアクションを実施
AddToLoadBalancer ELBに追加

注意事項

Auto Scalingは、バーストトラフィックには対応できない

AWS ElastiCache(1)ElastiCacheの概要

Elasticacheとは

完全マネージドなRedis および Memcached。インメモリデータストアのため非常に高速で、大量のデータを処理したり既存のシステムを効率化することができる。

インメモリデータストアの目的は、データのコピーに超高速で低コストなアクセスを提供することである。キャッシュするデータを決定するためには、データ自体とそのアクセスパターンを把握する必要がある。また、これらのキャッシュされたデータは最新データではないという認識が必要で、使用するアプリケーションの特性上、古いデータでも許容されるのかどうかについて考察が必要である。

Elasticacheは、RedisとMemcachedをサポートしているが、できるだけシンプルな構成が必要であったり、大きなノードを実行する場合は、Memcachedを選択すべきである。

キャッシュできるデータは、S3RDS, DynamoDB streamsなど。

クラスタとレプリケーション

ElastiCacheは、メモリの断片であるノードという単位から構成され、これらを1〜6台まとめたグループをシャードと呼ぶ。クラスタモードを有効化したRedisでは、1〜15のシャードで構成される。無効化されている場合は常に1シャードのみである。

Redisクラスタ

クラスタ構成を有効化する場合には、ノード数を2以上とし、マルチAZ構成とすることが望ましい。クラスタ構成とするとデータは、シャードごとに分散されて保存され、クラスタの一部に異常が発生した場合には、正常なノード(サービス)にマスターが自動で移動する。また、異常が発生したノード(サービス)は再構成される。

Redisレプリケーション

リードレプリカを使用することで、耐障害性が向上するとともに読み込み能力がスケールアウトする。Redisに異常が発生した場合は、DNSが切り替わり、新しいノードにマスターが移動する。

キャッシング戦略

Redisにおけるキャッシュ方法は以下が用意されている。

方法 内容 利点 欠点
遅延書き込み データがキャッシュにない、もしくは古い場合に追加 容量, 障害の影響 遅延, データの古さ
書き込みスルー データがデータベースに書き込まれると常にデータを追加 データが新しい ノード拡張時にデータが存在しない, 不要なキャッシュ
TTLの追加 有効期限を指定し、期限切れはデータがないものとして扱う

AWS SQS(1)Amazon Simple Queue Serviceの概要

Amazon SQSについて

Amazon SQSは、マネージド型のメッセージキューイングサービス。SQSを使用することであらゆる量のソフトウェアコンポーネント間で、メッセージの送信や保存、受信が可能となる。

SQSでは、標準キューと呼ばれる配信順序がベストエフォート型のキューと、FIFOキューと呼ばれる送信順に配信されるキューの2つが用意されている。FIFOキューは、米国東部(バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、および 欧州 (アイルランド) リージョンのみで使用可能。

内容 標準キュー FIFOキュー
イメージ 標準キュー FIFOキュー
特徴 無限のスループット, 1回以上の配信, ベストエフォート 300件/秒, 1回のみ処理, 厳密な順序

キュー内のメッセージ数の上限は、12万件。メッセージ属性は、単一メッセージ内に10個まで。バッチ処理は、10メッセージまで同時に可能である。

AWSサービスとの連携

Amazon SQSは、他のAWSサービスと連携して使用することができる。

  • Amazon SNSでトピックが発行された際に、指定したSQS(標準キューのみ)対してキューメッセージを送信することができる。
  • キュー(標準キューのみ)にメッセージが着信した際に、これをトリガにLambda関数を事項させることができる。

キューの設定

キューを作成する際には、以下の項目を設定する。

設定項目 内容 デフォルト値 最大
可視性タイムアウト 受信したメッセージが他のキューから見えない時間 30秒 12時間
保持期間 メッセージの保持期間 4日 14日
最大メッセージサイズ 最大メッセージサイズ 256KB 256KB
配信遅延 初回配信時の遅延時間 0秒 15分
メッセージ受信待機時間 ロングポーリング時の待機時間。0秒に設定するとショートポーリングとなる。 0秒 20秒
コンテンツに基づく重複排除 (FIFOのみ) 本文のハッシュ値から重複排除IDを自動生成する 無効
デッドレターキュー 最大受信数を超えた場合の処理 無効 1000
サーバ側暗号化 CMKを用いたサーバ側暗号化の設定 無効

ロングポーリングとショートポーリング

ロングポーリングの場合、問い合わせの結果が空であった場合に、指定したメッセージ受信待機時間、SQSが待機してから応答を返す。これによって、空のレスポンス数を削減し、効率的なメッセージ取得が可能となる。

ショートポーリング

ショートポーリングは、問い合わせの結果に関わらず、常に応答を返す。

メッセージの送信

SQSのメッセージには本文に加えて、メッセージ属性を含むことができる。メッセージ属性は、キータイプ(String, Number, Binary)、から成る。

標準キー

1メッセージ単位で、配信遅延時間を設定することができる。

FIFOキー

メッセージグループIDメッセージ重複排除IDが入力必須。メッセージグループIDが同一のメッセージは、順序が保障される。キューの設定で、コンテンツに基づく重複排除を有効化していない場合は、メッセージ重複排除IDも入力する必要がある。

重複排除間隔は、5分

メッセージの受信

可視性タイムアウトの値は、受信ソフトウェアがメッセージを処理する時間を計測して決定する。具体的には、受信ソフトウェアが処理時間よりも長く、かつリトライまで待つ時間が必要以上に長くならない値に設定すべきである。

また、ロングポーリングを設定することで空の応答を減らしたり、バッチ処理によって複数のメッセージを処理することで、SQSの使用コストを削減することができる。

メッセージのエラー処理

デッドレターキューを設定することで、処理できない問題のあるメッセージをキャプチャすることが可能である。なお、デッドレターキューにメッセージが送信されても、元のメッセージのタイムスタンプは変更されないことに留意が必要

利用シーン

SQSは、以下のような用途で使用できる。

用途 内容
ワークキュー 同時に処理できないデータを処理から切り離す
バッファリング システムにスケーラビリティと信頼性を追加
リクエストのオフロード インタラクティブな処理から遅い処理を切り離す
ファンアウト SNSと組み合わせて1つの処理を複数のキューに配信
優先順位 優先順位ごとのキューを用意

AWS Elastic Beanstalk(1)Elastic Beanstalkの概要

Elastic Beanstalkとは

Elastic Beanstalkは、Java、.NET、PHP、Node.js、Python、Ruby、Go などを使用して開発されたプログラムをApache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするためのサービス。インフラストラクチャの準備、運営から、アプリケーションスタック (プラットフォーム) の管理までをElastic Beanstalkが担当するため、ネットワーク設定や保守などの作業が不要

All at Onceローリング追加バッチとローリングイミュータブルブルー/グリーンなどの複数のポリシーからデプロイ方法を選択可能である。

Elastic Beanstalkを使用するにあたっての利用料金は不要で、デプロイしたAWSリソースに対する通常の使用料金のみ課金される。

使用するAWSリソースとその機能について、十分な知識を有する場合は、CloudFormationテンプレートを作成して運用することが望ましい。

Elastic Beanstalkのワークフロー

Elastic Beanstalkは、複数のアプリケーションを作成することが可能で、各アプリケーションは、Application VersionEnvironment(デプロイ済みのアプリケーション)やEnvironment TierEnvironmentの種別)、Environment Configuration(Environmentの設定)を有する。

Application Version

デプロイ可能なコードを指し、S3上でバージョン管理される。

Environment Tier

HTTP リクエストを処理し、ウェブアプリケーションを実行可能なWebサーバ環境と、Amazon SQSキューからタスクを引き出し、バッチ処理などをスケーラブルに実行可能なワーカー環境の2つから選択することが可能である。

Webサーバ環境

Webサーバ環境で構築されるEC2のソフトウェアスタックは、選択したコンテナタイプ(テンプレート)によって異なる。また、ホストマネージャー(HM)と呼ばれるソフトウェアコンポーネントも実行され、アプリケーションのデプロイの実行や、アプリケーションの監視等も行なっている。

Webサーバ環境

ワーカー環境

完了するまでに長い時間がかかる処理は、SQSを用いたワーカー環境で実行することが望ましい。ワーカー環境では、Amazon SQS キューを管理しタスクを実行するSQSデーモンが実行される。また、cron.yamlにタスクを記述することで、タスクの定期実行を行うことも可能である。

ワーカー環境

設計上の注意事項

スケーラビリティを確保する方法として、スケールアップ(垂直スケーリング)とスケールアウト(水平スケーリング)が存在が、スケールアップは過剰なリソースの準備となるなど問題点が存在するため、Elastic Beanstalkアプリケーションは、必要に応じてスケールアウトできる耐障害性に優れた疎結合コンポーネントを使用して、できるだけステートレスにする必要がある。

また、耐障害性を有するように、必ず故障から自動回復できるように設計、実装、およびデプロイする必要がある。

アプリケーションの管理

ソースコードをアップロードするたびに、新たなバージョンラベルを付与し、アプリケーションバージョンを作成する。古いアプリケーションバージョンは削除することも可能で、削除してもデプロイ済みのEnvironmentには影響を与えない

アプリケーションバージョンライフサイクルポリシーを設定することで、過去のバージョンを自動的に削除することが可能である。保有するバージョンの数、もしくは期間を設定でき、これを超えるとサービスが自動でアプリケーションバージョンを削除する。

アプリケーションは、ソースバンドルと呼ばれる処理プログラムを含む必要があり、ソースバンドルは、単一のZIPファイルまたはWARファイルで構成される必要がある。AWS Toolkit for Eclipse等を使用して開発を行なっている場合は、ツールが正しく構造化した上でZIP化してくれる。

Environmentの管理

1つのアプリケーションは、開発環境、統合環境、本番環境など複数のEnvironmentをデプロイすることができる。新たなEnvironmentを作成する場合は、

  • プラットフォーム
  • Application Version もしくは 新たなソースバンドル
  • Environment Tier(ウェブ環境/ワーカー環境)

等を指定する。作成したEnvironmentを終了すると、デプロイしたリソースの全てが削除される。

デプロイ

Environmentをデプロイする際には、複数のデプロイ方法の中から1つを選択することが可能である。

方法 デプロイメントポリシー 内容 制約 時間 ダウンタイム DNS変更
All at Once All at Once 現行のインスタンス全てに新たなコードを適用する
Rolling Rolling 現行のインスタンスに順に新たなコードを適用する 単一インスタンス環境では選択できない やや速
Rolling with additional batch Rolling with additional batch 新たなインスタンスと現行のインスタンスの一部に新たなコードを適用する 単一インスタンス環境では選択できない
Immutable Immutable 新たなインスタンスに新たなコードを適用する
Blue/Green Rolling with additional batch もしくは Immutable 新たなインスタンス(と現行のインスタンスの一部)に新たなコードを適用する 単一インスタンス環境では選択できない URL Swap もしくは DNS切り替え

Rollingを用いてデプロイする場合は、更新するバッチサイズを指定する。また、Route53の加重ラウンドロビンを利用することで、新バージョンを徐々に適用していくことも可能である。

プラットフォームの更新

アプリケーションを実行しているプラットフォームの更新を定期的に、もしくは手動で行うことが可能である。また、マイナーアップデートを含めるのか、パッチの適用だけなのかについても選択することができる。

AWS API Gateway(1)API Gatewayの概要

API Gatewayとは

API Gatewayは、完全マネージドのAPI作成サービス。受信したAPIコールと送出したデータ量に対して課金される。スロットリングによるトラフィック管理ができるため、DDoSやトラフィックの激増にも対応することが可能であり、リミットを超えたリクエストにはHTTPステータス 429が返却される。また、レスポンスはキャッシュ可能であり、レイテンシやトラフィック等を低減することができる。

API Gatewayは、IAMやCognitoを用いたアクセス認証署名付きAPIコールなどを使用することができるために柔軟にセキュリティ管理ができる。また、CloudWatchやCloudWatch Logsを用いた監視が可能で効率的なデバッグとモニタリングを実現している。

![API Gateway]https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/images/BackplaneArch.png

エンドポイント

API Gatewayは、特定のリージョンにデプロイされる。エンドポイントは以下の3種類がサポートされている。エンドポイントは、HTTPSのみサポートされている。

種類 内容
エッジ最適化 CloudFrontネットワークにデプロイ
リージョン リージョンにデプロイ。EC2 インスタンスまたは API と同じリージョン内のサービスから送られる場合に使用すると良い。
プライベート VPCからのみアクセス可能

リソースとメソッド

APIは階層構造となっており、リソースやメソッドをネストすることも可能。指定可能なメソッドは以下の通り。

種類 実行内容
POST 子リリースの作成
PUT 既存リソースの更新
DELETE リソースの削除
PATCH リソースの更新
HEAD テストシナリオに使用
OPTIONS 通信オプションに関する情報を取得する度に使用できる

CROSを有効にするためには、OPTIONSメソッドのプリフライトリクエストに対してAPIが応答することが必要であり、このリクエストに対して、HTTPステータス 200Access-Control-Allow-Method, Access-Control-Allow-Headers, Access-Control-Max-Ageヘッダを含んだレスポンスを返す。これらの挙動には、統合リクエスト/レスポンスのMockタイプを使用する。

リクエストに対して、 URLクエリ文字列パラメータHTTPヘッダHTTPボディを検証し、必須の項目が含まれているかやキャッシュを行うかなどを指定することができる。HTTPボディがapplication/json形式である場合は、JSON Schemaを用いてJSON形式を指定することもできる。

統合リクエスト/レスポンスとマッピングテンプレート

API Gatewayとバックエンドとを接続する内部インタフェース。マッピングテンプレートを用いることで、フロントエンド(API Gateway)とバックエンドのデータ形式を変換することができる。

  • Lambda関数の呼び出し
  • 他のAWSサービスの呼び出し
  • HTTPウェブサイトのアクセス

の3つのバックエンドへのアクセスに対応している。Lambdaプロキシ統合を用いることで、API GatewayとLambdaがより協力に結合され、リクエストヘッダやパス変数などがLambdaに渡される。また、HTTPプロキシとして使用することも可能である。

デプロイ

APIを利用可能とするためには、APIのリソースおよびメソッドのスナップショットであるAPIのデプロイを実施する必要がある。APIをバージョン管理できるために、新しいバージョンを簡単にテストしリリースすることが可能である。

1アカウント1リージョンあたりのAPIの上限は、10000RPSである。これ以上のアクセス負荷にも耐えうる値とする場合は上限緩和申請が必要となる。

エラーコード

API Gateway の代表的なレスポンスコードは以下の通り。

エラーコード レスポンスタイプ 内容
400 BAD_REQUEST_PARAMETERS リクエストパラメータの不整合
400 BAD_REQUEST_BODY リクエストボディの不整合
401 UNAUTHORIZED 認証の失敗
403 EXPIRED_TOKEN トークンの期限切れ
403 ACCESS_DENIED 認証の失敗
403 INVALID_API_KEY APIキーの不整合
403 INVALID_SIGNATURE 署名の不整合
403 MISSING_AUTHENTICATION_TOKEN トークンが見つからない
403 WAF_FILTERED WAFによるブロック
404 RESOURCE_NOT_FOUND リクエスト先が存在しない
413 REQUEST_TOO_LARGE リクエストが大きすぎる
415 UNSUPPORTED_MEDIA_TYPE メディアタイプの相違
429 QUOTA_EXCEEDED クオータの超過
429 THROTTLED スロットルの発生
500 API_CONFIGURATION_ERROR API 設定が無効
500 AUTHORIZER_CONFIGURATION_ERROR オーソライザーへの接続が失敗
500 AUTHORIZER_FAILURE オーソライザーの認証が失敗
504 INTEGRATION_FAILURE 統合に失敗
504 INTEGRATION_TIMEOUT 統合のタイムアウト