Every machine has recurring tasks. Backups, updates, runs of configuration management software like Chef, small scripts, … But one of the problems in a cloud environment is visibility. Instead of scheduling dozens of cron jobs or tasks per instance, would it not be nice to have a central service for this? You already have. And it’s called EventBridge…
When setting up a microservice architecture, each individual service is often owned and managed by a different team. To achieve a higher level of resource isolation, and allow for more granular security and cost management, each service team usually deploys its resources into a dedicated AWS account. While this type of distributed approach offers many benefits in terms of productivity, scalability, and resiliency, it introduces another layer of complexity in regard to AWS cross-account communication and microservice consumption. In this blog post, I would like to show you how you can leverage AWS services like Amazon API Gateway, Lambda, DynamoDB, and VPC Endpoints in combination with Terraform to build a fully-managed and serverless cross-account microservice architecture.
In this blog post, I would like to show you the various types of AWS permission management capabilities to generate a better understanding, where access denied API errors (403) may arise from and what ample options there are to grant permissions. One should be familiar with IAM policies to get the most out of the blog.
When setting up IPSec VPN connections between different companies, the connecting parties often require the tunnel to use public IP addresses as the encryption domain. Especially when establishing a connection to telecommunication partners, the usage of public addresses is often mandatory and ensures that there are no overlapping addresses across other connections. In this blog post, I would like to show you how you can leverage tools like pfSense and VNS3 in combination with Terraform to build a Site-to-Site IPSec VPN connection between AWS and on-premises networks with a public encryption domain.
Sometimes, developing a fully-fledged Lambda is not feasible, is too much work, or is simply outside of the knowledge domain of the people involved. But what if we could run plain Bash scripts instead?
When deciding which Infrastructure as Code tool to use for deploying resources in AWS, Terraform is often a favored choice and should therefore be a staple in every DevOps Engineer’s toolbox. While Terraform can increase your team’s performance quite significantly even when used locally, embedding your Terraform workflow in a CI/CD pipeline can boost your organization’s efficiency and deployment reliability even more. By adding automated validation tests, linting as well as security and compliance checks you additionally ensure that your infrastructure adheres to your company’s standards and guidelines. In this blog post, I would like to show you how you can leverage the AWS Code Services CodeCommit, CodeBuild, and CodePipeline in combination with Terraform to build a fully-managed CI/CD pipeline for Terraform.
In an era where cloud computing is revolutionizing businesses, the rise of a new discipline called FinOps is commanding attention. Financial Operations, or FinOps, brings a financial lens to the operational aspects of cloud computing, enabling organizations to drive cost efficiency, business value, and growth. But what exactly is FinOps and how can businesses leverage it in the realm of cloud computing? Understanding FinOps FinOps is a cultural shift, a practice that combines systems, best practices, and organizational culture to bring financial accountability to the variable spend model of cloud computing.
Amazon OpenSearch Service is a fully-managed solution for interactive log analytics, real-time application monitoring, website search, observability, and more. With a vast customer base, Amazon OpenSearch Service manages hundreds of thousands of clusters and processes trillions of requests monthly. The service provides seamless access for users through SAML-based federation for OpenSearch Dashboards, enabling single sign-on (SSO) on Amazon OpenSearch Service domains using existing identity providers (IdPs) like OneLogin. SAML simplifies the login process by allowing users to access multiple platforms with a single username and password, providing a safer and more convenient online experience. This guide will walk you through integrating OneLogin with OpenSearch Dashboards for a seamless SSO experience, leveraging Amazon OpenSearch Service’s capabilities.
