DevOps Tips

Securing Multi-Cloud Environments: Monitoring, Logging, and Best Practices

Explore the advantages of multi-cloud architecture for flexibility and risk management. Implement secure back-end VPN connections, monitor efficiently with the ELK stack, and enforce robust authentication. Enhance logging configurations effortlessly with CoGuard.

Albert Heinle
Written by
Albert Heinle

Cloud computing is the delivery of computing resources as a service, managed by the cloud provider rather than the end user. This is different to how many on-premise resources operate, the buying and managing of the hardware and software. 

Adopting a multi-cloud architecture across public and private clouds provides flexibility but also poses security and operations challenges. Hybrid and multi-cloud are suspiciously similar (and could be used interchangeably). Every cloud provider has its own pros and cons, by combining several a business can leverage the unique aspects of each. The reasons for choosing a multi-cloud setup include:

  • Risk management, 
  • Avoiding vendor lock-in and reliance on a single vendor,
  • Compliance with regulatory requirements,
  • Unique services that are not available on other providers,
  • Cost management (or using free cloud credits). 

It requires some planning and effort, but multi-cloud configurations can provide flexibility, access to unique features and avoid vendor lock-in. These are key areas that need to be thought about early in the adoption process. 

Back-End VPN Connections

The clearest sign that you have done something wrong is when you need to open up the ports to a low-level resource, such as a database, to the internet. This violates the principle of network segmentation (NIST guidelines).

Even when you create API endpoints that require authentication and authorization: If it is a back-end service that generally has no need to have direct external access, it is not good to expose it. 

To address these concerns, establishing secure Back-End VPN (Virtual Private Network) connections becomes imperative. VPNs create a private and encrypted tunnel between your cloud environments, ensuring that sensitive back-end services are shielded from direct external access. This approach aligns with best practices for network security, minimizing the risk of unauthorized access and potential vulnerabilities.

By implementing VPNs between major cloud platforms like Azure, AWS, and GCP, you can control and restrict access to specific services, enhancing the overall security posture of your multi-cloud architecture. This not only aligns with security principles but also contributes to a robust and well-organized network infrastructure, fostering a safer environment for your back-end services.

Remember, the goal is not just to avoid exposing unnecessary endpoints but to do so while maintaining a seamless and secure communication channel between your cloud resources. This approach aligns with the broader strategy of securing your infrastructure in a multi-cloud environment.

How can you then do it better? 

One way is to create a VPN and allow access to the respective services through the VPN. There are multiple ways of doing this. Here is the official documentation for traffic between the major clouds:

The only scenario where you do not need to do this in a multi-cloud environment is when your back-end services on the clouds do not need to talk to each other.

Monitoring & Logging Considerations

All major cloud providers have their in-house monitoring solution. AWS has CloudWatch, Azure has Monitor, and GCP has Cloud Monitoring. The problem is now that with having multiple sources, one is lacking a central log/alerting collection point. That may cause vital information being missed when analyzing logs.

This is the moment to consider using logging tools like the ELK stack (ElasticSearch, Logstash and Kibana). The ELK stack is designed to capture and collect information from a huge variety of sources (cloud-native infrastructure including hosts, containers, pods, etc.). Detailed integrations for each of the major cloud providers (and hybrid stacks) can be enabled: 

Alternatively, one can also use an external service such as Loggly. The ELK stack provides the tools you need to deep dive into logs for analysis, troubleshooting, or security audits. 


Implement single sign-on (SSO) for centralized identity and access management. Use role-based access control (RBAC) with standard roles across clouds. Revoke access instantly when employees leave.

This requires a multi-cloud SSO solution for user accounts (not necessarily service accounts). Solutions can be self-hosted (Keycloak) or hosted (Auth0). 

The authentication/authorization architecture that you generally should aim for is a role-based access model (RBAC). All modern SSO solutions provide the respective roles inside the authentication tokens, which you can then use across all your services. These roles should also be independent of the cloud provider itself. Architect APIs for access control using standards like OpenAPI Specification. Enforce authentication and authorization systematically. 

Especially when considering off-boarding employees and ensuring that all their access is revoked, it is important to use centralized authentication and authorization mechanisms. Otherwise, human error/forgetfulness may leave an employee with access credentials post-termination.

Use a general IaC tool

Keeping all infrastructure information in one central spot is guaranteed to have the greatest visibility into your infrastructure and your change management. Define all Infrastructure as Code (IaC) with a standard tool like Terraform. This provides a unified language and framework for describing your infrastructure, ensuring consistency and facilitating change management across different cloud platforms.

When you opt for a universal IaC tool like Terraform, you create a single source of truth for your infrastructure configuration. This not only streamlines the management of resources but also enhances collaboration among teams, regardless of the specific cloud provider they are working with. Terraform's declarative syntax allows you to describe your infrastructure in a human-readable and version-controlled format.

Contrastingly, relying on separate platform-specific languages, such as CloudFormation for AWS or Azure Resource Manager for Microsoft Azure, can lead to fragmentation. Each cloud provider has its own syntax and structure, making it challenging to maintain a cohesive and standardized infrastructure configuration.

By adopting Terraform or a similar cross-platform IaC tool, you ensure that your infrastructure is agnostic to the underlying cloud environment. This not only simplifies the deployment and management processes but also reduces the learning curve for team members working across different cloud providers. Ultimately, the use of a general IaC tool contributes to a more efficient, consistent, and manageable multi-cloud architecture.

Enhance Your Logging Configuration with CoGuard

Streamline your security practices by leveraging CoGuard's configuration analysis capabilities. Identify and optimize logging configurations effortlessly for containers, applications, and infrastructure. Save time locating essential configuration files and gain insights into misconfigurations. CoGuard provides practical details, including file names, line numbers, and suggested changes, facilitating efficient remediation. Explore the benefits of a refined logging setup—try CoGuard now.

Save time and secure your infrastructure by scanning it with CoGuard. Getting started is easy:

pip install coguard-cli
coguard folder {infra_repo_location}
coguard cloud {aws,gcp,azure}

Photo credit Robynne Hu on Unsplash

Explore a test environment

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Check out and explore a test environment to run infra audits on sample repositories of web applications and view select reports on CoGuard's interative dashboard today.