Dalet Pyramid - Operational Requirements for Customer's Dedicated Deployment

(Revision 1.5, July 2024)

Product specifications and availability are subject to change without notice. Dalet is a registered trademark owned by Dalet. All other brands and trademarks are those of their respective owner.

Disclaimer

Dalet Pyramid service has been designed with Cloud-native approach.

At the time of this writing, Dalet Pyramid can be offered :

• As a pure Private SaaS service, fully hosted and operated by Dalet. This option will remain over time and will always be the recommended approach, maximizing the Service Level Agreements (SLA) and level of service delivery quality Dalet can provide.
• As a customer-hosted service, while still operated by Dalet, as Managed Services. Operating on a shared-responsibility basis, this approach is known to be less efficient than its pure Private SaaS service counterpart.
• As a customer-hosted service, fully operated and self-maintained by the customer, with the help of Dalet support teams, labelled as Supported. 

When customer-hosted, the customer will have two distinct hosting options:

• • On Cloud, on a supported dedicated Cloud provider account of his choice (currently limited to AWS).
  • On-Premises

Regardless of these deployment topologies, Pyramid may require connection with Dalet Galaxy system(s), which may:

• be newly installed on Cloud environments
• already exists, generally deployed on customer's premises.

This document provides the Pyramid traditional operational requirements with a customer-hosted Galaxy. The exact requirements may however vary, depending on the nature of the infrastructure and customer’s private security policy and Dalet Operations team is able to accommodate to some specific variations.

Please note that any deviance from the usually offered and supported requirements is subject to either increase the cost of the delivered solution as subject to customization and/or lower down the global quality of the service, SLA and capacity to provide accurate and timely customer support.

Operational Responsibilities

Customer-dedicated deployments require a shared-responsibility operational approach with clearly defined and respected boundaries between customer and Dalet IT organizations. Dalet services can be contractually offered from 3 distinct ways:

• The default Supported way, where:
  • Customer is in charge of providing (and ensuring reliability, durability and scaling) of the underlying infrastructure, including but not limited to networking, computing and storage resources. It covers both metal servers, virtualization stack and, to some extent, orchestration stack, if required.
  • Customer is in charge of delivery, reliability, scalability, persistence and operational maintenance of the underlying database.
  • Dalet is in charge of supporting the deployed service itself, including its maintenance and upgrade processes. Dalet’s responsibility is limited to a per customer request, support delivery activity, offering software maintenance and software updates delivery.
  • Customer oversees the day-to-day monitoring and right-behavior of the service and reach out to Dalet’s customer service in case of incapacity from the service to operate properly.
• The extended Managed Services way, where 24x7 monitoring, alarming, and troubleshooting of the Dalet's service is delegated by customer to Dalet’s Cloud Operations teams, to the extent that:
  • The underlying infrastructure remains the customer’s responsibility and Dalet will not intervene to mitigate out-of-control issues. Customer's responsibility remains up to computing stack (physical or virtual). Orchestration stack and database remain deployed and maintained by Dalet teams.
  • The proper remote administration capabilities must be provided by the customer to Dalet for the service to be properly operated.
• The Private SaaS way, where:
  • Dalet provides a complete dedicated Cloud hosting service on behalf of the customer, ensuring a proper redundancy, high-availability and scalability of the solution.
  • Provides offloads the customer from all operational troubles, providing the same 24x7 coverage than offered by the Managed Services subscription
  • Provides an additional level of SLAs, platform's scrutiny and security awareness.

The matrix below summarizes the split of roles and responsibilities between Dalet and its Customer:

For hybrid Pyramid/Galaxy deployments, the following responsibilities apply:

Pyramid Typical Deployment Overview

Full SaaS

Dalet Pyramid "AWS-hosted reference" key Cloud infrastructure components are usually deployed the following way:

• 1 region with 3 Availability Zones (AZs) or assimilated, across a shared L2/L3 network.
• 1 frontal classic load balancer, accepting users traffic and request and routing them backend to Pyramid's backend. The actual SSL termination is performed at Pyramid's layer.
• 1 multi-AZ Kubernetes EKS cluster, running Pyramid Cloud-native applications spread evenly amongst AZs and workers.
• Legacy Windows instance(s) with Galaxy backend.
• Postgres SQL on RDS
• Media files are stored in region based S3 buckets. No cross-region replication is configured. S3 is configured with AES-256 server-side encryption.

Pyramid's platform application logs and key technical metrics are sent over Dalet's global Control Tower for large-scale monitoring and possible troubleshooting.

For Pyramid to run properly, a few things are expected from customer side:

• an Identity Provider, supporting Active Directory (AD), OpenID or SAML protocols.
• optionally, an existing Galaxy remote site with its associated storage.

In most cases, it is unlikely that such services are configured to be publicly exposed over Internet, hence can't be connected to Pyramid's instance.

Multiple options can be considered for that purpose (see next section) but both aim at providing a secure communication tunnel between customer premises on Cloud instances. In most cases, Dalet offers to support customers with a virtualized network equipement (Iris Gateway), providing such connectivity means, and ensuring that Dalet provides and end-to-end solution.

The following diagram provides an example overview of such topology.

Hybrid SaaS

An alternative hybrid deployment exists, in the case customer requires to:

• optionally keep control of the networking stack and associated resources. The customer is then in charge of providing the networking remote access capability, allowing Pyramid to reach out on-premises resources. It is up to the customer to define the scope of access, for instance, should the service be exposed on public Internet or restricted to a private network, and exposing routing tables in a secure way to Cloud VPC of its own, where the termination to Dalet's AWS account can finally happen.
• optionally keep control of the media assets Cloud storage (S3) instead of leveraging Dalet's account resources.

The following diagram provides an example overview of such topology.

AWS Customer Hosted

Customer hosting the deployment requires more complexity:

• The customer is then in charge of providing the networking remote access capability, allowing Pyramid to reach out on-premises resources. It is up to the customer to define the scope of access, for instance, should the service be exposed on public Internet or restricted to a private network, and exposing routing tables in a secure way to Cloud VPC of its own, where the termination to Dalet's AWS account can finally happen.
• In the case of an EKS cluster with a private endpoint only accessible through a bastion, Dalet requires a set of tool in order to deploy, operate and maintain the Kubernetes cluster (more details in Infra).

The following example assumes a fully customer-hosted private mode.

IMPORTANT: Hybrid SaaS and Customer Hosted approach implies more responsibility on customer and will automatically lower-down Pyramid’s expected level of resilience, availability and will be out of Dalet’s control and support.

Infrastructure Requirements

Supported Hosting Provider

At the time of this writing, Dalet Pyramid can be deployed on the following infrastructure providers:

• Dalet Cloud, on AWS
• Customer Cloud, on AWS
• Customer On-Premises

NOTE: support for more Cloud providers will come in time.

AWS

AWS Permissions

On deployment, upgrades and possibly fixes, administrative rights are required to create the different resources, the needed IAM roles and permissions, and the OIDC provider for the Kubernetes cluster service accounts

At all time, a minimum of Read-Only rights are needed to the AWS Console for Dalet Ops team

Subnets

When customer hosted, the customer shall provide at least 3 /24 subnets which is due to EKS pod networking management. Another 3 public subnets for the AWS load balancer are required if Pyramid should be publicly accessible. The customer shall allow Dalet to tag the subnets with the following keys:

• kubernetes.io/cluster/cluster-name
• kubernetes.io/role/elb
• kubernetes.io/role/internal-elb

On-Premises

Kubernetes Stack

A the time of writing, Dalet Pyramid has been successfully tested to be compatible with several Kubernetes stacks:

• Dalet Atlas, our self-packaged, automated, license-free Kubernetes stack (based on k0s edition). When on-premises managed services subscription is engaged, Atlas is the de-facto standard.
• VMware Tanzu

Pyramid might be compatible with other Kubernetes implementations but none are presently supported and would require customized work.

IMPORTANT:

•  Pyramid, like any other Kubernetes-friendly application, relies on Kubernetes APIs. These APIs evolve over the course of time and Kubernetes lifecycle and Pyramid software releases will always be compatible with a specific range of underlying Kubernetes versions only. Pyramid software upgrades are consequently tight to specific Kubernetes version, which operational management remains fully on customer's responsibility when Managed Services offer has not been subscribed to.
• Applications lifecycle being tight to Kubernetes versions, Dalet only support using dedicated Kubernetes cluster for Pyramid's orchestration, not to be mutualized with other third-party software, possibly having different lifecycle.
• When Supported plan has been subscribed to, customer has full responsibility of the operational deployment and maintenance of the Kubernetes stack. Unless relying on Dalet Atlas edition, Dalet support teams will not be in position to provide customer with any support on the third-party Kubernetes stack deployment and operational maintenance. If required, Dalet strongly recommends subscription to third-party vendor enterprise-grade commercial support.
• When Managed Services plan has been subscribed to, customer's responsibility remains at virtualization level. Dalet Atlas will be used as a de-facto standard for orchestration, without any other further requirement from customer's perspective. Dalet will NOT be in position to provide operational support for third-party Kubernetes stack providers, even if listed as compatible.
• Switching from Supported to Managed Services plan in the course of the project (and vice-versa), while possible, will imply a complete infrastructure teardown and downtime, induced by the change of underlying Kubernetes stack.

Kubernetes Permissions

When the Kubernetes cluster is fully managed by the customer (Supported plan), administrative rights should be provided in order for Dalet teams to deploy and configure the Pyramid services.

Kubernetes supported base components

• CNI: kube-router, cilium, antrea(Tanzu only)
• CRI: containerd
• CSI: ceph-csi, vsphere-csi, nfs

Database Requirements

Pyramid currently relies on PostgreSQL database v15.2 for business data storage and transaction. The exact database version is subject to upgrade with future software releases. Pyramid requires root/admin permission/account to PostgreSQL to create and managed databases and associated tables and schema migrations routines.

AWS

Unless specified otherwise, Pyramid relies on multi-AZ RDS to provide PostgreSQL service

On-Premises

The nature of database deployment and operational maintenance depends on the selected plan:

• When in Managed Services plan, the PostgreSQL database deployment, configuration and operational maintenance will be fully managed by Dalet teams and part of the underlying Kubernetes cluster.
• When in Supported plan, the PostgreSQL database deployment, configuration and operational maintenance will be at customer's discretion. It can be in-cluster or externalized (in a possibly already existing mutualized PostgreSQL infrastructure). Security, scale-up, backup and maintenance of the database remains at customer's responsibility. Dalet strongly recommends having well trained DBA IT staff to ensure its reliability and will not be in position to support and assist customer, except for Pyramid-inherited schema and content issues.

Here are the PostgreSQL configuration requirements for on premises external instance:

Collation, charsets:

LC_MESSAGES: "en_US.utf8"
LC_MONETARY: "en_US.utf8"
LC_NUMERIC: "en_US.utf8"
LC_TIME  : "en_US.utf8"
LC_COLLATE: "en_US.utf8"
LC_CTYPE: "en_US.utf8"
database encoding (`--encoding` option): "UTF8"

Extensions:

• pg_stat_statements
• pg_cron
• auto_explain

Users and roles: access to postgres user (superuser)

Configuration (postgresql.conf):

auto_explain.log_analyze: "on"
auto_explain.log_buffers: "on"
auto_explain.log_min_duration: "100"
auto_explain.log_nested_statements: "on"
checkpoint_completion_target: "0.9"
checkpoint_timeout: "2min"
cron.database_name: "wn_maintenance"
cron.max_running_jobs: "5"
cron.use_background_workers: "on"
deadlock_timeout: "100"
effective_cache_size: ##<70% of baseline memory>##
effective_io_concurrency: "100"
log_autovacuum_min_duration: "0"
log_checkpoints: "on"
log_line_prefix: "%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h "
log_lock_waits: "on"
log_min_duration_statement: "-1"
log_temp_files: "0"
log_timezone: "Etc/UTC"
max_connections: "200"
max_locks_per_transaction: "1024"
max_wal_size: "1024MB"
min_wal_size: "128MB"
pg_stat_statements.track: "all"
shared_buffers: ##<25% of baseline memory>##
timezone: "Etc/UTC"
track_activity_query_size: "4096"
track_io_timing: "on"

Network Requirements

From service usage perspective

Several network-oriented considerations must be circled out to allow end-users to connect to the Dalet Pyramid service.

Domain Name

The customer shall provide a domain name for Dalet Pyramid to be hosted upon. The chosen domain can be either a public or private domain depending on the targeted usage (service exposed over Internet or restricted to private usage).

The domain name configuration can either be managed by the customer or by Dalet CS Ops team (recommended). The selected domain name is to be provided by the customer. If the customer prefers Dalet to provide a dedicated domain, Dalet offers free usage of the dalet.cloud generic domain. The customer’s Pyramid system will then be made available under pyramid.<customer-env>.dalet.cloud domain.

Dalet strongly recommends to setup a dedicated DNS sub-zone for Pyramid (one sub-zone per environment, e.g: production, staging, QA …). This process can ease the DNS creation automation.

IMPORTANT: The DNS configuration is usually managed by Dalet through automation process. Dalet currently supports AWS Route53 only. If the customer’s selected DNS provider is different, customer will either (1) manage the Pyramid DNS configuration by himself or (2) require an additional customization effort from Dalet teams at an additional charge.

DNS Entries

Should the customer not being able to provide a DNS sub-zone for Dalet to manage it, the following DNS A entries will need to be added. More might be needed, depending on the customer requirements):

• pyramid.<domain_name>
• dashboard.<domain_name> OR dashboard.pyramid.<domain_name>

If an external cube engine is used :

• cube.pyramid.<domain_name>
• cube-rest.pyramid.<domain_name>

The underlying IP addresses mapping is to be disclosed after initial deployment. Multi-A entries need to be supported by the DNS provider to offer high-availability mechanisms.

SSL Certificate

Dalet requires a certificate with the following pattern <pyramid_hostname>.<customer_domain> (When managed by Dalet, this is fully automated by Dalet deployment scripts.) The certificate may require SAN depending on the deployed application.

The SSL certificate can be obtained in different ways:

• Customer requires Pyramid to use the customer-provided SSL certificate
  • Dalet then suggests that the provided SSL certificate is at least RSA-2048 or EC-256 encrypted, with a SHA-256 digital signature and a 1y minimal validity. These encryption requirements are considered to be safe enough to nowadays standards while keeping a wide compatibility with modern client OSes and browsers.
  • The customer is responsible for the proper management (including expiry) of the certificate provided. Dalet requires the customer to provide the renewed certificate within 30 days prior to expiry to ensure a continuity of service.
  • The customer agrees to provide Dalet with both the public SSL certificate, the associated private key and the intermediate CA certificates to ensure a valid chained certificate.
  • Note that Dalet strongly discourages the customer-provided SSL certificate approach, as it may lead to more complexity in SSL management and may induce possible side-effects and unavailability of the service.
• Customer agrees to use a Dalet-provided SSL certificate (recommended)
  • Dalet will then be responsible for global end-to-end security provided by this SSL certificate.
  • A Let’s Encrypt issued certificate will be used, with auto-renewal support.

Load Balancer

Dalet Pyramid requires load balancer(s) to provide users access to the actual services Loadbalancer.

The load balancers are responsible of:

• Exposing Pyramid backend services to users.
• Offering a highly available entry point to Dalet Pyramid.
• Offloading (or terminating) the incoming SSL-secured HTTPS traffic.

AWS

Load balancers are used “as-a-service”, through AWS Classic LB component

Load balancers can be, depending on customer requirements, configured to be:

• Publicly available, exposing Pyramid services over public Internet (recommended)
  • They consequently require to be exposed through one or many public IP addresses and secured (firewall) accordingly.
• Private-only, limiting Pyramid services exposure to private users.
  • In such a scenario, the customer remains responsible to ensure access from its internal network to the Pyramid Cloud application.

On-premise

The Load Balancer is inside the Kubernetes cluster. It requires a Virtual IP (VIP) inside the servers subnet.

This VIP can be private, and the public exposition is on the customer responsibility. This is useful if any network appliance is running in front of it

The VIP can be public and exposed directly by Dalet LB

In both case, the routing is on the customer responsibility

The load balancers only expose the following ports:

• TCP/80 (HTTP) - redirect to 443
• TCP/443 (HTTPS)
• TCP/4222(TCP+SSL)

For on-premises service administration perspective

When Dalet is mandated to manage the hybrid connectivity between customer's premises equipment and Pyramid system on cloud, some extra requirements apply:

On-Premises Ingress

Dalet CS Ops team requires an SSH connectivity to the customer's on-premises network gateways for initial installation, upgrade, configuration or debugging of the environment. This SSH connectivity is mandatory for Dalet to perform the service operation. SSH access can however (more than recommended) be limited to private access through the usage of peering or VPN-like connections and doesn’t require servers to be exposed over Internet.

When per-server SSH access is not possible, Dalet CS Ops team may use a bastion or jump host as a possible SSH-relay alternative. This jump host is expected to be Linux/UNIX-based.

On-Premises egress (When using Dalet's Iris' virtualized network gateway equipment)

Deployed Iris servers need to have Internet egress access to:

• Dalet packages repository
• Linux distribution repository
• <to be completed>

IMPORTANT: The SSH connectivity is the only way for Dalet CS Ops and Support teams to provide efficient deployment, management, troubleshooting, and mitigation of possible incidents. If customer is not able to or doesn’t allow such requirement, the expected level of serviceability and quality of customer service will be greatly weakened and Dalet may not perform as per the SLA, falling to a degraded best-effort approach.

IMPORTANT: “Remote display” mechanisms through browser-based or dedicated applications and protocols like RDP, TeamViewer or similar are not supported options nor an SSH replacement. While such alternatives are somehow possible, the efficiency of support will fall in the same “best-effort” approach as previously mentioned.

Remote Network Gateway Administration / Support

Dalet requires a network connection between customer’s private infrastructure and Pyramid's one on Cloud to communication.

Dalet’s Customer Remote Administration process relies on the following:

• Dalet CS Ops team members authenticate through a corporate LDAP-based MFA-enforced portal to ensure of their identity and authorization / ability to manage customer platforms.
• Once authenticated, they establish a secure one-way VPN tunnel to Dalet’s Cloud Operations administration network and platform.
• Dalet’s Cloud Operations network is connected to customer’s infrastructure and Dalet Ops members can establish an SSH remote connection from there on.

From Dalet’s Cloud Operations network, multiple ways of connecting with customer’s infrastructure are considered and supported (sorted by prefered option):

• Dalet Teleport Bastion
  • Provides native SSH access to backend servers without need for public exposure nor complex VPN gateway.
  • Pros: seamless access to underlying servers for remote administration through dedicated bastion-host over secure client-established HTTPS reverse tunnel. Bastion does not require any public exposure and global remote access can be turned off anytime.
  • Cons: require an extra lightweight VM next to customer's platform and Internet egress connectivity.
• AWS Infrastructure Connectivity: VPC Peering with Dalet CSOps VPC
  • This allows the CSOps team to administer all AWS resources
  • Pros: This is the fastest and reactive access and will greatly reduce response time on incident. It will also reduce time on the deployment
  • This is Dalet's recommended approach when AWS is used.
• Site-to-Site IPSec VPN Tunnel
  • This allows connecting Dalet’s Cloud Administration network with virtually any customer’s platform through public Internet over a secured VPN.
  • Pros: fast and easy access to customer’s environments when it comes to troubleshooting, allows for the customer to control / restrict / limit the subnets to be accessed to.
  • This is Dalet's on-premise recommended approach
• Customer-provided Bastion Host
  • Customer provides a Linux jumphost with SSH access that Dalet’s Ops team members can use as relay to SSH to network gateways.
  • In order to deploy, operate and maintain, Dalet requires root privileges on a instance (It can be the bastion or a server accessible through it)
  • Dalet can also provide a toolbox image for that purpose
  • Pros: SSH connectivity is still manageable.
  • Cons: Customer must provide bastion access to all Dalet CS Ops team members and manage individual contributors’ security. Incapacity from customer to do so will result in a degraded operational quality. Connections will be established from Dalet’s CS Ops team members instead of centralized trusted Cloud Administration network platform with may increase security concerns.
  • Dalet will not support a Windows-based bastion host (unless WSL is available and configured) or a host with no outgoing Internet connection.
• Customer-provided VPN access
  • Customer provides a VPN access to access to network gateways.
  • Pros: SSH connectivity is still manageable.
  • Cons: Customer must provide nominative VPN access to all Dalet CS Ops team members and manage individual contributors’ security. Incapacity from customer to do so will result in a degraded operational quality. Connections will be established from Dalet’s CS Ops team members instead of centralized trusted Cloud Administration network platform with may increase security concerns. Customer must authorize multiple concurrent VPN connections as to allow Dalet Ops team members to perform simultaneous troubleshooting
  • IMPORTANT: Customer-provided Bastion host and dedicated VPN access, while supported, are not recommended. These approaches usually imply heavy changes in terms of access rights, human resources management, and greatly impact Dalet’s responsiveness to incident and capacity to support. If these approaches are considered, Dalet may not perform as per the SLA, and support will fall back to a ‘best-effort’ approach. If this approach is chosen, Dalet CS Ops team requires a Unix-Based/Linux administration VM with root privileges with internet connectivity to achieve the deployment

Hybrid Network Connectivity

Dalet Pyramid can require connectivity to customer's services which are likely to only be hosted on-premises and not publicly available. Different ways can be considered to achieve that purpose:

• Public exposure of the required services to Pyramid Cloud platform. This relies on customer offering public access routing to his private network (direct connection or behind NAT gateways and firewalls).
• Integration of free-of-charge Dalet's Iris virtualized network gateway equipment, providing a secure VPN tunnel between customer on-premises private network and Pyramid Cloud private network (recommended approach).
• Use of a third-party customer-provided network gateway equipment, providing the same kind of secure VPN tunnel between customer on-premises private network and a customer-managed private cloud, peered with Dalet's Pyramid Cloud account.

Ports and connectivity to services

If no specific VPN tunnel is foreseen or if the solution is installed on-premise, it is up to the customer's IT to ensure that the following services and port are accessible from Pyramid over a specific port and protocol. It is up to the customer to set this up in a secure and reliable way. It is up to the customer to decide on whether or not the aformentionned services should be fully exposed publicly and directly or behind NAT and/or firewall using IP whitelisting etc ...

For Pyramid Planning package, the mandatory following service exposure is required:

• SMTP:
  • SMTP (UDP/25, TCP/25)
  • SMTPS (TCP/465)
• Corporate DNS:
  • TCP/53, UDP/53
• Active Directory Domain Services (AD DS):
  • LDAP (UDP/389, TCP/389)
  • LDAPS (TCP/636, UDP/636)
• Galaxy Solr Indexer:
  • TCP/8999
• Galaxy NameServer:
  • TCP/8500
• Galaxy WebService:
  • TCP/8431
• Wowza:
  • TCP/1935
  • TCP/1936

The Pyramid Production package, requires the additional service exposure on top of the default ones:

• Adobe Media Encoder:
  • TCP/8007
• Galaxy MTA:
  • TCP/7900-9000

IMPORTANT: The list of services to be exposed is subject to change over Pyramid's lifecycle and proper service exposure falls under customer's responsibility. Dalet cannot be held responsible for any kind of security side-effects induced by such exposure nor able to support customer should Pyramid fail to be able to reach out the aformentionned services.

Dalet Iris Network Gateway (Full SaaS)

The most straightforward and recommended approach for hybrid networking provided by Dalet Iris Network Gateway.

Iris is a network gateway solution that aims to provide site-to-site connectivty, as to interconnect a Cloud provider to an on-premise infrastructure. Iris is a custom Linux OS to be installed on metal or virtualized servers on customer premises. It provides the following optional networking services:

• Core network services:
  • DNS
  • DHCP
  • Router (static, BGP, OSPF)
  • Firewall
  • High-Availability
• Connectivity services:
• IPSec site-to-site VPN
• WireGuard client-server VPN
• Client-Server OpenVPN

The following diagram exposes how Iris offers edge network connectivity:

Iris being a router, it allows for bi-directional traffic between 2 locations over a restricted list of protocols.

Subnets must be known and shared by both Pyramid & Galaxy to setup IPSec connection (when enabled) and the routing. The Galaxy servers will need to have a route defined to reach the Pyramid endpoints. This can be done by the customer network team or on the Galaxy server themselves in the case Iris servers are located in the same subnet than Galaxy. We recommend using BGP protocol to exchange routes

Pyramid servers will need to have a route defined to reach the Galaxy server. This is implemented by Dalet as part of the Cloud deployment. DNS resolution can also be needed to ensure the Galaxy server can resolve the Pyramid DNS names if the DNS entries are not public.

Customer Third-Party Network Gateway (Hybrid SaaS)

Customer may choose to use its own network gateway to provide hybrid networking and decide not to go with Dalet Iris. When such an option has been selected, it becomes customer's responsibility to deploy, administrate and manage a third-party solution of its own, provided it features a routed tunnel between customer's premises and a Cloud account.

The Dalet recommended approach is for customer to provide network connectivity between his premises and an AWS account under his control. This ensures customer's IT teams to have full control offer the networking traffic flowing between the two peers. Connectivity between Dalet's Pyramid on AWS is then achieved through a matter of a simple AWS VPC peering.

NOTE: Dalet highly recommends the network gateway to be deployed in a highly-available and resilient manner, to ensure a possible network loss will not prevent Pyramid services from being down.

IMPORTANT: It is up to the customer to fully manage the hybrid connectivity solution, from end-to-end. This includes commercial contract with the chosen third-party solution vendor, setup, network routing and end-to-end security and resilience and 24x7 management. Dalet cannot be held responsible for any deficience on networking side as solely operating the Cloud VPC end.