DEV Community: Srinivasa Raju Addepalli

AWS MGN Overview

Srinivasa Raju Addepalli — Wed, 21 Sep 2022 04:17:55 +0000

AWS MGN

AWS MGN (AWS Application Migration Service) is a highly automated lift-and-shift (rehost) solution:

• Simplifies, expedites, and reduces the cost of migrating applications to AWS

• Enables lift-and-shift migration from any source infrastructure with minimal business disruption.

AWS MGN utilizes continuous, block-level replication and enables short cutover windows measured in minutes.

AWS MGN (AWS Application Migration Service) is based on CloudEndure Migration and improves on it by integrating with the AWS Management Console. (Note: CloudEndure Migration will be no longer be available for use in most AWS Regions as of December 30, 2022. It will continue to be available for migrations into GovCloud and China Regions through 2023).

AWS recommends AWS MGN as the primary migration service for lift-and-shift migrations. If AWS MGN is unavailable in a specific AWS Region, we can use the AWS SMS APIs through March 2023. AWS SMS (AWS Server Migration Service) utilizes incremental, snapshot-based replication and enables cutover windows measured in hours.

With AWS MGN, we can migrate our applications from physical infrastructure, VMware vSphere, Microsoft Hyper-V, Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), and other clouds to AWS.

AWS MGN Benefits

• Minimal downtime during migration
• Reduced costs
• Automated modernization

Initializing Application Migration Service

In order to use Application Migration Service, the service must first be initialized for any AWS Region in which we plan to use Application Migration Service.

Application Migration Service must be initialized upon first use from within the Application Migration Service Console. The initialization process occurs automatically once a user accesses the Application Migration Service Console. The user is directed to create the Replication Settings template, and upon saving the template, the service is initialized by creating the IAM Roles which are required for the service to work.

Application Migration Service can only be initialized by the Admin user of our AWS Account.

During initialization the following IAM roles will be created:

AWSServiceRoleForApplicationMigrationService
AWSApplicationMigrationReplicationServerRole
AWSApplicationMigrationConversionServerRole
AWSApplicationMigrationMGHRole
AWSApplicationMigrationLaunchInstanceWithDrsRole
AWSApplicationMigrationLaunchInstanceWithSsmRole
AWSApplicationMigrationAgentRole

Additional Policies

You can create roles with granular permission for Application Migration Service. The service comes with the following pre-defined managed IAM policies:

• AWSApplicationMigrationFullAccess - This policy provides permissions to all public APIs of AWS Application Migration Service (MGN), as well as permissions to read KMS key information.

• AWSApplicationMigrationEC2Access - This policy allows Amazon EC2 operations required to use Application Migration Service (MGN) to launch the migrated servers as EC2 instances.

• AWSApplicationMigrationReadOnlyAccess - The Read-Only policy allows the user to view all data available in the Application Migration Service Console but does not allow them to modify any data or perform any actions. This policy also includes several EC2 read-only permissions.

• AWSApplicationMigrationAgentPolicy - This policy allows a user to install the AWS Replication Agent.

• AWSApplicationMigrationAgentInstallationPolicy - This policy allows a user to install the AWS Replication Agent.

we must attach the AWSApplicationMigrationFullAccess and the AWSApplicationMigrationEC2Access policies to our IAM users and roles in order to be able to launch Test and Cutover instances and to complete a full migration cycle with Application Migration Service.

Accessing the Application Migration Service Console

We can access Application Migration Service through the AWS Console:

https://console.aws.amazon.com/mgn/home

Application Migration Service is AWS Region-specific. We have to select the correct Region from the Select a Region menu when using Application Migration Service.

AWS MGN Lifecycle

Agent Installation

Implementation begins by installing the AWS Replication Agent on your source servers. Once it’s installed, you can view and define replication settings. AWS Application Migration Service (AWS MGN) uses these settings to create and manage a Staging Area Subnet with lightweight Amazon EC2 instances that act as Replication Servers and low-cost staging Amazon EBS volumes. (Note: If we cannot install agents on our servers, we can use the agentless replication option)

Continuous Replication

Replication Servers receive data from the agent running on our source servers and write this data to the staging Amazon EBS volumes. our replicated data is compressed and encrypted in transit, and can be encrypted at rest using EBS encryption. AWS Application Migration Service keeps our source servers up to date on AWS using continuous, block-level data replication. It uses our defined launch settings to launch instances when we conduct non-disruptive tests or perform a cutover.

Testing and Cutover

When we launch Test or Cutover instances, AWS Application Migration Service automatically converts our source servers to boot and run natively on AWS. After confirming that our launched instances are operating properly on AWS, we can decommission our source servers. We can choose to modernize our migrated applications by leveraging AWS Application Migration Service and additional AWS services.

Best Practices

Planning

• Plan your Migration project prior to installing the AWS Replication Agent on your source servers.

• Do not perform any reboots on the source servers prior to a Cutover.

• Do not archive or disconnect the source server from AWS until your launched Cutover instance in AWS is working as expected.

Testing

• Perform Test at least two weeks before you plan to migrate your Source servers. This time frame is intended for identifying potential problems and solving them, before the actual Cutover takes place. After performing the test launch, validate connectivity to your Test instances (using SSH for Linux or RDP for Windows), and perform acceptance tests for your application.

• Ensure that you perform a Test prior to performing a Cutover.

Successful Implementation

The following are the required steps to complete a successful migration implementation with Application Migration Service:

• Deploy the AWS Replication Agent on your source servers.

• Confirm that the data replication status is Healthy.

• Test the launch of Test instances a week before the actual Cutover.

• Address any issues that come up, such as Launch setting misconfiguration and potential AWS limits.

• Launch Cutover instances for the servers on the planned date.

Best Practices for Ensuring Project Success

• Train a field technical team & assign a Application Migration Service SME.
• Share project timelines with Application Migration Service.
• Monitor data replication progress and report any issues in advance.
• Perform a test for every server in advance, and report issues to Application Migration Service.
• Coordinate Cutover windows with Application Migration Service in advance.

Migration workflow

The general process is:

• Install the AWS Replication Agent on the source server. (If we are using the agentless replication for vCenter feature, then e will need to add our source servers by installing the AWS MGN vCenter Client)

• Wait until Initial Sync is finished.

• Launch Test instances.

• Perform acceptance tests on the servers. After the Test instance is tested successfully, finalize the Test and delete the Test instance.

• Wait for the Cutover window.

• Confirm that there is no Lag.

• Stop all operational services on the source server.

• Launch a Cutover instance.

• Confirm that the Cutover instance was launched successfully and then finalize the Cutover.

• Archive the source server.

AWS MGN Pricing

For each source server that we want to migrate, we can use AWS Application Migration Service for a free period of 2,160 hours, which is 90 days when used continuously.

The free period starts as soon as we install the AWS Replication Agent on our source server and continues during active source server replication.

If we do not complete our migration of a specific server within the free period, we will be charged per hour while we continue replicating that server.

Additional charges

While our source servers are actively replicating, including during the free period, we will incur charges for any AWS infrastructure that is provisioned by AWS Application Migration Service to facilitate data replication.

We will also incur charges for resources that are provisioned when we launch test or cutover instances, such as compute (Amazon EC2) and storage (Amazon EBS) resources, according to our AWS pricing plan.

Pricing details

AWS Application Migration Service pricing is the same for all supported AWS Regions.

Supported AWS Regions

The following AWS Regions are supported by Application Migration Service:

AWS Application Migration Service is not yet supported in AWS GovCloud and China Regions, and does not currently support some legacy operating systems that are supported by CloudEndure Migration. Consider using CloudEndure Migration if our preferred AWS Region or operating system is not currently supported by AWS Application Migration Service.

Note: While CloudEndure Migration will continue to be available for use in AWS GovCloud and China Regions, it will no longer be available in other AWS Regions as of December 30, 2022. After January 1, 2023, CloudEndure Migration will be available only for migrations to AWS Outposts and AWS GovCloud and China Regions.

CloudEndure Migration EOL

Important dates to plan for:

June 30, 2022 - No new CloudEndure Migration licenses will be allocated, but we can continue using existing licenses.
September 30, 2022 - No new CloudEndure Migration agents can be installed, but we can complete migrations in progress, using the agents already installed
December 30, 2022 - Existing CloudEndure Migration licenses will expire, and the service will no longer be available

(Note: These dates are excluding for the GovCloud and China Regions. The CloudEndure Migration service will continue to be available for migrations into GovCloud and China Regions, at this time.)

References

Supported operating systems - https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html

CloudEndure Migration EOL - https://docs.cloudendure.com/#Configuring_and_Running_Migration/Migration_EOL/Migration_EOL.htm

Hope you got some valuable information.

Social Footprints:

Happy Learning 📚

Thank you!

AWS Control Tower Overview & Set up

Srinivasa Raju Addepalli — Wed, 07 Sep 2022 02:10:35 +0000

AWS Control Tower Overview & set up

Introduction

AWS Control Tower offers the easiest way to set up and govern a secure, multi-account AWS environment.

It establishes a landing zone that is based on best-practices blueprints, and it enables governance using guardrails we can choose from a pre-packaged list. The landing zone is a well-architected, multi-account baseline that follows AWS best practices. Guardrails implement governance rules for security, compliance, and operations.

AWS Control Tower is an AWS native service providing a pre-defined set of blueprints and guardrails to help us implement a landing zone for AWS accounts. AWS Landing Zone is an AWS solution offered through AWS Solution Architect, Professional Services, or AWS Partner Network (APN) Partners that provides a fully configurable, customer-managed landing zone implementation. We can use either AWS Control Tower or the Landing Zone solution to create a foundational AWS environment based on best-practices blueprints implemented through AWS Service Catalog.

AWS Control Tower is designed to provide an easy, self-service setup experience and an interactive user interface for ongoing governance with guardrails. While AWS Control Tower automates creation of a new landing zone with predefined blueprints (e.g., IAM Identity Center for directory and access), the AWS Landing Zone solution provides a configurable setup of a landing zone with rich customization options through custom add-ons (such as Active Directory or Okta Directory) and ongoing modifications through a code deployment and configuration pipeline.

AWS Control Tower is a service that helps us to set up and manage governance rules for security, operations, and compliance at scale across all our organizations and accounts in the AWS Cloud.

AWS Control Tower orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center (successor to AWS Single Sign-On), to build a landing zone.

Features of AWS Control Tower

Landing zone – A landing zone is a well-architected, multi-account environment that's based on security and compliance best practices. It is the enterprise-wide container that holds all of our organizational units (OUs), accounts, users, and other resources that you want to be subject to compliance regulation. A landing zone can scale to fit the needs of an enterprise of any size.

Guardrails – A guardrail is a high-level rule that provides ongoing governance for our overall AWS environment. It's expressed in plain language. Two kinds of guardrails exist: preventive and detective.

Three categories of guidance apply to these two kinds of guardrails: mandatory, strongly recommended, or elective.

Account Factory – An Account Factory is a configurable account template that helps to standardize the provisioning of new accounts with pre-approved account configurations. AWS Control Tower offers a built-in Account Factory that helps automate the account provisioning workflow in our organization.

*Dashboard *– The dashboard offers continuous oversight of our landing zone to our team of central cloud administrators. We can use the dashboard to see provisioned accounts across our enterprise.

Structure of an AWS Control Tower Landing Zone

Root – The parent that contains all other OUs in your landing zone.

Security OU – This OU contains the Log Archive and Audit accounts. These accounts often are referred to as shared accounts. When we launch our landing zone, we can choose customized names for these shared accounts, and we have the option to bring existing AWS accounts into AWS Control Tower for security and logging. However, these cannot be renamed later, and existing accounts cannot be added for security and logging after initial launch.

Sandbox OU – The Sandbox OU is created when you launch your landing zone, if you enable it. This and other registered OUs contain the enrolled accounts that your users work with to perform their AWS workloads.

*IAM Identity Center directory *– This directory houses your IAM Identity Center users. It defines the scope of permissions for each IAM Identity Center user.

IAM Identity Center users – These are the identities that your users can assume to perform their AWS workloads in your landing zone.

Set Up AWS Control Tower

We can set up an AWS Control Tower landing zone in an existing organization, or we can start by creating a new organization that contains our AWS Control Tower landing zone.

Pre-requisites to setting up control tower for the first time:

Sign up for AWS (create AWS account)

https://portal.aws.amazon.com/billing/signup

Follow the online instructions to complete the account creation.

Sign in as an Administrator user

https://console.aws.amazon.com/iam

Create IAM account and sign in if the IAM account is not created before.
Create AWS Identity and Access Management (IAM) user and grant that user full access.

Set up MFA

We have to enable multi-factor authentication (MFA) for our account.

Prerequisites steps for setting up AWS Control Tower

• Sign in to the AWS management console with administrator user credentials.

• Access AWS Control Tower console at https://console.aws.amazon.com/controltower

• Verify that we selected our desired home Region.

• Choose Set up landing zone.

• Follow the instructions in the console, accepting all the default values (email address for our account, a log archive account, and an audit account).

• Confirm our choices and choose Set up landing zone.

• AWS Control Tower takes time (about 30 to 45 minutes) to set up all of the resources in your landing zone

Prerequisites: Automated pre-launch checks

Before setting up the landing zone by AWS Control Tower, it automatically runs a series of pre-launch checks in our account. There's no action required on our part for these checks, which ensure that your management account is ready for the changes that establish our landing zone.

By default, all accounts are subscribed to these services.

AWS Control Tower runs:

The existing service limits for the AWS account must be sufficient for AWS Control Tower to launch.

The AWS account must be subscribed to the following AWS services:

• Amazon Simple Storage Service (Amazon S3)

• Amazon Elastic Compute Cloud (Amazon EC2)

• Amazon SNS

• Amazon Virtual Private Cloud (Amazon VPC)

• AWS CloudFormation

• AWS CloudTrail

• Amazon CloudWatch

• AWS Config

• AWS Identity and Access Management (IAM)

• AWS Lambda

Step 1: Create our shared account email addresses

In order to set up our landing zone with new shared accounts, AWS Control Tower requires two unique email addresses that aren't already associated with an AWS account. Each of these email addresses will serve as a collaborative inbox -- a shared email account -- intended for the various users in our enterprise that will do specific work related to AWS Control Tower.

If we are setting up AWS Control Tower for the first time, and if we are bringing existing security and log archive accounts into AWS Control Tower, we can enter the current email addresses of the existing AWS accounts.

The email addresses are required for:

*Audit account *– This account is for our team of users that need access to the audit information made available by AWS Control Tower. We can also use this account as the access point for third-party tools that will perform programmatic auditing of your environment to help us audit for compliance purposes.

Log archive account – This account is for our team of users that need access to all the logging information for all of your enrolled accounts within registered OUs in our landing zone.

These accounts are set up in the Security OU when we create our landing zone. As a best practice, AWS recommends that when we perform actions in these accounts, we should use an IAM Identity Center user with the appropriately scoped permissions.

Key items to configure during setup

• We can select our top-level OU names during setup, and you also can change OU names after we set up our landing zone. By default, the top-level OUs are named Security and Sandbox.

• During setup, we can select customized names for the shared accounts that AWS Control Tower creates, called log archive and audit by default, but we cannot change these names after setup. (This is a one-time selection.)

• During setup, we can optionally specify existing AWS accounts for AWS Control Tower to use as audit and log archive accounts. If we plan to specify existing AWS accounts, and if those accounts have existing AWS Config resources, we must delete the existing AWS Config resources before you can enrol the accounts into AWS Control Tower. (This is a one-time selection.)

• If we are setting up for the first time, or if we are upgrading to landing zone version 3.0, we can choose whether to allow AWS Control Tower to set up an organization-level AWS CloudTrail trail for our organization, or you can opt out of trails that are managed by AWS Control Tower and manage your own CloudTrail trails. We can opt into or opt out of organization-level trails that are managed by AWS Control Tower any time you update your landing zone.

• We can optionally set a customized retention policy for our Amazon S3 log bucket and log access bucket, when we set up or update your landing zone.

Configuration choices that cannot be undone

• We cannot change your home Region after you've set up your landing zone.

• If we are provisioning Account Factory accounts with VPCs, VPC CIDRs can't be changed after they are created.

Step 2. Configure and launch your landing zone

Before we launch our AWS Control Tower landing zone, determine the most appropriate home Region.

Changing our home Region after we deployed our AWS Control Tower landing zone
requires decommissioning as well as the assistance of AWS Support. This practice is not
recommended.

AWS Control Tower has no APIs or programmatic access for launching our landing zone. To configure and launch your landing zone in the console, perform the following series of steps.

Prepare: Navigate to the AWS Control Tower console

Open a web browser, and navigate to the AWS Control Tower console at https://console.aws.amazon.com/controltower
In the console, verify that you are working in your desired home Region for AWS Control Tower. Then choose Set up your landing zone.

Step 2a. Review pricing and select your AWS Regions

Do check whether we have correctly designated the AWS Region that we select for our home Region. After we deployed AWS Control Tower, we can't change the home Region.

In our setup process, we can add any additional AWS Regions that we require. We can add more Regions at a later time, if needed, and we can remove Regions from governance.

To select additional AWS Regions to govern

• The panel shows us the current Region selections. Open the dropdown menu to see a list of additional Regions available for governance.

• Check the box next to each Region to bring into governance by AWS Control Tower. Our home Region selection is not editable.

To deny access to certain Regions

In order to deny access to AWS resources and workloads in certain AWS Regions, select Enabled in the section for the Region deny guardrail. By default, the setting for this guardrail is Not enabled.

Step 2b. Configure your organizational units (OUs)

If we accept the default names of these OUs, there's no action we need to take for setup to continue.

To change the names of the OUs, enter the new names directly in the form field.

• Foundational OU – AWS Control Tower relies upon a Foundational OU that is initially named the Security OU. We can change the name of this OU during initial setup and afterward, from the OU details page.

This Security OU contains your two shared accounts, which by default are called the log
archive account and the audit account.

• Additional OU – AWS Control Tower can set up one or more Additional OUs.

If Additional OU is intended for development projects, we can name it as SandboxOU.

If we already have an existing OU in AWS Organizations, you may see the option to skip setting up an Additional OU in AWS Control Tower.

Step 2c. Configure our shared accounts, logging, and encryption

Here, the panel shows the default selections for the names of our shared
AWS Control Tower accounts. These accounts are an essential part of our landing zone. Do not move or delete these shared accounts.

We can choose customized names for the audit and log archive accounts during setup. Alternatively, we have a one-time option to specify existing AWS accounts as our shared accounts.

We must provide unique email addresses for our log archive and audit accounts, and we can verify the email address that we previously provided for our management account. Choose the Edit button to change the editable default values.

About the shared accounts

• *The management account *– The AWS Control Tower management account is part of the Root level. The management account allows for AWS Control Tower billing. The account also has administrator permissions for our landing zone. We cannot create separate accounts for billing and for administrator permissions in AWS Control Tower.

The email address shown for the management account is not editable during this phase of setup. It is shown as a confirmation, so we can check that we are editing the correct management account, in case we have multiple accounts.

• The two shared accounts – We can choose customized names for these two accounts, or bring our own accounts, and we must supply a unique email address for each account, either new or existing.

In order to configure the shared accounts, we have fill in the requested information:

At the console, enter a name for the account initially called the log archive account. Many customers decide to keep the default name for this account.
Provide a unique email address for this account.
Enter a name for the account initially called the audit account. Many customers choose to call it the Security account.
Provide a unique email address for this account.

Optionally configure log retention

Here, we can customize the log retention policy for Amazon S3 buckets that store our AWS CloudTrail logs in AWS Control Tower, in increments of days or years, up to a maximum of 15 years. If we choose not to customize your log retention, the default settings are one year for standard account logging and 10 years for access logging.

This feature also is available when we update or repair our landing zone.

Optionally configure AWS CloudTrail trails

As a best practice, we have to set up logging. If we wish to allow AWS Control Tower to
set up an organization-level CloudTrail trail and manage it for us, choose Opt in. If we wish to manage logging with our own CloudTrail trails or a third-party logging tool, choose Opt out.

We have to confirm our selection when requested to do so in the console. We can change our selection, and opt into, or opt out of, organization-level trails when we update our landing zone.

We can set up and manage your own CloudTrail trails at any time, including organization-level and account-level trails. If we set up duplicate CloudTrail trails, we may incur duplicate costs when CloudTrail events are logged.

Optionally configure AWS KMS keys

If we wish to encrypt and decrypt your resources with an AWS KMS encryption key, select the checkbox.

If we have existing keys, we will be able to select them from identifiers displayed in a dropdown menu. We can generate a new key by choosing Create a key. we can add or change a KMS key any time we update our landing zone.

When we select Set up landing zone, AWS Control Tower performs a pre-check to validate our KMS key.

The key must meet these requirements:

• Enabled
• Symmetric
• Not a multi-Region key
• Has correct permissions added to the policy
• Key is in the management account

We may see an error banner if the key does not meet these requirements. In that case, we have to choose another key or generate a key.

To make the key's policy update

In order to use a KMS key with AWS Control Tower, we must make a specific policy update to the key. At minimum, the KMS key must have permissions that allow AWS CloudTrail and AWS Config to use the chosen KMS key.

Make the required policy update

Navigate to the AWS KMS console at https://console.aws.amazon.com/kms
Select Customer managed keys on the left
In the table, select the key you wish to edit, or select Create a key from the upper right
Under the section called Key policy, make sure we can see the policy and edit it. We may need to select Switch to policy view on the right.

We can copy and paste the following example policy statement. Alternatively, for an existing key, we can ensure that your KMS key has these minimum permissions by adding them to our own existing policy.

We can add these lines as a group in a single JSON statement, or if we prefer, we can
incorporate them line by line into our policy's other statements.

{
"Sid": "Allow CloudTrail and AWS Config to encrypt/decrypt logs",

"Effect": "Allow",

"Principal": {

"Service": [

"cloudtrail.amazonaws.com",

"config.amazonaws.com"

]

"Action": [

"kms:GenerateDataKey",

"kms:Decrypt"

"Resource": "*"

}

The AWS Key Management Service (AWS KMS) allows us to create multi-Region KMS keys and asymmetric keys; however, AWS Control Tower does not support multi-Region keys or asymmetric keys.

AWS Control Tower performs a pre-check of our existing keys. We may see an error message if we select a multi-Region key or an asymmetric key. In that case, generate another key for use with AWS Control Tower resources.

The customer data in AWS Control Tower is encrypted at rest, by default, using SSE-S3.

Step 3. Review and set up the landing zone

• At the console, review the Service permissions and when we are ready, choose I understand the permissions AWS Control Tower will use to administer AWS resources and enforce rules on my behalf.

• In order to finalize our selections and initialize launch, choose Set up landing zone.

• It can take about thirty minutes to complete. During setup, AWS Control Tower creates our Root level, the Security OU, and the shared accounts. Other AWS resources are created, modified, or deleted.

Confirm SNS subscriptions

The email address which we provided for the audit account will receive AWS Notification – Subscription Confirmation emails from every AWS Region supported by AWS Control Tower.

In order to receive compliance emails in our audit account, we must choose the Confirm subscription link within each email from each AWS Region supported by AWS Control Tower.

Reference

https://www.wellarchitectedlabs.com/security/quests/quest_100_quick_steps_to_security_success/1_control_tower/

Labs:

https://controltower.aws-management.tools/immersionday/

Hope you have got some idea about AWS control tower.

Happy Learning 📚

Social Footprints:

Thank you!

Security best practices of Amazon S3

Srinivasa Raju Addepalli — Thu, 01 Sep 2022 06:30:06 +0000

Security best practices of Amazon S3

Amazon S3

Amazon S3 is an object storage service. It enables us to store virtually unlimited amounts of data. Data files are stored as objects.

We place objects in a bucket. Every S3 bucket name must be globally unique across Regions (unique across all AWS customer accounts).

The objects we store can vary in size from 0 bytes to 5 TB. Though individual objects cannot be larger than 5 TB, we can store as much total data as we need.

Object values are immutable, which means that after we upload an object, we cannot modify the value. If we want to modify the object, we must make a change outside of Amazon S3 and then re-upload the object.

Objects also include metadata, which is a set of name-value pairs we can use to store information about the object. we can assign metadata, which is referred to as user-defined metadata, to our objects in Amazon S3. Amazon S3 also assigns system-metadata to these objects, which it uses for managing objects.

Security of Amazon S3 - Introduction

Security is a shared responsibility between AWS and customers. AWS is responsible for the “security of the cloud,” and customers are responsible for “security in the cloud”

Security of the cloud

AWS is responsible for protecting the infrastructure that runs Amazon Simple Storage Service (Amazon S3). The effectiveness of the security is regularly tested and verified by third-party auditors as part of the AWS compliance programs.

Security in the cloud

Our responsibility is managing access to our data (by using tools to apply the appropriate permissions and access levels). We are also responsible for your organization’s requirements, and applicable laws and regulations.

Key security best practices of Amazon S3

• Access control

• Data protection

• Monitor and audit security settings

Amazon S3 offers access policy options broadly categorized as resource based policies and user policies. Access policies we attach to our resources (buckets and objects) are referred to as resource-based policies.

When granting permissions, we have to decide who is getting them, which Amazon S3 resources they are getting permissions for, and specific actions we want to allow on those resources.

By default, all Amazon S3 resources (buckets, objects, and related sub resources (lifecycle configuration and website configuration) are private.

Access Control best practices:

• Implement a “Least Privilege” access model to limit access to S3 resources by using a combination of Identity and Access Management (IAM) policies, bucket policies and S3 Access Points

• Ensure that our S3 buckets are not publicly accessible

• Limit access to specific Virtual Private Clouds (VPCs) or known IP address ranges with bucket policies, and access point policies

• Use IAM roles for applications and AWS services that require Amazon S3 access

• Consider Amazon S3 presigned URLs or Amazon CloudFront signed URLs to provide limited-time access to Amazon S3 for specific applications

• Use Amazon S3 VPC Endpoints and Service Control Policies

• Use Access Analyzer for S3 to monitor and control access to our data

Data protection best practices for S3

• Encrypt all Amazon S3 data at rest using Server-side Encryption (SSE) or client-side encryption

• Enforce encryption-in-transit for access to Amazon S3

• Enable object versioning

• Enable Multi-factor Authentication (MFA) Delete and S3 Object Lock when appropriate

• Consider S3 Replication to different AWS accounts to protect our data and remain compliant

• Use tools including Amazon Macie, Amazon GuardDuty for S3, and Amazon S3 Inventory to protect your sensitive data Monitor

Monitor and audit security settings for S3

• Audit Amazon S3 API actions using AWS CloudTrail

• Monitor data access from Amazon S3 with access logging

Other S3 best practices

Encryption of data at rest

We can use Server-Side Encryption and Client-Side Encryption for protecting data at rest in Amazon S3

Server-Side Encryption – Request Amazon S3 to encrypt our object before saving it on disks in its data centers and then decrypt it when you download the objects. Server-side encryption can help reduce risk to our data by encrypting the data with a key that is stored in a different mechanism than the mechanism that stores the data itself.

Amazon S3 provides these server-side encryption options:

Server-side encryption with Amazon S3‐managed keys (SSE-S3).
Server-side encryption with KMS key stored in AWS Key Management Service (SSE-KMS).
Server-side encryption with customer-provided keys (SSE-C).

Client-Side Encryption – Encrypt data client-side and upload the encrypted data to Amazon S3

We have to manage the encryption process, the encryption keys, and related tools. As with server-side encryption, client-side encryption can help reduce risk by encrypting the data with a key that is stored in a different mechanism than the mechanism that stores the data itself.

Enforce encryption of data in transit

We can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the condition aws:SecureTransport on Amazon S3 bucket policies.

Hope you have got some basic idea about Security best practices of S3.

Happy Learning 📚

Thank you!

Social Footprints:

Six Pillars of AWS Well-Architected Framework

Srinivasa Raju Addepalli — Mon, 22 Aug 2022 03:54:00 +0000

AWS Cloud Services - Pillars of AWS Well-Architected Framework

What is Cloud Architecture

Cloud architecture is the practice of applying cloud characteristics to a solution that uses cloud services and features to meet an organization’s technical needs and business use cases. A solution is similar to a blueprint for a building.

We can use AWS services to create highly available, scalable, and reliable architectures

Software systems require architects to manage their size and complexity.

Cloud architects

• Engage with decision makers to identify the business goals and the capabilities that need improvement.

• Ensure alignment between technology deliverables of a solution and the business goals.

• Work with delivery teams that are implementing the solution to ensure that the technology features are appropriate.

Having well-architected systems increases the likelihood that the technology deliverables will help meet business goals.

AWS Well-Architected Framework

The AWS Well-Architected Framework provides a consistent approach to evaluate cloud architectures and guidance to help implement designs.

It is based on six pillars - operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability.

The pillars of the AWS Well-Architected Framework

Operational Excellence

The Operational Excellence pillar addresses the ability to run systems and gain insight into their operations to deliver business value. It also addresses the ability to continuously improve supporting processes and procedures.

When we design a workload for operations, we must be aware of how it will be deployed, updated, and operated. Implement engineering practices that align with defect reductions and quick, safe fixes. Enable observation with logging, instrumentation, and business and technical metrics so that you can gain insight into what is happening inside your architecture.

In AWS, we can view our entire workload (applications, infrastructure, policy, governance, and operations) as code. It can all be defined in and updated using code. This means that we can apply the same engineering discipline that we use for application code to every element of our stack.

Security

The Security pillar addresses the ability to protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies.

Our architecture will present a much stronger security presence if we implement
a strong identity foundation, enable traceability, apply security at all layers, automate security best practices, and protect data in transit and at rest.

Reliability

The Reliability pillar addresses the ability of a system to recover from infrastructure or service disruptions and dynamically acquire computing resources to meet demand. It also addresses the ability of a system to mitigate disruptions such as misconfigurations or transient network issues. It can be difficult to ensure reliability in a traditional environment. Issues arise from single points of failure, lack of automation, and lack of elasticity. By applying the best practices outlined in the Reliability pillar, we can prevent many of these issues. It will help us and our customers to have a properly designed architecture with respect to high availability, fault tolerance, and overall redundancy.

Performance efficiency

choose efficient resources and maintain their efficiency ad demand changes
Democratize advanced technologies
Employ mechanical sympathy.

Cost Optimization

Cost optimization is an ongoing requirement of any good architectural design. The process is iterative, and it should be refined and improved throughout our production lifetime. Understand how efficient our current architecture is in relation to our goals can remove unneeded expense. We can consider using managed services because they operate at cloud scale, and they can offer a lower cost per transaction or service.

Sustainability

The Sustainability pillar focuses on environmental impacts, especially energy consumption and efficiency, since they are important levers for architects to inform direct action to reduce resource usage.

The AWS Well-Architected Tool

The AWS Well-Architected Tool is a self-service tool that provides us with on-demand access to current AWS best practices. These best practices can help us build secure, high-performing, resilient, and efficient application infrastructure on AWS.

It helps us review the state of our workloads and compares them to the latest AWS architectural best practices.

This tool is available in the AWS Management Console. We can define our workload and answer a series of questions in the areas of operational excellence, security, reliability, performance efficiency, and cost optimization. The AWS Well-Architected Tool then delivers an action plan with step-by-step guidance on how to improve our workload for the cloud.

We can use the results that the tool provides to identify next steps for improvement, drive architectural decisions, and bring architecture considerations into our corporate governance process.

References :

https://www.wellarchitectedlabs.com/operational-excellence/

https://www.wellarchitectedlabs.com/security/

https://www.wellarchitectedlabs.com/reliability/

https://www.wellarchitectedlabs.com/performance-efficiency/

https://www.wellarchitectedlabs.com/cost/

https://www.wellarchitectedlabs.com/sustainability/

https://www.wellarchitectedlabs.com/well-architectedtool/

Social Footprints :

Happy Learning 📚

Thank you!

DEV Community: Srinivasa Raju Addepalli

AWS MGN Overview

AWS MGN

AWS MGN Benefits

Initializing Application Migration Service

Accessing the Application Migration Service Console

AWS MGN Lifecycle

Agent Installation

Continuous Replication

Testing and Cutover

Best Practices

Planning

Testing

Successful Implementation

Best Practices for Ensuring Project Success

Migration workflow

AWS MGN Pricing

Additional charges

Pricing details

*Supported AWS Regions *

CloudEndure Migration EOL

References

Social Footprints:

AWS Control Tower Overview & Set up

AWS Control Tower Overview & set up

Introduction

Features of AWS Control Tower

Structure of an AWS Control Tower Landing Zone

Set Up AWS Control Tower

Step 1: Create our shared account email addresses

Step 2. Configure and launch your landing zone

Step 2a. Review pricing and select your AWS Regions

Step 2b. Configure your organizational units (OUs)

Step 2c. Configure our shared accounts, logging, and encryption

About the shared accounts

Step 3. Review and set up the landing zone

Reference

Social Footprints:

Security best practices of Amazon S3

Security best practices of Amazon S3

Amazon S3

Security of Amazon S3 - Introduction

Key security best practices of Amazon S3

Access Control best practices:

Data protection best practices for S3

Monitor and audit security settings for S3

Other S3 best practices

Encryption of data at rest

Enforce encryption of data in transit

Social Footprints:

Six Pillars of AWS Well-Architected Framework

AWS Cloud Services - Pillars of AWS Well-Architected Framework

What is Cloud Architecture

Cloud architects

AWS Well-Architected Framework

Operational Excellence

Security

Reliability

Performance efficiency

Cost Optimization

Sustainability

The AWS Well-Architected Tool

References :

Social Footprints :

Supported AWS Regions