SURAJ KUMAR DAS

Hello. I have a total of 13 years of experience in IT, and I have been working in AWS and infrastructure for the last 8 years. So, initially, I was in a Linux environment and worked for clients like Tech Mahindra and Polaris. After that, I moved to Cofax and Thoughtworks, maintaining the infrastructures and implementing solutions for customers who utilize our products. Whenever new instances, VMs, or servers are required, we manage the infrastructure and provide the details to them. We also manage anything related to applications, CSUs, or databases in RDS, DynamoDB, or any other AWS services. We are the first point of contact and work on resolving those issues. Additionally, when decommission requests come into the picture, like old servers or projects getting decommissioned, we clean up the systems and everything happens in the agile development process. We work on a sprint-by-sprint basis. Besides that, we write new Terraform scripts, Cloudformers, and templates to automate the infrastructure as required by the clients. In one of my previous organizations, I wrote Terraform scripts for the ONIX client, a major client for Bitcoin mining and related activities. We deploy instances through Jenkins, which is also known as JUULES.

So in AWS, when data is in transit, we can use SSL/TLS, and the certification 5509, in order to encrypt the data in transit. And there are two ways, whether it's a customer-managed or the AWS-managed. So the customer-managed, the customer will have full control over the encryption and decryption and only use the AWS services for data storage and everything. And when it comes to the KMS, it's managed by the AWS, and AWS will take care of the auto-rotation of the keys every once in a while, but we can configure that. So, at rest, for example, in S3, if we are storing the data, we can enable KMS. By default, S3 encryption is enabled, but we can enable it by using KMS, which is managed by the AWS. So, and another thing, SSCC, where the customer has to request the customer will manage the encryption part, and AWS has nothing to do with it.

BPC pairing is nothing but. It's a communication between two VPCs. Suppose VPC A and VPC B, we can establish a connection among these two VPCs by doing VPC pairing. So, and the security can be provided in two ways. One is using security groups, which are stateful and will only allow traffic to it. And in addition, in order to provide additional security, we can provide security at the subnet level by using a network access list, which is stateless. This allows us to define allow and deny rules, and everything is different based on our requirements. Whatever traffic we want as inbound and outbound, everything can be defined and checked. So, in VPC peering, communication between two different VPCs can be done by using security groups and NACL level, by providing NACL at the subnet level.

In code pipeline, we can use CodeDeploy. The CodeDeploy is where we can have two instances to deploy to. And there are several ways to have no downtime. If we are using, for example, the blue-green deployment type or rolling in batches or rolling update. So in that case, we won't have any deployment downtimes. So when we have that, for example, the blue-green deployment, in that case, we can have another instance where we can redirect our traffic to a part of the traffic can be redirected to that. And once everything is sorted out, the full traffic can be redirected to the newly created instance. And the older one can be terminated. And another one is rolling updates. So what happens in rolling update is another set of instances can be created, and once that is updated with the latest code and everything, we can terminate the existing one and all the traffic can be done. If we implement a zero-downtime deployment, then there will be no downtime.

So what CloudTrail does is it stores information related to the user accessing the APIs and it's best sure for figuring out what user has access to the API and for trailing the information, is there any person who is trying to access who is not supposed to be. So, that thing can be done using the CloudTrail. And in the AWS config, I don't recall what AWS Config does right now.

The version control can be created in either Git or Bitbucket, anywhere we want to use. And the usable modules mean we don't need to suppose one resource is being created, like an EC2 instance by using CloudFormation Terraform. So that resource, we don't need to rewrite it every time we want to have one EC2 instance. In that case, we can have one module, one small module for that, which does what it does is it gets the right set of permissions, and that can be reused. That's where the reusable module is. And the same thing applies in cloud formation.

But, in any ISE, the database, especially when a stateful set is not part of an ISE, it should be handled externally, and the connection endpoint should be provided to the ISE, regardless of the cloud formation or Terraform. And the username and password should not be hardcoded in the template itself. There is a concept called parameter, where while providing the template, the username and password can be provided as a parameter. So if that is the case, then the password also can be stored in a secret manager, and it can be accessed through the secret manager or SSM parameter. Anywhere we can store it, and we can make sure that it is KMS encrypted. So the username and password should not be hardcoded in this case.

Effect allows actions 3. Resource is here in my bucket. Condition string does not report. My Slush. Well, the resource section is here. Given my bucket, wildcard. It means everything inside my bucket should be accessible. And then again in the condition section, if the string is not home slash AWS username. So AWS colon username is given to the specific username who is trying to access, so that he can only access what he's storing. He cannot see what others store. So effect is a low. This was condition string not equal to. So it should not be home, but instead my bucket then AWS username. Or in the resource section, we can have home slash.

Well, the monolithic applications, the approach would be like, first, we'll have the connectivity, whether we wanted to use SSO login or SAML 2.0. And we need to figure that out first. And once we have that, the monolithic applications first of all require some measures. Just like we have to have microservices instead of putting everything in a single instance, having numerous instances coming to the load balancer and AZ coming into the picture. So what we can do is we can utilize Kubernetes, Docker containerization. All that stuff can be used, which will definitely require major development changes. So if we want to directly use the monolithic application, what we can do is we can have static content if that application is processing. So we can redirect the user to CloudFront. And from there, we can send the request directly to S3. If not, then the API gateway, then the load balancer, and underneath all the EC2 instances. And each EC2 instance will have an individual, standalone component. And so, in order to have a microservices approach, we need to do the development changes. And all individual components can be deployed into a port, and port means in EKS.

Well, when I'm unsure about how many issue 2 instances will be created in ACS, the task is task definition based on the task definition, and two instances are getting created. Suppose if we don't want to manage the underlying resources and we don't know the load, how many containers will be getting created. In that case, it's better to give it to AWS. AWS will take care of all the underlying resources. We don't need to worry about the number of issue 2 instances we want or how many resources we want for our purpose. So, AWS will take care of the auto-scaling and underlying resources. If it's required more, then it will have more, and based on the request, it will scale down. So, everything will be happening in the backend. We won't be managing the resources. The AWS will take care of it.

Lambda, we can send the Lambda log into CloudWatch, and CloudWatch is the best part to see log information, unless there's another way, like using Kinesis Data Stream to send data to 3rd party observability tools like Splunk, Datadog, and all that stuff. That's one way to figure it out. And we need to see what lambda function is, whether it's synchronous or asynchronous. If synchronous, we know right away if we're not getting a 200 or success message. In asynchronous, what happens is like if something is sending to an S3 bucket and we don't wait for the response. We do get a response right away, but underneath it still works, putting data into S3 or SQS sending queue. So whenever any issue happens, it sends data to the dead letter queue and processes subsequently with exponential backoff. So if those things are still not working, everything is failed, we need to see the CloudWatch and CloudWatch logs. And we need to do a testing on the Lambda, like we can have another Lambda function and try to test if everything's working fine or not. So the error loop Lambda usually used for short intervals of time. We don't write a big complex program into that. So most of the complaints which can be handled within 15 minutes, those things would be mentioned, and those things should be handled by using Lambda, and testing everything can be in a linear application itself. So yeah.