Nowadays, it is very common to run applications on Spot instances. In this scenario, where a spot instance could be terminated at any point of time because of AWS pulling back their resource or ASG Scale-In incident, we need to have something in place to handle the termination smoothly so that we can complete our final tasks before the system shutdown. It could be executing some scripts, unmounting some storage device, shipping final log files to S3, or uploading cache data in a centralized server like Redis. Today, I will attempt to cater to this problem.
First of all, let’s think of trying to run a custom script prior to shutdown in our local system. If everything works fine, the same would be applicable for ec2 spot instances too.
As we all know AWS and Azure are the two Cloud providers and there can be possibilities that one of our services is running on one cloud provider and the other is running on another cloud provider and, both are dependent on each other.
Through this blog, I will guide you on the steps which will be needed for connecting AWS with Azure and also will be explaining all the components of both the cloud provider that will be required for creating the site-to-site VPN Connectivity.
Why are we trying to connect both?
In one of my projects, I met with a requirement where I was working on an application that follows a client-server architecture. There were servers connected to multiple clients. Initially, the Server was placed into AWS and the connected clients were also there, but after a couple of years our requirements got changed and a new business unit came into the picture with its own clients that were needed to be connected with the server present in the AWS cloud.
Now, these new clients were present on Azure but the server was on AWS. Migration of server was not an option for us because our customer was not ready to migrate those clients from Azure to AWS, so this was a completely new use case, to which we decided to connect both the cloud providers with each other by setting up IPSec VPN tunnel.
Most of the IT companies are working or are migrating their infrastructure to the cloud environment for cost reduction, high availability, data security, and hassle-free setup. Companies create or use applications/databases on the cloud, where they need to authenticate via secrets (or credentials). These days protection of passwords is one of the challenges, and hard-coding the secrets into the system would be a major security issue. Hence, we can make use of the AWS service named Secret Manager that will be responsible for the management of secrets.
What is a Secret?
A secret is not just a pair of usernames and passwords. It might contain a set of credentials holding key-value pairs or connection details to access the related services. In AWS Secret manager, a secret has metadata:
An Amazon Resource Name, name of the secret, a description, a resource policy, and tags, ARN for an encryption key (an AWS KMS key that Secrets Manager uses to encrypt and decrypt the secret value), Information of rotation of secret.
To understand what AWS Lambda is, we have to first understand all about serverless architecture. The serverless architecture is a way to build and run applications and services without having to manage infrastructure. Your application still runs on servers. When you run a serverless application, you get the benefit of not worrying about OS setup, patching, or scaling of servers that you would have to consider when you run your application on a physical server.
Serverless applications or platforms have four characteristics:
Amazon Route 53 is a highly available and scalable authoritative cloud Domain Name System (DNS) service. It connects the Internet traffic to appropriate servers hosting the requested Web application. In addition, route 53 also facilitates health-checking and domain name registration of services. The design of route 53 aims at providing a highly reliable and cost-effective approach for routing end-users to Internet applications. Why the name Route 53! AWS Route 53 takes its name from the Port 53, which handles DNS for both the TCP and UDP traffic requests, the term Route may signify the routing, or perhaps the popular highway naming convention in the USA.