Accend Networks San Francisco Bay Area Full Service IT Consulting Company

Tag: AWS Cloud Security

Categories
Blogs

Hosting Static Website Amazon S3

Hosting Static Website on Amazon S3

How to Host a Static Website on Amazon S3 Bucket: A Step-by-Step Guide

Hosting Static Website on Amazon S3

In the current digital landscape, having a simple fast, and cost-effective website is essential for showcasing your content, be it running a personal blog, small business, or portfolio. Amazon S3 provides an excellent platform for hosting static websites with its simple storage services.

In this blog, we will guide you through the essential steps to deploy your static website in Amazon S3.

Deploying a static website in s3 is a straightforward and powerful way to leverage cloud infrastructure for your online presence and this article will equip you with everything you need to launch your website effortlessly in amazon s3.

What is Amazon S3?

Amazon S3 is a highly scalable object storage service that offers data availability, security, and performance. It’s suitable for businesses of all sizes and can be used for various use cases such as data lakes, websites, mobile apps, backup and restore archives, and big data analytics.

Let’s dive into the hands-on where we will break down this into a step-by-step guide.

Step 1: Creating an S3 Bucket

Log in to the management console and type S3 on the Search bar then Select S3 under services.

In the s3 console, Click Create Bucket.

Enter the bucket name and choose the region where you want the bucket to be located.

Scroll down and uncheck the Block all public access checkbox to disable Amazon S3’s default setting to block public access to an S3 bucket. A warning will appear beneath this section; click on the checkbox to acknowledge current settings to enable public access to the bucket.

This configuration allows users to access static website pages stored in the S3 bucket.

Leave the rest of the options at their default settings, and click on the Create bucket button.

Step 2: Enable Static Website Hosting

On the resulting page from the successful creation of the bucket, click on the bucket name. Select the Properties tab, scroll down to the Static website hosting section, and click Edit. 

Once you choose Enable, more configuration options will be made available on the console to enable you to provide the necessary settings and documents for hosting your website.

Leave the Hosting type as the default (Host a static website), and enter the exact name of the Index document that should serve as the file for your static webpage. Do the same for the Error document if you want to have a custom web page for 4XX class errors. This section is case-sensitive, therefore ensure the names you provide are the exact match.

Navigate to the end of the page and click on Save Changes.

When you scroll down the resulting page, you will notice that a bucket endpoint was successfully created.

Step 3: Add a Bucket Policy that Makes an S3 Bucket Content Publicly Available

Here we will add a policy to grant public read-only access to our S3 bucket.

To edit the permissions of your bucket, follow these steps:

On the current page of the console, navigate to the Permissions tab.

To edit the permissions of your bucket, follow these steps:

On the current page of the console, navigate to the Permissions tab.

Scroll down to the Bucket policy section and click on Edit.

Paste the code into the text editor provided in the console.

In the Resource section of the code, replace the unique bucket name with your own. This will ensure that you have the correct permissions for your bucket.

At the bottom of the page, click on Save Changes.

Step 4: Configure an Index Document

The index document is the root file of our static website. Make sure you have your web files ready.

choose the Object tab, and on the resulting page, drag and drop the file (or folders) you want to upload here, or choose Add files (or Add folder). Scroll down and click the Upload button.

After a successful upload, you can view your static website by visiting the Endpoint of your S3 bucket on your web browser.

To get your bucket endpoint, choose the Properties tab and scroll down to the Static website hosting section at the end of the page. Click on it to open your static website on a new tab.

This brings us to the end of this article, pull everything down.

Conclusion

Hosting a static website on Amazon S3 is an efficient and cost-effective solution for delivering web content to a global audience. By leveraging S3’s robust infrastructure, you can ensure high availability, durability, and scalability for your static website.

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 [email protected].

Thank you!

Categories
Blogs

VPC Security

Enhancing VPC Security: An Overview of AWS Network Firewall

As cloud computing keeps changing, protecting network infrastructure is key. Amazon Web Services (AWS) provides strong security tools, including AWS Network Firewall. This article looks at leveraging AWS Network Firewall to protect resources in a Virtual Private Cloud (VPC).

What is Network Firewall?

Network Firewall is a managed network firewall service for VPC. It is a stateful, network firewall and intrusion detection and prevention service for your virtual private cloud (VPC) that you create in Amazon Virtual Private Cloud (VPC).

Network Firewall lets you filter traffic at the edge of your VPC. This covers filtering traffic going to and coming from an internet gateway, NAT gateway, or through VPN or AWS Direct Connect.

Understanding AWS Network Firewall

To understand the concept of a Network Firewall, let’s first explore some of the security features available for the VPC.

From the above architecture, we can observe that at the instance level, security groups are used to provide security for your instances and manage all incoming and outgoing traffic. At the subnet level, Network Access Control Lists (NACLs) are utilized to evaluate traffic entering and exiting the subnet.

Any traffic from the internet gateway to your instance will be evaluated by both NACLs and security group rules. Additionally. AWS Shield and AWS WAF are available for protecting web applications running within your VPC.

Single zone architecture with internet gateway and network firewall

AWS network firewall will establish a subnet in your VPC’s availability zone and set up an endpoint within it. All traffic from your subnet heading to the internet will be routed through this network firewall subnet for inspection before proceeding to its destination and vice versa for incoming traffic. This is a valuable feature that enhances the security of your VPC.

Two zone architecture with network firewall and internet gateway

In this setup, you can have firewall subnets in each availability zone, where each network firewall will inspect traffic going to and from the customer subnet in that zone. To make sure all traffic goes through these firewall subnets, you’ll need to update your route tables.

How it Network Firewall Works

To apply traffic-filtering logic provided by Network Firewall, traffic should be routed symmetrically to the Network Firewall endpoint. Network Firewall endpoint is deployed into a dedicated subnet of a VPC (Firewall subnet). Depending on the use case and deployment model, the firewall subnet could be either public or private. For high availability and multi-AZ deployments, allocate a subnet per AZ.

Once NF is deployed, the firewall endpoint will be available in each firewall subnet. The firewall endpoint is similar to the interface endpoint and it shows up as vpce-id in the VPC route table.

Network Firewall makes firewall activity visible in real-time via CloudWatch metrics and offers increased visibility of network traffic by sending logs to S3, CloudWatch, and Kinesis datafirehorse.

NF is integrated with AWS firewall Manager, giving customers who use AWS Organizations a single place to enable and monitor firewall activity across all VPCs and AWS accounts.

Network Firewall Components:

Firewall: A firewall connects the VPC that you want to protect to the protection behaviour that’s defined in a firewall policy.

Firewall policy: Defines the behaviour of the firewall in a collection of stateless and stateful rule groups and other settings. You can associate each firewall with only one firewall policy, but you can use a firewall policy for more than one firewall.

Rule group: A rule group is a collection of stateless or stateful rules that define how to inspect and handle network traffic.

Stateless Rules

Inspects each packet in isolation. Does not take into consideration factors such as the direction of traffic, or whether the packet is part of an existing, approved connection.

Stateful Rules

Stateful firewalls are capable of monitoring and detecting states of all traffic on a network to track and defend based on traffic patterns and flows.

This brings us to the end of this blog.

Conclusion

Protecting resources inside a VPC plays a key role in today’s cloud setups. AWS Network Firewall gives you a full set of tools to guard your network against different kinds of threats. setting AWS Network Firewall manager, will give your VPC resources strong protection.

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 [email protected].

Thank you!

Categories
Blogs

Deep Dive into CloudFront

Deep Dive into CloudFront: Understanding Internal Caching Mechanisms and Implementing Websites on S3 with Region Failover Part One

Amazon CloudFront, a Content Delivery Network (CDN) provided by AWS, is key in ensuring that content is delivered swiftly to users across the globe. When paired with S3, it’s perfect for hosting fast, secure, and reliable static websites. In this article, we will explore CloudFront’s internal caching mechanisms and discuss how to implement an S3-hosted website with region failover capabilities.

What is CloudFront

CloudFront is a CDN service (Content delivery network). CloudFront caches content such as HTML, CSS, and dynamic content to a worldwide data center called Edge Location or Regional Edge location. it is used to boost your website performance by availing content closer to users all over the world.

How it works?

CloudFront caches the contents in all the edge locations around the world. Caching refers to storing frequently accessed data in high-speed hardware, allowing for faster retrieval. This hardware is known as a cache. However, caches have limited memory capacity, and it is not possible to store everything in them due to their relatively expensive hardware. We use caching strategically to maximize performance.

Cache Hierarchy in CloudFront

Regional Edge Caches: Before content reaches the edge locations, it may pass through regional edge caches. These are a middle layer that provides additional caching, helping to reduce the load on the origin server and improve cache hit ratios.

Cache Hit: This refers to a situation where the requested data is already present in the cache. It improves performance by avoiding the need to fetch the data from the source such as a disk or server. Cache hits are desirable because they accelerate the retrieval process and contribute to overall system efficiency.

Cache Miss: This occurs when the requested data is not found in the cache. When a cache miss happens, the system needs to fetch the data from the source, which can involve a longer retrieval time and higher latency compared to a cache hit. The data is then stored in the cache for future access, improving subsequent performance if the same data is requested again. Cache misses are inevitable and can happen due to various reasons, such as accessing new data or when the data in the cache has expired.

How CloudFront utilizes caching to reduce the latency and increase the performance

When a user requests a website, the DNS service resolves to the DNS of the CloudFront distribution, which then redirects the user to the nearest edge location. The user receives the response from that particular edge location. However, there are instances when the requested data is not present in the edge location, resulting in a cache miss. In such cases, the request is sent from the regional edge location, and the user receives the data from there if it is available, indicating a cache hit. However, this process can take some time.

In situations where the data is not present in the regional edge location either, retrieving the data becomes a lengthier process. In such cases, the data needs to be fetched from the origin server, which, in our case, is the S3 bucket. This additional step of fetching the data from the origin server can introduce latency and increase the overall response time for the user.

CloudFront origin failover

For high-availability applications where downtime is not an option, CloudFront origin failover ensures that your content remains accessible even if the primary origin server becomes unavailable. By setting up multiple origins (like two S3 buckets in different regions) and configuring CloudFront to switch to a backup origin when the primary one fails, we can maintain uninterrupted service for users, enhancing our website’s reliability and resilience.

For CloudFront origin to be achieved, we create an origin group with two origins: a primary and a secondary. If the primary origin is unavailable or returns specific HTTP response status codes that indicate a failure, CloudFront automatically switches to the secondary origin.

To set up origin failover, you must have a distribution with at least two origins. Next, you create an origin group for your distribution that includes two origins, setting one as the primary. Finally, you create or update a cache behavior to use the origin group. We will demonstrate this with a hands-on in the second part of this blog.

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 [email protected].

Thank you!

Categories
Blogs

AWS X-Ray

Unlocking Application Insights and Debugging with AWS X-Ray

AWS X-Ray stands as a pivotal service within the AWS ecosystem offering developers deep insights into their application’s performance and operational issues. Moreover, it enables a comprehensive analysis of both distributed applications and microservices facilitating a seamless debugging process across various AWS services.

What is AWS X-Ray?

AWS X-Ray is a tool designed to aid developers in understanding how their applications operate within the AWS environment. It provides a detailed view of requests as they travel through your application, allowing for the identification of performance bottlenecks and pinpointing the root cause of issues.

With the aid of a service map, AWS X-Ray visually depicts the interactions between services within an application, providing invaluable insights into the application’s architecture and behaviour.

How Does AWS X-Ray Work?

The functionality of AWS X-Ray can be broken down into a simple workflow that ensures detailed trace data collection and analysis. It starts with collecting traces from each component of your application, it then collects this data into what AWS refers to as traces. These traces then form a service map, offering a visual representation of the application’s architecture. This service map is crucial for analyzing application issues, as it provides detailed latency data, HTTP status, and other metadata for each service.

The Features and Benefits of AWS X-Ray

Simplified Setup

Getting started with AWS X-Ray is remarkably straightforward. Whether your application is running on EC2, ECS, Lambda, or Elastic Beanstalk. Integrating with X-Ray involves minimal configuration. This ease of setup ensures that developers can quickly start gaining insights into their applications without a steep learning curve.

End-to-End Tracing

One of the standout features of AWS X-Ray is its ability to offer an end-to-end view of requests made to your application. This application-driven view is instrumental in aggregating data from various services into a cohesive trace, thereby simplifying the debugging process.

Service Map Generation

At the heart of AWS X-Ray’s functionality is its service map feature. This automatically generated map provides a visual overview of your application’s architecture, highlighting the connections and interactions between different services and resources. It serves as a critical tool for identifying errors and performance issues within your application.

Practical Application and Analysis

Analysing Application Performance

AWS X-Ray shines when it comes to analyzing and improving your application’s performance. The service map and traces allow developers to drill down into specific services and paths, identifying where delays occur and optimizing them for better performance.

AWS X-Ray Core Concepts

Traces and Segments

At the core of AWS X-Ray’s functionality are traces and segments. A trace represents a single request made to your application, capturing all the actions and services that process the request. Segments, on the other hand, are pieces of the trace, representing individual operations or tasks performed by services within your application. For example, if a user uploads an image, the processing of that image by your application could be one segment of the trace of the user’s request.

Service Maps

Service maps visually represent the components of your application and how they interact with each other. By analyzing a service map, you can quickly identify which parts of your application are experiencing high latencies or errors. Think of it as a map of a city, where each service is a building, and the paths between them are the roads. The map shows you traffic flow and blockages, helping you navigate your application’s architecture more effectively.

AWS X-Ray Workflow

Data Collection

The first step in the AWS X-Ray workflow is data collection. As requests travel through your application, X-Ray collects data on these requests, creating traces. This data collection is automatic once you’ve integrated the X-Ray SDK with your application.

Data Processing

Once data is collected, AWS X-Ray processes it, organizing the information into a coherent structure that you can analyze. This processing stage is where traces are assembled, and service maps are generated, providing a comprehensive view of your application’s performance and interactions.

Data Analysis

The final stage is data analysis, where you, the developer, step in. Using the AWS X-Ray console, you can examine the traces and service maps, identify issues, and gain insights into how to improve your application. Whether it’s a slow database query or a faulty external API call, X-Ray helps you find and fix problems fast.

Integrating AWS X-Ray with Other AWS Services

AWS X-Ray seamlessly integrates with various AWS services, enhancing its tracing capabilities. When you use AWS Lambda, EC2, or Amazon ECS, integrating X-Ray allows you to trace requests as they move through these services, providing a unified view of your application’s performance across the AWS ecosystem.

AWS X-Ray is a valuable tool for developers and operations teams looking to improve the performance, reliability, and troubleshooting of their applications running on AWS. It’s particularly useful in microservices architectures where understanding dependencies and performance across services is crucial.

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 [email protected].

Thank you!

Categories
Blogs

Amazon S3

Enhancing Data Integrity in Amazon S3 with Additional Checksums

In the security world, cryptography uses something called “hashing” to confirm that a file is unchanged. Usually, when a file is hashed, the hash result is published. Next, when a user downloads the file and applies the same hash method, the hash results, or checksums (a string of output that is a set size) are compared. This means if indeed the checksum of the downloaded file and the original file are the same, the two files are identical, confirming that there have been no unexpected changes — for example, file corruption, man-in-the-middle (MITM) attacks, etc. Since hashing is a one-way process, the hashed result cannot be reversed to expose the original data. 

Verify the integrity of an object uploaded to Amazon S3

We can use Amazon S3 features to upload an object with the checksum flag “On” with the checksum algorithm that is used to validate the data during upload (or download) — in this example, as SHA-256. Optionally, you may also specify the checksum value of the object. When Amazon S3 receives an object, it calculates the checksum by leveraging the algorithm that you specified. Now, if the two checksum values do not match, Amazon S3 will generate an error.

Types of Additional Checksums

Various checksum algorithms can be used for verifying data integrity. Some common ones include:

MD5: A widely used algorithm, but less secure against collision attacks.

SHA-256: Provides a higher level of security and is more resistant to collisions.

CRC32: A cyclic redundancy check that is fast but not suitable for cryptographic purposes.

Implementing Additional Checksums

Sign in to the Amazon S3 console. From the AWS console services search bar, enter S3. Under the services search results section, select S3.

Choose Buckets from the Amazon S3 menu on the left and then choose the Create Bucket button.

Enter a descriptive globally unique name for your bucket. The default Block Public Access setting is appropriate, so leave this section as is.

You can leave the remaining options as defaults, navigate to the bottom of the page, and choose Create Bucket.

Our bucket has been successfully created.

Upload a file and specify the checksum algorithm

Navigate to the S3 console and select the Buckets menu option. From the list of available buckets, select the bucket name of the bucket you just created.

Next, select the Objects tab. Then, from within the Objects section, choose the Upload button.

Choose the Add Files button and then select the file you would like to upload from your file browser.

Navigate down the page to find the Properties section. Then, select Properties and expand the section.

Under Additional checksums select the on option and choose SHA-256.

If your object is less than 16 MB and you have already calculated the SHA-256 checksum (base64 encoded), you can provide it in the Precalculated value input box. To use this functionality for objects larger than 16 MB, you can use the CLI or SDK. When Amazon S3 receives the object, it calculates the checksum by using the algorithm specified. If the checksum values do not match, Amazon S3 generates an error and rejects the upload, but this is optional.

Navigate down the page and choose the Upload button.

After your upload completes, choose the Close button.

Checksum Verification

Select the uploaded file by selecting the filename. This will take you to the Properties page.

Locate the checksum value: Navigate down the properties page and you will find the Additional checksums section.

This section displays the base64 encoded checksum that Amazon S3 calculated and verified at the time of upload.

Compare

To compare the object in your local computer, open a terminal window and navigate to where your file is.

Use a utility like Shasum to calculate the file. The following command performs a sha256 calculation on the same file and converts the hex output to base64: shasum -a 256 image.jpg | cut -f1 -d\ | xxd -r -p | base64

When comparing this value, it should match the value in the Amazon S3 console.

Run this code by replacing it with your image.

Congratulations! You have learned how to upload a file to Amazon S3, calculate additional checksums, and compare the checksum on Amazon S3 and your local file to verify data integrity.

This brings us to the end of this blog, 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 [email protected].

Thank you!