以下、AWSへの問い合わせ内容です。
API Gateway の HTTP API におけるルートは、REST API の場合におけるリソースパスと HTTP メソッドに相当致します。
そのため、すでにご認識を頂いておりますように、HTTP API の Lambda 統合では、入力イベントに含まれる routeKey や rawPath を通じて REST API の入力イベントにおける resource や path と同様の値を取得頂けます。

• HTTP API のルートの使用 – Amazon API Gateway
  https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/http-api-develop-routes.html
  （抜粋）
  「ルートは、HTTP メソッドとリソースパスという 2 つの部分で構成されます (例: GET /pets)。」

なお、routeKey や rawPath といった名称より、当該の HTTP API における Lambda 統合では、デフォルト設定であるペイロード形式バージョン 2.0 を選択頂いているものとお見受けをしておりますが、入力イベントに含まれるこれらの要素名は Lambda 統合で選択頂くペイロード形式バージョンに応じて異なります。
また、routeKey につきましては、REST API の場合における resource と同様に、API 上のルート設定に応じて、API クライアントからの具体的なリクエストパスではなく $default や {proxy+} といった複数のリクエストパスに合致し得る値が保持される場合がございます点にご注意をお願い申し上げます。

The post REST-APIとHTTP-APIのイベントペイロード名称 first appeared on アスキー(asQii).

下記のCORSエラーがクライアントコンソールで発生します。
No ‘Access-Control-Allow-Origin’ header is present on the requested resource

オリジンはS3です。

1 オリジンのレスポンスヘッダーポリシーにSimpleCORSを設定してもエラー発生
2 linkの中にcrossorigin=”anonymous”を設定してもエラー発生

一方、edgeの場合は上記1,2に関係なくエラーは発生しません。

これはブラウザに起因するもので対応できないのか、　わかる方教えてください。

The post PWAをChromeで実行するときmanifest.jsonのダウンロードエラー（未解決） first appeared on アスキー(asQii).

　AppSyncのウィザードで作成する場合、モデルフィールドの設定においてタイプがIDとあります。実際タイプをIDにしてDynamoDBのパーティションキーに設定するとクエリで取得できます。この場合でもDynamoDBのパーティションキーは「項目名(String)」と表示されています。
　DynamoDBコンソールから作成(デフォルト設定、カスタマイズ設定でも同じ)した場合、パーティションキーのタイプには数値、バイナリ、文字列しかなく、文字列で作成すると同様に「項目名(String)」となります。しかし、この場合クエリからは以下のようなエラーとなります。
　The provided key element does not match the schema (Service: DynamoDb, Status Code: 400, Request ID:〜)
IDとStringの違いと思うのですが、ウィザードでは可能なDynamoDBのタイプIDを、直接DynamoDB作成で指定する方法がわかりませんでした。ウィザードで作成したテーブルで運用できているので、以下をサポートへ質問しました。
————————————————————————–
AppSyncのウィザードで作成する場合、モデルフィールドの設定においてタイプがIDとあります。タイプをIDにしてDynamoDBのパーティションキーに設定してもDynamoDBのパーティションキーは「項目名(String)」と表示されています。違いは何でしょうか？
————————————————————————–

回答
　AppSync ではオブジェクトタイプのフィールドのスカラー型として、ドキュメント [1] の型を定義しております。その中でも ID 型はオブジェクトの一意な識別子を表しております。
[1]AWS AppSync のスカラー型 – AWS AppSync
　https://docs.aws.amazon.com/ja_jp/appsync/latest/devguide/scalars.html
　まとめると「IDはオブジェクトの一意な識別子。このスカラーは、String のようにシリアル化されますが、人間が読めることは意図していない、DynamoDB ではパーティションキーとソートキーは文字列、数値、またはバイナリとして定義される必要がある。そのため、AppSync における ID 型は DynamoDB では String 型として格納されている。」

[2] データ型 – Amazon DynamoDB でサポートされるデータ型と命名規則 – Amazon DynamoDB
　https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes

　まとめると「テーブルまたはセカンダリインデックスを作成するときは、各プライマリキー属性 (パーティションキーとソートキー) の名前とデータ型を指定する必要があり、各プライマリキー属性は、文字列、数値、またはバイナリとして定義する必要がある。」

　ちょっと消化不良なのですが、特に問題は起こっていないので良しとしました。

The post AppSyncのウィザードから作成したDynamoDBのIDフィールド first appeared on アスキー(asQii).

　AWS上でシステムが完結すれば良いのですが、オンプレのシステムにアクセスする必要がある時、APIGateway – Lambda – VPC – ALB/NLB – ダイレクトコネクト – プライベートネットワークのような形になろうかと思います。

　オンプレのWebシステムがシンプルなWebサービスやマイクロサービスであれば特に問題ありませんが、通常の画面を返すようなWebサイトだと、html上のリンクがオンプレ上のアドレスや相対パスになっていたり、リダイレクトを指示しているケースがあります。その場合、当然ですが、アクセス元のブラウザに正しく表示されません。更にヘッダー等でトークン等を認証している場合もあります。

　基本的には「インターネット→API Gateway（※greedy パス変数を設定）→ (VPC Link) → VPC内  Network LoadBalancer → (Direct Connect) → オンプレWeb サイト」の流れになるでしょう。

　自分がコントロールしているシステムであれば対応もさほど難しくは無いのですが、色んなパッケージ製品やERP、他社でSIされたシステムが対象となると「サポート対象外です」とか言われて、情報提供してくれません。Chromeで取得したHARファイルから拾うしかなく大変でした。

　最終的には①greedyパス変数②受信リクエスト(ヘッダー、パス)とレスポンスコードのマッピング③特定の条件下のクエリパラメータをパスの書き換えで変換するの方法でクリアすることが出来ました。

　少し③について説明します。HTTP APIのパラメータマッピングではすべての受信リクエストに対して変換が適用されるので、特定条件の場合のみパラメータを追加したいというような対応が出来ません(当時はそのようにAWSから回答頂きました。機能要望としてはあげてもらいましたので、今は可能になったかも？)。

クエリパラメータであることから、パラメータを含めたパスの書き換えで行ってみたところ、問題なく特定の条件下でパラメータの追加の有無が可能になりオンプレシステムにも連動できました。パラメータのマッピングをパスのマッピングで/aaa?prm01=val01&prm02=val02のように上書きするって感じです。念の為AWSにも確認しましたが、問題ありませんと回答頂きました。

　その他以下のことがわかりました。

1. VPCリンクを使用するとき、NLB DNS 名の設定がある。デフォルトではhttpはOKだが、httpsにする場合はNLB 側で TLSのリスナー設定が必要(内部ネットワークなのでhttpで不都合はない)。
2. VPCLinkと接続されたNLB 、VPCピアリングを経由する構成においても、別 VPC 内に配置されたリソースよりレスポンスを受け取ることは可能。

The post APIGateway(HTTP API)からオンプレシステムへの連携 first appeared on アスキー(asQii).

対応
　Android スマートフォンや iPhone (iOS) は AppStream 2.0 のクライアントオペレーティングシステムとしてサポートされていない。スマートフォンからアクセスした際にブラウザにて PC 版のサイトを表示するオプションを有効にすることで、接続が可能となる場合がある(サポート外)。AWSでは機能要望として担当部署までフィードバックすると

WorkLinkが提供されなくなったので、スマホ用のセキュアリモートアクセス環境を考えました。AppStreamはコストが高口なるので、結局ワークに紹介しましたモバイルアクセスプラットフォームを作りました。

The post AppStreamのクライアント first appeared on アスキー(asQii).

対応
　AWSの技術チームから直接連絡(この時点ではオフレコ)があった。なんとサービス終了予定のためコンソールのメニューから外しているらしい。今後はAppStreamに移行していくとのこと。これからの予定だったため実害はなかったが、クラウドサービスはやはりこういった事があるのであまりマイナーなサービスは使わない方が良い。

The post WorkLink　東京停止 first appeared on アスキー(asQii).