AWS Public Sector Blog

AWS accelerates digital public infrastructure adoption with automation

AWS branded background design with text overlay that says "AWS accelerates digital public infrastructure adoption with automation"

Digital public infrastructure (DPI) is a phrase regularly referenced by public sector institutions, strategic influencers, social sector organizations, nonprofits, and global CEOs as a transformational approach to leapfrogging citizen progress at scale. Countries such as Brazil, India, Singapore, Australia, and Thailand have all built and scaled solutions based on DPI.

The Centre for Digital Public Infrastructure (CDPI) defines DPI as: “A set of technology building blocks powered by interoperable open standards or specifications operated under a set of enabling rules with open, transparent, and participatory governance to drive innovation, inclusion, and competition at scale.” The Digital Public Goods Alliance (DPGA) is a multi-stakeholder United Nations (UN)–endorsed initiative that facilitates the discovery and deployment of open source technologies, bringing together countries and organizations to create a thriving global ecosystem for digital public goods and helping to achieve sustainable development goals.

When implemented in a real-time production environment that serves a particular citizen-centric use case, DPI-based solutions are often referred to as digital public goods (DPG). The scope of such solutions spans academic institutions, professional colleges, building approvals, fire no objection certificates (NOCs), citizen identity verification services, micro and macro financial institutions, and much more. Various DPGs for such use cases are available in open source domains, and countries such as India encourage the adoption of DPGs by other countries. India has seen significant success with some of its Digital Public Infrastructure (DPI) platforms, including CoWIN, a system for managing COVID-19 vaccinations; UPI, a real-time digital payments system; DigiLocker, a secure platform for digital document storage and verification; and DIKSHA, a national platform for educational resources.

Automating DPI and DPG deployments on AWS

Although DPIs are proven accelerators for digitally rolling out citizen-centric services across the globe, there are practical challenges acting as a barrier to their adoption by public sector institutions. Some common challenges include lack of access to skilled resources or the need for better security and observability. Public sector institutions, without fail, look for solutions that are packaged for rapid prototyping, are readily available, and can scale in the future as their adoption increases. There are compliance and budgetary requirements to adhere to.

Amazon Web Services (AWS) offers numerous advantages, including fostering rapid adoption and experimentation with different building blocks. Automating these deployments on AWS is crucial for several reasons:

  1. Rapid adoption – The deployment automation of DPGs makes it straightforward for builders to swiftly dive into experimenting with DPGs for their unique use cases. This eliminates the hassle of dealing with initial setup and configuration in the development environment, making the process smooth and efficient. Additionally, packaging also facilitates rapid development of proofs of concept (POCs), minimum viable products, and prototypes because the deployment provides builders with the entire DPG,enabling quick building of their use cases.
  2. Skill enhancement – Many public sector institutions want to enhance their skills in deploying the stack on AWS. Automating the process for deploying DPGs streamlines deployment and reduces the need for highly skilled resources.
  3. Budget constraints – Public sector organizations are often constrained by fixed budgets, making it challenging to hire highly skilled personnel. Automating the deployment helps them achieve their goals within budget constraints.
  4. Scalability – When deployed, DPGs almost always require scaling. Standardizing on a scalable and resilient architecture deployment on AWS becomes necessary to meet these scaling needs effectively.

In this post, we explore how AWS enables the automation of deploying a DPI-based solution stack. We highlight Sunbird RC (Registry and Credentials) as a real-world DPG building block. The following example provides an overview and execution of the packaging available in the Sunbird community GitHub repository for provisioning required AWS services and deploying Sunbird RC services. The solution leverages the AWS Cloud Development Kit (AWS CDK) for infrastructure-as-code (IaC) capabilities. It utilizes Amazon Elastic Kubernetes Service (Amazon EKS) for orchestration, along with Amazon RDS for database management and other services defined in the reference architecture section. Helm is used as the Kubernetes package manager.

Overview of Sunbird RC

Sunbird RC is a low-code framework to enable organizations to rapidly build next generation electronic registries and verifiable credentials. Sunbird RC is listed as a global DPG within the DPGA registry. Sunbird RC is the core engine within DIVOC, a globally recognized DPG for vaccination and health credentialing. Sunbird RC is also part of India’s massively adopted DIKSHA school education platform used at population scale.

Sunbird RC can be used to quickly build numerous national registries of individuals, objects, and entities for a variety of domains. It facilitates enrollment, authentication, data ownership, search, issuance and management of verifiable credentials, claim attestation flows between user and attester, and sharing of credentials with user consent, among others. It provides microservices to issue portable standard schema-based World Wide Web Consortium (W3C) verifiable credential (VC)–compliant credentials with attestation and verification flows. These credentials can be printed with QR codes, translated into many languages, and are instantly verifiable.

Some common examples of digital identities that Sunbird RC can manage are doctors, patients, and hospitals IDs; school teacher, student and school IDs; patient health certificates; academic and skill certificates; employment certificates; property ownership certificates; birth and death certificates and any proof of work; proof of ratings; and proof of earnings. The following image from Sunbird.org illustrates these possibilities.

Figure 1. Digital identities that Sunbird RC can manage. (Image sourced from Sunbird RC, used under CC BY-SA as per Terms of Use.)

Sunbird RC opens up many possibilities for addressing real-world business problems. The functionalities can be extended to a range of agencies and organizations that need to store a single source of truth and validating entities against the single source of truth. This application can be a direct fit to many organizations, including doctor and healthcare facilities registrations; educational institutes; national and local citizen skill repositories; real-estate residential-, commercial-, and government-owned properties; citizenship and identity registries; and farm and industrial corporation registries.

The following image illustrates the process flow for implementing the solution.

Figure 2. The process flow for implementation goes from entity onboarding (registry events) to issuing verifiable credentials (attestation and claims) to sharing VCs and verifying VCs (consent and discovery). (Image sourced from Sunbird RC, used under CC BY-SA as per Terms of Use.)

Reference architecture for deploying Sunbird RC on AWS 

The Sunbird RC 2.0 solution is available for deployment on AWS with a well-defined reference architecture. This architecture outlines the recommended approach for setting up Sunbird RC on AWS, covering infrastructure provisioning, networking, storage, and security considerations. A deployment option simplifies the setup process, making it easier to get started.

Figure 3 below illustrates the key components and their interactions within the AWS environment.

The following AWS services are used in the reference architecture to operate the Sunbird RC registry and credentialing services and are included in the deployment package:

For scaled deployments, Sunbird RC uses auxiliary services including Redis, ElastiCache, and Kafka for scalability. You can also consider using their managed offerings from AWS, although these are not included in the deployment:

Sunbird RC deployment automation using AWS CDK

Deploying Sunbird RC on the AWS is by using automation scripts available in the Sunbird RC GitHub repository. This automation uses AWS CDK for provisioning infrastructure and Helm charts for deploying services on an Amazon EKS cluster, offering a simplified approach to get Sunbird RC up and running quickly.

Developers can use the automation package to efficiently deploy the Sunbird RC components without manual configuration. By providing reusable AWS CDK templates and Helm charts, this deployment provides a consistent, repeatable process that organizations can rely on when setting up registries and credentialing systems on AWS.

The deployment package simplifies provisioning, allowing builders to start DPG experiments with default service configurations. However, this setup is for demonstration purposes only and is not production-ready. For a secure production deployment, follow AWS security best practices to verify data protection, observability, and threat detection:

Each AWS CDK stack focuses on a specific set of tasks, allowing independent development, testing, and scaling of components without affecting the overall architecture. This design, shown in the following screenshot, not only makes the deployment efficient but also enhances maintainability.

Figure 4. AWS CDK execution flow for deploying Sunbird stack.

The following table describes the stacks. For more detailed information about the components within each stack, refer to the Sunbird RC AWS CDK repository.

Stack Description
vpcstacksbrc2 Configures the Amazon VPC connection, including subnets and route tables, establishing a secure and isolated network foundation.
rdsstacksbrc2 Sets up an Amazon Aurora PostgreSQL cluster to fulfill Sunbird RC’s database requirements.
eksstacksbrc2 Deploys an EKS cluster running on EC2 instances, enabling scalable Kubernetes infrastructure for the deployment.
vaulthelmstacksbrc2 Deploys HashiCorp Vault on the EKS cluster to securely manage and distribute sensitive secrets.
vaultinithelmstacksbrc2 Initializes Vault, handling its setup and configuration as a supporting stack, providing proper integration with the EKS environment.
sunbirdrc2helmStacksbrc2 Deploys Sunbird RC services through a Helm chart, automating the setup of essential configurations and services on the EKS cluster.

Helm charts for Sunbird RC Services

To deploy Sunbird RC services on the EKS cluster, Helm charts are used to manage and configure the various components needed to run Sunbird RC and are part of the automation project. These charts mean that each service is deployed with the correct configurations, making the deployment process smooth and scalable.

During the deployment stage, AWS CDK invokes these Helm charts, allowing for seamless integration and automation of the deployment process. The necessary resources are provisioned and configured according to the specified settings, enhancing the overall efficiency of the deployment.

Running Sunbird RC deployment installer

The deployment installer offers reusable and configurable (through environment variables) scripts for setting up Sunbird RC in different AWS accounts and Regions. Each deployment will produce consistent results with similar endpoints.

Prerequisites

To perform the solution described in this post, you need to have the following prerequisites in place:

  1. AWS account – An AWS account is required to deploy AWS CDK stacks, including the necessary AWS Identity and Access Management (IAM) permissions for the AWS services included in the reference architecture.
  2. AWS Command Line Interface (AWS CLI) – The AWS CLI needs to be configured with the AWS account. The AWS CLI must be installed and configured on the developer’s machine with the appropriate AWS account access. Alternatively, AWS CloudShell can be used as a pre-configured environment.
  3. Amazon EC2 bastion host: Provisioned in the VPC where EKS cluster is deployed for accessing aprivate only Amazon EKS API
  4. Kubectl client – Install Kubectl client on the EC2 bastion host to access Amazon EKS APIs.
  5. Public domain and subdomain – You must obtain a public domain or create a subdomain if you already have a domain to access Sunbird RC Registry and Keycloak services.
  6. Public SSL certificate – Use AWS Certificate Manager (ACM) to obtain a public SSL certificate for your domain or subdomain. Alternatively, you can import a public SSL certificate issued by a third party into ACM.

Requesting a public SSL certificate through ACM

Identify a domain or subdomain you intend to use for Sunbird RC services as outlined in the prerequisites.

To obtain an SSL certificate through ACM, follow the steps provided in the official ACM documentation.

After a certificate is issued, copy the certificate Amazon Resource Name (ARN) to be used in the environment variables. The certificate ARN follows this format:

arn:aws:acm:ap-south-1:<aws-account-id>:certificate/<identifier>

Bootstrapping CDK

Bootstrapping is the process of preparing an environment for deployment. Bootstrapping is a one-time action that you must perform for every environment that you deploy resources into.

Bootstrapping provisions resources in your environment such as an S3 bucket for storing files and IAM roles that grant permissions needed to perform deployments. These resources get provisioned in an AWS CloudFormation stack called the bootstrap stack. It is usually named CDKToolkit. Like any CloudFormation stack, it will appear in the CloudFormation console of your environment after it has been deployed.

Install TypeScript AWS CDK globally:

npm i -g typescript
npm I -g aws-cdk

Clone the Sunbird RC CDK repository and install dependencies:

git clone https://github.com/Sunbird-RC/aws-cdk.git
cd aws-cdk
npm i

Bootstrap the CDK environment in your AWS account:

cdk bootstrap aws://ACCOUNT-NUMBER-1/REGION-1

Update the .env file from the Sunbird RC AWS CDK repository with the required environment variables. Variables that are marked as Required must be provided. Fields without this label have default values but can be modified if needed.

Environment Variable

Default Value

Description

Required

REGION

ap-south-1

AWS Region.

No

ACCOUNT

123456789123

AWS account number.

No

CIDR

10.20.0.0/16

VPC CIDR block.

No

MAX_AZS

2

Number of Availability Zones.

No

RDS_USER

postgres

Database username.

No

RDS_PASSWORD

None

Database password for RDS_USER.

Yes

EKS_CLUSTER_NAME

ekscluster-sbrc2

EKS cluster name.

No

ROLE_ARN

None

EKS mastersRole ARN for super-user access.

Yes

RC_EXTERNAL_DOMAIN

None

Domain to access registry and Keycloak.

Yes

CERT_ARN

None

SSL certificate ARN for the domain.

Yes

SUNBIRD_RC_MODULES_CHOICE

RC

Modules to install: R, C, or RC (default).

No

Deploying CDK

After updating the .env file, use the following AWS CDK commands to deploy the required resources.

Step 1: Listing available CDK stacks

Before deploying, list the available CDK stacks to confirm the stack names. You should see a complete list of CDK stacks explained in the earlier section.

cdk list

Expected output:

vpcstacksbrc2

rdsstacksbrc2

eksstacksbrc2

vaulthelmstacksbrc2

vaultinithelmstacksbrc2

sunbirdrc2helmStacksbrc2

Step 2: Deploying CDK stacks

You can deploy either individual stacks or all stacks at once.

Option 1: Deploying all stacks

To deploy the entire setup and automatically handle dependencies:

cdk deploy --all

Note: It may take several minutes for all stacks to be deployed.

Option 2: Deploying individual stacks

If you need to deploy a specific stack, follow the order in the following table to respect dependencies:

Stack name Deployment command Dependencies
VPC stack cdk deploy vpcstacksbrc2 None
RDS stack cdk deploy rdsstacksbrc2 vpcstacksbrc2
EKS stack cdk deploy eksstacksbrc2 vpcstacksbrc2
Vault Helm stack cdk deploy vaulthelmstacksbrc2 eksstacksbrc2
Vault init Helm stack cdk deploy vaultinithelmstacksbrc2 vaulthelmstacksbrc2
Sunbird RC Helm stack cdk deploy sunbirdrc2helmStacksbrc2 vaultinithelmstacksbrc2, rdsstacksbrc2

Step 3: Verifying deployment

After deployment is complete, verify the resources, such as the Amazon EKS cluster, Amazon VPC, and Amazon Aurora PostgreSQL-Compatible Edition instance, in the AWS Management Console. You can also check CloudFormation service for a list of all stacks created by the CDK.

Configuring kubectl with Amazon EKS

The EKS cluster API service endpoint is restricted to private access, meaning it can only be accessed within the VPC where Sunbird RC resources are deployed. As highlighted under the prerequisite section, ensure you have an Amazon EC2 instance in the same VPC to run the AWS CLI and kubectl tools.

Note: The ROLE_ARN variable defines the IAM role that CDK uses to grant super-user access to Amazon EKS resources. If you need to grant access to additional IAM users, groups, or roles, create the necessary EKS access entries accordingly.

To verify that Sunbird RC services are running as expected, configure the kubectl CLI to interact with your EKS cluster.

aws eks --region <your-region> update-kubeconfig --name <EKS_CLUSTER_NAME>

Replace <your-region> with your AWS Region (for example, ap-south-1) and <EKS_CLUSTER_NAME> with the EKS cluster name specified in your .env file (default: ekscluster-sbrc2).

Listing Sunbird RC 2.0 pods in the sbrc2 namespace

To view the status of the pods in the sbrc2 namespace, run:

kubectl -n sbrc2 get pod

Expected output:

You can also run a few more kubectl commands to further verify the Kubernetes objects created by the AWS CDK installer and Helm charts:

kubectl -n sbrc2 get ingress        # Inspect ingress resources

kubectl -n sbrc2 get deployment     # List deployments

kubectl -n sbrc2 get service        # Check services

Post-installation configuration for Sunbird RC registry service

The AWS CDK also handles the post-installation configuration necessary to prepare the Sunbird RC registry service so that users don’t need to follow any manual steps. This process includes the following key steps:

  1. Importing Sunbird RC realms – The realms for Sunbird RC are imported into the Keycloak service using this JSON file.
  2. Generating admin client secret – The `KEYCLOAK_ADMIN_CLIENT_SECRET` required for the Sunbird RC admin API is generated in Keycloak. This secret is then imported into a Kubernetes secret, which gets loaded as an environment variable in the registry pod.
  3. Vault initialization – The Vault server is initialized in High Availability (HA) setup offering three peers pod replica for Sunbird RC services and to unseal the Vault for regular functions.
  4. Accessing services – The Sunbird RC registry API and Keycloak are accessible through a single public-facing Application Load Balancer (ALB).The /auth path is redirected to the Keycloak service, and the root path directs traffic to the Sunbird RC Registry service.Users can obtain the ALB endpoint either through the AWS Management Console or by using the Kubectl client to list the ingress under the sbrc2 namespace, for example,kubectl -n sbrc2 get ingress

Testing Sunbird RC APIs

Sunbird RC provides a comprehensive set of APIs for managing registry and credentialing services. Instead of detailing each API here, we recommend referring to the official Sunbird RC API Reference for complete documentation.

Key API categories include:

  • Registry APIs – Manage entity registration, schema definition, attestation, claims, among others.
  • Credential APIs – Enable credential issuance and management.

For testing these APIs, you can use tools like Postman or cURL to interact with the endpoints. Refer to the official API Reference documentation for request formats, authentication details, and example payloads.

Cleanup

AWS CDK also helps you to automate the release of the resources you deployed in the stack. Rather than manually deleting the resources, you can delete the complete AWS CloudFormation stack using a single command. When you delete the stack, resources in the stack will be destroyed (unless they were configured with a DeletionPolicy of Retain).

During stack deletion, this command will output progress information similar to cdk deploy behavior.

To remove all AWS resources created in this solution, run the CDK destroy command:

cdk destroy --all

Conclusion

DPI has emerged as a powerful strategy to drive inclusive and sustainable economic growth. DPI-based solutions are effective for public sector institutions in providing citizen services through digital technology. However, the barriers to adoption of DPI remain to be addressed, particularly when various public sector institutions across the globe lack the necessary funds and skilled resources to implement and run the solution. Adding to this challenge is the complexity around scalability and resiliency that DPI solutions need to operate at a large scale.

AWS addresses these issues by providing the necessary scalability and resiliency at the platform level. Similarly, by automating deployments on AWS, lack of skilled resources and higher cost no longer remain a barrier to the adoption of DPI-based solutions.

If you’re building DPI solutions and find implementation complexity a challenge, AWS offers a suite of services to simplify deployment and management. With tools like AWS CDK, you can automate infrastructure provisioning, ensuring a robust, scalable, and secure foundation. Additionally, AWS provides managed services, security best practices, and cost optimization tools to accelerate adoption. For guidance, connect with your AWS Solutions Architect or contact us today.