API Gatewayのキャッシュ機能[解決済み]
キャッシュ機能
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api-gateway-caching.htmldocs.aws.amazon.com
ヘッダやクエリパラメータは個別にキャッシュキーに使う設定をすればいいらしい。 ということでCloudFormationのテンプレートを書いてみたのだが、、、
書いたテンプレート(抜粋)
Resources:
MyApi:
Type: AWS::ApiGateway::RestApi
Properties:
Name: MyApi
MyApiResource:
Type: AWS::ApiGateway::Resource
Properties:
RestApiId:
Ref: MyApi
ParentId:
Fn::GetAtt:
- MyApi
- RootResourceId
PathPart: hoge
MyApiMethod:
Type: AWS::ApiGateway::Method
Properties:
HttpMethod: GET
ResourceId:
Ref: MyApiResource
RestApiId:
Ref: MyApi
AuthorizationType: NONE
RequestParameters:
method.request.querystring.foo: true
method.request.querystring.bar: false
Integration:
CacheKeyParameters:
- method.request.querystring.foo
- method.request.querystring.bar
MyApiDeployment:
Type: AWS::ApiGateway::Deployment
Properties:
RestApiId:
Ref: MyApi
StageName: fuga
StageDescription:
CacheClusterEnabled: true
CacheClusterSize: 0.5
CachingEnabled: true
MethodSettings:
- HttpMethod: GET
ResourcePath: /hoge
CachingEnabled: true
普通のリクエストだとキャッシュされるが、、、
問題のリクエスト
GET /hoge?foo=one&bar=two&foo=threeGET /hoge?foo=one&bar=two&foo=four
1.と2.のレスポンスは同じものが返ってきてしまう。。。 どうやら同名のパラメータが複数あると、どういう基準でキャッシュキーを作っているのだろう🤔 (今回はキャッシュを使うことはMUSTでは無かったので、これ以上深入りしなかった。。。)
同名複数パラメータを受け入れられるようになったのはそんなに前では無いから、このあたりもこれから対応されるのだろうか？
解決(2019/12/21追記)
この問題、CloudFormationのstackをupdateしてもAPIGatewayのstageにdeployされるわけでは無かった、というだけでした、、、
CloudFormationだけでdeployするやり方が分からなかったので、以下のコマンドでとりあえず解決。
$ aws apigateway create-deployment --rest-api-id hoge --stage-name fuga --description "deployment"
API GatewayのリソースポリシーでのRefの使い方
前回のメモを書いた後、そういえばCustomStatementsで自由にPolicyが書けるようになっていたのを思い出した。
作り直したテンプレート(抜粋)
Resource:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: hoge
EndpointConfiguration: PRIVATE
Auth:
ResourcePolicy:
CustomStatements:
- Effect: Deny
Principal: "*"
Action: execute-api:Invoke
Condition:
StringNotEquals:
aws:SourceVpce:
Ref: MyEndpoint
MyEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: vpc-1234
VpcEndpointType: Interface
SubnetIds:
- subnet-1234
ServiceName:
Fn::Sub: com.amazonaws.${AWS::Region}.execute-api
SecurityGroup:
- sg-1234
これで無事通りますね👍
API Gatewayのリソースポリシー指定時の制約
最近SAMのテンプレートを書く機会が増えてきた。 (多分一過性)
SAMと言っても、AWS::Serverless::Functionだけで事足りることが多かったものの、
今回新たにAWS::Serverless::Apiを使おうとして、痒いところに手が届かないことがあったのでメモ、、、
作りたかったもの
AWS::Serverless::Functionに接続するプライベートAPIの構築
以下を参考にテンプレートを作成 docs.aws.amazon.com
リソースポリシーで「ソースVPCホワイトリスト」を指定して、作成したVPCエンドポイントからのアクセスを許可したい
作ったテンプレート(抜粋)
VPCエンドポイントを同じテンプレートで作成 後述しますが、これが通らない、、、
Resource:
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: hoge
EndpointConfiguration: PRIVATE
Auth:
ResourcePolicy:
SourceVpcWhitelist:
Ref: MyEndpoint
MyEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: vpc-1234
VpcEndpointType: Interface
SubnetIds:
- subnet-1234
ServiceName:
Fn::Sub: com.amazonaws.${AWS::Region}.execute-api
SecurityGroup:
- sg-1234
何故通らなかったか
VPCのホワイト/ブラックリストに指定できる値は、VPCエンドポイント(vpce-hogehoge)だけでなくVPC(vpc-hogehoge)全体も指定できる
で、リソースポリシーで指定するときは、それぞれ以下のように指定するフィールド名が異なる
{ "Condition" : {
"StringNotEquals": {
"aws:SourceVpc": "vpc-hogehoge",
"aws:SourceVpce": "vpce-hogehoge"
}
}
}
AWS::Serverless::Apiでは、これらを同じフィールドに指定させる仕様になっているので、変換時にどちらか確定できないと変換できない、ということなんですね、、、
ここで落ちていたので、
今回落ちたRefだけでなく、Fn::GetAttやFn::ImportValueを使ってもやはりダメ、ということのようです。
解決策
大人しくAWS::ApiGateway::RestApiを使いましょう
Resource:
MyApi:
Type: AWS::ApiGateway::RestApi
Properties:
EndpointConfiguration:
Types:
- PRIVATE
Policy:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal: "*"
Action: execute-api:Invoke
Resource: execute-api:/stage/Method/*
- Effect: Deny
Principal: "*"
Action: execute-api:Invoke
Resource: execute-api:/stage/Method/*
Condition:
StringNotEquals:
aws:SourceVpce:
Ref: MyEndpoint
雑感
これバグっぽいなぁと思ってPRを出すつもりで読んでいたものの、実装やドキュメントを読んで見るとどうしてこうなったかある程度納得できる結果になりました。。。
プライベートAPIの機能自体が後発なので、そこまで考えてなかったのかなぁという気もするものの、SAM自体はライトなユーザ向けのものだと思うので、こういう使い方まで考慮しなくてもそんなに問題にならないんだろうなぁ
結局複雑な要件をテンプレートで満たしたい手練は素のリソースを指定しましょう(楽するな)ということなんですかね🤔
AWS CloudWatch Alarm一覧
最近AWS CloudWatch Logsとお友達としてお付き合いしているものの、お隣のAlarmの方とはあまり仲良くしていなかった。
困ったこと
「Management Consoleで最近のAlarmのステータス変更履歴って取れなかったかな？🤔」
解決策
awscli で取ってくれば良い👍 指定時間内のRegion内全履歴を取得できる！
$ aws cloudwatch describe-alarm-history --start-date 9999-99-99T99:99:99.999Z --end-date 9999-99-99T99:99:99.999Z
雑感
Management Consoleで本当にできなかったのかは分からず、、、 そして本当に欲しかった情報はそこにはありませんでした😭
Gemを作ってみた (7) CodeClimate
Rubyのリポジトリだったらまず導入したいCodeClimate。
CodeClimate
言わずと知れた静的コード解析サービス。
現在RubyとJavascriptに対応しているようだ。
導入しようと思っていたのだが、 publicなリポジトリをフリーで登録する場所がわからなかったため、 ここまで遅れてしまった(T_T)
登録する場所はこちら。
リポジトリのURLとメールアドレスを登録するだけと、とてもカンタン！
現在のバッジはこちら
クラスごとにAからFまでランク付けされ、
コードの綺麗さを数値化してくれる(MAX 4.0)。
導入したからには4.0を維持できるように実装していきたい(｀･ω･´)ゞ
