sábado, 10 de agosto de 2019

What should we know about AWS Migration?

I did and I used this summary with some bullets and some parts of text extracted from AWS papers and from come online courses like cloud guru, linux academy, udemy. To study concepts about  AWS Migration.
I hope it could be useful to someone.
Cloud Adoption Framework
Business:
Creation of a strong business case for cloud adoption.
Business goal are congruent with cloud objective.
Ability to mensure benefits (TCO,ROI)

People:
Evaluate  organizacional roles and structure, new skill and process needs and identify gaps.
Incentives and Career Management aligned with evolving roles.
Training options appropriate for learning styles.

Plataform:
Resource provisioning can happen with standardisation.
Architecture pattern adjusted to leverage cloud native.
New application development skills and processes enable more agility.

Security:
Identity and access Management modes change.
Logging and audit capabilities will envolve.
Shared Responsibility Model removes some and adds some facets.

Operations: 
Services monitoring has potential to be high automated.
Performance management can scale as needed.
Business continuity and disaster recovery takes on new methods in the cloud. 


Cloud Adoption Phases





Hybrid Architecture

Hybrid Architectures make use of cloud resources along with on-premises resources.
Very common first step as a pilot for cloud migrations.
Infrastructure can argument or simple be extensions of on-premises platform- VMWare for example.
Ideally, integrations are loosely coupled, meaning each end can exits without extensive knowledge of the other side.

 

Storage Gateway creates a bridge between on-premises and AWS.
Seamless to end-users.
Common first step into the cloud due to low risk and appealing economics.

 


Middleware often a great way to leverage cloud services.
Loosely coupled canonical based.

 

VMWare vCenter plugin allows transparent migration of VMs to and from AWS.
VMWare Cloud furthers this concept with more public cloud native features.

Migration tools 

AWS Server Migration Service

Automates migration of on-premises VMWare vSphere or Microsoft Hyper-V/SCVMM virtual machines to AWS.
Replicates VMs to AWS, syncing volumes and creating periodic AMIs.
Minimizes cutover downtime by syncing VMs incrementally.
Supports Windows and linux VMs only.
The Server Migration Connector is downloaded ad a virtual appliance into your on-perm vSphere or Hyper-V setup.

Database Migration Service

DMS along with the Schema Conversion helps customers migrate databases to AWS RDS or EC2-bases database.
Schema Conversion Tools (SCT) can copy database schemas for homogeneous migration(Same database) and contest schemas for heterogeneous migration(different database ).
DMS is used for smaller, simpler conversion and also supports MongoDB and DynamoDB.
Schema Conversion Tools (SCT) used for large, more complex datasets like data warehouses.
DMS has replication function for on-premises to AWS or to Snowball or S3.

 

Application Discovery Service

Gathers information about on-premises data centers to help in cloud migration planning.
Often customers don’t know the full inventory or status of all their data centers assets, so this tool helps with that inventory.
Collects configs, usage and behaviour data from yours servers to help in estimating TCO (Total Cost of Ownership) of running on AWS .
Can run as agent-less (VMWare environment) or agent-based (non-VMWare environment).
Only supports those OSes that AWS supports (Linux and Windows)./

AWS Migration HUB

Migration hub simplifies and accelerate discovery and migration form your data centers to the AWS cloud.

CIDR Reservation

Ensure your IP addresses will not overlap between VPC and on-premises.
VPCs supports IPV4 netmasks range from /16 to /28.
  • /16 = 255.255.0.0 = 65,024 Hosts 
  • /28 = 255.255.255.240 = 16 Hosts

5 IPs are reserved in every VPC subnet (example: 10.0.0.0/24).
  • 10.0.0.0 Network Address
  • 10.0.0.1 Reserved by AWS for VPC router
  • 10.0.0.2 Reserved by AWS for DNS
  • 10.0.0.3 Reserved by AWS for future use
  • 10.0.0.255 VPCs don’t supports broadcast so AWS reserves this address.

Network Migration

Most organisation start with a VPC connection to AWS.
As usage grows, they might choose Direct connect but keep the VPN as a Backup.
Transition from VPN to Direct Connect can be relatively seamless using BGP.
Once Direct Connect is set-up, configure both VPN and Direct Connect within the same BGP prefix.
From the AWS side, the Direct Connect path is always preferred.

Amazon Snow Family

Evolution of AWS Import/Export process.
Move massive amounts of data to and from AWS.
Data transfer as fast or as slow as you ’re willing to pay an common carrier.
Encrypted at rest.

AWS Import/Export: Ship an external hard driver to AWS. Someone at AWS plugs it in and copies your data to S3.
AWS SnowBall: Ruggedized NAS in box AWS ships to you. You copy over up to 80TB of your data and ship it back to AWS. They copy the data over to S3. 
AWS SnowBall Edge: Same as Snowball, but will onboard Lambda and clustering.
AWS Snowmobile: A literal shipping container full of storage (up to 100PB) and a truck to transport it.


AWS CAF perspectives


Organizational change management to accelerate your cloud transformation


Business Drivers

The number one reason customers choose to move to the cloud is for the agility they gain. The AWS Cloud provides more than 90 services including everything from compute, storage, and databases, to continuous integration, data analytics, and artificial intelligence.

Common drivers that apply when migrating to the cloud are:

  • Operational Costs
  • Workforce Productivity
  • Cost Avoidance
  • Operational Resilience
  • Business Agility

Migration Strategy

The 6 R’s”: 6 Application Migration Strategies


Migration Pattern
Transformation Impact
Complexity
Refactoring
Rearchitecting and recoding require investment in new High capabilities, delivery of complex programs and projects, and
potentially significant business disruption. Optimization for the
cloud should be realized.
High
Replatforming
Amortization of transformation costs is maximized over larger High migrations. Opportunities to address significant infrastructure
upgrades can be realized. This has a positive impact on
compliance, regulatory, and obsolescence drivers.
Opportunities to optimize in the cloud should be realized.
High
Repurchasing
A replacement through either procurement or upgrade. Medium Disposal, commissioning, and decommissioning costs may be
significant.
Medium
Rehosting
Typically referred to as lift and shift or forklifting. Automated Medium and scripted migrations are highly effective.

Medium
Retiring
Decommission and archive data as necessary. Low

Low
Retaining
This is the do nothing option. Legacy costs remain and Low obsolescence costs typically increase over time.
Low

  • 1. Re-host (Referred to as a “lift and shift.”)
    • Move applications without changes
  • 2. Re-platform (Referred to as “lift, tinker, and shift.”)
    • Make a few cloud optimizations to achieve a tangible benefit.
  • 3. Re-factor / Re-architect  
    • Re-imagine how the application is architected and developed using cloud-native features.
  • 4. Re-purchase  
    • Move from perpetual licenses to a software-as-a-service model.
  • 5. Retire  
    • Remove applications that are no longer needed
  • 6. Retain ( Referred to as re-visit.)
    • Keep applications that are critical for the business but that require major refactoring before they can be migrated


Comparison of cloud migration strategies



Your migration strategy  should address the following questions:
  • Is there a time sensitivity to the business case or business driver, for example, a data center shutdown or contract expiration?
  • Who will operate your AWS environment and your applications? Do you use an outsourced provider today? What operating model would you like to have long-term?
  • What standards are critical to impose on all applications that you migrate?
  • What automation requirements will you impose on applications as a starting point for cloud operations, flexibility, and speed? Will these requirements be imposed on all applications or a defined subset? How will you impose these standards?

Building a Business Case for Migration

A migration business case has four categories:
1) run cost analysis
2) cost of change
3) labor productivity
4) business value.

A business case for migration addresses the following questions:

  • What is the future expected IT cost on AWS versus the existing (base) cost?
  • What are the estimated migration investment costs?
  • What is the expected ROI, and when will the project be cash flow
  • positive?
  • What are the business benefits beyond cost savings?
  • How will using AWS improve your ability to respond to business changes?

The data from each value category shown in the following table provides a compelling case for migration.

 

The following are key elements of the platform work stream:

AWS landing zone – provides an initial structure and pre-defined configurations for AWS accounts, networks, identity and billing frameworks, and customer-selectable optional packages.

Account structure – defines an initial multi-account structure and pre- configured baseline security that can be easily adopted into your organizational model.

Network structure – provides baseline network configurations that support the most common patterns for network isolation, implements baseline network connectivity between AWS and on-premises networks, and provides user- configurable options for network access and administration.

Pre-defined identity and billing frameworks – provide frameworks for cross-account user identity and access management (based on Microsoft Active Directory) and centralized cost management and reporting.

Pre-defined user-selectable packages – provide a series of user-selectable packages to integrate AWS-related logs into popular reporting tools, integrate with the AWS Service Catalog, and automate infrastructure.

Application Migration Process


Migration Steps & Tools

Application migration to AWS involves multiple steps, regardless of the database engine:
1. Migration assessment analysis
2. Schema conversion to a target database platform
3. SQL statement and application code conversion
4. Data migration
5. Testing of converted database and application code
6. Setting up replication and failover scenarios for data migration to the target platform
7. Setting up monitoring for a new production environment and go live with the target environment

 

Each application is different and may require extra attention to one or more of these steps:

 

Tools for automate migration 

AWS Schema Conversion Tool (AWS SCT) – a desktop tool that automates conversion of database objects from different database migration systems (Oracle, SQL Server, MySQL, PostgreSQL) to different RDS database targets (Aurora, PostgreSQL, Oracle, MySQL, SQL Server).

AWS Database Migration Service (DMS) – a service for data migration to and from AWS database targets. 


AWS SCT and AWS DMS can be used independently. For example, AWS DMS can be used to synchronize homogeneous databases between environments, such as refreshing a test environment with production data. However, the tools are integrated so that the schema conversion and data migration steps can be used in any order. Later in this guide we will look into specific scenarios of integrating these tools.

AWS Database Migration Service

You can migrate data in two ways:
  • As a full load of existing data
  • As a full load of existing data, followed by continuous replication of data changes to the target

CDC offers two ways to implement ongoing replication:

  • Migrate existing data and replicate ongoing changes - implements ongoing replication by:
        a. (Optional) Creating the target schema.
        b. Migrating existing data and caching changes to existing data as it is migrated.
        c. Applying those cached data changes until the database reaches a steady state.
        d. Lastly, applying current data changes to the target as soon as they are received by the replication instance.

  • Replicate data changes only – replicate data changes only (no schema) from a specified point in time.

Challenges and Barriers

Your organization needs to overcome the following key challenges and barriers during this stage of the transformation:

• Limited knowledge and training
• Executive support and funding
• Purchasing public cloud services
• Purchasing public cloud services
• IT ownership and direction

Reference:

























sábado, 27 de julho de 2019

What should we know about AWS Security? (Part 1)


I did and I used this summary with some bullets and some parts of text extracted from AWS papers and from come online courses like cloud guru, linux academy, udemy. To study concepts about  AWS Security.
I hope it could be useful to someone.

Responsibility for security in cloud:

Customer:
  • Customer data
  • Platform, application, identity, access management
  • Operation system, network, firewall configuration
  • Client-Side Data Encryption
  • Data Integrity Authentication 
  • Server Side Encryption (File System and/or Data)
  • Networking traffic protection (Encryption, Integrity, Identity)

AWS:
  • Software
  • Computer, Storage, Database, Networking 
  • Hardware/ AWS Global Infrastructure
  • Regions, Availability Zones, Edge Locations

AWS offers shared responsibility models for each of the different type of service that we offer:
  • Infrastructure services
  • Container services
  • Abstracted services

The customer are responsible for the security of the following assets:
  • Amazon Machine Images (AMIs)
  • Operating systems
  • Applications
  • Data in transit
  • Data at rest
  • Data stores
  • Credentials
  • Policies and configuration


Shared Responsibility Model for Infrastructure Services


Security Concepts: 
Principle of Least Privileges
  • Give users (or services) nothing more than those privilegies required to perform their intended function. (and  only when they need them)

Security Facets

  • Identity
    • Who are you?
    • AWS Ex: Root Account User, IAM User, Temporary Security credentials
  • Authentication
    • Prove that you’re who you say.
    • AWS Ex: Multi-factor Authentication, Client-Side SSL Certification
  • Authorization
    •  Are you allowed to of this?
    • AWS Ex: IAM Policies
  • Trust
    • Do other entities that I trust say they trust you?
    • AWS Ex: Cross-Account Access. SAML-base federation, Web Identity federation

Typical Components of Security:
  • Identity Providers: Facebook, Google, Cognito
  • Identity Store
  • Identity Broker
  • Federation
  • Servide Provider
  • Identities 

Authentication Flow:


SAML:
  • Can handle both authorization and authentication
  • XML- Based protocol
  • Can contain user, group membership and other useful information
  • Assertion in the XML for authentication, attributes to authorization
  • Best suited for Single sign-on for enterprise users. 

OAuth 2.0
  • Allow sharing of protected assets without having to send login credentials
  • Handles authorization only, not authentication
  • Issues token to client
  • Application validate token with Authorization Server
  • Delegate Access, allowing the client application to access information on behalf of user
  • Best suited for API authorization between apps

OpenID Connect:
  • Identity layer built on top of OAuth 2.0, adding authentication
  • Uses REST/JSON message flows
  • Supports web clients, mobile clients, Javascript Clients
  • Extensible
  • Best suite for Single Sign-on for consumers

Multi-Account Management 
  • Most large organization will have multiples AWS Account
  • Segregation of duties, cost allocation, and increased agility
  • Need methods to properly manage and maintain them

When Should you use Multiple Accounts?
  • Do you require administrative isolation between workloads?
  • Do you require limited visibility and discoverability of workloads?
  • Do you require isolation to minimize “blast radius” ?
  • Do you require strong isolation of recovery and/or auditing data?

AWS Tools for Account Management:
  • AWS Organizations
  • Service Control Policies
  • Tagging
  • Resources Groups
  • Consolidate Billing

Identity Account Structure:
  • Manage all user accounts in one location
  • Users trust relationship from IAM roles in sub-account to grant temporary access
  • Variations included by Business Unit, Deployment Environment, Geography  


Logging Account Structure:
  • Centralized logging repository
  • Can be secured so as to be immutable
  • Can use Service Control Policies (SCP) to prevent sub-account from changing logging settings