Design Direction: AWS AppSync (GraphQL Managed Service) as BFF Layer

Date Dec 1, 2024

Idea Initiator

Design Producer @Mahaboob Shareef

Design Contributor(s) @Srinivas Krishnamoorthy

Status IN REVIEW

( DRAFT | IN PROGRESS | IN REVIEW | APPROVED |

ENDORSED | ON HOLD )

Governance

Design Authority
Endorsed ( | )
Who Role Date Endorsement Evidence
Endorsed

@Andrew Sanders Director, Enterprise Architecture

Design Approval
Approved( | )
Who Date Approval Evidence
Approved

Design Lead @Alex Crommelin

@Srikanth Yelakaturu

Idea Initiator

Security @Chris Martyn

Consulted

Who Comments

Product/Business Owner

Data Governance

Legal
 Privacy

Dependent/Impacted
System Owner(s)

Vendor

Other Stakeholders

Related Artefacts

Document Type Reference

Solution Design

Proof of Concept

Business Context

Technical Design(s)

Governance
Design Authority
Design Approval
Consulted
Related Artefacts
Design Request
Idea
GraphQL is particularly advantageous when:
When REST Might Be Better
Timing
Size and Complexity
Priority
Design Direction
Solution
Options Analysis
Guardrails/Governance for AppSync
Authentication and Authorization:
Data Encryption:
Resolver Optimization:
Query Complexity Limits:
Cost Monitoring:
API Rate Limits:
Resolver Optimization:
High Availability:
Monitor and Auto-Scale:
Versioning and Deployment:
Logging and Monitoring:
Schema Design:
Testing and Debugging:
Documentation and Developer Access:
GraphQL Query Templates
 Structure of Query Templates
Uses Cases:
Templates storage and Management
Potential Security Risks
Security Features Provided by AppSync
Governance for Secure Query Templates
Governance for aggregation of data across tables, views, datastores to ensure that joins are done consistently
Potential Scenarios
Consistency of responses across channels
Dependencies and Impacts
Design Decisions
AppSync Proof of Concept
Risks and Opportunities
Solution Design Estimate
Security Impact Assessment
Third-Party Risk Assessment
Conceptual Model
Data Classification
Data Impact Assessment
Business Continuity Management
Delivery Estimate
Architecture Principles Alignment

Design Request

Idea
What is the business problem or opportunity a design has been requested to resolve?

Technology standards considered for BFF API Implementation. Idea is to explore implementing BFF as GraphQL APIs with AWS AppSync.

Important Business Problems that can be addressed using AWS AppSync - GraphQL APIs

Real-Time Collaboration Applications: To build a real-time collaboration platform (e.g., shared document editing, task management, or a
live whiteboard) where updates from one user are instantly reflected for all other users.

Multi-Platform Data Access: An organization has multiple front-end clients (web, mobile, IoT devices) that require access to a unified
backend data model sourced from diverse systems like databases, third-party APIs, and microservices.

Search and Recommendation Engines: A platform wants to provide personalized product recommendations and robust search
capabilities for their users. Integrates with Amazon OpenSearch to handle search and ranking.

Data Aggregation for Microservices: An enterprise with a microservices architecture needs to aggregate data from multiple microservices
into a single interface for front-end applications.

Content Management Systems (CMS): Want to deliver dynamic, personalized content (e.g., news articles, videos) to users across
platforms while minimizing latency.

Event-Driven Applications: A scalable system to handle high traffic during search, ensure data consistency, and provide updates in real
time.

Development teams are increasingly choosing to build their APIs with GraphQL over the traditional REST API approach due to following
reasons as well

Import Features GraphQL REST

 Flexible Data Retrieval Allows clients to specify exactly what data Fixed endpoints return predefined data
they need in a single request. This avoids structures. To retrieve different
over-fetching (receiving unnecessary data) combinations of data, additional endpoints
and under-fetching (making multiple or requests may be needed.
requests to gather all needed data).

Single Endpoint Uses a single endpoint (e.g., /graphql ) Requires multiple endpoints (e.g., /users ,
for all operations (queries, mutations, and /posts , /comments ), which can lead to
subscriptions). This simplifies API complex endpoint management as the API
management and integration. evolves.

Strongly-Typed Schema Enforces a strongly-typed schema that Does not enforce strict typing, leading to
defines the structure of the API, the data potential inconsistencies in returned data
types, and the relationships between formats.
entities. This ensures consistency and
provides a clear contract between clients
and servers.

Real-Time Capabilities Supports real-time data updates using Requires additional mechanisms like
subscriptions, enabling clients to receive WebSockets or polling to achieve real-time
updates as soon as the data changes. updates, which adds complexity.

Efficient Data Handling Batch data retrieval is built-in. Clients can Often requires multiple round-trips to the
fetch data from multiple sources in one server to retrieve related data, leading to
request using resolvers. higher latency and more bandwidth usage.

Versionless API Evolving the API doesn't require creating API versioning (e.g., /v1/users ,
new versions. New fields can be added to /v2/users ) is common, which can create
the schema without affecting existing maintenance overhead and compatibility
clients, as clients only query what they challenges.
need.

Built-In Documentation Introspective queries allow clients to query Requires external tools (e.g., Swagger,
the schema itself for documentation. Tools Postman) to document the API manually.
like GraphiQL or Apollo Studio
automatically generate interactive
documentation.

Client-Driven Development Shifts control to the client by letting it define Server-driven responses limit flexibility,
the shape of the response. This is often requiring frontend changes if API
particularly useful for frontend teams responses need adjustments.
working on dynamic or diverse client
needs.

GraphQL is particularly advantageous when:

You need flexible data fetching for diverse clients (e.g., web, mobile, IoT).
The API involves complex or deeply nested data relationships.
Real-time data updates are required.
Multiple data sources need to be aggregated in a single API.

When REST Might Be Better

REST remains a strong choice for:

 Simple CRUD operations where the benefits of GraphQL might not justify the complexity.
Scenarios requiring caching at the HTTP level, as GraphQL uses a single endpoint, making caching more challenging.

This Design Direction recommends a POC using AWS AppSync which should satisfy criteria mentioned in the AppSync PoC section
which will help in taking a decision if AWS AppSync, a fully managed Service providing Serverless GraphQL API solutions can be
used as a BFF Layer as part of IDP Target state Architecture.

Timing
When is it required to be ready for Engineering? Which PI or Sprint or date?

As part of B2C Domestic Modernization

Size and Complexity

What size or complexity has the change initiator indicated they expect this to be?
N/A - It is a Technology change

Priority
What is the business priority?

Not a business priority. It is more of technology driven

Design Direction

Solution
What is the proposed solution architecture / technical solution?

Proposed solution is to decide if AWS AppSync, a fully managed Service providing Serverless GraphQL API solutions can be used as a BFF
Layer as part of IDP Target state Architecture due to the reasons mentioned in the Idea section.
Options Analysis
What options have been investigated and what rationale/evidence do you have to show that the full set has been investigated?

Options Analysis Table

Option # 1 - API Gateway (REST) 2 - AWS AppSync (GraphQL) Comments

Fully Managed Service Yes Yes

Data access REST API GraphQL

HTTPS/TLS Yes Yes

Request Validation Yes Yes

Direct support of Yes (to be defined in JSON Yes (GraphQL schema definitions inherently
Response Validation Schema) enforce validation on data returned by
resolvers)

WebSockets Yes (For real-time bidirectional Yes (Inherently supported)

updates)

Scalable WebSockets Complex Easy - Inherently Managed

Direct support of No - but can achieve through Yes

broadcast custom implementation - Complex

Implementing group Complex and cost inefficient Easy

chats

Real-time and offline No - Lacks offline functionality Yes

functionality

Handle real-time Difficult Easy

communication

Authorization AWS_IAM AWS_IAM

Cognito Cognito
API_KEY API_KEY
OPENID_CONNECT OPENID_CONNECT

Native support for Yes Yes

Cognito group-based
authorization

Cost Low Bit High AWS AppSync Pricing | Managed

GraphQL APIs | Amazon Web Services

Monitoring Logging Yes Yes

Caching options Yes (provides built-in caching at the Yes (resolver-level caching with Amazon
stage level using Amazon API DynamoDB Accelerator (DAX) or its built-in
Gateway Cache, backed by a fully AppSync Data Caching feature.)
managed Amazon CloudFront
Cache Scope - query/mutation granularity
distribution)

Cache Scope - API-wide (stage

level)
Integration with WAF Yes Yes

Custom domain Yes Yes

Private endpoint Yes Yes (Through Amazon VPC Endpoint)

Scalability Yes, but requires configuration like More scalable for extremely high traffic
throttling and need global APIs applications
optimized for edge delivery

Security On the resource and method level Field Level

1. Security setup might be 1. Real-time updates are more secure with

complex, especially for more built-in security for subscriptions and
advanced features like Lambda queries.
authorizers. 2. Simplified security configurations for
2. Requires manual configuration GraphQL APIs with automatic integration
for things like rate limiting and of IAM and Cognito.
CORS

Support of programming Wide range 1. AppSync supports various languages

languages through Lambda resolvers and other
While API Gateway supports
AWS integrations (e.g., DynamoDB, RDS,
numerous programming languages
Elasticsearch).
but might need to manage multiple
2. Focused on GraphQL APIs, allowing to
services for different languages,
integrate multiple data sources without
especially in more complex
worrying about the underlying language.
architectures.

Integration with other Possible Not possible with all, just with some AWS
services services

Direct Integration with With Most Services With most AWS Services
AWS Services
Limited support for some non-AWS services
compared to API Gateway, which can
connect to virtually any HTTP-based service.

How does this option Provides a secure API accessible Same

resolve the issue from internet to be used with
website

Risks (Delivered) Already in use New Tech stack - Learning curve involved

Risks (Project) Already in use New Tech Stack needs learning curve which Engineering team
increases delivery timelines. confirms they have
enabled resources
with
AppSync/GraphQL
skills

Dependencies None Need AWS / Technical support for AppSync

and GraphQL

Pros 1. Wide Protocol Support - 1. Native GraphQL Support

Supports REST APIs, 2. Seamless Integration with AWS Services:
WebSocket APIs, and HTTP
3. Real-Time and Offline Support
 APIs, making it highly versatile 4. Simplified Data Management
for different types of 5. Built-In Security
applications.
6. Scaling and Performance - Automatically
2. Low cost - Pay-per-use (may scales with built-in features
increase with high traffic)
7. Create a pub/sub solution for real-time
3. Global Distribution events
8. AWS AppSync can simplify integration
with AI backends like Amazon Bedrock
through its inbuilt serverless WebSocket
subscriptions.

Cons 1. Complexity with Multiple 1. Learning Curve for GraphQL

Integrations: 2. Limited to AWS Services for Data Sources
2. Potential for Latency with 3. Cost - Pay-per-request, real-time
Lambda subscriptions may add cost
3. No Built-In Real-Time Support:
4. Limited for Data-Driven Apps
5. Scalability - Handles high traffic,
but may require more
configuration for complex
setups

NFRs Aligns to product NFRs Aligns to product NFRs

Principles Alignment Yes Yes

Operations Supported by CloudOps Supported by CloudOps

Skills No additional skills required. GraphQL and AWS AppSync skills required
Current Tech stack.

Support / Vendor AWS business support AWS business support

Conclusion Choose API Gateway if solution Choose AppSync (GraphQL APIs), if

needs flexibility in handling REST, solution need real-time data
WebSocket, or HTTP APIs with synchronization via subscriptions, or want
custom backend integrations and simplified integration with AWS data sources
fine-grained control over traffic and offline functionality for mobile/web apps.
management, security, and
monitoring.

Status

Recommended

Guardrails/Governance for AppSync

Count Guardrails Governance

1 Security Authentication and Authorization:

Use AWS Cognito for Authentication:

Use Amazon Cognito User Pools for
user authentication, which allows for
 seamless management of user
authentication and authorization at the
API level.
Enable OAuth 2.0 or OpenID
Connect for federated identities.
Use Cognito Groups for more
granular access control.
Fine-Grained Authorization:
Implement field-level authorization
to control access to specific fields in
GraphQL schema based on user
roles (e.g., only an admin can
access certain fields).
Use IAM-based authorization for
fine-grained access control to AWS
resources (like DynamoDB,
Lambda) via AppSync resolvers.
Use API Keys Carefully:
Avoid using API keys for sensitive
or production environments.
Instead, rely on AWS IAM or
Amazon Cognito for better security.
Set expiration times for API keys
to limit their validity, and ensure they
are rotated regularly.
Secure API Endpoints with AWS
WAF:
Use AWS Web Application
Firewall (WAF) to protect AppSync
API from common threats like SQL
injection, XSS, and other malicious
attacks.
Validate Inputs:
Use schema validation within
AppSync to enforce data types,
required fields, and patterns to
prevent invalid data from entering
the system.

Data Encryption:

Enable TLS/SSL Encryption: Ensure

that all AppSync endpoints use HTTPS
to encrypt the data in transit.
Encryption at Rest: For services like
DynamoDB, RDS, or any other data
store, enable encryption at rest to
ensure sensitive data is protected in the
storage layer.
2 Performance Resolver Optimization:

Minimize Resolver Complexity: Keep

resolvers simple and efficient to avoid
performance bottlenecks. Avoid
complex logic inside resolvers that
could slow down data retrieval.
Consider batching multiple
operations (e.g., batch queries to
DynamoDB) in a single request.
Optimize DynamoDB queries with
efficient indexes and partition
keys.
Use DataLoader or Caching:
If using Lambda resolvers,
implement DataLoader or a similar
pattern to reduce the number of calls
to underlying data sources.
Caching can help improve the
performance of frequently requested
data. Use AppSync's integrated
caching to cache responses for
repeated queries.
Avoid N+1 Query Problem: Be mindful
of how resolvers fetch related data to
avoid N+1 query issues, which can
result in excessive database calls and
poor performance.

Query Complexity Limits:

Limit Query Depth: Set query

complexity limits to prevent users from
issuing very deep or complex queries
that could overwhelm the backend
systems.
AppSync allows setting maximum
query depth and maximum query
complexity for GraphQL queries.
Set Timeout and Execution Limits:
Set timeouts for resolver functions,
especially when dealing with
external services like RDS, Lambda,
or third-party APIs.
For DynamoDB or other integrated
services, set query timeouts to
avoid long-running requests that
might stall the system.

3 Cost Control Cost Monitoring:

Use AWS Cost Explorer to track and

monitor AppSync API usage and its
associated costs.
 Set budget alerts for AppSync-
related services (e.g., data transfer,
resolver execution time) to avoid
unexpected costs.
Monitor Data Transfer:
Be aware of the data transfer
costs, especially when AppSync API
serves large amounts of data or has
high-frequency traffic. Optimize
queries to minimize the data sent
back to clients.

API Rate Limits:

Use subscriptions efficiently:

Keep track of active GraphQL
subscriptions and use subscription
limits to ensure that solution is not
over-consuming resources with
long-lasting connections or too many
active subscriptions.

4 Scalability and Availability Resolver Optimization:

Use DynamoDB Global Tables for

multi-region replication when solution
needs a highly available and scalable
database layer.
Leverage AppSync’s built-in caching
to reduce backend load for common
queries and improve performance.

High Availability:

If high availability is needed across

multiple regions, deploy AppSync APIs
in multiple AWS regions to improve
fault tolerance and availability.
Use AWS Global Accelerator to
route traffic to the nearest healthy
AppSync endpoint.

Monitor and Auto-Scale:

Use AWS CloudWatch to monitor

AppSync metrics such as request
count, error rates, and latency, ensuring
quick reaction to issues.
Auto-scale backend services (e.g.,
DynamoDB, Lambda) to ensure they
can handle the load when demand
spikes.

5 Maintenance Versioning and Deployment:

Implement API versioning to avoid

breaking changes. This allows to roll out
 new features without impacting existing
clients.
Can use the API versioning within
the AppSync schema to support
different client versions.
Deployment Automation:
Use AWS CloudFormation or AWS
CDK for Infrastructure as Code
(IaC) to manage AppSync
configurations and resolve
discrepancies between
development, staging, and
production environments.
Consider using CI/CD pipelines for
automating AppSync schema
deployments.

6 Compliance and Auditing Logging and Monitoring:

Enable AWS CloudWatch Logs to

capture and monitor detailed logs of
AppSync API activity, including resolver
execution and errors.
Use AWS CloudTrail to log API calls
and activities in AWS environment,
ensuring team has full visibility of any
changes to AppSync configurations or
API requests.

Data Privacy:

Ensure compliance with GDPR, HIPAA,

and other data privacy regulations by
properly handling and encrypting
sensitive data.
Be careful about storing sensitive
data (like credit card information) in
services such as DynamoDB. Use
encryption and masking
techniques as appropriate.

7 Best Practices for Developer Productivity Schema Design:

Design modular, reusable schemas

that are easy to maintain and extend.
Break down the schema into smaller,
domain-based parts.
Use input validation within GraphQL
schemas to avoid invalid data being
processed by resolvers.

Testing and Debugging:

Leverage AppSync’s built-in testing

capabilities to test GraphQL queries
 and mutations in a development
environment.
Use Mock Resolvers to simulate
interactions with backend services,
allowing for easier testing and
debugging.

Documentation and Developer Access:

Keep clear, up-to-date API

documentation and ensure that
GraphQL schema is properly annotated
with comments that describe types,
queries, and mutations.

GraphQL Query Templates Provide SDKs or sample clients for

developers to interact with AppSync
In AppSync, query templates are used to transform GraphQL requests into operations that interact with data sources. These templates are
seamlessly.
written in Apache Velocity Template Language (VTL). They are split into request mapping templates and response mapping templates.

Structure of Query Templates

Request Mapping Templates: A request mapping template transforms the GraphQL query into a format that the data source
understands.

Response Mapping Templates: A response mapping template formats the data returned by the data source into the structure expected
by the GraphQL schema.

Uses Cases:

1. Basic Query with Arguments

2. Pagination

3. Custom Headers for HTTP Data Source

Templates storage and Management

Storage and Management Description

In the AppSync Management Manage and edit query templates directly in the AWS Management Console for AppSync:
Console
Resolvers Section: Each field in GraphQL schema that needs a resolver has its associated
request and response mapping templates. To find:
Navigate to the Resolvers tab in the AppSync console.
Select the field or operation (e.g., Query.getItem , Mutation.createItem ).
Both the request and response mapping templates can be edited here.

In Infrastructure as Code If managing AppSync API using tools like AWS CloudFormation, AWS CDK, or Terraform, the query
(IaC) templates are stored as part of IaC configurations:

Stored Externally for Reuse For larger projects or to promote reusability and maintainability, mapping templates are often stored
in external files (e.g., .vtl files) and referenced in IaC or deployment scripts.

For example:

CloudFormation or AWS CLI: Use RequestMappingTemplateS3Location and

ResponseMappingTemplateS3Location to reference templates stored in Amazon S3.

AWS CDK: Use MappingTemplate.fromFile() to load templates from files.

Potential Security Risks

Security Risk Description Mitigation

Injection Attacks Mapping templates allow interpolation of 1. Use $util.escapeJavaScript() or

$context variables and other user inputs, $util.escapeJavaScriptString() for
which can be a vector for injection attacks if sanitizing input.
not sanitized properly. For example, directly 2. Validate all user inputs rigorously in the
including user inputs in expressions without template logic.
validation can lead to unexpected results.

Overexposure of Data Improperly designed templates can expose 1. Use fine-grained access control by
sensitive data if: filtering or transforming data in the
response mapping templates.
They don't enforce access control.
2. Return only the data needed by the
They include too much information in
client.
the response ( $context.result ).

Leaking Secrets in Error Messages If errors are not handled properly in the Always sanitize error messages with
templates, sensitive data (e.g., database $util.error() and avoid returning
keys or internal logic) might be exposed in internal details.
error responses.

Security Features Provided by AppSync

AWS AppSync ensures security for query templates through the following mechanisms:

Security Feature Description

Encryption at Rest Mapping templates stored in AppSync are encrypted at rest using
AWS-managed encryption keys. This ensures that the templates
themselves are protected from unauthorized access on AWS's
backend.

Role-Based Access Control (RBAC) Access to manage mapping templates is governed by AWS
Identity and Access Management (IAM). Team can control who
has permissions to:

View or edit templates in the AppSync console.

Deploy updates to templates using APIs, SDKs, or CLI.

Fine-Grained Access Control via Resolvers Mapping templates can include logic to enforce security
measures, such as:

Data access control: Filtering results based on user identity

( $context.identity ).
Custom authorization logic: Enforcing business rules.

Governance for Secure Query Templates

Governance Implementation

Use IAM for Access Management 1. Limit access to the AppSync API and its resolvers to only
authorized users or roles.
 2. Define least-privilege IAM policies to control who can view,
edit, or deploy templates.

Test for Security Vulnerabilities Use the AppSync Mapping Template Simulator to test queries
and mutations to identify unintended behaviors or data leaks.

Restrict Direct User Input in Queries 1. Avoid directly embedding unvalidated user inputs in query
expressions or headers.
2. Use predefined constants or validated inputs wherever
possible.

Store Templates Securely If using external .vtl files stored in S3:

Encrypt the files using Amazon S3 encryption.

Restrict S3 bucket access using IAM and bucket policies.

Use Logs for Monitoring Enable AWS CloudWatch logs for AppSync API to monitor:

Unusual activity in requests or resolvers.

Errors that may indicate potential vulnerabilities.

Governance for aggregation of data across tables, views, datastores to ensure that joins are done consistently

In AWS AppSync, aggregating data across multiple tables, views, or data sources can be achieved through GraphQL resolvers. However,
ensuring that these "joins" are done consistently requires careful designing of schema, resolvers, and data sources. Here’s how this can be
governed and implemented effectively:

Coun Governance Implementation

t

1 Use GraphQL Schema to Define The GraphQL schema acts as the contract between API and the clients,
Relationships defining the relationships between types. Relationships in the schema guide
how resolvers perform joins across data sources.

2 Use Pipeline Resolvers for Aggregation AppSync supports pipeline resolvers, which allow to chain multiple resolver
operations within a single GraphQL query. This is useful for performing
consistent joins across multiple data sources.

3 Leverage AWS Lambda for Complex Joins For complex joins or aggregations that require substantial computation or
integration with multiple data stores, AWS Lambda can serve as a resolver.

Lambda can perform joins across databases like DynamoDB, Aurora, or

even external APIs.
Return the aggregated data in a format that matches the GraphQL schema.

4 Enforce Consistency with Resolvers and To ensure joins are consistently governed:
Identity Context
Use $context.identity to enforce user-level access control in all
resolver stages.
Ensure resolvers share a consistent format for input and output data.

5 Optimize with Caching Data Source Level Caching: Use DynamoDB Accelerator (DAX) or RDS
query caching to minimize repeated joins.
AppSync API Caching: Enable caching in AppSync to store frequently
requested aggregated data.
 6 Test and Validate with Stubs Use the AppSync Mapping Template Simulator to validate each stage of
data aggregation. Ensure that:

Resolvers output data consistently.

Each data source's schema aligns with the GraphQL schema.

7 Monitor and Govern with Logging and 1. Enable AWS CloudWatch logs for AppSync to track resolver execution
Metrics and identify inconsistencies.
2. Use AppSync metrics to monitor latency for joins and adjust as needed.

8 Version Control and Schema Evolution As the API evolves:

Use a versionless approach by adding new fields or resolvers for

additional joins, avoiding breaking changes.
Deprecate old joins gradually.

Potential Scenarios

Consistency of responses across channels

Scenario: To guarantee consistency when there are multiple consumers that need the same response from the databases, APIs or
Lambdas that GraphQL can consume

When multiple consumers need the same response from databases, APIs, or AWS Lambda functions that AppSync can query, we can
optimize the architecture by implementing strategies like caching, shared subscriptions, or using persistent queries. Here's how it can be
handled it effectively:

Strategy to implement Description

Caching 1. AppSync Resolver Caching:

AppSync supports server-side caching at the resolver level.
Responses to identical GraphQL queries can be cached for
a configurable duration.
This reduces redundant calls to underlying data sources
like DynamoDB, RDS, or Lambda.
Use Pipeline Resolvers to pre-process or post-process
cached data if needed.
Configure TTL (Time-to-Live) to balance data freshness
and performance.
2. External Caching (e.g., Redis/ElastiCache):
Use an external caching layer for data shared across
multiple services. This can reduce the load on the database
or backend APIs.

Shared Subscriptions 1. AppSync natively supports GraphQL subscriptions to push

real-time updates to multiple clients.
2. When a change occurs in the database or backend, AppSync
automatically sends updates to all subscribed clients.
3. This is particularly effective for use cases like collaborative
applications or dashboards where multiple clients require the
same updates.

Persistent Queries 1. If clients are frequently requesting the same GraphQL query,
use persistent queries.
2. Persistent queries are pre-defined and stored on the server,
avoiding the need to send query definitions repeatedly.
 3. This improves performance and reduces bandwidth usage.

Batch Processing in Resolvers For efficiency, use batch operations:

In DynamoDB, batch read/write operations can handle multiple

requests in a single call.
Lambda resolvers can aggregate requests from multiple
consumers and return a single response, minimizing backend
calls.

Data Source Optimization 1. DynamoDB: Use indexes (GSI/LSI) for quick query responses.
2. RDS: Optimize SQL queries or consider materialized views for
pre-aggregated data.
3. API Gateway or REST APIs: Implement server-side caching
at API Gateway for frequently requested data.

Event-Driven Architectures 1. For highly dynamic or time-sensitive applications, consider

AWS EventBridge or SNS to fan out events to multiple
consumers.
2. AppSync can integrate with these services to distribute data to
multiple clients efficiently.

Rate Limiting and Throttling To prevent excessive load on backend systems, implement rate
limiting or throttling mechanisms at the AppSync level or the
backend.

Dependencies and Impacts

What are the dependencies and impacts?

AWS Services

Design Decisions
What design decisions may be required?

Decision # Decision Options Selected option Justification

description

D01 Decision is required 1. AppSync(Grap Please refer the Pros mentioned in Options
if AWS AppSync, a hQL) Table
fully managed 2. REST API
Service providing
Serverless GraphQL
API solutions can be
used as a BFF Layer

AppSync Proof of Concept

The POC should demonstrate key features of AppSync and its integration with AWS services. Here are some features and capabilities
should be considered
Count Core AppSync Features

1 GraphQL API Setup: 1. Design and deploy a GraphQL schema with queries, mutations, and subscriptions.
2. Highlight the ease of defining relationships between data entities (e.g., one-to-many, many-to-
many).

2 Data Source Connect AppSync to various AWS data sources:

Integration:
DynamoDB: Showcase CRUD operations using resolvers.
Aurora Serverless or RDS: Implement SQL queries/mutations through Aurora or RDS.
AWS Lambda: Use Lambda functions to perform complex business logic.
Elasticsearch/OpenSearch: Demonstrate search capabilities with AppSync.

3 Subscriptions: 1. Implement real-time data updates using GraphQL subscriptions.

2. Example: A real-time dashboard or chat application.

4 Pipeline Resolvers: 1. Use pipeline resolvers to chain multiple operations (e.g., combining data from multiple
sources).
2. Example: Fetching additional data after a mutation.

5 Caching: 1. Enable AppSync caching to demonstrate performance improvements for repeated queries.
2. Configure TTL for query caching.

Security and Access Control

6 Authorization 1. Showcase the use of different authorization modes:

Modes: API Key for simple use cases.
AWS IAM for secure, role-based access.
Cognito User Pools for user authentication.
OIDC Providers for third-party auth integration.
2. Implement fine-grained access control using GraphQL directives like @auth .

7 Field-Level Security: Use resolver-level permissions to restrict access to specific fields or data.

Performance and Scaling

8 Scalable Demonstrate how AppSync integrates with scalable backend services (e.g., DynamoDB with on-
Architecture: demand capacity).

9 Offline Sync: 1. Implement offline capabilities for mobile/web apps using the AWS Amplify SDK with AppSync.
2. Example: Add and update data offline, and sync changes when reconnected.

10 Monitoring and 1. Enable AppSync logs in CloudWatch for tracking queries and resolving issues.
Logging: 2. Use X-Ray for tracing backend performance and latency.

Advanced Integrations

11 Custom Data 1. Create a custom data source to fetch data from a third-party API or another non-AWS service.
Sources: 2. Example: Fetching external weather or stock data.

12 Event-Driven Use AppSync with EventBridge or SNS to trigger downstream processes.

Workflows:
Risks and Opportunities
What are the risks or opportunities? Use the Risk Assessment Matrix to assess Likelihood, Consequence and Rating

Risk Description Cause Impact Likelihood Consequenc Rating Mitigation

e

R01 GraphQL Security Low Unlikely Minor 4 Please refer

Query Risks Mitigation
Templates

Solution Design Estimate

What are the time or effort estimates to produce the conceptual solution design?

Solution Design is not required

Security Impact Assessment

Consult Cyber Security (Chris Martyn or Sharath Chander) to confirm the impact

Security Impact ( PURPLE = Extreme | RED = High | AMBER = Medium | GREEN = Low)

PURPLE - Handles PII Data

Third-Party Risk Assessment

<<If the Design Direction is to use a specific third party technology vendor/platform engage @Jane Tran and/or @David Huynh to
confirm the Third Party Risk Assessment in OneTrust>>

Not Applicable - AWS Managed Services

Conceptual Model
Provide a conceptual model that covers the data elements that will be impacted by this solution. A conceptual model serves as a high-level
representation of the organisation's data structures and relationships. This will help in the understanding of the data domain of change. The
conceptual model is described here. The designers of the Design Direction will need to consult with the Data Design Authority or Authorities
for the domains of change. The DDAs are listed here.

Not Applicable

Data Classification
What is the classification of the data the solution manages?

( HIGHLY CONFIDENTIAL | CONFIDENTIAL | INTERNAL | PUBLIC )

Refer: IDP Standards | Data Classification Standards

CONFIDENTIAL

AWS AppSync GraphQL APIs will handle Confidential PII data only as a Data Carrier. It does not manage or store any data.
Data Impact Assessment
If the solution process/ingest/publish highly confidential or confidential data:
How is RTBF going to be managed?
AWS AppSync is a data carrier service which handles Confidential data as well but its is encrypted as per IDP guidelines.
RTBF is managed by respective line of business as there is no data retention involved

What data retention period does the data have? Use IDP Standards | Enterprise Data Archiving and Retention policies
Not Applicable - No Data Retention

What data models are impacted by this solution?

Not Applicable

Business Continuity Management

How does the solution address the DR Category, Availability, RPO and RTO? Use IDP Standards | Disaster Recovery

Delivery Estimate
What are the time or effort estimates to deliver the solution?

Architecture Principles Alignment

Reference all Architecture Principles Design Principles and add commentary to explain how the solution aligns to or the justification for
misalignment.

Note: Principles are the guardrails for building solutions that are consistent and standardised - where feasible, practical and appropriate. It
must be stressed that they are also not policy so if there is good reason (business and/or technical) for deviation then this can be discussed
through the governance process and an informed decision made on whether to grant an exemption.

Legend Meaning Comments

:check_mark:
Fully Aligned Briefly explain how the solution is fully aligned.

:cross_mark:
Not Aligned Provide justification as to why the solution is not aligned.

:yellow_circle:
Partially Aligned Briefly explain how the solution is partially aligned, with justification.

:question_mark:
More information needed Explain what further clarification is required.

:info:
Not Applicable Briefly explain why this principle is not applicable.

Expand and complete the following Principles Alignment section:

Principles Alignment

Principle Domain Principle Aligned Notes

Solution Principle 001: Primacy of Principles

Solution Principle 002: Maximise Benefit to the Enterprise

Solution Principle 003: Designs will not include technologie

s that are legacy or in a contained state, nor introduc
e tech debt/regret spend.

Solution Principle 004: Protection of Intellectual Property

Solution Principle 005: Automation

Solution Principle 006: Designs will facilitate agility and ad

aptability

Solution Principle 007: Sustainability v2

Solution Principle 008: Compliance with Law

Solution Principle 009: Operational Log Aggregation and M

onitoring

Business Principle 101: Requirements-Based Change

Business Principle 102: Business Continuity

Data Principle 201: Data Accuracy, Availability, and Qu

ality Management

Data Principle 203: Enterprise Data Standardisation, D

efinitions and Model

Data Principle 204: Data is Classified and Protected

Data Principle 205: Data Replication is achieved with fu

nctional integration

Data Principle 206: Data Retention and Archiving

Data Principle 207: Master Data and Reference Data M

anagement

Data Principle 208: Data for Reporting

Data Principle 209: Gen AI (Generative Artificial Intellig

ence) technology based solutions and Gen AI model
s shall follow the Design Governance process gover
ned for changes throughout their lifecycle

Integration Principle 301: Event Driven Architecture

Integration Principle 302: Real-Time or Near Real-Time

Integration Principle 303: Batch Operations

Integration Principle 304: Loose Coupling

Integration Principle 305: Service Orientation

Integration Principle 306: Integration services shall be statele

ss and idempotent

Integration Principle 307: Data Exchange shall use a preferre

d method

Integration Principle 308: Third-party data exchange

Security & Privacy Principle 401: Collection and Storage of PI inform

ation
Security & Privacy Principle 402: Security Information and Event Ma
nagement

Security & Privacy Principle 403: Designs meet the Security Control
Requirements

Security & Privacy Principle 404: Authorisation uses Role and Attribu
te Based Access Control

Security & Privacy Principle 405: Data is encrypted in transit and at r

est

Security & Privacy Principle 406: Externalise Identity and Access Ma

nagement

Security & Privacy Principle 408: Privacy Principles

Application Principle 501: Technical Orchestration

Application Principle 502: Focus on Differentiation

Application Principle 503: Re-use of Solutions and Platforms

Application Principle 504: User Centric Design

Infra & Ops Principle 601: Infrastructure deployment model hi

erarchy

Infra & Ops Principle 602: Public Cloud Infrastructure Provide

r

Infra & Ops Principle 603: IDP Technology Standards

Infra & Ops Principle 604: Cost Optimisation

Infra & Ops Principle 605: Enterprise Non Functional Require

ments

Infra & Ops Principle 606: Migration Principles

Infra & Ops Principle 607: Technology Version Currency

Infra & Ops Principle 608: Disaster Recovery and Business C

ontinuity v2

Infra & Ops Principle 609: Infrastructure as Code