Does an API key auto-renew before it expires?

No, an AppSync API key has a maximum lifetime of 365 days and does not automatically renew, once it expires, any client still using it starts getting authentication failures. You need to explicitly create a new key (or update the expiry) before the old one lapses and roll clients over to it, this is a common source of a sudden, unexplained outage when a long-lived key nobody was tracking finally expires.

Can different fields in the same schema require different authentication providers?

Yes, via AppSync's field-level auth directives (like @aws_auth or @aws_api_key depending on the specific auth mode syntax), a schema can require Cognito auth for most fields while allowing a specific public field to be accessible via API key, giving fine-grained per-field access control layered on top of the API-level list of allowed authentication providers, not just an all-or-nothing choice.

What's the tradeoff of setting FieldLogLevel to ALL versus ERROR?

ALL logs every single field resolution, useful for deep debugging of resolver behavior and performance but generates significantly more CloudWatch Logs volume (and cost) in production. ERROR only logs resolver failures, which is usually the right default for production once the API is stable, reserving ALL for active debugging sessions on a specific problematic resolver, not as a permanent production setting.

AWS AppSync Schema Builder

ServerlessAWS

Build AppSync GraphQL API schema configurations with types, queries, mutations, subscriptions, and auth providers.

AWS AppSync Configuration

Build AppSync GraphQL API schema configurations with types, queries, mutations, subscriptions, and auth providers.

Required Fields

ApiNameAuthenticationTypeSchema.Types

{
  "ApiId": "abc123def456",
  "ApiName": "ecommerce-graphql-api",
  "AuthenticationType": "AMAZON_COGNITO_USER_POOLS",
  "AdditionalAuthenticationProviders": [
    {
      "AuthenticationType": "API_KEY",
      "ApiKeyConfig": {
        "Description": "Public read-only access",
        "ApiKeyExpiresAfterDays": 365
      }
    },
    {
      "AuthenticationType": "AWS_IAM"
    }
  ],
  "Schema": {
    "Types": [
      {
        "Name": "Product",
        "Fields": [
          {"Name": "id", "Type": "ID!"},
          {"Name": "name", "Type": "String!"},
          {"Name": "description", "Type": "String"},
          {"Name": "price", "Type": "Float!"},
          {"Name": "category", "Type": "Category!"},
          {"Name": "reviews", "Type": "[Review]", "Resolver": "listReviewsByProduct"}
        ]
      },
      {
        "Name": "Review",
        "Fields": [
          {"Name": "id", "Type": "ID!"},
          {"Name": "productId", "Type": "ID!"},
          {"Name": "rating", "Type": "Int!"},
          {"Name": "comment", "Type": "String"},
          {"Name": "author", "Type": "String!"}
        ]
      }
    ],
    "Queries": [
      {"Name": "getProduct", "Args": "(id: ID!)", "ReturnType": "Product"},
      {"Name": "listProducts", "Args": "(limit: Int, nextToken: String)", "ReturnType": "ProductConnection"}
    ],
    "Mutations": [
      {"Name": "createProduct", "Args": "(input: CreateProductInput!)", "ReturnType": "Product"},
      {"Name": "updateProduct", "Args": "(input: UpdateProductInput!)", "ReturnType": "Product"}
    ],
    "Subscriptions": [
      {"Name": "onCreateProduct", "ReturnType": "Product"}
    ]
  },
  "LogConfig": {
    "CloudWatchLogsRoleArn": "arn:aws:iam::123456789012:role/appsync-logs-role",
    "FieldLogLevel": "ERROR",
    "ExcludeVerboseContent": false
  },
  "XrayEnabled": true
}

Generated Output

Output will appear here...

About This Tool

Build an AppSync GraphQL API definition combining a primary AuthenticationType with AdditionalAuthenticationProviders, letting different clients authenticate differently against the same API (Cognito user pools for logged-in app users, an API key for limited public read access, IAM for server-to-server calls), each provider's access scoped further by @aws_auth-style directives on individual schema fields, not a single blanket permission model for the whole API. An API key (as configured via ApiKeyConfig) has a hard maximum lifetime of 365 days and must be manually rotated before expiry, since AppSync doesn't auto-renew API keys, a key silently expiring is a common self-inflicted outage for any client still relying on it.

When to Use This Tool

•Adding API_KEY as an AdditionalAuthenticationProviders entry specifically scoped (via schema-level auth directives) to public read-only queries, while the primary Cognito user pool authentication handles authenticated mutations, giving anonymous users limited access without requiring login for read-only browsing.
•Adding AWS_IAM as an additional provider so server-to-server calls (from a Lambda function or another backend service) authenticate via IAM roles rather than needing to manage a separate API key or user pool credential for machine-to-machine access.
•Setting FieldLogLevel to ERROR rather than ALL in production, logging only resolver errors instead of every single field resolution, which keeps CloudWatch Logs volume and cost manageable while still catching genuine failures.
•Attaching a custom Resolver (listReviewsByProduct) to a specific field like Product.reviews, so that nested relationship resolves via its own dedicated data-fetching logic rather than requiring the client to make a separate follow-up query.

Pro Tips

TIP

Track API key expiration dates actively, an expiring, unrotated API key is a completely preventable outage that catches teams off guard because nothing alerts on it by default, set a calendar reminder or automated check well before the 365-day maximum.

TIP

Field-level auth directives are what actually make multi-provider authentication useful, just listing multiple AdditionalAuthenticationProviders without corresponding field-level directives means every provider effectively has access to everything the primary auth type would, verify the directives are actually scoping access as intended.

TIP

XrayEnabled adds useful request tracing for debugging resolver performance issues but has a small cost and overhead, it's usually fine to leave on for production APIs given the debugging value, but confirm your X-Ray sampling and cost expectations rather than assuming it's free.

How It Works Under the Hood

The builder validates that ApiName, AuthenticationType, and Schema.Types resolve before accepting the JSON as a valid combined API definition (spanning what would actually be several separate AppSync API calls to create the API, set its schema, and configure logging); it can't verify the schema's GraphQL syntax is fully valid or that referenced Resolver names correspond to actually-configured data sources, those checks happen only when the schema is applied against a live API.

Frequently Asked Questions

Does an API key auto-renew before it expires?: No, an AppSync API key has a maximum lifetime of 365 days and does not automatically renew, once it expires, any client still using it starts getting authentication failures. You need to explicitly create a new key (or update the expiry) before the old one lapses and roll clients over to it, this is a common source of a sudden, unexplained outage when a long-lived key nobody was tracking finally expires.
Can different fields in the same schema require different authentication providers?: Yes, via AppSync's field-level auth directives (like @aws_auth or @aws_api_key depending on the specific auth mode syntax), a schema can require Cognito auth for most fields while allowing a specific public field to be accessible via API key, giving fine-grained per-field access control layered on top of the API-level list of allowed authentication providers, not just an all-or-nothing choice.
What's the tradeoff of setting FieldLogLevel to ALL versus ERROR?: ALL logs every single field resolution, useful for deep debugging of resolver behavior and performance but generates significantly more CloudWatch Logs volume (and cost) in production. ERROR only logs resolver failures, which is usually the right default for production once the API is stable, reserving ALL for active debugging sessions on a specific problematic resolver, not as a permanent production setting.

Related Learning Guides

Lambda Performance Tuning26 min read
SQS vs SNS vs EventBridge25 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.

AWS AppSync Schema Builder

ServerlessAWS

Build AppSync GraphQL API schema configurations with types, queries, mutations, subscriptions, and auth providers.

AWS AppSync Configuration

Build AppSync GraphQL API schema configurations with types, queries, mutations, subscriptions, and auth providers.

Required Fields

ApiNameAuthenticationTypeSchema.Types

Generated Output

Output will appear here...

About This Tool

When to Use This Tool

•Adding API_KEY as an AdditionalAuthenticationProviders entry specifically scoped (via schema-level auth directives) to public read-only queries, while the primary Cognito user pool authentication handles authenticated mutations, giving anonymous users limited access without requiring login for read-only browsing.
•Adding AWS_IAM as an additional provider so server-to-server calls (from a Lambda function or another backend service) authenticate via IAM roles rather than needing to manage a separate API key or user pool credential for machine-to-machine access.
•Setting FieldLogLevel to ERROR rather than ALL in production, logging only resolver errors instead of every single field resolution, which keeps CloudWatch Logs volume and cost manageable while still catching genuine failures.
•Attaching a custom Resolver (listReviewsByProduct) to a specific field like Product.reviews, so that nested relationship resolves via its own dedicated data-fetching logic rather than requiring the client to make a separate follow-up query.

Pro Tips

TIP

How It Works Under the Hood

Frequently Asked Questions

Does an API key auto-renew before it expires?: No, an AppSync API key has a maximum lifetime of 365 days and does not automatically renew, once it expires, any client still using it starts getting authentication failures. You need to explicitly create a new key (or update the expiry) before the old one lapses and roll clients over to it, this is a common source of a sudden, unexplained outage when a long-lived key nobody was tracking finally expires.
Can different fields in the same schema require different authentication providers?: Yes, via AppSync's field-level auth directives (like @aws_auth or @aws_api_key depending on the specific auth mode syntax), a schema can require Cognito auth for most fields while allowing a specific public field to be accessible via API key, giving fine-grained per-field access control layered on top of the API-level list of allowed authentication providers, not just an all-or-nothing choice.
What's the tradeoff of setting FieldLogLevel to ALL versus ERROR?: ALL logs every single field resolution, useful for deep debugging of resolver behavior and performance but generates significantly more CloudWatch Logs volume (and cost) in production. ERROR only logs resolver failures, which is usually the right default for production once the API is stable, reserving ALL for active debugging sessions on a specific problematic resolver, not as a permanent production setting.

Related Learning Guides

Lambda Performance Tuning26 min read
SQS vs SNS vs EventBridge25 min read

Was this tool helpful?