Category: Blogs

Blogs

Amazon Elastic File System

A Comprehensive Overview Amazon Elastic File System: Shared File Storage for Your AWS Workloads

Amazon Elastic File System (Amazon EFS) provides a fully managed service that enables easy file storage management for applications and workloads on AWS. In the blog, we will provide an overview of EFS architecture, key features, and how it compares to other storage options.

There are multiple storage offerings in AWS, each designed to meet different storage needs. Some of the most popular storage solutions include:

AWS S3 (Simple Storage Service)
AWS EBS (Elastic Block Store)
AWS EFS (Elastic File System)

What is Amazon EFS

Amazon Elastic File System (EFS) is a scalable, fully managed, cloud-based file storage service provided by Amazon Web Services. It is designed to work with Linux-based workloads and can be mounted on Amazon EC2 instances, containers (ECS), and AWS Lambda functions across multiple Availability Zones within an AWS region.

AWS EFS Architecture

Amazon Elastic File System (EFS) is AWS’s implementation of NFS (Network File System) v4. With Amazon EFS, you can grow and shrink storage automatically as you add or remove files, providing read-after-write consistency for your data.

Amazon EFS file systems can be accessed by multiple compute instances like EC2, ECS, or Lambda within a VPC in various Availability Zones (AZs) within an AWS region. Additionally, Amazon EFS can connect to multiple VPCs via VPC Peering connections and can even be accessed from on-premises environments through VPN or Direct Connect.

Mount Targets

A mount target in Amazon EFS is an endpoint that allows EC2 instances to connect to and access an EFS file system. Each mount target is associated with a specific Availability Zone (AZ) and provides network access to the EFS file system within that zone.

Key Features of Mount Targets in EFS:

Per AZ Mount Target: To access an EFS file system from EC2 instances in a specific AZ, you must create a mount target in that AZ, enabling VPC-based connectivity.

Security Group Control: Each mount target can have its security group attached to control traffic. Typically, you must allow inbound traffic on NFS port 2049 from EC2 instances accessing the EFS.

Highly Available: By creating a mount target in each AZ, EFS ensures high availability and fault tolerance.

For standard Amazon EFS file systems, you need to create a mount target in each AZ within your AWS region.

When using the One Zone storage class, however, only a single mount target can be created in the AZ where the file system is located.

Throughput Modes

Amazon offers two throughput modes:

Bursting mode: This is the default and allows throughput to scale based on the amount of data stored.

Provisioned mode: Suitable for applications that require higher throughput than what is provided by bursting mode.

Performance Modes

There are two performance modes available for Amazon EFS:

General Purpose (recommended): Best for most workloads and is ideal for latency-sensitive applications.

Max I/O: Designed for use cases where many EC2 instances are accessing the file system simultaneously, such as big data and media processing applications.

Amazon EBS vs EFS: A Key Comparison

Both Amazon EBS and Amazon EFS offer storage solutions, but they are designed for different purposes. Amazon EBS is a block storage solution used for a single EC2 instance and is ideal for high-performance storage, whereas Amazon EFS is designed for shared file storage across multiple EC2 instances, providing elastic scalability without manual intervention.

If you’re choosing between Amazon EBS vs EFS, EFS is the better option for shared storage and file-based workloads, while EBS is optimal for individual instances with higher performance needs.

When to Use Amazon EFS

Amazon Elastic File System is an ideal solution for workloads that require scalable, shared file storage. Whether you’re running an application in AWS Lambda, working on big data analysis, or simply need shared storage for multiple EC2 instances, Amazon EFS provides a reliable, fully managed, and elastic solution.

Conclusion

Amazon Elastic File System (EFS) is robust and scalable. With its elastic capabilities, seamless AWS integration, and strong security features, Amazon EFS is ideal for a wide range of cloud storage needs.

Thanks for reading and stay tuned for more.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at sales@accendnetworks.com.

Thank you!

Tags AWS, AWS Cloud, AWS Cloud Computing, AWS Cloud Security, AWS Cloud Services

Blogs

Comprehensive Guide to AWS Code Build

Post author By Lino Almojela
Post date October 18, 2024
No Comments on Comprehensive Guide to AWS Code Build

Comprehensive Guide to AWS Code Build: Features, Setup, and Best Practices

In modern software development, automating the process of building, testing, and deploying applications is key to streamlining workflows. AWS CodeBuild, part of AWS’s continuous integration and delivery (CI/CD) suite, plays a significant role in automating the build process. It compiles source code, runs tests, and produces deployable software packages in a highly scalable, managed environment so read on as we provide comprehensive guide to AWS Code Build in this blog.

What is AWS CodeBuild?

AWS CodeBuild is a fully managed build service that compiles source code, runs tests, and produces software packages that are ready to deploy. With CodeBuild, you don’t need to worry about provisioning and managing your build infrastructure. You simply provide your build project’s source code and build settings, and CodeBuild handles the rest.

For example, if you have a web application that you want to deploy, you can use CodeBuild to compile your source code, run unit tests, and produce a deployable package. You can also use CodeBuild to build Docker images, run static code analysis, and more. CodeBuild integrates with other AWS services like Code Pipeline, so you can easily automate your entire software release process.

Build Projects and Builds

A build project defines how AWS CodeBuild runs a build. It includes information such as where to get the source code, the build environment to use, the build commands to run, and where to store the build output. A build refers to the process of transforming the source code into executable code by following the instructions defined in the build project.

Key Features of AWS CodeBuild

Automated Builds: Compiles source code and packages it for deployment automatically.

CI/CD Integration: Works seamlessly with AWS CodePipeline to automate your entire CI/CD workflow.

Scalability: Automatically scales to meet the demands of your project, ensuring there are no build queues.

Pay-As-You-Go Pricing: You are only charged for the compute time you use during the build process.

How does AWS CodeBuild Work?

AWS CodeBuild uses a three-step process to build, test, and package source code:

Fetch the source code: CodeBuild can fetch the source code from a variety of sources, including GitHub, Bitbucket, or even Amazon S3.

Run the build: CodeBuild executes the build commands specified in the Buildspec.yaml file. These commands can include compilation, unit testing, and packaging steps.

Store build artifacts: Once the build is complete, CodeBuild stores the build artifacts in an Amazon S3 bucket or another specified location. The artifacts can be used for deployment or further processing.

What is the Buildspec.yaml file for Codebuild?

The Buildspec.yaml file is a configuration file used by AWS CodeBuild to define how to build and deploy your application or software project. It is written in YAML format and contains a series of build commands, environment variables, settings, and artifacts that CodeBuild will use during the build process.

Steps to consider when planning a build with AWS CodeBuild

Source Control: Choose your source control system (e.g., GitHub, Bitbucket) and decide how changes in this repository will trigger builds.

Build Specification: Define a buildspec.yml file for CodeBuild, specifying the build commands, environment variables, and output artifacts.

Environment: Select the appropriate build environment. AWS CodeBuild provides prepackaged build environments for popular programming languages and allows you to customize environments to suit your needs.

Artifacts Storage: Decide where the build artifacts will be stored, typically in Amazon S3, for subsequent deployment or further processing.

Build Triggers and Rules: Configure build triggers in CodePipeline to automate the build process in response to code changes or on a schedule.

VPC: Integrating AWS CodeBuild with Amazon Virtual Private Cloud (VPC) allows you to build and test your applications within a private network, which can access resources within your VPC without exposing them to the public internet.

Conclusion:

AWS CodeBuild is an excellent solution for developers and DevOps teams looking to automate the build process in a scalable, cost-effective manner. Whether you’re managing a small project or handling complex builds across multiple environments, AWS CodeBuild ensures that your software is always built and tested with the latest code changes.

Thanks for reading and stay tuned for more.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at sales@accendnetworks.com.

Thank you!

Tags AWS, AWS Cloud, AWS Cloud Computing, AWS Cloud Security, AWS Cloud Services

Blogs

Control and Optimize Cloud Expenses

Post author By Lino Almojela
Post date October 12, 2024
3 Comments on Control and Optimize Cloud Expenses

Control and Optimize Cloud Expenses: Best Practices for Cost Management

Amazon Web Services (AWS) provides many cloud services that help businesses grow and create new things quickly. But with so many options, it can be hard to manage costs. Understanding how AWS billing works is important to avoid surprise charges and make the best use of cloud resources. In this article, we explain AWS billing and give simple tips to help you control and optimize cloud expenses.

AWS Billing Overview

AWS charges customers based on usage, meaning that costs can vary depending on the services consumed and the way resources are used. Here’s a breakdown of key concepts in AWS billing:

Pay-As-You-Go Model

AWS operates on a pay-as-you-go model, meaning that you only pay for what you use. This provides flexibility but can also lead to unpredictable costs if not properly managed. Billing is typically based on:

Compute: Charges for EC2 instances, Lambda executions, and other compute services.

Storage: Costs for services like S3, EBS (Elastic Block Store), and Glacier.

Data Transfer: Costs related to transferring data between AWS regions or out to the internet.

Free Tier
AWS offers a Free Tier that allows new customers to explore AWS services without incurring costs. This includes limited usage for services like EC2, S3, and Lambda for 12 months, and certain services that remain free within usage limits.
Reserved Instances (RI)
For predictable workloads, AWS offers Reserved Instances, which allow you to reserve capacity in advance for a reduced hourly rate. These provide significant savings (up to 72%) compared to on-demand pricing.
Savings Plans
AWS Savings Plans are flexible pricing models that allow you to save on EC2, Lambda, and Fargate usage by committing to a consistent amount of usage (measured in dollars per hour) for a 1 or 3-year term. They offer similar savings to Reserved Instances but with more flexibility.
AWS Pricing Calculator
The AWS Pricing Calculator is an invaluable tool for estimating the costs of AWS services before you commit. It allows you to model your architecture and get an estimated cost for the resources you intend to use.
To access the pricing calculator, on the left side of the Billing console select pricing calculator, you can also access this service even if you are not logged in to the management console, lets see how we can create an estimate, click on create an estimate.
Fill in your details for the estimate.
Select your operating system, number of instances, and workloads.
Select payment options,
Then you can save and view estimates.

Tips for Managing AWS Billing

To avoid unexpected charges and optimize your AWS costs, consider these key tips:

Set Billing Alerts

AWS provides the ability to set up billing alerts, which can notify you when your usage exceeds a specified threshold. By configuring these alerts in the AWS Budgets service, you can track your spending in real time and take action before costs spiral out of control.

For example, if you are a new bae, you can set zero spending in the AWS budget, lets create a small budget for zero spend, this will ensure as we navigate the AWS free tier, the AWS budget does not exceed the free tier with any amount.

In your Billing dashboard, click on the AWS budget, then click on Create Budget.

In the choose budget type, select use a template, then select zero spend budget.

Give your budget a name, for example, my zero-spend budget. Provide the email address you will be notified with in case your budget exceeds zero, then scroll down and click Create a budget.

Use Cost Explorer
AWS Cost Explorer allows you to visualize your spending patterns over time. It provides detailed reports on your usage, making it easier to identify which services are consuming the most resources and where potential savings can be made.
Filter by Service: Use filters to see which services are driving the majority of your costs.
Set Time Frames: Analyze costs over different periods (daily, monthly, or yearly).
Track Reserved Instances (RIs): Keep an eye on your RI usage to ensure you’re getting the most out of your investments.
Conclusion
By familiarizing yourself with key AWS billing concepts, taking advantage of available tools, and implementing best practices, you can avoid surprises on your AWS bill and ensure that your company’s cloud spending matches its goals.
Thanks for reading and stay tuned for more.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at sales@accendnetworks.com.

Thank you!

Blogs

Mastering IAM Policies

Mastering IAM Policies: A Guide to Cloud Security and Access Management

AWS Identity and Access Management (IAM) is at the core of securing your AWS resources by providing fine-grained control over access permissions. IAM policies are essential in defining what actions are allowed or denied on AWS resources. There are two main types of IAM policies: managed policies and inline policies. In this article, we’ll break down these policies.

When thinking about IAM, there are two broad categories to consider, Identities and permissions.

Identities refer to the various mechanisms that AWS provides to identify who is requesting a particular AWS action, authenticate that person or entity, and organize similar entities into groups, all are essential to mastering IAM policies.

Permissions refer to what a particular identity is allowed to do in the AWS account.

Best Practices for IAM Policies: IAM Users

IAM users are individual entities within your AWS account representing people or applications interacting with AWS services. Each IAM user has a unique identity and can be assigned specific permissions that dictate what AWS resources they can access and what actions they can perform. IAM users can authenticate using an AWS Management Console login, access keys for programmatic access (CLI or API), or both. Users are often created for individuals in an organization who need access to AWS resources and are assigned policies that define their permissions.

IAM Groups

IAM groups are collections of IAM users that share the same set of permissions. Instead of managing permissions for each user, you can attach policies to a group, and all users within that group will inherit those permissions. This makes it easier to manage users with similar access needs, such as developers, administrators, or auditors.

IAM Roles

IAM roles used to grant temporary access to AWS resources without requiring long-term credentials like passwords or access keys. Instead, roles are assumed by trusted entities such as IAM users, applications, or AWS services (e.g., EC2, Lambda) when they need to perform certain actions. Roles have permissions associated with them through policies, and when an entity assumes a role, it temporarily gains those permissions.

What are IAM Policies?

An IAM policy is a JSON document that defines what actions are allowed or denied on specific AWS services and resources. It contains statements with actions, resources, and conditions under which access is granted or denied.

Actions: These define what the policy allows or denies.

Resources: These are the AWS resources on which actions are performed, such as an S3 bucket or an EC2 instance.

Conditions: Optional filters that refine when the policy applies, such as applying only to a specific IP address.

Managed Policies

Managed policies are standalone policies that can be attached to multiple users, roles, or groups. They are easier to maintain because any changes to a managed policy apply across all entities attached to it. Managed policies come in two types:

AWS Managed Policies: Predefined policies created and maintained by AWS. These cover common use cases, like AdministratorAccess which grants full access to all AWS resources, or ReadOnlyAccess which allows viewing but not modifying resources.
Customer Managed Policies: Policies created and managed by AWS users. These are useful when predefined AWS-managed policies don’t meet specific business needs, allowing you to create custom policies tailored to your organization’s security requirements.

Inline Policies

Inline policies are policies directly embedded within an IAM user, group, or role. Unlike managed policies, inline policies exist solely within the entity they are attached to and cannot be reused. Inline policies are best when you need strict control over specific permissions, such as granting temporary or highly tailored access to a particular user.

Comparison of Managed Policies vs. Inline Policies

Managed policies can be attached to multiple users, roles, or groups, making them reusable across various entities. In contrast, inline policies are attached to a specific user, role, or group and cannot be reused.

When it comes to maintenance, managed policies are easier to update because any changes apply to all the entities they are attached to. On the other hand, inline policies need to be handled individually for each user, role, or group they are attached.

The typical use case for managed policies is to provide general-purpose permissions that can be reused across multiple accounts, while inline policies are ideal for fine-grained control over specific entities.

Conclusion:

AWS IAM policies provide the fine-grained access control needed to manage who can access your resources and what actions they can perform. Managed policies are reusable, making them easier to manage across multiple entities, while inline policies provide more granular control for individual users or roles. Understanding when to use each type is key to maintaining security and flexibility in your AWS environment.

Thanks for reading and stay tuned for more. Make sure you clean up.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at sales@accendnetworks.com.

Thank you!

Tags AWS Cloud Computing, AWS Cloud Security, AWS Cloud Services

Blogs

Exploring Managed and Inline Policies for Cloud Security

Post author By Lino Almojela
Post date October 12, 2024
2 Comments on Exploring Managed and Inline Policies for Cloud Security

Exploring Managed and Inline Policies for Cloud Security: Hands-On Demo

AWS Identity and Access Management (IAM) is a powerful tool that helps control access to AWS resources. By managing who can access what, IAM ensures the security and flexibility of your AWS environment. In this blog, we will be exploring Managed and Inline Policies for Cloud Security and provide a hands-on lab to demonstrate how to create an IAM user and attach an inline policy to the user.

We will start by creating an IAM user through the AWS Management Console and attaching a managed policy that allows the user to change only their password. After creating the user, we will log in with their credentials and attempt to describe EC2 instances, which will result in access being denied due to insufficient permissions.

Next, we will create an inline policy specifically for the user, permitting them to describe EC2 instances. This will provide the user with the necessary access to view instance details while maintaining fine-grained control over their permissions.

To begin, log into the AWS Management Console using an IAM user with administrative privileges. In the AWS Console, navigate to the search bar, type IAM, and select IAM from the list of services. This will take you to the IAM dashboard, where we can manage users, roles, and policies.

In the left side UI of the I AM console, select users then click Create User.

Fill in the user’s details, including a preferred name. Afterward, check the box labeled Provide user access to the AWS Management Console to allow the user to log in. Next, select the radio button that says I want to create an IAM user.

Under the Console password section, select Autogenerate password, and then check the box labeled Users must create a new password at the next sign-in (this is recommended for security purposes). Once done, click Next to proceed.

In the Set Permissions section, select Attach policies directly. In the managed policy search bar, type IamUserChangePasswordand select the policy that appears. This will be the only policy assigned to the user, allowing them to change their password. After selecting the policy, click Next to continue.

Review the permissions summary then click Create user.

Retrieve the newly created user’s details, including their login credentials. Use these credentials to log in to the AWS Management Console as the new user.

Once logged into the console, navigate to the EC2 dashboard. You’ll notice that the user receives API errors, indicating they lack the necessary permissions to access or view EC2 resources. This is because no permissions have been granted to the user for EC2-related actions.

When attempting to view EC2 instances, you will see a red flag stating, you are not authorized. This means the user does not have the required permissions to access or view EC2 instances, confirming that the necessary permissions have not yet been assigned. To resolve this, we’ll need to attach a policy granting EC2 permissions.

Log back in as the admin user and navigate to the IAM dashboard. From there, locate and select the user you created earlier. Once on the user’s detail page, click on the Permissions tab to review and manage the permissions assigned to that user.

Select the Add permissions drop-down button, then choose Create inline policy from the options. This will allow you to create a new inline policy specifically for the user.

In the Services section, click the drop-down button and select EC2 from the list. This specifies that the policy will apply to actions related to EC2.

Under Actions allowed, type instances in the search bar, then select Describe Instances from the list of available actions. After making your selection, make sure under effect, allow is checked then scroll down and click Next to proceed.

In the Policy Details section, enter your preferred name for the policy. Make sure the name is descriptive enough to reflect the policy’s purpose. After entering the name, click Create Policy to complete the creation process.

The policy has been successfully created. Under the Policy Name section, you can see the names of the policies, and under the Type column, you can distinguish between AWS Managed and Customer Inline policies. Additionally, in the Attached Viasection, you’ll see whether the policies are Attached Directly or in line, indicating how they are associated with the user.

Log in as the newly created user, and attempt to describe EC2 instances. At this point, you should notice that the user can successfully describe the instances. This access was granted by attaching an inline policy to the user, specifically allowing them to perform this action.

This process demonstrates the flexibility of AWS in managing user permissions, helping you maintain security and efficiency in your cloud environment. Additionally, inline policies provide a way to grant access to individual users based on their needs.

Thanks for reading and stay tuned for more. Make sure you clean up.

If you have any questions concerning this article or have an AWS project that requires our assistance, please reach out to us by leaving a comment below or email us at sales@accendnetworks.com.

Thank you!