AWS認定ソリューションアーキテクト-プロフェッショナルに合格するためにやったことまとめ

8月にアソシエイトに合格し、じゃあプロフェッショナルも取るかと思ったものの、日本語のソースだとプロフェッショナルに受かるためにどんなことをしたらいいかの情報が少なかったので、自分がやったことのまとめ。
※2017年10月時点での情報だと思ってください

よく問われるサービス

  • コンピューティング

    • EC2,Elastic Beanstalk
  • ストレージ
    • S3, EFS, Glacier, Storage Gateway
  • データベース
    • RDS, DynamoDB, ElastiCache, Amazon Redshift
  • ネットワーク&コンテンツ配信
    • VPC, CloudFront, Direct Connect, Route53
  • 管理者ツール
    • CloudWatch, CloudFormation, CloudTrail, OpsWorks
  • セキュリティ、アイデンティティ、コンプライアンス
    • IAM, Certificate Manager, Directory Service, CloudHSM
  • 分析
    • EMR, CloudSearch, Kinesis, Data Pipeline
  • モバイルサービス
    • Cognito
  • アプリケーションサービス
    • SWF, Elastic Transcoder
  • メッセージング
    • Simple Queue Service, Simple Notification Service, Simple Email Service

最低限読んでおく資料

まずはここを見て各サービスの概要を把握する。

概要をつかんだらこれを読んで細かいハマりポイントを理解する。

試験ガイドにあるようにホワイトペーパーも出題範囲。英語多め。各種ベストプラクティスくらいは読んでおく。

いわゆるCDP。典型的な設計パターンがまとめられている。

主要なサービスのドキュメントは一通り読む。

気を付けるポイント

  • 各種IDフェデレーション

AssumeRole, AssumeRoleWithWebIdentity, AssumeRoleWithSAML, GetFederationToken, GetSessionTokenがそれぞれどのようなケースで使うのが適当かを押さえる。

  • EC2のインスタンスタイプ
    「T2はバースト可能」「R4はメモリ最適化」といった用途を押さえる。回答の選択肢の中にさらっと出たりする。

  • VPN, DirectConnect, VPC peeringの特徴やユースケース
    オンプレミスとのハイブリッド環境でよく問われる。冗長化する(SPOFをなくす)方法も押さえておく。

  • EBSのIOPS
    最大値および最大値を超えるIOPSが必要な場合の設計方法を押さえる。

  • VPCにおいて予約されているIP

  • 各種サービスがどのレベルで提供されるのか(AZ、リージョン、グローバル)
    単一リージョンから複数リージョンへの移行や、グローバルレベルでの可用性・耐障害性に関する問題がよく出る。

  • CloudFormation, Elastic Beanstalk, OpsWorks
    それぞれの特徴や違い、作成(デプロイ)・変更・削除・中止方法を押さえる。

  • キャッシュエンジンの違い
    ElastiCacheにおけるmemcachedおよびRedisそれぞれの特徴を理解する。

  • 一括請求 (コンソリデーティッドビリング)
    請求を統合する方法および共有されるもの/されないものを押さえる。

有料学習サービス

  • Linux Academy

    • AWS SAプロ用のコースがあって、動画とハンズオンで学習できる。
    • 動画は英語のみで字幕もないが、活用資料集で概要を把握していれば十分理解できるレベル。
    • 登録後7日間は無料。その後は月額料金($29)が発生。無料期間だけで終わることもできる(ただし、ハンズオンは利用不可)。
    • 登録時にクレジットカードかpaypalの登録必須。
    • 独自の模擬試験もついていて、個人的にかなり良かった(無料期間だけで終わったけど…)

他にも海外のブログだとQwikLABSとかa Cloud Guruが評判が良かった(僕は使ってないです)

模擬試験について

公式の模擬試験は一度は受けた方がいい。問題形式や時間配分を体感できるのは重要。
アソシエイトに受かった時に模擬試験を無料で受験できるバウチャーがもらえるので、それを使うのが吉。
ただし、僕が受けた時は日本語がひどくて、日本語として何を言っているか分からない問題が多々あった(本番はまともだった)。もし模擬試験を受けてその日本語に恐怖を覚えても、本番ではそこまで怯える必要はないと思う。

本試験予約時の注意

  • 支払ページの請求先住所は英語で入力。全部入りきらなくても気にしない。

赤字で「英語で入力しろ」と注意書きもあるけど、英語で入力するとフォームの文字数制限で書ききれない。これじゃAWS困るだろと思って日本語で入力するとtemporary errorになる。このtemporary errorが日本語入力のせいだと気付かず、LiveChatで聞いたりして1週間以上待った…。
ちなみに英語で住所を入力して全部入りきらなくても郵便番号欄もあるので、中の人が補完してくれるとのこと。

  • 試験会場の住所が全部表示されない時は英語表示に切り替える

なぜか日本語表示だと郵便番号レベルの住所しか表示されず、とても不安な気持ちになるが、英語表示に切り替えるとちゃんと表示される。謎。

続きを読む

AWS Route53とWAFのGeolocation機能を検証

WAFに地域を制限する新機能がでました。geolocationについて検証しました。ついでにroute53のgeolocationも検証しました。

1.route53のgeolocation検証

検証

アクセスをUS(アメリカ)だけに限定して、あらゆる方法で日本からのアクセスどこまで防いでくれるか検証

検証環境

・route53にて[test.example.com]と登録後geolocaionをUSに設定する。(ドメインは例です。)
・EC2静的webホストのインスタンスを作成
・EC2にEIPを付与
・Applicattion load blanceでインスタンスを紐付け

ALBのヘルスチェックを通して検証

結果(左アクセス方法と右結果)

ドメインアクセス————————–拒否(ドメインが見つかりませんでした。)
EC2のパブリックドメイン—————–アクセスできた
EC2のEIP————————————アクセスできた
ALBのドメイン—————————–アクセスできた
ALBのネットワークインターフェース—-アクセスできた

感想

当たり前ですがRoute53を通らない方法でやると通る。

2.WAFのGeoMatch検証

検証

US以外のアクセスすべて拒否設定で日本からアクセス検証
(上記のroute53で設定した。geolocationはもとに戻しています。)

検証環境

・EC2静的webホストのインスタンスを作成
・EC2にEIPを付与
・Applicattion load blanceでインスタンスを紐付け
・WAFGeoMatchをUS(アメリカ)以外全部拒否設定

結果(左アクセス方法と右結果)

ドメインアクセス————————–拒否(HTTPStatus:403)
EC2のパブリックドメイン—————–アクセスできた
EC2のEIP————————————アクセスできた
ALBのドメイン—————————–拒否(HTTPStatus:403)
ALBのネットワークインターフェース—-拒否(HTTPStatus:403)

感想

通常のアクセスする順番が「クライアント⇒route53⇒ALB(WAFアタッチ)⇒EC2」なので、WAFで拒否してくれるが、EC2に直接アクセスするとALBは通らないのでアクセス可能になってしまう。
本来であれば、WEBインスタンスを作るときにEC2に直接EIPとパブリックドメインはつけることがないので問題ないと思います。
地域のアクセス制限するのならWAFのほうが良い。

続きを読む

ALBの概観図

AWSのALBの設定をするときに概念が混乱し始めて来てしまったので、全体の概念図をまとめようとおもいました。

今後、始めてALBを設定する人の参考になれば幸いです。

全体図

image.png

各設定に関してはAWSのドキュメントや様々な記事が参考になるので詳しい設定方法は省略します。

  1. Route53で、ドメイン名を、ALIASでALBと紐付ける。
  2. ALBのListenerのTargetGroupを設定します。
  3. TargetGroupに当該のEC2インスタンスを紐付けます。

セキュリティグループをつける

image.png

ALBと各EC2にそれぞれセキュリティグループをつけます。
ALB -> インバウンド:全て アウトバウンド:EC2のセキュリティグループ
EC2 -> インバウンド:ALBのセキュリティグループ インバウンド: 全て
にそれぞれ設定します

続きを読む

Fessでドキュメント検索環境を構築した話

やったこと

  • プロジェクトの新規ドキュメントはGitBookで作成しGitで管理
  • 既存のドキュメント(Word、Excel、PDF、テキスト程度のメモ書きなど)はGitに登録
  • GitbookのBuildはcommitが行われる度にJenkinsで自動的に実行
  • Gitに登録されたドキュメントはFessサーバ内に日に1回pullする
  • ドキュメント群をFessで毎日クローリングしインデックス作成
  • 上記はすべてAWSで構築

全体構成

ざっくりとしたものですがこんな感じです。

キャプチャ.PNG

GitBook構築

GitBookインストール

https://www.gitbook.com/

ざっくりと言うと、マークダウン形式でドキュメントを作成し、ビルドすることによって
htmlやPDFを作成し、公開したりプロジェクト内に展開できるツールです。
今回はAWSのEC2上に環境を作成しましたが、GitBook.com上でも行えますので用途に応じて変えたらよいと思います。

インストールに関しては、検索して出てきた先達の方々のを参考にして行いましたので、こちらでは割愛します。

プロジェクトメンバーに公開する

公開に用いたWebサーバはapacheの2.2系を用いました。
GitBookはプロジェクト内のチーム毎に作成しており、都度増減します。
その度にapacheのconfを書き換えるのは面倒なので、VertualDocumentRootを利用しました。
AWSのRoute53で社内用プライベートドメインを割り当て、そのサブドメイン毎にGitBookとJenkinsのジョブを作成します。
workspace以下をドキュメントルートとすることで定義の書き換えの必要性をなくしています。

<VirtualHost *:80>
  ServerName [プライベートドメイン]
  ServerAlias *.[プライベートドメイン]
  VirtualDocumentRoot /var/lib/jenkins/workspace/%1/_book
  <Directory "/var/lib/jenkins/workspace/%1/_book">
    Options Indexes FollowSymLinks
    AllowOverride All
  </Directory>
</VirtualHost>

Jenkinsとの連携

GitBookとJenkins

Jenkinsの Gitlab Plugin を用いて、GitlabのCommitとビルドを連動するようにしました。

キャプチャ.PNG

既存ドキュメントとJenkins

Jenkins内に最新のドキュメントを保持するのが目的です。
理由は後述するFessで利用するためです。

Fess構築

http://fess.codelibs.org/ja/

OSSの全文検索エンジンです。
公式にも書いてありますが。ElasticSearchを利用しており
WebAPIも対応しているため、WebベースでのGoogleライクな検索もできれば
APICallによるシステム内の検索部品としての役割も持つことができます。

現在はパッケージインストールに対応しているみたいなので、導入は比較的容易だと思います。
私の時(1年半ほど前)はなかった気がする…。

GitBookをクローリング

GitBookの公開URLに対してクローリングさせる設定を行います。
プロジェクト内で使っている名前などは[]書きで置き換えています。
キャプチャ.PNG

既存ドキュメントのファイルクロール

FessにGitで管理しているドキュメントのインデックスを作成させます。
検索対象は、Jenkinsでリポジトリからpullしたドキュメントが格納されているフォルダです。

クロール対象とするパス項目で、検索で見つかるドキュメントをある程度制御しています。
全ファイル対象だと、不要なゴミファイルまで引っかかってしまったためです。

キャプチャ.PNG

構築して思ったこと

  • GitBookを使う場合はマークダウンに慣れていれば楽
  • Fessでの検索はExcelなどの図形内テキストまで拾ってくれるので細かい検索ができる
  • ドキュメントのアップデートが知りやすくなった
  • OSSだけでもそれなりのものが構築できた
  • Jenkinsおじさんは働き者

続きを読む

AWSの用語と解説

AWS(Amazon Web Services)General_AWScloud.png

インフラ系のクラウドサービスを提供しているAWSは2006年3月から始まり、現在10周年。
アメリカでは政府機関が使っているほど高いセキュリティ

サービスや機能は800個以上あり、もはや中の人も何がいつリリースされたかわからないらしい

Region(リージョン)

AWSは世界中のデータセンターのサーバーで実行されており、サービスを開始する時はリージョンを選択する
リージョンは以下の通り

リージョン
米国東部(バージニア北部) us-east-1
米国西部(オレゴン) us-west-2
米国西部(北カリフォルニア) us-west-1
欧州(アイルランド) eu-west-1
欧州(フランクフルト) eu-central-1
アジアパシフィック (シンガポール) ap-southeast-1
アジアパシフィック(東京) ap-northeast-1
アジアパシフィック (ソウル) ap-northeast-2
アジアパシフィック(シドニー) ap-southeast-2
南米 (サンパウロ) sa-east-1
中国(北京) cn-north-1

アジアパシフィックを選んでおけば問題ないが、特定のリージョンにしかないマイナーなサービスがあったりするので注意が必要

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

リージョン内のデータセンターのことで、
東京リージョンだと ap-northeast-1a ap-northeast-1b ap-northeast-1c のAZがある

EC2(Elastic Compute Cloud) Compute_AmazonEC2.png

仮想サーバ

ブラウザ上で何回かクリックするだけで、簡単にインスタンスが立ち上がる
利用料金はインスタンスタイプや性能にもよるが、最低スペックで 744円/月 くらい?

RDS(Relational Database Service) Database_AmazonRDS.png

リレーショナルデータベース

Amazon Aurora  Oracle  Microsoft SQL Server  PostgreSQL  MySQL  MariaDB
からデータベースエンジンを選択可能

中でも MySQL5.6互換がある Amazon Auroraは1分あたり600万回のインサート、3000万件のセレクトが可能らしい。
下記のサイトによれば、DB性能向上が期待できそう?
http://dev.classmethod.jp/cloud/aws/wordpressdb-migrate-aurora/

Redshift  Database_AmazonRedshift.png

データウェアハウス

2TBから最大1.6PBまでスケール可能でログなどのビッグデータを保存するのによく使用される
カラムナー(列指向)と呼ばれるデータ格納方式が特徴

Redshift は、PostgreSQL 8.0.2 に基づいている。
なので、PostgreSQL 9系で追加されたクエリが使えなかったりする。

ElastiCache  Database_AmazonElasticCache.png

KVSのキャッシュサービス

Memcached・Redis から選べる
Elastic Cacheではなく ElastiCache(エラスティキャッシュ) という名前なので注意が必要

S3(Simple Storage Service) Storage_AmazonS3_bucket.png

オンラインストレージサービス

bucket(フォルダ)
object(ファイル)
という名称がある

1B ~ 5TBまでのオブジェクトを書き込み・読み込み・削除が可能
バケットに容量制限はない

・SLAは99.99%
・静的webサイトのホスティングが可能

CloudFront NetworkingContentDelivery_AmazonCloudFront.png

コンテンツデリバリネットワーク(CDN)

CDNはAkamaiなどがあるが、それに比べると割高

VPC(Virtual Private Cloud) General_virtualprivatecloud.png

仮想プライベートクラウド

Amazon VPCは、AWS上に利用者が占有可能な仮想プライベートネットワークを構築するためのサービス。
このVPCの内部にIPサブネットを作成し、その中に仮想サーバーの「EC2」やデータベースサーバーの「RDS」といったAWSのリソースを配置する。

・ユーザ側で使いたいIP空間(VPC) を作成
・VPCにユーザがサブネットを切ることができる
・サブネット単位で アクセスリストが設定できる

Route53 NetworkingContentDelivery_AmazonRoute53.png

DNSサーバ

DNSは通常マスターとスレーブ構成にすることが多く、2台で構成する場合が多いが
Route53では、4つのネームサーバーで構成され、全世界にDNSサーバーを設置しているので高可用性である
米国:20   欧州:16  アジア:12  オーストラリア:2   南米:2

・SLA100% (ほんとに?)
・DNSラウンドロビンでの負荷分散が可能
料金はかなり安い。

ホストゾーン
0.50 USD(ホストゾーンごと)/月 - 最初の25のホストゾーン
0.10 USD(ホストゾーンごと)/月 - それ以上のホストゾーン

標準的クエリ
0.400 USD(100 万クエリごと) - 最初の 10 億クエリ/月
0.200 USD(100 万クエリごと) - 10 億クエリ以上/月

1つのホストゾーンで、10億クエリ行かなければ、月1ドルかからない。

IAM(Identity and Access Management) SecurityIdentityCompliance_IAM.png

ユーザーの権限を管理できるサービス

ポリシーと呼ばれる権限をユーザーにアタッチすることで、該当ユーザーの操作できる範囲を限ることができる

ポリシーは自由に設定可能で、管理者が細かく設定可能で
例えば、とある管理者が s3-readonly-userを作成し S3の閲覧だけを許可するポリシーを作成してアタッチ。など

随時追加中…

続きを読む

CloudFront に SSL 証明書を導入する際のポイントまとめ

CloudFront に SSL を入れる際に気をつける項目のまとめです。

2017年9月時点では、特に S3 との連携で大きな制約があり、将来的には改善されていくのではと思います。現在の状況を確認してください。

SNI か専用 IP か

まず、ブラウザと CloudFront 間の通信で、SNI (Server Name Indication) が使えるかどうか検討します。

ガラケーやWindowsXP の IE は SNI に対応していません。これらの古い環境でサイトが見えなくても構わないかどうかを確認します。

SNI 非対応のブラウザに対応するには、専用 IP を使う必要があります。専用 IP は $600/月かかります。

専用 IP 独自 SSL の料金体系はシンプルです。SSL 証明書ごとの専用 IP アドレスに伴う追加コストのため、CloudFront ディストリビューションに関連付けられた各独自 SSL 証明書ごとに、毎月 600 USD をお支払いいただきます。

SNI は無料です。

SNI 独自 SSL 証明書管理には、前払い料金や最低月額料金は不要です。お客様にお支払いいただくのは、Amazon CloudFront のデータ転送と HTTPS リクエストに対する通常料金のみです。

証明書の取得について

どのドメインでどんな証明書が必要か、証明書は有料か無料か、を確認します。

証明書の取得方法には、以下の選択肢があります。

  1. 代理店などから購入する (有料)
  2. ACM (AWS Certificate Manager) を使う (無料、ただし EC2 にはインストール不可)
  3. Let’s Encrypt を使う (無料、ただし Amazon Linux 未対応)
  4. etc.

CloudFront – オリジン間を HTTPS にする

通常は、ビューア – CloudFront 間だけでなく、 CloudFront – オリジン間も通信を暗号化します。(表向き暗号化している風を装って、裏を平文で流して良いのかは微妙な問題です…)

CloudFront とオリジンの両方で、証明書が必要になる可能性があります。

オリジンが EC2 の場合、 ELB を入れるか検討する

ACM で取得した証明書を EC2 にインストールすることはできません。

https://aws.amazon.com/jp/certificate-manager/faqs/

Q: ACM により提供された証明書を使用できるのは、AWS のどのサービスですか?

ACM は AWS の以下のサービスと連携できます。
• Elastic Load Balancing – Elastic Load Balancing のドキュメントを参照してください。
• Amazon CloudFront – CloudFront のドキュメントを参照してください。
• Amazon API Gateway – API Gateway のドキュメントを参照してください。
• AWS Elastic Beanstalk – AWS Elastic Beanstalk のドキュメントを参照してください。

https://aws.amazon.com/jp/certificate-manager/faqs/

Q: Amazon EC2 インスタンスや自分のサーバーに証明書を使用できますか?

いいえ。現在のところ、ACM により提供される証明書は、AWS の特定のサービスのみで使用できます。

EC2 で ACM を使いたい場合は、CloudFront – ELB – EC2 の構成にします。証明書が無料になる代わりに、ELB の費用が発生します。

S3 に証明書を入れる必要はない

  • Amazon S3 は SSL/TLS 証明書を提供するため、その必要はありません。

この日本語訳はいまいち何を言っているのかわかりませんが、、

  • Amazon S3 provides the SSL/TLS certificate, so you don’t have to.

「S3 が証明書を提供するので、あなたが(提供する)必要はない」という意味です。

今のところ、S3 に独自の証明書を入れる手段はありません。オリジンに S3 の CNAME を指定することもできません。

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html

以下の形式を使用してバケットを指定しないでください。

  • Amazon S3 のパススタイル (s3.amazonaws.com/bucket-name)
  • Amazon S3 の CNAME (ある場合)

CloudFront – S3 間の HTTPS には大きな制約がある

S3 をウェブサイトエンドポイントとしてオリジンに設定すると、HTTPS が使えなくなります。

Amazon S3 バケットがウェブサイトエンドポイントとして構成されている場合、オリジンとの通信に HTTPS を使用するように CloudFront を構成することはできません。Amazon S3 はその構成で HTTPS 接続をサポートしていないためです。

ウェブサイトエンドポイントは、

http://example-bucket.s3-website-ap-northeast-1.amazonaws.com/

のような URL での配信方法です。「静的ウェブサイトホスティング」の設定です。この URL をオリジンに設定すると、CloudFront – S3 間で HTTPS が使えません。

ウェブサイトエンドポイントは、以下の機能で必要です。

  • /foo/bar//foo/bar/index.html を返す
  • 独自のエラー画面を表示する
  • リクエストを全てリダイレクトする (例えば、www なしドメインを www ありにリダイレクトする)

ウェブサイトエンドポイントを使わず、S3オリジンで設定すると、サイトのトップ / (Default Root Object) 以外、index.html が見えるようにはなりません。

CloudFrontではDefault Root Objectという設定項目でIndex Documentを指定することができますが、これはRootへのアクセス時(例:http://example.com/) に対してのみ有効であり、サブディレクトリ(例:http://example.com/foo/) に対しては有効になりません。そのため、階層構造のあるWEBサイトをホストする際には不向きだと思われます。

ウェブサイトエンドポイントを使う場合は、裏が暗号化されていなくてもいいのか、バレなければいいのか、を検討しなければならなくなります。。ちなみに、オリジンが S3 であることは Server レスポンスヘッダで判別できます。S3 がウェブサイトエンドポイントかどうかは、/foo/bar/ の挙動で判別できます。

また、ウェブサイトエンドポイントにすると、Origin Access Identity を使うことができなくなります。バケット名を推測して、S3 に直接アクセスされる可能性があります。

ワイルドカード証明書の取得を検討する

CloudFront にもオリジンにも、ワイルドカード証明書が使えます。例えば、以下のような組み合わせが考えられます。

  • CloudFront *.example.com → Origin *.example.com

    • 1つのワイルドカード証明書を使う
  • CloudFront www.example.com → Origin www.example.com
    • 1つの非ワイルドカードの証明書を使う
    • CloudFront から Host ヘッダを転送する場合のみ、オリジンの証明書で Host ヘッダのドメイン名が使える
  • CloudFront www.example.com → Origin *.example.com
    • 表は高い非ワイルドカード証明書を使い、裏は安いワイルドカード証明書で済ませる
  • CloudFront www.example.com → Origin origin.example.com
    • 表と裏と、別々に非ワイルドカード証明書を購入する
    • または、証明書に別名 (SAN) を設定する
  • CloudFront www.example.com → Origin origin.example.jp
    • オリジンは .example.com でなくてもよい。DNS の自由が効かない場合、裏は Route53 で独自のドメインを取得すると便利

詳細は以下のドキュメントを参照してください。

カスタムオリジンを使用する場合、オリジンの SSL/TLS 証明書の共通名フィールドにドメイン名が含まれ、さらにサブジェクト代替名フィールドにもドメイン名がいくつか含まれることがあります。 (CloudFront は証明書ドメイン名にワイルドカード文字を使用できます)。

証明書のドメイン名のうち 1 つは、オリジンドメイン名に指定したドメイン名と一致する必要があります。ドメイン名が一致しない場合、CloudFront は、ビューワーに HTTP ステータスコード 502 (Bad Gateway) を返します。

内部の証明書を安くあげる

エンドユーザの目に触れないオリジン用の証明書にまでコストをかける必要があるかどうかを検討します。安価な証明書でも十分かもしれません。

オリジンが ELB なら ACM が使えます。

DNS を操作する権限があるか確認する

表側の DNS を操作する権限がない場合、オリジンに Route53 で取得した独自ドメインを設定すると、自由度が上がります。

オリジンに独自のドメインを使う場合は、その証明書が必要です。

リリース前の確認方法を検討する

リリース前に CloudFront に別のドメインを割り当てて確認する場合は、ワイルドカード証明書があったほうが便利です。

例えば https://staging.example.com/ のような URL を CloudFront に設定します。

Naked ドメインを使うか確認する

https://example.com/ のような Naked ドメイン (Zone Apex) を使うかどうか確認します。

Route53 を使わずに、Naked ドメインを CloudFront や ELB や S3 に割り当てることはできません。CloudFront を通さず、例えば EC2 で直接リクエストを受ける必要が出てきます。

Naked ドメインへのリクエストを EC2 で受ける場合

Naked ドメインへのリクエストを EC2 で直接受ける場合は、ACM が使えません。ACM で取得した証明書は EC2 にインストールできないからです。

証明書の購入が必要になる可能性があります。

Naked ドメインの DNS に Route53 を使っている場合

Route53 でエイリアスを使うと、CloudFront に Naked ドメイン (Zone Apex) を設定できます。

この場合は、Naked ドメインの証明書取得に ACM が使えます。

ワイルドカード証明書を使う場合、ワイルドカードに Naked ドメインは含まれないので、*.example.com に別名で example.com を設定します。

既存の証明書がある場合は SAN を確認する


既に証明書があって、足りない証明書を購入する場合。

既存の証明書の別名 (SAN) が何になっているのかを確認します。特に Naked ドメインなど、必要なドメインが SAN に設定されているかもしれません。

証明書をインポートするリージョンに注意する

CloudFront の証明書は、バージニア北部リージョンに入れる必要があります。

ACM で証明書を取得する場合にも、バージニア北部リージョンを選ぶ必要があります。

ビューワーと CloudFront との間で HTTPS を必須にするには、証明書をリクエストまたはインポートする前に AWS リージョンを 米国東部(バージニア北部) に変更する必要があります。

CloudFront とオリジンとの間で HTTPS を必須にする場合、オリジンとして ELB ロードバランサーを使用しているなら、任意のリージョンで証明書をリクエストまたはインポートできます。

例えば、オリジンが東京の ELB だとしたら、東京とバージニア北部リージョンの両方の ACM で証明書を取得 (またはインポート) します。

ACM の本人確認について

ACM で証明書を取得する場合は、本人確認 (取得意思の確認) メールが、証明書のドメイン宛てに送信されます。

Whois 情報の更新状態をチェックする

本人確認メールは、公開されている Whois の連絡先アドレスにも送信されます。

Whois に正しいアドレスが公開されている場合は、そのアドレスでメールを受け取るのが簡単です。

SES で ACM の認証を通す

ドキュメントの通りにやれば、ACM の確認メールを SES で受信するのは、さほど難しくありません。

SES の受信設定を行い、DNS に MX レコードを設定、受信したメールを SNS トピックで受け取るようにして、そのトピックに任意のメールアドレスをサブスクライブします。

ルールセットがアクティブになっているかどうかに注意する

SES のメール受信設定には、「ルールセット」というバージョン管理の仕組みがあります。

現行のルールセットをコピーし、編集し、アクティブなルールセットを入れ替える、という手順で設定を変更します。Inactive Rule Sets に新しいルールセットを足しても何も起こりません。

続きを読む

AWSでServerlessの環境をCIするための選択肢を調べたメモ

利用するサービスはAWSに限定するとした場合に開発・テスト・デプロイを継続するための選択肢をいくつか調べてみました。

開発したいものは、「API Gateway – Lambda – DynamoDB」で構成されるWebサービスとします。

正直なところ、対象像を少し絞らないと選択肢が多すぎて好みの問題になりそうなので・・・

注意

調査用のメモです。

実際に全ての選択肢で開発をしてみたわけではなく、入門記事やドキュメントを少しみた程度で判断しています。

そのため正確性に欠ける内容となっている可能性が高いことをご了承ください。

共通点

開発ツールで対応していない部分についてのデプロイについては、AWS CLIで対応していくことになるでしょう。

LocalStack

モックサービスの対応数にまず驚いた。

https://github.com/localstack/localstack

LocalStack はローカルでAWSのサービスのモックを動かしてしまうというツールです。
DockerコンテナでAWS各種サービスを一気に立ち上げることができるので、ローカル環境で開発を完結させることが出来ます。

これ自体にはAWSを管理する機能はなく、Lambdaをローカル環境で開発してテストするときに、ローカルで同時にAPI Gateway + DynamoDBを動かしたいという場合に必要となりそうです。
DynamoDB自身はAmazonからDynamoDB Localが提供されているので、どちらを使うかは検証が必要でしょう。

起動コマンドも簡単で、一発で全て立ち上げることが出来ます。

docker-compose up

macの場合は、$TMPDIRにシンボリックリンクがある場合、少しコマンドを変える必要があるようです。

TMPDIR=/private$TMPDIR docker-compose up

DynamoDB Local

ローカル開発用のDynamoDB。
ほとんどのLambda開発ツールがAPI Gatewayもサポートしていることから、DynamoDBを接続するローカル環境ではLocalStackよりはこちらを使用することになるのではないかと。公式提供でもあるし。

ダウンロードとインストールガイドはこちら

aws-sam-local

SAM は Serverless Application Modelのことで、aws-sam-localはAmazon公式がサポートしているローカル開発環境です。今はまだbetaですが、近いうちに良くなりそうです。

https://github.com/awslabs/aws-sam-local

AWS Blogで利用例が紹介されていて、DynamoDB Localを使う場合についても少し触れられています。
https://aws.amazon.com/jp/blogs/news/new-aws-sam-local-beta-build-and-test-serverless-applications-locally/

作成したLambda FunctionをローカルDockerコンテナで実行したり、現時点ではPythonとNode.jsはデバッグ出来るようです。(自分で試したところ、上手くいかなかった)

また、Lambda関数を単純に実行するだけではなく、ローカルのAPI Gatewayを通して実行を確認できます。

PostManで簡単にAPIの動作検証が行えたり、実際のHTTPアクセスの形でLambda関数の検証がローカルで行えます。
また、実行時間やメモリ消費量が表示されるため、AWSにデプロイする前に関数の効率化が出来ます。

Serverless Framework

現状で一番正解に近いと思います。

https://github.com/serverless/serverless

こちらのQitta記事こっちのQiita記事が参考になりそうです。
DynamoDB Localと連携するためのプラグインが存在し、serverless.ymlファイルにAWS上での構成を記載していき、そのままAWSにデプロイ出来るようです。

Apex

Go言語でLambdaが書ける!!!

純粋にLambdaの開発だけで見ればとても良さそうです。
ただし、ローカル実行はサポートしておらず、AWSリソースの操作もLambdaに限定されています。
その辺りは、Terraformで補う考えのようです。

公式

https://github.com/apex/apex

chalice

Python用のマイクロサービスフレームワークです。

https://github.com/aws/chalice

次の様なコードで、APIを定義できます。

chalice
@app.route('/resource/{value}', methods=['PUT'])
def put_test(value):
    return {"value": value}

デプロイでAPI Gateway, Lambdaに反映されるため、コードの見通しが良くなりそうです。
IAM Rolesなどは自動生成される様なので、とにかく簡単にコードを書いて、すぐデプロイということが出来そうです。

インストールからコード記述、デプロイまでの操作がHelloworldならこんなに簡単に出来るようです。

$ pip install chalice
$ chalice new-project helloworld && cd helloworld
$ cat app.py

from chalice import Chalice

app = Chalice(app_name="helloworld")

@app.route("/")
def index():
    return {"hello": "world"}

$ chalice deploy
...
https://endpoint/dev

$ curl https://endpoint/api
{"hello": "world"}

Zappa

こちらも、とにかく簡単にPythonで作成した関数をAWSにデプロイ出来ることがウリのようです。

https://github.com/Miserlou/Zappa

gifアニメーションで実演が付いています。(README.mdから引用しました)
README.md

Zappa Demo Gif

REST APIを作成する以外にも、AWS Eventsに対応するものや、Asynchronous Task Executionといって、別のLamdba関数を非同期に呼び出すことが出来る機能を持っているようです。
というか、chaliceに比べると非常に多彩。

また、ZappaはWSGI(Web Server Gateway Interface)をサポートしているので、他のアプリケーションサーバーにデプロイすることも可能です。

chalice vs Zappa

こちらに比較記事がありました。

続きを読む

AWS サービス別 APIプロトコル一覧

Pythonのbotocoreに入っているメタデータから持ってきた。

サービス名 API protocol
acm json
apigateway rest-json
application-autoscaling json
appstream json
athena json
autoscaling query
batch rest-json
budgets json
clouddirectory rest-json
cloudformation query
cloudfront rest-xml
cloudhsm json
cloudsearch query
cloudsearchdomain rest-json
cloudtrail json
cloudwatch query
codebuild json
codecommit json
codedeploy json
codepipeline json
codestar json
cognito-identity json
cognito-idp json
cognito-sync rest-json
config json
cur json
datapipeline json
dax json
devicefarm json
directconnect json
discovery json
dms json
ds json
dynamodb json
dynamodbstreams json
ec2 ec2
ecr json
ecs json
efs rest-json
elasticache query
elasticbeanstalk query
elastictranscoder rest-json
elb query
elbv2 query
emr json
es rest-json
events json
firehose json
gamelift json
glacier rest-json
greengrass rest-json
health json
iam query
importexport query
inspector json
iot rest-json
iot-data rest-json
kinesis json
kinesisanalytics json
kms json
lambda rest-json
lex-models rest-json
lex-runtime rest-json
lightsail json
logs json
machinelearning json
marketplace-entitlement json
marketplacecommerceanalytics json
meteringmarketplace json
mturk json
opsworks json
opsworkscm json
organizations json
pinpoint rest-json
polly rest-json
rds query
redshift query
rekognition json
resourcegroupstaggingapi json
route53 rest-xml
route53domains json
s3 rest-xml
sdb query
servicecatalog json
ses query
shield json
sms json
snowball json
sns query
sqs query
ssm json
stepfunctions json
storagegateway json
sts query
support json
swf json
waf json
waf-regional json
workdocs rest-json
workspaces json
xray rest-json

続きを読む