Infrastructures are abstractions that allow you to create a Virtual Private Cloud (VPC) instance in the DuploCloud Portal. When you create an Infrastructure, a Plan (with the same Infrastructure name) to supply the network configuration that runs your Infrastructure is automatically created and populated with the Infrastructure configuration.

For instructions to create an Infrastructure in the DuploCloud Portal, see:

• AWS Infrastructure

• Azure Infrastructure

• GCP Infrastructure

• On-premises Infrastructure

Each Infrastructure represents a network connection to a unique VPC/VNET, in a region with a Kubernetes cluster. For AWS, it can also include an ECS. An Infrastructure can be created with four basic inputs: Name, VPC CIDR, Number of AZs, Region, and a choice to enable or disable a K8S/ECS cluster.

When you create an Infrastructure, DuploCloud automatically creates the following components:

• VPC with two subnets (private, public) in each availability zone

• Required security groups

• NAT Gateway

• Internet Gateway

• Route tables

• VPC peering with the master VPC, which is initially configured in DuploCloud

Additional requirements like custom Private/Public Subnet CIDRs can be configured in the Advanced Options area.

Plans and Infrastructures

Once an Infrastructure is created, DuploCloud automatically creates a Plan (with the same Infrastructure name) with the Infrastructure configuration. The Plan is used to create Tenants.

DuploCloud Plans

When you create an in DuploCloud, a Plan is automatically generated. A Plan is a placeholder or a template for configurations. These configurations are consistently applied to all Tenants within the Plan (or Infrastructure). Examples of such configurations are:

• Certificates available to be attached to Load Balancers in the Plan's Tenants

• Machine images

• WAF web ACLs

• Common IAM policies and SG rules to be applied to all resources in the Plan's Tenants

• Unique or shared DNS domain names where applications provisioned in the Plan's Tenants can have a unique DNS name in the domain

• Resource Quota that is enforced in each of the Plan's Tenants

• DB Parameter Groups

• Policies and feature flags applied at the Infrastructure level on the Plan's Tenants

The figure below shows a screenshot of the plan constructs:

DuploCloud Plans and DNS Considerations

When creating DuploCloud Plans and DNS names, consider the following to prevent DNS issues:

• Plans in different portals will delete each other's DNS records, so each portal must use a distinct subdomain for its Plans.

• DuploCloud Plans in the same portal can share a DNS domain without deleting each other's records. Duplo-created DNS names will always include the Tenant name, which prevents collisions.

• The recommended practice for most portals is to set all Plans to the same DNS name, including the default Plan.

• Ideally, custom subdomains will be set in the Plans before turning on shell, monitoring, or logging. If the DNS is changed later, those services may need to be updated.

Tenant as a Logical Concept

A Tenant, like a project or a workspace and a child of the Infrastructure, is the most fundamental construct in DuploCloud. While Infrastructure is a VPC level isolation, Tenant is the next level of isolation implemented by segregating Tenants using concepts like Security Groups, IAM roles, Instance Profiles, K8S Namespaces, KMS Keys, etc.

For instructions to create a Tenant in the DuploCloud Portal, see:

• AWS Tenant

• Azure Tenant

• GCP Tenant

At the logical level, a Tenant is fundamentally four things:

• Container of Resources: All resources (except those corresponding to Infrastructure) are created within the Tenant. If we delete the Tenant, all resources within it are terminated.

• Security Boundary: All resources within the Tenant can talk to each other. For example, a Docker container deployed in an EC2 instance within a Tenant will have access to S3 buckets and RDS instances in the same Tenant. By default, RDS instances in other Tenants cannot be reached. Tenants can expose endpoints to each other via ELBs or explicit inter-Tenant SG and IAM policies.

• User Access Control: Self-service is the bedrock of the DuploCloud Platform. To that end, users can be granted Tenant-level access. For example, an administrator may be able to access all Tenants while developers can only access the Dev Tenant and a data scientist the data-science Tenant.

• Billing Unit: Since a Tenant is a container of resources, all resources in a Tenant are tagged with the Tenant's name in the cloud provider, making it easy to segregate usage by Tenant.

• Mechanism for Alerting: Alerts generate faults for all of the resource within a Tenant.

• Mechanism for Logging: Each Tenant has a unique set of logs.

• Mechanism for metrics: Each Tenant has a unique set of metrics.

Tenants and Kubernetes

Each Tenant is mapped to a Namespace in Kubernetes.

When you create a Tenant in an Infrastructure, a Namespace called duploservices-TENANT_NAME is created in the Kubernetes cluster. For example, if a Tenant is called Analytics in DuploCloud, the Kubernetes Namespace is called duploservices-analytics.

All application components in the Analytics Tenant are placed in the duploservices-analytics Namespace. Since nodes cannot be part of a Kubernetes Namespace, DuploCloud creates a tenantname label for all the nodes launched within the Tenant. For example, a node launched in the Analytics Tenant is labeled tenantname: duploservices-analytics.

Any Pods launched using the DuploCloud UI have an appropriate Kubernetes nodeSelector that ties the Pod to the nodes within the Tenant. Ensure kubectl deployments use the proper nodeSelector.

Tenant Use Cases

DuploCloud customers often create at least two Tenants for their Prod and Nonprod cloud environments (Infrastructures).

You can map Tenants in each (or all) of your production environments.

For example:

• Production Infrastructure

  • Pre-production Tenant - for preparing or reviewing production code

  • Production Tenant - for deploying tested code

• Nonproduction Infrastructure

  • Development Tenant: For writing and reviewing code

  • Quality Assurance Tenant: For automated testing

Some customers in larger organizations create Tenants based on application environments: one tenant for data science applications, another for web applications, etc.

Tenants can also isolate a single customer workload allowing more granular performance monitoring, flexibility scaling, or tighter security. This is referred to as a single-Tenant setup. In this case, a DuploCloud Tenant maps to an environment used exclusively by the end client.

With large sets of applications accessed by different teams, it is helpful to map Tenants to team workloads (Dev-analytics, Stage-analytics, etc.).

Tenant Naming Conventions

Ensure Tenant names in DuploCloud are unique and not substrings of one another. For example, if you have a Tenant named dev, you cannot create another named dev2. This limitation arises because IAM policies and other security controls rely on pattern matching to enforce Tenant security boundaries. If Tenant names overlap, the patterns may not work correctly.

To avoid issues, we recommend using distinct numerical suffixes like dev01 and dev02.

A Service could be a Kubernetes Deployment, StatefulSet, or DaemonSet. It can also be a Lambda function or an ECS task or service, capturing a microservice. Each service (except Lambda) is given a Load Balancer to expose itself and is assigned a DNS name.

DuploCloud Supported Services

For information on cloud-specific Services supported by DuploCloud, see:

DuploCloud supports a simple, application-specific interface to configure dozens of cloud services, such as S3, SNS, SQS, Kafka, Elasticsearch, Data Pipeline, EMR, SageMaker, Azure Redis, Azure SQL, Google Redis, etc. Almost all commonly used services are supported, and new ones are constantly added. DuploCloud Engineers fulfill most requests for new services within days, depending on their complexity.

All services and cloud features are created within a . While users specify application-level constructs for provisioning cloud resources, DuploCloud implicitly adds all the underlying DevOps and compliance controls.

Below is an image of some properties of a service:

Hosts (VMs) are a cornerstone of cloud infrastructure, essential for providing isolated, scalable, and flexible environments for running applications and services. Hosts can exist in various forms and configurations, depending on the environment and the technology stack.

For instructions to create a Host in DuploCloud, see the documentation for your specific cloud provider:

In DuploCloud, Hosts are virtualized computing resources provided by your cloud service provider (e.g., AWS EC2, Google Compute Engine, Azure VMs) or your organization's data center and managed by the DuploCloud Platform. They are used to provision scalable, on-demand infrastructure. DuploCloud abstracts the complexities of provisioning, configuring, and managing these Hosts. DuploCloud supports the following Host contexts:

• Public Cloud: VMs provided by cloud providers and managed through the DuploCloud Platform.

• Private Cloud: Virtualized environments managed within an organization's data center.

• Combination of On-premises and Cloud: A mix of physical hosts, VMs, and cloud-hosted instances.

Several DuploCloud components are used with AWS, GCP, Azure, and hybrid/On-premises Services. These include Infrastructures, Plans, Tenants, Hosts, and Load Balancers. This section provides a conceptual explanation of the following common DuploCloud components:

• Infrastructure

• Plan

• Tenant

• Services

• Diagnostics

For instructions to implement these common components in your DuploCloud account, see the documentation for your cloud provider:

• AWS Use Cases

• Azure Use Cases

• GCP Use Cases

DuploCloud Diagnostics Functions

The DuploCloud platform automatically orchestrates the following main diagnostic functions:

Central Logging

A shared Elasticsearch cluster is deployed and Filebeat is installed in all worker nodes to fetch logs from various applications across Tenants. The logs are injected with metadata corresponding to the Tenant, Service, container ID, Host, etc. Further, each Tenant has a central logging dashboard which includes the Kibana view of logs from applications within the Service. See the screenshot below:

Metrics

Metrics are fetched from Hosts, containers, and Services and displayed in Grafana. Services metrics are collected behind the scenes by calling cloud provider APIs like CloudWatch and Azure Monitor. For nodes and containers, metrics are collected using Prometheus, Node Exporter, and cAdvisor. The Metrics dashboards are Tenant-centric and segregated per application and Service as shown in the image below:

Alarms and Faults

The platform creates faults for many failures automatically. For example, health check failures, container crashes, node crashes, deployment failures, etc. Further, users can easily set alarms like CPU and memory for EC2 instances or free disk space for RDS databases. Failures are displayed as faults under their respective Tenant. Sentry and Pager Duty projects can be linked to Tenants, and DuploCloud will send faults there so the user can set notification configurations.

Audit Trail

All system changes are logged in an audit trail in Elasticsearch where they can be sorted and viewed by Tenant, Service, change type, user, and dozens of other filters.