1. Available regions

The PersonalisationHub stack supports deployment in all current and future commercial AWS Regions, excluding AWS GovCloud (US) and AWS China Regions.

This includes but is not limited to:

• North America: US East (N. Virginia, Ohio), US West (Oregon, N. California), Canada (Central)

• Europe: Ireland, Frankfurt, London, Paris, Milan, Zurich, Stockholm, Spain

• Asia Pacific: Singapore, Tokyo, Seoul, Sydney, Mumbai, Jakarta, Hong Kong, Osaka, Hyderabad, Melbourne, Auckland (New Zealand - coming soon)

• Middle East & Africa: UAE, Bahrain, Cape Town, Tel Aviv

• South America: São Paulo

2. Network Configuration

The deployment provisions a fully managed, secure network environment to support multi-service components of the PersonalisationHub stack.

2.1 Simplified Deployment Workflow

The deployment workflow is designed to provision all required network components automatically, without requiring the user to configure low-level networking details manually. These components include:

• Virtual Private Cloud (VPC)

• Public and private subnets across multiple Availability Zones

• Internet Gateway (IGW) and NAT Gateway

• Route Tables and Route Table Associations

• Network Access Control Lists (NACLs)

• Security Groups tailored per service (e.g., RDS, EKS, ElastiCache)

All configurations follow AWS security best practices and are referenced in the Architecture Diagram already

2.2 Key Networking Elements

The network topology is depicted in the Architecture Diagram and is created automatically as part of the installation process.

3. Instance Metadata Service (IMDS) Configuration

The solution is designed to support Instance Metadata Service Version 2 (IMDSv2), in accordance with AWS security best practices.

3.1 Compliance Overview

3.2 Recommendation

Customers can disable IMDSv1 and enforce IMDSv2 for all EC2-based components during or after deployment by modifying the EC2 metadata options. The application and installer do not rely on IMDSv1, and all AWS SDKs used are compatible with IMDSv2.

3.3 Support

If you prefer to enforce IMDSv2 during initial deployment or need help updating metadata settings on existing EC2 instances, please contact our support team for guidance.

4. IAM Roles and Policies

IAM resources are provisioned automatically by the CloudFormation stack. These roles and policies enable secure infrastructure provisioning and service operations during installation and runtime.

Note: The names below are logical identifiers. Actual resource names in your AWS account may vary depending on stack name, region or account configuration.

4.1 IAM Roles & Instance Profiles

4.2 Managed IAM Policies

4.3 Inline IAM Policies (Attached to EC2Instance Role)

5. Access Credentials and KMS Keys

The deployment provisions encryption keys and, where necessary, limited-scope credentials to support secure infrastructure provisioning.

Note: These resources are automatically created and managed by the stack. You do not need to manually create or rotate these keys.

5.1 IAM Access Key

5.2 KMS Keys

6. Secrets Management

The deployment securely stores and manages sensitive configuration values such as database credentials and API tokens without using AWS Secrets Manager.

6.1 Storage and Handling

• Secrets are stored in the installer’s internal configuration files and provisioned securely onto the EC2 instance or EKS workloads during deployment.

• These files are kept in restricted-access paths and not exposed to users or publicly accessible systems.

• For long-running services (e.g., database, MSK, ElastiCache), secrets are injected as environment variables or mounted files within containers using secure orchestration logic.

6.2 Access Control

• Only specific IAM roles (e.g., EC2InstanceRole, ServiceAccountRole) are granted permission to read the secrets at runtime.

• No hardcoded secrets are stored in version control or exposed in logs.

6.3 Maintenance

• At this stage, the deployment does not provide SSH-level access or in-guide instructions for manual secret rotation.

• If secret updates are required, users may contact the support team or await upcoming functionality to support secure rotation workflows.

7. Customer Data Storage

The deployment guide identifies where customer-sensitive data is stored during normal system operation. These include user profile data, media uploads, diagnostic logs, and genetic report results.

7.1 Primary Storage Locations

7.2 Access Control & Protection

• All storage services are deployed within private subnets (where applicable) and protected via security groups and IAM policies.

• Public access to sensitive data is explicitly disabled.

• Encryption at rest and in transit is enabled using AWS-managed KMS keys.

8. Data Encryption

The deployment ensures that all customer data is encrypted both at rest and in transit, using a combination of AWS-managed and customer-managed encryption services. This includes S3, EBS, RDS, ElastiCache, and MSK resources.

8.1 Encryption at Rest

8.2 Encryption in Transit

• TLS encryption is enabled for all communication between services that support it (e.g., RDS, MSK, ElastiCache).

• All external access endpoints (e.g., web access to PersonalisationHub) are served over HTTPS using a valid TLS certificate via AWS ACM.

• Internal communication between containers and AWS services is secured through private VPC connectivity and IAM-based authentication.

8.3 Disk-Level Encryption (LUKS)

• The deployment does not currently use LUKS or custom disk encryption for the EC2 root volume.

• All persistent storage volumes are protected using AWS-native encryption mechanisms (e.g., EBS with KMS).

9. Public Resource Disclosure

The deployment includes a limited number of publicly accessible resources, such as:

9.1 Public Application Load Balancer (ALB)

• Purpose: Serves as the main public entry point for the Personalisation Hub application.

• Access Level: Publicly accessible over HTTPS (port 443).

• Source: Deployed in public subnets with security groups allowing inbound access from the Internet.

• DNS Mapping: Typically mapped to a subdomain via Route 53 or a third-party DNS provider.

9.2 Amazon S3 Bucket with Public Read Access

• Purpose: Stores uploaded assets and media files, a subset of which are intentionally made publicly accessible (e.g., images, thumbnails, or publicly viewable content).

• Access Level:

  • The bucket is configured with a public-read ACL.

  • However, only specific objects (based on application logic or upload path) are exposed for unauthenticated access.

  • Other content remains private by default.

• Security Controls:

  • Object key naming and access logic are implemented at the application layer to control public vs. private access.

  • Public Access Block settings are reviewed and monitored to prevent unintentional exposure.

9.3 ACM + Route 53 (or External DNS)

• Purpose: Provides TLS/SSL encryption and DNS routing for the application.

• Access Level: Public DNS entries (e.g., ph.yourdomain.com) resolve to the public ALB.

• Note: DNS configuration is typically performed by the customer, using Route 53 or their preferred DNS provider.

9.4 Internet Gateway & NAT Gateway

• Purpose:

  • The Internet Gateway enables public resources (e.g., ALB) to receive traffic from the Internet.

  • NAT Gateway enables outbound Internet access for private subnets (e.g., EKS nodes, backend services).

• Access Level:

  • Internet Gateway is used only for explicitly public resources.

  • NAT Gateway is not directly exposed but facilitates secure egress from private components.