AWS architect Interview Questions and Answers for 2024 Cloud Computing

While we launch AWS EC2 instances, AWS provides us with different placement group options to ensure EC2 instances are spread across the different physical machines to minimize the failure of the entire applications at one go. Using placement group, we can decide how the instances can be launched based on our security, business or performance requirement on the underlying hardware. AWS placement group provides us with 3 strategies as part of it to plan our workloads accordingly. 

• Cluster placement group: It groups instances into low latency clusters in a single available zone (AZ). 
  • AWS Cluster placement group is a logical grouping of instances within a single AWS Availability Zone which doesn’t span across multiple AWS Availability Zones but can span across peered VPCs in the same AWS region 
  • This kind of placement group is recommended for applications that benefit from low network latency, high network throughput, or both.
• Spread placement group: It spreads the instances across underlying hardware. 
  • The AWS spread placement group groups instances that are each placed on the distinct underlying hardware, that is, each instance on a distinct rack, with each rack having its own network and power source. 
  • This kind of placement group is recommended for applications that have a small number of critical instances that should be kept separate from each other and reduce the risk of simultaneous failures that might occur when instances share the same underlying hardware.
• Partition placement group: It spreads the instances across many different partitions within an AZ. 
  • Partitions are nothing but logical groupings of instances where instances do not share the same underlying hardware across different partitions. 
  • It divides each group into logical segments called partitions and ensures that each partition within a placement group has its own set of racks and each rack has its own network and power source. 
  • No two partitions within a placement group share the same racks, isolating the impact of a hardware failure within the application to reduce the likelihood of correlated hardware failures for the application. 
  • Note: Partitions in multiple AWS Availability Zones in the same AWS region can have a maximum of seven partitions per AWS Availability Zone. 

This is a frequently asked question in AWS architect interview questions.  

Instances are virtual environments provided by EC2, also known as EC2 Instances, that can be used to host applications by cloud users. Following are the types of Instances available in Amazon EC2: 

• General Purpose: These instances equalize compute, memory, and networking resources and are ideal for applications that use these resources proportionately, such as web servers and code repositories. 
• Compute Optimized: These instances benefit from high-performance processors and are suitable for compute-bound applications like gaming servers, ad server engines, and compute-intensive applications. 
• Memory-Optimized: These instances are ideal for workloads that require the processing of large data sets in memory. 
• Accelerated Computing: These instances use hardware accelerators, or co-processors, to perform functions, such as calculations, graphics processing, data pattern matching, and others. 
• Storage Optimized: These instances are widely used to process workloads that require high, sequential read and write access to large data sets on local storage. 

Expect to come across this popular question in AWS solution architect interview questions.  

The ideal way to connect from your local data center to your cloud resources is through a VPC. Each of your instances is given a private IP address that may be accessible from your data center after your data center is connected to the VPC where it is located. In this manner, you can use the resources on your public cloud as if they were on your personal network.

• For reservation of AWS Elastic IP even though it's not attached to EC2. 
• When it is attached to an instance in the stopped state 
• Attached to an instance that already has an AWS Elastic IP attached 
• Associated with non-attached network interface 

EC2 stands for Elastic Cloud Compute. This technology is widely used to scale up computing capacities while eliminating the need for hardware architecture. The Amazon EC2 technology can launch multiple servers and manage security, networking, and storage all at once. Besides, while using EC2, the need for traffic forecast reduces as there are options to scale up and scale down as per the requirements.

Identity and Access Management (IAM) is a specialized web service dedicated to securing access to AWS resources. The IAM web service is vital to manage AWS users, access key credentials, and access permissions for AWS resources and applications.

A must-know for anyone heading into an AWS architect interview, this question is frequently asked in AWS architecture interview questions.  

The features of IAM are as follows: 

• Shared Access to our Account helps in sharing resources with the help of the shared access features. 
• Free of cost - AWS IAM is free to use, and also all the charges are added when we access other Amazon web services using IAM users. 
• Centralized control over your Aws account - Helps in the new creation of users and groups of any form of cancellation. 
• Grant permission to the user - It holds administrative rights, and the users can grant permission to access. 
• Multifactor Authentication - It adds layers of security implemented on our account by a third party. 

AWS policies are of two types:  

• Identity-based policies: This is the policy that binds with AWS identities, such as a user's, group or role. IAM policies are an example of that. These policies can be either Amazon Web Services managed or customer-managed.  
• Resource-based policies: AWS resource-based policies are the ones that can be tied directly to Amazon Resources, like a bucket policy (S3). Resource-based policies are only available for certain services.  

A common question in AWS solution architect interview questions for freshers, don't miss this one. 

• Do not use root accounts: Since root accounts have access to all the AWS resources and services, it is not a good idea to share or use them.  
• Use Groups: Create groups, grant access to them, and add users to them – so that all users within the group have the same access.  
• Enable Multi-factor Authentication (MFA): MFA should be enabled for privileged users such as admins. MFA adds an additional layer of security.  
• Grant least privileges: Only grant permissions that are necessary for the user or group.

Different types of load-balancers used in Amazon EC2 are: 

• Application Load Balancer: Used to make routing decisions at the application layer 
• Network Load Balancer: Used to make routing decisions at the transport layer 
• Classic Load Balancer: Used within the EC2-Classic network to balance load at varying EC2 instances.

A.9. AWS disaster recovery system enables businesses to quickly recover their critical IT systems without extra investment in a second infrastructure. The AWS cloud supports several disaster recovery architectures, including small customer workload data center failures to rapid failover at scale. Amazon has data centers worldwide, providing disaster recovery services to recover the business IT infrastructure quickly.

• Create a snapshot of the unencrypted root volume 
• Make a copy of the snapshot and select the encrypt option 
• Create an AMI from this encrypted snapshot 
• Now use this AMI to launch a new instance with encrypted volumes 

EC2 metadata is data about your EC2 instance. Let’s see an example to understand how we can use metadata in our cloud formation template script. 

View categories of instance metadata from within a running instance using the following IPv4 or IPv6 URIs. 

IPv4 

http://169.254.169.254/latest/meta-data/ 

IPv6 

http://[fd00:ec2::254]/latest/meta-data/ 
UserData: !Base64  
  'Fn::Sub': 
    - > 
      #!/bin/bash -x 
  
      # Installing packages and files using metadata 
  
      /opt/aws/bin/cfn-init -v --stack ${AWS::StackName} --resource TestInstance 
      --region ${AWS::Region} 
  
  
      # Send the status as signal from cfn-init 
  
      /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource 
      TestInstance --region ${AWS::Region} 
    - {}

EC2 Userdata is a bootstrap script that gets executed once when the EC2 instance gets launched. Suppose we want to install an apache web server on our Linux instance; we can add the below script in our user data.

#! /bin/bash 
    sudo su 
    sudo yum update 
    sudo yum install -y httpd 
    sudo chkconfig httpd on 
    sudo service httpd start 
    echo "<h1>Deployed EC2 With Terraform</h1>" | sudo tee /var/www/html/index.html

Here is a list of default security features. 

• Security groups - This controls inbound and outgoing traffic at the instance level for EC2 instances, acting as a firewall. 
• Network access control lists – They serve as a subnet-level firewall, regulating inbound and outbound traffic.

VPC Flow Logs: The inbound and outbound traffic from the network interfaces in your VPC is recorded in flow logs.

• Authentication: It is how you sign into AWS using your credentials. As a principal, you must be authenticated (signed into AWS) using an entity (root user, IAM user, or IAM role) to send a request to AWS. An IAM user can have long-term credentials such as a username and password or a set of access keys. 
• Authorization: It is the security process that determines a user or service's level of access. In technology, we use authorization to give users or services permission to access some data or perform a particular action.

There are two models that you can use to run your containers: 

• Fargate launch type - This is a serverless pay-as-you-go option. You can run containers without needing to manage your Infrastructure. 
• EC2 launch type - Configure and deploy EC2 instances in your cluster to run your containers.

• S3 is object storage, and latency is higher than EBS and EFS; we can host/install OS or application on it 
• EBS is block storage, and it is the default storage with an Ec2 instance. We can attach 1 EBS with 1 instance.  
• EFS is Elastic File Storage. It is shared storage provided by AWS. We can attach 1 EFS with multiple Ec2 instances. 

Amazon is Amazon DAAS (Database as a Service) supports various databases like  

1. MSSql(Mysql Server) 
2. Oracle 
3. Postgres 
4. Aurora(serverless and provisioned) 
5. Maria DB 

It is similar to Aurora Database(MySQL and Postgres compatible). It's an on-demand database. In this database, we don’t have to manage/control database instances, and we need not pay the higher compute cost. It assigns compute power as required. In serverless compute capacity denote as ACU(Aurora Capacity unite) we can use mn 1 ACU(2BG RAM) to 256ACU(488GB RAM).

Internet gateways allow AWS resources/instances to connect to public internet on a public subnet, and it provides inbound and outbound traffic on AWS resources. Nat Gateway provides a connection under a private gateway; only inbound traffic is allowed on the NAT gateway.

• Network ACL: NACL stands for Network Access Control Lists. It is a security layer that works on VPC. It controls inbound and outbound internet on one or more subnets. 
• Security Group: It acts as a virtual firewall. It controls inbound and outbound traffic in instances 
• Difference: Network ACL works on the subnet level, and Security Group works on the Instance/machine level. 

In default monitoring, it monitors on a 5-minute span, and it’s free; when we enable detailed monitoring, it will start monitoring every 1-minute span. For detailed monitoring, we have to pay for this monitoring.

No, one subnet means the chunk of IP address, the pool of IP addresses that cannot expand across the availability zone. Multiple subnets can be in a single subnet. For example, there are two subnets, 10.0.1.0 and 10.0.2.0. So, these two subnets can be in EU West one B. But if there is a subnet which is 10.0.1.0, that cannot expand across a single availability zone. It means that it cannot be available within one within us East us West, one B and one A both.

One of the most frequently posed solution architect AWS interview questions, be ready for it.  

AWS Route53 is a DNS service provided by AWS, it’s a highly scalable and highly available DNS management system, and it also provides a health-check web service. 

AWS route53 components are: 

1. DNS management 
2. Traffic management 
3. Availability monitoring 
4. Domain Registration

Route53 key features are: 

1. Resolver 
2. Traffic flow 
3. Latency-based routing 
4. Geo DNS 
5. Private DNS for Amazon VPC 
6. NS Failover 
7. Health Checks and Monitoring 
8. Domain Registration 
9. CloudFront Zone Apex Support 
10. S3 Zone Apex Support 
11. Amazon ELB Integration 
12. Management Console 
13. Weighted Round Robin 

No, both are different processes altogether. EC2 performs a regular shutdown when it is stopped. While it is in a stopped state, entire EBS volumes remain associated, so it is possible to start the instance anytime again when you want. When EC2 remains in the stopped state, users don’t need to pay for that particular time. Upon EC2 termination, the instance performs a regular shutdown and starts deleting EBS, which is associated with it. To save this kind of unwanted EBS loss, you can stop them from deleting simply by setting the “Delete on Termination” to false. Because the instance gets deleted, it is not possible to run it again in the future.

A staple in AWS SA interview questions, be prepared to answer this one.  

Migrating applications and data to the AWS cloud involve the following steps:  

• Planning Phase: Before starting the migration process, it is important to plan out the migration strategy. This includes identifying the applications and data that will be migrated, assessing their dependencies and requirements, and determining the target environment in AWS.  
• Pre-discovery and discovery phase: As part of this phase, the AWS migration specialist from AWS reviews the pre-confirmation application questionnaire as per the line of business. The AWS specialist also conducts interviews with application owners to validate the server inventory by going through a series of discovery-related questions to understand network and storage dependency requirements, high availability/disaster recovery (HA/DR) data points etc. 
• Migration path: There are several different approaches to migrating applications and data to AWS, depending on the specific needs and requirements of the applications and data. Some common approaches include  
  • Relocate: Containers/VMware Cloud on AWS 
  • Rehosting: Lift and shift 
  • Replatforming: Lift and reshape 
  • Repurchasing: Replace- drop and shop 
  • Refactoring: Rewriting or decoupling applications 
  • Retain/move 
  • Retire/decommission 
• Testing & Deployment: After the on-premises applications and data have been migrated, it is important to test them to ensure they function correctly in the AWS environment, which is taken care of by the application migration service, which is part of the AWS Migration hub.

Migrating applications and data to AWS involves careful planning, preparation, and testing to ensure a smooth and successful transition to the cloud.  

Different types of routing policies in Route53 are:  

• Simple Routing Policy: When there is only one resource performing the required function for the domain, a basic routing policy, which is a straightforward round-robin strategy, may be used. Based on the values in the resource record set, Route 53 answers DNS queries.  
• Weighted Routing Policy: Traffic is sent to separate resources according to predetermined weights, such as 75% to one server and 25% to the other, with the aid of a weighted routing policy.  
• Latency-based Routing Policy: To respond to a DNS query, a latency-based routing policy determines which data center provides us with the least amount of network latency.  
• Failover Routing Policy: In an active-passive failover arrangement, one resource (the primary) receives all traffic when it is functioning normally, and the other resource (the secondary) receives all traffic when the main is malfunctioning, which is permitted by failover routing rules.  
• Geolocation Routing Policy: To reply to DNS requests based on the users' geographic locations or the location from which the DNS requests originate, a geolocation routing policy is used.  
• Geoproximity Routing Policy: Based on the physical locations of the users and the resources, proximity routing assists in directing traffic to those locations.  
• Multivalue Routing Policy: Multiple values can be returned in answer to DNS requests thanks to multivalue routings, such as the IP addresses of the web servers. 

Create a service control policy in the root organizational unit to deny access to the services or actions. 

Service Control Policy concepts - 

• Service Control Policies offer centrally managed access controls for overall IAM entities in targeted accounts. You can use them to make sure to enforce the permissions you want everyone in your business to adhere to. Using Service Control Policies, you can give your proficient developers more freedom to manage their own permissions because you know they can now only operate within the boundaries you have defined for them. 
• You create and apply Service Control Policies through Amazon web services Organizations. When you create an organization, an AWS Organization automatically creates a root first, which forms the parent container for all the accounts in your organization. Inside the root account, you can group accounts in your organization into organizational units (OUs) to simplify the management of these targeted accounts. You can create multiple organizational units within a single organization, and you can create organizational units within other OUs to form a hierarchical structure. You can attach Service Control Policies to the organization's root, organizational units, and individual accounts. Service Control Policies attached to the root and OUs apply to all OUs and accounts inside of them. 
• SCPs use the AWS Identity and Access Management (IAM) policy language; however, they do not grant permissions. Service Control Policies enable you to set permission guardrails by defining the maximum available permissions for IAM entities in an account. If a Service Control Policies denies an action for an account, none of the entities in the account can take that action, even if their IAM permissions allow them to do so. The guardrails set in Service Control Policies apply to all 
• IAM entities in the account, which include all users, roles, and the account root user. 

Create a snapshot of the database. Copy it to an encrypted snapshot. Restore the database from the encrypted snapshot.

However, because you can encrypt a copy of an unencrypted DB snapshot, you can effectively add encryption to an unencrypted DB instance. That is, you can create a snapshot of your DB instance and then create an encrypted copy of that snapshot. You can then restore a DB instance from the encrypted snapshot, and thus you have an encrypted copy of your original DB instance.

• DB instances that are encrypted can't be modified to disable encryption.
• You can't have an encrypted read replica of an unencrypted DB instance or an unencrypted read replica of an encrypted DB instance.
• Encrypted read replicas must be encrypted with the same key as the source DB instance when both are in the same AWS Region.
• You can't restore an unencrypted backup or snapshot to an encrypted DB instance.
• To copy an encrypted snapshot from one AWS Region to another, you must specify the KMS key identifier of the destination AWS Region. This is because KMS encryption keys are specific to the AWS Region that they are created.

With target-tracking scaling policies, you select a scaling metric and set a target value. Amazon EC2 Autoscaling creates and manages the CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustments based on the metric and the target value. The scaling policy adds or removes capacity as required to keep the metric at, or close to, the specified target value. In addition to keeping the metric close to the target value, a target tracking scaling policy also adjusts to changes in the metric due to a changing load pattern. For example, you can use target tracking scaling to Configure a target tracking scaling policy to keep the average aggregate CPU utilization of your Auto Scaling group at 40 percent. Configure a target tracking scaling policy to keep the request count per target of your Application Load Balancer target group at 1000 for your Autoscaling group.

With target-tracking scaling policies, you select a scaling metric and set a target value. Amazon EC2 Autoscaling creates and manages the CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustments based on the metric and the target value. The scaling policy adds or removes capacity as required to keep the metric at, or close to, the specified target value. In addition to keeping the metric close to the target value, a target tracking scaling policy also adjusts to changes in the metric due to a changing load pattern. For example, you can use target tracking scaling to Configure a target tracking scaling policy to keep the average aggregate CPU utilization of your Auto Scaling group at 40 percent. Configure a target tracking scaling policy to keep the request count per target of your Application Load Balancer target group at 1000 for your Autoscaling group.

Use AWS Directory Service to create a managed Active Directory. Uninstall Active Directory on the current EC2 instance. 

Amazon Web Service Directory lets you run Microsoft Active Directory (AD) as a managed service. Amazon Web Service Directory for Microsoft Active Directory, also referred to as Amazon Web Service Managed Microsoft AD, is powered by Windows Server 2012 R2. When you target and launch this directory type, it creates a highly available pair of domain controllers connected to your AWS virtual private cloud (VPC). The domain controllers run in different AWS Availability Zones in an AWS region of your choice. Host monitoring and recovery, data replication, snapshots, and software updates are automatically configured and managed for you.

Install an Amazon web service Storage Gateway - file gateway hardware appliance on-premises to replicate the data to Amazon S3.

The perfect answer to this use case would be that we should opt for our very new Amazon FSx for Lustre. Amazon FSx for Lustre is a newly launched, fully managed service AWS based on the very well-known Lustre file system. 

This AWS Amazon FSx for Lustre provides you with a high-performance filesystem optimized for fast processing of your workloads, such as machine learning[ML], high-performance computing (HPC), video processing, financial modeling, and electronic design automation (EDA), which is very popular nowadays. 

AWS Amazon FSx for Lustre allows customers to create a Lustre filesystem on their demand and associate them to an Amazon S3(Simple Storage Service) bucket. As part of this filesystem creation, this Lustre reads the objects in the Amazon S3 buckets and adds that to the file system metadata. Any Lustre client in your AWS virtual private cloud is then able to access data, which gets cached on the high-speed Lustre filesystem. This is an ideal use case for HPC workloads because you can get the speed of an optimized and high-performant Lustre file system without having to manually manage the complexity of its deployments, optimization, and management of the Lustre cluster.

Amazon web services offer multiple options allowing you to choose based on your application or infrastructure needs.  

1. On-Demand EC2 Instances: Very popularly known as pay-as-you-go, it depends on the Amazon EC2 instance we select, there are no upfront costs, and we only pay for computing capacity per hour or per second. 
2. Spot EC2 Instances: AWS Spot EC2 Instances can be purchased for up to 90% less than on-demand rates, and these are used to host workloads that are not business-critical. 
3. Reserved EC2 Instances: Here, we can reserve our instances based on our application or new application implementation roadmaps, where we can save up to 75% on AWS EC2 Reserved Instances when compared to the cost of On-Demand Instances.  
4. Dedicated Hosts: With a dedicated host option, you purchase a whole physical host from AWS, and this host comes to you on an hourly basis billing manner similar to ec2 times are billed. 

Amazon S3 is one of the most popular and fully managed services by Amazon web service with below outstanding benefits it offers

• Simple data transfer 
• Scalability 
• Low cost 
• Flexibility 
• Security 
• Availability 
• Durability

To ensure data privacy and protection - 

• Use Encryption: Encrypt data at rest (e.g., S3, EBS) and in transit (e.g., TLS). 
• Implement IAM Policies: Apply the principle of least privilege. 
• Use VPC Security Features: Implement Security Groups and Network ACLs. 
• Enable Logging and Monitoring: Use AWS CloudTrail and CloudWatch to monitor and log activities. 
• Regularly Audit: Perform regular security assessments and audits using AWS Trusted Advisor and AWS Security Hub. 

AWS Lambda: Serverless compute service that runs code in response to events without provisioning or managing servers. It is ideal for short-duration tasks and supports automatic scaling. 

AWS Fargate: Serverless compute engine for containers that allows running Docker containers without managing servers. It is suitable for long-running applications and microservices architectures. 

To improve the performance, we can opt for a strategy where we can plan to launch an Amazon Aurora MySQL cluster with multiple read replicas, and multi-AZ enabled and configure an application to use the reader endpoint for reports. You might be aware that Amazon RDS Read Replicas for MySQL and MariaDB are now supporting multi-AZ deployments. If we combine DB Read Replicas with DB Multi-AZ enabled, you can build a resilient disaster recovery strategy and ease your DB engine upgrade process.

To achieve this scenario, we can use Amazon CloudFront with the S3 bucket as its origin. By using AWS S3(Simple Storage Service) Origins, Media Package Channels and Custom Origins for Web Distributions 

Using AWS S3 (Simple Storage Service) Buckets for Your Origin. When we configure AWS Amazon S3 as an origin for distribution, we place any number of objects that we want AWS CloudFront to deliver into the Amazon S3 bucket. Different methods can be supported by AWS S3 to get your objects into AWS S3 buckets. 

Example: - By using AWS S3 console/API/third-party tool, we can create a hierarchy structure into an S3 bucket to store the objects, just as you would with any other Amazon S3 bucket. Using an existing AWS S3 bucket as your Amazon CloudFront origin server doesn't change the AWS S3 bucket in any way, and you can still use it as you normally would to store and access AWS S3 objects at the standard AWS S3 price.

This is a frequently asked question in AWS Architect interview questions for experienced professionals.  

To accomplish this use-case, we have to provision AWS EC2 instances and configure an AWS Application Load Balancer (ALB) in the us-west-1 region. Then we need to create an accelerator in AWS Global Accelerator that would use an endpoint group that includes the AWS load balancer endpoints in both AWS Regions. Then register/configure these endpoints for endpoint groups; you can also register more than one regional resource, such as AWS Application Load Balancers (ALB), Network Load Balancers(NLB), AWS EC2 Instances, or AWS Elastic IP addresses, in each endpoint group. Then you can configure weights to allow traffic routing to each endpoint.

Use AWS Lambda to manipulate the original image to the requested customizations. Store the original and manipulated images in Amazon S3. Configure an Amazon CloudFront distribution with the S3 bucket as the origin. 

AWS Lambda supports the following scenario 

• If you would like to store your static website content or webpages or static website with Amazon S3, it provides a lot of advantages/benefits. To optimize the application's performance and security(Most important) while effectively managing our cost, it is recommended to set up Amazon CloudFront with your Amazon S3 bucket to serve and protect the content. Amazon CloudFront is nothing but a content delivery network 
• Content delivery network service(Amazon Cloudfront) that delivers video streams, APIs around the world and static and dynamic web content safely and securely at scale. As designed, delivering data out of Amazon CloudFront can be more cost-effective than delivering it from Amazon S3 directly to your users. 
• Amazon CloudFront serves content through a worldwide network of data centers known as Edge Locations. Amazon CloudFront has edge servers all around the world. Using edge servers to cache and serve content improves performance by providing content closer to where viewers are located. 

Take a Snapshot of the RDS instance. Create an encrypted copy of the snapshot. Restore the RDS instance from the encrypted snapshot 

Let's understand the steps to encrypt Amazon RDS snapshots 

Note: The steps defined below are only applicable to Amazon RDS for MySQL, Oracle, SQL Server, PostgreSQL, or MariaDB. 

1. First, we will open the Amazon RDS console and then go ahead and choose Snapshots via the navigation pane. 
2. Then, we will select the AWS RDS snapshot that we would like to encrypt. 
3. Next, we will go under Snapshot Actions and choose Copy Snapshot. 
4. Then, we will choose our destination AWS region and then enter our new DB Snapshot Identifier. 
5. Then configure Enable Encryption option to Yes. 
6. Make sure to select your Master Key from the list, and then go ahead and select Copy Snapshot. 
7. After your snapshot status is changed to available, the Encrypted field will become True to indicate to us that the snapshot is encrypted. 
8. Now, as you have an encrypted snapshot of your AWS RDS DB, you are ready to use this encrypted AWS RDS DB snapshot to restore the AWS DB instance from the AWS DB snapshot. 

Create an Amazon CloudFront distribution and configure the ALB as an origin. Then update the Amazon Route 53 record to point to the CloudFront distribution. 

What Is Amazon CloudFront? 

• Amazon CloudFront is a web service that speeds up the distribution of your static and dynamic web content, such as .html, .css, .js, and image files, to your users. 
• CloudFront delivers your content through a worldwide network of data centers called edge locations. When a user requests content that you're serving with 
• CloudFront, the user is routed to the edge location that provides the lowest latency (time delay) so that content is delivered with the best possible performance. 
• Routing traffic to an Amazon CloudFront web distribution by using your domain name. 
• If you want to speed up the delivery of your web content, you can use Amazon CloudFront, the AWS content delivery network (CDN). CloudFront can deliver your entire website ג€" including dynamic, static, streaming, and interactive content ג€" by using a global network of edge locations. Requests for your content are automatically routed to the edge location that gives your users the lowest latency. 
• To use CloudFront to distribute your content, you create a web distribution and specify settings such as the Amazon S3 bucket or HTTP server that you want 
• CloudFront to get your content from, whether you want only selected users to have access to your content, and whether you want to require users to use HTTPS.

We should choose Scheduled Reserved Instances to minimize the cost because AWS Scheduled Reserved EC2 Instances (Scheduled Ec2  Instances) enable you to buy capacity reservations that recur on a daily, weekly, or monthly basis, with a specific start time and duration, for a one-year time. You can reserve your capacity in advance so that you understand when it's available and when you would need it. You only pay for the time that the AWS EC2 instances are scheduled for, even if you do not use them. 

AWS EC2 Scheduled Instances are the best choice for the type of workloads that don’t run continuously, but they do need to be running on a regular schedule.  

For example, you can use AWS EC2 Scheduled for the following use cases. 

1. AWS EC2 Instances for a type of application that operates during business hours or for batch processing scenario that needs to be run at the end of every week. 
2. If you would require a capacity reservation as per your application needs on a continuous basis, AWS EC2 Reserved Instances might meet your needs and decrease your costs. 

Configure a Network Load Balancer in front of the EC2 instances and Configure an Auto Scaling group to add or remove instances in multiple Availability Zones automatically. Let's first understand AWS Network Load Balancer by understanding its overview - 

• An AWS Network Load Balancer(NLB) operates at the fourth layer of the Open Systems Interconnection (OSI) model. AWS NLB can handle millions of requests per second. After the AWS load balancer receives a connection request, it selects a target from the target group for the default rule. Then it attempts to open a TCP connection to the selected target on the port configured in the listener configuration. 
• When you enable an AWS Availability Zone for the AWS load balancer, Elastic Load Balancer launches a load balancer node in the AWS Availability Zone. By default, each AWS load balancer node distributes its traffic across the registered targets in its AWS Availability Zone. If you have enabled the option of cross-zone load balancing, each AWS load balancer node distributes traffic across the registered targets in all enabled AWS Availability Zones.  
• If you enable multiple AWS Availability Zones as part of your configuration for your load balancer and ensure that each target group has at least one target in each enabled Availability Zone, this increases the fault tolerance of your applications. This can be a very good option for disaster recovery scenarios. 
• An AWS Auto Scaling group is a fantastic option that contains a collection of Amazon EC2(elastic compute cloud) instances that are recognized as a logical grouping for automatic scaling and management. An AWS Auto Scaling group also provides you configuration option to use Amazon EC2 Auto Scaling features listed below 

1. Health check replacements 

2. Scaling policies 

• Both option helps us maintain the number of EC2 instances in an AWS Auto Scaling group and which does automatic scaling as the core functionality of the Amazon EC2 Auto Scaling service. 
• AWS Auto Scaling group size depends on the number of instances that you set as the desired capacity as per your application requirement or use case. You can anytime adjust its size to meet demand, either manually or by using automatic scaling.

For the presented use case, we would be opting for the AWS S3 Intelligent-Tiering option. Now the next question which comes to our mind is why we should opt for the AWS S3 Intelligent-Tiering option because AWS S3 Intelligent-Tiering is a new Amazon S3 storage class designed by AWS for customers who would like to optimize storage costs automatically based on data access patterns change, without causing any performance impact or operational overhead to the team. AWS S3 Intelligent Tiering is one of the first cloud object storage classes that helps you deliver automatic cost savings by moving your data between two access tiers, which would be “Frequent access” and “infrequent access” when access patterns change and are ideal for data with unknown or changing access patterns. 

AWS S3 Intelligent-Tiering class stores objects in two access tiers  

1. Frequent Access: Tier that is optimized for frequent access. 
2. Infrequent access: that is the lower-cost tier that is optimized for infrequent access.  

There are no retrieval fees in the AWS S3 Intelligent-Tiering class. If an S3 object in the infrequent access tier is accessed at a later time, then it is automatically moved back to the frequent access tier. Saving additional tiering fees apply when objects are moved from one access tier to another access tier within the AWS S3 Intelligent-Tiering storage class.  

Expect to come across this popular question in AWS architecture interview questions.  

AWS CloudFormation is a service that helps you model and set up your AWS resources so that you can spend less time managing those resources and more time focusing on your applications that run in AWS.  

Below are the listed benefits. 

1. Infrastructure management: For a scalable application that also consists of a backend database, to achieve high availability, you would possibly use an Auto Scaling group, an Elastic Load Balancing load balancer, and an Amazon RDS database instance. After you create the resources, you would have to configure them to work together. All these tasks can add complexity, rework and time before your application is up and running. To reduce this monotonous activity, you can create a CloudFormation template or modify an existing one. Describes all your resources and their properties as part of AWS CloudFormation templates. By using this template, you can create a CloudFormation stack, clubbing all your required resources like Auto Scaling group, load balancer, and database for you. After the stack has been successfully created, your AWS resources are up and running. You can delete the stack just as easily, which deletes all the resources in the stack. AWS CloudFormation helps you easily manage a collection of resources as a single unit. 
2. Replicate your Infrastructure: If your application requires extra availability, you may reflect it in multiple regions so that if one vicinity becomes unavailable, your customers can nevertheless use your application in different regions. The challenge in replicating your Infrastructure is that it also requires you to duplicate your sources. To avoid this rework of infrastructure replication in different regions, you can utilize your AWS CloudFormation templates to launch your Infrastructure in a consistent and repeatable manner; the main point to note here is it will also reduce human error. 
3. Control and track changes to your Infrastructure: While you provision your Infrastructure with AWS Cloudformation, the AWS Cloudformation template describes exactly what resource blocks are provisioned and their settings. Because these templates are text documents, you simply monitor differences in your templates to understand changes in your Infrastructure in a similar manner like developers hoe developers revise their source code. As an instance, you can use a VCS[GitHub, BitBucket etc.,.] or AWS Codecommit along with your templates so that you recognize exactly what changes have been done, who made them, and when. At any point in time, if you want to reverse changes to your Infrastructure, you may use a previous version of your template. 

A must-know for anyone heading into an AWS architect interview, this question is frequently asked in AWS solution architect interview questions.  

A. Stack Sets: AWS CloudFormation is used mainly for automating deployments of different applications. If your application has cross-region and multi-account deployment requirements, you should consider using Stack Sets. This will allow you to do these kinds of deployments simultaneously with ease. 

Remember, a stack set is a region-specific resource. In case you create a stack set in a single AWS region, you can only monitor and reconfigure it only while viewing it in that region. 

Stack set operations for AWS CloudFormation are as follows. 

1. Create stack set: Deploy new stack sets by defining the template based on the requirements to create your stack. 
2. Update stack set: When you update a stack set, you push changes out to stacks on your stack set 
3. Delete stacks: when you delete stacks, you're doing away with a stack and all its related resources from the goal money owed you specify in the regions you specify 
4. Delete stack set: you may delete your stack set most effectively whilst there aren't any instances in it. 

Stack set operation options for AWS CloudFormation templates are as follows 

• Maximum concurrent accounts 
• Failure tolerance 
• Retain stacks 
• Region concurrency 

a] Sequential    b] Parallel 

StackSet status code for AWS Cloudformation templates is as follows 

• RUNNING 
• SUCCEEDED 
• FAILED 
• QUEUED 
• STOPPING 
• STOPPED 

Stack instance status codes for AWS Cloudformation templates are as follows 

• CURRENT 
• OUTDATED 
• INOPERABLE 
• CANCELLED 
• FAILED 
• PENDING 
• RUNNING 
• SUCCEEDED 

B. Nested Stack: As your Infrastructure grows, there will be some cases where you need to declare the same resources to multiple CloudFormation templates. In these instances, it is a good practice to use nested stacks. You can create separate templates for these common resources and reference that on other templates. This way, you’ll avoid copying and pasting the same configuration on your templates, and this also simplifies stack updates. 

It's no surprise that this one pops up often in interview questions for AWS architect.  

• This drift detection ability of AWS Cloudformation helps you understand whether the stack’s actual configuration differs or it has drifted from its expected configuration. Cloudformation can be used to detect drift on individual sets or StackSets. 
• CloudFormation detects drift on those AWS resources that support drift detection. Resources that don't support drift detection are assigned a drift status of NOT_CHECKED. 

A common question in AWS architect interview questions, don't miss this one.  

1. CreationPolicy: Associate the “CreationPolicy” attribute with a resource to prevent its status from reaching complete until AWS CloudFormation receives a specified number of success signals or the timeout period is exceeded. To signal a resource, you can use the “cfn signal” helper script or “SingleResource” API. CloudFormation comments valid signals to the stack event viewer so that you track the number of signals sent. 
2. DeletionPolicy: With the DeletionPolicy attribute, you can preserve and, in some cases, back up a resource when its stack is deleted. You specify a DeletionPolicy attribute for each resource that you want to control. If a resource has no DeletionPolicy attribute, AWS CloudFormation deletes the resource by default. 
3. DependsOn: With the DependsOn attribute, you can specify that the creation of a specific resource follows another. When you add a DependsOn attribute to a resource, that resource is created only after the creation of the resource specified in the DependsOn attribute. 
4. Metadata: The metadata attribute enables you to associate structured data with a resource. By adding a metadata attribute to a resource, you can add data in JSON or YAML to the resource declaration. In addition, you can use intrinsic functions (such as GetAtt and Ref), parameters, and pseudo parameters within the Metadata attribute to add those interpreted values. 
5. UpdateReplacePolicy: Use the UpdateReplacePolicy attribute to retain or, in some cases, backup the existing physical instance of a resource when it's replaced during a stack update operation

One of the most frequently posed solution architect AWS interview questions, be ready for it.  

CloudFormation template sections are as follows: 

• Format Version (optional) 
• Description (optional) 
• Metadata (optional) 
• Parameters (optional) 
• Mappings (optional) 
• Conditions (optional) 
• Transform (optional) 
• Resources (required) 
• Outputs (optional)

For implementing web tier architecture in AWS Cloud, I would use the below template to launch with VPC, Subnet, NACL, Security Group, EC2 instances, elastic load balancer, ELB listener,  and target group.,  target group.

AWSTemplateFormatVersion: 2010-09-09 
Description: This template will create public subnet, public route table and associate that route table to the public subnet 
Parameters: 
  CustomVPC: 
    Description: Select One VPC available in your existing account 
    Type: AWS::EC2::VPC::Id 
    Default: "<your default VPC ID>" 
  PublicSubnet1: 
    Description: Select one public subnet available in your existing account 
    Type: AWS::EC2::Subnet::Id 
    Default: "<your default public subnet id>" 
  PublicSubnet2: 
    Description: Select one public subnet available in your existing account 
    Type: AWS::EC2::Subnet::Id 
    Default: "<your default public subnet id>" 
Resources: 
  InstanceSecurityGroup: 
    Type: AWS::EC2::SecurityGroup 
    Properties: 
      VpcId: !Ref CustomVPC 
      GroupName: "AllowEc2Traffic" 
      GroupDescription: "Enable SSH access and HTTP access on the inbound port for EC2" 
      SecurityGroupIngress: 
        - IpProtocol: tcp 
          FromPort: 80 
          ToPort: 80 
          CidrIp: 0.0.0.0/0 
        - IpProtocol: tcp 
          FromPort: 22 
          ToPort: 22 
          CidrIp: 0.0.0.0/0 
      Tags: 
        - Key: Name 
          Value: InstanceSecurityGroup 
  UbuntuInstance1: 
    Type: AWS::EC2::Instance 
    Properties: 
      KeyName: CustomVPC 
      ImageId: ami-04505e74c0741db8d 
      SubnetId: !Ref PublicSubnet1 
      InstanceType: t2.micro 
      SecurityGroupIds: 
        - !Ref InstanceSecurityGroup 
      UserData: 
        Fn::Base64:  
          !Sub | 
            #!/bin/bash 
            sudo su 
            sudo apt-get update -y 
            sudo apt-get install -y apache2 
            sudo ufw allow -y 'Apache' 
            sudo systemctl start apache2 
            sudo systemctl enable apache2         
      Tags: 
        - Key: Name 
          Value: UbuntuInstance1 
  UbuntuInstance2: 
    Type: AWS::EC2::Instance 
    Properties: 
      KeyName: CustomVPC 
      ImageId: ami-04505e74c0741db8d 
      InstanceType: t2.micro 
      SubnetId: !Ref PublicSubnet2 
      SecurityGroupIds: 
        - !Ref InstanceSecurityGroup 
      UserData: 
        Fn::Base64:  
          !Sub | 
            #!/bin/bash 
            sudo su 
            sudo apt-get update -y 
            sudo apt-get install -y apache2 
            sudo ufw allow -y 'Apache' 
            sudo systemctl start apache2 
            sudo systemctl enable apache2             
      Tags: 
        - Key: Name 
          Value: UbuntuInstance2 
  ELBTargetGroup1: 
   Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' 
   Properties: 
     HealthCheckIntervalSeconds: 6 
     HealthCheckTimeoutSeconds: 5 
     HealthyThresholdCount: 2 
     Port: 80 
     Protocol: HTTP 
     UnhealthyThresholdCount: 2 
     VpcId: !Ref CustomVPC 
     TargetType: instance 
     Targets:  
       - Id: !Ref UbuntuInstance1 
         Port: 80 
  ELBTargetGroup2: 
   Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' 
   Properties: 
     HealthCheckIntervalSeconds: 6 
     HealthCheckTimeoutSeconds: 5 
     HealthyThresholdCount: 2 
     Port: 80 
     Protocol: HTTP 
     UnhealthyThresholdCount: 2 
     VpcId: !Ref CustomVPC 
     TargetType: instance 
     Targets:  
       - Id: !Ref UbuntuInstance2 
         Port: 80 
  ELBSecurityGroup: 
    Type: AWS::EC2::SecurityGroup 
    Properties: 
      GroupName: "ELBTraffic" 
      GroupDescription: "Enable HTTP access on the inbound port for ELB" 
      VpcId: !Ref CustomVPC 
      SecurityGroupIngress: 
        - IpProtocol: tcp 
          FromPort: 80 
          ToPort: 80 
          CidrIp: 0.0.0.0/0 
        - IpProtocol: tcp 
          FromPort: 443 
          ToPort: 443 
          CidrIp: 0.0.0.0/0 
      Tags: 
        - Key: Name 
          Value: ELBSecurityGroup 
  ElasticLoadBalancer: 
    Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' 
    Properties: 
      Subnets:  
        - !Ref PublicSubnet1 
        - !Ref PublicSubnet2 
      SecurityGroups:  
        - !Ref ELBSecurityGroup 
  ElbListener1: 
   Type: 'AWS::ElasticLoadBalancingV2::Listener' 
   Properties: 
     DefaultActions: 
       - Type: forward 
         TargetGroupArn: !Ref ELBTargetGroup1 
     LoadBalancerArn: !Ref ElasticLoadBalancer 
     Port: '8000' 
     Protocol: HTTP 
  ElbListener2: 
   Type: 'AWS::ElasticLoadBalancingV2::Listener' 
   Properties: 
     DefaultActions: 
       - Type: forward 
         TargetGroupArn: !Ref ELBTargetGroup2 
     LoadBalancerArn: !Ref ElasticLoadBalancer 
     Port: '9000' 
     Protocol: HTTP 
Outputs: 
  outputInstanceSecurityGroup: 
    Description: A reference to the created security group 
    Value: !Ref InstanceSecurityGroup 
  outputUbuntuInstance: 
    Description: A reference to the created EC2 Instance 
    Value: !Ref UbuntuInstance1 
  outputUbuntuInstance: 
    Description: A reference to the created EC2 Instance 
    Value: !Ref UbuntuInstance2 
  outputELBTargetGroup: 
    Description: A reference to the created Target Group 
    Value: !Ref ELBTargetGroup1 
  outputELBTargetGroup: 
    Description: A reference to the created Target Group 
    Value: !Ref ELBTargetGroup2 
  outputELBSecurityGroup: 
    Description: A reference to the created Security Group 
    Value: !Ref ELBSecurityGroup 
  outputElasticLoadBalancer: 
    Description: A reference to the created Elastic Load Balancer 
    Value: !Ref ElasticLoadBalancer 
  outputElasticListener: 
    Description: A reference to the created Elastic Load Balancer Listener 
    Value: !Ref ElbListener1 
  outputElasticListener: 
    Description: A reference to the created Elastic Load Balancer Listener 
    Value: !Ref ElbListener2 

To design a multi-region, multi-master database - 

• Use Amazon Aurora Global Database: It supports multi-master replication across regions with low-latency reads and high-speed writes. 
• Implement Data Replication: Ensure real-time data synchronization across regions using AWS Database Migration Service (DMS) or native database replication features. 
• Design for Fault Tolerance: Use Route 53 for DNS failover, implement multi-region read replicas, and ensure that your application can handle regional failures gracefully. 
• Ensure Data Consistency: Use conflict resolution strategies and ensure data integrity through transactional support. 

To optimize AWS Lambda functions - 

• Minimize Cold Starts: Use Provisioned Concurrency to keep functions warm. 
• Optimize Code: Reduce dependencies and package size, and use efficient algorithms. 
• Adjust Memory Allocation: Allocate appropriate memory to reduce execution time, which can also reduce costs. 
• Leverage Environment Variables: Store configuration settings in environment variables to avoid redeploying code. 
• Monitor and Analyze Performance: Use AWS CloudWatch to monitor execution times, errors, and other performance metrics. 

To manage and optimize costs - 

• Use Cluster Autoscaler: Automatically adjusts the size of your Kubernetes cluster based on the demands. 
• Right-size Nodes: Choose appropriate instance types and sizes for your workloads. 
• Use Spot Instances: Run non-critical workloads on spot instances to reduce costs. 
• Leverage AWS Savings Plans: Commit to a consistent amount of usage for significant savings. 
• Monitor Resource Utilization: Use tools like Prometheus and Grafana to monitor and analyze resource usage and optimize accordingly.