diff --git a/day-2/README.md b/day-002/README.md similarity index 100% rename from day-2/README.md rename to day-002/README.md diff --git a/day-2/interview-questions b/day-002/interview-questions similarity index 100% rename from day-2/interview-questions rename to day-002/interview-questions diff --git a/day-3/README.md b/day-003/README.md similarity index 100% rename from day-3/README.md rename to day-003/README.md diff --git a/day-4/README.md b/day-004/README.md similarity index 100% rename from day-4/README.md rename to day-004/README.md diff --git a/day-5/README.md b/day-005/README.md similarity index 100% rename from day-5/README.md rename to day-005/README.md diff --git a/day-006/README.md b/day-006/README.md new file mode 100644 index 000000000..03c011c78 --- /dev/null +++ b/day-006/README.md @@ -0,0 +1,21 @@ +Here is a quick recap of AWS Route 53 based on the sources, presented point-wise for your interview preparation: + +* **What is Route 53?** AWS provides **DNS (Domain Name System) as a service** through Route 53. Think of it like AWS providing compute as a service (EC2) or Kubernetes as a service (EKS). +* **What is DNS?** DNS stands for Domain Name System. Its primary function is to **map human-readable domain names (like amazon.com or flipkart.com) to computer-readable IP addresses**. +* **Why is DNS needed?** + * **Ease of use:** Domain names are much **easier for people to remember** than complex IP addresses like `3.6.10.171`. + * **Flexibility:** IP addresses can **change** (they can be dynamic). Using a domain name provides a stable address even if the underlying IP address changes. +* **How DNS works (Simply put):** A DNS service **keeps records** that map a domain name to its corresponding IP address. +* **How Route 53 fits into AWS architecture:** + * In a typical setup (like applications in a private subnet behind a load balancer in a public subnet), when a user tries to access an application using its domain name (e.g., amazon.com), **Route 53 is the first service to intercept the request**. + * Route 53 looks up the domain name in its records to find the associated IP address, usually the **IP address of a load balancer**. + * Once the domain name is resolved to the IP address, the request is **forwarded to the load balancer** (and then typically to the application instances). +* **Key Components/Features of Route 53:** + * **Domain Registration:** You can **register (buy) domain names directly through AWS Route 53**. You can also integrate domain names purchased from other registrars (like GoDaddy). + * **Hosted Zones:** This is a critical concept in Route 53. **Hosted zones contain the DNS records** for a specific domain name. When Route 53 receives a request for a domain name, it looks for the DNS records in the relevant hosted zone (which can be public or private) to resolve the domain name to an IP address. + * **DNS Records:** These are the actual mappings within a hosted zone that **link a domain name or subdomain to an IP address** or other destination. + * **Health Checks:** Route 53 can **monitor the health of your web applications or web servers** (e.g., checking if they are active every minute or five minutes). It can use this information to determine where to forward requests, potentially performing some kind of balancing across healthy servers. + +Route 53 simplifies the complex process of managing DNS, especially when hosting applications on AWS.# Route53 + +TODO diff --git a/day-7/vpc-demo-2-tier-app b/day-007/vpc-demo-2-tier-app similarity index 100% rename from day-7/vpc-demo-2-tier-app rename to day-007/vpc-demo-2-tier-app diff --git a/day-8/Interview_q&a b/day-008/Interview_q&a similarity index 100% rename from day-8/Interview_q&a rename to day-008/Interview_q&a diff --git a/day-009/Quick-Interview-Recap.md b/day-009/Quick-Interview-Recap.md new file mode 100644 index 000000000..47f86294b --- /dev/null +++ b/day-009/Quick-Interview-Recap.md @@ -0,0 +1,22 @@ +**AWS S3 Quick Interview Recap** + +| Concept | Description | Key Detail/Benefit | +| --- | --- | --- | +| **What is S3?** | Amazon S3 stands for **Simple Storage Service**. It is a **storage service** provided by AWS. | It is one of the most **easy services to learn** on AWS. Many people start their AWS journey with S3 because it's simple to understand and execute. | +| **Purpose** | S3 solves the very common problem of **storage** for organizations. | Organizations deal with large amounts of data like heavy databases, continuous backups, application logs, dashboards, chats, CSV files, and Excel sheets. S3 provides a solution for where organizations can save all these things, especially when moving to the public cloud. | +| **Key Characteristics** | S3 possesses five important characteristics. | These are **highly scalable, highly available, security, cost efficiency, and performance**. These characteristics are major factors behind S3's popularity. | +| **Reliability & Durability** | How robust S3 is against data loss. | S3 is **99.999999999% (Eleven Nines)** reliable and durable. If you upload one billion objects over 100 years, you can expect **only one object to potentially be lost**. This is achieved by creating **multiple replicas** of objects across different Availability Zones and Data Centers within a region. Your data is almost guaranteed to never get deleted. | +| **Availability** | How often the data stored in S3 is accessible. | S3 Standard storage class offers **99.9% availability**. | +| **Scalability** | The ability of S3 to handle vast and growing amounts of data. | S3 is **highly scalable**. There is **no restriction on the amount of data** that can be stored in an S3 bucket. You can keep uploading as much data as required, and AWS S3 will not restrict you. | +| **Objects & Buckets** | The fundamental components of S3 storage. | A **Bucket** is what you create in the S3 service, acting as a container for your data. An **Object** is anything you store inside a bucket, such as pictures, videos, files, folders, Excel sheets, reports, application logs, database dumps, configuration files, etc.. **Each object cannot be more than 5 TB** in size, but you can store multiple objects. | +| **Bucket Naming** | The rules for naming an S3 bucket. | S3 bucket names **must be globally unique** across all AWS accounts. This is because anything uploaded to S3 can be globally accessible. DevOps engineers often use a naming standard to ensure uniqueness. | +| **Regional Scope** | Although content is globally accessible, buckets are tied to a specific AWS region. | S3 buckets are **scoped in a region**, similar to EC2 instances. You select a region when creating a bucket. Choosing a region nearer to the users can result in **less latency**. | +| **Global Accessibility** | How data stored in S3 can be reached from anywhere. | Content put on S3 is **globally accessible**. Objects can be accessed using the **HTTP/HTTPS protocol** via a URL. You can share the URL and grant permissions for access. | +| **Public Access Block** | A security feature to prevent accidental public exposure of data. | By default, **Public Access is blocked** for new buckets. This is highly recommended to keep enabled, especially for sensitive data. You must **disable this block** if you intend to host a public static website. | +| **Security Features** | Mechanisms to secure data stored in S3. | S3 offers various security options including **encryption** (at rest and in transit), Access Control Lists (ACLs), **Bucket Policies** to restrict permissions, Object Locking, and **Access Logging** to monitor who accesses buckets. These allow fine-grained control over who can access your data. | +| **Cost Efficiency** | How the cost of using S3 compares to other storage options. | AWS S3 is considered **very cheap and cost-effective**. The cost depends on the **storage class** selected. Hosting a static website on S3 can be very cheap compared to other platforms. | +| **Storage Classes** | Different options for storing data based on access frequency and cost requirements. | S3 offers **multiple storage classes** (e.g., Standard, Standard-IA, Glacier, Deep Archive). The choice depends on whether you prioritize **cost effectiveness or access time**. Glacier Deep Archive is the cheapest but has the longest retrieval time (12-48 hours). | +| **Performance** | The speed at which data can be uploaded to and downloaded from S3. | S3 offers good performance. Using a bucket in a nearby region reduces latency. S3 supports **Multi-Part Uploads**, which helps upload large files efficiently and can retry parts if there are interruptions. | +| **Versioning** | A feature that allows keeping multiple versions of an object. | S3 supports **versioning**. When enabled on a bucket, S3 keeps a copy of the previous version whenever an object is modified or deleted. This allows you to **retrieve old versions** of objects. Versioning can be combined with storage classes and lifecycle policies for cost management (e.g., moving old versions to cheaper storage or deleting them). | +| **Static Website Hosting** | Using an S3 bucket to host a static website. | S3 can host static websites because its content is globally accessible. This requires enabling the static website hosting option on the bucket properties, specifying an index document (like `index.html`), disabling the 'Block All Public Access' setting, and adding a **bucket policy** to allow public `s3:GetObject` permissions. It is a **cheap solution** for hosting static sites. **CORS** might need to be enabled for JavaScript making external API calls. | +| **Bucket Policies** | JSON documents used to grant or deny permissions for accessing S3 buckets and their objects at the bucket level. | Bucket policies are a crucial part of S3 **permissions**. They allow you to control access even for users who might have broad S3 permissions via IAM. For example, you can use a bucket policy to **restrict access for everyone except the bucket owner**. You can use a policy generator to help write the JSON. This is an important responsibility for devops engineers. | diff --git a/day-9/README.md b/day-009/README.md similarity index 100% rename from day-9/README.md rename to day-009/README.md diff --git a/day-9/demos/bucket-policies/restrict-access-to-owner.json b/day-009/demos/bucket-policies/restrict-access-to-owner.json similarity index 100% rename from day-9/demos/bucket-policies/restrict-access-to-owner.json rename to day-009/demos/bucket-policies/restrict-access-to-owner.json diff --git a/day-9/demos/bucket-policies/static-website-basic.json b/day-009/demos/bucket-policies/static-website-basic.json similarity index 100% rename from day-9/demos/bucket-policies/static-website-basic.json rename to day-009/demos/bucket-policies/static-website-basic.json diff --git a/day-011/Readme.md b/day-011/Readme.md new file mode 100644 index 000000000..c63fb66d5 --- /dev/null +++ b/day-011/Readme.md @@ -0,0 +1,18 @@ +structured table summarizing the key concepts about AWS CloudFormation Templates (CFT) and related topics based on the provided sources: + +| Concept | Description | Key Detail/Benefit | +| :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **AWS CFT** | AWS CloudFormation Templates. A template-based service on AWS used to **create, manage, and update cloud infrastructure** on AWS. Implements the principles of Infrastructure as Code (IaC). Takes declarative and versioned templates (YAML or JSON) from the user and converts them into AWS API calls. Only targets AWS. | Helps in **automating the creation of AWS resources and entire infrastructure stacks**. A **service on AWS** itself. Converts user-friendly template definitions into the necessary API calls for AWS. **Preferred tool for creating actual resources or huge stacks** compared to AWS CLI. | +| **IaC (Infrastructure as Code)** | A principle where you write code (or templates) to create infrastructure. Tools that follow this principle (like CFT, Terraform) act as a **middleman between the user and cloud provider(s)**. Users submit declarative and versioned templates (e.g., YAML, JSON) to the tool. The tool translates these templates into API calls that the cloud provider understands. | **Automates infrastructure creation and management** programmatically. Allows users to manage infrastructure without needing to know how to make direct API calls. Tools implement the **principles of declarative and versioned templates**. **CFT implements this principle**. | +| **AWS CLI** | AWS Command Line Interface [from conversation history]. A tool that can be used to manage and create infrastructure on AWS. Does not implement the principles of IaC. | **Very important for quick, short actions** or simple scripts. Useful for getting details about AWS resources quickly (e.g., listing S3 buckets). In scenarios requiring rapid simple tasks, CLI is preferred over writing and executing a CFT template. **Not ideal for creating complicated stacks or combinations of resources**. | +| **API Calls** | The programmatic language understood by cloud providers (like AWS) for creating, deleting, and managing resources. | IaC tools like CFT and Terraform **convert user templates/commands into API calls** to interact with the cloud provider. Users interact with the IaC tool, not directly with the API calls. | +| **Declarative Template** | A key principle of IaC. Describes the desired state of the infrastructure ("what you see is what you have"). When you look at a declarative template, you should understand exactly what resources will be created or are available on the cloud provider. CFT templates are declarative. | **Simplifies understanding of the infrastructure** by reading the template. Makes **code review and auditing easy**. Users define *what* they want, and the IaC tool figures out *how* to achieve that state [implied by "what you see is what you have"]. | +| **Versioned Template** | A key principle of IaC. Templates can be stored in version control systems (like Git) or storage services (like S3). Allows tracking changes over time and reverting to previous versions. AWS automatically saves CFT templates in a random S3 bucket. | **Provides a history of infrastructure changes**. **Enables collaboration** and easier management of infrastructure configurations within a team. Helps maintain consistency and track modifications. | +| **CFT Stacks** | A concept within the AWS CloudFormation service. When you write a CFT template, you **submit it to a stack**. The stack acts as the entity that implements the template and manages the resources defined within it. | **Manages a collection of related AWS resources as a single unit** [implied by "huge tags" and "group of resource"]. Allows creating, updating, and deleting a set of resources together by managing the stack. Can be initiated via the AWS UI or CLI. | +| **CFT Structure/Components** | The predefined format and sections within a CFT template (YAML or JSON). Includes optional sections like Version, Description, Metadata, Parameters, Rules, Mappings, Conditions, and Outputs, and a **mandatory Resources section**. | Provides a **standardized way to define infrastructure** as code. The **Resources section is the most important and only mandatory part**, defining the specific AWS resources to be created (e.g., `AWS::EC2::Instance`, `AWS::S3::Bucket`). Optional sections like Parameters, Rules, and Outputs add **flexibility, control, and useful information**. Helps teams understand and work with templates efficiently. | +| **CFT Template Format (YAML vs. JSON)** | CloudFormation templates can be written in either YAML or JSON format. | **YAML is generally preferred and recommended** due to better readability (indentation-based like Python), support for commenting, and wider use in the DevOps world (Kubernetes, Ansible). JSON is also supported but lacks commenting and can be harder to read due to brackets. | +| **CFT Drift Detection** | A feature of AWS CloudFormation that allows checking if the actual configuration of resources in a stack has drifted (changed) from the configuration defined in the original CFT template. Detects unexpected manual modifications to resources. | **Crucial for maintaining infrastructure consistency**. **Helps identify unauthorized or unintentional changes** made to resources outside of the CloudFormation process. Provides details on *what* has changed (e.g., enabled vs. suspended versioning on an S3 bucket). Important for managing hundreds/thousands of resources where manual checks are impractical. | +| **CFT Designer** | A feature in the AWS CloudFormation UI that provides a visual, drag-and-drop interface for creating and modifying templates. Can generate templates in either JSON or YAML format. | Useful for **beginners** to visualize resource relationships and generate basic template code without writing from scratch. Can help in understanding the structure of a template. | +| **AWS CloudFormation Documentation** | The official AWS documentation for the CloudFormation service. Contains theoretical explanations, examples, and detailed references. Includes sections on template formats, template anatomy, and resource/property references for all AWS services. | Considered **one of the best documentations** for an AWS service. **Essential for learning and mastering CFT**, providing detailed information on syntax, parameters, and properties. Contains **copy-pasteable examples** for various resources. Highly recommended for users to explore. | +| **Terraform (vs. CFT)** | An Infrastructure as Code tool. | **Supports multiple cloud providers** (multi-cloud/hybrid cloud environments) like AWS, Azure, and on-premises. Often preferred over CFT if an organization uses or plans to use more than just AWS. Considered by some as a "tool for the future" compared to CFT. If an organization is strictly on AWS, CFT is a valid choice. | +| **VS Code Plugins (YAML & AWS Toolkit)** | Extensions available for the Visual Studio Code editor. The YAML plugin (by Red Hat) helps with YAML syntax and indentation. The AWS Toolkit plugin assists with interacting with AWS services, including helping write CloudFormation templates. | **Significant help in writing CFT templates efficiently**. The YAML plugin assists with correct formatting. The AWS Toolkit provides suggestions for resource types and properties while writing template code, **reducing the need to constantly reference documentation**. Makes the process of writing templates quicker and easier. | \ No newline at end of file diff --git a/day-14/README.md b/day-014/README.md similarity index 100% rename from day-14/README.md rename to day-014/README.md diff --git a/day-14/simple-python-app/Dockerfile b/day-014/simple-python-app/Dockerfile similarity index 100% rename from day-14/simple-python-app/Dockerfile rename to day-014/simple-python-app/Dockerfile diff --git a/day-14/simple-python-app/app.py b/day-014/simple-python-app/app.py similarity index 100% rename from day-14/simple-python-app/app.py rename to day-014/simple-python-app/app.py diff --git a/day-14/simple-python-app/appspec.yml b/day-014/simple-python-app/appspec.yml similarity index 100% rename from day-14/simple-python-app/appspec.yml rename to day-014/simple-python-app/appspec.yml diff --git a/day-14/simple-python-app/buildspec.yml b/day-014/simple-python-app/buildspec.yml similarity index 100% rename from day-14/simple-python-app/buildspec.yml rename to day-014/simple-python-app/buildspec.yml diff --git a/day-14/simple-python-app/requirements.txt b/day-014/simple-python-app/requirements.txt similarity index 100% rename from day-14/simple-python-app/requirements.txt rename to day-014/simple-python-app/requirements.txt diff --git a/day-14/simple-python-app/start_container.sh b/day-014/simple-python-app/start_container.sh similarity index 100% rename from day-14/simple-python-app/start_container.sh rename to day-014/simple-python-app/start_container.sh diff --git a/day-14/simple-python-app/stop_container.sh b/day-014/simple-python-app/stop_container.sh similarity index 100% rename from day-14/simple-python-app/stop_container.sh rename to day-014/simple-python-app/stop_container.sh diff --git a/day-16/README.md b/day-016/README.md similarity index 100% rename from day-16/README.md rename to day-016/README.md diff --git a/day-16/custom_metrics_demo/cloudwatch_metrics.py b/day-016/custom_metrics_demo/cloudwatch_metrics.py similarity index 100% rename from day-16/custom_metrics_demo/cloudwatch_metrics.py rename to day-016/custom_metrics_demo/cloudwatch_metrics.py diff --git a/day-16/custom_metrics_demo/requirements.txt b/day-016/custom_metrics_demo/requirements.txt similarity index 100% rename from day-16/custom_metrics_demo/requirements.txt rename to day-016/custom_metrics_demo/requirements.txt diff --git a/day-16/default_metrics_demo/cpu_spike.py b/day-016/default_metrics_demo/cpu_spike.py similarity index 100% rename from day-16/default_metrics_demo/cpu_spike.py rename to day-016/default_metrics_demo/cpu_spike.py diff --git a/day-17/README.md b/day-017/README.md similarity index 100% rename from day-17/README.md rename to day-017/README.md diff --git a/day-18/README.md b/day-018/README.md similarity index 100% rename from day-18/README.md rename to day-018/README.md diff --git a/day-18/ebs_stale_snapshosts.py b/day-018/ebs_stale_snapshosts.py similarity index 100% rename from day-18/ebs_stale_snapshosts.py rename to day-018/ebs_stale_snapshosts.py diff --git a/day-19/README.md b/day-019/README.md similarity index 100% rename from day-19/README.md rename to day-019/README.md diff --git a/day-20/README.md b/day-020/README.md similarity index 100% rename from day-20/README.md rename to day-020/README.md diff --git a/day-21/Dockerfile b/day-021/Dockerfile similarity index 100% rename from day-21/Dockerfile rename to day-021/Dockerfile diff --git a/day-21/README.md b/day-021/README.md similarity index 100% rename from day-21/README.md rename to day-021/README.md diff --git a/day-21/app.py b/day-021/app.py similarity index 100% rename from day-21/app.py rename to day-021/app.py diff --git a/day-21/commands.md b/day-021/commands.md similarity index 100% rename from day-21/commands.md rename to day-021/commands.md diff --git a/day-21/requirements.txt b/day-021/requirements.txt similarity index 100% rename from day-21/requirements.txt rename to day-021/requirements.txt diff --git a/day-22/2048-app-deploy-ingress.md b/day-022/2048-app-deploy-ingress.md similarity index 100% rename from day-22/2048-app-deploy-ingress.md rename to day-022/2048-app-deploy-ingress.md diff --git a/day-22/README.md b/day-022/README.md similarity index 100% rename from day-22/README.md rename to day-022/README.md diff --git a/day-22/alb-controller-add-on.md b/day-022/alb-controller-add-on.md similarity index 100% rename from day-22/alb-controller-add-on.md rename to day-022/alb-controller-add-on.md diff --git a/day-22/configure-oidc-connector.md b/day-022/configure-oidc-connector.md similarity index 100% rename from day-22/configure-oidc-connector.md rename to day-022/configure-oidc-connector.md diff --git a/day-22/installing-eks.md b/day-022/installing-eks.md similarity index 100% rename from day-22/installing-eks.md rename to day-022/installing-eks.md diff --git a/day-22/prerequisites.md b/day-022/prerequisites.md similarity index 100% rename from day-22/prerequisites.md rename to day-022/prerequisites.md diff --git a/day-22/sample-app.md b/day-022/sample-app.md similarity index 100% rename from day-22/sample-app.md rename to day-022/sample-app.md diff --git a/day-24/main.tf b/day-024/main.tf similarity index 100% rename from day-24/main.tf rename to day-024/main.tf diff --git a/day-24/provider.tf b/day-024/provider.tf similarity index 100% rename from day-24/provider.tf rename to day-024/provider.tf diff --git a/day-24/userdata.sh b/day-024/userdata.sh similarity index 100% rename from day-24/userdata.sh rename to day-024/userdata.sh diff --git a/day-24/userdata1.sh b/day-024/userdata1.sh similarity index 100% rename from day-24/userdata1.sh rename to day-024/userdata1.sh diff --git a/day-24/variables.tf b/day-024/variables.tf similarity index 100% rename from day-24/variables.tf rename to day-024/variables.tf diff --git a/day-25/README.md b/day-025/README.md similarity index 100% rename from day-25/README.md rename to day-025/README.md diff --git a/day-25/lambda_function.py b/day-025/lambda_function.py similarity index 100% rename from day-25/lambda_function.py rename to day-025/lambda_function.py diff --git a/day-25/lambda_function_permissions.md b/day-025/lambda_function_permissions.md similarity index 100% rename from day-25/lambda_function_permissions.md rename to day-025/lambda_function_permissions.md diff --git a/day-6/README.md b/day-6/README.md deleted file mode 100644 index a6c40c6ef..000000000 --- a/day-6/README.md +++ /dev/null @@ -1,3 +0,0 @@ -# Route53 - -TODO