Blogs by Ashwin

  Blazor Server Blazor Server uses SignalR to communicate between the client and the server, as shown in the following diagram: SignalR is an open-source library for real-time communication that establishes a connection between clients and servers. It can utilize various methods of data transport and automatically identifies the most suitable protocol depending on the capabilities of both the server and the client. SignalR prioritizes the use of WebSockets, a transport protocol incorporated in HTML5. If for any reason WebSockets is unavailable, it will smoothly revert to an alternative protocol. Blazor is constructed using reusable UI elements referred to as components. Every component comprises C# code, markup, and may also incorporate additional components. Razor syntax allows you to blend markup with C# code, or you can choose to write everything in C# if preferred. User actions (like clicking a button) or events (such as a timer) can cause the components to be refreshed. The el...

  Preceding Blazor In today's world, the approach to app development has evolved. Frameworks like Angular, React, Aurelia, and Vue have transformed the web experience from needing to refresh the entire page to only updating specific sections dynamically. This method of dynamic updates has made page loading faster, as the perceived loading time has been reduced (although the total page load time might not have changed). However, for many developers, adapting to this requires learning a completely new skill set, particularly transitioning from a server-side environment to a frontend built with JavaScript. On the backend, data objects are created in C# and then converted into JSON, which is transmitted through an API and subsequently reconstituted into JavaScript objects on the frontend. In the past, JavaScript functioned differently across various browsers, a problem that jQuery aimed to address by providing a unified API that could be interpreted by web browsers. Nowadays, the varia...

  About AWS Organizations is a service for managing accounts that allows you to group various AWS accounts into an organization that you establish and oversee from one central location. You have the ability to share an AMI with an organization or a specific Organizational Unit (OU) you've created, in addition to sharing it with particular accounts. A organization is a structure you establish to unify and manage your AWS accounts from a central location. You can arrange the accounts in a hierarchical, tree-like format, with a root node at the top and organizational units positioned beneath the organization root. Each account can either be added directly to the root or organized into one of the organizational units within the hierarchy. When you share an AMI with an organization or an OU, all of the children accounts gain access to the AMI. Considerations Consider the following when sharing AMIs with specific organizations or organizational units: Ownership - To share an AMI, your AW...

  About To stop the public distribution of your AMIs, you can activate block public access at the account level. With block public access turned on, any attempt to make an AMI accessible to the public will be automatically denied. However, any AMIs that are already public will still remain available to the public. To share AMIs publicly, you need to turn off block public access. Once you have finished sharing, it is advisable to reactivate block public access to avoid any accidental public sharing of your AMIs. You can limit IAM permissions for an admin user, allowing only them to turn on or off public access blocking for AMIs. Note: This configuration is set at the account level, either directly within the account or through a declarative policy. It needs to be set in each AWS Region where you wish to restrict the public sharing of your AMIs. Utilizing a declarative policy enables you to implement this configuration across several Regions at once, as well as across multiple accoun...

  Introduction You have the option to share your AMI with all AWS accounts, making it publicly accessible. To avoid public sharing of your AMIs, you can activate the block public access feature. This feature prevents any attempts to share an AMI publicly, which helps safeguard against unauthorized access and possible misuse of AMI information. Keep in mind that turning on block public access will not impact the AMIs that are already publicly available; they will continue to be accessible to the public. Considerations Consider the following before making an AMI public: Ownership- To make an AMI public, your AWS account must own the AMI. Region- AMIs function as a resource within a specific region. When you distribute an AMI, it can only be accessed in the original region from which it was shared. To make an AMI accessible in another region, you need to duplicate the AMI to that region before sharing it. Block Public Access- To share an AMI publicly, you must turn off the block publi...

  Allowed AMIs operations The Allowed AMIs feature offers three operational modes for overseeing the image criteria: enabled, disabled, and audit mode. These modes allow you to activate or deactivate the image criteria, or examine them when necessary. Enabled When Allowed AMIs is enabled: The  ImageCriteria  are applied. Only allowed AMIs are discoverable in the EC2 console and by APIs that use images Instances can only be launched using allowed AMIs. Disabled When Allowed AMIs is disabled: The  ImageCriteria  are not applied. No restrictions are placed on AMI discoverability or usage. Audit mode In audit mode: The  ImageCriteria  are applied, but no restrictions are placed on AMI discoverability or usage. In the EC2 console, for each AMI, the Allowed image field displays either Yes or No to indicate whether the AMI will be discoverable and available to users in the account when Allowed AMIs is enabled. In the command line, the response for the describ...

  Control the Discovery and Use of AMIs in Amazon EC2 with Allowed AMIs To manage the discovery and utilization of Amazon Machine Images (AMIs) by users in your AWS account, the Allowed AMIs feature can be utilized. This feature enables you to define criteria that AMIs must fulfill to be visible and accessible within your account. Once these criteria are activated, users launching instances will only see and be able to use AMIs that meet the established standards. For instance, you could create a list of trusted AMI providers as part of the criteria, ensuring that only AMIs from these providers are visible and available for use. Prior to activating the Allowed AMIs settings, you can turn on audit mode to see which AMIs will be visible and available for use. This allows you to adjust the criteria as necessary to make sure that only the intended AMIs are accessible to users within your account. Furthermore, you can execute the describe-instance-image-metadata command and apply filte...

  Introduction A shared AMI is an Amazon Machine Image created by a developer for others to utilize. One of the simplest methods to begin with Amazon EC2 is to utilize a shared AMI that includes the necessary components and then incorporate your own content. Additionally, you have the option to develop your own AMIs and share them with others. When utilizing a shared AMI, you do so at your own risk. Amazon cannot guarantee the integrity or security of AMIs that other Amazon EC2 users have shared. Consequently, you should approach shared AMIs in the same way you would with any external code you might think about deploying in your own data center, and conduct the necessary due diligence. It is advisable to obtain an AMI from a reliable source, like a verified provider. Verified provider In the Amazon EC2 console, public AMIs owned by Amazon or recognized Amazon partners are labeled as Verified provider. You can also utilize the describe-images AWS CLI command to find public AMIs that...

  Encrypt a volume during launch In below figure, an AMI backed by an unencrypted snapshot is used to launch an EC2 instance with an encrypted EBS volume.   The Encrypted parameter by itself leads to the encryption of the volume for this instance. Specifying a KmsKeyId parameter is not mandatory. If a KMS key ID is not provided, the volume will be encrypted using the default KMS key associated with the AWS account. To use a different KMS key that you possess for encrypting the volume, include the KmsKeyId parameter. Re-encrypt a volume during launch In the figure below, an AMI backed by an encrypted snapshot is used to launch an EC2 instance with an EBS volume encrypted by a new KMS key. If you have ownership of the AMI and do not provide any encryption parameters, the resulting instance will have a volume that is encrypted using the same KMS key as the snapshot. In the case where the AMI is shared with you rather than owned by you, and no encryption parameters are provided, t...